Partager via

MDT 2010 Update 1 Beta Release Part 2: Things You Should Know

  • Article

Overview

This blog post is meant to quickly explain some of the things that you should know when using UDI.  I will not go into depth on solutions for each of the scenarios that I have listed here, but will create additional posts for those items that need to be explained in more detail.

When selecting the Format Option it Partitioned my Disk!

When using Modena and you started from WinPE we did not make an assumption that you want to blow away all partitions.  However, the template has changed now that it is moved into MDT and is called UDI. Be forewarned that with MDT when you start from WinPE it is thought of as a new computer.  So to cover this if you select to backup your user state rather than format, it will leave your partitions alone.  If you select format, all bets are off and disk 0 with be repartitioned to only have 1 partition.  As this post is an attempt to try and get information that you should know out there as quickly as possible, I will try to cover additional information from a different post on how to set it up if you only want the target drive to be formatted rather than repartitioning.

USMT Failed when Running LoadState

If you have local user accounts and have backed up user state you will run into a problem in which your user states will fail to restore.  This is because users will not get created as a password for setting up these accounts has not  been specified out of the box.  There are a number of options when dealing with this problem.

  • Remove the /lac switch for capturing user state using ScanState.exe (though your local users won’t be captured)
  • Specify a password to be used for creating local accounts.  This maybe a security risk however, as every local account on every machine on which the task sequence is used will get the same password.
  • Don’t use the built in USMT steps in the task sequence, use a script instead.

My Backgrounds aren’t Displaying When Using a x64  WinPE

When an x64 boot image is used for operating system deployments, the status background bitmap will not be displayed in Windows PE environment.  Currently there isn’t a x64 version of BGInfo.exe, which is used to display the backgrounds.  Keep in mind you can use an x86 boot image for applying either an x86 or x64 image rather than using the “applying an image from original source bits” option.  If you are doing the latter then you will need to use a boot image with the same architecture as the image that you are applying.

How Do You Setup Language Packs?

For installing language packs, you need to configure the list of language packs in UDI Wizard Designer and for each of the language packs an Install Language Packs Online or Offline task sequence step will need to be added in the UDI Task Sequence pointing to the Language Pack package. Additionally you will want to setup conditions for each of these steps so that the appropriate language will be applied only when it was selected by the end user. I will try to go more in depth on this subject in a later post.

When I Set Certain Languages the OSDResults Summary at the End of the Deployment Shows an Unknown Install Time

This occurs when the time date format is different than the time date format at the end of the deployment.  For example if you start from WinPE and it is in a US time date format and then you install a German language pack and set your default system locale to this date and currency format this will occur.  This is something that we are looking at fixing for the RTW version of UDI.

Why Is the Task Sequence Creating a Backup WIM Image Even When I Selected the Format Option?

A WIM image of your drive will currently be captured even if you have selected to format.  To avoid capturing a WIM of a drive that has been already formatted simply add an OSDDiskPart not equals true condition on the backup step and it will save some time as well as disk space.  When set in this manner a backup of the drive will only be taken when the format option is not selected. If you never want to capture a WIM image of the drive simply disable the backup step.

CM Console and .NET Framework 3.5 Requirements

You must install the designer on a machine that has the Configuration Manager Console.  Certain console dlls are used when connecting to a site server in order to pull down a list of packages. Additionally in order to use the UDI Wizard Designer, the Web Service Installer, and OSD Results you must have .Net Framework 3.5 SP1 installed.  When 3.5 SP1 is not installed the designer will through a warning message stating that it is required.  When the web service runs it also lists its requirements.  As OSD Results is a runtime executable used in your deployments it will simply not run prior to the logon screen.  You might ask what if I have .Net Framework 4.0 installed.  It wont’ work by itself.  You must install 3.5 SP1 which can be installed with 4.0 in parallel.

Web Service and 404.3 Errors

As is in the release notes for the Web Service: If you receive a 404.3 when browsing to the web service, this is typically due to WCF mime type not being registered correctly.  To register the WCF mime type on the web server, browse to: %Windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation.  From an elevated command prompt run ServiceModelReg.exe –i.  This should register the mime type for the .svc extension, required by the web service.

Bitlocker

There are a few scenarios around Bitlocker that should be discussed.  First the the one change between Modena and UDI is that the Enable Bitlocker step has been disabled in the default UDI template.  Because users may want to setup Bitlocker with a pin and the OSD Setup Wizard doesn’t prompt for a pin, or anything for Bitlocker for that matter, we decided that it would be best just to disable the step.  If you would like to setup Bitlocker without a pin you can simple enable the Bitlocker step in the task sequence and then change any of the settings provided from this step.

If you only want to run if Bitlocker was enabled previously you can add a condition in addition to the existing conditions on the Enable Bitlocker step so it will only run if OSDBitlockerStatus equals protected.  This variable is set when the Check Drive Encryption(OSDBitlockerState.vbs) runs from with the OSD Setup Wizard.  Because this preflight check is only executed when the OSD Setup Wizard is run from within Vista or Win7, this variable will only be set when starting from these operating systems.  For example if you set it up in this way and you started from WinPE you would never have Bitlocker re-enabled as this variable would never be set.

No Partitions? No Worries

When starting from WinPE two of the scenarios that we needed to cover were offline state capture and bare metal.  In many instances as was the case with MDT previously, if you start from WinPE it is considered a new computer and formats the drive.  Since we support offline user state capture you can’t just boot to WinPE, kick off your task sequence, and format the drive as you might unintentionally blow away user state.  So to cover this scenario we set the first step in the task sequence template called “Prompt before partitioning disk” to run a script contained in an MDT boot image. Then we added several condition to the group containing this step, one of which is a query to check to see if you have any partitions. If you don’t have any partitions the step will run and prompt you whether you would like to partition and format you disk.  If a user selects yes then it will format the machine.  If a user selects no then it will cancel out of the task sequence much in the same way that the UDI wizard does when you select cancel.  Again this is only available if you have created a new boot image with MDT 2010 Update 1 Beta.

What if I Want to Specify an Additional Configuration File Outside of the One Provided?

There were 3 configuration files available with Modena.  However, with UDI this has been stripped down to one configuration file.  This decision was made as really the only difference between the configuration files were the preflight checks executed from those configuration files.  Now there is a wrapper around the Setup Wizard that will determine which OS the task sequence is running in at the time and then strip out the appropriate preflight checks for that environment and save that information into a new XML.  The script will then execute the setup wizard with the newly created XML.

The time may come when you want to add in your own preflight checks that only runs in a specific environment or you may want to run multiple configurations for other reasons and run them based on a condition from your task sequence. For this you may ask, “can I simply run the wizard with the /xml switch as I did in Modena?”  It will run, but there are certain things that the wrapper does after the wizard exits such as converting the string value for the variable used to add in additional users into the local administrators group into a format that is consumed by existing MDTs scripts. Because of this I would not suggest you use the /xml switch when running. Instead run the script with the /definition switch and point it to the appropriate configuration file such as the following: cscript.exe "%DeployRoot%\Scripts\UDIWizard.wsf" /definition:..\..\scripts\<configuration XML>. This will allow you to run the setup wizard, point it to your XML, and still have the functionality of the UDIWizard script. One thing to note if you specify the /definition switch the UDIWizard.wsf does not strip out any preflight checks. So if you put together a customized XML you would need to make sure to customize it based on the environment that it will be run in by only including the preflight checks that run in that environment.

Comments

  • Anonymous
    May 27, 2010
    The comment has been removed