Deploying Windows 7

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part16.html

Part 16: Using the MDT Database


In the previous article of this series you learned how to create and configure the MDT database using Microsoft SQL Server 2008 Express. In this article and ones following we will examine how to use the MDT database to customize how Windows 7 is deployed based on the properties of the target computers, their intended roles, their locations, and their make/model. This present article focuses on the first method, that is, customizing how Windows 7 is deployed based on the properties of the target computer.
Configuring MDT Database Rules

As explained in the previous article of this series, the MDT database lets you store many of the configuration settings used for customizing deployment in a single, central database. These configuration settings are essentially the same as those that can be stored in the CustomSettings.ini file, and using the database allows you to have only one, generic CustomSettings.ini file while the remaining settings are stored in the database. Furthermore, by using the MDT database you can often perform all of your deployments using only a handful of images (such as x86 client, x64 client and x64 server) and only two task sequences (Standard Client and Standard Server). Clearly, being able to understand and use the MDT database is an essential key for simplifying Lite Touch (LTI) deployments.
Let us begin by picking up where we left off from the previous article in this series where you learned how to create the MDT database in SQL Server 2008 Express. Figure 1 shows the properties of the MDT database we created in that article:

Figure 1: Properties of MDT database created in previous article of this series
Let us also examine our CustomSettings.ini file again, which is configured to perform fully automated deployments of Windows 7 Enterprise edition (Figure 2):

Figure 2: CustomSettings.ini file configuring MDT database rules
Now before we can use the MDT database to deploy Windows 7 based on the properties, intended roles, locations or make/model of our target computers, we need to configure our CustomSettings.ini file so that it can use settings we choose to store in this database. To do this, right-click on Database in the Deployment Workbench and select Configure Database Rules. This launches the Configure DB Wizard, which is a bit of a misnomer because it does not configure the database but instead configures your CustomSettings.ini file by adding additional rules to it so that MDT can query the database during deployment. The first screen of this wizard enables MDT to query the database for computer-specific settings and for roles, applications, packages and administrators assigned to the computer (Figure 3):

Figure 3: Enabling MDT to query the database using computer options
Note that for each item selected in this wizard, MDT will use a script to perform the corresponding database query. That means the more items you select, the more queries will be performed and the longer it will take to perform the deployment. This added delay happens right after logging into the Windows Deployment Wizard using the credentials you specified, that is, it happens during the beginning "blue screen" portion of the deployment. On the other hand, the more items you select in the wizard, the more options you will have later for customizing how your deployments can be performed. Personally, I simply recommend you leave all checkboxes selected in this wizard, which is what I'm doing here in this article.
The next wizard page enables MDT to query the database for location names based on default gateways, for location-specific settings, and for roles, applications, packages and administrators assigned to the location (Figure 4):

Figure 4: Enabling MDT to query the database using location options
The next wizard page enables MDT to query the database for model-specific settings, and for roles, applications, packages and administrators assigned to the specified make and model (Figure 5):

Figure 5: Enabling MDT to query the database using make/model options
The next wizard page enables MDT to query the database for role-specific settings, and for applications, packages and administrators assigned to the role (Figure 6):

Figure 6: Enabling MDT to query the database using role options
The next wizard page presents a summary of your selections - verify and complete the wizard. Now open the CustomSettings.ini file for your deployment share and examine the changes (Figure 7):

Figure 7: CustomSettings.ini file after configuring MDT database rules
The new sections in this file are parsed and actions taken in the order specified by the Priority= statement in the initial Settings section. For example, the first section used is CSettings, which queries the contents of the MDT database for computer-specific information concerning the target computer such as the computer's Universally Unique Identifier (UUID), asset tag, serial number, or Media Access Control (MAC) address.
Customizing Deployment Based on the Target Computer's MAC Address

To see how this works in practice, let us add a new entry to the MDT database that specifies the MAC address of a particular computer on our network so that MDT can install Windows 7 onto this computer and assign the computer a pre-specified computer name. In other words, we're going to use the MDT database to identify a particular computer in our organization on which we want to perform a certain type of customized deployment of Windows 7 - this is the essence of what you can do using the MDT database. To do this, right-click on the Computers node in your database and select New to identify a particular computer you want to deploy to by adding a new record concerning the computer to your database (Figure 8):

