How to filter out Platform Specific Applications October 30, 2009
Posted by keithga in MDT 2010.4 comments
A common question that comes up every now and then is:
Using the Microsoft Deployment Toolkit deployment wizard, how do I filter out x86 applications when installing a x64 OS, and vice versa?
Say you have two applications defined in the MDT Management Console:
- 7-Zip (x86 version)
- 7-Zip (x64 version)
You have done the right thing and marked each one with the correct client platform types (See my previous blog entry). For x86, the new Platform Types in MDT 2010 are:
- All x86 Pre-Vista
- All x86 Vista and Newer
And for x64, the new Platform Types are:
- All x64 Pre-Vista
- All x64 Vista and Newer
However, when you start up the Litetouch Deployment Wizard in MDT 2010, it does not filter out the “7-Zip (x86 version)” when installing a x64 OS, and does not filter out “7-Zip (x64 version)” when installing a x86 OS. This is by design.
The file ZTISupportedPlatforms.xml contains a list of all platform types, the corresponding WMI Query Language (WQL) string used to validate each Supported Platform Types.
Unfortunately, the WQL string needs to be validated during the actual application, not during the Deployment Wizard pages. Most of the time, the Wizard Page is not running on the same as the OS we are installing to, so the Supported Platforms WQL test will return back false information. Supported platforms can only be evaluated during the actual install when the OS is running.
So how do we get the only one Application or the other to display?
The trick here is to create a “Application Bundle”. An Application Bundle is an Application defined in the MDT Management Console, that does not perform any application installation itself, but instead contains a dependency on other applications that do the actual installation.
In the case above we would create a new Application Bundle in the Management Console called “7-Zip” that is dependent on “7-Zip (x86 version)” and “7-zip (x64 version)”.
We would also go back to the “7-Zip (x86 version)” and “7-zip (x64 version)” entries and mark them as “Hidden” in the Property Pages.
- 7-Zip <—New dependent on 7-zip x86 and x64
- 7-Zip (x86 version) <– Hidden
- 7-Zip (x64 version) <– Hidden
Now in the Microsoft Deployment Toolkit Deployment Wizard Page we will see only one entry
- 7-zip
When it comes time to perform the actual installation, the ZTIApplications.wsf script will see that 7-Zip is dependent on two other items. When it tries to install the other two applications, only one will pass, depending on the platform type specified. The other platform type will not error, but silently continue.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupCustom Wizard Pages October 30, 2009
Posted by keithga in MDT 2010.20 comments
I had a customer recently (a very large Windows-only IT Shop), who wanted a custom wizard page in MDT.
Most of the wizard work I did on BDD/MDT was done by hand, editing html source code in a text editor. Michael Niehaus wrote an excellent tool to help develop and show MDT wizard pages in a C# application, however I prefer to develop by hand.
See: http://mdtwizardeditor.codeplex.com/
For this solution the customer wanted to allow their clients the ability to clean the partitions using the default MDT installation “New Computer” installation process, or to keep the existing partition configuration (and therefore keeping any 2nd data partition).
I created a web page that would query the partition configuration for disk 0, and display it in a graphical fashion, along with a graphical representation of the proposed “Clean” configuration.
Please note that there are technical problems with more than one partition on a Windows Deployment. It’s easy to setup, however, it can also creates management headaches later on if you need to service the machine.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupDefault state of “active” applications October 29, 2009
Posted by keithga in MDT 2010.add a comment
Noticed something the other day that got me stumped for a while.
When adding an application in MDT 2010, you can create the application using the MDT 2010 Management Console, or you can use powershell as a programming interface.
For a while now I had been using the following command in powershell to create applications (example single line):
import-MDTApplication -path 'DS001:\Applications' -ShortName 'MacroMedia' -Name 'Adobe Macromedia Flash Player 10' -CommandLine 'flash_player_ax.exe /S' -WorkingDirectory '.\Applications\MacroMedia' -DestinationFolder 'MacroMedia' -ApplicationSourcePath '$LocalPath\Sources'
However, I noticed that although my applications were appearing correctly in the Client Deployment Wizard, and installing correctly by ZTIApplications.wsf, they were not being copied from one Deployment point to another by the MDT Management Console (in my case a Media Deployment Point).
After some experimentation, I discovered that none of my applications added from my powershell scripts were “enabled” in the MDT Management Console. This was blocking the copies.
A simple addition to my scripts the explicit use of -enable “True”, fixed everything.
import-MDTApplication -path 'DS001:\Applications' -ShortName 'MacroMedia' -Name 'Adobe Macromedia Flash Player 10' -CommandLine 'flash_player_ax.exe /S' -WorkingDirectory '.\Applications\MacroMedia' -DestinationFolder 'MacroMedia' -ApplicationSourcePath '$LocalPath\Sources' -enable 'True'
It appears that the client scripts and the server scripts have different interpretations of what the default of “enable” should be if the element is not present in the applications.xml file.
Luckily for me, it’s an easy fix/work around to my powershell scripts.
Keith
Keith Garner is a Deployment Specialist withRecovery cmd.exe in Litetouch WinPE October 29, 2009
Posted by keithga in MDT 2010, Troubleshooting.2 comments
(New for MDT 2010)
One of the things we worked on for MDT 2010 were improvements to the user interface for “New Computer” scenarios in the Windows Pre-installation Environment (WinPE).
WinPE is used by MDT 2010 Litetouch, and SCCM to prepare the machine for OS installation. It’s a bare bones implementation of Windows, with out the Windows Shell (Start Button), and typically only runs with a command prompt “console” window.
One of the distracting things about BDD 2007 and MDT 2008, was the Console window that appeared at the start of the WinPE Litetouch New Computer” process. It really didn’t do anything, was a little distracting, and didn’t give MDT the feel of a polished product.
It’s fairly easy to use a different shell for WinPE, however we were concerned about proper error recovery. If something goes wrong with any child script in the process, we want to ensure that we have a chance to debug the problem before the machine reboots. If we replaced the standard WinPE shell with something that didn’t properly handle errors, then WinPE could reboot before we knew what happened.
We also wanted the ability to break out into a cmd.exe prompt if we needed to debug a background process or verify something else.
The final solution was to make some modifications to BDDRun.exe to act as a wrapper around wpeinit.exe. It does two things:
- It calls wpeinit.exe, and if wpeinit.exe returns any failure, it will launch a cmd.exe prompt allowing debugging.
- It also launches a thread in the background monitoring for the user to press the F8 button, if pressed, it will launch a cmd.exe window for debugging.
- If there are any instances of cmd.exe (spawned by pressing F8), and wpeinit.exe exits ready for a reboot, the bddrun.exe program will wait until all cmd.exe windows are closed. So be sure to close all windows if you expect the process to continue.
- If you wish to disable the F8 feature, modify the unattend_pe_x86.xml and unattend_pe_x64.xml in the templates directory of your MDT 2010 installation, and replace “/Bootstrap” with “/BootstrapNoSF8”.
Not sure why someone would want to disable the F8 windows (perhaps the F8 keystroke conflicts with another application. Disabling F8 won’t make things secure. Someone could still come in with a WinPE DVD and bypass the security.
Why is it called “SF8″ not “F8″? I had originally programmed the keystroke to be Shift-F8 (similar to the Shift-F10 used by Windows Setup. However the feedback I got from early builds is that it should mimmic SCCM behaviour which uses just F8. I changed the keystroke from F8 to Shift-F8, but forgot to change the command line string from /BootstrapNoSF8 to /BootstrapNoF8. Sorry about that…
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupHow to debug MDT Litetouch/Driver Problems October 28, 2009
Posted by keithga in MDT 2010, Troubleshooting.Tags: Drivers, Lite Touch, MDT
1 comment so far
Someone posted a question yesterday about some problems they had getting a driver installed via MDT. In a previous job, I worked in Microsoft Developer Support supporting the Windows Device Driver Kit. I even wrote several driver installation KB articles, and samples for the Windows 2000 & XP DDKs. Most recently, I re-wrote the ZTIDrivers.wsf script for MDT 2010.
Here is a quick overview for adding (non-boot) drivers in Windows. (Please note: Windows XP/2003 Boot drivers use a different process. Drivers like Storage Drivers. )
ZTIDrivers.wsf process
ZTIDrivers.wsf does not actually install a driver for each device during an OS installation. Instead during the pre-installation phase it will:
- Gather a list of all devices on the machine and their corresponding Plug and Play Device ID (PnPID).
A PnPID might look something like: PCI\VEN_8086&DEV_27C9&SUBSYS_01C21028 - It will then search for any matches in the “Out-of-Box Drivers” folder on your Deployment Share ( in the Out-of-Box Drivers folder, and the control\drivers.xml file).
- For each driver package found, it will copy the driver locally into the c:\drivers folder.
- For each folder added into c:\drivers. The folder will be added to the registry:
HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath - When the real OS begins installation, and it finds new devices, it will look in these paths for the drivers.
ZTIDriver.wsf assumptions:
Most of the time, it works just fine, however there are some things are assumed:
- You must be using a driver that contains at least one PnPID match with the device being installed.
- Windows will only auto-install drivers that have a valid Driver Signature.
If one file has been modified, or corrupted, even the *.inf file, the Signature is no longer valid. - You might be able to install non-signed drivers depending on the OS, but not for new OS’es like Vista 64-bit.
- It is possible that there may be other drivers on the local machine that the OS feels are a better match to the driver from the Out-of-Box drivers folder.
- It is also possible that the device just isn’t working, or the driver just doesn’t work.
I typically only use drivers that are WHQL signed (Disclaimer: I used to work for Microsoft, WHQL), and since Windows Vista, Windows Server 2008, and Windows 7, 64-bit modes will only support signed drivers, it’s usually a good idea to get into the habit of using Signed Drivers only.
Shout out: Michael Niehaus was kind enough to add a check for signed drivers in the MDT 2010 Workbench Driver Import routines. (Thanks Mike!)
To see if your driver is signed, go into the MDT 2010 Workbench, Out-of-Box Drivers, and find your Driver. When found, open the “Properties” page, “Details” tab, and verify the checkbox at the bottom of the screen: “This driver is WHQL signed”.
Debugging Steps:
If you are having troubles with device drivers, it’s typically a good idea to start looking at some basic things:
- Verify that you have the correct drivers imported into the workbench. Including:
- Go into the MDT Workbench and find your driver. Verify that the drivers are installed.
- You should also be able to verify the drivers are present in the Deployment Share.
- Test the deployment on physical hardware with the actual device installed. It may not be possible to test Video Driver X with Video Card Y, unless they have a subset of matching PnPID’s.
- Look to see if the Drivers were copied by ZTIDrivers.wsf.
- You should see ZTIDrivers.wsf identify the PnPID for your device.
- You should also see ZTIDrivers.wsf xcopy the driver from the Deployment Share locally.
- If the device and corresponding driver were found by ZTIDrivers.wsf and copied locally. Then Windows should find the device and install. Best place to look for more information is the SetupAPI.log file, used by the PnP Subsystem to log all issues with Device Driver Installation.
More information:
Windows Vista setup log file locations
Troubleshooting Device Installation with the SetupAPI Log File
Windows Setup and Device Installation Logging
Troubleshooting Device and Driver Installations
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupPlatform specific application installs October 28, 2009
Posted by keithga in MDT 2010.Tags: Applications, Lite Touch, MDT
add a comment
(New for MDT 2010)
When adding applications in Microsoft Deployment Toolkit it is possible to associate them with a specific OS or platform.
For example, if I wanted to associate an application with “Windows XP – x86 (any service pack version)”, I would select the item in the MDT Management Console, “Properties”, “Details”, “This can run only on the specified client platform:” with the item:
- All x86 Windows XP
When it comes time to install the application using ZTIApplications.wsf, the script will look up “All x86 Windows XP” in the file ZTISupportedPlatforms.xml and query the local machine using WMI Query Language (WQL):
SELECT * FROM Win32_OperatingSystem WHERE BuildNumber = '2600' AND OSType=18 SELECT * FROM Win32_Processor WHERE Architecture=0
In MDT 2008, if we wanted to have an application work on all x86 platforms, and *only* x86, then we would need to select more than one platform.
- All x86 NT
- All x86 Windows 2000
- All x86 Windows XP
- All x86 Windows Server 2003
- All x86 Windows Server 2003 R2
- All x86 Windows Vista
- All x86 Windows 7 Client
- All x86 Windows Server 2008
- All x86 Windows Server 2008 R2
This became a bit of a pain when a new version of windows came along like Windows 7, and I wondered what would happen when Windows 8 came out. Would we need to change our definitions, yet again? The answer was yes.
This was made more complex by the limitations of the WMI provider we use to determine if an OS is x86 or x64, they are different for Windows 5.0 vs Windows 6.0. So there is no way we could create a single entry for “All x86” or “All x64”.
So for Microsoft Deployment Toolkit 2010, we created four new entries that are mostly OS version agnostic.
- All x86 Pre-Vista
- All x86 Vista and Newer
- All x64 Pre-Vista
- All x64 Vista and Newer
Including “All x86 Pre-Vista” and “All x86 Vista and Newer” in the property page of your Application will ensure that it won’t be installed on a x86 OS.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupMDT 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 GroupFalling asleep on the job (task) October 26, 2009
Posted by keithga in MDT 2010, VBscript.3 comments
ZZzzzzzz…… (New for MDT 2010)
One of the new features of Windows 7 is a new aggressive power management policy. For machines that are plugged in, the new “Balanced” default policy will put a machine to sleep in 30 minutes. For Windows Vista, the default was 60 minutes.
For Deployments, that’s a problem if you have application installs that take longer than 30 minutes, like Microsoft Office 2007, with all the service packs. Half way through the deployment, the install pauses because the machine went to sleep.
I first noticed this in early tests of the Microsoft Deployment Toolkit 2010. I had written a utility for a similar problem back when I worked for Microsoft IT. It uses a Win32 API call: Win32 SetThreadExecutionState()
It’s a simple C/C++ call:
SetThreadExecutionState( ES_CONTINUOUS | ES_SYSTEM_REQUIRED );
This command resets the idle timer of the OS, and forces the machine to stay in a state while the Litetouch Task Sequence is running.
Updated (11/3/09):
KeepAlive was added to MDT 2010 in the Microsoft.BDD.Utility.dll file, you can see it being called in the litetouch.wsf script:
' Ensure that this machine does *not* go to sleep while running the task sequence steps. On error resume next oUtility.BDDUtility.KeepAlive On error goto 0
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting Group
