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.

Getting the Client Upgrade Settings of ConfigMgr 2012 with PowerShell

GetCliUpgTweThis week, my blog post will be a very short one. It will be a post about my tweet about the client upgrade settings, of a week ago. A big part of this information is also available via the Hierarchy Settings in the console.

Script

In WMI there is the class SMS_ImportedObject, which contains the method Get-ClientUpgradeSettings. This method can be used to get the client upgrade settings and doesn’t need any input parameters. It will give all the information, about the name, version and IDs and can be used via to the following code snippet:

function Get-ClientUpgradeSettings { param ( [string]$SiteCode, [string]$SiteServer ) Invoke-WmiMethod -Namespace root/SMS/site_$($SiteCode) -Class SMS_ImportedObject -Name GetClientUpgradeSettings -ComputerName $SiteServer }

Result

The code snippet will give a result like under here. If you ever had a package that couldn’t be distributed and you couldn’t find it in the console? A big change it can be matched with the this result!

GetCliUpgInf

Deployment of Configuration Baseline failed with error ‘Script is not signed’ in ConfigMgr 2012

This week my post will still be a small one, as my time is still limited during the move to our new home. In between I was still doing some work and trying to find a subject for a presentation/ demo. During that I was working with the Configuration Baseline of UE-V. That baseline is completely based on one Configuration Item, which consists of eight script setting types and those scripts are all written in PowerShell. The deployment of the baseline resulted in error 0x87D00327, which translates to ‘Script is not signed’ (see picture).ScriptIsNotSigned

Solution

In most cases it’s not possible, or allowed, to change the execution policy for PowerShell on the system. So just let the ConfigMgr client “manage it” and then the solution is actually very simple. In the Client Settings, under Computer Agent, there is an option to configure the PowerShell execution policy. The only pitfall in here is that it means something different then someone might think. These are the options:

  • Bypass: The ConfigMgr client bypasses the PowerShell configuration on the local system so that unsigned scripts can run.
  • Restricted (default in ConfigMgr 2012): The ConfigMgr client uses the current PowerShell configuration on the local system, which determines whether, or not, unsigned scripts can run.
  • All Signed (default in ConfigMgr 2012 SP1):The ConfigMgr client runs scripts only if they are signed by a trusted publisher and applies independently from the current PowerShell configuration on the local system.

PSExecPoliThe easiest way to configure this, for the Configuration Baseline, is to follow the next steps:

  • In the Configuration Manager Console navigate to Administration > Overview > Client Settings.
  • On the Home tab, in the Create group, select Create Custom Client Device Settings and the Create Custom Client Device Settings –popup will show.
  • On the General page, fill in with Name <aName> and select Computer Agent.
  • On the Computer Agent page, select next to PowerShell execution policy Bypass and click Ok.
  • Select the new policy <aName> and on the Home tab, in the Client Settings group, select Deploy.
  • Select <aDeviceCollection> and click Ok.

Result

PoliSpyPSExecAs always, now it’s time to take a look at the result. In this case it would be easy to just show a good result of the deployment of the Configuration Baseline, but I want to show some more. I want to show the result of the deployment of the new Client Settings. Normally, the best places to look at the results are the log files. In this case, there is no log file that shows the current setting of the PowerShell execution policy. So the best place to look at that is the old-school Policy Spy. In this case it will show PowerShellExecutionPolicy = 1 as a setting under, Machine \ CCM_ClientAgentConfig. The meaning of the different possible values are:

  • 0 = All signed
  • 1 = ByPass
  • 2 = Restricted

More information: http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_ComputerAgentDeviceSettings

Preventing initiation of available deployments on specific systems with ConfigMgr 2012

This week I want to devote a small post to a question that I read on windows-noob.com. The question came to the point whether, or not, it is possible to deploy applications via a task sequence, but only allow administrators to actually run it. This question triggered me to look a bit better into the different Client Settings and then specifically the setting of Install permissions. This setting gives us the possibility to prevent the initiation of available deployments via the Software Center and the Application Catalog on specific systems. So in this post I will show that setting by only allowing administrators to initiate available deployments.

Configuration

CompAgenInstPermNow lets start with the configuration, which is actually very easy, but like always it’s all about knowing that the possibility exists. The Install permissions –setting is another new (Computer) Client Setting under Computer Agent. This setting can be used to allow All users (default), Only administrators, Only administrators and primary users or No users to initiate available deployments on a specific system. To configure this, follow the next steps:

  • In the Configuration Manager Console navigate to Administration > Overview > Client Settings.
  • On the Home tab, in the Create group, select Create Custom Client Device Settings and the Create Custom Client Device Settings –popup will show.
  • On the General page, fill in with Name <aName> and select Computer Agent.
  • On the Computer Agent page, select next to Install permissions Only Administrators and click Ok.
  • Select the new policy <aName> and on the Home tab, in the Client Settings group, select Deploy.
  • Select <aDeviceCollection> and click Ok.

Result

After the deployment of the new Client Settings it is time to take a look at the impact on targeted system(s). Normally I’m a huge fan of looking at the client logs for the results, but in this case the log files don’t “speak” as much as the real error messages. When a normal users now logs on to the system and tries to initiate an available deployment, the following error messages will appear.

