Monthly Archives: December 2013

Looking back at 2013…

At the last day of 2013, I decided to look back at 2013 and write down how I experienced it.

First, I determine if my predictions of 2013 came out or not. I expected the year 2013 to be really crazy after Microsoft’s 2012 Christmas Gift: System Center 2012 SP1. I have to admit, it didn’t become ridiculously crazy as I expected.

Despite all efforts to introduce customers with the cloud, many organizations are not completely ready for it politically.

The first half of the year was quite turbulent and challenging for me. I was involved in quite a challenging project for a customer of Microsoft Consulting Services. The technical part was OK, it was the politics that made it challenging. Because the PoC phase was a part-time involvement, I had quite some time to do some little stuff as well. After a lengthy PoC, I was finally able to finish my part of the project and I was very happy to hear that the customer and Microsoft Consulting Services were very satisfied with my performance. This is an experience that nobody will take away from me and I consider it an honor to do something with Microsoft Consulting Services. Microsoft, thank you for that…

After that, I did a few other projects that were a little bit smaller but I was able to be successful in those as well. I am happy that my customers gave me very good feedback about my performance and they explained to be very satisfied. Microsoft taught me to put great effort in customer satisfaction and I start to understand why…

One other major highlight was my first (and also the last 😉 ) attendance at the Microsoft Management Summit (MMS) in Las Vegas. I learned a lot of new things, I started to develop an interest in Virtual Machine Manager 2012 and I really look forward to work with this technology a bit more. I met a lot of great people of the community and apparently some people knew me as well (also from outside The Netherlands). I found that rather interesting, I didn’t know I already had quite a reputation in the field…

From a technology perspective, I didn’t really expanded much at all. My projects and my focus stayed a lot with Configuration Manager, only the stuff related to ConfigMgr were introduced to me, Windows Intune is a good example of this.

An overall development I start to see is that I am more and more involved in conceptual challenges organizations face. It’s nice that I can introduce technology such as ConfigMgr to help achieve their goals, however I have to ask my customers what they want to achieve with the product. The gap between understanding the technology and discovering customer’s needs is becoming bigger and bigger. I find great pleasure in helping customers understand what goals they want to achieve. The technological solution becomes less relevant and starts to lose my interest more often. The greatest satisfaction can be found by successfully translating business needs to a technical solution. My colleague Marthijn van Rheenen received quite a nice quote at MMS 2013: The correct order is People -> Process -> Technology. I couldn’t agree more with this one…

Finally, I can also look ahead a little bit and think about what to expect in 2014. For that I have my own quote: Automating Automation…

In order to be successful with that, I need to discover workflows in order to automate them…

For me it means a lot more PowerShell, I need to determine my focus for 2014 as well. I believe it’s going to be Operations Manager and maybe some VMM, Orchestrator en Service Manager…

And last but not least: The end of Windows XP and Office 2003 is near (it’s about time). I expect great challenges with that as well. I believe 2014 will be the year of the end user. The end user, not some IT manager, will tell me how he wants to work and we need to facilitate…

Have a great 2014…

Leave a comment

Posted by on 31/12/2013 in Opinion


ConfigMgr 2012: a PowerShell script to generate an answer file for unattended setup

In a few of my previous posts, I was attempting to automate a ConfigMgr 2012 Site Deployment. One of the biggest challenges was preparing an answer file for an unattended setup because the .ini file needed is very, very static. One of the biggest challenges was dynamically adding hostnames for site server and sql server.

So my challenge was to create an answer file that dynamically fills in the required data…

I’ve decided to explore the world of PowerShell to see if I was able to create a script that will generate the answer file for me and populate it with the buildup ConfigMgr requires.

First, you need to know how an answer file looks like, you can grab the %TEMP%\ConfigMgrAutoSave.ini file to determine how the answer file looks like. You can find more information about this at the following website:

I used the following post from Marius Sandbu who posted an overview of such an answer file, you can read about it here:

Now that I know which lines are in the answer file, I can continue.

Before proceeding, I needed to have a few assumptions before proceeding:

  • The file name will be C:\setup.ini
  • I already downloaded the ConfigMgr setup update files and I know the location, which is at C:\Download
  • The target folder will be “C:\Program Files\Microsoft Configuration Manager”
  • I’m going to to install a stand-alone Primary Site with a local SQL runtime with a default instance
  • I assume all prerequisites are there

