Release Notes
07 September 2023, 08:42
These release notes provide information about the Active Roles 8.1.3 SP1 release. For the most recent documents and product information, see Active Roles Technical Documents on the One Identity support portal.
Active Roles 8.1.3 SP1 (build 8.1.3.10) is a service pack release containing additional resolved issues compared to the original Active Roles 8.1.3 (build 8.1.3.2) release.
For more information on the enhancements in releases 8.1.3 and 8.1.3 SP1, see Enhancements.
For more information on the resolved issues fixed in releases 8.1.3 and 8.1.3 SP1, see Resolved issues.
For more information on the list of known issues, see Known issues.
The following is a list of enhancements contained in both Active Roles 8.1.3 and 8.1.3 SP1.
| Enhancement | Issue ID |
|---|---|
|
In preparation for the deprecation of the Remote PowerShell (RPS) protocol in Exchange Online PowerShell, Active Roles 8.1.3 and 8.1.3 SP1 are 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 Active Roles 8.1.3 SP1 (build 8.1.3.10) and 8.1.3 (build 8.1.3.2).
NOTE: The following issues were fixed only in Active Roles 8.1.3 SP1 (build 8.1.3.10). To check the build of your Active Roles 8.1.3 installation:
In the Active Roles Configuration Center, navigate to 
Alternatively, open the Add or Remove Programs list of the operating system, search for One Identity Active Roles, then click its entry.
| Resolved Issue | Issue ID |
|---|---|
|
Previously, when configuring the Send on Behalf or Forwarding Address settings of a hybrid Azure user in the Exchange Online Properties > Mail flow settings > Delivery Options form, the Web Interface showed the available objects for these settings with their object GUIDs instead of their display names. This issue did not occur when checking the Send on Behalf or Forwarding Address settings of cloud-only Azure users. This issue is now fixed, so these settings are now much easier to use when configuring them for hybrid Azure users. |
415014 |
|
Previously, when configuring Full Access permission for a user to an Exchange Online mailbox, it could occur that Active Roles could not save the permission settings. This issue is now fixed. |
427713 |
NOTE: The following issues were fixed both in Active Roles 8.1.3 (build 8.1.3.2) and 8.1.3 SP1 (build 8.1.3.10).
| Resolved Issue | Issue ID |
|---|---|
|
Previously, when creating a new user with an Exchange mailbox either in the Active Roles Console or in the Web Interface, Active Roles did not populate the Mailbox database list if the performance fix described in Knowledge Base Article 4336544 was applied with a PerformanceFlag registry key value of 2 or 3. This issue was caused by Active Roles also evaluating the values of 2 and 3 specified for the PerformanceFlag key, even though the key supports only two values: 0 (to deactivate the performance fix) and 1 (to enable it). The issue was solved by making sure that Active Roles accepts only values 0 and 1 for the PerformanceFlag key. |
417246 |
|
Previously, in Active Roles Log Viewer, the Active Roles verbose log did not use the correct delta request URL to retrieve more objects. This resulted in not all users being listed under Azure Users. This issue is now resolved. |
417067 |
|
Previously, when checking the OneDrive settings of a hybrid or cloud Azure user, the Active Roles Web Interface and the Active Roles Management Shell:
This issue was caused by incorrect query parameters used for fetching the relevant OneDrive data, and is now fixed. |
412967 |
| 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 |
|
Previously, when opening the Active Roles Configuration Center and selecting the Web Interface tab, the following error could appear: Object reference not set to an instance of an object. This issue occurred due to errors in updating the Web Interface configuration during a product upgrade, and is now fixed. |
387283 |
| Resolved Issue | Issue ID |
|---|---|
|
Previously, in rare occasions, navigating to Configuration > Server Configuration > Scheduled Tasks > Builtin, and running the Dynamic Group Updater scheduled task could result in Active Roles not being able to communicate with the Domain Controller. The Dynamic Group Updater accidentally removed all members of the dynamic group, and to re-add members, the dynamic group had to be manually rebuilt by clicking Rebuild. The issue is now resolved. |
414916 |
|
Previously, when navigating to Configuration > Server Configuration > Scheduled Tasks > Builtin, opening the Azure Manual Cache Control Properties and changing the Manual clear cache script parameter to true in Parameters, manually clearing the cache failed by right-clicking Azure Manual Cache Control > All Tasks > Execute. The following event log entry appeared: ScriptModule: AzureCacheControl An error occurred when executing scheduled task The method or operation is not implemented. The issue is now resolved: running the tasks is successful, and the Manual clear cache script parameter was removed as a result of code refactoring. The Manual clear cache script parameter was removed because it only deleted the cache, but did not refill it, which caused significant lag when using Microsoft Azure. To manually clear cache use the Manual reload cache, which deletes and refills cache, ensuring smooth functionality. NOTE: If you set the values to true of both Manual delta processing and Manual reload cache script parameters, the script will not run and the following event log entry will appear: More than one actions have been selected for execution in Scheduled Task parameters. |
412644 |
|
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 synchronizing user licenses using the Azure AD or Microsoft 365 connectors, synchronization could fail. The issue was caused by querying the users' licenseDetails attribute as part of the synchronization process. When querying the licenseDetails attribute, in some cases, Microsoft Graph API responded with a 404 Not found error message, causing either the Azure AD or the M365 connector to abort the synchronization process. The issue is now resolved: the users that get stuck in Azure AD are now bypassed during the synchronization process and do not cause any errors. |
422136 |
|
Previously, when synchronizing Azure user licenses using the Azure AD or Microsoft 365 connectors, the synchronization process could fail with an Access token is expired error message. This issue occurred in case of a very large amount of users because the access token from Microsoft Graph API was only valid for 1 hour, but synchronizing the licenses took longer, and Synchronization Service did not refresh the access token. The issue is now resolved. |
419838 |
|
Previously, if you used the Synchronization Service Console with a different user than the one used for running Synchronization Service, the following errors could occur:
This issue occurred because Active Roles Synchronization Service could not properly access the secret used for authenticating these connections when you accessed Synchronization Service with a user other than the one that runs the service. The issue was fixed by making sure that Synchronization Service can properly access the certification store where the required secret is stored, regardless of the user you use. |
418137 |
|
Previously, when running Azure BackSync (or any Update sync workflow that used the Azure AD Connector) to synchronize group members after making changes to a group, Azure BackSync (or the sync workflow) failed with the following error: One or more added object references already exist for the following modified properties: 'members'. This issue occurred because Synchronization Service used expand queries to retrieve Azure group members (and object reference type attributes in general) with two limitations:
As Synchronization Service retrieved only the first 20 member objects, Azure BackSync or the Update sync workflow could run into data synchronization anomalies, such as trying to assign an object to a group where it was already a member. The issue was fixed by removing the previous limitations of the expand query, so that it can retrieve every member of a group (or every other object reference type attribute). This fix affects the following object reference type attributes:
|
418031 |
|
Previously, when running a sync workflow that used the Azure AD Connector for group object mapping, Synchronization Service could not map the object reference type attributes on Azure group objects, and showed the following error: Synchronization steps aborted. Details: the given key was not present in the dictionary. This issue occurred because the Azure AD Connector was processing the response incorrectly when querying the affected attributes from Graph API. The issue was fixed by updating the mapping for the following object reference type attributes, so that the Azure AD Connector can process Graph API responses correctly:
|
417804 |
|
Previously, the Microsoft 365 Connector (formerly known as Microsoft Office 365 Connector) could only synchronize up to 1,000 mail users. This limitation has been removed. |
405966 |
|
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 |
|
Previously, the Azure BackSync could only synchronize up to 1,000 contacts. The issue is now resolved. |
387685 |
| Resolved Issue | Issue ID |
|---|---|
|
Previously, after adding members to an Azure group, the value of the objectClass attribute cleared and the Azure group no longer appeared in the list of groups. This issue is now resolved. |
417068 |
|
Previously, in a federated or synchronized identity Azure tenant, creating hybrid users with an Exchange Online Plan 2 license, then adding those hybrid users to a list of users with Full Access resulted in Active Roles not saving the Exchange Online delegation settings, even though the following message appeared when clicking Save: The operation is successfully completed. The issue is now resolved. |
416873 |
|
Previously, 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, in Customization > Global Settings, when enabling or disabling quick searches for AD LDS and Azure AD objects, clicking Save did not save your settings. The issue is now resolved. |
412961 |
|
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. |
412961 |
|
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 configuring the Exchange Online Properties for the on-premises account of a remote shared mailbox, the Full Control permissions of the mailbox appeared blank in the Active Roles Web Interface. |
388526 |
|
Previously, registering a custom primary domain name for the Azure tenant and using it in the -organization parameter in Exchange Online connection strings was not supported by Microsoft and could result in performance issues in the Active Roles Web Interface when fetching tenant information. The issue is now resolved. |
387657 |
|
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 |
© 2024 One Identity LLC. ALL RIGHTS RESERVED. 使用条款 隐私 Cookie Preference Center
