Make/Model Match

Historically, if you had different hardware platforms, and you wanted to install drivers on each type, you would create separate packages for each Make and Model. Then you could query the Make and Model information from the BIOS to determine which package to install.

For example here are four Make+Model examples:

The disadvantage of this method is that you have to update the driver packages when new Models come along, and it’s also possible that you might keep multiple instances of the same driver package across many Make and Model repositories. 

PnP-ID Match

With MDT, ZTIDrivers.wsf was designed to do things in a different manner. Instead of downloading drivers and grouping them based on Make/Model, you would import the driver directly into MDT, MDT would parse the driver package, and MDT would install the driver package on the machine if the Plug and Play ID matched.

For example, Windows might search for Plug and Play ID’s that look like:

PCI\VEN_1099&DEV_0242&SUBSYS_02429005&REV_01
PCI\VEN_1099&DEV_0242&SUBSYS_02429005
PCI\VEN_1099&DEV_0242&CC_010401
PCI\VEN_1099&DEV_0242&CC_0104
PCI\VEN_1099&DEV_0242&REV_01
PCI\VEN_1099&DEV_0242
PCI\VEN_1099&CC_010401
PCI\VEN_1099&CC_0104
PCI\VEN_1099
PCI\CC_010401
PCI\CC_0104

Generally this system works better than copying based on Make and Model except for a few points:

• You must import the drivers in a correct fashion so MDT can parse the INF files, and so each driver package is a seperate entry (more on importing drivers later…)
• Some PC Makers only certify (support?) a subset of driver versions, so it is possible that MDT may give Windows the latest non-certified version of a driver.
• There also may be compatibility problems with specific drivers. When placed on some other platforms. (However IMHO, if a driver *can* be installed on a machine, but crashes the machine, then that is a bug of the driver).

Hybrid Make-Model + PnPID Match Solution

For my MDT environments, I don’t want to place all drivers into Make/Model groupings by default, since I loose the advantages of ZTIDrivers.wsf where it copy by PnPID. For example, I have the drivers for my Dell D620 integrated now, but it’s good to know that I probably have good coverage for any D820′s out there since they share mostly the same components.

I’ve seen some MDT implementations that totally throw away the ZTIDrivers.wsf PnPID style in favor of maintaining a manual mapping of drivers to Make+Model. However, I do concede, that there are some drivers out there that “… do not play nicely with others…”, and need to be quarantined somehow, and according to a make+model works well.

Create a Folder Structure in MDT Workbench:

Then in your CustomSettings.ini file, you can add the following: 

DriverGroups001=Common

DriverGroups002=%Make%\Common

DriverGroups003=%Make%\%Model%

DriverSelectionProfile=Nothing

(Note that DriverSelectionProfile=nothing is required if using DriverGroups).

%Make% and %Model% will be auto-expanded in the customsettings.ini file with the Make and Model values from the system BIOS.

• If you have a driver that will work for all Makes and Models, then place it under \Common.
• If you have a driver that is only supported for a single Manufacturer, then place it under \%Make%\Common.
• If you have a driver that only works on a specific Make and Model, then place it under \%Make%\%Model%.

This should allow you to use generic drivers by default, moving drivers to specific makes and models when required.

Keith

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

To fix this you would, right click on the DeploymentShare and choose Update.  Then you would choose Completely regenerate the boot images as shown below:

Now that your boot images are updated you will either need to burn new CDs or re-import the boot images into WDS

- Tim Mintner

I passed!!!

I’ve been an in-depth Microsoft technical guy for 14 years now, yet I’ve never gotten around to actually taking any Certification test before.

And I figured that since I was on the Dev team for MDT 2008, I’d start with 070-635 (Microsoft Deployment Toolkit 2008, Desktop Deployment). I took the test cold, no studying.

It was kind of weird going back and taking the test for MDT 2008. There have been two product releases since then, MDT 2008 Update 1 and MDT 2010. And I’ve been working on Windows 7/MDT 2010 components now for about a full year.

I’d take some more exams, but I had to pay for this one out of my own pocket. Perhaps in the new year.

Tim Mintner mentioned once that he took this test as well. Which wasn’t really fair, since he helped write the questions. :^)

Keith

During the development cycle for MDT 2010, one component that had constant change was the Windows Automated Installation Kit. MDT requires several components from the WAIK to perform correctly, so we were constantly upgrading.

One of the components, the WIMGAPI.dll was particularly nasty. The WAIK installer would set the permissions on the file so regular users could not delete it, and the intra-build upgrades didn’t replace the file automatically. Luckily, if you are using the final released (RTM) version of the WAIK, and upgrading from a previously released version, you should be OK.

Why are these files so hard to delete?

Windows protects some installed files by giving only the “Trusted Installer” account access to the file, and explicitly denying everyone else access, including administrators and the SYSTEM account.

