Running scripts on Christmas day (and any other day)

My last blog post of this year will also be about a new (pre-release) feature of Configuration Manager, version 1710. This post will be all about the ability to create and run scripts from the Configuration Manager administration console. To be correct, the ability to create and run scripts was added in Configuration Manager, version 1706, and Configuration Manager, version 1710, added the ability to use parameters with those scripts. It completed the functionality.  My Christmas day present for the community is a walkthrough through this functionality and how it runs on the client device. After reading this post you should be able to understand how your script can create the output and how you can find the correct GUIDs to follow the activity on the client device.

Introduction

Starting with Configuration Manager, version 1706, it’s possible to run PowerShell scripts, via the Configuration Manager console, directly on client devices. Configuration Manager, version 1710, completed this functionality by adding the use of parameters. The ability to run PowerShell scripts on client devices is available in the Configuration Manager administration console, via the Run Scripts option. This makes it easier to automate tasks and, in general, the scripts are understood by a large population. It really simplifies building custom tools. Think about all the custom right-click actions that can now be integrated in this functionality. The biggest advantages of using the Run Script option, are the usage of the notification channel and getting good monitoring information. That means, quick results shown in the Configuration Manager administration console. In this post I’ll show the Run Script option by using a simple PowerShell script that will restart a service on the client device. That service is provided to the script via a script parameter.

Script

Now let’s have a look at the Run Script option in the Configuration Manager administration console. I’ll start by looking at a couple of important prerequisites, followed by how to create, approve and run scripts. I’ll end this section by following the script action to the client device.

Prerequisites

Before looking into the possibilities of the Run Script option, the following prerequisites should be in place to take full advantage of the available possibilities:

  • The client device must be running PowerShell version 3.0, or later;
  • The Configuration Manager clients must be running client version 1706, or later;

Create script

Let;s start by looking at the required steps to create a PowerShell script that can become available via the Run Script option. I’ll do that by using a simple script that can restart a service on a client device, based on the provided script parameter. Based on the result, of the script, a specific script output will be returned. The administrative user, creating the script, must have at least the Create permission for SMS Scripts object class.The following six steps walk through the creation of a PowerShell script (step 3 contains the used script):

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Scripts;
2 On the Home tab, in the Create group, click Create Script to open the Create Script wizard;
3

CS_ScriptOn the Script page, provide the following information and click Next;

  • Script name: Provide a name for the script;
  • Script language: Select PowerShell, as it’s currently the only option;
  • Script: Click Import to browse to a script file and to display it in the wizard. It’s also still possible to edit the imported script;

Note: Declaring variables, as shown with number 1 on the right, will enable an additional page in the wizard for configuring script parameters. The output shown with number 2, can be returned by the client device.

4a

CS_ScriptParametersOn the Script Parameters page, an overview is shown of the provided parameters with the script and it provides the option to set a Default Value. Select the variable and click Edit to adjust the parameter properties (see step 4b). After that, click Next.

Note: This page should provide an overview of the variables as declared in step 3.

4b

CS_ScriptParameterPropertiesOn the Script Parameter Properties dialog box, the information about the name, required status, hidden status and data type is prepopulated based on the declaration of the variable (see step 3). Use this dialog box to configure the following validation properties and click OK:

  • Minimum Length: Specify the minimum number of characters;
  • Maximum Length: Specify the maximum number of characters;
  • RegEx: Specify a regular expression validation;
  • Custom Error: Specify a custom error message.
5 On the Summary page, verify the configuration and click Next;
6 On the Completion page, verify the result and click Close.

Approve script

Before the just created PowerShell script becomes available via the Run Script option, it must be approved by another administrative user with at least the Approve permission for SMS Scripts object class. That will prevent unverified scripts from running on client devices, which should decrease the possibility of running faulty scripts on client devices. The following seven steps walk through the approval of a PowerShell script:

HierarchySettings_GeneralBy default it’s not possible for a script author to approve and/or deny their own scripts. To enable script authors to approve and/or deny their own scripts, open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Site. Now open the Hierarchy Settings and remove the checkbox with Do not allow script authors to approve their own scripts.

