Jeff Huston at myITforum.com

Server Metadata in SCCM

jhuston — Tue, 21 Jul 2009 21:41:00 GMT

It is not uncommon to need additional data to be stored about a server or set of servers.

Who the responsible parties are (owners of the server or applications)
What applications the server supports (logical business systems that span multiple servers)
Maintenance information
And more

SCCM does a great job of inventorying the details of a system - the hardware installed, the applications installed, etc. It does not, however, have any mechinsm built in for collecting random bits of data that identify a server as part of a "system" of servers. For instance, you may have a multi-tier app that has a database server, a web front end, and a job server. SCCM clearly identifies the software bits that are installed on each of these servers but does not identify that the servers are related in some way.

With the tool available in the attachment to this entry, you have the option to add metadata to the server that is captured and can be used in reporting as well as collection assignment for targeting.

Since this is just metadata, it doesn't have to be limited to just logical business systems. You can include information such as who the responsible party for a server is or the maintenance window assignement for a server. You can determine which environment a non-production server is a part of. You can be as creative as you wish (or need) to be.

The attachment has four files in it:

MetaData_v1.1.1.hta. This is the main application that should be advertised to your systems. It allows for the editing of meta data on each server.
MetaData.SMS_DEF.MOF. This is an excerpt that should be inserted into your SMS_DEF.MOF file in order to allow SCCM to capture the metadata during hardware inventories.
MetaData.Reports.MOF. These are some sample reports that you can use that utilize some of the metadata. Some of the reports require a particular categorization to the metadata tags, so you may need to modify them.
Server MetaData Tool Overview.pdf. This document provides an overview of the tool and how it works. It also provides some ideas for tags and how to format them.

The HTML application, when it is run, does connect up to the management point to read in current tags. It assumes that the SCCM WMI provider is installed on the MP (since it just calls into that structure to identify the current tags). You may need to modify the query portion of the tool to connect to the correct server and if the WMI class name is different in your environment. Since it does do this connection, users who run the tool must have the right to read the SMS_site WMI repository on the site server. Usually not a big deal - just add them to the SMS Administrators group on the site server (which authorizes the ability to connect to the WMI provider but does not assign permissions within the app itself).

Let me know if this is useful to you.

Sysprep.inf and SCCM Image Capture

jhuston — Wed, 23 Apr 2008 15:09:00 GMT

When using SCCM to capture a computer image (such as under Microsoft Deployment Toolkit 2008), it is sometimes necessary to provide a custom Sysprep.inf file to be used with the Sysprep process (the Prepare Windows for Capture step).

In our environment, for instance, we do not have the Sysprep process preload all of the built in drivers (the Automatically Build Mass Storage Driver List option) because of the amount of time it takes for that to occur. Instead, we use OEM drivers for most everything. This works great until we get to Virtual Machines (VMware and Microsoft) where drivers are not provided. Instead, we must use the driver from the OS. Since SCCM cannot force in a driver that is originally part of the OS, we must have a custom Sysprep.inf file configured to preload just those specific drivers.

It is not obvious, however, where to place that Sysprep.inf.

We discovered that the Sysprep.inf file should be placed into the SCCM package that holds the Sysprep.exe and associated files. SCCM copies this directory to the hard drive fo the system being captured and will make use of that Sysprep.inf file.

When deploying the image, you can specify a diferent custom sysprep.inf file in place of an unattend.txt file to customize the setup of the system. Under the Microsoft Deployment Toolkit 2008 way of doing things, this deployment sysprep.inf file is located in the same place as the CustomSettings.ini file.

Since the original sysprep.inf file used for capture will be replaced with the custom one, you need to make sure that you modify the deployment sysprep.inf file to include the [Sysprepcleanup] section so that unused drivers will be successfully removed. You can get this section by using IMAGEX to mount a captured image WIM file and locating the Sysprep.inf file in the \Sysprep directory. The section is usually located at the end.

Problem with Software Updates and New SCCM Child Sites

jhuston — Thu, 14 Feb 2008 13:41:00 GMT