Figure 8: Step 1 of identifying a particular computer on which you want to perform a customized deployment of Windows 7
In the Properties sheet that opens up for the computer you are going to define in the database, type the MAC address for the computer (Figure 9). The MAC address for the computer can be determined by using Ipconfig (if the computer already has an operating system installed) and possibly also from its accompanying documentation or by using a network card configuration utility that might have been included with the computer's documentation.

Figure 9: Step 2 of identifying a particular computer on which you want to perform a customized deployment of Windows 7
Tip:
The MAC address must be specified in the format XX:XX:XX:XX:XX:XX. If you use any other format such as XX-XX-XX-XX-XX-XX, MDT will flash a red exclamation point icon, and hovering your mouse pointer over this icon will display a tip telling you the mistake you made. So watch out for these flashing red exclamation point icons!
Now let us indicate what type of customization will be performed when Windows 7 is deployed to the computer having this particular MAC address. To do this, select the Details tab, scroll down to the Identification section, and type SEA-DESK-299 as the value for the OSDComputerName property (Figure 10). Note that you must use the OSCComputerName property for doing this - the ComputerName property several lines above this is deprecated and should not be used.

Figure 10: Step 3 of identifying a particular computer on which you want to perform a customized deployment of Windows 7
Click OK to close the Properties sheet and create the new record in the MDT database. The result is shown in Figure 11:

Figure 11: A new record has been created in the MDT database that identifies a computer and allows deployment to be customized for this computer
Now when we boot the computer having this MAC address using my LiteTouch_x64 CD, the computer boots to Windows PE, connects to MDT and the database is queried and the record returned. MDT then uses CustomSettings.ini together with the results of the query to install Windows 7 on the computer and configure the computer's name as we intended, which can be verified by opening the System properties on the computer after MDT finishes the install (Figure 12):

Figure 12: Verifying that the computer has been named SEA-DESK-299 as specified in the MDT database
Customizing Deployment Based on the Target Computer's UUID

