Bitlocker Recovery Password saved to file January 22, 2010
Posted by keithga in MDT 2010.add a comment
Saw a question posted recently:
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
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupHow MDT does Application Installation January 20, 2010
Posted by keithga in MDT 2010, Troubleshooting, VBscript, Windows 7.8 comments
Been working lately on adding some Application Installation packages to MDT, and I’ve seen some good, bad, and ugly packages.
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
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupGreat Overview on Windows Deployment A-Z… January 18, 2010
Posted by keithga in Announcements, MDT 2010, Windows 7.add a comment
Our friend Jeremy Chapman has written a whitepaper:
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
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupThis week in OS Deployment January 15, 2010
Posted by tmintner in Announcements, MDT 2010.Tags: MDT
1 comment so far
Hey Everyone!
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:
Enjoy and have a great week!
Water Water everywhere… January 7, 2010
Posted by keithga in Uncategorized.comments closed
I was walking in through the Lobby of Microsoft building 18 yesterday, and someone came in to tell the receptionist that there was a burst water main leaking in the building. Unfortunately, this is a normal occurrence in Microsoft Building 18. And has happened every year since 2007, and typically localized arround the Microsoft Deployment Toolkit team members.
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
Keith Garner is a Deployment Specialist with Xtreme Consulting Group