This Blog post was created by Michael Schmidt.

Controlling the look and feel throughout OSD a very important part of creating a good user experience. Not only is the out-of-box experience a bit bland, it’s unfamiliar and confusing to someone who’s never experienced OSD before. Our goal in this article is to outline how to spice up the end-to-end deployment experience.

At a glance, a user should be able to tell:

• What’s going on?
• Where am I in the overall scheme of things?

Should the deployment go awry, these questions become even more important. In one glance, without looking at logs, anyone viewing the screen can answer questions such as:

• Where did the machine fail?
• What is the machine name?
• Does it have an IP address?
• Etc…

With BGInfo, the available information to display is nearly limitless; you have complete control over what details are visible and important to your organization.

A mockup of what might be used to accomplished this goal is shown below:

Showing Status

All this is possible through the use of BGInfo. With this utility, the background screen can be changed at any point in your Task Sequence.

In the mockup provided, the following practices were taken:

1. Branding was provided to create familiarity and provide context for what is taking place
2. Progress was grouped into 5 phases: System Backup, Install Image, Windows Setup, Install Applications, and Restore Backup
3. One background bitmap was created for each phase; each time a phase completes, the background is changed

So, in the example given, 5 bitmaps were created. Thus, BGInfo will be called 5 times within our Task Sequence. Each bitmap represents the active “Phase” in an “On” position, and all other “Phases” in an “Off” position.

Creating Status Backgrounds

Since our deployment consists of 5 phases, we’ll need 5 different bitmaps. In addition to 5 different bitmaps, we actually need 5 BGInfo configuration files. BGInfo configuration files store rendering information used to display the background; these files are passed to BGInfo as parameters. 

To create a screen, open BGInfo and:

1. Choose a background image to use
2. Choose what computer information to display
3. Format/Justify/Center as preferred

Defining the background image to use, color, and positioning:

Defining what computer information is displayed, and where to position it:

Create all 5 pages in this manner, and save each BGInfo session. After completing these steps, the final list of files will look something like this:

Setting up the Task Sequence

Assuming all the required files exist in one directory, a method for calling the appropriate “Step” is necessary. This can be accomplished through a batch file containing the following:

• "%~dp0bginfo.exe" "%~dp0step_0%1.bgi" /nolicprompt /silent /timer:0

In this manner, your Task Sequence would simply reference the package and call the batch file with a Step number:

Maintaining Look & Feel

To maintain the look and feel across the entire deployment, there are three areas where adjusting the background image is important for consistency:

• Task Sequence Wallpaper set through BGInfo (already covered)
• Windows PE Wallpaper contained in the Boot Image
• Windows Setup Phase Wallpaper

Boot Image

When initially starting up in Windows PE, a default built-in background image is displayed. Until your Task Sequence begins and the background batch file runs, a user will see whatever background ships in Windows PE.

Apply your own background by opening up the SCCM console, locating your boot image, and modifying its properties. Look for the “Windows PE Background” field:

Windows Setup

After applying and booting into it the new OS (after the “Setup Windows and ConfigMgr” step), an animated black background will appear for the duration of your Task Sequence. Windows Setup overlays a full-screen window named “FirstUXWnd”, displaying the text “Setup is preparing your computer for first use”. Until the Task Sequence has completed in its entirety, this window will be seen and the custom background will not.

Task Sequence background after booting into the new OS:

Assuming you’ve customized the first half of your Task Sequence to show a snazzy look/feel, you’ll probably want to persist this. Especially if your Task Sequence contains a large number of post-OS-install tasks, such as application installs.

One simple and safe workaround is to hide this window. Since we know the window title, we can simply search for it and send it a “hide window” message. However, this requires creating a small application to perform the hide.

Creating this application isn’t too difficult. An example of the API calls necessary to perform this is given below. Using either .NET or native C++, this is relatively simple to create.

1. Enumerate all windows (EnumWindows)
2. Search for the window titled “FirstUXWnd” (GetWindowText)
3. Set the window state to “Hidden” (ShowWindow SW_HIDE | SW_SHOWNORMAL)

Once completed, run this binary from your Task Sequence immediately after the “Windows Setup and ConfigMgr” step.

Update! A complete source-code sample is available here.

You now completely control the deployment look and feel, end-to-end.

This blog post was created by Michael Schmidt.

At Microsoft, we have the unique challenge of having to build a OSD experience that includes providing a great user experience prior to deployment of a new OS.  In our case, we had the challenge of figuring out how we could do this considering that task sequence runs in Session0 and many of our users would never get this pretty user experience. 

In the interest of helping others who have this same goal - bettering the user experience of OSD – we wanted to cover launching an interactive process from the Task Sequence (TS). No binaries are provided; this post only journals a high-level overview of creating a C++ binary to launch an interactive process.

A similar idea with source is available from The Deployment Guys.

1. What are we building?

Assuming the user interface/wizard is pre-built in the form of a standard binary (.exe), a launcher is necessary. Shown below is an example of the launcher concept, and how it might be used.

• Binary: SessionLaunch.exe
• Parameter: A process name to find; our next parameter will launch in the same session
• Parameter: A process to launch interactively, in the user’s context

2. When is this useful?

Since processes launched under WinPE are visible, this launcher provides value only when run from an existing OS. Two of the primary modes for operating a TS are:

• Standalone Media TS
• Download and Execute / Download on Demand TS

With a custom launcher, a UI could be spawned from any place in your Task Sequence. It could be used to:

• Prompt the user for information
• Popup error information or warning dialogs
• Show TS status, or replace the progress implemented by OSD completely (by hiding TSProgress UI via ShowWindow())

Another point worth mentioning is that a native launcher has no dependency on the .NET Framework. All API calls covered will run on Windows XP and higher. Building a launcher after this manner grants deployment flexibility, in relation to target OS and required runtimes.

3. Understanding Process Context

When running a Task Sequence within an existing Operating System (OS), all TS work is performed in SYSTEM context. As a result, all user interface (UI) wizardry you might inject wouldn’t be visible to the user (Windows Vista+). To quickly cover this (emphasis added):

Impact of Session 0 Isolation on Services and Drivers in Windows Vista
“The Microsoft Windows Vista™ operating system mitigates this security risk by isolating services in Session 0 and making Session 0 noninteractive. In Windows Vista, only system processes and services run in Session 0. The first user logs on to Session 1, and subsequent users log on to subsequent sessions. This means that services never run in the same session as users’ applications and are therefore protected from attacks that originate in application code.”

Take note of the following points:

1. Task Sequence execution occurs in Session 0
2. User Logon occurs in Session 1+
3. Unless you boot and execute your TS UI in WinPE, no one will see it

4. Which Session?

Our goal is to launch a process from SYSTEM context into a session where our user interacts. Since TS execution is performed in Session 0 (non-interactive), we need to locate an alternative, interactive session which the user is running under. How can one tell which Session ID the user is operating under? One useful API to determine this might be:

• WTSGetActiveConsoleSessionId
  ”The WTSGetActiveConsoleSessionId function retrieves the Terminal Services session that is currently attached to the physical console. The physical console is the monitor, keyboard, and mouse. Note that it is not necessary that Terminal Services be running for this function to succeed.”

In most cases, WTSGetActiveConsoleSessionID is sufficient to retrieve the working session. Unfortunately, while this session provides the physical console session ID, problems arise when multiple users are logged in (or when our target user is connected over Remote Desktop/Terminal Services). A more appropriate function for our purpose is:

• ProcessIdToSessionId
  ”Retrieves the Terminal Services session associated with a specified process.”

Now, only one TS can execute at a time. When the TS launches, a process is spawned by the TS to show progress; this process is “tsprogressui.exe”. OSD opens this process from SYSTEM context into the active user’s session, which is precisely what we’re attempting to do. Thus, in our launcher we simply search for the OSD-spawned “tsprogressui.exe” process. By searching for this process and calling ProcessIdToSessionId against it, we can determine the session ID our UI should spawn in.

Searching processes can be accomplished through the following API calls:

• CreateToolhelp32Snapshot
  ”Takes a snapshot of the specified processes, as well as the heaps, modules, and threads used by these processes.”
• Process32First
  ”Retrieves information about the first process encountered in a system snapshot.”
• Process32Next
  ”Retrieves information about the next process recorded in a system snapshot.”

An example of this is provided by MSDN; using this example, we can extract the session ID by:

1. Inserting a string comparison in the while-loop to match “pe32.szExeFile” against the name “tsprogressui.exe”
2. Once found, call ProcessIdToSessionId to determine which session the TS is running in

5. Launching the UI

CreateProcessAsUser

Now for the tricky part. I defer source examples for this next section to the wide world of the web, but will overview on the idea. Most important is the CreateProcessAsUser API. Using this function, it becomes possible to launch your UI from the Task Sequence in SYSTEM context, into the user’s session. When this is accomplished, your UI will be visible/interactive.

• CreateProcessAsUser
  ”Creates a new process and its primary thread. The new process runs in the security context of the user represented by the specified token.”

The difficulty in making this call is the preparation. Numerous parameters must be created and pre-populated prior to making the call, and this is where the trouble lies.

Creating an Access Token from the user’s Winlogon

An Access Token, representing the user we wish to execute under, is required for CreateProcessAsUser. Before launching a process under the user’s session, this token must be created/duplicated. To perform this, we extract and duplicate an Access Token from the existing user’s Winlogon session.

1. Find the “winlogon.exe” process and obtain its handle for the target user.
   This can be done by looping through processes (shown previously) and matching the process name and session:
   • Loop through processes…
   • If process name (pe32.szExeFile) is “winlogon.exe” …
   • If process session ID (ProcessIdToSessionId) matches our user’s session ID, grab the Process ID (PID)
2. Call OpenProcess against the PID.
3. Extract a handle to the Winlogon token using OpenProcessToken.

Elevating token privileges with SE_DEBUG_NAME

Once a handle to Winlogon is obtained, an Access Token can then be extracted. First, a template containing the privileges we require is necessary (LUID type); this will be used when creating/duplicating our Access Token (TOKEN_PRIVILEGES object).

1. Use LookupPrivilegeValue to find the LUID representing SE_DEBUG_NAME
2. Create a new TOKEN_PRIVILEGES object
3. Call DuplicateTokenEx using the handle from our user’s Winlogon; our desired access is MAXIMUM_ALLOWED
4. Call SetTokenInformation with the previously extracted Session ID (where our UI will execute)
5. Call AdjustTokenPrivileges to merge/append privileges from the LUID template, into our duplicated token

Launching, waiting, and returning

While many other parameters are required, they’re much simpler to generate. Creating the Access Token is the tricky part; MSDN documentation and other code samples suitably cover the rest. However, when launching from a TS you’ll likely need to wait for the process to end, and want to know the resulting exit code. Launch, wait, and process the return code in this order:

1. CreateProcessAsUser( …, &piConsole)
2. WaitForSingleObject(piConsole.hProcess, INFINITE);
3. GetExitCodeProcess(piConsole.hProcess, dExitCode);

6. Summary

This is all it takes… a little bit of code and a little bit of work and you can give a “new” face to OSD like never before thought of.  To wrap up the order presented for creating a launcher:

1. Find where “tsprogressui.exe” is executing (session ID)
2. Find the corresponding “winlogon.exe” process associated with that session
3. Duplicate the token
4. Set the token session
5. Adjust the token privilege
6. Launch the process
7. Wait
8. Extract and return the exit code

7. Troubleshooting Tips

A few small tips to consider when developing, testing, or troubleshooting.

PsExec

Working between SYSTEM and USER context can be difficult and complex. PsExec is invaluable for troubleshooting; this utility can open a process in SYSTEM context, allowing the ability to test your binary. To open a SYSTEM context command-line, run the following from an elevated command window:

• psexec –s –i –d cmd.exe

Task Manager: Adding the Session ID Column

It’s useful to see what tasks are executing under which Session ID. Add the “Session ID” column to Task Manager:

In a previous blog post located here we outlined how to create an interactive task sequence experience and detailed how to interact between a system session and a user session. Although it is not our recommended approach, as we would like you to use the tools available, sometimes customization outweighs using an in box solution. So in this blog post I will outline how you can launch your own customized wizard using the same technique we use to launch the UDI wizard.

Launching an EXE

You can use the same command line that UDI uses in order to launch your customized wizard. Although the UDI wizard has a script wrapper to do a few other things to launch the wizard interactively it follows this simple command line process:

ServiceUI.exe -process:tsprogressui.exe Wizard.exe

In this example ServiceUI will look for which session tsprogressUI.exe is running in so it can display my.exe to it. However, because it was launched from the task sequence it will be running in system context.

If you were to run from the UDI task sequence you would probably want to use the already defined task sequence variables in order to specify the paths of your custom wizard. Of course you must first update your scripts package to include your custom wizard executable.

Here is an example:

%ToolRoot%\ServiceUI.exe -process:tsprogressui.exe %ScriptRoot%\MyCustomWizard.exe

Launching an HTA

Launching an HTA will be very similar as the process outlined above, but instead ServiceUI.exe must launch mshta.exe which in turn calls your customized HTA. Here is an example:

%ToolRoot%\ServiceUI.exe -process:tsprogressui.exe %SYSTEMROOT%\system32\mshta.exe %ScriptRoot%\MyCustomHTA.hta

Overview

If you have multiple images that you deploy but would like to reduce the amount of operation overhead in maintaining task sequences, consolidating your task sequences into one task sequence should be considered. For example if you have a task sequence that deploys an x86 image and a different task sequence to deploy the amd64 version of the image, combining these images into one WIM with multiple indexes and combining your task sequences into one task sequence is something that should be considered.

Why Combine Images

• Combining images will reduce the amount of footprint on your servers by using single instancing.
• Reduce the amount of operation overhead required for a task sequences as an administrator will not have to make edits in multiple task sequences.

How to Combine images

As a rule of thumb images can be combined by using the following steps:

1. Capture ImageA
2. Capture ImageB
3. Rename and change the description for ImageA
4. Mount ImageB
5. Append the Mounted ImageB to ImageA

If there are additional images you can continue by mounting ImageC etc. and appending them to ImageA.

Capture Our Images

Now that we have gone over the procedure at a high level lets take a look at a specific example and the command needed to combine images. The purpose of this blog is not to talk about how images are captured so lets say that we have captured an image called Win7x86.wim and another image called Win7amd64.wim and we would like to combine these images. As a best practice the x86 image should be the first index in a combined image (perhaps this is just personal choice, but for the remainder of this blog it will be outlined in this way).

Rename and Change the Description for ImageA

To avoid confusion on which image is which lets start out by changing the name and description for the first image (or index) and the name of the actual file before appending additional images. Lets start by renaming the file to Win7Combined.wim. Now lets change the information in the image using the following example:

imagex /info Win7Combined.WIM 1 "Win7(x86)" "Windows 7 x86"

Using this command the first index in the WIM has had its name changed to “Win7(x86)” and its description to "Windows 7 x86".

The change can be verified by using imagex /info Win7Combined.WIM

Mount ImageB

So now we will need to mount our Win7Amd64.wim and append it to the Win7Combined.wim. This will be done using the /apply switch, which will actually extract all of the files to the directory specified. Keep in mind that whatever directory you apply the image to will need to be empty. Follow this example to mount the image:

imagex /apply "Win7Amd64.wim” 1 C:\Mount

Where 1 is the index of the image and C:\Mount is the location where the image will be applied. Of course the image can be applied to any directory as long as it is empty.

Append the Mounted ImageB to ImageA

Now the image is ready to be appended to the first image that was renamed. Use the following example to append the images:

Imagex /append C:\Mount "Win7Combined.WIM" "Win7(AMD64)" "Windows 7 AMD64"

This will append the mounted image to the x86 image that we modified at the beginning. Additionally we have set the name to "Win7(AMD64)" and the description to "Windows 7 AMD64" of the appended image.

Now that the images have been combined imageX can be used with the /info switch to see that the image count is now 2.