In our environment, we recently added two new child sites to our System Center Configuration Manager 2007 hierarchy. The parent site had been running for several months prior to the addition of the child sites.

While that parent site was up and running, we used it to perform typical software update tasks such as the packaging and deployment of updates. We would create a new update list and deployment for each monthly issuance of updates from Microsoft. Rather than make monthly deployment packages, the patches were downloaded to a single annual package (thus 2007-10, 2007-11, and 2007-12 were sourced out of the 2007 deployment package).

All was working just fine until I added the child sites.

The child sites are automatically configured to have WSUS synchronize from the parent site's WSUS server. This part worked out just fine. The child WSUS server obtained the list of updates successfully. The break in the process, however, came with the synchronization of the SCCM database.

With the parent site, the SCCM database gets its data from the local WSUS server. The child sites, however, get their database data from the parent SCCM database rather than the WSUS server. This means that the child sites separate the WSUS synchronization from the database synchronization.

The SCCM database table that holds the lionshare of the data for the software updates process is the CI_ConfigurationItems table. This table holds records for each update known to the system as well as each of the update lists, deployments, and deployment packages definitions. Part of these definitions indicate when a particular update is superseded by another and when an update is expired.

There does seem to be a mechanism to tombstone entries so that they are properly replicated, but the tombstone lifetime does not appear to be sufficient. It is unclear which Delete Aged XX Data site maintenance task is responsible for getting rid of the data, but in my case, the expired data had been removed from the system.

Now because I had been using the parent site for longer than the tombstone lifetime, I still had packages, deployments, and update lists that referred to data that was no longer present (or at least would not replicate to the child site). Because of this, the child site would not correctly replicate the package or deployment. Even though all other updates were available and valid, the child site would not allow the replication to succeed. This was a huge problem.

At first, I tried forcing the CI_ConfigurationItems table to re-replicate (I updated the LastModifiedBy text field on all rows). The replication process was kicked off successfully (it took 4-5 hours to complete), but I was still missing the data. On the child site, the objreplmgr.log file would contain records similar to Referenced configuration items are not available yet and list the unique identifiers for the item that was needed. In addition, the inboxes\objmgr.box\INCOMING\Retry folder would have a large number of .CID files in it. Obviously there was some problem here.

Turns out, the problem was the expired updates. On the parent site, I went through all of the deployment packages, deployments, and update lists and removed the expired updates from them. Once that was completed, the replication was successful and the child sites now had fully registered versions of the lists/deployments/packages.

So, the lesson here is to find those expired updates and remove them from the referencing lists before you add any child sites. Theoretically, the tombstoning should catch it properly when a child site exists, but that still bears some discovery to see if that part works (I have my doubts as I have the system downloading definition updates every few hours, which would expire previous updates and the IsTombstoned flag is never set in the database table).

Long post, but hopefully this will help someone else out there.

OPINION: Software Updates or Software Deployments

jhuston — Thu, 20 Dec 2007 20:18:00 GMT

Under SCCM (and SMS), there are two different methods for the deployment of software "bits" to an end-user's system. These two different methods have clear distinctions in how they operate and what they should be used for, but there is a gray area between them that can be a bit muddled to deal with.

Software Updates

The Software Update system in SCCM is designed, primarily, for the distribution of binary patches to existing software. The most obvious example are Microsoft security updates. These updates are installed in, essentially, a non-interactive mode and return a simple numeric exit code to determine success, reboot needed, or failure. SCCM has a built in detection mechanism and uses state messages to track the progress of deployment.

Software Deployments

The Software Deployment subsystem, however, is designed to distribute full software packages - especially new installations. Software is expected to return either an exit code or a MIF file to determine status. Deployments are targeted to collections of computers that must use membership queries (based on inventory) to determine applicability of the package. For instance, if the primary console user of a machine is in a particular user group, deploy (or offer to deploy) the ACME Widget software.

The gray area starts to show up when a software update is provided as a full software package. Think of Apple QuickTime Player or Adobe Reader as examples. Although IT staff wish to deploy the updated version due to security vulnerabilities, they are faced with deploying a full product.

