This is basically the result of the the system coming up in an OS it didn’t expect. For example WinPE instead of XP/Win7. Commonly, you might be testing and have restarted the box in the middle of the Task Sequence running. Or perhaps you did a deployment and didn’t click “Finish” on the summary screen.

The appropriate action is to either click “Finish” or reboot into the appropriate OS. You can also hit F8 at this point and format the drive and then restart or manually kick off the Lite Touch process again.

If you want an automated way to deal with this, which is most likely unsupported, read on!

Normally when you click “Finish” the Task Sequence will exit and clean up after itself. There is a script called LTICleanup that runs. What we came up with at a recent client of mine, was developed for a lab environment. To avoid this pesky screen, we added the LTICleanup script to to the WinPE load process to automatically clean up the drive for us every time we load WinPE. The obvious advantage is that we will never seen the above error. However you will also lose all your log files if you just had a failed deployment. To counter that, I always recommend you take advantage of SLShare (logs copied at end of deployment) and SLShareDynamicLogging (logs copied during deployemnt) so that you have copies of what happened and can still troubleshoot the process. See the MDT documentation for more information on these properties.

First what you need to do is pull the unattend.xml from the boot image. You will need one for each architecture x86 and x64. You can use imagex to mount the litetouchpe_x64 or litetouchpe_x86 and then extract the unattend.xml.

Once you have this, you will want to place it in your Extrafiles directory. This allows us to make changes without having to manually mount the boot media everytime. When changes are made, the boot media will be updated and the unattend.xml injected into the boot media. The unattend.xml will go in the root of your Extrafiles directory.

DeploymentShare\Extrafiles\x86\unattend.xml

DeploymentShare\Extrafiles\x64\unattend.xml

Next we need to open the unattend.xml with Windows System Image Manager. What you’ll see is that there is a RunSynchronous that calls the LiteTouch.wsf script to start the process. What we want to do is add a step right before that to call LTICleanup.wsf before LiteTouch.wsf attempts to load.

First change the Order to “2” on the existing step.

Next add a new step that calls LTICleanup.wsf

Do this for both the x86 and x64 unattend.xml files to ensure this process works on both platforms. Now every time WinPE loads, it will first run LTICleanup, then it will launch the wizard.

x64

If you want to test this solution, just restart in the middle of a Task Sequence, and then immediately boot to WinPE. You should receive the welcome screen instead of the “This Task Sequence has been suspended” error message.

Two of the administrative tasks you often have to do after a SCCM based Deployment has finished is removing the computer from the OSD Collection it has been added to start the Deployment (you don’t really want to leave a computer in a collection with an active OSD advertisement, do you?), and to clear the last PXE Advertisementflag in cases the Deployment has been started via PXE.

The latter is mainly interesting for testing purposes, where you need to re-image the same computers over and over again. But it’s also helpful in cases where the initial Deployment failed. If the underlying problem has now been fixed the Tech (or End-user) might not be able to re-initiate the Deployment before you also cleared the last PXE advertisement flag of that computer. I understand that this has been created to avoid kind of a Deployment loop for computers configured to boot from network first. But as we also remove the computer from the collection there shouldn’t be any bad side-effect. And there is still the caching on the PSP.

Since Version 7.0 the Deployment Webservice (Download) supports a couple methods that let us remove a computer from a specific collection and also to clear the last PXE advertisement flag. So all we actually need to know is the current collection. The following is based on an idea from Richard Zuraff and Jason Scheffelmaer (give credit where credit is due 😉 ). They suggested to simply add the same custom variable to each OSD Collection and then just add the CollectionID to this variable. If the TS executes, this variable will be available for us and filled with the ID of the appropriate collection. This way we can use a generic approach to remove the computer from whatever collection is configured in this variable. Very easy to implement and support.

Great post over the The Configuration Manager Support Team Blog talking about USMT 4.

Here’s a snippet:

Suppose you want to use the USMT 4 feature of hardlinking in a System Center Configuration Manager 2007 Task Sequence, but you notice that the "Capture User State"/"Capture User Files and Settings" and "Restore User State"/"Restore User Files and Settings" tasks do not have any options to perform a local capture with hardlinking. What’s up with that?

Well what’s going on is that USMT 4, which introduced hardlinking, shipped after ConfigMgr 2007 so the hardlinking option was not available in ConfigMgr 2007. However, USMT 4 support was added in ConfigMgr 2007 SP2, and via the OSDMigrateAdditionalCaptureOptions and OSDMigrateAdditionalRestoreOptions variables, a hardlink user migration can be accomplished in a ConfigMgr 2007 SP2 Task Sequence.

