In MDT deployment I have Bitlocker set to save the recovery key to AD.  However, I am noticing that it is also copying the recovery key to either C: root or the USB flash drive.  How do I control this behavior?

In MDT 2010, the ZTIBDE.wsf script will perform most nasty administrative tasks in the background automatically. That is the beauty of MDT. However, some administrators may wish to control this Recovery File in a manner other than the default, which is to save the file to the C: drive or to a USB Key.

MDT Saves the recovery key even though the administrator told MDT to save the Password into Active Directory, as a backup process, just in case AD was *not* able to save the data to AD.

Disable Key Save

There are two ways to prevent ZTIBDE.wsf from saving the Administrator password in Active Directory.

Either:

Comment out lines 722 – 724 in the ZTIBDE.wsf script. (MDT 2010 Only).

or:

Set the variable in your customsettings.ini file to point to a location that is cleaned at the end of the Task Sequence process:

BDEKeyLocation=%SystemDrive%\minint\

If you don’t save the Password, and the AD backup of the recovery key fails for some reason, you will have no record of the recovery key.

Keith

So, what makes an application installation compatible with MDT (or other scripted installation methods, for that matter)?

Good question.

Microsoft Installer (MSI)

The good!

More and more products are being released lately as MSI packages. Most MSI Packages are easy to automate. For example, I typically use the following parameters:

Msiexec.exe /qb- /l*vx  %LogPath%\<file>.log REBOOT=ReallySuppress UILevel=67 ALLUSERS=2 /i <File>.msi

MDT will easily handle this installation script, and install properly for most MSI packages. Yea!

Non-MSI Packages

However, it is possible that you are working with a custom installation package, or perhaps developing your own. What are the rules necessary to make the package work in MDT?

Rule 1: Provide unattended installs

The install program should have a way to install in a unattended manner. Typically this is done by some sort of command line switch to the installer program or script: /quiet /silent /q whatever. MDT 2010 is a fully automated installation system, and the automation will break if there are any user prompts blocking installation.

For example, if you have a MSI installer package, you can call MSIExec.exe with the /q[bn][-] parameter.

This also equally important for errors. If the install package generates errors, it should provide a method to log the errors to a file for analysis later, rather than prompting the user for interaction with a blocking Error Message Box.

Rule 2: Do not exit until done

The install programs should not exit until all setup tasks have finished. If the setup program returns, yet there are still installation tasks being performed in the background, MDT has no way to determine this. So MDT may continue with the next installation, or perhaps a reboot thus causing conflicts with the installation running in the background.

For example, say you have two installation packages, A.Exe and B.Msi. A.Exe is just a Self Extracting Executable that expands A.MSI to the %temp% folder, and kicks off msiexec.exe. However, A.Exe calls msiexec.exe and doesn’t wait, instead A.Exe promptly exits. MDT does not know what is running in the background, and instead continues installing the next package in the list B.Msi. However since A.Msi is running in the backgound, and MSIExec only allows one installation at a time, B.Msi will fail.

Instead A.Exe should wait until Msiexec.exe /i A.msi has finished.

Rule 3: No rebooting

Sometimes an install package will need to reboot to complete the installation. Reboots, for example, are required to update any file that is already open and in use. It’s a common misconception that you need to reboot to install a device driver, you don’t (unless the driver is in use).

However problems arise if the setup program, when running in an unattended matter, decides to reboot on it’s own, without letting the calling script (in this case MDT), know before hand. It may be a couple of seconds before all processes have a chance to shutdown. It’s possible that MDT may try to continue installing the next program in the order or other cleanup tasks, when it shouldn’t.

Instead, a program should return Windows.h Error Code: 3010 ( ERROR_SUCCESS_REBOOT_REQUIRED ).

This will let MDT know that a reboot is required, reboot the machine, and *then* continue with the rest of the installation packages.

Other Notes

There are a few other notes that I wish I could mention to the authors of installation packages:

• Be aware that the installation may be performed under one user account, but the program may be used under another account. When calling MSIExec.exe, I usually call it with the ALLUSERS=2 property.
• Please make it easy to determine what the unattended/silent installation procedures are. It’s not always easy to determine what the command line parameters are.
• If you have a Self Extracting Executable that calls msiexec.exe, please provide a way to pass logging and other properties (see above) to msiexec.exe.
• Speaking of Self Extracting Exe files that call *.msi packages. Please just provide the *.msi install package, it’s much easier.
• On your web site, please provide direct access to your install packages, rather than going through some web logic. Several populat sites, for example will attempt to offer you *only* the x86 or x64 binaries depending on which platform you are running on, even though I may need both for packaging.
• Please keep the desktop free from links/icons, or provide a property in MSI to disable shortcuts creation on the desktop (I’m talking to you Adobe Reader). I like keeping my desktop clean.
• Speaking of options, please provide ways on the command line to enable/disable most common features.

Keith

Deploying Windows 7 from A to Z.doc
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dfafb346-97dd-4fca-947e-3d9149834da6

It’s a good introductory reference to MDT, SCCM, and Deployment in general.

Keith

There has been several items posted in the OS Deployment community this week that you should definitely know about:

New KB Article published on USMT and MDT 2010.  This will fix issues when migrating items such as Operating System specific settings like network shares, printers, and EFS certificates.  This is a must have fix for MDT 2010!

The Deployment Guys also posted two great stories this week:

802.1x Security for Windows PE!  This has been a much requested feature to add 802.1x security to Windows PE. 

They also posted a great article on how to migrate time zone settings from an existing computer during an installation:

http://blogs.technet.com/deploymentguys/archive/2010/01/11/setting-mdt-time-zone-variables-from-the-source-os-time-zone.aspx

Enjoy and have a great week!

Luckily, this year, we found most Team Members, and we were disconnecting machines from power before the flood waters came. And were also able to get critical machines out before the moving crews came to cart the equipment out to an undisclosed location during repairs.

For example, here is what the office of Mike Niehaus looked like yesterday.

His entire office is now completely bare, and cleaning crews are doing their thing.

It’s been a crazy start to 2010! Hopefully things will calm down and I’ll start posting more soon.

Keith

http://social.technet.microsoft.com/Forums/en-US/mdt/threads

See ya there!

- Tim

In MDT 2010 when I am in the Deployment Wizard I can select the option to join a domain, enter in my domain and near the bottom I have the option to select my OU with a dropdown menu.
Within my control folder of my deployment share I have a file called DomainOUList.xml that has a long list of all the OUs I want our techs to be able to select from. The structure of the file looks something like this:

<DomainOUs>
<DomainOU>OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD</DomainOU>
…

How can I make it look like this:
Laptops / Accounting / Calgary / MYDOMAIN
…

I did some investigation, and discovered that MDT lacks the ability to display Friendly names in the Domain OU selection on the dialog box. This is a problem all the way back to BDD 2007.

Something I forgot to do.

Updated change

It s quick change to DeployWiz_Initialization.vbs to make the wizard display friendly names rather than the OU style.

First we introduce a new set of functions:

Function AddItemToMachineObjectOUOpt(item)   AddItemToMachineObjectOUOptEx item, itemEnd function

Function AddItemToMachineObjectOUOptEx(item,value)  Dim oOption

  set oOption = document.createElement("OPTION")  oOption.Value = value  oOption.Text = item  MachineObjectOUOptional.Add oOption  MachineObjectOUOptionalBtn.style.display = "inline"End function

I personally like to add *EX style function like this, it means that we can reduce the number of changed lines in the code, and keep the old version of the function around for compatibility.

Then later on we modify the code to read the DomainOUList.xml:

iRetVal = oUtility.FindFile( "DomainOUList.xml" , sFoundFile)
if iRetVal = SUCCESS then     For each oItem in oUtility.CreateXMLDOMObjectEx( sFoundFile ).selectNodes("//DomainOUs/DomainOU")

        if oItem.Attributes.getNamedItem("value") is nothing then             AddItemToMachineObjectOUOpt oItem.text         else
            AddItemToMachineObjectOUOptEx oItem.text, oItem.Attributes.getNamedItem("value").value         end if     Next
End if

If the DomainOUList.xml file contains a value attribute in the XML file, it will use that for the value, and the node for the Friendly Name:

<DomainOUs>
 <DomainOU>OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD</DomainOU>
 <DomainOU value="OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD" > Domain\Calgary\Accounting\Desktops </DomainOU>
</DomainOUs>

Full sample can be found at:

DeployWiz_Initialization.vbs

<p>Keith</p>