As a second example, we can also use MDT to customize how Windows 7 is deployed based on the UUID of the target computer. The UUID of a computer (sometimes called the computer's Globally Unique Identifier or GUID) is a hexadecimal string of the form XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX that may be listed on a label on the outside of the computer's case or on a label inside the case. It may also be specified in the BIOS settings or displayed by the BIOS when the computer is starting up. If none of these helps and you already have a Windows operating system installed on the computer, you can use the following Windows Management Instrumentation (WMI) script that I wrote which lists the computer's UUID along with other information gleaned from the Win32_ComputerSystemProduct WMI class:

' DisplayClassProperties.vbs
' Used to find the UUID of a specific desktop computer
' By Mitch Tulloch (www.mtit.com)
Option Explicit
On Error Resume Next
Dim strComputer
Dim strWMINamespace
Dim strWMIQuery
Dim objWMIService
Dim colItems
Dim objItem
strComputer = "."
strWMINamespace = "\root\CIMV2"
strWMIQuery = ":Win32_ComputerSystemProduct.IdentifyingNumber='MXG5380254 NA540',Name='PY196AV-ABA a1130e',Version='0n31211CT101AMBEM00'"
Set objWMIService = GetObject("winmgmts:\\" & strComputer & strWMINamespace & strWMIQuery)
WScript.Echo "Number of properties of " & strWMIQuery & " class is " & objWMIService.Properties_.count
For Each objItem in objWMIService.Properties_
   Wscript.Echo "Property: " & objItem.name & vbTab & "Value: " & objItem.value
Next

Note that you'll have to customize the following line for your particular computer before the script can work:

strWMIQuery = ":Win32_ComputerSystemProduct.IdentifyingNumber='MXG5380254 
NA540',Name='PY196AV-ABA a1130e',Version='0n31211CT101AMBEM00'"

Specifically, you'll need to use wbemtest.exe to determine how to modify the above line for a particular computer. To learn how to do this, see the earlier article by me on WindowsNetworking.com called Managing Windows Networks Using Scripts - Part 13: A Handy Return-All-Values Script.
For example, when I run cscript DisplayClassProperties.vbs on a particular computer where the line identified has been customized appropriately, the results returned look like this:

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. #All rights reserved.#i
Number of properties of :Win32_ComputerSystemProduct.IdentifyingNumber='MXG5380254 
NA540',Name='PY196AV-ABA a1130e',Version='0n31211CT101AMBEM00' class is 8
Property: Caption            Value: Computer System Product
Property: Description        Value: Computer System Product
Property: IdentifyingNumber  Value: MXG5380254 NA540
Property: Name               Value: PY196AV-ABA a1130e
Property: SKUNumber          Value: 
Property: UUID Value: 843E4800-986A-1010-9814-8CFE95F168A8
Property: Vendor             Value: HP Pavilion 061
Property: Version            Value: 0n31211CT101AMBEM00

From the above script output you can see that this particular computer's UUID is 843E4800-986A-1010-9814-8CFE95F168A8. Now, if I create a new Computer record in the MDT database that specifies this UUID, I can perform a customized deployment of Windows 7 to this particular computer in a similar way as if I had specified the MAC address of the computer

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part17.html

Part 17: Deploying Applications Based on Make and Model


In the previous article of this series you learned how to use the MDT database to customize the deployment of Windows 7 based on computer properties such as the MAC address or UUID of the target computer. In this article we'll learn how to use the MDT database to deploy Windows 7 Enterprise edition together with an application (Microsoft Office 2007 Enterprise edition) based on the make and model of the target computer.
Adding Office 2007 as an Application

The powerful thing about Microsoft Deployment Toolkit is that you can use it to deploy Windows operating system images together with any applications, packages and drivers that may be needed by your users on their target computers. For this walkthrough, we're going to deploy Microsoft Office 2007 Enterprise edition together with Windows 7 Enterprise edition, which is a typical scenario for information workers (IWs). Begin by inserting your Office DVD into the DVD drive of your MDT technician computer. Then open Deployment Workbench, expand your deployment share, right-click on the Applications node and select New Application (Figure 1):

Figure 1: Step 1 of adding a new application to a deployment share
Doing this launches the New Application Wizard as shown in Figure 2 below. We will choose the first option here, which copies the Office installation files from the Office DVD into a folder in our deployment share.

Figure 2: Step 2 of adding a new application to a deployment share
On the next wizard page, we'll type Microsoft as the publisher and Office 2007 Enterprise as the descriptive name for the application; we'll leave the other two fields blank (Figure 3):

Figure 3: Step 3 of adding a new application to a deployment share
On the next page, we will browse to select our DVD drive as the source directory where the installation files currently reside. Note that the option to move the files to the deployment share instead of copying them is grayed out—this is because you can not move files from a DVD, you have to copy them (Figure 4):

Figure 4: Step 4 of adding a new application to a deployment share
On the next page, we will accept Microsoft Office 2007 Enterprise as the name of the folder that will be created within our deployment share to host the application's installation files (Figure 5):

Figure 5: Step 5 of adding a new application to a deployment share
On the next page, we will type setup.exe as the command that will be used to install the application on our target computers (Figure 6):

Figure 6: Step 6 of adding a new application to a deployment share
Once we have finished walking through the wizard, the new application is displayed in the Deployment Workbench within the Applications folder of our deployment share (Figure 7):

Figure 7: Office has been added to the deployment share as an application to be deployed
You are done adding Office as an application in MDT.
Customizing Office 2007 for Installation

Before you deploy an application using MDT, you may need to further configure the application by opening its properties from the Workbench. This is particularly true for Office 2007, which includes its own special Office Customization Tool (OCT) you can use to customize your installation Office prior to deploying it. The OCT lets you customize Office and save your customizations in a Windows Installer (MSI) Patch file having an .msp file extension. Once you create this .msp file, you then save it in the Updates folder of your deployment share. Then, when Office is being installed on the target computer, the Office installation program (setup.exe) looks for an .msp file in the Updates folder of your deployment share, and if it finds one it applies the customizations contained in the .msp file during the installation of Office. For more detailed information concerning customizing Office 2007 installations using the OCT, see this article on Microsoft TechNet.
To customize how Office will be deployed by MDT, right-click on the application in the Applications folder in the previous screenshot and select Properties. This opens the application's properties sheet, which has several different tabs. We'll learn more about what these tabs can be used for in a future article, but for now let's select the Office Products tab as shown in Figure 8:

Figure 8: Step 1 of configuring Office for deployment using the OCT
Now, on the Office Products tab, click the Office Customization Tool button. An information dialog box will be displayed indicating where you need to save the .msp file you will create using the OCT (Figure 9):

Figure 9: Step 2 of configuring Office for deployment using the OCT
Clicking OK closes the dialog box and opens the OCT, which prompts you to create a new .msp file or open an existing one. We'll select the first option to create a new .msp file (Figure 10):

Figure 10: Step 3 of configuring Office for deployment using the OCT
When you click OK, the Select Product box closes and you're presented with the main screen of the OCT (see Figure 11). By clicking on various items on the left, you will be able to customize many different aspects of how Office will be customized during its deployment.

Figure 11: Step 4 of configuring Office for deployment using the OCT
To deploy Office unattended using MDT, we only need to configure the Licensing And User Interface page of the OCT. To do this, make the following customizations as shown in Figure 12 below:

• Type your Office 2007 product key into the textbox.
• Select the checkbox for accepting the EULA.
• Change the Display Level to None, which enables Office Setup to run silently without displaying any user interface.
• Make sure the Completion Notice checkbox is cleared—doing this will prevent Office Setup from displaying a message to the user when the installation is finished.
• Make sure the Suppress Modal checkbox is selected—doing this will prevent Setup from displaying error messages or other dialog boxes that could interrupt the installation.
• The No Cancel checkbox can be used to prevent the user from being able to cancel the installation by clicking the close gadget on the installation UI, but since the Display Level is set to None in this example, there is no installation UI so it doesn't really matter whether you select or clear this checkbox (we'll clear it anyways).