Most of these products come as a collection of files, which Software Deployments are good at delivering. However, in many cases, those files can be collected into a self-extracting executable (such as one created by the SMS Installer), which is what is required by Software Updates.

Since it is an update, it is tempting to use Software Updates to determine its applicability and handle the deployment. The rules provided by Software Updates, however, are essentially the same as what is available to collections for Software Deployments (registry keys, file information, WMI lookups).

What doesn't help the matter is when vendors provide what are essentially full software installs as Software Updates. Dell does this. Even Microsoft does this (such as Windows Live branded products).

For items that do not come in a catalog (where we would have to use the Custom Updates Publisher), we have chosen to stay faithful (if that is the right term here) to the original purpose of Software Deployments vs Software Updates.

If the software is a single-file binary patch, it goes through Software Updates. If it is a full version of the software, it goes through Software Deployments.

Hopefully this advise helps some out there.

SCCM Maintenance Windows and Software Updates

jhuston — Tue, 18 Dec 2007 18:08:00 GMT

SCCM has made huge changes and improvements with software update delivery/installation as well as the introduction of very much needed functionality with service windows.

However, there are some "gotchas" for maintenance windows that you should be made aware of.

With regular software deployments, the maximum runtime value is used to determine if the program will be run within a given maintenance window. For software updates, there is no opportunity to input this data. Instead, SCCM has defaulted to a runtime of 35 minutes per software update (75 for each service pack). When the update deployment routine runs, it requires a maintenance window of at least 35 minutes in order to deploy the updates.

Another gotcha is users that configure their own update installation schedule via the Configuration Manager control panel applet (on the Updates tab). If the user selects a time that is outside of defined maintenance windows, the updates will NOT be installed. It appears that SCCM just treats this as another schedule item and evaluates it like any other running program (with maintence window exclusions in-tact if excluded by the original advertisement).

Finally, software update deployments that have a grace period of, say two weeks, assigned to computers with a maintenance window between the original advertisement and the mandatory deadline will not install automatically during one of the intervening maintenance periods. The software updates will only be automatically installed once the mandatory deadline has been exceeded (during the next maintenance window). If you have laptop computers, this may prove to be challenging to setup correctly and to establish end-user expectations. For example, if the mandatory period is set for Thursday night at midnight (during a maintenance window), if a computer is on, it will be patched and rebooted. If the computer was off during the maintenance period but comes on the following morning, one of two things will happen. If the exclusion to only run during maintenance windows is enabled, the laptop will not get the updates. If the exclusion is to run anytime after the mandatory date is reached, the computer will get the patches and potentially reboot (if that exclusion is also enabled).

Scripts in SCCM 2007 DCM Configuration Items

jhuston — Fri, 14 Dec 2007 22:42:00 GMT

DCM in SCCM 2007 allows the administrator to use scripts to detect if a particular configuration item is applicable as well as if a particular setting is valid. Unfortunately, the documentation that comes with the product does not show how to author the scripts to make it work. I found the info in the beta version of the SCCM SDK (thanks to Wally Mead for the clue) and I wanted to share with you what I've found.

Detection Method Scripts

For Application configuration items, you can specify a script to determine if an application is installed (as opposed to an MSI installation GUID). To do that, simply create a script that returns any kind of text. If text is returned, DCM believes that the application is installed. If no text is returned, DCM believes that the application is not installed.

For example, I've created a configuration item that ensures that any Intel NICs installed in Windows XP workstations is set to AUTO. In order to do this, I need to know if the Intel NIC is installed. I use the following script to do this:

Set WMI = GetObject("winmgmts:\\.\root\cimv2")
Set RS = WMI.ExecQuery("SELECT * FROM Win32_PNPEntity WHERE DeviceID like 'PCI\\VEN_8086&DEV_109A%'")
If RS.Count > 0 Then WScript.Echo "Device Found"

You can see that if a matching device is found, text is returned, causing DCM to continue processing the configuration item.

Setting Scripts

