In part 1, I showed you how to enable the Branding to Reg steps, and where you could find the information in the registry. Part 2 showed you how you can extend what information is branded into the registry, and in this part I will show you how you can use Compliance Settings and Compliance Baselines to read this information and create collections in ConfigMgr based on that information.
Using the information branded in the Registry we can use the Configuration Baseline to eventually create collections based on this registry information.
In part 1 of this series, I showed you how to enable the Branding to Reg steps, so that during a Task Sequence some information about the Task Sequence is stored in the Registry under HKLM\Software\Microsoft\MPSD\OSD. In this part, we are going to extend the information which is written to include some information we want to include.
The Branding to Reg and Branding to Reg x64 steps, call two scripts which can be found in the Scripts folder under your MDT Files Package source location. When you open the scripts, you will notice that you can modify which values are written, or which variables you explicitly don’t want written to the Registry during the Branding steps, like OSDJoinPassword for example.
I’m a big fan of integrating the Microsoft Deployment Toolkit into ConfigMgr, but notice that I’m having a hard time to convince my customers (and some fellow Deployment enthusiasts) of the added value. Personally I think that has something to do with the overwhelming added functionality you get. Take for example the MDT created Task Sequence, which looks very complex in the beginning, but once you get the know the MDT generated Task Sequence you will begin to see its added value. I firmly believe that you can have one task sequence per OS type, and from that Task Sequence you can install several configurations.
Ok, so what’s the goal in these series of blogposts.
This post will detail how you can use standard functionality provided in a MDT task sequence, to write some registry values based on variable settings which we can later use to determine under what circumstances a machine was deployed. We are going to modify our MDT Task Sequence in order to enable branding when not using User Driven Installation (UDI), define some custom variables to use and later use Configuration Items, and Configuration Baselines to create Collections based on this information which branded in the registry of clients.
So let’s start.
When you decide to install Applications during your OS Deployment using Configuration Manager, there are some caveats which must be taken into account
Applications installed during a task sequence must be installed completely silent, that means that no user interaction is allowed.
Some points of attention are:
- Task Sequence runs in the context of the System account
- There is no Explorer.exe running during a Task Sequence
- Installation must be fully unattended, no user interaction is allowed
- The installer may never initiate a reboot, it should return return code 3010 for example when a reboot is needed. ConfigMgr will then take care of the reboot when needed.
During many of my project building Task Sequences for customers I’ve build a way to test successful installation of an Application during a Task Sequence.Read More
Update: Some readers of my blog still experience this issue, and up until now the exact cause is not clear. The workaround is still valid though ! Please read the comments below for the latest updates. If you also experience this issue, please up the counter on the Microsoft Connect site where this issue is reported: https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/772079/task-sequence-doesnt-install-or-fails-when-application-version-is-updated
Recently I experienced some strange issues with installing applications during a task sequence, and at this time of writing there is no official fix for this issue in ConfigMgr 2012 only a workaround. It caused me a lot of question marks before i could actually figure out what the problem was.
So, to start let first answer the question about what the symptoms are:
When you install applications you will notice that the task sequence when executed will not install the latest application revision of that application. Instead the application revision of the Application at the time it was added to the task sequence is used, causing either the Task Sequence to fail or an earlier version of the Application ends up being installed.
When looking to the References of your task sequence you will notice that it displays a reference to the latest application revision you have.
This corresponds to the actual revision, which you can view by right clicking on the application and by choosing Revision History. As you can see here Revision 2 corresponds to the /2 behind the Application ID.