The following two links helped me to create the script:


To me, the world of PowerShell is still pretty new, but I’m starting to familiarize myself more and more with it. I have to admit it’s great stuff to work with.

After some testing, I came up with this:

#determine answer file location



#retrieve fqdn for Site Server and SQL Server



#prepare lines for appending to answer file








$line08=”SiteName=Primary Site”

$line09=”SMSInstallDir=””C:\Program Files\Microsoft Configuration Manager”””


















#Create answer file

New-Item -Path $path -Name $file -ItemType file -Force

#Append each line to answer file

$line01 | Out-File $path$file -Append

$line02 | Out-File $path$file -Append

$line03 | Out-File $path$file -Append

$line04 | Out-File $path$file -Append

$line05 | Out-File $path$file -Append

$line06 | Out-File $path$file -Append

$line07 | Out-File $path$file -Append

$line08 | Out-File $path$file -Append

$line09 | Out-File $path$file -Append

$line10 | Out-File $path$file -Append

$line11 | Out-File $path$file -Append

$line12 | Out-File $path$file -Append

$line13 | Out-File $path$file -Append

$line14 | Out-File $path$file -Append

$line15 | Out-File $path$file -Append

$line16 | Out-File $path$file -Append

$line17 | Out-File $path$file -Append

$line18 | Out-File $path$file -Append

$line19 | Out-File $path$file -Append

$line20 | Out-File $path$file -Append

$line21 | Out-File $path$file -Append

$line22 | Out-File $path$file -Append

$line23 | Out-File $path$file -Append

$line24 | Out-File $path$file -Append

$line25 | Out-File $path$file -Append

$line26 | Out-File $path$file -Append

Some things are still very static, for example site code and some locations.

You can always modify them to your needs before you run the script. You may notice that I created a separate variable for the Site Server and SQL Server in case the SQL runtime is running on a different machine. I added some empty lines to maintain the same buildup.

Keep in mind though, this will only generate an answer file at a given location. After running this script you should be able to run an unattended install of ConfigMgr 2012.

Feel free to use this script. If the script can be optimized a little bit more, then please feel free to comment on this.


Windows 8.1 and Windows Server 2012 R2 image cleanup…

Recently, I received a tweet from Mikael Nyström aka The Deployment Bunny about a TechNet article which states that you can reduce your Windows 8.1 or Windows Server 2012 R2 image size by redefining your ‘base’ image through cleaning up your WinSxS folder. Thanks for that Mikael, this gives me something to look into for various scenarios.

The article Mikael mentions is the following:

When installing updates, either online or offline, all old files which are being replaced by the update are stored in the WinSxs folder to allow yourself to initiate a rollback by uninstalling the update(s) selected in case you need to do so. A major downside is that if a lot of updates are installed this folder can become particularly large. This applies to a Windows installation on a computer and to a somewhat lesser extent the size of your Windows image.

NOTE: this method can be used when managing updates by ConfigMgr, for example Offline Servicing…

So, I decided to put the article to a small test and see if I can get a result from this.

I’ve decided to deploy Windows Server 2012 R2 using MDT 2013. I enabled the Windows Update (Pre-Application Installation) task which allowed a ten-something number of updates. Nothing else is installed, just a plain server OS installation…

When installation is finished I check the amount of space used by the WinSxS Folder.



The number of updates is quite low (ten-ish) so no huge numbers of GB used.

Then, I ran the following command:

Dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase

Then I checked the amount of disk space used again.



Hmmm, that’s nice. Roughly 1.4 GB of space freed. Although the number is not so dramatic in this example, I can image this can increase when the number of updates is much bigger.

Keep in mind though, that you can no longer uninstall any updates installed. You need to make sure your process and workflow suit the requirements of company policy.

Of course, quite a number of options are available to use this method to reduce the space used by the WinSxS folder. Too bad this ridiculously easy way works with Windows 8.1 and Windows Server 2012 R2 only.

For earlier versions, different options are available. Here’s a KB article what needs to be done to clean up the WinSxS folder for Windows 7 SP1:


Considerations for deploying thin clients using ConfigMgr OSD…

