지금 지원 담당자와 채팅
지원 담당자와 채팅

Active Roles 8.2 - Best Practices Guide

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

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

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

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

  1. In the Active Roles Console, right-click the Script Module.

  2. Navigate to Properties > Debugging > Enable debugging, then select the desired tracing level.

  3. 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.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택