Note: You can also use DISM.exe for this process also

I know that I haven't posted in a while, but I have been thinking about it. I have several topics in draft form just waiting to be finished up and posted. In today's blog I will go over the task sequence variables that are read or set based on the selections made from each page in the wizard. 

Welcome Page

 No variables are read or set for this page.

Preflight Page

 No variables are read or set from the wizard for this page. However, there are some task sequence variables that may be set from some of the preflights being run from the page. An example of this is the variable set from the BitLocker preflight check.

OSDBitlockerStatus 

This task sequence variable specifies if BitLocker Drive Encryption is enabled on the target computer by the BitLocker preflight check.

Computer Page

OSDComputerName

The computer name assigned to the target computer

OSDDomainName

Specifies the name of the domain to which the target computer will be joined if the computer is configured to be a domain member.

OSDDomainOUName

Specifies the name of the OU in the domain to which the target computer account will be created when the computer joins a domain.

OSDWorkgroupName

Specifies the name of the workgroup to which the target computer will be joined if the computer is configured to be a workgroup member.

OSDNetworkJoinType

Specifies whether the target computer joins a domain or a workgroup.

OSDJoinAccount

Specifies the domain-based account used to join the target computer to the domain specified in the OSDDomainName task sequence variable. This task sequence variable is necessary if the target computer will be joined to a domain.

OSDJoinPassword

Specifies the password for the domain-based account used to join the target computer to the domain specified in the OSDJoinAccount task sequence variable. This task sequence variable is necessary if the target computer will be joined to a domain.

User Configuration Page

OSDLocalAdminPassword

Specifies the password for the Administrator local built-in account on the target computer.

AddAdmin

This task sequence variable specifies a list of domain-based accounts or local accounts to be added to the Administrators local built-in group on the target computer.

Language Page

UILanguage

The default language to be used with the target operating system. If not specified, the language configured in the image being deployed will be used.

UserLocale

 The user locale to be used with the target operating system. If not specified, the user locale configured in the image being deployed will be used.

SystemLocale

Default system locale used for the operating system.

KeyboardLocale

Keyboard locale to be used in the deployed operating system.

OSDTimeZone

The default time zone  

Volume Page

OSDImageIndex

Specifies the index number of the target operating system in a WIM file.

OSDArchitecture

Specifies the processor architecture of the target operating system selected for deployment.

OSDTargetDrive

Specifies the disk volume where the target operating system will be deployed.

OSDWinPEWinDir

Specifies the folder in which the Windows operating system is currently installed on the target computer.

OSDDiskPart

Specifies whether the target disk partition should be formatted.

Application Page

OSDApplicationList

Specifies which applications should be selected by default on the Install Software page of the Operating System Deployment (OSD) Setup Wizard.

Application Base Variables

These variables will be set based on which applications are selected when the wizard exits and what the base variable name is set to.

Summary Page

No variables are set from this page. However, as this is the last page in the wizard when the Finish button is selected then the selections for each page will be set as task sequence variables.

Other

OSDSetupWizCancelled

Specifies if the user cancelled the Operating System Deployment (OSD) Setup Wizard. The wizard can be cancelled from any page in the wizard.

Release

The long awaited release of MDT 2010 Update 1 Beta is finally here. We have been working hard to integrate Modena into MDT, now known as UDI. Today is the day when users can finally get their hands on it. What is UDI, you might ask. It stands for User Driven Installation. For those that are not familiar with Modena, UDI gives the end user the ability to interact with Configuration Manager Operating System Deployment (OSD), which is not available with out of the box OSD. In addition to the OSD Setup Wizard which is displayed to the end user, UDI comes with the UDI Wizard Designer which allows an administrator to customize the end user’s Wizard experience. Additionally UDI comes with a number of preflight scripts, a web service for storing your application master configuration, and OSD Results (an executable that shows a summary of the deployment such as how long it took and whether your selected applications were successfully installed or not).

Don’t worry, if you are new to Modena or UDI we will be talking about all of these components in later blog posts to better familiarize you with what is available with UDI. For those that are familiar to Modena we will cover some of the differences between Modena and UDI in this blog post. In addition to UDI there are a number of new features and bug fixes that available with MDT 2010 Update 1 Beta outside of UDI. However, as I was the feature PM for Modena and a PM for integrating Modena into MDT under the name UDI, I will be concentrating on UDI specific content for this post.

What’s Different between Modena and UDI?

At a high level I will try to cover what the difference is between Modena and UDI. Modena was a tool we created internally to meet our deployment needs which we thought other users of Configuration Manager may also find useful. Because of this we made it available through several releases to the Microsoft Connect site. Although at a low level there are quite a few changes between Modena from the previous release and UDI available with the MDT Update 1 Beta release, for this blog post I will try to stick to the major changes between the two:

One Configuration File

UDI comes with one configuration file while Modena came with three. The three Modena configuration files where used based off of the environment the OSD Setup Wizard was running from. There was one configuration file for XP, one for WinPE, and one used while started from either Vista or Windows 7. The only difference between these configuration files were the preflight checks that were run in each environment. If these checks were run from an environment that they were not intended to run from they may return an error and an end user may not be able to move forward from the preflight page of the wizard. However, because UDI now has a wrapper around the OSD Setup Wizard which checks which environment the wizard is running in and based on that environment strips out the unneeded preflight checks, we have been able to get the OSD Setup Wizard down to 1 configuration file. What happens if you want multiple configuration files? I will go over that later in a later post.

You no longer have to create packages and attach them to your task sequence.

With Modena, after you installed the Modena components you would need to copy the given bits to their source directory and setup all of the Configuration Manager packages manually. After this was done you would need to import the task sequence into your Configuration Manager console and associate the appropriate package to each of the steps missing a package. One of the nice things about integrating with MDT is when you want to use the UDI template you simply need to right click on the task sequence node of the console and select “Create Microsoft Deployment Task Sequence”.

Now select “User Driven Installation Task Sequence” from among the templates:

Now you will be walked through a wizard for creating your task sequence. As part of this process the wizard will ask you if you have existing install image package, SCCM Client Package, boot image package, MDT toolkit package, USMT package, and MDT settings package. If you do not have existing packages then you can specify information such as a name and the package source in order to have the package created for you as part of the process (including copying the bits to the source directory). This will happen after confirming your selections from the wizard. Don’t forget that once the packages are created you still must associate these packages to at least one distribution point to be usable as part of the task sequence. Now if you would like to customize your task sequence you just need to edit it from the task sequence node and make your changes. This makes for a better administrator experience as you will not have to edit the task sequence and then associate each of the requisite packages to each of the steps requiring those packages.

There are a number of validation fixes that have been included into the UDI Wizard Designer.

As nice as it was to have a UI for modifying and creating your configuration files there were a number of things that we would have liked to have done for the previous release of the Designer, but there simply wasn’t enough time as is normally the case. We added a lot of validation checks around the designer. For example when you add an image index to the designer it now validates whether that image index was already added and gives you a prompt. This is just one of many examples of the validation that has been added to the Designer. There is no longer a Blogs page, but when we RTW we plan to add help links into the designer where the blogs page was. Overall the designer still has the same look and feel as it did previously just with a bit more logic behind it.

Task Sequence

The task sequence between Modena and UDI has completely changed. It is now a merge between the previously released Modena task sequence and a standard MDT Client Task Sequence. The task sequence is now structured in such a way to handle MDTs Refresh and New Computer scenarios for example, but still includes a master group, called execute task sequence, a group for cancelling the wizard, and a failover group for gathering logs. There are many differences in-between that I plan to blog about in future posts.

When Should I Use LTI, ZTI, or UDI?

With MDT there used to be two different deployment methods: LTI (Lite Touch Installation) and ZTI (Zero Touch Installation). Now with UDI (User Driven Installation) you may wonder in which scenario should I use each of these deployment methods. The chart deploy walks you through when each method should be used.

• If you do not have Configuration Manager there is only one option and that is LTI
• If you have Configuration Manager and do not require user interaction then use ZTI
• If you have Configuration Manager and require user interaction then use UDI

