Windows 7 and that pesky System Partition November 5, 2009
Posted by tmintner in MDT 2010, Windows 7.Tags: Disks, MDT, Partitions, Windows 7
add a comment
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.add a comment
(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:
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