<address><a href=”http://keithga.com”><span style=”color: #993300;”>Keith Garner</span></a><span style=”color: #993300;”> is a Deployment Specialist with </span><a href=”http://deployment.xtremeconsulting.com/”><span style=”color: #993300;”>Xtreme Consulting Group</span></a></address>

Are you bored? Might be a good utility to build. The PowerShell script [..] posted at http://blogs.technet.com/mniehaus/archive/2009/09/09/sorting-the-contents-of-an-mdt-2010-deployment-share.aspx shows how to rearrange the items in a folder – basically, it just reorders the GUIDs in the group and then saves the modified GUID list. The script only does alphabetical sorting, but some might want to manually rearrange – not terribly easy to do in PowerShell, so it would require a real UI.

For most scenarios, I recommend using Application Dependencies to ensure that applications install in the correct order.

I really didn’t think much of it until recently. When I had some applications that could install stand alone, by themselves, however when both were installed, they needed to be installed in a specific order. If I were creating a CustomSettings.ini file, I would manually ensure that the Applications were placed in order. However, if the user selected the applications from the wizard, then there was no way to ensure the order of the apps unless we modified the order within the ApplicationGroups.xml manually. <yuck>

The blog above shows how application ordering can be done. Simply create a temporary sub-folder, an move the items *in order* to the temporary subfolder and then move everything back.

Solution

This solution should work for sorting both Folders and Application Items within MDT 2010. The application is a simple wrapper around the MDT 2010 Powershell provider, and simply makes calls to move Applications and/or folders using Powershell.

User Interface

The wizard will prompt you for the correct MDT 2010 Deployment Share to use. The deployment share must be visible within the MDT 2010 console on the same machine and using the same user account. If you have not opened any MDT 2010 Deployment shares on this computer and this account, please run the MDT 2010 console, and open your Deployment Share.

When selected, the wizard will display a list of all applications and application folders present on the MDT 2010 Deployment share. You may highlight the Application you wish to move, and use the “Move Up” and “Move Down” buttons to rearrange the order of the application. 

When you are done, press the “Commit” button to run the Powershell script that performs the re-ordering. The applications will not be sorted until the script has finished running.

The MDT 2010 Powershell Provider will do all the necessary work to ApplicaitonGroups.xml on the back end.

You can view the script by saving the results to a txt file.

Restrictions and Limitations

It is recommended that you backup your MDT 2010 deployment periodically,

You can sort the contents of only one folder at a time.

You can not sort Folders within Application entries. Folders are always displayed first.

Link

MDT2010Ordering.zip

License

This tool is provided “as-is”, with no warranties.
You agree not to hold the author, Keith Garner liable for any damages.
This tool is provided “Free of Charge” for “Evaluation” purposes only.
This tool is copyrighted by the author, Keith Garner, and he retains all
ownership, this tool is not public domain.
You are not permitted to redistribute this tool without the express written
consent of the author, Keith Garner.
The license for this tool can be revoked and/or superseded at any time, by the author, Keith Garner.
Of course, you should backup your critical files before running any 3rd party program downloaded off the internet.