How Do I Get It and What Else Should I Know?

Keep following this blog as I will be posting new information about UDI and OSD.

Join the MDT Update 1 Beta. (Live ID required.)

To see the official blog post for the release click here

Learn more about MDT 2010 and its components by visiting the MDT site on TechNet.

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.

Microsoft Deployment Toolkit 

Download MDT 2012 Update 1 Beta 1 now!

Microsoft Deployment Toolkit 2012 Update 1 Beta 1 is now available for download! This release expands your deployment capabilities with support for the latest released software, including Windows 8 Release Preview, Windows Server 2012 Release Candidate, and System Center 2012 Configuration Manager SP1 Community Technology Preview.

What's New

Build Your Own Page (BYOP)  support for User-Driven Installation (UDI)

enabling IT pros to create new wizard pages using simple drag-and-drop operations for a few controls – no
coding required.

DaRT 8

Support for using the DaRT 8 Beta with the Windows 8 Release Preview version of the Assessment and Deployment Kit (ADK).

Integration with System Center Orchestrator

Enabling task sequences to invoke Orchestrator runbooks at any point in the deployment process.

Support for PowerShell 3.0

making it easier to run PowerShell scripts inside task sequences on Windows 8, Windows Server 2012, and Windows PE 4.0.

And much more

Download MDT 2012 Update 1 Beta 1 now

Tell
us what you think!
We value your input; this is the perfect opportunity to be heard so send us your feedback through the Connect site. 

Already using the
Microsoft Deployment Toolkit? We’d like to hear about your experiences.

If you are not already a member of the MDT Connect program, click here to join.

When enabling the hyper-v role during a task sequence,  using ServerManagerCMD.exe the role requires a reboot... well actually 2 reboots. This causes problems with the task sequence. The task sequence will handle the first reboot fine but when the machine comes back up it will reboot the machine outside of the task sequence's control. There are a number of other ways that you can enable the Hyper-V role, which are outlined in this blog. As this blog points out there are several problems using a number of these solutions for setting the Hyper-V role in a task sequence.

The best way that I have found to set the Hyper-V role in a task sequence is to run Dism to install the role. During the task sequence after the image has been applied and prior to running the setup and Config Mgr step run the following:

cmd /c Dism.exe /image:%OSDTargetDrive%\ /Enable-Feature /FeatureName:Microsoft-Hyper-V /LogPath:%_SMSTSLogPath%\Hyper-V.log

After this step has finished run the following:

cmd /c Dism.exe /image:%OSDTargetDrive%\ /Enable-Feature /FeatureName:Microsoft-Hyper-V-Management-Clients /LogPath:%_SMSTSLogPath%\Hyper-Vclient.log

In the above commands %OSDTargetDrive% is the volume that the image was applied to and Dism will treat this an offline image. %_SMSTSLogPath%, where the DISM log will be written, is the same location that the task sequence log will be written to.

Overview

In Consolidating Your Task Sequence Part 1: How to Combine WIM images into one I discussed how you can combine your images into one. This blog talks about how to apply the appropriate index from a task sequence when a WIM file has multiple indexes, such as Win7 x86 and Win7 amd64.

Why

Why would I consolidate my images into one:

• Saves server side footprint
• Consolidate your images and task sequences.
• Reduce the amount of time and room for error when making changes as you will only have to make a change in one place rather than multiple.

How

The simple answer is to use the built in task sequence variable called OSDImageIndex to apply the right image. This variable must be set with the appropriate number that corresponds to the index of the image you are trying to apply from a WIM. The UDI Wizard Designer which will be available as part of UDI, formally known as Modena, will be available when MDT 2010 update 1 Beta ships. However, an older version of the designer, along with other Modena tools, is available now from our connect program. The designer allows an administrator to create the XML configurations that are run with the OSD Setup Wizard also available with Modena and soon to be with UDI. So an administrator can simply set up his WIM image as was outlined in Consolidating Your Task Sequence Part 1: How to Combine WIM images into one and then use the designer to set the image index to the corresponding number. He will also need to give each index a friendly name and set the appropriate architecture for each of the indexes. An example of which can be seen in the below screenshot.

After the administrator has created and saved his XML configuration from the Designer, he can use it as part of the deployment by making sure that OSDSetupWizard.exe points to the XML file using the “/xml:” switch. As part of the deployment, based on the image that an end user selects from the drop down the OSDImageIndex variable will be set with the number that corresponds to the image that was selected. In the screenshot below this would be index 2 if the administrator set it as is seen above.

When the task sequence gets to the “Apply Operating System Image” step it will use the OSDImageIndex variable to determine which index to apply out of an image. Because the variable is set, the task sequence will disregard whatever image index is selected on this task sequence step and apply the index that was set in the OSDImageIndex variable instead.

For more information about this and related variables please check out this page: http://technet.microsoft.com/en-us/library/dd252753.aspx.

Related Blog Posts

Consolidating Your Task Sequence Part 1: How to Combine WIM images into one

There hasn’t been a release of UDI since MDT 2010 Update 1 and with a complete redesign of the designer and wizard you may not recognize it other than the name on the home page of the designer.Chris Adams has put together a good blog post explaining the goals that we came up with when we first sat down to decide what we were going to build for the next version of UDI. The Beta product actually ended up being very close to what our goals were. In this blog post I will explore at a high level the new features and functionality that are available with MDT 2012 Beta 2 UDI Designer and in later blog posts I will explain those and additional features in more depth.

The UDI designer has been rewritten from the ground up making a number of new features available along the way. The layout of the designer has completely changed with a more modern look and feel making use of a ribbon, drag and drop features, as well as making a number of other usability improvements over MDT 2010 Update 1 version. In this section I will layout at a high level the new features and functionality of the designer.

Additional Scenarios

Before we talk about additional scenarios lets get some terminology out of the way which will make more sense when I describe the flow below as well as the wizard in later posts.

• Scenarios: A scenario in this context is tied to a type of deployment, such as New Computer, and is made up of one or more stage.
• Stage: A stage is comprised of a set of pages, resides under a scenario, and is what is specified when running the wizard which I will talk more about in the wizard section below
• Page: A page is pretty self explanatory. Pages are what get configured from the designer and added to stages for presentation from the wizard.

Previously UDI only really offered 2 scenarios, Bare Metal and Refresh, for deployments which were really the same flow of pages just with a few small tweaks. That is changing with MDT 2012. There are 3 scenarios available from the designer out of the box, with one or more stage(s) under each scenario. UDI now offers the Replace scenario in addition to Refresh and Bare Metal, although the Bare Metal scenario is renamed to the New Computer scenario to align with MDT’s terminology. A scenario can have multiple stages under it for example the New Computer scenario has NEWCOMPUTER and NEWCOMPUTER.Prestaged which I will talk about in more detail when I outline stages under the Wizard.

Now I mentioned that there are additional scenarios that are available out of the box, but what about custom scenarios. There is a way to do this which I will explore in future blog posts, but if you want to add additional scenarios to the existing ones this cannot be done currently through the designer. If this is functionality that you think that you would take advantage of, please either leave me a comment, provide feedback through Connect or on the MDT 2012 Beta 2 survey that should be coming out shortly.

Page Library

The Page Library shows all the pages which are currently loaded in the designer. When loading a configuration file all of the available pages which are defined in the configuration file are displayed to the page library. The page library shows the page types in alphabetical order and each of the page instances under the page type. For instance you may want 2 different welcome pages for 2 different scenarios or stages in which case the Welcome page type would show in alphabetical order in the page library and then under the Welcome page type it would show the 2 different Welcome page instances. Additionally each page instance will show how many times it is used throughout the flow on the right side of each page and when you hover over a page in the library it shows a picture of the page as well as showing which stages that page is used in.

Flow

Now the administrator can see the layout of all the available scenarios that will be made available to end users during deployments in a visual flow. Administrators can also drag and drop pages from the page library to the flow. The number on that page will then be incremented and updated to show all of the stages that the page is located in from the page in the page library. Additionally a page can be rearranged by dragging and dropping it in the appropriate spot from within the stage the page is located in. I will try to put together a few videos showing this in future posts.

