The Run Scripts feature in Microsoft System Center Configuration Manager was added as a preview feature in build 1706. It was officially released as of build 1802.
What does it do?
The Run Scripts feature allows running of PowerShell scripts on remote devices in real time, rather than having to prepare a Package or Application, and going through the usual motions to distribute content and deploy the actions. The goal was/is to enable site administrators to execute tasks in real-time for situations which using the traditional (and slower) processes isn’t quick enough to avoid urgent risks or address time-sensitive needs.
If you’re familiar with the “right-click tools” which have been around for many years, this is a similar capability, except that you author your own tools. While the assumption some have is that this feature is intended to return results or values to the console, that is not a requirement. You can deploy a script to restart a service, modify a setting, or anything you wish, and it’s up to you to decide if you want a result to be returned to the console, and what that result should be. So, for example, if you don’t like zero (0) as a success code, you can trap the result and if it equals zero, return your own result of “Success” and so on.
There are some limitations to what this feature can do, but don’t be surprised if these change with future build releases. More information about requirements, limitations and best practices can be found here: https://docs.microsoft.com/en-us/sccm/apps/deploy-use/create-deploy-scripts.
Setting It Up
Once you are on the latest current branch release (1802), and your clients meet the minimum requirements, you are ready to get started. There are only a few moving parts to this feature, but most of them are trivial to configure. In a nutshell:
- Enable the feature
- Configure Script Approval
- Create a Script
- Approve the Script
- Deploy the Script
Enable the Feature
To enable this feature, go to Administration / Updates and Servicing / Features and look for “Create and Run Scripts.” Then make sure it is set to “On”. If not, right-click and select Turn On.
Configure Script Approval
After the feature is enabled, you may want to turn off a default setting which prevents script authors from approving their own scripts. This is only recommended during testing/piloting. As a “best practice” it should be enabled for production environments as an added layer of security and configuration control.
The setting is found on the Hierarchy Settings form, which is under Administration / Site Configuration / Sites. On the General tab, at the bottom you’ll find “Script authors require additional script approver”.
Create a Script
Creating a script is easy. You can either enter your code in the form, or import code from a .PS1 file. This example will enter code directly into the text box in the form.
- Go to the “Software Library” node of the administration console
- Select “Scripts” (appears at the bottom of the list of features)
- Select “Create Script” on the Ribbon Menu (or right-click and choose “Create Script”)
- Provide a name: Refresh Group Policy
- Enter PowerShell code: GPUPDATE /FORCE
- Click Next
- Click Next again
- Click Close
Approve the Script
Only approved scripts will be available for selection when using the feature on managed devices. By default, a new script is unapproved until explicitly approved by someone with sufficient permissions. To approve a script:
- Select the script (Software Library / Scripts)
- From the Ribbon menu, click “Approve/Deny” (or right-click and choose “Approve/Deny”)
- Click Next
- Select Approve, and enter an Approver comment.
- Click Next
- Click Next again
- Click Close
Note: The approver comment is optional, but strongly recommended if you want to enforce change control in your environment. The “Approver” field reflects the user who actually clicked on the form, but the comment would be for who or what approved the script in production, such as a Change Request number, Service Ticket number, etc.
Deploy the Script
You can deploy scripts to individual devices or Device Collections. You can cherry-pick multiple devices within a Collection as well as deploying to the entire Collection.
5 Sample Scripts
The examples below are only for demonstration purposes, and do not include error/exception handling or documentation, comments and so on.
1 – Check if Hyper-V is Installed
Check if Hyper-V is installed and running on a client with Windows 10 (1709 or later)…
if (Get-Service vmms -ErrorAction SilentlyContinue) {Write-Output "Hyper-V installed"}2 – Restart the SCCM Client Service
Restart the client SMS Agent Host service…
Stop-Service ccmexec -Force; Start-Service ccmexec3 – Show File Properties
Show version of Chocolatey installed…
Write-Output (Get-Item "$($env:ProgramData)chocolateychoco.exe" -ErrorAction SilentlyContinue).VersionInfo.FileVersion4 – Install Chocolatey
Install Chocolatey, if not already installed…
if ($env:ChocolateyInstall) {
Write-Output "Installed already"
}
else {
Set-ExecutionPolicy ByPass -Scope Process -Force
Invoke-Expression ((New-Object System.Net.WebClient).DownloadString("https://chocolatey.org/install.ps1"))
Write-Output "Installing now"
}5 – Get a Registry Value
Display the last Windows Update downloads purge time…
(Get-Item -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate").GetValue("LastDownloadsPurgeTime")
(Get-Item -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate").GetValue("LastDownlo
adsPurgeTime")Summary
These are only a few, very basic, examples of what you do with this feature in Configuration Manager. The possibilities are almost limitless, but you should definitely read more about this feature on the Microsoft documentation portal (link) before going further. As with most technologies, there are trade-off issues to consider, and every environment has its unique constraints and possibilities. However, this small change to Configuration Manager opens up a whole new world of capabilities to make device management easier and more efficient than ever before.