By Keith Garner ( http://keithga.com ) – Deployment Consultant – Dec, 2009
Xtreme Consulting Group ( http://deployment.xtremeconsulting.com )
Microsoft Deployment Toolkit 2010 ( http://microsoft.com/deployment )
Copyright Keith Garner (keithga.com), All Rights Reserved.

Normal Process

Before MDT 2010, the variables collected in the wizard for joining the domain were placed directly into the unattend.xml or unattend.txt file. The OS would then perform the join to the domain during (OOBE) Setup.

This tool came about because of several scenarios that could prevent the machine from successfully joining the domain during Windows Setup. For example. If the network did not have DHCP available, Windows Setup is not programmed with the correct Static IP address settings necessary for the Join Domain feature to contact the domain controller. Later on in the Task Sequence Steps, the ZTINICConfig.wsf script would correctly configure the Network Cards, however it was too late for joining the domain.

So we developed a new script ZTIDomainJoin.wsf as a thin wrapper around the WMI call Win32_ComputerSystem:JoinDomainOrWorkgroup(). If the script sees that the machine is already joined to the correct domain, no problem, it continues on, without any errors. However, if the script sees that a request was made to join the domain, and the machine is *not* in that correct domain, then it will attempt to join the domain and reboot. If there is a failure joining the domain, the script will retry up to 3 times before logging a failure and continuing.

Domain Policies that break MDT

Another scenario where this script works well is when a Domain has a Policy that blocks automation. For example a Legal disclaimer at login, or a rename of the local Administrator Account. Either one of these changes will break MDT.

One possible work around in these scenarios is to *remove* the domain join entries in the unattend.xml and unattend.txt templates on your MDT server, or remove the entries in the ZTIConfigure.xml script. Once removed, the ZTIConfigure.wsf script won’t populate the unattend.txt with the correct variables gathered form the CustomSettings.ini file and/or Deployment Wizard.

Then add the ZTIDomainJoin.wsf script near the *end* of the Deployment Task Sequence. Most of the automation will be complete by that point.

Variables

It takes the following variables:

• JoinDomain – Name of domain to join
• DomainAdmin – User Account used to Join Domain (must have permissions to perform Domain Join)
• DomainAdminDomain – Domain of User account used to Join Domain
• DomainAdminPassword – Password used to Join Domain
• MachineObjectOU – Domain OU to join
• DomainErrorRecovery – [Auto|MANUAL|FAIL]
  • Auto – Automatically try to Join to the domain, reboot and retry if there is a failure.
  • Manual – Stop processing the Task Sequence, and wait for the user to manually join the domain.
  • Fail – Stop the Task Sequence if the machine has not joined the domain.

Notes

Fail could be useful if you have applications that *require* the machine to be part of the domain. If for any reason, the machine failed to join the domain, you could call the ZTIDomainJoin.wsf script with the “Fail” Parameter to crash the installation process if the machine is not joined to the domain.

Manual style is a new feature in MDT 2010, where MDT can “Halt” the execution of the Task Sequence, and allow the user the ability to perform manual steps (without the pesky Task Sequence progress bar, which insists that it remain on “top”). Just follow the instructions to restart the task sequence.

Keith

Both of them needed a good jump start getting MDT 2010 up and running in their environments. Like many IT departments out there, they are interested in Windows 7, and MDT 2010 is the de-facto reference design for Windows 7 Deployment.

Medium Sized LiteTouch Deployment

For the Medium Sized Company, we created a MDT 2010 Litetouch system with Windows 7, and packaged up around 50 applications, including the latest versions of: 7-Zip, Adobe Reader, QuickTime, iTunes, Adobe Flash Player, Silverlight, Java Runtime, VLC, Microsoft Office 2007 SP2, Microsoft Office Communicator, Microsoft Live Meeting, Citrix Online Plugin, Rumba, Microsoft App-V Client, and more including several internal tools! We also created a MDT 2010 Litetouch DVD boot media disk for their subsidiary sites, standardizing the desktop images throughout the company.

It then took about a day on-site to configure the server, run the validation tests, and personally go through the documentation and steps with the IT Staff.

Large Litetouch Deployment

For the Large Company, we are moving their existing MDT 2008 Update 1 system to MDT 2010. Remediating any scripts and configuration items as necessary. This is an experienced staff, who just needed an extra set of eyes to help ensure this upgrade goes as quickly and as smoothly as possible. (FYI: They have about 250 Applications defined in MDT 2008)

ZTIWindowsUpdate.wsf

One of the changes we needed to perform today at the Large Company was to fix a couple of bugs in ZTIWindowsUpdate.wsf when calling WSUS servers.

First off, was a fix for the WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS error in WSUS. This is a Large Company, with a well managed WSUS server(lots of updates), and they found out they were hitting the hard 200KB limit during Office Updates. So we needed to code a work around to just call ZTIWindowsUpdate.wsf *again* if the error is returend.

Secondly, since they were *only* using WSUS, we wanted to ensure the the ZTIWindowsUpdate.wsf script did not call Microsoft Update. So I added some code to skip Microsoft Update if the parameter “/SkipMicrosoftUpdate:YES” is on the command line.

We will run some tests tomorrow to ensure it’s performing as expected.

Link

ZTIWindowsUpdate.wsf 

Next

It’s been fun setting up Companies large and small with deployment solutions like MDT 2010! We are available for consulting in 2010, if you would like to get Windows 7 and your MDT 2010 environment up and running quickly, give us a call!

Keith and Tim

Keith Garner is a Deployment Specialist with Xtreme Consulting Group