I was once asked by a coworker if I had an automation filter in my head that I ran my emails through, after I proposed a solution in Orchestrator to a problem we had. After thinking about it, I’m pretty sure I do!
Anyway, we were recently tasked with documenting all our service accounts on all servers. Normally this task would fall to the lowest person on the totem poll with enough access to login to servers. Instead I did some quick searching and found the scripting guy’s blog where the scripting wife needed to solve the same problem. (link) After modifying the script a little to the following:
get-wmiobject win32_service | select name, startname, startmode
I tested it out on some servers and I was set.
Now to put it in Orchestrator. We just need a list of servers and Powershell remoting. I remembered I have a collection in SCCM with all Windows Servers in it. Here is the example Runbook.
You may not have a collection in SCCM with all your windows servers, or you may not have a SCCM connection via Orchestrator, but you could do the same task importing a list of servers from a text file or CSV. Here is how I get all the collection members from SCCM.
And finally the PowerShell:
And the code for copy and paste purposes
$RunAsAccount = “subscribed DomainUsername”
$RunAsPass = “subscribedPW”
$pass = $RunAsPass | ConvertTo-SecureString -AsPlainText -Force
$credentials = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $RunAsAccount, $pass
$session = New-PSSession -computername {subscribed member server name} -credential $credentials
$services = invoke-command -session $session -scriptblock {
get-wmiobject win32_service | select name, startname, startmode
} | export-csv e:logsservicessubscribed member server name.csv
remove-pssession $session
As you can see I am piping the variable $services to a CSV on a local drive with the server name as as the filename.
Obviously the account you are using will need access to every server. In my case, this is a domain admin account, your organization my differ, the choice is yours. And the other caveat is that all your servers need to have PowerShell Remoting enabled, again, your mileage may vary depending on your organizations policies.
Some error handling should be added to track if the PowerShell could not connect or run the command on specific servers.
This runbook is provided as an example and is not production ready, please test in your own environment. The runbook is provided as is and without warranty.
You can download the runbook here.