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
With ConfigMgr 2012 there are 2 packages used to install the ConfigMgr client. The first package which is called the Configuration Manager Client Package can be found under the Packages node of the Software Library and is used during OSD in the Setup Windows And ConfigMgr step to install the ConfigMgr client. The other package, which is hidden is called Configuration Manager Client Upgrade Package and this package is used when the Client Upgrade feature of ConfigMgr 2012 is enabled. The fact that this package exist can only be determined by looking at the Content Status under Distribution Status in the Monitoring pane for example.
The Client Upgrade functionality provided in ConfigMgr 2012 can be used to upgrade existing ConfigMgr clients already assigned to your Site to a new version. The functionality is not suitable if you have many clients, because it’s an on/off option without any further control in terms of scheduling or collection scoping.
If for some kind of reason the Configuration Manager Client Upgrade Package gets deleted, you cannot recreate it by creating a new one from a package definition file, like you could do with the Configuration Manager Client Package.
Normally when the Configuration Manager Client Upgrade package is deleted, this should be detected and should be regenerated automatically, but if it doesn’t you can create a empty file with the name client.acu and place that file in the inboxes\hman.box folder at the top-level site (either your CAS or PSS). After that check your hman.log to check whether the Client Upgrade package gets updated.
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.
System Center 2012 Configuration Manager Unleashed, the book on Microsoft System Center 2012 Configuration Manager is now generally available for purchase through Amazon and other shops.
I contributed two chapters to this book, and feel really honored to be part of the excellent line up of writers and contributors. I’ve written Chapter 9 on Client Management and Appendix B on extending Hardware Inventory.
Topics Covered in Chapter 9 include:
- ConfigMgr Client Requirements
- ConfigMgr Client Installation
- Client Assignment
- Client Health
- Client Settings
- Using the Resource Explorer
- Wake on LAN
Topics Covered in Appendix B: Extending Hardware Inventory include:
- How to extend Hardware Inventory
- Example of Extending Inventory
- Creating A Device Collection
Currently I already implemented several ConfigMgr 2012 and I must say I’m very pleased about the new Application Model and the new opportunities customers have for deploying applications.
I want to thank Kerrie Meyler who was the lead author for giving me this opportunity, and Steve Rachui for his technical review. And of course all the other Authors and Contributors for their feedback.
I’m currently working on a project where we implement a new ConfigMgr 2012 hierarchy in a forest where several ConfigMgr 2007 hierarchies already exist. The new ConfigMgr 2012 environment will be installed in a new domain within that existing Forest and we will not migrate any content from these ConfigMgr 2007 environments, but install every client using the OSD functionality of ConfigMgr 2012, but other deployment methods could be necessary for special scenario’s.
Even though this isn’t such a common scenario, I think the results of the test provide some insight on what you can expect in your own migration from ConfigMgr 2007 to ConfigMgr 2012, therefore I decided to share my findings. I hope it will be useful for someone reading this article.
Because one of the requirements for the implementation of ConfigMgr 2012 is that the impact on the existing environment should be as minimal as possible we did some test on what would happen if a ConfigMgr 2007 client would assign itself to a ConfigMgr 2012 environment and possible ways to prevent that.
- Install a ConfigMgr 2007 client when conflicting boundaries are configured on both ConfigMgr 2007 and ConfigMgr 2012
- Install a ConfigMgr 2007 client when there is only a boundary group with corresponding boundary defined in ConfigMgr 2012
- Install a ConfigMgr 2007 client and see what happens when it assigns to the ConfigMgr 2012 site and automatic client upgrade is turned on
- Install a ConfigMgr 2007 client and see what happens if only a boundary for Content Location in ConfigMgr 2012 is defined.
First there are some known and documented rules which we need to take into account:
A ConfigMgr 2012 client cannot attach itself to a ConfigMgr 2007 site. During Automatic Site Assignment, the ConfigMgr 2012 client will do a version check and when the site it tries to attach to isn’t at the correct level, it will fail to assign to that site.
In order to test the scenario’s, we build the following test environment
ConfigMgr 2007 Primary Site (pss1.nl.domain.local) in the NL child domain, with code N01
ConfigMgr 2012 Primary site (pss2.emea.domain.local) in the EMEA child domain, with site code E01
When Microsoft released the Consumer Preview of Windows 8, they also introduced the Windows Assessment and Deployment Kit, in short Windows ADK. With the release of the Windows 8 Release Preview (or release candidate) Microsoft also supplied an updated version of the ADK.
The Windows ADK contains updated tools which used to be part of both the Windows Automated Installation Kit (AIK) and the Windows OEM Preinstallation Kit (Windows OPK). Windows APK can be used for two scenarios: Windows Deployment and Windows assessment.
The Windows Deployment tools help IT Professionals with the deployment of a new version of Windows. Most of these tools are used as a basis for other Deployment tools, like the Microsoft Deployment Toolkit (MDT), the Operating System Deployment (OSD) functionality in System Center Configuration Manager (ConfigMgr) and since version 2012 also for System Center Virtual Machine Manager (SCVMM) to deploy both Operating Systems to bare metal servers and Operating Systems running on top of on of the three Hypervisors that SCVMM can manage (Microsoft Hyper-V, VMware vShpere and Citrix Xen). The products using the functionality of the Windows ADK will most probably be updated after the release of Windows 8 and Windows Server 2012 so that they can use the Windows ADK instead of the Windows AIK. ConfigMgr and SCVMM currently don’t support the use of the ADK and MDT provides support for the ADK for non production Windows deployments
Besides that the Deployment tools contain tools to test and mitigate application compatibility issues, migrate user data from an old OS to a new OS and Manage licenses across many machines from a central console.Read More