For setting validation scripts, DCM treats text returned as the "value" of the script. This is similar to looking at a REG_SZ registry key. You can evaluate based on the specific text returned to return an Information, Warning, or Error level event. In addition, you can ensure that some string is returned by setting the Report a non-compliance event if the instance count fails and set the requirement to be Greater than 0.

For the same example, here is the script used:

'This script will check the speed duplex setting
'
DeviceIDs = Array("pci\ven_8086&dev_109a")
'
Set REG = GetObject("winmgmts://./root/default:StdRegProv")
'
Const HKLM = &H80000002
Const Root = "SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}"
'
'Enum configuration subkeys
REG.EnumKey HKLM, Root, ConfigKeys
'
'Look for matching device id
For Each ConfigKey in ConfigKeys
MDID = ""
On Error Resume Next
REG.GetStringValue HKLM, Root & "\" & ConfigKey, "MatchingDeviceID", MDID
On Error Goto 0
For Each DID in DeviceIDs
  If Left(UCase(MDID),Len(DID)) = UCase(DID) Then

'Check the speed setting here
   REG.GetStringValue HKLM, Root & "\" & ConfigKey, "SpeedDuplex", SD
   If SD = "0" Then
    WScript.Echo "Set correctly"
   End If
  End If
Next
Next

For the Validation tab, I'm checking that the string returned is "Set correctly" and that there is at least 1 string returned.

Hope that this helps!

Dell PowerEdge R900 in BDD

jhuston — Thu, 13 Dec 2007 14:13:00 GMT

We are starting to deploy the new Quad-Quad Dell R900 servers here (16 cores) via BDD 2007. We have had great success with the Dell PowerEdge 2950, which uses a similar Braodcom dual-driver NetXtreme II 1GigE net card.

For the 2950, we would run a custom script in Windows PE to load both halves of the driver stack (since Win PE does not detect newly attached PnP devices). The drivers that worked for the 2950 would NOT work for the R900.

Dell, unfortunately, did not make drives available for the R900 in a format that could be used. Via their support site, I could download the installer package for the drivers, but it attempts to actually install the drivers, not just deliver them in a flat directory for me to import into BDD. What to do?

I downloaded the CD-ROM ISO that Dell provides for OS installation. This CD would normally be used by booting off of it and running through a little wizard to configure an UNATTEND.TXT file, then swapping it out for the OS CD/DVD upon which the installation completes. Obviously, the drivers for the system must be in there somewhere.

Buried on the CD was a tool to handily extract said drivers for me. Buried in the Server_Assistant\Driver_Tool\Bin directory (from the 5.3 version of the CD) was a tool called make_driver_dir.exe. This tool would take a couple of parameters and provide a directory of extracted drivers for a given server model and operating system. The CD supports all 6th generation servers up through the current models and for the following operating systems:

Red Hat Linux in 32-bit (rh30, rh40, rh50) and 64-bit (rh30_64, rh40_64, rh50_64) versions
SUSE Linux in 64-bit (suse9_64, suse10_64) versions
VMware ESX (esx310)
Windows 2000 (w2000)
Windows 2003 (w2003, w2003_64, w2003sbs)
Windows 2008 (w2008, w2008_64, winlh, winlh_64)

The nicknames listed in bold are the OS names to use with the tool to extract drivers.

Using this tool, I was able to obtain working Broadcom drivers that work for the system. In addition, I changed how I install those drivers.

For Windows PE, I am now making use of the monolithic stack drivers (the RIS driver) since I now have a version that is 64-bit. I had to clean up the INF file a bit before importing it into the BDD Workbench (remove the empty sections 64-bit sections from the 32-bit driver and the empty 32-bit sections from the 64-bit driver). When will manufacturer's learn?

For the OS build, I now include the virtual bus driver (which is tied to the actual PCI device ID) in my SYSPREP.INF file (along with RAID card drivers). This causes that driver layer to be pre-installed for deployment and will be removed if not needed (just like unusued RAID cards). In addition, the Broadcom NIC drivers (that associate with the virtual device ID) are located in a static directory that is referenced in Sysprep's OEMDriverFiles search path. This was done because BDD only includes drivers for devices that it enumerates while under Windows PE (which would exclude the virtual NIC device).