Running the icacls.exe command on wimgapi.dll reveals:

NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)

The problem is that normal users and administrators don’t have full access to the file and are not allowed to modify the permissions.

How to Modify “Trusted Installer” files

If you ever find yourself in the situation where you need to modify/delete files that are “trusted installer” protected, here is what I do:

1. Start up an elevated command prompt (with administrator privileges).
2. Run “icacls.exe <file>” to see the current permissions.
3. Run “TakeOwn.exe /f <file>” to change ownership.
4. Run “icacls.exe <file> /reset” to change permissions.
5. Run “icacls.exe <file>” to display the new permissions.

Example:

Keith

Presented here is the MDT Application Export Tool (MDTAppExport.exe). This tool will export the settings for a selected Application in MDT 2010 into a Powershell *.ps1 script file. This portable powershell script file can be used to import the Application settings into another instance of MDT 2010.

One of the coolest new features of MDT 2010 is the new Powershell Programming interface. This interface makes it possible for 3rd party programs to Read, Manipulate, and Create settings in your MDT 2010 environment.

Still, Powershell is a relatively new programming language. And many IT Pros may still be unfamiliar with it. Which makes this tool so cool, you can create powershell scripts without knowing powershell.

Advantages

Exporting to Powershell provides a good way to share Application metadata between MDT 2010 Shares:

• Upgrade your existing MDT 2008 Deployment Share to MDT 2010, and extract out all of your applications for archival.
• Move individual applications between test and production environments without copying other items still in test.
• Use Powershell scripts as a way to document/store the settings for each application in your environment.
• Share your solutions to difficult/complex application installations to IT Community Forums (please don’t share software files you don’t have the rights to redistribute :^) ).

Notes

While running the Application Script Export Tool Wizard, Simply select one of the Deployment Shares already present in the Microsoft Deployment Toolkit 2010 Workbench. Then Select the Applications you wish to export, and the Target location they should be exported to.

Most applications should export without trouble 97-98% of the time. However it is generally a good idea to review the settings created by the tool to ensure that everything is correct.

This script will create one Powershell *.ps1 script file for each item selected in the wizard. If an Application has dependencies defined in the MDT 2010 Workbench, then the dependencies will also be included in the same *.ps1 file.

All Source Files imported into the Deployment Workbench when the Application was created will be copied to the Target Location.

Limitations

• You must have MDT 2010 installed on the same machine this tool is running on.
• You must have your Deployment Share visible in the MDT 2010 Deployment workbench.
• This tool will create one *.ps1 for each application Selected, and all dependent applications will be imported to the same *.ps1 file.
• If you have hidden and or non-enabled applications defined, they will also be Displayed in the Application Script Export Tool Wizard.
• This tool will create scripts with the –hidden and –enabled settings as defined in the workbench.
• This tool will *not* export the Language Field. Language Field is not used in ZTIApplications.wsf
• If you are exporting Sources, the files must be located in the Deployment Share, meaning that you can’t have a %ResourceRoot% at a different location from the %DeployRoot%.
• If there were any errors in copying the Sources to the Target, there should be an
  “# ERROR – <something>”
  line present in the source.
• Please ensure that all application items imported into MDT are placed in their own directory. Installing more than one Application Item from the same directory may result in duplicate files in the MDT system.

Links

MDTApplicationExport.zip

Further

This tool has tremendous potential. Beyond just coping application settings between MDT 2010 Servers.

We are already using this tool here at Xtreme Consulting Services to create “repositories” of applications that can be used to quickly build out MDT 2010 deployments for our customers. A fullly functional MDT 2010 Litetouch Deployment System setup on site in Hours, not Days, or Weeks.

It could also be the start of a public repository of Applications for MDT Administrators. Although I have not yet figured out a great hosting site for this kind of community/forum. Have some ideas, drop me a line.

Update: 11/13/09 – I updated the tool to generate scripts that support Powershell v1.0 better, and to fix a problem with applications with spaces in the shortname.

Keith

From my previous post, I wrote that for MDT 2010, there is a new common command line parameter called “/debugcapture”. This command line parameter will disable the common MDT error handling functions and let any errors echo out to the console.

This is great when calling MDT Client scripts directly from cscript.exe, however it is not helpful when calling from within a MDT Litetouch Task Sequence. Since the MDT 2010 Litetouch Stand Alone Task Sequencer does not capture the output from the client scripts for logging.

Introducing ZTICscript

To solve this problem, I developed a wrapper script called ZTICScript. It will call a client script with the new /debugcapture flag, capture any error output, and copy the error lines to the standard bdd.log system.

It’s been really great when developing new client scripts that may have errors, and speeds up the identification of bad code. As I mentioned in my earlier post, using the information captured with the /debugcapture flag, I can identify the line number and sometimes the variable name of of any errors.

