Get-QADUser vs Get-ADUser

I'm just wondering why there seems to be such a massive performance difference between the Get-QADuser and Get-ADuser.  I know the QAD commands return a lot more data and I have to use them when I need access to the virtual attributes defined in my environment but the speed difference is a millennium apart.  

This takes 6 seconds - measure-command { Get-ADUser    -LdapFilter '(&(sAMAccountType=805306368)(!(|(userAccountControl:1.2.840.113556.1.4.803:=2)(employeeID=*)(employeeNumber=*))))' }  
This takes 2 minutes  - measure-command { Get-QADUser -LdapFilter '(&(sAMAccountType=805306368)(!(|(userAccountControl:1.2.840.113556.1.4.803:=2)(employeeID=*)(employeeNumber=*))))'     -proxy -SizeLimit 0 }  

2 minutes seems like a lifetime when debugging :-) 

I've taken to loading the AD commandlets more and more despite feeling that they are somewhat inferior to the Quest commandlets but convincing others that they shoul dbe using them is pretty hard when the first script they write using them runs so sloooooooly.


Parents
  • Your example is an interesting one because I have always believed that the main reason why the Quest cmdlets are slower is that they implement a more sophisticated (?) name resolution algorithm.  That is to say that when you specify the '-Identity' switch, the cmdlet performs a more thorough search for the object (examines more name-related attributes).  As you have probably experienced, this can have unintended consequences with more objects being returned than you expect in some cases.

    But back to your example...

    You are using a straight-up LDAP query which by my way of thinking would bypass the mechanism I described above so like you, I am surprised by the difference in performance.

    For the very best performance in Active Roles embedded scripts, I often use the ADSI coding approach.  It's very arcane and unfriendly to work with syntax-wise but it is fast.

    Day to day though, like you I will often get use Get-ADUser.

    I maintain though that especially for beginner scripters who just need to get something done, the Quest cmdlets are much friendlier to use both because of the way they implement switches for searching and setting attributes AND because of the additional calculated properties they return.  'Plus they give you a handy way to send Controls to the AR service.Relaxed

  • I have exactly the same sentiments, I just don't understand why they are so much slower and mine is a small environment I can imagine the speed being a real issue in a 100,000 plus user environment.  If I didn't have such a dependence on the ARS virtual attributes I use in my environment I would probably stop using them at all, which is a shame as they are much more feature rich and user friendly and in a multidomain environment allow management of all environments from a single prompt!  

  • You might not have to stop using them for the AR cmdlets don't have to connect through Active Roles. Try eliminating the -Proxy parameter and see if they are on pace with the native AD cmdlets.

Reply Children