Addressing Known Issues
In large environments, poor Active Roles performance which is linked to high CPU utilization on the SQL server in addition to possible crashes of the Active Roles service could be related to a known issue which is addressed in Active Roles 7.2.1 and later versions, but which is not enabled by default.
In environments with a large number of Microsoft Exchange mailboxes, retrieving accounts with Microsoft Exchange attributes may be noticeably slower than retrieving accounts without Microsoft Exchange attributes. This could be related to a known issue which is addressed in Active Roles 7.2.1 and later versions, but which is not enabled by default.
If the Active Roles Web Interface is the only Active Roles client experiencing performance issues, then there may be a known issue related to SignalR connectivity requirements.
Establish a baseline or benchmark
It can be very useful to gather a performance baseline in order to be able to be able to better provide a contrast against any issues which might be encountered. Active Roles has PerfMon counters which can be very useful for this and for troubleshooting any performance issues.
Update Microsoft Dependencies
Occasionally, there may be an issue in a Microsoft dependency which can cause performance issues and/or memory leaks because of Microsoft Exchange Online PowerShell module being outdated here: Active Roles exceeds 3 GB of memory usage after the service is restarted (331957).
Updating the installed PowerShell modules, for example, has been known to resolve memory leaks in the Active Roles Administration Service process.
In an elevated PowerShell session, run the following cmdlets to update all of the installed PowerShell modules:
Get-InstalledModule | Update-Module -Verbose -Force
Resources on the host server
As a general rule, a real-world deployment of the Windows operating system requires at least 2GB of RAM. In addition, each of the Active Roles components should be allocated at least 1GB of RAM. Therefore, if a server is hosting the Active Roles Service as well as the Web Interface, at least 4GB of RAM should be allocated. This would be sufficient for Active Roles to manage a small to medium environment - thousands of Active Directory objects could possibly be managed comfortably. Larger environments will notice significant performance issues in such a configuration. Extremely large environments, with Active Directory objects in the tens or hundreds of thousands, may encounter out-of-memory errors or outright crashes.
Working with Remote Mailboxes in Microsoft Exchange
In Active Roles 7.1.x, Active Roles 7.2.x and Active Roles 7.3.x, Active Roles can work with remote mailboxes but this functionality is not enabled by default. If this functionality is not turned on, this can be a performance issue as Active Roles will attempt to connect to Microsoft Exchange using the wrong cmdlets, and will then encounter an error. Ensure that the EnableRemoteMail registry key is in place as per this resource.
This registry key is no longer relevant in Active Roles 7.4.x and later versions.
Quick Connect and Active Roles Synchronization Service Connector Performance
Poor connector performance in the Quick Connect or the Active Roles Synchronization Service can sometimes be addressed by enabling multithreading for that connector.
SQL Server Considerations
Having a dedicated SQL instance (one hosting only Active Roles databases) is always recommended.
Microsoft SQL is a resource-intensive application, and will typically consume any available memory on its host server.
To avoid SQL consuming all available memory and negatively impacting performance of the host server, the maximum memory available to SQL should be capped at no more than 2GB less than the total amount of available RAM as per this Microsoft resource. For example, if the Windows host has 16GB of RAM allocated, then a dedicated SQL instance on a dedicated SQL server host should be capped at 14GB.
High CPU utilization on the SQL host can be an indication of missing SQL indexes.
Performance issues affecting only Active Roles Virtual Attributes
If there is a marked difference in performance noted in multiple Active Roles clients when working with Active Roles Virtual Attributes compared to a similar operation which only references Active Directory native attributes, it may be necessary to perform maintenance on SQL indices.
Active Roles Administrative Service and SQL co-location
In labs, pre-production environments, or very small (e.g. 1000 managed objects or less) production environments, it may be possible to have a dedicated SQL instance hosted on the same machine which is hosting Active Roles. In larger production environments, separate dedicated hosts for the Administrative Service and SQL server are recommended. This is especially true for environments with tens of thousands of managed objects.
Other Windows Host Configuration Considerations
The Windows page file settings on the host server can also negatively impact performance if they are set too low. As per this Microsoft resource, the minimum page file size should be equal to the amount of RAM present on the host server, and the maximum size should be three times the amount of RAM present.
Latency to the environment
Active Roles is most sensitive to latency on communications to the SQL Server and to the associated Global Catalog server. Ideally, these resources would be in same site, with latency less than 1ms.
Cached information from before a change in the environment
Active Roles has a few different places where it caches environmental information. If the environment changes significantly (Active Directory schema or functional level updates, Microsoft SQL or Microsoft Exchange major version change, etc.) then this cache may contain obsolete information which negatively impacts performance.
Follow all steps in this reference in order to clear all of these caches.
Obsolete and/or incompatible components
External applications such as Change Auditor, Defender, Recovery Manager, and Authentication Services all deploy Active Roles components. When Active Roles or these external applications are upgraded, older versions of their deployed components may remain in the Active Roles configuration and will need to be disabled and/or removed.
"Expensive" Script calls
There are a few calls within scripts which should be used with caution, as they have the potential to significantly increase computational overhead. Be very careful when using policy scripts with the following triggers:
Any PowerShell scripts which are run by Active Roles should avoid the use of the Exit cmdlet when terminating. This call will actually cause the Active Roles PowerShell runspace to stop and reload. It is recommended to instead use Return to end a script. Enhancement ID 280594 have been created so that Active Roles handles the Exit cmdlet more gracefully.
The Active Roles System Summary will contain an export of all scripts. This file can be searched for instances of these functions or cmdlets - this can help with large or complicated environments with many script modules.
If PerfMon logs indicate that Script module average execution time is a potential performance bottleneck, this could also indicate poor performance when connecting to or working with Microsoft Exchange. When working with Microsoft Exchange 2010, it is an optional configuration to use Remote PowerShell when working with Microsoft Exchange - in all later versions of Microsoft Exchange, it is the only option. These Remote PowerShell calls are included in all Active Roles Script Module performance counters.