Figure 12: Step 5 of configuring Office for deployment using the OCT
Now let's save our customizations as an .msp file. To do this, select File, Save As from the OCT menu. Then, in the Save As dialog, browse to the following folder:
<drive>\DeploymentShare$\Applications\Microsoft Office 2007 Enterprise\Updates
Now type custom as the name for the .msp file you will create (Figure 13):

Figure 13: Step 6 of configuring Office for deployment using the OCT
You are done customizing Office for deployment.
Determining the Make/Model of a Target Computer

Now remember that our goal is to deploy Windows 7 together with Office 2007 to computers that have a certain make and model. How can you determine the make and model of a specific computer? If this information has not been provided to you by the vendor or displayed on a sticker on the outside or inside of the case, and if a Windows operating system is already installed on the computer you can customize the DisplayClassProperties.vbs script used in the previous article of this series to do this. Simply take the script in that article and replace the following line:
strWMIQuery = ":Win32_ComputerSystemProduct.IdentifyingNumber='M XG5380254 NA540',Name='PY196AV-ABA a1130e',Version='0n31211CT101AMBEM00'"
with this instead:
strWMIQuery = ":Win32_ComputerSystem.Name='INSERT'"
Next, substitute INSERT with the actual computer name of the computer, which can be found using the System utility in Control Panel and for this example is SEA-DESK-115.
Now use cscript to run the script to display the values of all the properties of the Win32_ComputerSystem WMI class:
c:\scripts>cscript DisplayClassProperties.vbs
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Number of properties of :Win32_ComputerSystem.Name='SEA-DESK-115' class is 58
Property: AdminPasswordStatus Value: 3
Property: AutomaticManagedPagefile Value: True
Property: AutomaticResetBootOption Value: True
Property: AutomaticResetCapability Value: True
Property: BootOptionOnLimit Value:
Property: BootOptionOnWatchDog Value:
Property: BootROMSupported Value: True
Property: BootupState Value: Normal boot
Property: Caption Value: SEA-UUID-TEST
Property: ChassisBootupState Value: 3
Property: CreationClassName Value: Win32_ComputerSystem
Property: CurrentTimeZone Value: -360
Property: DaylightInEffect Value: False
Property: Description Value: AT/AT COMPATIBLE
Property: DNSHostName Value: SEA-UUID-TEST
Property: Domain Value: contoso.com
Property: DomainRole Value: 1
Property: EnableDaylightSavingsTime Value: True
Property: FrontPanelResetStatus Value: 3
Property: InfraredSupported Value: False
Property: InitialLoadInfo Value:
Property: InstallDate Value:
Property: KeyboardPasswordStatus Value: 3
Property: LastLoadInfo Value:
Property: Manufacturer Value: HP Pavilion 061
Property: Model Value: PY196AV-ABA a1130e
Property: Name Value: SEA-UUID-TEST
Property: NameFormat Value:
Property: NetworkServerModeEnabled Value: True
Property: NumberOfLogicalProcessors Value: 1
Property: NumberOfProcessors Value: 1
Property: OEMLogoBitmap Value:
Property: PartOfDomain Value: True
Property: PauseAfterReset Value: -1
Property: PCSystemType Value: 1
Property: PowerManagementCapabilities Value:
Property: PowerManagementSupported Value:
Property: PowerOnPasswordStatus Value: 3
Property: PowerState Value: 0
Property: PowerSupplyState Value: 3
Property: PrimaryOwnerContact Value:
Property: PrimaryOwnerName Value: Windows User
Property: ResetCapability Value: 1
Property: ResetCount Value: -1
Property: ResetLimit Value: -1
Property: Status Value: OK
Property: SupportContactDescription Value:
Property: SystemStartupDelay Value:
Property: SystemStartupOptions Value:
Property: SystemStartupSetting Value:
Property: SystemType Value: x64-based PC
Property: ThermalState Value: 3
Property: TotalPhysicalMemory Value: 2078859264
Property: UserName Value: SEA-UUID-TEST\Administrator
Property: WakeUpType Value: 6
Property: Workgroup Value:
Now, from the above script output of property/value pairs, examine these two lines:
Property: Manufacturer Value: HP Pavilion 061
Property: Model Value: PY196AV-ABA a1130e
The Win32_ComputerSystem.Manufacturer WMI property corresponds to the Make property in MDT, and the Win32_ComputerSystem.Model WMI property corresponds to the Model property in MDT. In other words, the Make of this particular computer is HP Pavilion 061 and its Model is PY196AV-ABA a1130e as far as MDT is concerned.
Customizing Deployment Based on Make/Model

