Automating Run As Account Distribution – Finally!

<!--[if lt IE 9]>


Comments (29)
  1. Kevin Holman says:

    This post is new Naeblis – give them time. This will be a huge timesaver for people, for sure!

  2. Kevin Holman says:

    @Khaled –

    The only way that can happen is if you used a group that contained no objects, or you misspelled the displayname of the group.

  3. Kevin Holman says:

    @Khaled – make sure you are using a group that contains ONLY Windows Computer objects.

  4. Khaled_Hamad says:

    Thanks a lot. It worked, but there is an error appeared in powershell (I’m beginner in powershell)

    Compare-Object : Cannot bind argument to parameter ‘ReferenceObject’ because it is null.
    At C:Automating_RunAs_Account_Distribution.ps1:42 char:31
    + $DistClusters = Compare-Object <<<< $DistComputerNames.DisplayName $DistAgents.DisplayName -PassThru
    + CategoryInfo : InvalidData: (:) [Compare-Object], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.CompareObje

  5. Naeblis says:

    Why people are not jumping for joy is beyond me. this is great I will test this out. Thank you Kevin, Tim, and crew for this great tool.

  6. Marnix Wolf says:

    Will certainly cross post it 🙂

  7. Kevin Greene says:

    Awesome work guys – this will definitely save time on deployments and ongoing admin 🙂

  8. Anon says:

    Sportscenter would call this is a "WebGem"

  9. Hjortby says:

    great work! Will be put into use here 🙂

  10. Anonymous says:

    RunAs accounts can be very cumbersome and annoying if they have not been deployed correctly! I think

  11. Anonymous says:

    While working with Kevin Holman, we thought we would combine our two posts on RunAs Account Distribution

  12. MedeBay says:

    This is exactly what we needed to be able to monitor SQL 2012 and 2014. We already have SQL groups populated from a CMDB, now we can use those same dynamic groups to distribute their run as account to.

    But I do have one questioncommentrequest….. It appears that if a server is removed from the group specified in the script it does not get removed from the account distribution list. Any possibility of modifying the script to remove items not currently in
    the group?

  13. Kevin Holman says:

    @MedeBay –

    I already covered that in the script – see the section:

    #Get the current RunAs account distribution as it exists today and save it in an array
    #Comment out this entire section if you want to ignore the current distribution and ONLY go with what it in the group

    All you need to do is comment out the section where I gather the existing distribution membership, then it will always replace.

  14. Kevin Holman says:

    I tested this with a customer today with 735 SQL servers and a healthy mix of multi-node clusters. Worked flawlessly.

  15. Keithk2 says:

    Thanks you for the effort on this script. Unfortunately for me it isn’t working out so well. I am keeping things pretty vanilla. I have a simple group called "SQL Computers" with three explicitly added Windows computer objects. I also have a simple run
    as account name called "SQL monitoring account". When I run the script (on the RMSe) with the updated references it just doesn’t work. When I look at the Ops log from where I ran the script I see an event 3250:

    "RunAsHSDist.ps1 : RunAs HealthService Distribution Script Starting for account: (SQL Monitoring Account) and group: (SQL Computers) "

    followed by an event 3252:

    "RunAsHSDist.ps1 : RunAs HealthService Distribution Script ended in error. The group was not found or contained no objects".

    I have tried every scenario to get this working recreating everything, but same result. Any suggestions would be appreciated.


  16. Keith says:

    Ok I was able to resolve. Apparently the group I was using contained other objects besides windows computer objects. Thanks!

  17. Marlin says:

    Hi Kevin.

    What would this Script look like for SCOM 2007 R2. I made changes from the 2012 to 2007 but keep receiving errors:

    Get-RunAsAccount : Cannot bind positional parameters because no names were given.
    At C:scriptsAutomating Run As Account Distribution.ps1:31 char:10
    + $RunAs = Get-RunAsAccount $RunAsDisplayName
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (:) [Get-RunAsAccount], ParameterBindingException
    + FullyQualifiedErrorId : AmbiguousPositionalParameterNoName,Microsoft.EnterpriseManagement.OperationsManager.ClientShell.GetRunAsAccou


    Get-MonitoringObjectGroup : A parameter cannot be found that matches parameter name ‘DisplayName’.
    At C:scriptsAutomating Run As Account Distribution.ps1:35 char:48
    + $DistComputerNames = Get-MonitoringObjectGroup -DisplayName $DistGroupName | Get …
    + ~~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (:) [Get-MonitoringObjectGroup], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.EnterpriseManagement.OperationsManager.ClientShell.GetMonitoringObjectGroupC


    Thanks in advance.

  18. Pallavi says:

    Hi Kevin,

    Is it possible to append servers to an already existing Run-as-account and not disturb the current Run-as-account group. We already have a Run-as-account group having 1000+ objects. Our requirement is to distribute future SQL servers coming to SCOM.

    Any help is higly apppreciated..!!

    Thanks in Advance

  19. Kevin Holman says:

    @Pallavi –

    I think you missed reading this part in my post:

    "Additionally, many of the scripts will simply REPLACE the RunAs distribution when the run. However, there will almost always be one-off scenarios where you need to quickly add a healthservice to the distribution, even though it might now reside in the core
    group. Therefore the script should provide for a way to gather the existing list of distributed health services, and only add news ones where necessary."

    My script does indeed append – it does not replace. Of course, you should test this first and get a backup of the membership via PowerShell just in case you have a problem running the script if it doesn’t behave correctly.

    1. varalakshmi says:

      Hi Kevin,

      Thanks a lot for this.In our environment we are using single SCOM platform for two domains(CATE&DEV).Recent we have installed SQL 2014 MP and we created two run as accounts one for CATE domain and one for DEV domain.Am in a confusion how to distribute these run as accounts to CATE and DEV servers.Since SQL 2014 Computers group contains both CATE&DEV SQL servers when am mapping run as account in profile am getting error.How to create a groups to separate CATE SQL server and DEV sql server??If i create a two groups manually how about newly added SQL servers?It will be a additional work for me always to add servers manually.
      Kindly suggest us how to proceed for this.


  20. Dominique says:

    Great blog again thanks Kevin!
    In my case it is a little bit different as the Profile (SQL) was distributed with "less secure" first then now I use "More Secure" and all servers with no SQL are getting the alert as the MP(Rules for discovery and monitoring) were distributed previously and
    could not find the profiles/accounts anymore due to the strengthening of the security..
    Any idea how to clean all these alerts? Is it automatic the next time the agent will check for MPs?

  21. Dominique says:

    Hello Kevin,

    Excellent article to add Run As to new servers. Thanks,
    How to remove the RunAs Account from servers which do not need it?
    e.g.: The Run As Account Distribution is changed from "Less Secure" where it was distributed to all servers then now it is "More Secure" and the distribution is limited to few servers.
    How could I handle this as apparently the RunAs account still exist on All Servers even not listed in the New Distribution list of the RunAs Account…
    It is the SQL MP SQL Discovery Account…?


  22. Dominique DUCHEMIN says:

    What was the equivalent in SCOM 2007 R2?

    1. Bruno Gabrielli says:

      Hi Kevin,
      good to see another great piece of content from you. Definitely “I am with the Kevin Holman”. I have one issue with the script. The instruction at line 107 ($DistAgents += $ActRunAsOld;) is failing with this output
      Method invocation failed because [Microsoft.EnterpriseManagement.Monitoring.MonitoringObject] doesn’t contain a method named ‘op_Addition’.
      At line:8 char:17
      + $DistAgents += $ActRunAsOld;
      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      + CategoryInfo : InvalidOperation: (op_Addition:String) [], RuntimeException
      + FullyQualifiedErrorId : MethodNotFound

      Any idea why and how to resolve it?

      Thanks in advance,

      1. Bruno Gabrielli says:

        Nm, I found out it was due to a bad copy/paste …

  23. svobodma says:

    Thanks a lot, it solved my problem 🙂

  24. John_Curtiss says:

    in windows server 2016, it seems Microsoft has removed “users” from the default configuration of the “allow log on locally” permission. it’s now only Administrators and Backup Operators. so we have to grant our runas accounts that permission somehow on the servers to which we’re distributing the runas account. is there a best practice on this? or are we assuming that our runas accounts are admins on their respective target servers?

    1. Kevin Holman says:

      It is assumed that runas accounts will be granted whatever rights necessary, to accomplish the workflows that execute under them. This includes local group memberships, or explicit defined access to the registry, perfmon, events, WMI, filesystem objects, etc.

      Log on locally is a requirement for any runas account.

      1. John_Curtiss says:

        I was wrong anyway. It’s exchange that removes the log on locally permission from “users”. I had the same issue on exchange 2010 servers.

Comments are closed.

Skip to main content