So, with all of that done, my Windows PE deployment is much more streamlined and I can successfully deploy to R900 (and 2950) servers.

HAL Replacement in BDD

jhuston — Thu, 09 Aug 2007 17:25:00 GMT

Many of you folks probably attended the session at TechEd on building a single master image. There was a sample script in there about replacing the HAL. Based on that script and other knowledge gleened around the internet, I've created a BDD-compliant script that will replace the HAL.

Please see the script in the attached ZIP file.

To use the script, save it to the Scripts directory in the Distribution$ share, and then add it to the task sequence in the PostInstall phase (I have it nudged between the Configure and Install Drivers tasks).

The script will examine the HAL being used by Windows PE (which indicates if the chipset is PIC or APIC) as well as the number of processors installed (via WMI). Based on that information (along with whether the target system is 32-bit or 64-bit), it will update the Sysprep.inf file with the appropriate command (UpdateUPHAL or UpdateHAL) as well as copy over the correct HAL.DLL and NTOSKRNL.EXE images (so that mini-setup can boot).

Give it a whack and let me know if you have any issues.

UPDATE 9/4/2007

I found an error in the script when it is run against a flat-file installation (i.e., when creating an image). I've posted an updated version of the script that should correct that error.

SMS Schedule Token Strings

jhuston — Mon, 30 Jul 2007 20:19:00 GMT

In many places, SMS uses a 16 character string to represent one of the SMS_ST schedule token WMI class objects. SMS provides a way to convert between the textual representation and the WMI object via the SMS_ScheduleMethods object.

Unfortunately, this object is only available via the site server. Unless you wish to allow all of your users and machines to directly access the WMI on your site server (not recommended), you are at a loss as to how to convert these strings into useful data.

Well, I took the time to reverse engineer the text strings into their objects and have provided some documentation on how the 16 character interval string is formulated (see the attachment). In addition, in the attached document, is sample VBScript code to encode and decode these strings. Take a gander. Let me know if you have any questions.

Note that this may change for SCCM 2007 (since the string itself is undocumented for SMS 2003).

Hardware Device Enumeration and Driver Installation in Windows PE 2.0

jhuston — Thu, 26 Apr 2007 17:53:00 GMT

Microsoft Windows PE 2.0 is an improvement over the previous versions of Windows PE. This new version is built on the Vista kernel and has updated components. But with this upgrade come a couple of caveats.

In PE 1.x, there was a difference between factory -minint and factory -winpe in how plug and play device enumeration and driver installation was handled. With the -minint switch, the enumeration occurred only once. With the -winpe switch, enumeration was much more exhaustive.

My example where this makes a difference is the Broadcom NetXtreme II Gigabit Ethernet NICs (specifically in Dell PowerEdge x950 servers, but also in models from HP and others). This NIC has a dual-layer driver model. Essentially, there is one driver (matched to the hardware's PCI device ID) that creates a virtual driver bus. A second driver is necessary (matched to the virtual bus's device ID for the NIC) that is the actual network layer driver. This was done so that the NIC could be used as an iSCSI interface (same VBD driver matched to the physical layer but a different top-level driver).

With -minint, the VBD driver would be installed but the driver for the NIC itself would not be loaded. With -winpe, an exhaustive check was performed that would catch the "installation" of the new virtual bus, enumerate it, and then install the network layer driver.

Windows PE 2.0 no longer has the -minint or the -winpe switches. Instead, it appears (in my experience) to operate equivalent to the -minint switch mode -- it will only install drivers for devices found during the initial enumeration.

In a previous post, I mentioned the use of HWPNP.EXE from Paraglider to work around this issue. I found this utility from the Bart's PE build documentation. This utility works well and quickly. However, it only works under 32-bit Windows PE 2.0. I do not know if they plan on providing a 64-bit version in the future, but it became necessary for me to have something that would work under 64-bit Windows PE 2.0 (because I was in the process of installing Windows Server 2003 Enterprise x64 which requires a 64-bit PE shell to launch from).

