If you take a look at the What’s New section of Runbook Automation (RBA) you see: Windows as a script automation target is supported for quite some time now (since December 2018). However sometimes users contact us with additional questions.
This Deep Dive will try to remedy all of that. We will take a look at the details, explain various options, and hopefully clarify the some ambiguities for you. There are some handy examples in there to get your PowerShell scripts working in no time at all!
First things first, let’s cover our basics here. In order to use PowerShell scripts on Windows endpoints you need to consider the following:
- The Automation – Your automation must be of type script and you need to select the PowerShell type.
- The Script Content – Your script must be in UTF-8 encoding.
- The Script Type – Your script must be a PowerShell script. Other types of scripts, like a Batch script, are not supported.
- The SSH Server – By default, Windows is not installed or shipped with an SSH server. You need to install an SSH server on the Windows system and have it running.
- Default Shell – The default shell on the target endpoint, must be PowerShell.
- The User – The RBA Script Provider, by default tries to run a script automation with a user named ‘root’. As Windows systems typically do not have a user like this, be sure to specify a proper user name, when running the automation. You can set a fixed value in your runbook, if you know which user should be used.
Make sure to set the script type to PowerShell like shown here:
Step by Step Setup Example
In this example I am going to show you, which steps I performed to have a working automation using PowerShell. I will touch a few Microsoft Windows specific topics, which might change in the future, but even though it should be good information to get you going. We will start with a blank Runbook Automation and a blank Windows 10 Server.
- Install openSSH on Windows 10 – Go to “Apps” > “Manage Optional Features” > “Add a feature” > “OpenSSH Server”. This will install the openSSH server on your system.
- Set the default shell – As described on docs.microsoft.com configure the default shell by running the command:
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force
- Properly set ACL for authorized_keys – This is the point where most problems arise. The openSSH server is quite picky on the correct access right of this file. Unfortunately the automated tool called “Repair-AuthorizedKeyPermission” does not set those rights correctly. Instead do the following manually: Find your authorized_keys file under C:\users\$username\.ssh. Open the security properties and click on “Advanced”. Disable Inheritance and let the system convert the settings, if asked. The file needs to have full control permisions from exactly two users. SYSTEM and your account, which is currently logged in. Delete all other permissions.
- Setup the Script Connection in Runbook Automation – Log in as a user with MANAGER_ROLE and go to Connections. Click on Edit Script connection. Then copy the public SSH key and proceed by saving. The script connection should be displayed with a green checkmark and connected message.
- Add the RBA public key – On the Windows server, open the authorized_keys file and add the RBA public key to it.
- Create a PowerShell script automation – Use the Automations page to create a new Script Automation. Be sure to set PowerShell as the subtype.
- Test your Automation – On the Automations page, find your Automation and directly test it. On the screen enter your Windows Server hostname as the target and the Windows Server user from before as your user. The result should be successful now.