I’ve had several people contact me asking if I had new templates for ConfigMgr 2012 for my popular USMT to UNC posts I’ve done in the past. I’ve cleaned up the process quite a bit over the years and here is what I’ve been using with clients lately. In this blog post I will explain how I configure my Task Sequences to capture to a network location and I will provide links for the templates you can download.
There are many times where capturing/restoring USMT to a network share fits into the workflow better than using the built in State Migration Point (SMP). The SMP is encrypted, which is a good thing, but can cause issues for swapping data between devices. You are also required to create computer associations before you do a capture, which some times people forget to do. So an easy solution is to simply capture USMT to a network share instead. This process can be configured to dynamically move to different servers for different locations without much difficulty but I won’t be discussing that in this post.
The first thing I do in the Task Sequence is create a Set Variables group where we can set a few properties to be used in the Task Sequence.
The first variable we set is a ServerA property. This is the name if the server you want to capture the data up to. This step is conditioned to only run if the ServerA value is not already defined. If you are using MDT integration, you can define the ServerA value dynamically using the Database. This is commonly used to account for different geographical locations.
The second step we use to define the MigData variable. We take the ServerA value and create the path with the built-in OSDComputerName variable available to the Task Sequence.
The third step in the Set Variables section we use to set the OSDStateStorePath variable which is what USMT will actually use. We use this value so we can use the built-in USMT steps in the Task Sequence.
Capture User State
The USMT Capture section is made up of 3 steps.
The first step creates the directory in the targeted OSDStateStorePath location. This ensures the folder for the computer name exists. If the folder doesn’t exist, we can’t dump the user state data to it. This step is conditioned to continue on error, if the folder already exists, then the step will error out.
The second step is optional, but is an example of how you would pass additional parameters to the built-in Capture User State step. In the templates, I’m doing a /uel:90, which excludes all accounts older than 90 days. We do this using the variable OSDMigrateAdditionalCaptureOptions.
The third and final step in the USMT capture group is the default Capture User State step. You can customize which XML’s you want to use and the step will automatically process the values we have set previously.
Restore User State
One of the big advantages of using a process like this to capture user state is that we are dumping the data to a network share. If you are using the templates I’ve provided or created a similar process using the steps in this blog post, then User State will automatically be restored whenever a matching folder name is found. No association is required, if we can find data in the OSDStateStorePath then we will restore it.
The USMT Restore process also consists of 3 steps.
The first step simply sets our OSDStateStorePath variable again.
The second step configured additional restore options. In the templates/example, I’ve used a /ue:%computername%\* which excludes all local accounts from being restored.
The third and final step again simply uses the built in Restore User Step. This will use the OSDStateStorePath variable we’ve set and the OSDMigrateAdditionalRestoreOptions values together with however you have chosen to configure the Restore User State Step.
The first template I’ve created is for a stock ConfigMgr Task Sequence without MDT Integration. This has all the steps I’ve discussed configured for you, with explanations of what each step is doing.
These templates were created on a ConfigMgr 2012 SP1 lab environment, I don’t believe you can import these into a RTM site without issues.
If you are not going to use the templates I’ve provided, then you will need to configure your Task Sequence using the logic I discussed in this blog post and you will need to disable/remove all existing Request/Release/Move State Store steps in the Task Sequence. Those are used to work with the SMP and we won’t be needing those.
The second template is configured for a MDT integrated Task Sequence.
Download the Templates here:
Microsoft Deployment Toolkit – 2012 Update 1 6.1.2373, Do I Need To Recreate The Toolkit Package in ConfigMgr?
MDT 2012 Update 1 was updated to a new version to fix an issue when used in combination with ConfigMgr 2012 CU1.
MDT 2012 Update 1 version 6.1.2373.0 was made available for download on September 19, 2012 and adds support for System Center Configuration Manager 2012 CU1 and System Center Configuration Manager 2012 SP1 Beta. It can be identified as MDT build 6.1.2373.0 in the MDT Workbench console or in the installer program properties. This is the latest version and we recommend all users run the latest version when they can to ensure the smoothest experience during future upgrades.
A common question is whether you need to recreate your packages for use with MDT/ConfigMgr integration. This came up on the MDT/OSD list today and Michael Niehaus responded:
No, you don’t need to. The only changes between Update 1 build 2369 and build 2373 are:
· A fix to the “Create MDT Task Sequence” wizard to make it work with ConfigMgr 2012 CU1.
· Documentation updates indicating support for ConfigMgr 2012 Beta 1 (lab only).
So all the scripts, tools, etc. are otherwise identical. (Well, technically the scripts are different because they all contain the build number, but that’s the only change in them.)
MDT 2012 Update 1 version 6.1.2373.0 (Version 6.1.1 on this page) was made available for download on September 19, 2012 and adds support for System Center Configuration Manager 2012 CU1 and System Center Configuration Manager 2012 SP1 Beta. It can be identified as MDT build 6.1.2373.0 in the MDT Workbench console or in the installer program properties. This is the latest version and we recommend all users run the latest version when they can to ensure the smoothest experience during future upgrades.
Really great post by Peter Van Der Woude, this had been on a list of mine to get this working and blog it, but guess I don’t need to anymore!
The power of Orchestrator 2012 to automate actions is getting bigger and bigger, as the community for it grows and by that the number of Integration Packs (IPs). Of course there are also IPs for ConfigMgr, from both Microsoft itself and the community (via CodePlex). Besides that there wasn’t a real integration between ConfigMgr and Orchestrator, yet, but with MDT 2012 Update 1 a really nice new cool feature was introduced. This feature is the Execute Runbook –step during a Task Sequence. It gives anyone, with or without real programming skills, more robust options during a Task Sequence, as long as an IP exist for the action anyone wants to perform. Just remember, lots of these IPs are created by the community. So deliver useful feedback on them, or even better add your own actions, or IPs.
Michael Niehaus has an updated post regarding modifying the LTI wizard to show a different list of applications based on which Task Sequence is selected.
A few years back, I posted a blog at http://blogs.technet.com/b/mniehaus/archive/2010/06/11/selection-profiles-with-the-lite-touch-deployment-wizard.aspx describing how to modify the Lite Touch wizard so that the deployment wizard shows a different list of applications based on the task sequence that was selected. This worked fine with MDT 2010 Update 1, but there have been a few changes to the scripts and the structure since then. So how do you need to do it now? Well, it hasn’t changed much, but just enough to break things.
I mentioned in the blog post at http://blogs.technet.com/b/mniehaus/archive/2012/07/21/mdt-2012-update-1-always-applying-images-with-imagex.aspx that MDT 2012 Update 1 no longer uses SETUP.EXE to install Windows 7 and above. One side effect of this is that $OEM$ folders are no longer going to be copied, since that was something that SETUP.EXE did that the MDT LTIApply.wsf script doesn’t handle.
I’ve never been a big fan of using the $OEM$ folder structure, as it’s just as easy to add explicit XCOPY steps into the task sequence. But for those of you out there that are using them, you can leverage the attached script (see the attachment link below) in your task sequence to do that.
Johan Arwidmark walks you through deploying Windows 8 using MDT 2012 Update 1.
Windows 8 RTM is now available and so is the deployment solution to deploy it. As of this writing (September 19, 2012) MDT 2012 Update 1 is the only deployment solution by Microsoft that supports deploying the final version of Windows 8. The other deployment solution Microsoft has, System Center 2012 Configuration Manager, will not support Windows 8 until the SP1 update is released later this year.
Note: Yes, I know: Technically you can use plain vanilla Windows Deployment Services (WDS) and ADK to deploy Windows 8, but that’s not a deployment solution. WDS and ADK are only plumbing tools for deployment, not a deployment solution, and MDT 2012 Update 1 will use them in the background anyway. Please do not waste your time trying to build a deployment solution on WDS and ADK, Microsoft has already done it for you: It’s named MDT 2012 Update 1!
Mikael Nystrom has another good post on "back to basics". This time on CustomSettings.ini which is a file that commonly gets people confused because of it’s many uses and ways to do things.
One of the most important files in MDT (and in SCCM with MDT) is customsettings.ini, it is the rule file to rule your deployment. Yesterday Johan and I did a session at MMS and besides getting great scores and that is always fun. During that session I did a couple of demos around customsettings.ini and I would like to explain this a bit more. Because if you do understand the rules you can become much more dynamic and that will hopefully lead to less hassle and more work done in less time.