Software Center Application Portal
SoftCentInstErro PortInstErro

An overview of my posts about ConfigMgr 2012 SP1

Let’s start my first post, of this new year, with an overview of my latest post about ConfigMgr 2012 Service Pack (SP) 1. Normally I’m not really the kind of person that looks back, but in this case it’s with a reason, as most of my posts where with pre-release versions of SP1. I also tried to sort all my posts per subject, even though sometimes there is some overlap. The following posts are all tested, this week, with the RTM version of SP1 and I can confirm that they are still working:

System Center Orchestrator

Windows Azure

Windows Intune

OS Deployment

Application Deployment

Client Settings

Allowing access to Cloud Distribution Points for specific systems with ConfigMgr 2012

To end this year in the cloud, I would like to devote this weeks post to allowing systems access to cloud distribution points. A bit more then two months ago I already did a post about creating a cloud distribution point, but until now I’ve never posted anything about the client configuration. By default, a system is not allowed access to cloud distribution points.

Prerequisites

Before it’s even useful to allow a system access to a cloud distribution point, the system needs to be able to resolve the name of the cloud distribution point. There are two ways to achieve this:

  • The proper way – Create a public CNAME –record to map the service name, provided with the certificate for the cloud service, to the Windows Azure service FQDN.
  • The dirty way – Create a private HOST –record to directly map the the service name, provided with the certificate for the cloud service, to the IP address of the Windows Azure service FQDN (only for testing!).

Configuration

CusPolAllCloDisPoiNow lets start with the configuration, which is actually very easy. Like almost all the previous times, this year, it’s all about knowing that the possibility exists. The configuration is another new Client Setting in ConfigMgr 2012 SP1, named Allow access to cloud distribution point. This setting can be used to control access to cloud distribution points. To configure this, for specific systems, follow the next steps:

  • In the Configuration Manager Console navigate to Administration > Overview > Client Settings.
  • On the Home tab, in the Create group, select Create Custom Client Device Settings and the Create Custom Client Device Settings –popup will show.
  • On the General page, fill in with Name <aName> and select Cloud Services.
  • On the Cloud Services page, select next to Allow access to cloud distribution point Yes and click Ok.
  • Select the new policy <aName> and on the Home tab, in the Client Settings group, select Deploy.
  • Select <aDeviceCollection> and click Ok.

Result

PolSpyCloDisPoiAs always, now it’s time to take a look at the result. In this case I want to show two things, first the result, and second the impact, of the deployment of the new Client Settings. Normally, the best places to look at the results are the log files. In this case, there is no log file that shows whether cloud distribution points are allowed, or not. So the best place to look at that is the old-school Policy Spy. It will show AllowCloudDP = True as a custom setting under, in this case, Machine \ CustomSettings.

To look at the impact, the best places are still the log files. There are lot’s of log files that will show the usage of the cloud distribution points. A cool log file to look at the different blobs that are used during the download is the DataTransferService.log. The log file that I will show under here is the ContentTransferManager.log. In here it will also show the cloud distribution point, including the message that the Content location type is Azure.ConTraManAzuDisPoi

Preventing user-targeted applications and policies on specific systems with ConfigMgr 2012

This week I want to devote a small post to something very nice and, in some situations, very easy. Think about a situation where, in general, applications are user-targeted and only a few exceptions are system-targeted. Usually these targeted systems are then used specifically for that application. So these systems shouldn’t get all the applications (and settings) of every user that logs on, as it might screw-up the specific application. The nice thing is that ConfigMgr 2012, and especially SP1, has a solution for this! The solution is the new setting Enable user policy on clients.

Configuration

NoUserPoliciesNow lets start with the configuration, which is actually very easy. Like always it’s all about knowing that the possibility exists. This is another new Client Setting in ConfigMgr 2012, of which the values are renamed in SP1, named Enable user policy on clients. This setting can be used to enable or disable user policies. To configure this, follow the next steps:

  • In the Configuration Manager Console navigate to Administration > Overview > Client Settings.
  • On the Home tab, in the Create group, select Create Custom Client Device Settings and the Create Custom Client Device Settings –popup will show.
  • On the General page, fill in with Name <aName> and select Client Policy.
  • On the Client Policy page, select next to Enable user policy on client No and click Ok.
    • Note: In ConfigMgr 2012 RTM the possible values are True or False.
  • Select the new policy <aName> and on the Home tab, in the Client Settings group, select Deploy.
  • Select <aDeviceCollection> and click Ok.

Result

After the deployment of the new Client Settings it is time to take a look at the impact on targeted client(s). The best places to look at this are the log files. During a User Policy Retrieval & Evaluation Cycle the PolicyAgent.log will show that it will skip the request for user policy (see picture). PolicyAgent

Since ConfigMgr 2012 SP1 this will also disable the ability to install an application from the Application Catalog. In case somebody tries it anyway, the application installation will not start and the PolicySdk.log will show that the user policy is disabled (see picture).PolicySdk