Active Roles 8.2 - Best Practices Guide

Introduction Installing and upgrading Active Roles

SQL database options Active Roles Web Interface topologies Active Roles client components Multi-factor authentication and two-factor authentication support Integration with other One Identity and Quest products Customization support

General best practices

Minimum permissions Active Roles service recovery Establishing a baseline or benchmark Active Roles deployment considerations Custom scripts Management History and Report Pack use cases

Management History considerations Report Pack considerations

Job Server

Example: Using a job server for Active Roles Synchronization Service Configuring Active Roles to handle real-time dynamic group updates

Performance bottlenecks

Known performance issues and workarounds Active Roles Synchronization Service connector performance SQL Server considerations Performance issues that are affecting only Active Roles Virtual Attributes Other Windows host configuration considerations Latency to the environment Clearing obsolete cached information Handling obsolete and incompatible external components Preventing high CPU usage when running the Dynamic Group Updater scheduled task Common SQL bottlenecks Common memory bottlenecks Hard drive space bottlenecks CPU, network, third-party integration and Azure integration bottlenecks

Troubleshooting

Active Roles service recovery

General best practices > Active Roles service recovery

By default, the Active Roles service recovery option is not set. As with any Windows service, you can configure recovery options, such as restarting the computer or running a program.

One Identity recommends setting an option that is appropriate for your specific environment. For example, your can use the Run program option to create an email alert with the Send-MailMessagePowerShell cmdlet, so that you can notify the appropriate people in the event of a service failure. For more information on the Send-MailMessage cmdlet, see Microsoft Send-MailMessage in the Microsoft PowerShell documentation.

NOTE: Send-MailMessage is a Microsoft cmdlet and is not supported by One Identity.

Establishing a baseline or benchmark

General best practices > Establishing a baseline or benchmark

One Identity recommends creating a performance baseline to avoid potential performance issues later. Active Roles contains performance monitoring (perfmon) counters that can be useful in both avoiding performance issues and troubleshooting existing ones.

After configuring and installing Active Roles, to determine if additional resources are required, One Identity recommends to monitor the overall resource usage. In some environments, the time required to determine this might take a week, while in others, it might take a month.

Once your system resources match the base usage requirements, One Identity recommends to create a baseline to establish typical resource usage in your environment. Once you have established this typical baseline, it will be much easier to identify any abnormal resource usage scenarios.

For more information on Active Roles perfmon counters and their usage, see Monitoring performance in the Active Roles Administration Guide.

Active Roles deployment considerations

General best practices > Active Roles deployment considerations

Latency between geographic locations can negatively impact user experience and data updates between regions. Consider implementing region-specific Active Roles and SQL Servers to help reduce latency.

For some environments, dedicated servers, such as job servers or Web Interface-only hosts, can help reduce the load on the main Active Roles servers.

Custom scripts

General best practices > Custom scripts

One Identity Support cannot provide assistance for custom scripts. If you need help with custom scripts, contact One Identity Professional Services.

For issues with code snippets or examples from the Active Roles SDK, contact One Identity Support.

In general, consider the following when using custom scripts.

Expensive script calls

Use the following triggers with caution, because they can significantly increase computational overhead:

onPreGet
onPostGet
onGetEffectivePolicy

Scope

Adjust the scope of the scripts to the relevant object class. For example, if the script is intended for user objects, the first line of the script function must be if($Request.class -ne 'user'){return}.

Function usage

Use return, instead of exit.

Using the exit function causes the Active Roles runspace to stop and reload, resulting in a negative performance impact to Active Roles.

NOTE: Always use return in PowerShell.

Connect-QADService

For scripts within Active Roles, using Connect-QADService is not necessary, as all Active Roles cmdlets will function internally as expected.

Troubleshooting scripts

Active Roles saves a verbose log named ds.log that contains a system summary. This system summary also has all scripts within the Active Roles configuration exported in a plain text format. Use this export to quickly search all scripts at once to check if the exit function is used anywhere. This is especially useful for large environments that have many script modules.

You can enable script debugging individually for each script.

To enable script debugging

In the Active Roles Console, right-click the Script Module.
Navigate to Properties > Debugging > Enable debugging, then select the desired tracing level.
To see the debug trace, click View Log.

You can use performance monitoring (perfmon) to troubleshoot performance issues.

If perfmon logs indicate that the average run time of a Script Module is a potential performance bottleneck, it could also indicate poor performance when connecting to or working with Microsoft Exchange. When working with Microsoft Exchange, Remote PowerShell is used. Remote PowerShell calls are included in all Active Roles Script Module performance counters.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.