MDT 2010 and Windows Recovery (WinRE) October 27, 2009
Posted by keithga in MDT 2010.add a comment
(New for MDT 2010)
Windows Recovery Environment (WinRE) is a set of tools included in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. It can help diagnose and recover from errors that prevent Windows from booting successfully. It’s the modern equivalent of repair tools like “fixmbr”.
Typically WinRE works along side of WinPE. There is no need to install it into a functioning OS, if you can get to a functioning OS, then there is typically nothing to recover.
Back in BDD 2007, we added code to the BDD Welcome Wizard to display a link to the WinRE tools if they were installed on the image. However for some reason, WinRE support was yanked from the WAIK, so most people could never install WinRE into their BDD/MDT Litetouch boot images.
Changes for MDT 2010
New for MDT 2010, when building a new Litetouch WinPE WIM (Update Deployment), if MDT detects the presence of Windows 7/Windows Server 2008 R2 in the workbench, then it will leverage the boot.wim file from those directories, which is great since these boot.wim files contain the WinRE bits. This is a change from MDT 2008, where the Litetouch.wim boot file comes directly from the WAIK.
If you have a pre-existing delivery mechanism for distributing Litetouch Images in your company, like PXE, USB Flash, or DVD, you now automatically have a boot recovery method, since WinRE is automatically included in the litetouch WinPE Boot wim.
It is possible to add WinRE to the local machine for recovery, however chances are that if your client machines are having problems booting to the OS, either they have bad hardware (not fixable by WinRE), or their boot environment is messed up enough that booting to WinRE off the local hard disk is also not an option. Having WinRE available over the network via PXE boot is typically good enough.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupSecuring your installation of Litetouch MDT October 27, 2009
Posted by keithga in MDT 2010.Tags: Lite Touch, MDT, Security
1 comment so far
There are several instances during the litetouch deployment process where sensitive pieces of information are stored and retrieved as plaintext. The most common example of this is the Administrator Password.
The Administrator Password is typically gathered by the Deployment Wizard, stored locally in the c:\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT file, and later set by ZTIConfigure.wsf and Litetouch.wsf.
I would be great if this data was encrypted during installation, however, that is not possible in all instances. The Administrator Password, for example, must be available as plaintext (unencrypted) for AutoLogon to work. And Windows AutoLogon does not itself encrypt the Administrator Password.
For MDT 2010, we added a new feature that obfuscates critical data in the variables.dat file using the same obfuscation method used by Windows in the Windows System Image Manager found in the WAIK. This data is not 100% secure, I know the method used to obfuscate the data, and I can easily read the information, however most users can’t. (Can you guess the algorithm? Don’t tell anyone :^)).
In most scenarios though, this shouldn’t be a problem. The user will type in a local password, the scripts will save the information locally, but the data is purged at the end of the Litetouch Deployment process.
There are ways that we *can* help protect sensitive information like the Administrator Password if required. One possible way is to get the user to input a “Less Secure” Administrator password at the start of the installation process. We can then inject at the end of the Litetouch deployment process a new step to auto-expire the administrator account’s password. Then the next time a user logs into the administrator’s account, they will be forced to change the password.
Forcing the user to change the password at the end of the Litetouch process has another advantage. When we start the Litetouch installation process for an OS (new computer), we are not joined to a domain. Meaning any Local Administrator Password complexity policies are not applied. If we force the user to change the password at the end of the install process, after the machine has been auto-joined to a domain, then we can enforce any Complexity Requirements required by the domain.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting Group