ActiveRoles Performance Tip: Use Distinguished Name instead of Canonical Name in OrganizationalUnit Parameters

When making over 100 accounts today for some hard core Skype for Business monitoring, I (re-)discovered that the form of New-QADUser‘s -ParentContainer parameter makes a huge performance difference. I didn’t time it, but noticed that it took about as long to make five accounts using the Canonical Name (mandie.net/Region/State/City/Purpose) as it did to make the rest of the batch using DN, or Distinguished Name (OU=Purpose,OU=City,OU=State,OU=Region,DC=mandie,DC=net).

This was with Quest ActiveRoles Management Shell for AD 1.7, which goes with ARS 6.9. It was an issue back in the QARMS 1.6/ARS 6.8 days, so hopefully Dell has fixed it for recently-released ARS 7.0. I say “hopefully,” because I can’t find QARMS 1.8(?) anywhere in the ARS 7.0 installation download, much less the Release Notes. Anyhow, it is something to do with how ActiveRoles checks your permissions on the Organizational Unit you are attempting to write to.

You might leave the team responsible for ActiveRoles Server at your company, but ActiveRoles Server never really leaves you…

Advertisements

One thought on “ActiveRoles Performance Tip: Use Distinguished Name instead of Canonical Name in OrganizationalUnit Parameters

  1. I’m still running my 6.9 and 7.1 in parallel while I regression test all of my scripts. One of the first issues I hit was that they changed the quest commandlets used and all of my scheduled tasks are designed for easy editing outside of ARS by using the TaskDN and loading the quest commandlets manually.

    Quest changed them into a powershell module so instead of Add-PSSnapin -Name “Quest.ActiveRoles.ADManagement” you need to use Import-Module -Name “ActiveRolesManagementShell”

    I’ve had issues getting the connect-QAdService to connect to the correct back end so I’m currently forcing it to got the server I want. The -proxy switch isn’t enough it seems to get confused and does not reliably connect.

    They also appear to have broken some functionality and I have a service request in for them to fix the issues but because they are custom scripts they are reluctant to do anything. Some exchange attributes cannot be managed using the new commandlets, specifically the allowed senders list. You can read the attribute but not update it. The attribute is dLMemSubmitPerms and take an array of DNs – it’s only manageable when the group is mail enabled and the new commandlets refuse to update the values so you have to resort to using the GUI which is not conducive to automation obviously.

    Like

Write your own memo:

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s