Scenarios can be expanded to see the stages and pages contained in each scenario. A picture of each page is displayed along with a number representing the order each page will be displayed in during runtime of a stage. Stages can be previewed to make sure that the pages contained in that stage are configured correctly by selecting the Preview option on the right side of the stage. Additionally the wizard can be displayed in preview mode by first selecting a stage and then selecting Preview in the ribbon.

Extensible Designer

I will devote a future blog post to this topic but I would like to mention that this new version of the designer can be extended by adding in additional pages into the designer. If you would like to extend the designer and wizard with additional pages this can be developed using the SDK, the documentation for which is currently in the works, but which a sample of is currently available. To get a head start please check out the SDK directory directly under the Microsoft Deployment Toolkit installation directory. The SDK contains code for a couple of simple sample pages which can be compiled for use with the designer, for configuring which locations to make available in a dropdown list, and for use with the wizard, for allowing the end user to select from among the configured locations from the dropdown on the page.

Tighter Integration with Your Environment

There are a number of improvements that make it easier when needing to work in conjunction with Configuration Manager and your AD environment. At a high level these include:

• Validation to determine the site server connection version. This is particularly useful when working with package/programs as well as the new App Model available from Configuration Manager 2012.
• Support for retrieving Operating System Images (WIM files) and Operating System Installers (Setup Bits) directly from your Configuration Manager site server.
• Easier configuration of domains and OUs by connecting to AD. This functionality was in 2010 Update 1, however it has been improved in this version.

I will be delving in-depth into the features and functionality that I mentioned in this post as well as into others that I did not mention. In my next post I will explore at a high-level the new features and functionality that is available from the wizard so keep posted.

