Monthly Archives: July 2014

ConfigMgr: funny behavior with building Collection queries using Chassis Types…

I’m currently involved in a project that requires me to build a ConfigMgr 2012 R2 infrastructure from scratch (these are the best ones to be honest).

In this project, the customer requires to have different collections for desktops and laptops for various reasons. All client devices have Windows 8.1 Enterprise installed.

As many ConfigMgr admins, specialists and consultants know, a lot of different ways are possible to populate collections with the right objects. In this scenario, I decided to use the Chassis Types.

I used this website as a reference:

I encountered some funny behavior with the collection for desktops (with the very obvious name All Desktops).

The collection had the following query rule:

Very straightforward…

After a while I decided to verify if the objects returned are the ones I expected. This wasn’t the case unfortunately. The collection also contained computer objects which were virtual machines running Windows Server 2012. I concluded that a Hyper-V virtual machine also received that Chassis Type (I prefer not to use Chassis Types 1 and 2). The only reason I can come up with is using this chassis type for VDI purposes.

NOTE: I used the script available at on a virtual machine running on a ESXi platform to investigate what Chassis Type the script returns. On that platform I received Chassis Type 1 (= other).


Fortunately, a small modification of the Query Statement provided me Desktops only. Since I know that all desktops are equipped with Windows 8.1 I added a rule that checks if a Workstation OS is installed:

After the next update cycle the virtual machines running Windows Server 2012 were no longer a member of this collection.


Hope this helps…


ConfigMgr 2012 SP1/R2: making sure the machine REALLY restarts after finishing a Task Sequence…

Quite often I’m confronted with the issue which is described in KB2976660, the article is available at

The issue is quickly resolved by restarting the machine, it won’t come back after restarting so I didn’t really bother investigating. For many customers a quick restart is fine. However, in one of my current projects the customer doesn’t want to confront users with an error message on a freshly deployed machine, especially when it’s a brand new one…

The KB article provides two workarounds. I chose to go with workaround 1 which is using the SMSTSPostAction variable available from ConfigMgr 2012 SP1 and newer.

For this blogpost I used the following posts from Peter van der Woude and Jörgen Nilsson as a reference. I’d like to thank both gentlemen for writing them, here are the links:



Initially I went the same way as both gentlemen did by setting the Task Sequence Variable in the Task Sequence itself.


After some consideration and sitting on my hands for a while, I wasn’t really happy by adding this step to the Task Sequence itself. If you need to manage a high number of Task Sequences, then it would become quite a burden by adding this rule. In many projects, the same Task Sequence is used for different purposes. They can be the following:

  • Standard deployment (requires a restart)
  • Preparing master VDI machine (requires a shutdown after sysprep)
  • Build & Capture reference image (a shutdown after capturing is nice to have)
  • Deploying Servers which require a lot of customization, for example RDS or Citrix XenApp servers (at least a restart is recommended)

NOTE: a bit off-topic but I prefer to use MDT 2013 for anything that requires preparing something. However, company policies might state using ConfigMgr only.

So, different deployment usages require different commands for the SMSTSPostAction Variable. This requires a certain flexibility that needs to be configured elsewhere.

Fortunately, we have Collection Variables which provides me the flexibility I need. The screenshot below is an example:

Using this method allows you to manage the SMSTSPostAction in many different ways, it eliminates the need to manage to Variable at Task Sequences.


More information about Task Sequence Variables is available at




ConfigMgr 2012 PXE issue with a nasty surprise…

It happens quite often that during the build phase of a new ConfigMgr 2012 site infrastructure issues arise. The most common thing to do is verifying the configuration first. Analyzing log files is the next step to help you determine a possible cause. Unfortunately, most issues are caused outside ConfigMgr 2012 so more digging is required to solve the issue.

Recently, I was confronted with a situation that required me to do some more digging. The issue was that deploying client machines using PXE didn’t start. The client received an IP address, but didn’t receive a response from WDS Server, however I was able to proceed but the PXE boot abruptly ended with a boot error message (Windows Boot Manager failed to start)…

The environment has the following properties:

  • 1 stand-alone Primary Site;
  • 1 Site server which hosts the Site Database and the MP role;
  • 1 DP server available at a different VLAN (together with the clients);
  • All content is available;
  • DP is running normally;
  • All permissions and settings are correct.

I’ve decided to have a look at SMSPXE.log and I found the messages which tell me something is wrong (hostnames have been changed to something fictional):

socket ‘connect’ failed; 8007274c    SMSPXE    11-7-2014 10:51:19    3244 (0x0CAC)

sending with winhttp failed; 80072ee2    SMSPXE    11-7-2014 10:51:19    3244 (0x0CAC)

Failed to get information for MP: http://CM01.domain1.local. 80072ee2.    SMSPXE    11-7-2014 10:51:19    3244 (0x0CAC)

PXE::MP_InitializeTransport failed; 0x80004005    SMSPXE    11-7-2014 10:51:19    3244 (0x0CAC)

PXE::MP_LookupDevice failed; 0x80004005    SMSPXE    11-7-2014 10:51:19    3244 (0x0CAC)

socket ‘connect’ failed; 8007274c    SMSPXE    11-7-2014 10:51:29    4068 (0x0FE4)

sending with winhttp failed; 80072ee2    SMSPXE    11-7-2014 10:51:29    4068 (0x0FE4)

Failed to get information for MP: http://CM01.domain1.local. 80072ee2.    SMSPXE    11-7-2014 10:51:29    4068 (0x0FE4)

PXE::MP_InitializeTransport failed; 0x80004005    SMSPXE    11-7-2014 10:51:29    4068 (0x0FE4)

PXE::MP_ReportStatus failed; 0x80004005    SMSPXE    11-7-2014 10:51:29    4068 (0x0FE4)

PXE Provider failed to process message.

Unspecified error (Error: 80004005; Source: Windows)    SMSPXE    11-7-2014 10:51:29    4068 (0x0FE4)

00:11:22:33:44:55, 0B635897-6F74-4F21-BE48-FEBB3402AA60: Not serviced.    SMSPXE    11-7-2014 10:51:29    4068 (0x0FE4)


Hmmm, that’s odd, the DP cannot connect to the MP…

I was a little bit surprised that this connection couldn’t be established because it’s ‘standard’ HTTP traffic. I don’t use HTTPS so SSL related issues are not an item. Not only does it block PXE, all activities that requires a DP reporting to a MP are blocked because the DP can’t report back to the MP caused by the blocked traffic.

After verifying that HTTP or HTTPS are the only protocols used, I was even more stunned to see this happen. I learned later that this customer is using firewalls extensively. Their default policy states that all communication is blocked. Each port must be specified for communication to be allowed.

This was something new to me but it explained the behavior in the log. They make no exceptions so even standard HTTP port is blocked as well (something I haven’t seen before).

I gave the network team the following webpage and have the required ports opened:


Well, quite a surprise to be honest…



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