jump to navigation

Troubleshooting Database Issues with MDT 2010 November 4, 2009

Posted by tmintner in MDT 2010, Troubleshooting, Uncategorized, VBscript.
Tags: , , ,
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

Prevent machine from falling asleep. November 4, 2009

Posted by keithga in Uncategorized.
comments closed

Erik, asked about a post from last week regarding “Falling asleep on the job (task)”:

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

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/KeepAlive.zip

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Writing custom scripts with MDT 2010 November 3, 2009

Posted by tmintner in MDT 2010, Uncategorized, VBscript.
Tags: , ,
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

Quickly add MSI package to MDT 2010 (New Tool) November 3, 2009

Posted by keithga in MDT 2010.
comments closed

New Tool! MDTMSIApp.exe

This tool can quickly import an application defined in a MicroSoft Installer (*.msi) package. This tool will extract out many of the required fields required to import an Applicaiton into MDT 2010 directly from the *.msi meta-data.

One of the most most overlooked features of MDT is the ability to define the “Uninstall registry key name” for each Application Item. When defined, during install time ZTIApplications will skip over the installation of any application by checking the windows registry.

This is a “Best Practice” for applications, as it will save time and errors during installation if a subset of applications were installed previously. The most common scenario is a set of applications that are installed in the base “Common” image before sysprep. Then afterwards, the user is provided a “full” list of applications to install, MDT install will easily skip over any application already installed in the base image.

There is also a command line interface below for scripting.

Fields auto-generated

The following Fields are Auto-Added:

  • ShortName – Generated from the name of the *.msi package.
  • Folder – Placed in the root of .\Applications by default. Can be changed in the command line.
  • Version – From the MSI Package “ProductVersion”.
  • UnInstallKey – From MSI Package “ProductCode”.
  • Publisher – From MSI Package “Manufacturer”
  • Name – From MSI Package “PackageName”
  • DisplayName – From MSI Package
    “Manufacturer” + “PackageName” + “ProductVersion”
    (If the Manufacturer name is duplicated in the PackageName, only one is added).
  • CommandLine – The following default command line will be used:
    ‘msiexec.exe /qb- /l*vx %LogPath%\<ShortName>.log REBOOT=ReallySuppress /i <MSIFile>‘

Links

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/MDTMSIApp.zip

Keith

Keith Garner is a Deployment Specialist 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 Group

Background on Driver Installation in MDT November 2, 2009

Posted by keithga in MDT 2010.
1 comment so far

Most Drivers are installed via an *.inf file. These *.inf files contain all the meta-data needed to define what a driver does, what devices it’s used for, and how it’s installed, including files, registry keys, and any other custom action(s).

When a new hardware device is added to the system, Windows will detect the device and gather as much information about it as possible. This includes a list of Plug and Play Device ID’s (PnPID’s) that are unique to that make and model of device. For example:

PCI\VEN_8086&DEV_4236&SUBSYS_10118086

An *.inf file in turn will contain a list of Plug and Play devices its compatible with.

Matching

When presented with a list of Devices, and a collection of drivers, the OS will find all combinations that match, and determine which one is the best (most descriptive) match.

What’s cool about MDT is if you have more than one possible match, the MDT system will copy all possible matches to the OS. Windows has Driver Ranking Algorithms that will determine the best possible match given a set of possible matches.

It can be important, therefore, to insure that you keep your MDT Driver store clear of all duplicates.

Driver Install Packages

Most hardware manufacturers will produce a driver in two parts:

  • A basic driver package, Containing an *.inf file describing the package, a *.sys file containing any driver code, and a *.cat digital signature. The digital signature indicates that the driver has gone through some basic testing, what it’s origin is, and that it has not been tampered with. This driver package could be copied to Windows Update or the Windows Update Catalog, and is typically the kind of driver package that is best when importing drivers into MDT 2010 workbench.
  • In addition, a company may wish to include add-ons: Tools, Utilities, or Setup wrappers for end-users to install the drivers from the *.inf package more easily. An example might be an advanced radio tuning tool included with a Wi-Fi Driver, or perhaps a Video Communications sample included with a Web-Cam driver. These packages are typically optional, however sometimes they may be required.

When searching for a basic driver *.inf package, typically the best place to start is looking *within* an *.exe Driver Install Package. I like to use 7-Zip to search within self extracting *.exe files for *.inf files.

MDT Drivers

MDT was designed to handle the OS relationship between Devices and Drivers. In other systems, you might assign a driver package to a specific Make and Model. However, whenever a new system comes out, you need to re-define the relationship between the drivers and the Make and Models. Say you have the drivers defined for the Dell D620, and you need to add support for the Dell D820. These two machines mostly share the same class of components, with the same PnP ID’s. With the Driver system in MDT, the drivers are not associated with the Make/Model, instead they are associated with the PnPID of the device itself. All the components of the Dell D620 will automatically be used in the D820, if they share the same PnPID (same device), which in this case they mostly do.

 

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Tools Week at Xtreme Consulting Deployment Team November 2, 2009

Posted by keithga in Announcements.
add a comment

Got some tools to share this week.

As many of you already know Tim, Keith, and about a half dozen other Specialists from Xtreme Consulting have recently come off an engagement with Microsoft, where we worked on the development team for the Microsoft Deployment Toolkit 2010.

We are all extremely proud of this product, having worked many long hours, to see a final product of such immense ability, and high quality.

During that time we developed solutions to solve “hundreds” of different problems and scenarios.

Submitted for your approval this week, is a collection of “other” tools for MDT 2010. Some of these tools fit a small niche, others are just demonstrations.

  • We have a couple of driver examples.
  • Some tools for importing and exporting applications
  • And time permitting, some Powershell Scripting Demos!
Do you have a problem that needs to be solved?
Do you have an idea, and need someone to execute it?
We are here to solve your Deployment Challenges. Large or small.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group