So, I took the idea of what HWPNP does and coded it up as a VB script file. Essentially this file locates the INF directory in Windows PE 2.0, enumerates the INF files and builds a list of device IDs that are supported by those INF files. Then it enumerates all devices via WMI and, if no driver is currently installed, it uses the DRVLOAD command to attempt to load the matching driver (via the discovered INF files). It then repeats this process until it has enumerated through the WMI list and not installed a driver.

Save the attached TXT file and change the extension .WSF. In our environment, we have modified the UNATTEND.XML file for the Windows PE build so that it calls the script prior to either launching a command prompt (or in the case of BDD, launching the wizard). That way, network and devices are present for the BDD driver injection scripts.

BDD Task Sequences Stink; Well, No They Don't; Well, Maybe

jhuston — Thu, 15 Feb 2007 18:28:00 GMT

Interesting title. I guess you can see my frustration with task sequences as they are used in BDD 2007. The Deployment Workbench is where the problem lies, especially in how it lets you screw up task sequences.

The task sequencing is a powerful feature of BDD 2007 (and SCCM 2007) and it definitely has its place. The problem comes with the way that DW lets you add items to it and how those items become "disconnected". Specifically, I'm talking about applications here.

I started out using the task sequence for my build to add in my custom applications that I wanted in my workstation/server images. The first application I tried would install just fine. It was only after I started to make changes that I noticed the issue. You see, I would make a change to the command-line in the Applications "table" in the Distribution Share section of the DW. Those changes would not get used by the task sequence. When DW adds the application to the task sequence, it copies the then-current command line to the TS.XML file and then that's it. Any changes to the application entry in DW do not get replicated over to the task sequences that use it.

The second issue comes with reboots. The application table allows you to specify that a particular application needs a reboot of the computer after installation. When you add this type of application to the task sequence, the reboot request is not part of that addition. If you need a reboot, you must manually add in a reboot task to the sequence. The task sequence quickly starts to lose some of its shine.

So, I took a giant step back and said to myself "what other way could I get applications to install on the system?" Well, the task sequence so conveniently has a call to the ZTIApplications.wsf script. This script processes that fancy applications table from the deployment share part of DW. It will correctly handle the reboots as well as command-line changes to application installs. Now, how to get my build computer to have applications assigned to it.

The applications are assigned via the CustomSettings.ini file. At first, I was adding them in manually. Unfortunately, you must know the GUID of the application that you want to install (which can only be found by manually reviewing the Applications.XML file in the CONTROL folder). Not fun.

I then moved on to using a database version of CustomSettings (where it looks everything up from a database). This way, I can use the DW GUI to manipulate the sequence of applications and pick from a list. I ended up creating a "role" that has the applications that I want installed in my image. I then assigned that role to my specific build computer. Now, when the computer is built, it gets the correct applications.

So, I recommend using roles wherever possible and avoiding making changes to the task sequence.

BDD 2007 for Server OS Deployment - Trial 3

jhuston — Thu, 01 Feb 2007 15:14:00 GMT

Okay, on with the continuing saga. So far, I've managed to get Windows PE 2.0 to recognize my "unique" network card. Now, when it boots into Windows Server 2003 after completing setup, I discover that the network card is no more. What happened?

Well, here's what happened. The script that copies drivers onto the hard drive has a unique method of operation that probably works fine in most cases, but not here. Here's how Microsoft's provided script works:

On the destination computer, enumerate all plug and play device IDs into an XML file
Enumerate through the PNP device IDs

For each PNP ID, see if there is a match in the BDD Workbench list of Out-of-box drivers
If there is a match, see if the driver belongs to one of the driver groups authorized for this computer (combination of the driver group specified in the Build configuration and the CustomSettings.ini)
If all of that comes out positive, then copy the driver to the C:\Drivers directory on the destination computer and update the UNATTEND.TXT file.

