The Case of the Disappearing Task Sequences November 13, 2009
Posted by tmintner in MDT 2010, VBscript.Tags: DeployRoot, Empty, MDT, Task Sequences
17 comments
We’ve gotten quite a few emails on this so I figured it was time to put this on the blog. 
The problem that most people run into is that sometimes when they go through the Lite Touch Client Deployment Wizard, the task sequence list is empty. So what causes the task sequence list to be empty? The simple answer is if the DeployRoot cannot be found or is incorrect. The DeployRoot is the location of the DeploymentShare or content of the MDT Media Point.
Here is the basic process that should help troubleshoot the problem:
· Windows PE boots up and runs litetouch.wsf
· Litetouch.wsf calls ztigather /inifile:bootstrap.ini and the DeployRoot value is read from the bootstrap.ini
· Litetouch.wsf then makes a call to connect to the DeployRoot using the wizard credentials or the credentials in the bootrap.ini
· Litetouch.wsf then calls ztigather and reads the values from the customsettings.ini (note if a full Media Deployment is inserted in the DVD or USB drive the customsettings.ini will be read from that location instead of the DeployRoot)
· If the DeployRoot value has changed In the customsettings.ini, the value is updated and Litetouch.wsf tries to connect to the DeployRoot
· The wizard is started and the tasksequences.xml file is read from the DeployRoot
· If the DeployRoot does not contain a valid tasksequences.xml then a blank Task Sequence wizard is displayed
Steps to troubleshoot:
· Open BDD.Log
· Search for the value DeployRoot and do a Find Next to make sure that all values in the log file for DeployRoot are the same. If they are not then there is some setting either in CustomSettings.ini, the database, or on local media that is changing the value
Validation: Passing the MDT 2008 Certification Exam November 12, 2009
Posted by keithga in Uncategorized.add a comment
Took the Microsoft Deployment Toolkit 2008 Certification exam today.
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
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupHow to delete files that won’t delete November 11, 2009
Posted by keithga in MDT 2010, Troubleshooting, Uncategorized.add a comment
One of the frustrations when working with beta software is dealing with constant changes and little support for cross-build (not major version) upgrading.
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:
- Start up an elevated command prompt (with administrator privileges).
- Run “icacls.exe <file>” to see the current permissions.
- Run “TakeOwn.exe /f <file>” to change ownership.
- Run “icacls.exe <file> /reset” to change permissions.
- Run “icacls.exe <file>” to display the new permissions.
Example:
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupChanging Boot order for MDT Litetouch November 10, 2009
Posted by keithga in MDT 2010.1 comment so far
Microsoft Deployment Toolkit (MDT) has the ability to initiate a new computer installation from several different sources:
- Boot from Litetouch CD Boot image. This is about a 200MB *.iso image that allows you to connect to a deployment share on the network.
- Network Booting. You can also take the Litetouch Boot image and PXE boot over the network if you have a WDS (Windows Deployment Services) Server available.
- Media Builds. You can also copy a subset of the deployment share onto a DVD drive for installs that do not have any network access or slow network access.
- OEM installs. If you have a Media Build ready, MDT also has the ability to prepare the DVD for OEM installation.
- USB Flash/USB Hard Disk. If you have a USB Drive, you can prepare the drive to boot either the Litetouch Boot Image, or a Litetouch Media image to boot off of USB. This is helpful if you are trying to deploy an image that is larger than 8GB, the largest DVD Dual Layer size.
Booting from CD/DVD and from the hard disk are fairly straight forwards. But booting from Network and/or USB requires a little bit of work.
Just a few years ago, in order to boot from other devices, each user would need to ensure that the local machine was configured to boot from these other devices by going into the BIOS at the start of the computer boot-up sequence. This method had problems, since it’s possible to configure the machine to boot into these other devices and leave the machine in an unsecure state.
I had a case recently where a user re-configured the boot order to boot from a USB Hard disk first for a “New Computer” install from USB. Unfortunately, he forgot to change the BIOS boot order back to the default settings after he initiated the install, so after the MDT 2010 Litetouch “New Computer” WinPE phase was complete, it did not reboot into the OS, it booted back into WinPE.
Thankfully, most modern BIOS’es have the ability to boot from these other devices without permanently changing the boot order into an unsafe configuration.
Recommended configurations:
So, what if the boot order settings of your BIOS have been modified beyond recognition?
For most machines, I recommend the following boot order:
- Boot from CD-ROM
- Boot from Hard Disk
- Boot from Network
- Everything else
For Security Paranoid people, I recommend:
- Boot from Hard Disk
- Boot from CD ( Remove from the list if possible )
- Boot From Network ( Remove from the list if possible )
- Everything else
For Network/Lab machines that Boot from WDS, you could also do:
- Boot from Network
- Boot From CD-ROM
- Boot From Hard Disk
- Everything Else
Dynamic Selection of Boot Devices
Instead of modifying the boot order in the BIOS, I recommend changing the BIOS boot order dynamically per boot. Most Modern PC’s support the ability to dynamically select the BIOS boot order during boot up using some combination of F12, F10, or sometimes: F9
For example, my Dell machines, pressing F12 should bring up a menu of all available boot devices.
My HP machines have a similar option, pressing F9 should bring up a menu of available boot devices as well.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupWindows Update in MDT 2010 November 9, 2009
Posted by keithga in MDT 2010, Troubleshooting.14 comments
I have a confession to make, ZTIWindowsUpdate.wsf was written by me, it’s my fault. When it works, it’s the biggest time saver for getting my machines up to date, when it’s not working, yes even I get frustrated. It was designed to fill problem of mine and still has some advantages for the right customers.
I wrote it back in 2007 when I was working for Microsoft IT. At the time, Microsoft IT didn’t have a good Update/Patching story, there were some tools that ran occasionally as part of Group Policy, but it was hard to tell if a given machine was up to date, and what the correct manifest of patches for a given machine were. I was setting up a Litetouch deployment server and wanted to ensure that each machine was up to date when litetouch was done.
ZITWindowsUpdate.wsf was designed to fulfill a specific task: Update the local machine to the latest Updates/Patches/Drivers from Windows Update (WU), Microsoft Update (MU), or a WSUS server.
When the script works, its great. Most of my Dell and HP test machines have great Windows Update Driver support, so I have to spend less time updating my MDT 2010 Out-Of-Box driver folder with the latest drivers. I also don’t have to spend too much time staying up to date on the latest patches from Microsoft (hello patch Tuesday). The script does a good job downloading the latest/greatest patches from Microsoft.
However, things are not always perfect, and it does require some work once in a while. This might be due to new packages that don’t install properly, or other problems.
Most of the changes to ZTIWindowsUpdate.wsf between MDT 2008 and MDT 2010 were changes to improve the robustness of the system if the package failed to install.
One example was a specific patch from Windows Update that would try to install, and fail. However it reported back to the system that it passed. The script would keep retrying, and get into an infinite loop. We added some better logic to ensure that ZTIWindowsUpdate would not get into those kinds of infinite loops.
By default, ZTIWindowsUpdate.wsf will install everything from the WU/MU servers. There are some exceptions:
- If the package says that it “can” request user input, then we skip over the update. ZTIWindowsUpdate.wsf should be fully automated, and User Input could break automation. I added this primarily for IE7 and IE8 updates. So be sure you have IE8 install packages elsewhere if you require IE8.
- We skip Windows Vista and Windows 7 Ultimate “Language Pack” files. It’s just too much data to download.
- We can also skip packages for a specific KB article, or by Package ID.
Manually Excluding Updates
Occasionally you may come across cases where you need to exclude specific packages from installing on ZTIWindowsUpdate.wsf.
First step is to find the bdd.log or ZTIWindowsUpdate.log file generated by your test machine. We need the log files to know which Update ID numbers to exclude. While Microsoft Deployment is running, the log will be located at c:\minint\smsosd\osdlogs, however after the installation has finished, the logs could be uploaded to your SLShare Log Share, or to c:\windows\temp\deploymentlogs.
At the start of the log there will be some connection/diagnostic information. ZTIWindowsUpdate.wsf needs to connect to Microsoft Servers to ensure that the runtime binaries are up to date (yes, even Windows Update needs updating). You’ll want to look for the line “Start Search…”, then we see a list of packages:
Start Search... INSTALL - d49c3450-6646-4fbc-9e67-da7947bf3f13 - Update for Microsoft Office Outlook 2007 Junk Email Filter (KB974810) SKIP - 254a9c2e-0431-4a37-b977-f1652d9d4b4d - Windows Malicious Software Removal Tool x64 - October 2009 (KB890830)
Here we see a list of all the relevant packages Windows Update has returned for this machine.
- First column is either “INSTALL” or “SKIP”, all items marked “INSTALL” are to be installed, all items marked “SKIP” are *not* going to be installed.
- Then we see a 36 character GUID – This is the unique ID For the package. Please note that x86 and x64 packages of the same fix may have different ID’s.
- A short description of the fix.
- And sometimes we may have also have the associated Microsoft KB article.
Once you have identified the package you wish to exclude in the future, you can add the ID or the KB article in your customsettings.ini file. Test the install again to ensure that all packages are marked as “SKIP” in the log file, and you are good to go.
Here are some examples of ID’s that I included recently in my customsettings.ini file.
WUMU_ExcludeKB1 = 941160 ; Ultimate Extras WUMU_ExcludeKB2 = 928416 ; .NET Framework 3.0 WUMU_ExcludeKB3 = 955020 ; Add En/De words to dictionary WUMU_ExcludeKB4 = 905474 ; Windows Genuine Advantage ; Bad AuthenTec Driver, blocks installation. WUMU_ExcludeID001 = 3a130260-44f8-4769-9b9e-57c3bbd4ce45
Other
One trick I use often when testing ZTIWindowsUpdate.wsf directly is to use the /query flag.
net use z: \\server\deploymentshare$ cd /d z:\scripts cscript \ztiwindowsupdate.wsf /query
When you specify the flag, it will only query windows update, it won’t download or install anything. This is helpful if you need to test your WUMU_ExcludeKB or WUMU_ExcludeID entries to see if they match.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupExample application exported by MDTAppExport November 6, 2009
Posted by keithga in MDT 2010, PowerShell.add a comment
Wanted to include at least one example of what a MDTAppExport.exe powershell script looks like.
So for your review, I have included a sample for 7-zip.
Link
About 7-zip
7-zip is a popular file archiver that supports numerous file formats, and is available for free over the internet.
What also makes 7-zip a great example, is that you can download the *.msi package directly over the internet.
The command line MSI installer, msiexec.exe, supports the ability to install packages over http://, so there is no need to download the package first. Note that this could cause problems if you try to install 7-zip on a machine that does not have full internet access.
Typically, in real world MDT Deployment Shares, I would download the packages first, but this makes for a fine example.
Persistent Drives
For MDT 2010, the concept of the “Deployment Share” ( Distribution Share, or Distribution Point) has been abstracted even further than that in MDT 2008. A ‘”Deployment Share” can be a Network Share, a Local folder, and it doesn’t even have to be on the same machine as the MDT 2010 Workbench Console is currently running on.
It’s also possible to keep track of multiple “Deployment Shares” within a running MDT 2010 Workbench console. The “Deployment Shares” that are added to the MDT 2010 Workbench Console are called “Persistent-Drives” because they are persisted across Workbench sessions.
Behind the scenes, you can see the settings by looking at the configuration file:
“%appdata%\Microsoft\Microsoft Deployment Toolkit\user.config”
Which Drive to use
I wanted to develop a script that you could run as-is and have the contents instantly added to your MDT Deployment Share.
However, since a machine can have multiple Deployment Shares, or none at all, the question became:
How do we find the default MDT Deployment Share, if any exists?
The best way I figured was to use the Persistent Drives defined in the MDT 2010 Workbench. The Persistent Drive meta-data could be easily read using the powershell cmdlet: “Get-MDTPersistentDrve”.
If more than one drive was defined in the MDT 2010 Workbench, then we just select the first one. Typically defined as “DS001:”
Header
With all powershell scripts we start off with a list of parameters:
# MDT 2010 Exported Application # By Keith S. Garner (KeithGa.com) # 7-Zip File Archiver 4.65 param( [string]$Folder = "Applications\Common", [string]$DPDrive = "DS001", [string]$DPShare = "\\$env:ComputerName\DS$", [switch]$Confirm, [switch] $Verbose, [switch] $WhatIf )
Here the Administrator is given the ability to override several defaults:
- Folder – This is the folder where the Application will be placed in the workbench, and displayed in the Deployment Wizard.
- DPDrive – This is the name of the Deployment Drive used in Powershell. Unless defined as something non-standard by the Administrator, it should be DS001:
- DPShare – This is the UNC path to the Deployment Share, typically a Networking Share. It’s only needed if there are no persistent drives defined.
- Confirm, Verbose, WhatIf – For more information look here.
Restore
Once started, the script will need to load the MDT 2010 environment into powershell, and restore everything:
if (!(test-path "$($DPDrive)`:\"))
{
Add-PSSnapin Microsoft.BDD.PSSnapIn […]
restore-MDTPErsistentDrive […]
if ((!(test-path "$($DPDrive)`:\"))
-band (test-path $DPShare)) {
New-PSDrive -Name $DPDrive -PSProvider `
MDTProvider -Root $DPShare […]
}
if (!(test-path "$($DPDrive)`:\")) {
throw "$DPDrive not Mounted/Persisted."
}
}
First of all, we don’t do anything if the DPDrive is already visible to Powershell. This means that a calling “wrapper” script can perform the restoration of the Persistent drives once, and we won’t need to perform it each time for every application being imported.
Otherwise, we add the Powershell Snapin, and restore any MDT 2010 Persistent Drive(s).
We then test for DPDrive, if there is still nothing there, then we mount a new DPDrive to the Deployment Share given.
We test for DPDrive again, if there is *still* nothing there, then we fail.
Folders
If we are importing the application into an Application Folder that does not exist, we must first create the folder.
foreach($NewPath in "$($DPDrive)`:\$Folder")
{
if(!(test-path $NewPath))
{
new-item -type directory $NewPath –[…]
}
}
Import Application
Finally, we import the application using the settings gleamed from the application meta-data in MDT 2010.
$7zipx86 = import-MDTApplication -path '$($DPDrive)`:\$Folder' -ShortName '7zipx86' […] -Name '7-Zip File Archiver 4.65 – x86' -CommandLine 'msiexec.exe /qb- […] /i http://[…]' -UninstallKey '{23170F69-40C1-2701-0462-000001000000}' -enable 'True' -hide 'True' -SupportedPlatform @( 'All x86 Pre-Vista', 'All x86 Vista and Newer' )
More to come
I hope this will be the first of many Application Examples from MDT 2010.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupExport & share MDT Applications (New Tool) November 6, 2009
Posted by keithga in Uncategorized.comments closed
New for MDT 2010
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
http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/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
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupWindows 7 and that pesky System Partition November 5, 2009
Posted by tmintner in MDT 2010, Windows 7.Tags: Disks, MDT, Partitions, Windows 7
3 comments
If you have installed Windows 7 or Server 2008 R2 through either the Windows media or MDT then you have noticed that a 100 – 300 MB system partition is created that is hidden when you finish in the final operating system (well it is not really hidden, it just doesn’t have a drive letter). The Microsoft Windows team made that decision so that bitlocker could easily be enabled at a later time without having to repartition the disks. However if you don’t ever plan on enabling Bitlocker on your Windows 7 or Server 2008 R2 systems you can use MDT with an extra variable in the customsettings.ini and MDT won’t create the extra partition. The variable is:
DoNotCreateExtraPartition = YES
Capturing Debug Information from Client Scripts (New tool) November 5, 2009
Posted by keithga in Uncategorized.comments closed
(New for MDT 2010)
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:
http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/ZTICScript.zip
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupGetting Debug information in Client Scripts November 5, 2009
Posted by keithga in MDT 2010, Troubleshooting, VBscript.1 comment so far
(New for MDT 2010)
Most of the client script in BDD/MDT are written in VBScript. VBScript is a powerful scripting language, and it is avaiable on all versions of windows that MDT supports.
I would have loved to work in a more modern language like Powershell and/or C#, however when deploying an operating system from scratch, there are very few guarantees what kind of run time environments are going to be available. The .NET framework, for example, is not available on Windows XP. So back to VBScript for me.
Error Handling
VBScript has the ability to skip/ignore errors if it comes across them when executing them, using the “On error resume next” command.
This can be helpful if you have a long series of non-interdependent tasks. However if you have a long set of dependent tasks, this can be problematic since the failure of any one step in the task could cause the entire thing to fail.
I would have to agree with Eric Lippert’s comments about error handling in VBScript (He was one of the architects of VBScript):
I think I’m old school in saying that error handling should be very tight. Handle errors where you expect to find them. Everything else is left to fail. I’d rather have a program end in a messy death than to blithely continue on in an unpredictable fashion. Some of my cohorts would rather do broad error handling (whole subroutines or sections of the script). They seem to assume that only the errors they expect will happen. And even if other errors do happen, it’s better to have the script finish as best it can than to do nothing at all.
Most of the code in the MDT client scripts is written with this in mind. If it’s possible for a routine to return an error, the script will handle the error cases. If the results of a routine are unexpected or bad, then we want to halt execution to be notified of the problem, rather than continue in an unexpected state.
MDT Error Handling
BDD/MDT was written with a really cool feature that allows it to pick up run time errors identified by the VBScript host program. These errors are logged to the bdd.log file for review later.
The only problem is that the built in error handling routines made available by the VBScript Host program are not as complete as if we were to run it using cscript.exe with the error written to the console.
For example, here is what an undefined variable error would look like when processed by MDT and it’s built in error handling routines:
c:\>cscript zti_test.wsf ZTI ERROR - Unhandled error returned by zti_test: Variable is undefined (500)
New for MDT 2010, is the ability to disable the “on error resume next” main error handler in all MDT client VBScript programs, with the “/DebugCapture” flag. When we run the same script with that flag, we get the following output:
c:\>cscript zti_test.wsf /debugcapture Property debugcapture is now = c:\zti_test.wsf(10, 10) Microsoft VBScript runtime error: Variable is undefined: 'UndefinedVariableFoo'
Note that when calling the script with the /debugcapture flag, the cscript.exe host program not only found the run time error as in the previous example, but it also displayed the line number where the error occurred and the name of the actual variable!?!?
Really cool stuff, and it has been invaluable for me while debugging scripts in MDT 2010.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting Group