Another cool thing about getting the output from /debugcapture rather than from the default error handler, is that it can also capture compile time errors. For example, if you have written a script with an unterminated string:

wscript.echo "Unterminated string

These errors are nasty, since the bdd.log will not display any errors from the script. Sometimes you may need to go into the smsts.log file to find out which script it was executing when it failed.

Step 1 – Modify your TS.xml file.

Open up your Ts.xml file ( %deployroot%\control\<dir>\ts.xml ), or ( %programfiles%\microsoft deployment toolkit\templates\client.xml ), and replace every instance of

cscript.exe

with

cmd.exe /c %scriptroot%\zticscript.cmd

For example, if you are trying to capture debugging information from the ZTINextPhase.wsf script, the command line should look like (single line):

cmd.exe /c %scriptroot%\zticscript.cmd
"%SCRIPTROOT%\ZTINextPhase.wsf"

Step 2 – Create ZTICScript.cmd and ZTICScript_log.wsf.

Get the script files from here, and copy them to your %DeployRoot%\script directory.

That’s it!

Now, if there are any errors in your script that would normally be caught by the standard MDT Exception Handler, they will instead be output to the console and piped to the bdd.log file. Very helpful in scenarios where normal bdd.log files are not returning the correct information.

Please note, that for some reason, I have been unable to get this script to wrap around LTISysprep.wsf 100% of the time. I just haven’t had the time to debug what’s happening. I think it may have to do with the heavy resource requirements of sysprep.exe.

Attachments:

ZTICScript.zip

Keith

1. Create a folder on the client device and copy the following files from the deployment point to this folder:

• ZTIGather.wsf
• ZTIGather.xml
• ZTIUtility.vbs
• CustomSettings.ini
• ZTIDataAccess.vbs (new script file in MDT 2010 for accessing data sources)
• Create a Tools folder and create an X86 and X64 folders underneath the Tools folder.  Copy the Microsoft.BDD.Utility.dll file from the Tools\X64 and Tools\X86 folders in your deployment share to your newly created Tools\X86 and Tools\X64 folder

  2. Delete C:\MININT directory if it already exists. This folder can also be located at X:\MININT if the C drive is not available.

NOTE: MDT stores configuration and progress information in the MININT folder, if this folder is not removed between tests then the results will be invalid.

  3. From the command prompt navigate to the newly created folder and execute the rule processing script using the following command:

“cscript.exe ZTIGather.wsf /debug:true”

      The script will then be processed and the results outputted to the command prompt and a log file ( .\MININT\SMSOSD\OSDLOGS\ZTIGather.log)

NOTE: The script can be run within Windows PE or the host operating system.

  4. Review the results of the script.

Enjoy!

Tim Mintner is a Principal Consultant with Xtreme Consulting Group

Would you mind sharing that tool you wrote ?

Also, is ES_CONTINUOUS and ES_SYSTEM_REQUIRED flags cleared when the system is rebooted?

What I am thinking of is if you run a util that set the above at the beginning of the Lite Touch process. Would you need to run another util that that clears the EXECUTION_STATE flag at the end of the Lite Touch sequence? Or will it be cleared automatically when you reboot the computer using a Restart Computer entry in the Task Sequence?

More background

When you set the Execution state, although you are setting the state of the entire system, the Operating System will only keep track of the requested state during the lifespan of the Thread that made the call. Once the thread (or process) exits, the request is no longer valid, and the system goes back to whatever the last state was.

In MDT 2010, this was easily solved by making the call to SetThreadExecutionState() from within the litetouch.wsf script. Since the Litetouch.wsf script thread stayed alive during the Task Execution phase (in the background), that worked out fine.

Also, the Thread Execution State does not persist across reboots, so cleanup was not necessary, just exit out of litetouch.wsf, and the machine can go into hibernation.

Side Effects

This *may* have a side effect. If you choose to display the final Summary Dialog Box at the end of the Litetouch process, the machine will stay alive during that time, until the user comes back to the machine.

New Tool

Just in case you have “Other” tasks that require you to keep a machine alive, here is a tool I wrote back in 2005 (cleaned up here). This *.exe tool will keep a Windows Machine alive while it is running. Meaning the machine won’t be able to fall asleep either by hibernate or by suspend.

The tool has to remain running while you want the machine to stay awake. So you can run it with the command line:

start KeepAlive.exe

This program is a Windows Program and will run with no user interface. You can see if it’s running by checking the task manager.

When you are done, just run the command again (Either with or without the –close flag:

KeepAlive.exe

If KeepAlive.exe detects that another instance of itself is running in the background holding up Thread Execution State, the new instance of KeepAlive.exe will signal to the previous instance to stop and release the Execution State.

The source code is included

Link

KeepAlive.zip

Keith