Important: It’s strongly advised to only do this in test and/or lab environments.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Scripts;
2 Select the just created script and click Approve/Deny, in the Scripts group, on the Home tab, in the Create group, to open the Approve or deny script wizard;
3

ADS_ScriptOn the Script page, verify the script and click Next;

4

ADS_ScriptParametersOn the Script Parameters page, verify the parameters and click Next;

Note: To verify the details of a parameter, select a parameter and click Details. That will show the script parameter properties, as configured during the creation of the script.

5

ADS_ApproveScriptOn the Approve or deny script page, select Approve, provide an Approver Comment (optional) and click Next;

Note: I know this is stating the obvious, but only approve scripts once you’re certain about their behavior. The ability to run scripts on client devices is just really strong and once the script is triggered it will run almost instantly.

6 On the Summary page, verify the configuration and click Next;
7 On the Completion page, verify the result and click Close.

Run script

After approving the just created PowerShell script, it becomes available via the Run Script option. The administrative user, that will run the script, must have at least the Run permission for SMS Scripts object class and the script will be executed in SYSTEM context on the client device. The following six steps walk through running a PowerShell script:

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2

Open a device collection and right-click a client device and select Run Script to open the Run Script wizard;

Note: It’s also possible to start the Run Script wizard by right-clicking a device collection.

3

RS_ScriptOn the Script page, select the just created script and click Next;

Note: The script GUID is interesting for monitoring the script execution.

4

RS_ScriptParametersOn the Script Parameters page, provide a value for the available parameters and click Next.

5 On the Summary page, verify the details and click Next;
6

RS_MonitoringOn the Monitoring page, verify the script output and click Close.

The script output, on the Summary tab, shows the output as provided in the initial script. Within this summary it’s also possible to look at the exit codes and to look at different chart forms. The Script Details tab shows the general information about the script, like the name, version and parameters and the Run Details tab shows the details about the results, like the device name, execution status, exit code and script output.

Monitor script

Now let’s end this post by looking at the monitoring options for the initiated script. This can be done in real-time, as shown in the step 6, and this can be done by looking at the Script Status node in the Monitoring workspace. Below is on overview of the just triggered script and I’ve included the following highlighted numbers:

  • Number 1 highlights the Show Status button that can be used
    to get the script details, as shown in step 6 of the Run script
    section;
  • Number 2 highlights the Client Task ID that can be used to
    follow the script through the server log files (bgbserver.log) and the client
    log files (ccmnotification.log and script.log), as shown below;
  • Number 3 highlights the Script Guid, as also shown in step
    3 of the Run script section, that can be used to follow the script
    activity in the client log files (script.log), as shown below;
  • Number 4 highlights the Script Output that can be used to
    verify the results. It should refer to the scripted output, as shown in step 3
    of the Create script section.

ConfigMgrConsole_ScriptMonitoring

Let’s continue by following the initiated script through the log files. At least the three log files below are related to this action and together those log files provide a lot of information. As there is some overlap with the log files of last week, I won’t provide the generic information about the log files this time.

BgbServer.log: When initiating a script to run on a client device, this log file shows the information about pushing the script action to the client device, followed by information about the generation of the BGB task status report (.BTS) in the bgb.box inbox (see below). The processing of the BGB task status report can be followed through the bgbmgr.log.

Script_bgbserver

CcmNotificationAgent.log: When initiating a script to run on a client device, this log file shows the arrival of the script action on the client device (see below).

Script_ccmnotification

Script.log: When initiating a script to run on a client device, this log file will show the details about the script that will be executed. That includes the earlier mentioned IDs and the command line that will be used.

Script_script

Let’s end this section by looking at the executed command line in more detail. Below is the highlighted version of the executed command line. That command line clearly shows that the script on the client device is signed, that it uses parameters and that it’s stored locally. The script is stored in C:\Windows\CCM\ScriptStore, which is a hidden folder on the client device. By default only the SYSTEM account has permissions on the script files in that folder.

Executing command line: “C:\Windows\system32\WindowsPowerShell\v1.0\PowerShell.exe” -NoProfile -ExecutionPolicy RemoteSigned -File “C:\Windows\CCM\ScriptStore\D5FF9FBE-D25B-45DB-9771-946076A9FFAD_EB1AA60AF73737F0B342AEED2C5ECB15A9956654BDA4D30263178B3A79E79DD4.ps1” -ServiceName “Group Policy Client”