To make use of such Make/Model information and deploy Windows 7 together with Office 2007 to computers having this particular Make and Model, we now need to create a new Make And Model record in the MDT database that specifies this particular Make and Model and is configured to deploy Office 2007 to these computers. To do this, expand the Database node for your deployment share in the Workbench, right-click on Make And Model, and select New (Figure 14):

Figure 14: Step 1 of creating a MDT DB record for Make/Model deployment of Office
In the Properties sheet for the new record, type the Make and Model of the target computers (Figure 15):

Figure 15: Step 2 of creating a MDT DB record for Make/Model deployment of Office
Next, click the Applications tab (Figure 16):

Figure 16: Step 3 of creating a MDT DB record for Make/Model deployment of Office
Click Add and select Microsoft Office 2007 Enterprise from the list of applications you can deploy to computers that match the Make/Model specified in this record (Figure 17):

Figure 17: Step 4 of creating a MDT DB record for Make/Model deployment of Office
Click OK to return to the Applications tab which will now show Microsoft Office 2007 Enterprise (Figure 18):

Figure 18: Step 5 of creating a MDT DB record for Make/Model deployment of Office
Click OK to apply the changes and create the new record in the MDT DB. The new record will now be displayed under Make And Model in the Workbench (Figure 19):

Figure 19: A new MDT DB record for Make/Model deployment of Office has been created
At this point we are ready to begin our deployment. Insert your LiteTouch_x64 CD into a computer having the specified Make/Model and turn the computer on. The Windows Deployment Wizard will run completely unattended and Windows 7 will be installed on the computer in the usual way. Once Windows 7 has been installed, the desktop will be displayed and a progress dialog will indicate that Office is being installed (Figure 20):

