Standard

Posted by

Posted on

April 6, 2016

Posted under

ActiveRoles, PowerShell

Comments

1 Comment

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…

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

    Reply

Write your own memo:

This site uses Akismet to reduce spam. Learn how your comment data is processed.