Huge difference in query time compared to other methods
zjorz opened this issue · comments
QUERYING FOR OBJECTS:
"computer"
"inetOrgPerson"
"msDS-GroupManagedServiceAccount"
"user"
"group"
"container"
"organizationalUnit"
"domainDNS"
QUERYING FOR ATTRIBUTES:
"accountExpires"
"canonicalName"
"carLicense"
"cn"
"displayName"
"distinguishedName"
"lastLogonTimestamp"
"lockoutTime"
"mail"
"msDS-AllowedToActOnBehalfOfOtherIdentity"
"msDS-AllowedToDelegateTo"
"msDS-SupportedEncryptionTypes"
"msDS-UserPasswordExpiryTimeComputed"
"name"
"nTSecurityDescriptor"
"objectClass"
"ObjectGUID"
"pwdLastSet"
"sAMAccountName"
"servicePrincipalName"
"userAccountControl"
"UserPrincipalName"
"whenCreated"
Number of Objects: 100341
S.DS.P ==> Time Elapsed....: '49.2810517766667' Minutes
ADSI ==> Time Elapsed....: '1.46958625833333' Minutes
AD POSH==> Time Elapsed....: '4.44061052333333' Minutes
ADFIND ==> Time Elapsed....: '2.25115640833333' Minutes
I seriously do not understand why that S.DS.P posh module is so slow
If you need more info, feel free to ask
Hello,
did you run your test with -RangeSize:0 ?
Jiri
specified that option and it is way better now!
Time Elapsed....: '4.28738873333333' Minutes
still surprised that ADSI is faster and that it is near as fast as the ad posh cmdlets
something else:
do you know to convert the binary values of nTSecurityDescriptor and msDS-AllowedToActOnBehalfOfOtherIdentity to human readable values? I have been trying to figure that out but I'm failing miserably. Both are listed in PropertiesToLoad and BinaryProperties parameters
Well, ADSI is compiled code, that's most likely why.
In fact, performance is not a main criteria here - original purpose was to show how to operate LDAP directories from PowerShell, and kind of document some not-well-known knowledge (ranged property retrieval, 1.1 OID, etc.)
something else:
do you know to convert the binary values of nTSecurityDescriptor and msDS-AllowedToActOnBehalfOfOtherIdentity to human readable values? I have been trying to figure that out but I'm failing miserably. Both are listed in PropertiesToLoad and BinaryProperties parameters
Well, I just return byte array, and caller is responsible for converting. Each value has own semantics, so you're supposed to know how to convert to object you want to work with.
For example ntSecurityDescriptor:
#$obj=Find-LdapObject -PropertiesToLoad @('ntSecurityDescriptor') -BinaryProperties @('ntSecurityDescriptor') ....
$dacl = new-object System.DirectoryServices.ActiveDirectorySecurity
$dacl.SetSecurityDescriptorBinaryForm($obj.ntSecurityDescriptor)
#list ACEs
$dacl.AccessBTW I'm thinking about something like lambda that could be registered and would do conversion to desired object on the fly... still lambda would need to be developed by caller, but then code would use it automatically to transform raw values into desired form.
So maybe in some of next version...
I guess we can close this issue now....
Well, ADSI is compiled code, that's most likely why.
In fact, performance is not a main criteria here - original purpose was to show how to operate LDAP directories from PowerShell, and kind of document some not-well-known knowledge (ranged property retrieval, 1.1 OID, etc.)
the option "-RangeSize:0" seriously makes a difference! Thanks!!!!