Monthly Archives: October 2012

SCCM 2012: Configuration Baselines for Software Updates

Recently more and more questions arise about creating baselines to manage compliancy by SCCM 2012. Many organizations have security officers who define a required set of Software Updates that a specific set of computers must have, for example client machines such desktops and laptops. These same security officers often require reports to check if the set of Software Updates are deployed to the set and if these computers are automatically remediated if they’re not compliant.

SCCM 2012 allows administrators to translate these required set of Software Updates into one or more Configuration Baselines which can be deployed to collections to check compliancy.

The screenshot below is an example of a configuration baseline with one software update (KB931125 is used in this example).

Its deployment properties may look like this.

With Software Updates, make sure that your deployment mechanism used downloads these required updates into a Software Update Package.

Only then can they be deployed to the machines that requires them.

Make sure to test this feature to make sure that you get the expected results before deploying them in a production environment.


SCCM 2012: Using Configuration Items, a real world example…

Recently I’m more often confronted by customers who ask me a vital question using SCCM 2012 for content distribution. The question is: how about managing settings for an application or generic Windows configuration settings?

The easy answer is: it depends…

However, it doesn’t really help the customer that much.

Not only are customers confronted with diversity in their organizations, departments often require different settings for the same application or Windows environment.

Application packaging specialists are also confronted in the process as well since they need to do the application scripting. Environments who require different settings for the same application confronts them with the question how to provide the different settings to the end user. It may be clear that creating the same package multiple times to have the different settings inside the package is most likely NOT the right strategy. I strongly believe in the approach in keeping the custom part of any deployment of technology as little as possible, the more standard the technology the better its reusability. This gives the customer more freedom in upgrading the technologies to their needs.

Unfortunately, it happens quite often that organizations depend so much on this heavily customized technology that it will effectively prevent them from upgrading/migrating to something newer. I guess most of us saw organizations still use the aging Windows XP SP3 with Internet Explorer 6 because the organization’s core application can only run on Internet Explorer 6 and the company supporting this application is out of business or terminated the support for the application.

Other technologies exist such as GPO/GPP. However, having a lot of GPO/GPP objects can significantly slow down user experience due to slow logons. Managing these objects might require a lot of administrative effort on the Active Directory administrator. Scripts, registry files are possible but these cannot guarantee that they are properly deployed.

So, we can conclude that a suitable mechanism must be available that allows administrators to easily deploy, manage and modify settings for the applications they need to distribute in the IT environment.

SCCM 2012 provides a method to deploy these kind of settings by means of Configuration Items. In this blog, a few registry settings will be set and modified to demonstrate its usage.

The application in this example is Microsoft App-V 4.6 SP1 client. The application is deployed using a default silent setup using the following command: setup.exe /s /v/qn

The goal is to modify the client to run in standalone mode which can be achieved by modifying at least the following registry keys (some settings may differ to satisfy your needs):









A single Configuration Item is created which consists of three settings, one for each registry key.

For each setting, a compliance rule is created to check what the setting needs to be.

Remediation of noncompliant rules needs to be enabled to have the settings modified to meet the compliance rules set.


Once the Configuration Item has been created, it needs to be added to a Configuration Baseline. This baseline needs to be deployed to the collection that needs the settings.

It may be obvious that multiple Configuration Items for the same application can be deployed if organizations need different settings.

Modifying the Compliance Rules also allow administrators to change settings if requirements change or an unintentional mistake was made during packaging.


Once the settings have been deployed, Compliancy Reports become available to check if the targets are compliant.


As usual, make sure to test the Configuration Items to determine if the results are applied as expected before deploying them to any production environment.

More information is available at


For your convenience: a Powershell cmdlet for adding the Roles & Features for SCCM 2012 in Windows Server 2012

In a previous post a Powershell cmdlet was displayed to install the required Roles & Features for an SCCM 2012 Primary Site.

Microsoft has released Windows Server 2012. In order to get the installation of SCCM 2012 running on a Windows Server 2012 platform (Core installations not supported) the following Powershell cmdlet can be used to install the required Roles & Features:

PowerShell -Command “& {Import-Module ServerManager;Add-WindowsFeature NET-Framework-Features,BITS,RDC,Web-Common-Http,Web-Http-Redirect,Web-Asp-Net,Web-ASP,Web-Health,Web-Log-Libraries,Web-Http-Tracing,Web-Basic-Auth,Web-Windows-Auth,Web-Url-Auth,Web-IP-Security,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Compat,Web-Mgmt-Console,Web-Scripting-Tools,Web-Mgmt-Service,UpdateServices-Services,UpdateServices-WidDB -IncludeAllSubFeature}”

The cmdlet is slightly different than the used for Windows Server 2008 R2. In Windows Server 2012 it is possible to install the WSUS Service and a database used for WSUS. The cmdlet displays that the Windows Internal Database is used. For SCCM Site Servers who don’t require WSUS, you can remove the last 2 Windows Features: UpdateServices-Services,UpdateServices-WidDB (you might consider removing Web-Dyn-Compression as well).

According to the following Technet article installing SCCM 2012 with no Service Pack is not supported on Windows Server 2012:

Until release of SP1, building an SCCM 2012 Site server on a Windows Server 2012 Operating System can only be used in lab environments.


SCCM 2012 SP1 Beta: Building images from Operating System Installer Package not available