More information

For more information about the Run Script option, please refer to this article about creating and running PowerShell scripts from the Configuration Manager console.

Restarting a computer couldn’t be easier!

This week I’m still staying in the new features of Configuration Manager, version 1710. This time it’s all about how easy it became to restart a client device. Restarting a client device became a right-click action! It simply couldn’t be easier! This opens up a whole new world for managing client devices with a pending restart. In this blog post, I’ll start with a short introduction about restarting a client device, followed by the simple actions to trigger a restart for a client device. I’ll end this post by following the activity through the log files.

Introduction

Starting with Configuration Manager, version 1710, it’s possible to use the Configuration Manager console to identify client devices that require a restart, and then use a client notification action to restart those client devices. When the restart notification is received by a client device, a notification window opens to inform the user about the restart. By default, the restart occurs after 90 minutes. That might sound like a long period, but that’s related to the configuration of the Client Settings. The restart simply honors the restart behavior, as configured in the Computer Restart tab of the Client Settings.

Trigger a restart

Now let’s have a look at triggering a restart of a client device. The easiest method to trigger a restart, of a client device, is to first identify client devices that are pending a restart, followed by right-clicking those devices and selecting restart. To perform these activities, simply follow the next steps:

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Devices;
2

Open a device collection and add the new Pending Restart column (see below);

PendingRestart_All

3

RC_RestartRight-click a client device, with a pending restart, and select Client Notification > Restart;

Note: Of course it’s not required for a client device to have a pending restart, before the restart option becomes available. The restart option is available for every client device.

4

PendingRestart_NotificationOn the Configuration Manager dialog box, select OK to confirm the restart action for the client device.

5

SC_RestartOn the client device, a Software Center notification window opens to inform the user about the restart. This notification can not be ignored. It provides a countdown and the option to RESTART or HIDE.

Follow the restart

The best method to follow the restart, of the client device, is by using the log files. At least the following three log files are related to this action and together those log files provide a lot of information:

BgbServer.log: This log file records the activities of the notification server, such as client-server communication and pushing tasks to clients. It also records information about the generation of online and task status files to be sent to the site server. When triggering a restart of the client device, this log file shows the information about pushing the restart task to the client device, followed by information about the generation of the BGB task status report (.BTS) in the bgb.box inbox (see below).

bgbserver

CcmNotificationAgent.log: This log file records the activities of the notification agent, such as client-server communication and information about tasks received and dispatched to other client agents. When triggering a restart of the client device, this log file shows the arrival of the restart task on the client device (see below).

ccmnotificationagent

bgbmgr.log: This log file records details about site server activities related to client notification tasks and processing online and task status files. When triggering a restart of the client device, this log file will show information about processing the created BGB task status report (.BTS) from the bgb.box inbox.

bgbmgr

Note: The log snippets above show how quick the notification arrives on the client device. In my test environment that was within the same second.

More information

For more information about the restart client device option, please refer to this article about How to manage clients.

The awesome world of child task sequences

Like last week I’m staying in the world of new features of Configuration Manager, version 1710. This time it’s all about the awesome world of child task sequences. Awesome. To be a bit more specific, the awesome world of child task sequences, which refers to the newly introduced task sequence step Run Task Sequence. This opens up a whole lot of options, from using specific standards throughout all deployments until enabling different administrators from maintaining their own child task sequence. In this post I’ll go through a short introduction about the Run Task Sequence step, followed by the configuration options for the Run Task Sequence step. I’ll end this post with the end result of running a child task sequence, by showing how it’s logged.

Introduction

Starting with Configuration Manager, version 1710, it’s possible to add a new task sequence step that runs another task sequence. That is the Run Task Sequence step. This creates a parent-child relationship between the task sequences. Child task sequences are enablers for creating modular and re-usable task sequences. Before starting with using child task sequences, make sure to be familiar with the following:

  • The parent and child task sequences are combined into a single policy;
  • The task sequence environment is global;
  • The status messages are sent for a single task sequence operation;
  • The child task sequence writes entries to the same smsts.log file (like a group);