Out of the box, ConfigMgr 2007 SP2 only supports USMT 4 online captures, or captures that take place while in the full Windows OS. ConfigMgr 2007 SP2 does not support USMT 4 offline captures, or captures that take place while in WinPE. Offline captures are possible using the UDI feature of MDT 2010 Update 1 when it is integrated with ConfigMgr 2007 SP2.

With that said, there are several ways that a USMT 4 hardlink migration can be accomplished in a ConfigMgr 2007 Task Sequence, including:

You will be prompted in the middle of the installation to download additional files, these are noted in the Release Notes. If you don’t have access to download these at this time, you will have to download them later.

Lets click on “Yes” and have it download the files for me.

You will also be prompted to copy files into your MDT Deployment Share during the install process. Click “Yes” on this prompt.

Click “Finish” to exit the installation.

Post-Install Changes – Lite Touch

After installing, the installer will have downloaded the required files into your DeploymentShare\Tools folder. If you choose to download these manually, make sure to put the files in the \Tools folder as you see below.

If you open up the Deployment Workbench and create a new Task Sequence, you will see 3 new templates available.

Standard Client Task Sequence with P2V Migration

Standard Client Replace Task Sequence with P2V Migration

Custom Task Sequence with P2V Migration

Post Install Changes – ConfigMgr Integration

There is no documentation provided for ConfigMgr setup. That should be in the next Beta according to Jeremy Chapman in the video I linked above. Here are just some examples of changes you might see, this may not include all changes.

Looking at the Task Sequence Wizard for ConfigMgr (with MDT Integration), we will also see the 3 new templates.

Client Replace Task Sequence for P2V Migration

P2V Restore only Template

Client Task Sequence for P2V Migration

You will have to no doubt have to update your ConfigMgr MDT Toolkit package to include the new scripts and Tools that have been added to the DeploymentShare with the P2V installer. Either use the wizard to create another Toolkit package for you, or manually copy over the new files as I’ve identified as “new” below.

A quick compare of our old Toolkit package versus the new Toolkit P2V package, shows us these are the differences, if you prefer to manually update, then copy the updated files into your existing Toolkit package.

That’s it for the install. I’ll post a few more entries once I get further into my testing with the Beta. Enjoy!

Copy SCCMClientHotfixPath.wsf and ZTIUtility.vbs to the ConfigMgr client source files. ZTIUtility.vbs can be found in your MDT Toolkit Package, under the \Scripts directory. Here we have a screenshot of the files copied into the ConfigMgr Client source files.

Update your ConfigMgr Client Package to the Distribution Points, so the changes can be replicated out.

Next open up your MDT Integrated Task Sequence. Right-Click on the Task Sequence and select “Edit”.

Next, add a Run Command Line Step, just before the “Setup Windows and ConfigMgr” step under the Post Install Phase.

Name the step appropriately. I will use “Set ConfigMgr Client PATCH Paths”.

Set the Command Line to “cscript.exe SCCMClientHotfixPath.wsf”

Make sure to select your ConfigMgr Client package for the Package.

Go to the “Setup Windows and ConfigMgr” step and copy any properties you have set here to the notepad or clipboard (to be used later in this guide), if any. Then remove them from the step.

Settings have been removed and copied to clipboard or notepad.

Setting The Variable Method 1

Open up your CustomSettings.ini in the source files for the Settings Package you are using in that Task Sequence.

NOTE: You can check which package this is by looking at the first Gather step in your Task Sequence. This will tell you what Settings package is being used by the Task Sequence.

We will need to set a variable for “SMSClientInstallProperties” and define the variable, as the variable is not known to MDT, however it is a known variable for ConfigMgr. You will want to put any client command line items you previously had in the “Installation Properties” section of the “Setup Windows and ConfigMgr” Task Sequence step, minus any PATCH values.

###############################

[Settings]

Priority=Default

Properties=SMSClientInstallProperties

[Default]

OSInstall=Y

SMSClientInstallProperties=FSP-ConfigMgrFSP

###############################

Then make sure to update the distribution points for the Settings package you just modified.

Setting The Variable Method 2

If you prefer to not set the variable through CustomSettings.ini and would rather set the variable through the Task Sequence you can also do that by doing the following steps.

Create a new Set Task Sequence Variable step before the “Set ConfigMgr Client PATCH Properties” step you created earlier (or whatever you happened to call it).

Set the variable to be set as “SMSClientInstallProperties”

Then set any client properties you want set, again minus the PATCH property.

