Active Roles 8.1.3 - SP1 Release Notes

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.

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.

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.

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.

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.

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.

More than one actions have been selected for execution in Scheduled Task parameters.

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.

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.

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.

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.

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.

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.

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.

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:

• Creating and consenting a new Azure AD Connector or Microsoft 365 Connector with the auto-configuration settings could result in the following error when testing the connection:

  Connection failed
  Cannot connect using the specified connection settings.

• Configuring Azure BackSync could fail with the following error:

  Synchronization Service has returned an error
  Active Roles cannot acquire the access token.

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.

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:

• They retrieved only the first 20 member objects.

• They did not support pagination.

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:

• Members

• MemberOf

• Owners

• TransitiveMembers

• TransitiveMemberOf

• MembersWithLicenseErrors

• ResourceProvisioningOptions

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:

• Members

• MemberOf

• Owners

• TransitiveMembers

• TransitiveMemberOf

• MembersWithLicenseErrors

• ResourceProvisioningOptions

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Previously, when enabling JavaScript and creating a button to run a workflow by following the instructions in Knowledge Base Article 4257804, the button did not work and caused the Web Interface to display the following error:

An error occurred during the last operation.
Error: Property accessor 'TaskOnclickJS' on object 'ActiveRoles.We-b.Application.Controls.TaskBoxList.TaskItemPresenter' threw the following exception:'Object reference not set to an instance of an object.'

The issue is fixed: adding a button to the homepage of the Active Roles Web Interface can run JavaScript and trigger workflows without breaking the Web Interface.