In a lab environment an SCCM 2012 SP1 Beta is running. The environment is running fine, MDT 2012 Update 1 has been integrated to use the extra functionality MDT 2012 offers. The build & capture process of Windows images has always been a straightforward action. Since most images don’t require anything fancy (maybe some applications), the standard Task Sequence is mostly used to build & capture a Windows image.

When creating a Task Sequence in SCCM 2012 SP1 Beta a somewhat funny feature occurs as the screenshot below displays:

Only an existing image package can be selected so a big challenge occurs when starting from scratch…

Fortunately, integrating MDT 2012 Update 1 allows you to capture a reference image. Running the wizard to create an MDT Task Sequence creates a complete set of actions. One part of the actions is to capture a reference image. The steps are part of a group which has a Task Sequence condition.

Nothing fancy here either. The only challenge here is that the Task Sequence Variable is not set anywhere so this group will always be skipped.

The easiest way to set the Task Sequence Variable is to create a Task before the group itself.

The task looks like this:

Nothing fancy here.

If you use the Task Sequence for deployment, then you need to delete this task again. Keep in mind though that the machine is not a domain member before capturing. If the machine is member of the domain, then create another Task to join a machine to a workgroup. This Task must be the first Task of the group for capturing.

The solution provided is one of many to get the Task Sequence Variable set. Because SCCM 2012 is used, the solution displayed is the easiest one.

At the moment it’s not clear why the feature to select an Operating System installer package has been removed.

The screenshots were generated from a lab environment. As long as SP1 is in Beta, you should not use this in a production environment until its official release.


SCCM 2012: How to troubleshoot Wake on Lan functionality

Wake on Lan (WoL) functionality is one the poorest documented features SCCM 2012 offers. Enabling WoL requires one checkbox (to enable it) and two radio buttons (to select the packet type and the protocol). Getting it to work though is rather challenging. Many people have written blogs to set up requirements (such as BIOS and OS settings and of course the network infrastructure) so these can be found at a lot of places on the internet. The biggest challenge is to determine which UDP port is used. The default value is 9 but very often this port is not used at all.

To facilitate and test WoL functionality, it is recommended to install the SCCM Right Click Tools which includes wol.exe. wol.exe can be used to wake up machines by sending wake up packets to destination computers. These packets should arrive when the destination computer is on.

If UDP port 9 is not used, then it becomes a guess to determine which UDP port is used instead. One great way of determining the right UDP port is using a packet sniffer tool such Microsoft Network Monitor or Wireshark. Filtering options can be used to discard all irrelevant traffic for display purposes.

At my current project, the administrators did a great job by setting up Wireshark which allowed them to detect that wol.exe was using UDP port 12287 instead of 9.

After challenging the WoL port in SCCM 2012 from 9 to 12287, they were able to successfully wake up machines to let them execute the required task. In this case a new operating system is deployed started from PXE. Wol.exe is no longer needed to wake up the machines at any time.


SCCM 2012: Issue installing Applications on non-domain clients

In my current project I’m participating in a team with two organization administrators implementing SCCM 2012.

We’re building a reference image using OSD, the Task Sequence is configured to apply the computer to a workgroup, this makes sure that no GPO/GPP settings are applied to keep the machine as clean as possible.

During the build process of the windows image the ‘Install Application’ task failed with error 0x80074005. The error code means ‘Access denied’. The fun part is though, installing a package works as a charm. The easiest workaround is to use packages only. However, the Task Sequence might get unnecessary long and you’re not using a great feature SCCM 2012 offers.

Reviewing the Task Sequence provides the following information:

Step 2 out of 2 complete

Sending error status message

Setting URL = http://<hostname&gt;, Ports =

80,443, CRL = false

Setting Server Certificates.

Setting Authenticator.

Set authenticator in transport

Setting Media Certificate.

Sending StatusMessage

Setting message signatures.

Setting the authenticator.

CLibSMSMessageWinHttpTransport::Send: URL: <hostname>:80 CCM_POST /ccm_system/request

Request was succesful.

hrInstallation, HRESULT=80004005(e:\nts_sccm_release



Policy Evaluation failed, hr=0x80004005

Install application action failed: ‘7-Zip 9.20 (x64 edition)’.

Error Code 0x80004005

Install application action cannot continue.

ContinueOnErrorFlag is set to false.


sContinueOnError), HRESULT=80004005 (e:



Install Static Applications failed, hr=0x80004005

It is obvious that the client machine wants to connect to something which he’s not entitled to do so even though the application is distributed to all available DP’s. Since the machine is a workgroup member (at that time) the computer doesn’t meet boundary criteria (AD site boundaries are most commonly used). It is also unable to query AD to find an MP.

2 possible solutions are available:

  • Join the machine to the domain during the build process and join to workgroup during the capture process
  • Provide the Site code and Management point during client installation (/MP:<fqdn hostname> SMSSITECODE=xxx)

For the first option: make sure the machine is added to an OU that has no GPO/GPP settings (one more reason not to use Default Domain Policy) to keep the machine clean from any settings.

The second option is more elegant but provides a challenge when more Management Points exist. This is pretty common if the SCCM Site is highly available. If the provided MP is not available for whatever reason, then the Task Sequence will fail. In the domain situation, you don’t have this problem because any MP is available if the SCCM site is available. The second option makes sense if only one MP represents the SCCM Site.

Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This site is all about System Center and PowerShell

IT And Management by Abheek

Microsoft certified Trainer -Abheek

Heading To The Clouds

by Marthijn van Rheenen