• State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 5877 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Active Roles Management Shell slow when called from powershell

deas
over 5 years ago

Hello,

This is a quite strange problem. We use Active Roles Management Shell for scheduled tasks. By accident we discovered now that those scripts run very slow when started from the command line with Task Scheduler.

I investigated this now and found out the following:

When I open the Active Roles Management Shell and start the script - it runs as it should be.

When I open Windows PowerShell and start the script from this shell - it runs some commands very slow.

Not sure if this has something to do with it - we use it on Windows 2012 R2 with PowerShell 5.1 and Active Roles Management Shell is version 7.3.

To give you an idea what slow means:

Get-QADGroupMember groupname takes 2 seconds in total and I get only one line for each group member as it should be.

The same command on Windows PowerShell with the module ActiveRolesManagementShell loaded takes 45 seconds! And it looks like as if it executes Get-QADGroupMember groupname | ForEach-Object {Get-QADObject $_ | fl *}

I also reproduced it now on my Windows 10 machine. Active Roles Management Shell is fast, the same command from Windows PowerShell is very slow.

Why the hell is it doing such strange things? Have you ever seen such strange things?

Brgds Andreas

  • 0 over 5 years ago

    Do you run your scheduled scripts with the native OS Task Scheduler or the one built into Active Roles?

    If the former, try the Active Roles Task Scheduler.

    I have myself seen where on post 2012 OS's that the Management Shell is very slow to initialize though I believe this has something to do with UAC / account permissions.

  • 0 over 5 years ago in reply to JohnnyQuest

    I am doing this on a different machine with the OS Task Scheduler from Windows. And actually I want to keep it separate.

    This is for the old version, but why not for the new one?

    https://www.quest.com/community/one-identity/active-roles/product-knowledge/w/wiki/51/how-to-schedule-the-ad-management-shell

    I also don´t find a psc1 file for my installation.

    And there is also some documentation how to load the cmdlets in a normal PowerShell session:

    support.oneidentity.com/.../how-to-load-the-active-roles-management-shell-in-a-powershell-session

    But I don´t think that it has something todo with uac or account permissions. I did my tests on the same machine, same user, two PowerShell windows open. One the native Microsoft PowerShell, the other one Active Roles.

    In the meantime I played around a little bit.

    When I do $Test = Get-QADGroupMember -Identity groupname it runs quick on both windows.

    when I then to $Test I get on Active Roles this:

    Name                           Type            DN

    and of course the list of group members.

    But on the Windows PowerShell with the loaded modules it looks like a $Test | fl * and is very slow again! I need to do $Test | ft to get a similar and fast output. And then it looks like this:

    whenCreated         whenChanged         objectSid                                                objectClass

    and a list of those object properties.

    There is something really wrong…

    Sorry - it must be possible to load the Active Roles cmdlets in any PowerShell session and use them.

    Is anybody able to reproduce the problem?

    Brgds Andreas

  • 0 over 5 years ago in reply to deas

    To your point about loading the powershell cmdlets in any shell session...

    import-module activerolesmanagementshell

  • 0 over 5 years ago in reply to JohnnyQuest

    Of course, this assumes that the module was correctly registered on the host in the first place.

  • +1 over 5 years ago in reply to deas

    The Active Roles Management Shell has a type definition which is different from the one loaded by a default PowerShell session. This means that different attributes are included in results returned by the same cmdlet.

    I think that the biggest hit to the performance noted in your environment is the fact that the default PowerShell session is returning objectSID. SID resolution is an expensive process.

    The  workaround for this should be simple: just load the Active Roles Management Shell type definition into your PowerShell session before using your script.

    So, the first line of your script should be this (assuming default installation paths):

    ."C:\Program Files\One Identity\Active Roles\7.3\Shell\ManagementShell.ps1"

    You can take out the Import-Module call.

  • 0 over 5 years ago in reply to Terrance.Crombie

    This is a GREAT idea!!!!!!!

    And it is working perfect!!!!!!!!!

    Thank you so much for helping me!!!!!!!!

    Maybe it will also help others…

    Brgds Andreas