A small portion of my customers adopted thin clients in their organization. Managing thin clients is something that requires a somewhat different approach. Fortunately, Windows Embedded Standard 7 and newer make it easier than earlier versions. It is strongly recommended to use at least ConfigMgr 2012 SP1 or newer because of the built-in functionality for managing write filters. The explanation is available at the following location:

In general, thin clients are equipped with very small disks. Your image file should be as small as possible but should fit to your needs.

Using ConfigMgr OSD capabilities allow you to deploy an Operating System to the device. Since space is very limited, you might get in trouble when running a Task Sequence.

Out of the box, when all content is created using the default settings, all content must will be downloaded to the device and run locally. It’s the only option you have when you create the deployment for your Task Sequence.

But there’s an alternative way that might reduce the risk that you run out of space during the deployment, I’ve seen it happen at one of my customers…

Thin clients are generally very static when used. More or less it a deployment looks like this:

  • Install Windows Embedded 7 Standard
  • Install a small number of additional tools, for example Citrix Receiver or VMware Horizon View
  • Maybe some updates
  • Run some cleanup scripts and enable the write filter when finished

When all content is downloaded, it will be stored in the %SYSTEMDRIVE%\_SMSTaskSequence\Packages folder and remains there until the deployment is finished. When finished, the _SMSTaskSequence folder and all its content will be deleted. This is fine if space is not an issue, but we might have issues when using thin clients with a small disk (sometimes 8 GB or even smaller)…

As I stated earlier, most thin clients are very static in use. After deployment not much management is applied then. I would even recommend deploying them again in a scheduled fashion when modifications have been done to the image such as injecting new updates or a new version of one of the small additional tools…

The static nature makes it very suitable to use Packages instead of Applications. This allows you to run everything from the Distribution Point instead of downloading them.

In order to make each package accessible from the DP, you need to modify the following setting at each package.

Enabling the selected check box will create a folder in the SMSPKGX$ (where X is the drive letter of your disk used) once distributed.

Once done, an additional setting is available in your deployment.

As you may notice, this is nothing new. This is standard configuration ConfigMgr 2012 offers you. However, you may need to do this if space is a limitation.

Of course you can use this method for other deployments than thin clients only. Using this method has some advantages and disadvantages.


  • Local disk space is not used during OSD
  • Content is not downloaded, this can save a significant amount of time which results shorter deployments


  • Each package configured with the settings above will be stored twice on each DP, this will significantly increase disk space usage
  • The SMB protocol is used instead of HTTP(S), this might impact network performance and might require some tuning on your infrastructure
  • You cannot use multicast for deployments since multicast deployments always use a stream. Therefore, content must always be downloaded when using multicast
  • You need to make sure the package can run successfully from a DP

Hope this helps…


Issue building your VDI master image using ConfigMgr 2012 with a vmxnet3 NIC

Recently, a customer had a rather annoying issue when attempting to build a master machine for his VDI environment. The customer deploys their VDI infrastructure on a VMware platform. Windows 7 is used as a client OS. Since my knowledge regarding VMware is rather limited, I was told it’s a VMware best practice (I prefer to use the word ‘recommended’ instead of ‘best’) to equip the VM with a vmxnet3 adapter.

ConfigMgr 2012 SP1 is used to deploy Operating Systems for everything, all site servers are running Windows Server 2008 R2 SP1. Next to VDI, fat clients and thin clients are deployed with ConfigMgr 2012 SP1.

To illustrate the annoying issue, here’s what happens when trying to deploy an image:

  • Deploy an image to a fat client à WORKS
  • Deploy an image to a thin client à WORKS
  • Deploy an image to a VDI using a vmxnet3 NIC à FAILS (mostly)
  • Deploy an image to a VDI using an Intel E1000 NIC à WORKS

For the VDI machine using a vmxnet3 NIC, the deployment fails loading the boot image into the RAM drive. I receiver error 0xc0000001 which states: A required device isn’t connected or can’t be accessed.

It became more ‘fun’ to see the failure happened at different moments, sometimes in the beginning and sometimes at the end. And in a rare case, it loaded successfully and the Task Sequence can continue…

Knowing that it does come through sometimes, I can confirm that drivers are not an issue either…

I’ve decided to enable trace logging for the WDSTFTP part, the following KB article explains how to do this:

However, I couldn’t find any relevant information in the trace so no luck there…

