New Tool: MDT 2010 Build-out/Hydration Evaluation November 13, 2009
Posted by keithga in MDT 2010, PowerShell, VBscript, Windows 7.comments closed
I wanted to give a glimpse of some projects we are working here at Xtreme Consulting Services – Deployment Team.
This is a Microsoft Deployment Toolkit 2010 Build-out (sometimes called Hydration) system.
It starts off as a small 3MB *.zip file. The MDTBuildout.exe program will automatically download all required files (around 10GB of files), create a Virtual Machine running Windows Server 2008, and build out a functional MDT 2010 system. All the files downloaded are publicly avaiable over the internet.
This sample is *not* designed for production environments. The Server OS and Windows 7 Client OS’es downloaded are time-limited Evaluation versions of Microsoft OS’es, and not intended for production environments. If you would like to setup a functional system for your corporate environment, please let us know.
Xtreme Consulting Service’s Deployment Team is ready to assist you with your deployment needs.
Features
When complete, this Buildout (Hydration) system will create:
- A Virtual Machine running Windows Server 2008 (R1) x86 Server Standard.
- MDT 2010, with all dependencies installed (including WAIK).
- OS’es: Server 2008 R1 x86, Windows 7 x86 and Windows 7 x64.
- Microsoft Office 2007 Enterprise Evaluataion Version.
- Applications: 7-zip, Foxit PDF Reader, MacroMedia player, Silverlight player, SQL Server 2008 Express, Sun Java Runtime, Video Lan Player, Windows Debugger (windbg).
- Sample Driver package: Intel Chipset drivers.
- Sample Packages: Windows 7 Language Packs, Hyper-V Drivers, Remote Server Administration Tools (RSAT)
- A Windows 7 Media build DVD image with Office 2007.
- It will also enable a PXE/WDS Service for servicing MDT 2010 WinPE Images (no Domain Controller required).
- A blank Virtual Machine ready to perform a capture of Windows 7 back to the MDT 2010 server.
Requirements
- Your machine must be running windows with a version of either Hyper-V (for Windows Server 2008) or Virtual PC 7 (for Windows 7).
- Your machine must have at least 2GB of ram, and 60GB of free hard disk space.
Walkthrough
Download the MDTBuildout.zip file to your local machine and expand the contents to their own folder. You should see the manual: MDTBuildout.rtf and the Wizard Wrapper MDTBuildout.exe. Go ahead and launch the MDTBuildout.exe.
The MDTBuildout.exe wizard will guide you through the process of creating the virtual machine and downloading the necessary files to get it started. The wizard will create to Virtual Machines:
MDTVirtualServer – This is the Virtual Server that will host MDT 2010. It takes a couple of hours to setup, depending on the speed of your network connection.
MDTVirtualClient – This Virtual Machine will be used later on to capture a reference image of Windows 7 with Office 2007.
It is recommended that you use the default settings during the MDTBuildout.exe wizard, although, you can override the settings if required. Be sure to give the Virtual Machines enough memory, place the *.VHD files on a disk with 40+GB of space free, and select the Virtual Networking adapter with internet access.
When you select “Build” the wizard will begin the process of downloading the Windows Server 2008 Eval *.iso file to the local machine, this file is about 1.8GB. When done, the wizard will automatically create the virtual machines with the required parameters, and start the process. You can continue to watch the progress in the VM window.
The entire build process can take several hours depending on the speed of your network connection. Let the install run. When complete, you should see a dialog showing the status.
The password for the MDT Server is: P@ssword
When complete, you can start the MDT 2010 Workbench (start –> Microsoft Deployment Toolkit –> Deployment Workbench), and view the components added to the system.
The deployment share should be at: c:\deploymentshare
The media share should be at: c:\media
If you wish, you can start the PXE server, to allow other computers on the network to boot into MDT 2010, this is a great way to upgrade machines on your corporate network in a “self-service” fashion. To enable the pxe server, run the command “net start wdsserver”. WARNING: The PXE/WDS Server running on the Virtual Machine *will* conflict with other PXE/WDS servers on the network. Please ensure that you are the *only* PXE/WDS server on the network before starting! This is why the WDS service is disabled by default.
You can also burn the contents of the Win7 Media ISO to a DVD drive. Or perhaps copy the *.iso file to the local machine.
Use this server to evaluate MDT 2010 and try deploying Windows 7 (Evaluation Version), to your test lab.
When ready, you can boot the MDTVirtualClient Virtual Machine, using either the Win7 Media ISO image, or PXE/WDS. The Client Virtual Machine has been specially configured to auto install Windows 7 and upload the captured image back to the MDT 2010 Server in a completely hands off fashion.
More documentation, walkthroughs, and videos to follow.
Link
<Edit> No longer available.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupThe 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
Getting 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 GroupTroubleshooting Database Issues with MDT 2010 November 4, 2009
Posted by tmintner in MDT 2010, Troubleshooting, Uncategorized, VBscript.Tags: Database, MDT, Troubleshooting, ztigather
add a comment
There have been a few really great posts on how to troubleshoot database connection issues with BDD and MDT over the past couple of years. Ben Hunter wrote a great post on this here: http://blogs.technet.com/benhunter/archive/2007/07/10/bdd-2007-troubleshooting-database-issues.aspx. However, if you try to do this with MDT 2010 you will get a few errors in the output. In MDT 2010 the structure of the scripts have changed somewhat and the functionality of ztigather has been extended to also gather additional information that now requires some compiled code. So with MDT 2010, you can perform the same steps with the following modifications:
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
Writing custom scripts with MDT 2010 November 3, 2009
Posted by tmintner in MDT 2010, Uncategorized, VBscript.Tags: custom script, MDT 2010, VBscript
6 comments
Ben Hunter wrote a great blog post a few years ago on how to create a custom VBscript to use with BDD 2007 (http://blogs.technet.com/benhunter/archive/2007/04/15/bdd-2007-ndash-tips-and-tricks-ndash-how-to-write-a-custom-script.aspx). Ben’s script template will still work with MDT 2010 however If you have spent any time looking at the scripts in MDT 2010 you will notice that the format of the built in scripts have changed. So you might be wondering how to create a custom script with MDT 2010. MDT 2010 introduced some script structure changes to better handle error reporting and to make the scripts a bit easier to read and test. The new template is listed below. So how do you use the template? Start by pasting the following code into a script file with a WSF extension (somefile.wsf). After creating the file edit the Class ScriptName with the name of your script. As an example if you named your custom script somescript.wsf then the Class would be Class SomeScript.
Now that you have your script and your class named correctly you can add your code under the Function Main. Once you are finished you just need to save the file and put it into the scripts folder in your deployment share.
So what does the new structure give you beyond what Ben’s post originally pointed out? First it gives you some nice debugging capabilities. Normally you would run your script by calling cscript.exe “%scriptroot%\somescript.wsf” in the task sequence. If you want to use the advanced debugging you can add /debugcapture. Adding the /debugcapture will turn on advanced debugging features by disabling the standard On Error Resume Next in the scripts and capturing any errors in the script that might occur and displaying them to the screen. For example if you forgot to declare a variable the /debugcapture will display the variable that could not be found and the line number that the error occurred on. You can also use your own test hook scripts to unit test the different functions in the script (more on that later). For right now, enjoy the template and we will definitely be posting more custom script samples over the next few months!
<job id=”ZTIConnect”>
<script language=”VBScript” src=”ZTIUtility.vbs”/>
<script language=”VBScript”>
Option Explicit
RunNewInstance
‘//—————————————————————————-
‘// Global Constants
‘//—————————————————————————-
Const ANSWER_TO_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42
‘//—————————————————————————-
‘// Main Class
‘//—————————————————————————-
Class ScriptName
‘//—————————————————————————-
‘// Global constant and variable declarations
‘//—————————————————————————-
Dim iRetVal
‘//—————————————————————————-
‘// Constructor to initialize needed global objects
‘//—————————————————————————-
Private Sub Class_Initialize
End Sub
‘//—————————————————————————-
‘// Main routine
‘//—————————————————————————-
Function Main
‘Insert your code here
End Function
End Class
</script>
</job>
Tim Mintner is a Principal Consultant with Xtreme Consulting Group
Install Driver EXE Package (New Tool) November 2, 2009
Posted by keithga in MDT 2010, Uncategorized, VBscript.comments closed
New Tool! ZTIInstallDriverExePackage.wsf
As I described in my earlier post. MDT has a great system for Driver Management. You import a driver via it’s *.INF file, and that driver will be installed on every machine where that PnP ID is found. No need to associate a driver via a Make/Model.
However, there are some cases (very rare), when a driver package can’t be installed by *.inf file alone, or a *.exe installation package may need to be installed along side a specific piece of hardware.
The ZTIInstallDriverExePackage.wsf tool was designed to allow an Driver *.exe installation package to associate with a set of PnPID’s defined in the Workbench.
Steps
- Download the Driver Installation *.exe Package to your MDT Workbench machine. Ensure that you copy the package to its own directory.
- Add the Application to the MDT workbench as you would any other Application Installation Package.
- You will need to extract out the GUID for the Application added. It may be in the depoyment share under \Control\applications.xml
- Extract out as much of the driver *.inf component as you can to a separate directory (not a sub-directory). There are several tools available on the internet for extracting out compressed files from Self extracting Executables. My personal favorite is 7-Zip (see 7-zip.org)
- Add the Driver Package to the MDT workbench as you would any other Driver Package.
It is not necessary that it be fully functional. However the PnPID’s should be properly added. - Once the driver has been imported successfully. Open the Properties for the new device
- You may disable the driver. Uncheck “Enabled”. Disable only if you want the Exe Package to be the only way for the driver to be installed.
- Add the following string to the comments section:
“DriverExePackage {GUID}”
Where {GUID} is the Application GUID extracted from the 3rd step above.
- Copy the ZTIInstallDriverExePackage.wsf file to the Deployment Share under …\Scripts\
- Add a new Step in your Task Sequence calling ZTIInstallDriverExePackage.wsf
cscript.exe “%ScriptRoot%\ZTIInstallDriverExePackage.wsf”
Script Flow
ZTIInstallDriverExePackage.wsf will operate in a manner similar to ZTIDrivers.wsf.
- It will enumerate though all hardware devices on the machine, and extract out their PnPID’s.
- For each Hardware PnPID found, it will try to match that ID with any driver found in the Deployment Share.
- For each Driver package found it will search the comments field, searching for the “DriverExePackage” string followed by the Application GUID.
- The script will then call ZTIApplications.wsf with the GUID from the Comments section.
ZTIApplications.wsf will do a good job of ensuring that the corresponding application is installed only once.
Assumptions
- In most cases, I personally recommend sticking with the *.inf only method of driver installation. The Exe only method should only be used in rare cases.
- This script uses the drivers.xml file from the distribution share to associate the PnPID’s with the Application GUID. It is important that the MDT Workbench Add the driver package to the system. IT is not necessary for the driver package to actually work. The Driver Package can be disabled if it is failing to work, it should not be removed.
- To associate a Device with an Application Item, you also need to add the Application GUID of the device prefixed with the string “DriverExePackage” into the comments of the driver in the MDT Workbench.
Links
http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/ZTIInstallDriverExePackage.zip
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