So, here's my issue with that. As you may recall, my network card (the Broadcom NetXtreme II) uses multiple drivers. The first is a virtual bus driver which maps to a PNP PCI bus ID. Once loaded, this driver then establishes new "virtual" devices on the "virtual" bus which then would load the NDIS or iSCSI drivers. Since the PNP enumeration only happens once, it never sees these virtual devices and therefore never copies them down to the destination computer.

Another issue is what if I wanted to essentially pre-stage device drivers on the computer (such as when I'm making a multi-platform source image to be captured and then deployed)? BDD will copy down a named directory and add it to the computer (you must specify the directory in CustomSettings.ini and, I believe, manually update UNATTEND.TXT). That's great, but now I have to maintain the driver in multiple spots. The BDD Workbench isn't helping me out any here.

To work around this, I copied the ZTIDrivers.wsf file to ZTIDriversPreStage.wsf. I made a couple of quick modifications to it so that it would copy all drivers in the list of driver groups into the C:\Drivers directory.

First, comment out the PNP device enumeration sequence on lines 266 - 274. Add a line just below with the command FindMatch "XXX". This will call the FindMatch subroutine. Since we're going to modify that in a second, the PNP ID will become pointless (hence the XXX).

Scroll down to line 395 (in the FindMatch function) and change the If Instr(1, sPNPId, oPNPId.text, 1) > 0 then statement to If 1 = 1 then. This will bypass the PNP ID match and simply resort to driver group matching.

Finally, in my Task Sequence, I modified the two "Inject Drivers" tasks (Preinstall\Non-Replace Only and Postinstall) to use the ZTIDriversPreStage.wsf file.

After these modifications, the system found my unique network card and started it successfully (not to mention pre-staging all of the available device drivers for me).

Issue with WinPE 2.0, Diskpart.exe, and certain RAID cards

jhuston — Wed, 31 Jan 2007 21:21:00 GMT

While using BDD 2007, which uses WinPE 2.0, I had a strange issue. BDD 2007 would call the DISKPART.EXE and FORMAT.COM commands to partition and format a RAID-1 volume and install an OS onto it. This seems to work fine until the OS (Windows 2003 in this case) reboots after the textmode portion of the setup.

After playing around with this, I discovered that there is some sort of weird interaction with DISKPART.EXE (version 6.0), Windows Server 2003, and the Dell PERC 5/i serial-attached-SCSI (SAS) RAID card on my Dell PowerEdge 2950.

The symptom was this. During the reboot after the textmode portion of the setup has completed, the computer would being the POST operation. When it got to the RAID card, it would initialize the card, not that there were 1 or more logical volumes, and then freeze. It is my belief that at the point it freezes, the system BIOS is attempting to enumerate the logical volume to see if it should add it to the boot order when POST is completed.

The only way to clear this was to reinitialize the drives (erasing all data). It was clear that *something* was being written to the drives in a weird way that caused the behavior.

I then tried various permutations (including running the bootsect.exe command) to get it to work. If I used WinPE 2005 (from BDD 2.5) to partition/format the disk and then used WinPE 2.0 (and BDD 2007) to perform the installation (with the partition/format command disabled), it would work just fine.

I then discovered that the FORMAT.COM command was not at fault, but it was the DISKPART.EXE utility that was causing my issue. BDD 2007 does not issue any unusual commands so I have to assume that it was the utility itself. To verify this, I ended up replacing the command with a third-party shareware utility (AEFDISK32) to repartition the volume. I was still calling WinPE 2.0's FORMAT.COM. Once this was in place, the system partitioned the disk, formatted it, and made its way past the point it was freezing before.

Not sure if this is a fix to come from Microsoft or Dell (either the system BIOS or the RAID firmware), but if you get stuck with some unusual behavior, give this a try.

BDD 2007 for Server OS Deployment - Trial 2

jhuston — Wed, 31 Jan 2007 21:10:00 GMT

Okay, last time I discussed how to get plug and play enumeration to fully discover all resources. That's just fine. One of those resources, however, is a serial-attached-SCSI (SAS) RAID card that has the boot disk attached to it.

The Out-of-box drivers works just fine for getting WinPE 2.0 to see that RAID card, partition it, format it, etc. However, when the Windows 2003 setup runs, it needs the same RAID drivers available for the textmode portion of the installation. BDD 2007 does not place the SCSIAdapter drivers into a $OEM$\textmode directory for you - you need to do this yourself.

So, where do I put them? You will notice a $OEM$ directory at the top of the d:\Distribution folder. Should you place the files here? Not necessarily. Turns out that the task sequence calls a script called LTIApply.wsf when it comes time to install the OS. For non-Vista operating systems, it will first copy the source files down to the MININT directory on the boot drive and then copy the $OEM$ directory and proceed with installation.

The LTIApply.wsf script will look in several locations for the $OEM$ directory and, once it is found, use that directory for the build. It will not merge directories, so plan ahead. This is the order in which it looks for the directory:

d:\Distribution\Control\build_name\$OEM$
d:\Distribution\Operating Systems\OS_Name\$OEM$
d:\Distribution\architecture\$OEM$
d:\Distribution\$OEM$

In my test case, I used the first option and placed the $OEM$ in the same directory as the build control files. This makes sense since you also must update the UNATTEND.TXT file to indicate which drivers to load via the OEM files and what files to include in the temporary boot directory used by textmode.

Once that is taken care of, you should be good to go for installation.

BDD 2007 for Server OS Deployment - Trial 1

jhuston — Mon, 29 Jan 2007 01:58:00 GMT

As I indicated before, I'm going to include some of the information that I've learned about adapting BDD 2007 for server operating system deployment (specifically Windows Server 2003).

The first trial that has come up is the use of Windows PE 2.0 in combination with certain "unusual" network drivers. Here's my example system: a Dell PowerEdge 1950 (also PowerEdge 2950). These puppies use the Broadcom NetXtreme II network interface cards. These high-falutin' NICs not only gain access to the network, but include support for a TCP Offload Engine (TOE) as well as an iSCSI driver. In order to accomplish this, Broadcom has written a two-driver stack. The first is the Virtual Bus Driver (VBD). This is a "System" driver (at least according to the Deployment Workbench. This is the base level interface that you then plug in the NDIS or iSCSI drivers.

Because of this two-tier structure, Windows PE 2.0 cannot correctly determine and load the drivers. Under Windows PE 2005, this was curable by using the -winpe switch instead of the -minint switch which would effectively perform an exhaustive plug and play detection. Since Windows PE 2.0 no longer has these switch options, it does not seem to do an exhaustive PNP detection and therefore does not load both drivers.

Broadcom has "tried" to help by offering a monolithic driver (which they call their RIS driver stack). This is a purpose built driver for networking only (no TOE or iSCSI support). Unfortunately, the driver is not signed. I believe that it is for this reason that Windows PE 2.0 will not load the driver (but I cannot be certain).

Here's how I've gotten around this. First, I created a directory and placed the HWPNP utility from Paraglider (http://www.paraglidernc.com/plugins/HWPnP1022a.cab extract the contents) in it. This is a pretty nifty utility that forces a plug and play enumeration and installs the device drivers, signed or not. It was originally written for the BartPE set of tools, but works just fine over here.

In my LAB distribution point, I configured it to load the additional set of files (this directory). This will put the files at the root of the PE image (X:\).

Next, I modified the Unattend_PE_x86.xml file to run the HWPNP.EXE when PE starts. This file can be found in the C:\Program Files\BDD 2007\Templates directory.

I changed the <ORDER> value of the litetouch.wsf command to be 2 and added a new section just above it with an order of 1. Here's the snippet:

<RunSynchronousCommand wcm:action="add">
<Description>HW Plug and Play</Description>
<Order>1</Order>
<Path>X:\HWPNP.EXE +all /a /p</Path>
</RunSynchronousCommand>

The +all forces the HWPNP utility to check all drivers and add them. The /a command will attempt to load all drivers even if one is loaded with a matching PNP ID. The /p parameter shows a progress bar.

Now, I include the RIS version of the Broadcom driver in the Out-of-box drivers listing and assign it to a group that is included in the LAB Windows PE build. Build out the Windows PE image and voila - network connectivity is there.