In this post the basics for finding and hiding a window will be shown in Visual Studio 2008 (C#). As previously mentioned in Snazzy OSD status with BGInfo, hiding the Windows 7 Setup window will be demonstrated.

Creating and Compiling

First, create a simple Console Application under the C# tree.

Next, copy and paste the code sample below.

using System;

using System.Collections.Generic;

using System.Text;

using System.Runtime.InteropServices;   // Namespace for Import DLL

namespace HideSetupWindow

{

    class Program

    {

        static void Main(string[] args)

        {

            // ####################

            // | Find Window

            // ####################

            int hwnd = WinAPI.FindWindow(null, "FirstUXWnd");

            Console.WriteLine("FindWindow API Result: " + hwnd.ToString());

            // ####################

            // | Hide Window : 0 = Hide, 1 = Show

            // ####################

            if (hwnd != 0) WinAPI.ShowWindow(hwnd, 0);

        }

        internal static class WinAPI

        {

            // ----------------------------------------------------------

            // FindWindow : http://msdn.microsoft.com/en-us/library/ms633499.aspx

            // ----------------------------------------------------------

            [DllImport("user32.dll", SetLastError = true)]

            internal static extern int FindWindow(string lpClassName, string lpWindowName);

            // ----------------------------------------------------------

            // Show Window : http://msdn.microsoft.com/en-us/library/ms633548.aspx

            // ----------------------------------------------------------

            [DllImport("user32.dll", SetLastError = true)]

            internal static extern int ShowWindow(int hwnd, int nCmdShow);

        }

        // ####################

        // NOTE: Any of the following will work...

        // ####################

        // ----------------------------------------------------------------

        //int hwnd = WinAPI.FindWindow("FirstUXWndClass", null);

        //int hwnd = WinAPI.FindWindow("FirstUXWndClass", "FirstUXWnd");

        //int hwnd = WinAPI.FindWindow(null, "FirstUXWnd");

        // ----------------------------------------------------------------

    }

}

Finally, compile the application.

Tips & Tricks

Use the code sample below to hide an instance of Notepad. Two points worth mentioning:

1. The Class Name for Notepad windows is “Notepad”; all Notepad windows will share this common class name.
2. The Text or Window Name for Notepad windows may vary for each window; for example, a new instance of Notepad will usually contain the window text “Untitled – Notepad”

Parameter 1 is the Class Name. Parameter 2 is the Window Name. Searching on either (or both) parameter is possible:

/* Sample 1 */ int hwnd = WinAPI.FindWindow("Notepad", null);

/* Sample 2 */ int hwnd = WinAPI.FindWindow(null, "Untitled - Notepad");

/* Sample 3 */ int hwnd = WinAPI.FindWindow("Notepad", "Untitled - Notepad

In parting, a very accommodating utility for learning and working with this type of window manipulation is Winspector.

This blog post was originally created by Michael Schmidt.

As part of ConfigMgr's move towards user centric, ConfigMgr User Device Affinity(UDA) allows you to define a relationship between a user(s) and a device. This can be done through the ConfigMgr console, but it can also be done as part of an OS deployment. John Vintzel has posted a blog discussing this concept here. Additionally there is a related topic on TechNet here. These gives a good overview of the process, but I would like to discuss this concept further in this blog post as it applies to User Driven Installation (UDI).

As part of MDT 2012 UDI there is a new wizard page for setting User Device Affinity as part of the task sequence as well as a designer page for configuring the UDA page. The User Device Affinity wizard page is very simple. It has a checkbox allowing you to select whether UDA should be set or not and a textbox allowing you to set a comma delimited list of users.

Don't be fooled into thinking that UDA is simple by the simplisity of this page however. There are a number of criteria that must be met in order to have a user set as a primary user of a device automatically as part of the OS deployment process.

1. Only works with NewComputer

The first thing to note is that this only works with new computers. When I say new computers I don't just mean the new computer scenario I mean that a new computer object will be setup in ConfigMgr as part of the OS Deployment. An existing computer object cannot be used as part of the deployment otherwise it will not work and the only way to set UDA is from the console.

2. Set Boot Media/PXE settings

Remember this is only for new computers so the deployment will occur using a PXE service point or bootable media. As such there is a Primary User Assignment setting that must be set on the PXE service point or bootable media. These can be set to any of the following settings

Do Not Allow UDA

Allow UDA Pending Administrators Approval

Allow UDA with Auto-Approval

In order to have the primary user setup automatically as part of the detployment you must set this setting to Allow UDA with Auto-Approval.

3. Users added as a primary user must be a known user

The users added from the UDA page of the wizard must be known users in ConfigMgr. Either set Active Directory User Discovery or import the users through the console

4. Set SMSTSAssignUsersMode

The SMSTSAssignUsersMode task sequence variable must be set in the task sequence prior to the wizard loading. This setting can be set to any of the follwing settings:

Auto: The task sequence automatically creates a relationship between the user and destination computer and deploys the operating system.

Pending: The task sequence creates a relationship between the user and the destination computer, but waits for approval from the administrative user before the operating system is deployed.

Disabled: The task sequence does not associate a user with the destination computer and continues to deploy the operating system.

In order to automatically set the user account as a primary user of a machine SMSTSAssignUsersMode must be set to Auto. If this isn't set prior to the wizard loading in the task sequence the wizard will set this variable to Pending.

5. Set the Users(s) from the UDA page of the wizard

Finally set the users which you would like to add as primary user through the UDA page of the wizard. This can be a comma separated list of users using the folling as an example: domain\user, domain\user. The contents of the textbox will be set as the value for the SMSTSUdaUsers variable. It is important to note that we have attempted to set an FQDN for the domain such as Contoso.corp.forest.com\user and it did not correctly set the user as a primary user of the device.

I hope that gives you a good overview of how to setup UDA as it pertains to UDI. Next we will be discussing how this setting is used with UDI's AppInstall.exe to install applications.

Wizard

The wizard has been rewritten as well as the designer to give it a new look and feel, make it more testable, and make it extensible. When running the wizard you will notice the available pages on the left hand side are highlighted as you navigate through the wizard. These pages and the stages that they run in are defined in the stage the wizard is running in. In this post I will talk a bit about the wizard and at a high level the new features and pages available which the wizard offers.

Stages

Stages, as I defined in a prior post about the designer, is comprised of a set of pages and resides under a scenario. All, but the Refresh scenario have multiple stages. As all scenarios and stages are in the same configuration file the wizard can now be run with the new /stage switch. The UDIWizard.wsf script, which is used to run the wizard from the UDI task sequence, automatically determines which stage to run from the configuration file based on the environment that the wizard is in. The pages for each of the stages are defined under each stage in the configuration file and are displayed in the designer. The available stages are outlined below:

NEWCOMPUTER

NEWCOMPUTER.Prestaged

REFRESH

REPLACE

REPLACE.WinPE

Note: Running stages with the wizard is case sensitive

New Pages

There are several enhancements to both the existing wizard and designer pages, but in this section of this post I would like to highlight the new pages available in MDT 2012 (Beta 2 and above) and discuss briefly some of the changes to the Software page formally known as the Application page.

User device Affinity

User device Affinity allows for a primary user to be associated to a device and is explained in more detail here. However, the wizard page allows for specifying a user account to be set as a primary user of the device being imaged. There is a bit more to setting UDA than just setting a user account from this page however so please take a look at the blog post which I just mentioned. Additionally I will cover this in more detail as it pertains to UDI in a future blog post.

BitLocker

The BitLocker page, which has been modeled around MDT LTI’s BitLocker page, allows for enabling BitLocker with various settings. It allows for setting various TPM settings or a startup key, whether to store a recovery key in active directory or not, and whether to wait for encryption to complete. Because the UDI page offers the ability to set a PIN and the in the box BitLocker task sequence step does not - understandably so as you may not want to make a user type in their PIN during reboots in a task sequence - we ended up using the same MDT script for setting up BitLocker as LTI does. We decided that we would leave it up to the administrator to determine if he wants to make this option available or not. Remember you can disabled any of the controls on a page from the designer so users can’t select them.

User State

The user state page allows for selecting where to capture user state to or restore user state from. User state can be captured or restored locally, to or from a USB drive, and to or from a network location. If either the USB or Network options are selected then a user name and password must also be specified. The user name and password are used to hash the folder that the user state will be captured to, or in the event of restoring which folder to restore it from. Additionally, during a capture the password is used to encrypt the user state by using ScanState.exe with the /encrypt /key:KeyString parameters and during a restore decrypt the user state by using LoadState.exe with the /decrypt /key:KeyString parameters. For more information about ScanState and LoadState please see the TechNet pages on ScanState Syntax and LoadState Syntax.

Not all of these options are available in every scenario as logic has been built in to display the particular options based on the following: 

• Mode: This is can either be set to restore or capture, and is controlled by the config file which can be set from the designer for this page.
• WinPE: Whether the UDI Wizard is running in Windows PE or the full operating system which is determined based on whether the _SMSTSInWinPE task sequence variable is set to TRUE or not.
• Format: Whether the format checkbox is set from the volume page.

Note: The built in logic in the wizard will trump the lock and unlock settings for radio buttons from this page. You can further lock a radio button down if it is normally enabled in a particular environment, but setting a radio button to enabled will be ignored if the built in logic determines it should be locked in a particular environment.

Progress

The progress page is pretty much the same page as the preflight page except it has a progress bar on it. The progress bar on the page is used to display the progress of the ScanState process, which is used for capturing user state. It uses scanstate’s progress log to get the percentage of the completed process. If there is a problem for any of the tasks, including running the USMT task, there is a retry button that the end user can use to run all the tasks on the page again.

Software Page

Not that this page is new, but it has changed so much that I thought that it was worth mentioning a few things. First off because Configuration Manager 2012 now offers package and programs as well as Applications (using the new App Model) we decided to offer both from the software page of the wizard. To end users software items will display the same as they won’t need to know the difference between the two only that they actually installed at the end of the day. In the designer the icon which represents an item does display different between a package/program and an application as administrators may want to know the difference.

Additionally the Software Page allows you to nest groups. In the 2010 update 1 wizard there was a top most group and then just 1 layer below that group which was available. Now you can add in groups at the root level and then add in multiple groups under a root group allowing for 2 layers of applications.

Preview

The latest version of the wizard actually runs without the /preview switch outside of a task sequence. However, it is best to run the wizard in preview mode in this scenario so you won’t be blocked by things such as preflight checks which fail. You can run the wizard directly from the designer by either selecting preview from a stage or by selecting a stage and then selecting preview from the ribbon item.

There is so much more to discuss about UDI, so keep posted as I’ll keep posting.

Getting Started

As I mentioned in my previous post, Package Conversion Manager (PCM) allows for converting packages and programs into applications and deployment types in System Center Configuration Manager 2012. Packages must first be migrated from a 2007 site to a 2012 site. There is a migration feature built into Configuration Manager 2012 that allows packages to be migrated from 2007 to 2012. I will see if I can’t dig up some good information about migration and post some links in a future post. However, once you have migrated your package objects and installed PCM then it is just a matter analyzing your packages in order to determine which readiness state each are in, and then converting those packages that are in the appropriate readiness state. I will go over the different readiness states and the rules that determine those readiness states in a future blog post as this post is just a high level introduction to get you started with Package Conversion Manager.

Readiness Columns and Ribbon Items

Once PCM is installed on a machine that has the Configuration Manager 2012 console installed your console will have a few new ribbon items available from the packages node as well as right click actions. Additionally a Readiness column will be populated with Readiness information for each package and a Package Conversion Manager Overview sub node will be available which is a mockup of the information that will be made available in the future. In this version of PCM the readiness column isn’t turned on by default so you will need to make it available by right clicking on the available columns and selecting the readiness column. Once you do this you should see that all of the packages are in the “Unknown” readiness state. This simply means that they haven’ t been analyzed yet.

Package Analysis

PCM can currently analyze a single item or in bulk by selecting all of the items that you would like to run the analysis on. Because we are integrated into the Configuration Manager console we adhere to the permissions available through RBA. So only the packages that you have permission to will you be able to analyze. Once you have selected the appropriate items to analyze you can either run the analysis by selecting the “Analyze Package” ribbon item or right clicking and selecting “Analyze Package”. Once the analysis completes your package should be in one of three states: Automatic, Manual, or Not Applicable. You can see these readiness states from the screenshot above. For CTP1 we can only help you with the Automatic packages. Don’t fear however as we are working on helping you convert over your packages that are marked as “Manual” in our CTP2 release.

Package Conversion

Once you have analyzed your packages you can now convert those packages that are marked as Automatic. By selecting one or more package that are marked as automatic you can initiate the conversion process from the Package Conversion ribbon item or by right clicking on the selected packages and selecting Package Conversion. A dialog will be displayed confirming if you would like to continue with the conversion process. From this dialog you can either remove the packages that you don’t want to convert or you can continue forward. Once you select OK you should see a progress bar of the conversion process and then finally a summary screen. The summary screen will display if the selected packages were successfully converted or if there were any errors. Select OK and then navigate to the Applications node to confirm if those packages have been converted properly.

Pretty simple right? I will delve into more detail of Package Conversion Manager including analysis states and rules, as well as more information about the conversion process in future posts. In the meantime I hope that this helps you get started with Package Conversion Manager.

Release

The long awaited release of MDT 2010 Update 1 is finally here. After making several fixes over the Beta version, MDT 2010 Update 1 released earlier this week.

To find out what is different between Modena and UDI, and when to use UDI, LTI, or ZTI please see the Beta release link here.

To find out more about MDT 2010 Update 1, please the visit the TechNet Library or the MDT 2010 TechCenter. In addition to these links you can download MDT 2010 Update 1 from here.

In an effort to inform those who are currently using or are planning on using UDI about the features available in MDT 2012 we have put together a video series covering UDI. I know what you are thinking: "But Update 1 Beta1 is already available". These videos still apply to Update 1 and I will point out any changes that are different between the two.

In this video we discuss how to configure the Replace scenario for UDI which allows you to capture user state and data from your old PC and replace it on your new PC. The first part of the Replace scenario is configured in 2 stages called Replace and Replace.WinPE while the second part of this scenario uses one of the 2 New Computer stages to restore user state during an OS deployment to a New PC. For more detail on the New Comptuer stages discussed in this video check out the following blog covering the New Computer scenarios found here.

As part of this video we talk through what the minimum pages needing to be configured for the Replace stages. This really boils down to configuring the user state page if you would like to make capturing user state to network locations available to your end users. There are a number of factors which affect the user state page such as the mode the page is set to (capture or restore), environment the wizard is launched from (WinPE, or the full OS), and whether the format checkbox is checked or unchecked. These are outlined in this video and will be covered in more detail in a later blog. Additionally the user state page encrypts the user state data and hashes the directory the user state page is captured to when capturing to a USB or network location which is also discussed in this video.

In addition we discuss that you will have to have your applications configured and set with mappings if you would like to discover your installed applications on your old PC and have these default selected for reinstallation during a deployment on your new PC. For more information on how to configure software installation with UDI and setup Application Discovery to discover software for reinstall checkout the Application Discovery video in the UDI Video Series.

To help you get started in configuring the Replace Scenario please check out this video:

Configuring-MDT-2012-UDI-Replace-Computer-Scenario

One thing that was left out of this video was the option to prompt and format the USB drive from the user state page. This ensures that only one set of user state data is on the USB drive when capturing and restoring during an OS deployment. These options are available for configuration in the USB Combo Box on the User State (Select Target) page in the designer.

I hope you enjoy this video and please check back to see additional videos covering User Driven Installation.

Updated in MDT 2012 UDI Update 1: One of the things that was enhanced in Update 1 UDI was the ability to seperate the credentials used for connecting to a network location and the credentials used for encrypting the data and hashing the directory in which it is stored. In MDT 2012 these weren't seperated and caused problems when attempting to image multiple machines at the same time while using a network location for capturing and restoring user state. I will be putting together a seperate blog post on how this is configured in the future.

Release

MDT 2012 Beta 2, including the new version of User Driven Installation(UDI), is now available for download. To participate, register for MDT 2012 Beta 2 at Microsoft Connect.

MDT released 2012 Beta 1 sometime back which included support for System Center Configuration Manger 2012 as well as improved Lite Touch user experience, and behind-the-scenes enhancements for partitioning, UEFI, and user state migration. There have been a number of improvements made in these areas for Beta 2 as well as providing DaRT support and integrating Security Compliance Manager (SCM) for applying GPO packs into the MDT task sequence.

MDT has not released a new version of User Driven Installation (UDI) since MDT 2010 Update 1, but that is changing with this Beta 2 release. Many of UDI’s components have been completely rewritten and we think that this new version will be a game changer for user driven deployments. I will explore some of the highlights in this blog post, but look for future posts to delve in depth into the new features and functionality made available with MDT 2012 UDI.

To participate, register for MDT 2012 Beta 2 at Microsoft Connect.

What’s New in MDT 2012 UDI?

MDT 2012 UDI has a number of new features. At a glance these include:

• Extensible wizard
• Extensible designer
• Support for new scenarios
• Visual flow which allows you to see and rearrange the layout of your deployment scenarios by dragging and dropping pages
• Support for Configuration Manager 2012’s new App Model Apps
• A number of new wizard and designer pages
• A designer which is more tightly coupled with Configuration Manager over the previous version making it much easier when adding things like WIM files or Applications
• A configuration file which contains multiple scenarios
• Wizard support for running stages from the scenarios

I will be covering these topics and more in future blog posts.

How Do I Get It and What are the Next Steps?

So what are you waiting for? Follow the steps below to participate in the MDT 2012 Beta 2 program.

1. Join the MDT 2012 Beta 2 Program
2. Test the tools in your environment and then provide feedback through Connect and direct support issues through SATfdbk@microsoft.com
3. Learn more about UDI as I provide in-depth information in future posts through my blog
4. Learn more about MDT in general by connecting to the MDT TechNet site and the official MDT team blog

The Problem

If you are using MDT 2012 Update 1 UDI and are configuring language settings, you may have run into the problem setting up your User Locale. In MDT 2012 Update 1 Beta the UDI wizard was setting InputLocale when it should have been setting UserLocale. As this was found at the last minute before releasing there was a workaround put in place in order to set the appropriate task sequence variable. Rather than changing this variable in compiled code which is a bit more costly and risky the workaround was added to the UDI Wizard script wrapper (UDIWizard.wsf). The script wrapper would simply read what the UDI Wizard set the InputLocale task sequence variable to once it exited and then set UserLocale to that same value.

Why is this a problem? It is a problem because the wizard was fixed in the released version of MDT 2012 Update 1, but the script wrapper was never fixed to remove the line which sets UserLocale with the value of InputLocale. So what does this mean? It means that the wizard sets the UserLocale correctly based on what the end user selects when the wizard exits, the script wrapper will then read InputLocale, which is no longer set, and sets UserLocale with this value. Thus UserLocale is always set to blank.

The Solution

Luckly this problem is very easy to fix. You simply need to modify the script wrapper, udiwizard.wsf file, in the toolkit package under the scripts directory and either comment out or remove the following line:
oEnvironment.Item("UserLocale") = oEnvironment.Item("InputLocale") 

Don't forget to update your distribution points on your MDT Toolkit package once you make this change.

Additional Notes about Language Settings

Variables used on the language page:

• Language pack to install: UILanguage
• Time and Currency Format: UserLocale
• Keyboard Layout: KeyboardLocale
• Timezone: OSDTimeZone

Language pack to install

Customer's have asked how do I default language options to the default language set on a machine. UDI doesn't provide any detection for determining which language had been set on a machine. However, it does provide a way to default to a language setting. So if you have added logic to a script you can simply set the appropriate task sequence variables prior to the wizard loading in order to default to those settings. The one thing to call out here is that the values used in task sequence variable must match the case of the values in the dropdown list in order to default to a value. In other words if you want to default to French for a language pack to install that language pack must be available in the list, and you must set UILanguage to FR-FR not fr-FR.

Keyboard Layout

Additionally if you wanted to set the keyboard layout to French for example you should set the KeyboardLocale variable to either 040c:0000040c or 0000040c. Do not set the variable to the following format 0x0000040c.

In my previous post I gave an overview of what Package Conversion Manger (PCM) was. In this post I will cover the various readiness states and the rules that determine each of the readiness states.

Readiness states

There are 5 readiness states which are shown in the slide below along with their definitions.

Automatic, Manual, and Not Applicable Readiness Rules

As unknown and converted are pretty straight forward lets concentrate on the rules associated with automatic, manual, and not applicable.

1. Package Contains only 1 MSI

Essentially this means that they only have 1 program and it must be pointing to an MSI. The reason for this is if it contains more than one program PCM won’t be able to determine your Deployment Type preference. If you don’t have a program pointing to an MSI then PCM won’t be able to determine your detection method.

The one exception to this rule is if you have an install program and an uninstall program. Because we get the uninstall from the MSI and discard the uninstall program.

2. No Unconverted Dependencies

If a program has a dependency setup that dependency will need to be converted first. Once the dependency is converted we can setup the link between the dependent app and the dependency app on conversion of the dependent package.

3. Content is Accessible

Content must be accessible in order to get to the MSI and get the detection method.

4. Must have content

Must have content: The setting “this package contains source files” on the package must be checked and filled out with a valid path.

5. Is a Software Dist Package

There are many types of packages in Configuration Manager. We check the type of package and only analyze/convert software distribution packages.

6. Contains at least 1 Program

If it doesn’t contain any programs then it is a just a package possible with source files and is not applicable.

Readiness States and Corresponding Rules

In this section we will take a look at the Automatic, Manual, and Not Applicable states and which rules have to be true in order for a package to be in a particular readiness state.

Automatic Readiness State

In order for the package to be in the “Automatic” readiness state, which is the only readiness state that CTP 1 can convert, all rules (1 - 6) have to be true.

Manual Readiness State

In order for a package to be in the “Manual” readiness state rules 4, 5, and 6 have to be true. Additionally if rules 1, 2, or 3 are not true, then the package will be in the “Manual” readiness state. I would like to reiterate that in the CTP 1 release PCM does not help convert “Manual” packages. We are working on adding support for the Fix and Convert feature (converting manual packages) in a future release.

Not Applicable

If rule 4,5, or 6 are not true then the package will be in the “Not Applicable” readiness state.

The MDT 2012 UDI Designer has a new concept called the Page Library. The Page Library allows you to see all of the page types and instances that are available from the configuration file you are editing. Prior to MDT 2012 UDI if you wanted a page with different information you had to have multiple configuration files. However, as is described in the video below with MDT 2012 UDI, you can have one or more instance for each page type. By allowing multiple page instances, each configured differently, UDI supports the ability to run all scenarios from a single configuration file which is one of the key goals that we had in mind for MDT 2012 UDI.

Another key goal for MDT 2012 UDI was the ability to configure once and use in multiple places.This is accomplished between the Page Library and the designer flow. The Page Library allows you to configure each of the instances of a page and also drag and drop these page instances into one or more of the stages in the flow. To see more information on the page flow please take a look at my previous blog post on the flow. There are several right click and ribbon item actions that you can take from the flow which can affect page instances in the Page Library. Let's walk through these as well as some of the other aspects of the Page Library. 

Page Instance Count

The Page Library tells you how many times each page instance is used throughout the flow of the loaded config file on the right hand side of the page instance as can be seen in the picture below. As you drag and drop pages from the Page Library into the flow or remove page items from the flow the number will increment or decrement accordingly.

Page Hover

The Page Library displays a picture of the page and tells you which stages of the flow that page is used in. This should hopefully help to identify which page you are about to either configure or drag into the flow, as well as help identify where in the flow a page is being used. If you want to remove a page from the Page Library this will help you identify which stages you will need to first remove those pages from before removing the page from the Page Library. Additionally it should help you understand that configuring or editing the page instance will mean changing the configuration for each of the stages that the page resides in.

Page Configuration

You can configure a page instance by either double clicking on it in the Page Library or flow or by selecting the page instance from either the Page Library or flow and then selecting the configure tab next to the flow tab. This will display the page editor which will allow you to start configuring each of the controls and fields on the page in the desired manner.

Add and Remove Pages

Page instances can be both added and removed from the Page Library. In this section I will walk you through both.

Adding Pages

From the Page Library you can add in additional instances of one of the pages provided natively with MDT 2012 UDI or if you have taken advantage of the SDK, which I will blog about later, you can add in your own custom editor for the custom wizard page which was built. This can be done by selecting the "Add Page" ribbon item from the Page Library ribbon group or through a right click action.

Selecting the Add Page ribbon item or right clicking in the flow and selecting "Add Page" will bring up the dialog below. From this dialog you can select the page type for which you would like to add an instance of. The display name and page name will be filled in automatically, but you can change these to whatever you would like. However, the page name provided must be unique otherwise the Add New Page dialog will block you from selecting OK.

Removing Pages

If a page instance is no longer in use it can be removed from the Page Library by using the "Remove Page" ribbon item in the same Page Library ribbon group which "Add Page" can be found. A page instance can only be removed form the Page Library if all instances of that page have been removed from the flow. If all page instances have not been removed from the flow the following error will occur when attempting to remove a page from the library:

 Simply use the "Remove Item" ribbon item in the Flow Designer ribbon group or "Remove Item" right click action in order to remove each of the page instance from each of the stages in the flow.

Once the page item has been successfully removed from all stages in the flow and the page instance shows 0 usage you can now select "Remove Page" in order to successfully remove the page instance from the Page Library.

 I hope that this blog has helped you understand the UDI Designer's Page Library better. Please visit again as I will be discussing additional functionality of the UDI Designer, Wizard, and other features that UDI provides.

Overview

For those times when you need to find out what a variable is set to while running a task sequence, you can run a simple script along with the variable name that you would like to check the value for. As long as the task sequence environment is available and the variable’s value is set to something other blank, it should return the value.

Code Sample

Dim sTSVar, sParameters, oTSEnv, Wsh
Set oTSEnv = CreateObject("Microsoft.SMS.TSEnvironment")
Set Wsh = CreateObject("Wscript.Shell")

Main

Sub Main()
    On Error Resume Next

    If trim(Wscript.Arguments.Item(0)) <> "" Then
        DisplayVariables Wscript.Arguments.Item(0)
    Else
        Wscript.echo "No TS variables were passed for the script-" & Wscript.ScriptFullName
    End If
    If Err.number <> 0 then
        Wscript.echo "Error Writing the variable." & Err.Description
    End If
End Sub

Sub DisplayVariables(sParameters)
    Wscript.Echo oTSEnv(sParameters)

End Sub

Runtime Example

Let’s say you named your script readtsvar.vbs. While the task sequence was running you could hit F8 to open a command window and simple run the following:

cscript readtsvar.vbs OSDComputerName

This would return whatever the computer name variable is currently set to.

In today’s post I would like to talk a bit about the Designer Flow. Two key concepts we had when creating the UDI designer were that pages should be configured once and used in multiple locations and visually represented in the logical order in which they will be displayed. The designer flow helps accomplish these goals by first showing you thumbnails of the actual wizard pages in the order in which the pages will be displayed when running a stage and by allowing you to drag pages from the page library and drop the page in the appropriate location in the flow.

In addition to adding pages the flow also allows you to remove a page from a stage and reorder pages in a stage. Additionally you can double click on a page in the flow in order to configure the page. These are all concepts which I will talk through in the video I have put together below.

I have received several emails asking why applications are not showing up in various scenarios even though they have been configured. Depending on the scenario there are a number of reasons why this may occur. In this blog post I will be concentrating on one of the reasons why this may occur.

So you have opened up the designer and have configured the wizard’s configuration file. As part of the configuration you have connected to your site server and added several applications. When you open the wizard in preview mode however the applications don’t show up. Or even worse they show up while in preview mode but they do not show up at times when running through an actual task sequence.

Reason #1: Architecture

One of the main reasons for this occurring is due to architecture. This can be the architecture of the machine or the architecture of the image that you selected. The OSD Designer and UDI wizard gives you the ability to add either x86 and/or x64 applications. This allows for the scenario of only displaying applications to the end user based on the architecture of the target Operating System. If an application only worked on x86 you would not want to show the application to the end user if they selected an x64 target OS as it would fail when it got to the point of installing the application. Additionally this allows for the scenario where there are different programs which installs x86 compared to x64.

In this blog post lets use the example of an Adobe Reader being configured as shown in the below screenshot:

As you can see the 32 bit properties have been filled out but the x64 properties have not.

Scenario 1: Architecture of the image that you have selected

Using the above example this Adobe Reader app will only show up when the end user selects an x86 image. If they select an x64 image then this application will never show up in the list. If the program was meant to run on both architectures then simply attach it to both the 32 bit and 64 bit properties as seen below and it should show up if the end user has selects either a 32 bit or 64 bit image from the wizard’s image drop down as the target OS.

If there is a different program for the same app that runs on an x64 architecture then simply attach it.

Scenario 2: Architecture of your machine

In this scenario the OSD Admin has disabled the volume page of the wizard and only attached the 32 bit program properties. This is a valid scenario as the admin may only have configured one image in the task sequence and may not want to give the end user a choice of the image or any of the other options from the volume page of the wizard.

In the event that the Wizard doesn’t know what the architecture of the target OS will be, which is the case when the volume page is disabled, it will display apps based on the architecture of the machine. Therefore if your machine is 64 bit and the volume page is disabled, any application that was only configured with 32 bit program properties will not be displayed from the application page of the wizard.

One way to get around this is to simply set the OSDArchitecture task sequence variable to the architecture of the image that was configured as the target OS in the task sequence prior to the wizard loading. Of course this will not help you in the event that you loaded the wizard in preview mode. If this is the case make sure that you have set up your applications properly and if need be, simply enable the volume page prior previewing the wizard and then disable it again after you find it is configured to your liking.

Reason #2

I will explain the second reason that your applications may not display, specifically in preview mode, in a future blog post