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

Share

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

Share

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
Share

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

Share

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

Share

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

Share