Figure 20: Office is installed after Windows has been installed
When Office Setup is finished, you should be able to launch Office programs from your Start menu (Figure 21):

Figure 21: Office 2007 has been deployed together with Windows 7 using MDT
Final note

Using Make and Model to deploy Windows using MDT is not as simple as using Computer and specifying the UUIDs or MAC addresses as described in the previous article of this series. To understand some of the complexities involved in using Make/Model for MDT deployment and to learn about some workarounds, see this article on The Deployment Guys blog

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part18.html

Part 18: Determining the UUID of a Computer


Tip:
You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I am the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit where you will find the latest updates and other useful information.
In Part 16 of this series you learned how to use the MDT database to customize the deployment of Windows 7 based on the UUID of each target computer. In that article you also learned how to use WMI to determine the UUID of a computer if this UUID is not displayed in the system's BIOS or accompanying documentation. The method we used to do this however was a bit messy, plus the computer whose UUID you want to determine must already have had a Windows operating system installed on it.
This brings up a question: Can you use WMI to determine the UUID of a computer if there is no operating system installed on it? The answer is Yes. To do this, we first need to clean up the scripting stuff we did in the last two articles. Then we need to build a custom Windows Preinstallation Environment (WinPE) image, add the scripts to this image, and burn the image to CD media. You can then use this CD to boot a bare-metal computer into WinPE and run the script to determine the system's UUID.
And that's what this present article and the next one are all about. First, in this article we'll create a clean little script that will display a computer's UUID without any fiddling around. Then in the next article we'll learn how to create a customized WinPE "tools" CD you can use to run the script on a bare-metal system that has no operating system installed in order to determine the system's UUID. Once you've used your WinPE CD to run the script on a number of target computers, you can enter these UUIDs into the MDT database and deploy customized Windows images to each computer as desired.
Tip: If you are new to WMI scripting, check out my 14-part introductory series of articles on WindowsNetworking.com titled Managing Windows Networks Using Scripts.
Script to Determine the UUID of a Computer

In Part 16 of this series we saw how we could determine the UUID of a computer using WMI as follows:

1. We began with the DisplayClassProperties.vbs script from Part 13 of my earlier series of scripting articles that displays the names of all the properties of a WMI class together with the values of these properties.
2. Next we ran WBEMTEST on the computer to determine how we need to customize the strWMIQuery = <string> line of our script so that the script will work on that particular computer. The actual steps to do this are: (a) run WBEMTEST (b) connect to root\cimv2 namespace (c) click Enum Instances (d) type Win32_ComputerSystemProduct (e) press OK. The resulting output from WBEMTEST is then used as the value of <string> in the above line of our script. And this must be done manually as WBEMTEST output doesn't support copy to clipboard!
3. Then once the script was customized, we ran it on the computer and included as part of the script's output was the computer's UUID.

This was all a bit messy of course—we'd rather not have to run WBEMTEST on the computer or have to customize the script each time we have to run it. And we'd rather just get the script to output the computer's UUID and not a bunch of other stuff as well.
Here's how we can do this. We'll begin with the modified DisplayClassProperties.vbs script taken from Part 16 of this series:
' DisplayClassProperties.vbs
' Used to find the UUID of a specific desktop computer
' By Mitch Tulloch (Mitch Tulloch, MVP, lead author of the Windows 7 Resource Kit from Microsoft Press��������������� �)

