Technical Preview 1706 feature highlight : Create and run scripts

5 minute read

Create and run scripts feature explained and demoed


As you are well aware, Configmgr usually offers you various different options to get to a certain result. The difficult part is choosing the correct feature for the issue you are trying to resolve.

Luckily for us, the product team has made our lives easier by adding another feature to choose from : Running scripts directly on clients from the collection-node.

TP 1706 Challenges

In the just released technical preview (1706), one of the 14 (!!) new challenges is : Create and run scripts


In order to complete that particular challenge, we need a script that we want to run on our clients. I’ve chosen here to run a script to disable SMBv1 on your (windows 10) clients as that is something most of you are probably working on (or should be working on).

Setting it all up

In order to create a new script, we need to navigate to the Software Library node and all the way at the bottem we see a new entry for Scripts


Right-Click Scripts and select “Create Script” (or select it from the quick action toolbar).

A new wizard will appear allowing you to provide a meaningfull name for your script, select the language (for now, only PowerShell is supported) and the actual Script itself.

Either copy/paste the content of your script or import directly from an existing PS1 file.


Once completed, finish the wizard as usual.

It will be added to the list of scripts you might already have in an “Unapproved” state.


Let’s approve our sample-script by selecting it and clicking the “Approve/Deny” buttom from the quick action toolbar.

A wizard will appear again showing you the selected script. Click Next and Approve the script (obviously, provide some meaningfull comment). Finish the wizard.


Note 1 There is no ability (yet) to approve more than 1 script. Selecting multiple scripts for approval removes the Approve/Deny button from the quick action toolbar.

Note 2 Right-Clicking on a script reveals an interesting hint “Configure whether script authors can approve their own scripts in the site hierarchy settings.”

If we check those hierarchy settings (Administration Node Site Configuration Site), we can see that this is disabled by default :


However, I just approved my own script so for now this setting doesn’t seem to do much, but as such this feature is another safety-feature to prevent us from shooting ourselves in the foot.

Ok, So now that we got an approved script, let’s send it off to some clients.

Before running any script on a client-collection make sure that you know the effects of your script ;-). I’ve done my homework here and it’s safe to turn off SMB1 on all my windows 10 clients.

Select the target Collection and choose “Run Script” from the quick action toolbar. Choose the script you want to run (only 1 can be selected at the same time) and finish the wizard.

That’s it ! 1 challenge completed !


The results

Ok, so we sent a script to a bunch of clients… That’s cool, but where can I see the results? What feedback is there ? Let’s move over to the monitoring node again. First, let’s take a look at “Client Operations”


We can see that we triggered the script at 19:07 on the “All windows 10 Clients”-collection and that all my clients ran it succesfully.

Under the Client Operations, there’s another new entry called “Script Status” that reveals another piece of the puzzle :


This gives us individual feedback per machine, including the output of your script, meaning, everything that was written to the console it seems. With the limited space available in the AdminUI, it’s probably a good thing to keep that output limited to the essentials.

Also, notice the Script Version column displaying a “1”, seemingly indicating some sort of version-control on your scripts. However, at this point it does not seem possible to edit your scripts once you created them in the Software Library pane.

Behind the scenes

This new feature is very powerfull and allows for some nice things to do in the future, but if you’re like me, you are probably also a little bit interested in what’s going on behind the scenes. What technology is used to make this work ?

Well, the fact that you see some results in “Client Operations” in the monitoring node reveals that it’s probably relying on the Client notification Channel (aka BGB). Opening up the BGBServer.Log on my site server indeed confirms this :


We can see that a push notification was sent out to my clients at 19:07 (matching what we saw in the console) and that about 30 seconds later we get feedback that 1 client reported back. The fact that that last line is in red is due to the keyword highlighting feature in CMTrace rather than we had e real error.

And where are those scripts stored ? When we added a new script, there was no ability to save it to a share or any other location. Well, it seems they are stored in SQL directly. Searching the tables for “Script” gave me these results :


and querying the Scripts table itself indeed reveals my scripts !

The script

So the script I ran is nothing special as such and quickly whipped up for this purpose.

if ($PSVersionTable.PSVersion -ge '')
  if (!(Get-PackageProvider | ? {$_.Name -eq 'NuGet'}))
    {  Install-PackageProvider -Name Nuget -force -MinimumVersion }
  if (!(get-module -ListAvailable -Name osccpslogging | ? {$_.Version -ge ''}))
    write-host "installing module"
    install-module -Name OSCCPsLogging -MinimumVersion -Force}

try {$log = Initialize-CMLogging -LogFileName %ccmlog\SMB1_Status.log -ConsoleLogLevel off -fileLogLevel info} catch {}
try {$log.Info("Checking status of SMBv1")} catch{}

$SMB = Get-SmbServerConfiguration
try {$log.Infoformat("Current SMB Configuration on client :","$SMB")} catch{}
if ($SMB.EnableSMB1Protocol -eq $TRUE)
        try {$log.Info("SMB1 Enabled")} catch{}
        try {$log.Info("Disabling SMB1 now ...")} catch{}
            Disable-WindowsOptionalFeature -online -FeatureName SMB1Protocol -NoRestart
            $ErrorMessage = $_.Exception.Message
            try {$log.Error("Oops ...Something went wrong")} catch{}
            try {$log.Error($ErrorMessage)} catch{}
    try {$log.Info("SMB1 is already disabled")} catch{}    

However the top-bit could be very usefull ! We first check if you have PowerShell 5 (or above) installed as we need that to auto-install modules. If so, we verify if “Nuget” is installed, if not, it gets installed and then finally we install Kim’s Logging module, explained here.

This allows us to easily add logging capabilities to any script in the CMTrace format. The Try{} Catch{} blocks around each log-entry is just a precaution as we don’t want the script to fail if something went wrong while installing the logging module.

That’s it ! Enjoy …

Leave a Comment