Note: Make sure to go through the information mentioned in the More information section, as the second link provides useful information about the abilities.

Configuration

Now let’s have a look at the available configuration options for using the Run Task Sequence step. The four steps below walk through those configuration options. After that, the parent task sequence can be deployed like any other task sequence. However, when deploying a parent task sequence, be aware that the criteria for showing the “high-impact” warning is not detected in Software Center when the child task sequence contains the “high-impact” steps. In that case, use the User Notification properties of the parent task sequence to force the “high-impact” warning.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Operating Systems > Task Sequences;
2 Now either create a new task sequence by using Home > Create > Create Task Sequence, or select an existing task sequence and select Home > Task Sequence > Edit to open the Task Sequence Editor;
3 In the Task Sequence Editor, select Add > General > Run Task Sequence;
4

TS_RunTaskSequenceIn the Run Task Sequence step, it’s as simple as browsing to the task sequence and selecting it.

Note: It’s not possible to select a task sequence that contains a boot image reference. The boot image reference has to be on the parent task sequence.

Note: Keep in mind that any chain containing a disabled task sequence will fail and that the Continue on error won’t work for that step containing the disabled task sequence.

Result

Let’s end this post by having a look at the end result. I’ll do that by looking at the smsts.log file and by looking at the deployment status in the Configuration Manager administrator console. When looking at the deployment status, see screenshot below, the first section shows the start of the parent task sequence and the second section shows the start of the child task sequence, like a group within a normal task sequence.

TS_StatusMessage

When looking at the smsts.log, something similar is shown, see screenshot below. The start of the child task sequence is shown like the start of a group within the parent task sequence.

TS_SMSTSLOG

More information

For more information about the Run Task Sequence step, please refer to the following articles:

Super easy customizing Software Center

This week it’s time for a short blog post about customizing Software Center. And not without reason. About two years ago I did a post about setting the company logo in the new Software Center. I received many reactions on that post about why a Microsoft Intune subscription configuration was required to set a company logo in Software Center. I had no answer. Now that time is over! Starting with Configuration Manager, version 1710, it’s super easy to customize Software Center with Client Settings. Including the company logo! In this post I’ll walk through the available configuration options and I’ll show the end-user experience. Including an additional bonus about the Software Center icons.

Configuration

Starting with Configuration Manager, version 1710, it’s super easy to add company branding elements to Software Center and it’s super easy to specify the visibility of tabs in Software Center. An administrator can now add a Software Center specific company name, set a Software Center configuration color theme, set a company logo in Software Center, and set the visible tabs in Software Center. The following three steps walk through the available easy configuration options.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client Device Settings and select the Software Center section, or open open the Default Client Settings and select the Software Center section;
3 In the Software Center section, it’s possible to configure the following settings;

  • Select these new settings to specify company information: Set to Yes to enable the Software Center customization settings;
  • Company name: Provide a valid company name;
  • Color scheme for Software Center: Select a valid color;
  • Select a logo for Software Center: Browse to the company logo;
  • Enable Applications tab: Set to Yes to enable the Application tab;
  • Enable Updates tab: Set to Yes to enable the Updates tab;
  • Enable Operating Systems tab: Set to Yes to enable the Operating Systems tab;
  • Enable Installation Status tab: Set to Yes to enable the Installation Status tab;
  • Enable Options tab: Set to Yes to enable the Options tab;

SC_ClientSettings

Note: The logo must be a JPEG or PNG of 400×100 pixels with a maximum size of 750 KB.

End-user experience

Now let’s have a look at the end-user experience. To show how the Software Center configuration relates to the actual look-and-feel, I would like to highlights the three sections as shown below.

1 The first section shows the configured Company name, the configured Color scheme and the configured Logo. This relates to the first section of the Client Settings shown above;
2 The second section shows the enabled tabs. This relates to the second section of the Client Settings shown above;
3 BONUS: The third section shows the updated Software Center icons experience. Software Center will no longer distort icons that are larger than 250×250. Administrators can now set an icon with a pixel dimensions of up to 512×512, and it displays without distortion.

SC_Custom