Option Explicit
On Error Resume Next
Dim strComputer
Dim strWMINamespace
Dim strWMIQuery
Dim objWMIService
Dim colItems
Dim objItem
strComputer = "."
strWMINamespace = "\root\CIMV2"
strWMIQuery = ":Win32_ComputerSystemProduct.IdentifyingNumber='M XG5380254 NA540',Name='PY196AV-ABA a1130e',Version='0n31211CT101AMBEM00'"
Set objWMIService = GetObject("winmgmts:\\" & strComputer & strWMINamespace & strWMIQuery)
WScript.Echo "Number of properties of " & strWMIQuery & " class is " & objWMIService.Properties_.count
For Each objItem in objWMIService.Properties_
Wscript.Echo "Property: " & objItem.name & vbTab & "Value: " & objItem.value
Next
Now, to accomplish what WBEMTEST does and return the instances of the Win32_ComputerSystemProduct class, we'll need to use the SWbemServices.InstancesOf method of the SWbemServices object. To figure out how to do this, I simply adapted the following script from a page of the good old Windows 2000 Scripting Guide (see here):
strComputer = "."
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colSWbemObjectSet = objSWbemServices.ExecQuery _
("SELECT * FROM Win32_Service")
For Each objSWbemObject In colSWbemObjectSet
Wscript.Echo "Name: " & objSWbemObject.Name
Next
My customized version of the above script looks like this:
strComputer = "."
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colSWbemObjectSet = objSWbemServices.ExecQuery _
("SELECT * FROM Win32_ComputerSystemProduct")
For Each objSWbemObject In colSWbemObjectSet
strIdentifyingNumber = objSWbemObject.IdentifyingNumber
strName = objSWbemObject.Name
strVersion = objSWbemObject.Version
Next
Wscript.Echo "IdentifyingNumber: " & strIdentifyingNumber
Wscript.Echo "Name: " & strName
Wscript.Echo "Version: " & strVersion

The reason I need the above script to determine the values of the three properties IdentifyingNumber, Name and Version is because the Win32_ComputerSystemProduct class has three key properties, namely (you guessed it) IdentifyingNumber, Name and Version. To see this, refer to the documentation page for this class on MSDN. Remember that a key property is a property that provides a unique identifier for an instance of a class, and to connect to an instance of a class, you need to specify a particular instance by using the key property of the class. Key properties are marked with the "Key" qualifier in MSDN documentation—refer back to Part 13 of my earlier series of scripting articles for more information concerning key properties.
Now I simply need to merge the above customized script with my earlier DisplayClassProperties.vbs script in order to create the following new script which I've named UUID.vbs (note that I've simplified this script by omitting variable definitions and error handling):
'UUID.vbs
'Displays the UUID of a computer
'By Mitch Tulloch (Mitch Tulloch, MVP, lead author of the Windows 7 Resource Kit from Microsoft Press��������������� �)

strComputer = "."
strWMINamespace = "\root\CIMV2"
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM Win32_ComputerSystemProduct")
For Each objSWbemObject In colSWbemObjectSet
strIdentifyingNumber = objSWbemObject.IdentifyingNumber
strName = objSWbemObject.Name
strVersion = objSWbemObject.Version
Next
strWMIQuery = ":Win32_ComputerSystemProduct.IdentifyingNumbe r='" & strIdentifyingNumber _
& "',Name='" & strName & "',Version='" & strVersion & chr(39)
Set objWMIService = GetObject("winmgmts:\\" & strComputer & strWMINamespace & strWMIQuery)
For Each objItem in objWMIService.Properties_
If objItem.name = "UUID" Then
Wscript.Echo objItem.name & " = " & objItem.value
End If
Next

Note that the tricky part here is making sure the quotes are correct in the strWMIQuery = <string> statement. For instance, the statement ends with & chr(39) which appends the single quote needed to properly complete the syntax of the statement. It took some fiddling to get this to work—the trick that helped me was to temporarily insert a Wscript.echo strWmiQuery statement immediately after the strWMIQuery = <string> statement so I could run the script and output the contents of the string to see whether the string had the correct syntax, then make a change and run the script again, and so on until I got the syntax right.
Testing the Script

Now let's see if our script works by running it from the command-line on a computer that has Windows XP installed on it (Figure 1):


Figure 1: Running UUID.vbs on a computer that has an operating system

Let us make our script even easier to run by creating an accompanying batch file named UUID.bat that reads as follows:

@ECHO OFF
cscript.exe //nologo UUID.vbs

This makes it easier to run the script and also makes the output cleaner (Figure 2):


Figure 2: Running UUID.bat on a computer that has an operating system
Conclusion

Now that our script is ready, we need to build a WinPE image and include our script in this image so we can run our script on bare-metal systems. You will learn how to do this in the next article of this series