• Replies 3 replies
  • Subscribers 62 subscribers
  • Views 948 views
  • Users 0 members are here
Options
Related

Active Roles CMDlets are HEAVY

nick.springer
over 1 year ago

So wanted to put a little more data behind the ARS vs Native AD.

  • Dataset base on 30 compartmentalized runs of the snippets
  • Time based on total seconds and then averaged

Test scenario 1: Search for a specific user in Domain Y.

Native get-aduser

ARS get-qaduser

ARS DirectoryEntry EDMS://

0.40

1.34

0.18

 

Test scenario 2: Search for a specific user in Domain X.

Native get-aduser

ARS get-qaduser

ARS DirectoryEntry EDMS://

0.48

1.32

0.14

 

Test scenario 3: Search for a specific user in Domain Z.

Native get-aduser

ARS get-qaduser

ARS DirectoryEntry EDMS://

Cannot from primary

1.36

0.19

 

 

Test scenario 3: change description for a specific user in Domain X

Native get-aduser

ARS get-qaduser

ARS DirectoryEntry EDMS://

0.52

3.68

0.38

 

 

The ARS cmdlets are heavy.  This means that while get-aduser returns 11 attributes the ARS cmdlet returns 33.  With the use of EDMS (ADSI calls for ARS the times can be greatly cut).  So what is the consensus on this bloat?  I have read a few posts and KBs, Talks about setting the datatypes, limiting searches etc. 

**Side note on limiting search; the use of -DontUseDefaultIncludedProperties actually causes the cmdlet to run longer...
1.48 with 'DontUseDefaultIncludedProperties'

1.41 WITHOUT 'DontUseDefaultIncludedProperties'

Parents
  • over 1 year ago

    They are absolutely heavy when it comes to scripting bulk operations on many many objects.

    However, for those new to scripting, they are IMO also easier to use because of their many intuitive switches. For example, Get-QADUser -Userprincipalname john.smith@company.com  as opposed to having to do Get-ADUser -ldapfilter "(userprincipalname=john.smith@company.com)" -properties *.

    They also provide a convenient way to send "Controls" to the Active Roles Administrative service.

    I use them but sparingly as my goal is generally to write fast, readable code for add-on's to Active Roles.

Reply
  • over 1 year ago

    They are absolutely heavy when it comes to scripting bulk operations on many many objects.

    However, for those new to scripting, they are IMO also easier to use because of their many intuitive switches. For example, Get-QADUser -Userprincipalname john.smith@company.com  as opposed to having to do Get-ADUser -ldapfilter "(userprincipalname=john.smith@company.com)" -properties *.

    They also provide a convenient way to send "Controls" to the Active Roles Administrative service.

    I use them but sparingly as my goal is generally to write fast, readable code for add-on's to Active Roles.

Children
  • over 1 year ago in reply to JohnnyQuest

    So is the running solution to use the EDMS to create your own modules for your user base?

    If that is the case, can we work to have the powershell module reviewed as it now part of a paid program and "cannot" be obtained freely?

  • over 1 year ago in reply to nick.springer
    nick.springer said:
    So is the running solution to use the EDMS to create your own modules for your user base

    When I write code for my clients, I use a mixture of ADSI/EDMS, the Msft cmdlets, and here and there, the Quest cmdlets.  My clients are mostly users of the Active Roles product so they have access to the latest version of the cmdlets (see below).


    nick.springer said:
    If that is the case, can we work to have the powershell module reviewed as it now part of a paid program and "cannot" be obtained freely?

    The cmdlets have not been "freely distributed" for many years.  They have however been updated - for example with Office 365 related functionality.