Knowing that I have scenarios which are successful all the time, the only thing I could come up with is network related. I focused my troubleshooting on the networking part. One important question here is: In what way is the vmxnet3 driver behaving differently to other NICs?

After an extensive search I found the following article that got me in the right direction:

I noticed the registry key RamDiskTFTPBlockSize in hive HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP didn’t exist. We all know that ConfigMgr uses its own default values if registry keys don’t exist so I decided to add it myself (a DWORD value). The value became 1456. 1456 is the same block size that WDS uses for TFTP running at Windows Server 2008 R2. According to article , that particular registry key doesn’t exist either so the Operating System default values are used…

After restarting the WDS and SMS_EXECUTIVE services, we tried again.

We noticed the number of failures dropped significantly. Although the success rate is not 100%, it became much better than before the modification.

A funny side effect was that the boot image loading phase went significantly faster as well, even for all other scenarios as well. I probably need some additional testing to determine if it’s recommend to tune this value. I’ve received more complaints that the boot image loading part goes very slowly, even when the Distribution point itself is not under full load…

Again, more and more testing is required but the fun factor is maintained when working with Configuration Manager (I like to work with other things such as OpsMgr too)…


ConfigMgr 2012 R2: Playing around with Powershell for the 1st time…

Recently, Microsoft was very nice to provide a webpage with all available Powershell cmdlets for the System Center Suite. Fellow Dutchman and MVP James van den Berg made me aware (Thanks for that James J).

To save time roaming extensively on TechNet, you can download all the information at the following website:–ITPRO40886&WT.mc_id=aff-n-we-loc–ITPRO40886

To play around with Powershell, I’ve decided to use the scenario of my previous Case Study post regarding collections and deployment. For this blogpost, the application used is already imported and distributed to a DP (this is something for another post to create/manage possible workflows).

In order to achieve the goal, I need to determine the workflow first. After sitting on my hands for a little while I determine the workflow is the following:

  • Create a User collection to install the application
  • Create a query membership rule for that collection
  • Create a User collection to uninstall the application
  • Add an ‘Include Collection’ rule using the collection ‘All Users’
  • Add an ‘Exclude Collection’ rule using the ‘install’ collection
  • Create a required deployment to install the application and assign it to the ‘install’ collection
  • Create a required deployment to uninstall the application and assign it to the ‘uninstall’ collection

To run the Powershell cmdlets, the ConfigMgr Console must be installed according to the following blog post:

Let’s get started…

First we need to import the ConfigMgr module into the Powershell session:

As you see here, I’ve imported the module and I changed the PSDrive using cd P01: (P01 is the site code I use)

Step 1: Create a User collection to install the application

The cmdlet New-CMUserCollection -LimitingCollectionName “All Users” -Name “Adobe Reader XI” -RefreshType ConstantUpdate is the one I use here. I didn’t need to use all the available parameters to create the collection, it may look a bit crude but we keep it simple for now…

Step 2: Create a query membership rule for that collection

Step 2 was a bit tricky because I was initially struggling a lot with all the quotes at the end. Eventually I got it working using the following cmdlet:

Add-CMUserCollectionQueryMembershipRule -CollectionName “Adobe Reader XI” -RuleName “All Adobe Reader XI Users” -QueryExpression “select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain from SMS_R_User where SMS_R_User.UserGroupName = “”DOMAIN1\\Adobe_Reader”””

Step 3 is the same as Step 1, nothing special here:

Step 4: Add an ‘Include Collection’ rule using the collection ‘All Users’

Add-CMUserCollectionIncludeMembershipRule -CollectionName “Uninstall Adobe Reader XI” -IncludeCollectionName “All Users” did it for me.

Step 5: Add an ‘Exclude Collection’ rule using the ‘install’ collection

Add-CMUserCollectionExcludeMembershipRule -CollectionName “Uninstall Adobe Reader XI” -ExcludeCollectionName “Adobe Reader XI”

Well, it’s almost the same as step 4. It’s good to see the cmdlets are very straightforward.

Step 6: Create a required deployment to install the application and assign it to the ‘install’ collection

Start-CMApplicationDeployment -CollectionName “Adobe Reader XI” -Name “Adobe Reader XI” -DeployAction Install -DeployPurpose Required -UserNotification DisplaySoftwareCenterOnly is the cmdlet used. You may notice I left out a lot of optional parameters (like start time)