“This is the third and final blog in the series . In the last blog, The Pros and Cons, I covered the main benefits and underlying drawbacks of file-based and sector-based core images. I intentionally stuck to core image files (the .WIM, .V2I, .GHO, .TIB, .VHD, etc. files themselves) and purposely left out the automation needed to tailor installations at install-time using automation. The automation will actually play a role into the overall recommendations of what type of image to use – file or sector-based. I would argue that thin, file-based images would make a lot less sense if the automation wasn’t there to support the additional functions.”

On the Details page, we can set the options for joining a workgroup or joining a domain (along with providing domain join credentials). We can also set the user name, organization name and product key.

I’ve changed the user to “Deployment User” and the organization to “Deployment Organization”. Since this is Windows 7 I’ve left the product key blank (I’m relying on KMS to activate this box once it’s imaged).

The next screen allows you to set some options if you were going to capture an image of the machine. This will let you set some properties for the image capture. We are going to a create a Task Sequence for deploying here and thus will not provide anything related to capture settings.

The next screen allows you to select an existing boot image (like the one we created in Part 2) or you can optionally create a new boot image, which will run through the process we used in Part 2 to create our MDT boot image. We will choose to use our existing image here.

Once we’ve selected our boot image, click “Next”:

Next we will need to create a MDT Toolkit Files package or select an existing one. The first time you create and MDT Task Sequence, you will have to create a MDT Toolkit package, after that, you can just choose an existing one.

If you have an existing package you’ve created before you can select that now.

If you have not completed the wizard before, then we will need to create a Toolkit package.

Select “Next” once you have put in the path for where you want to store your Toolkit Package.

On the MDT Details pane, we will need to provide a name for the ConfigMgr package we are creating, then click on “Next”:

The OS Image pane provides us with various options.

We can specify and exisiting image we’ve previously captured and imported into ConfigMgr:

We can create a new OS image if we import an image file we have previously capture:

We can specify an existing OS install package (source files) if we have previously imported these into ConfigMgr:

Or lastly, we can point the wizard to source files (local drive, network share, or DVD/CD) and create a new OS install Package in ConfigMgr:

For this walkthrough I’m going to use an existing OS image that I’ve previously imported into ConfigMgr and then select “Next”.

Next we need to specify and existing ConfigMgr client package (client source files for installation) or have MDT create a new ConfigMgr client package for us.

I’m going to have MDT create a ConfigMgr client package for me and then select “Next”.

Next we need to either specify an existing USMT package or have the wizard create a new USMT package for us. The wizard will create a USMT 4.0 package by default. If you are deploying XP and require USMT 3, you will want to select a USMT 3 package here that you have previously created in ConfigMgr.

Lets have the wizard create a USMT 4 package for us and then select “Next”.

Name the package appropriately and then select “Next”.

Next we have the Settings Package screen. Here is where we will create a Settings Package that will help drive our MDT Task Sequence.

Settings Packages contain the following files:

XP

Sysprep.inf

Customsettings.ini

Unattend.txt

Vista/Windows 7

Customsettings.ini

Unattend.xml

Set your source path for the Settings Package, and then click on “Next”:

Set the name of the ConfigMgr Package, and then click “Next”:

The next wizard screen is for specifying the Sysprep Package. If you are deploying XP/Server 2003, then you will want to create a new Sysprep Package and it will create a ConfigMgr package containing the require sysprep files for you. If you are working with Vista/Windows7/Server 2008, then a sysprep package is not required.

Select “Next”:

Finally, we have a summary screen showing all the options we have selected in the wizard:

Click on “Next to process the wizard and create the necessary packages. This process can take some time depending on how many packages you have to create and where the source/destination paths are located.

Once completed, you will have a completion screen showing that the process completed successfully.

Click “Finish” to exit the wizard:

Under Software Distribution – Packages, you will now see all the created packages:

You may have different names or more packages depending on the options you selected in the wizard.

If you imported any images or install packages, you will have those listed now as well:

Any package that was created will now need to be sent to the distribution points. Again, I will assume that you know how to do this already.

Keep in mind any time you make changes to any of the packages, you will have to update the distribution points to reflect those changes.

I recommend use of the Copy Packages wizard to copy the packages out to distribution points. This option is also available in the OS Images and OS Install Packages nodes as well.

Editing the Task Sequence

If you right-click on your newly created MDT Task Sequence and click “Edit”, you will now see that the MDT Task Sequence is quite a bit different from a ConfigMgr Task Sequence.

Some important steps to note that you will likely have to modify in the future are the following:

“Use Toolkit Package” – change this to reflect your Toolkit/Scripts package if you ever change or create a new one, this step exists in the following places:

Initialization

Preinstall – New Computer Only

Install – Refresh Only

State Restore

Gather Logs and StateStore on Failure

“Gather” step under Initialization. This step is where you would define the “Settings” package you want to use to control rules, namely processing the CustomSettings.ini file.

“Apply Operating System Image” step under the “Install” phase. This is where you can specify the unattended or sysprep answer file contained in your “Settings” package.

A couple other common modifications you will want to make the to Task Sequence after it’s been completed are the following.

Disable the “backup” task. This task is located under Install – Refresh Only. This is enabled by default and will create an image of the machine you are refreshing (OS to OS), this adds a significant amount of time to the process.

By default the local administrator account is disabled in the Task Sequence.

We’ll want to enable this and set the appropriate password.

Set the appropriate Time Zone. By default the Time Zone is set to “Microsoft Time”.

If you didn’t set Domain properties in the wizard (like we didn’t in this example), but want to come back later and change this, you will want to go to Post Install – Apply Network Settings.

CustomSettings.ini

By default the customsettings.ini created in each “Settings” package you create will look like the following:

As you work with MDT more, you will probably end up adding some rules to process in here, along with database queries. Whenever you work with this file, keep in mind that you will have to update your package to the distribution points after making changes.

Resolving “Task Sequence cannot be run because the program files cannot be located on a distribution point”

One of the most common issues when working with Task Sequences is getting to this screen:

Either something failed to replicate out, or, not that it ever happens, we “might” have to forgot to distribute a package or two. There isn’t an easy mechanism to identify what packages are missing as this wizard will only give you one at a time, which can be quite frustrating if you are missing several.

There are 2 scripts provided by community members to help resolve the above error. The first script was created by Michael Niehaus and details can be found here. The second is by Jason Scheffelmaer and is based upon Michael Niehaus’s and can be found here.

Michael Murgolo has a nice post over on The Deployment Guys Blog about using command shell (CMD) scripts within MDT.

“OK… I’ll admit it, I like to write Command Shell (CMD) scripts when I can. For me it’s like putting on an old broken-in pair of sneakers… so comfortable and familiar. Unfortunately, using them in MDT task sequences can be challenging. I this post I’ll demonstrate some techniques and helper scripts that can bring Command Shell scripts into the MDT era. There are four main tasks that I’ll address today: calling other scripts and executables, getting Task Sequence Variables, setting Task Sequence Variables, and logging.”

In addition to the driver management methods that I’ve blogged about before, I wanted to create a post showing how I typically handle “bad” drivers, or drivers that are software based. These would be drivers we can’t manage through normal PNP detection (auto-apply) or through driver groups (“forced” injection), usually they are MSI based or setup.exe based as well.

So what I’d like to do here, is show you a few common approaches to handling how to install the software, sort of a good, better, best approach. All of these methods do work, so feel free to use the approach that works best for you. I’m using a bunch of generic names and models instead of specific vendors as I don’t want to give the impression that one vendor is “better” than others.

Installing drivers on a per manufacturer and/or model basis (good)

The first method involves creating a structure in your task sequence for each manufacturer and model you might have. This gives you some very good organization, and it’s nicely laid out. However the negative here is that you could be listing the same drivers for multiple models. If you add a new model, then you would need to create new steps and match up the appropriate drivers. If you have a large organization with a lot of models and manufacturers, your task sequence could get very large.

We use a model query on the model steps to limit those to only run on a per-model basis. Anything under that step will then run on the given model.

Installing drivers on a per driver basis with model detection (better)

One way to improve upon the previous method is to create steps for the various drivers themselves, and then add queries for the models they support. This allows for more flexibility. If you add a new model that uses the same driver, you just have to add another query for it work. This method has fewer steps in your task sequence than the previous method.

On the driver package itself, we use model queries to tell it what models that step will apply to.

Installing drivers based upon the HardwareID (best)

The method I prefer for installing these types of drivers is based upon the HardwareID. Just like we do for mass storage drivers. This allows the most flexibility you don’t have to worry about new model support, as long as the HardwareID matches, the driver will install successfully on your systems. This is the cleanest method and allows for the fewest steps in your task sequence.

Then for Bad Driver 1, we’ll set a single HardwareID for an example.

For Bad Driver 2, here’s an example when the driver could apply to multiple HardwareID’s. We’ve set a “If any conditions are true”, so it’ll run as long as there is a single match.

So, just like we can use the HardwareID to detect and inject the correct mass storage driver for Windows XP, we can also use it to install “software”.