Release Notes
19 May 2023, 18:01
These release notes provide information about the Active Roles 8.1.2 release. For the most recent documents and product information, see Active Roles Technical Documents on the One Identity support portal.
Active Roles 8.1.2 is a patch release with no new functionality.
This release fixes a potential breaking change due to the deprecation of the Remote PowerShell (RPS) protocol in Exchange Online PowerShell, effective from June 2023.
For more information on this breaking change and its related enhancements, see Enhancements.
For more information on other resolved issues fixed in this release, see Resolved issues.
For more information on the list of known issues, see Known issues.
The following is a list of enhancements implemented in Active Roles 8.1.2.
| Enhancement | Issue ID |
|---|---|
|
In preparation for the deprecation of the Remote PowerShell (RPS) protocol in Exchange Online PowerShell, Active Roles 8.1.2 is updated to:
For more information, see Announcing Deprecation of Remote PowerShell (RPS) Protocol in Exchange Online PowerShell in the Microsoft Tech Community portal. NOTE: You can continue using cmdlet New-PSSession to connect to on-premises Exchange Server deployments. |
402974 |
| Enhancement | Issue ID |
|---|---|
|
Updated the Generic SCIM Connector with the following enhancements:
For more information, see Configuring data synchronization with the Generic SCIM Connector in the Active Roles Synchronization Service Administration Guide. |
404915 |
|
In preparation for the deprecation of the Remote PowerShell (RPS) protocol in Exchange Online PowerShell, Active Roles Synchronization Service is updated with the following enhancements:
For more information on configuring the updated connectors, see Working with Microsoft 365 and Working with Microsoft Azure Active Directory in the Active Roles Synchronization Service Administration Guide. |
403476 |
The following is a list of issues addressed in this release.
| Resolved Issue | Issue ID |
|---|---|
|
Previously, scheduled Active Roles operations could fail with the following error if the Active Directory domain controller (DC) assigned to perform the scheduled operation was unavailable: The server is not operational. This issue occurred because Active Roles did not fall back to another working DC in the Disaster Recovery Plan (DRP) process in such cases, and is now fixed. |
407373 |
| Resolved Issue | Issue ID |
|---|---|
|
Previously, when importing a configuration database in the Active Roles Configuration Center, attempting to use a backup encryption key in the Import of the encrypted data tab did not work, and the encryption file could not be used to decrypt the imported database. This issue occurred because even though the Administration Service validated the contents of the encryption file, it did not use it for the actual import process. This issue is now solved, and the key is used properly. NOTE: As this issue is now fixed, make sure not to use the encryption file key to manually restore the encryption key after the import with the Restore-AREncryptionKey command. Use the file only when instructed during the import process. |
405222 |
| Resolved Issue | Issue ID |
|---|---|
|
Previously, when applying both an Access Template (AT) using a Full Control permission and another granular AT denying access to certain password-related attributes (such as PasswordNeverExpires, UserCannotChangePassword, UserMustChangePasswordAtNextLogon) to a user, the deny AT did not take effect for the user. This issue was caused by the AT specifying an explicit deny not taking precedence over the AT using the Full Control permission. The issue was fixed by ensuring that explicit deny ATs always take precedence over inherited allow permissions. |
410412 |
|
Previously, in certain environments, Active Roles might not update Dynamic Groups in time when adding a new rule or forcing a rebuild. Also, in case of more than 1,000 changes, the changes were not processed until the nightly scheduled task. To solve this problem, Active Roles features a rebuilt Dynamic Group logic that removes the 1,000 group member limit for normal group membership changes, and also ensures that changes are now always processed immediately. |
405859 |
|
Previously, when configuring the mail configuration in Configuration > Server Configuration > Mail Configuration > Default Mail Settings Properties to use Exchange Web Services with Exchange Online and send approval responses by email, response emails sent by approvers could stuck indefinitely without being processed by Active Roles. This problem did not affect approval workflows using on-premises Exchange Server mailboxes. The issue was caused by approval notifications not supporting Exchange Web Service modern authentication, and is now fixed. |
404659 |
|
Previously, when configuring the mail configuration in Configuration > Server Configuration > Mail Configuration > Default Mail Settings Properties to use Exchange Web Services with Exchange Online and send approval responses by email, the mailto: links of approval workflow notification emails always contained the service account address even if an impersonated account was configured in the mail configuration settings. The issue was caused by approval notifications not supporting Exchange Web Service modern authentication, so Active Roles could not collect emails from the impersonated account. Instead, it was falling back to the service account address. This issue is now fixed, so when you configure an impersonated account address, that email address will appear properly in the approval workflow email messages. |
404217 |
|
Previously, undoing the deprovision of a user object that was originally licensed via group-based licensing would result in the previous license reassigned to the object directly instead of inheriting it from the group. The issue is fixed and now if a user has a license inherited from a group, after deprovisioning and undo-deprovisioning it, the license will be inherited from the group again instead of being reassigned directly. |
388433 |
|
Previously, after upgrading Active Roles and importing a configuration that contained a scheduled automation workflow, the workflow schedule was disabled, so the workflow could not run as originally scheduled. The issue was caused by unintended data modification: the scheduled workflow stores the Active Roles Service GUID in a database record, but new installations could change this GUID. The issue is now resolved by replacing the previous service GUID with the current one when importing the configuration, so that automation workflows can run as scheduled even after upgrading or reinstalling Active Roles. |
326759 |
| Resolved Issue | Issue ID |
|---|---|
|
Previously, attempting to install Microsoft OLE DB Driver for SQL Server via the Active Roles installer required users to manually install the prerequisite Microsoft Visual C++ Redistributable for Visual Studio packages, as they were not included in the Active Roles installation package. This issue was fixed by including the packages in the installer. |
411389 |
| Resolved Issue | Issue ID |
|---|---|
|
Previously, the Active Roles Management Pack for SCOM showed an incorrect version number. This issue is now fixed. |
405577 |
| Resolved Issue | Issue ID |
|---|---|
|
Previously, when running Azure BackSync with the Azure AD Connector for several thousand users, Synchronization Service did not indicate the number of processed user objects until all user objects were processed. Because of this, it could appear that nothing happened until the on-screen counter jumped to the total number of processed objects. The issue is fixed, and now the counter of processed objects in the Azure AD Connector increases gradually, as expected. |
401938 |
| Resolved Issue | Issue ID |
|---|---|
|
Using a personal view to open an Active Directory (AD) Organizational Unit (OU) whose name contains special character(s) resulted in the following error: Administration Service encountered an error when retrieving properties of the object. The issue was caused by special characters in the request URL of the Web Interface and are now resolved, with the exception of the < character. For more information, see issue 415590 in Known issues. |
414564 |
|
Previously, when setting a custom global color scheme in Customization > Global settings > Color scheme, the customized Web Interface scheme could appear incorrectly in the user interface, with the sidebar colors, various selected elements and certain panes not following the base color of the scheme. This issue was fixed by adjusting the management of customized Web Interface themes. |
407336 |
|
Previously, customizing the Web Interface could negatively impact the functionality and performance of object search queries. Following customization, queries in the Web Interface could return too many objects, and query searches could slow down due to performing complex internal filtering before displaying query results in the Web Interface. This issue is now fixed, so customized Web Interface instances now work without any such problems. |
395064 |
|
Previously, searching for Azure objects took approximately 15-20 seconds. The issue has been resolved by modifying Microsoft Graph API pagination to reduce network traffic. As a result, searching for Azure objects is now significantly faster. |
389314 |
|
Previously, when using the Customization > Directory Objects > Customize Navigation Bar > General option of the Web Interface to open the Item Properties of the Reload button or the Restore Default button, clicking OK to close the dialog without any changes and reloading the configuration resulted in the changed Reload or Restore Default button no longer working. This issue occurred because Active Roles was unable to get the target URL of these buttons, resulting in the Item Properties > URL to open field appearing empty in the Web Interface. If this field was left empty, clicking OK in the dialog to save the button settings broke the button. To fix the issue, the Web Interface now sends a pop-up alert to inform users that the URL to open field cannot be left empty. |
322689 |
|
Previously, when copying a shared, equipment or room mailbox in the Web Interface, the copied mailbox did not inherit the original mailbox type, and was created as a standard user mailbox instead. In other words, the value of its msExchRecipientDisplayType attribute was always set to 1073741824 instead of inheriting the original value. This issue was caused by a Web Interface infrastructure problem, and was fixed by implementing a switch case to determine the type of mailbox and add the proper attribute during the copy process. |
307164 |
© ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center
