Recurring PowerShell Scripts via SCCM Compliance Baseline

There are several valid ways to execute a PowerShell script on a routine, recurring basis across a group of client PCs. In most cases, my preference is to use a SCCM Configuration Item in a Compliance Baseline. In this post, I show you how to accomplish this.

There are several valid ways to execute a PowerShell script on a routine, recurring basis across a group of client PCs. In most cases, my preference is to use a SCCM Configuration Item in a Compliance Baseline.

Wait, What?

That may seem an odd choice if you've never tried it before, but it offers several key benefits:

  • The PowerShell runs completely silent without the need to launch powershell.exe via some other silent means, such as wscript.exe. (For instance, if you try to launch powershell.exe as the action in a Scheduled Task, you'll never get it to run completely silent. The best you can do is a brief flash of the PowerShell console on the user's screen.)
  • The script itself is never actually installed on the client workstations. So, if you need to tweak the script at any time after you have deployed it, it's incredibly easy. Just update the script source in your Configuration Item and you're done. No local script files or task definitions on every workstation to update.
  • Controlling the execution context of the script, either as SYSTEM or as the logged on user is as simple as checking a box.
  • You can make easy use of your existing user or device collections to target the deployment.

Building the Configuration Item

So, let me show you how to set that up. Open the SCCM admin console and navigate to the Compliance Settings section. Start the wizard for creating a new Configuration Item.

Give it an appropriate name, and make sure to select Windows Desktops and Servers (custom).


Select the supported Operating Systems where the script is allowed to run. Just keep in mind that different OSes shipped with different versions of PowerShell. If you're targeting multiple OSes, make sure your scripts are compatible. If you only want to run this on Windows 10 PCs, you'd set it up like this.


On the Settings page, choose to define a new setting. In the Create Setting dialog, use the Script setting type, and choose the appropriate data type for any return value that your script may generate. In most cases, I like to use the boolean data type. That way I can simply return $true or $false from my PowerShell scripts to indicate to SCCM whether the script ran successfully. Also, take note of that checkbox for specifying script execution context and set it according to your needs.


In the Discovery Script section, click Add Script.... This is where you'll enter your actual PowerShell script source. Make sure to choose the proper script language in the combobox at the top.


Next, we need to create a compliance rule for this setting. Since we're just using the compliance mechanism to run a script on a schedule, the only thing that really matters is that the script runs without error. Again, I handle this by designing my scripts to return $true if they execute without error. So, the compliance rule should look like this.


A few more OK's and you're done.


Deploying the Configuration Item

Now you have an SCCM Configuration Item that is comprised of the PowerShell script that you want to run on a recurring basis. The next step is to add it to a Configuration Baseline and deploy it.

Start the wizard to create a new Configuration Baseline. Give it a name and choose Add -> Configuration Items.


Find your new Configuration Item in the list and click Add. Click OK. Click OK again.


Done. Now to deploy it. Right-click on your new baseline and choose Deploy.

Choose the target collection for your deployment and configure the schedule to your needs.


All done! Your SCCM clients will pick up this new baseline during their next policy refresh cycles and begin executing your script on a recurring basis according to the schedule you set up.

I hope this was helpful. If you have any comments or questions, or if you have an idea about how to further improve this approach, you can connect with me via the comments below or via Twitter.