Step 7: Create a required deployment to uninstall the application and assign it to the ‘uninstall’ collection

Start-CMApplicationDeployment -CollectionName “All Users” -Name “Adobe Reader XI” -DeployAction Uninstall -UserNotification HideAll is similar as the cmdlet in step 6. I left the –DeployPurpose parameter out because I know an uninstall deployment is always required. I changed the –UserNotification parameter to HideAll because I don’t want to confront the user with the uninstall

Of course, it’s a good idea to verify if everything is in place. After a quick view in the Console I determined that all is there, sweet J

I have to admit the example used is very static. I need to familiarize myself more how to dynamically populate items such as security group names. Once I achieve this, I can take it to the next step to add more automation to this workflow (maybe with Orchestrator). I need to find ways to achieve this but I feel confident in doing so. Suggestions are very welcome, so please post your feedback on this.

I also have to admit that I really love this approach, it really allows me to translate a workflow into a technical solution. I am certain I’m going to investigate more time using Powershell with ConfigMgr.


ConfigMgr 2012 Case Study: user collection memberships and application deployment…

Recently, at one of my customer’s ConfigMgr site, I was asked to look into an issue regarding application deployment.

They had the following issue:

To keep the number of applications deployed only to users who are assigned the application, two deployments were made:

  1. A required install deployment on a collection which has a User Group Resource name as a target (straightforward direct membership, nothing special)
  2. A required uninstall deployment to the collection All Users

The philosophy behind the deployments is the following:

  • Any user who had an application assigned must have the application removed when the user loses membership of the assigned group

While the philosophy and its approach make sense, the customer was confronted with uninstall actions executed at users even though the user was a member of the security group. I learned that hundreds of applications were deployed in this fashion and the behavior wasn’t happening all the time. I can imagine that a ConfigMgr client has to process too many rules that will cause some uninstall rules to slip through and take precedence.

I’ve decided to build a similar setup in my lab environment which has the following properties:

  • 1 DC
  • 1 ConfigMgr 2012 R2 Site server with a local SQL instance
  • 1 Windows 8.1 client, domain joined
  • I used the .msi file of Adobe Reader XI available at the Adobe website
  • I created 3 users: Richie, Fonzie and Potsie (I guess the somewhat older audience knows these characters pretty well)
  • I created a security group for Adobe Reader and made Richie a member

I created a user collection for Adobe Reader with a straightforward query rule (nothing fancy):

I created a standard .msi application (all defaults) for Adobe Reader.

For the deployment type created by the application, I defined two deployments that meet the customer’s configuration:

When I logged on as Richie on my client machine, I noticed the application was installed as expected. However, I was unable to reproduce the customer’s behavior. I have too few applications…

After a while I decided to have a look at the deployment status:

This is expected, only one user has the application installed.

Now the uninstall deployment:

Huh, 1 error?

Well, let’s have a look at the Status.

Hmm, this message is actually really nice. It is good to see that ConfigMgr reports that the deployments user DOMAIN1\Richie are conflicting with each other…

It is interesting to see the install deployment wins over the uninstall deployment for DOMAIN1\Richie.

To prevent such behavior we need to define queries that will create such conflicts. The goal I want to achieve is the following:

  • Create a collection that will query users based on group membership for the installation of the application
  • Create a collection for everyone except the users that are member of the ‘install’ collection

With my current collection queries, I can’t achieve this goal. I need users instead of user groups.

NOTE: Having users in a collection also allows me to see which users are a member of that group, that saves me from opening my Active Directory Users & Computers console

I need to create a new query that will target users instead of user groups to achieve my goal.

Pretty straightforward right?

Creating the uninstall collection is pretty straightforward as well:

There you go…

NOTE: Initially I tried the same query and added a ‘not’ operand but that doesn’t work. If a user is member of more than one group, then they will meet the query. Eventually I got all users in the collection. I was forced to use the rules displayed above to meet my goal.

Using this mechanism allows you to prevent conflicts since DOMAIN1\Richie will no longer be a member of the uninstall collection…

Feel free to try this out yourself, make sure that you got your collections right by making sure the objects that meet the query are the ones you expect before deploying anything.

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