January 2007 - Posts
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.
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.
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.
For the past year or more, we have been using the automation in BDD 2.5 to deploy our server operating systems. This has been a great deployment tool for us and I'm looking forward to adapting BDD 2007 to this same purpose.
Deploying a server OS is very similar to a workstation OS, but is usually done with more interaction (such as the Lite-Touch scenario). Because our environment encompasses several domains, I'm still interested in the SMS OSD automation component of the Zero-Touch scenario. I'm attempting to mold the two together in a meaningful way.
As I learn more, I'll post some notes for how I've customized BDD 2007 for this purpose. Perhaps the Microsoft folks will take a listen that many admins do not want to have multiple build, image, and deploy technologies but, instead, want a more unified approach to deploying all flavors of the operating systems available from Microsoft.
I'm hoping to provide some scenario based prescriptive guidance for deploying SMS packages to end users. You should see a few of these over the coming weeks as I add more scenarios. I'm going to start with a bunch of the less obvious ones so that you can benefit faster.
Scenario: Deploy a software upgrade from a given file share, but that software installation must be run from that particular file share (i.e., poorly written software that still uses a shared executable).
Solution 1: If the user is an administrator, run the program as the user. Target a batch file or other command that is on the share. This will force the network connection to the file share to be done as the user.
Solution 2: If the user is not an administrator, then you must run as the SYSTEM account. Because the SYSTEM account will not have access to the network file share (by default), you need to configure SMS to use the Advanced Client Network Connection Account. First, grant that account access to the file share. Then, configure the program to run as the local system context but to execute a batch file or command from the particular share. When running, the client will first attempt to connect as SYSTEM. Once that fails, it will then attempt to connect using the Network Connection account and then proceed to run the executable (still as SYSTEM - only the network connection's credentials are changed).
NOTE: In order for the network connection account to be attempted, the package cannot contain any source files - it must be considered a script instead of an installation. Second, the program's command must be a UNC path to a batch file or executable. Doing otherwise will not cause the SMS client to try to connect with the network connection account.
That's it for the first installment. More as I come up with them.
I don't know about the rest of you, but walking a user through the Start menu to the Control Panel and then on to an SMS applet is too much for some of my end-users.
To get around this "problem", I've created a set of scripts that get copied down to each user's workstation during computer startup. In addition, a script is run during the startup script to create/maintain a link on the Start menu with a keyboard shortcut to the main script. This way, I only need to tell the users to press Ctrl+Shift+S to bring up a simple numeric menu and then type in the number of the option that I want them to run.
So far, I've got options for running the basic health scripts (some of which are run during computer startup anyway), displaying status of inventories and ITMU, launching the Systems Management or the Run Advertised Programs applets, and excuting particular actions from the Actions tab (kicking off inventories or policy downloads).
This "menu" provides a quick way for me to instruct a user to obtain information and pass it back to me. For instance, how many users know how to get their IP address? Using my tool, I tell them to press Ctrl+Shift+S, run menu item 4 (display key system information) and read me the data on line 9. No more crazy directions (open up a command prompt, okay, click Start, click Run, it's the one down in the lower-right corner, no - that's the clock - the lower-right corner of the Start menu, type C-M-D and press Enter, no M as in Mike, type I-P-C-O-N-as in November-F-I-G and press Enter, now scroll up and look for the lines that say IP Address, keep scrolling up since that was your wireless card, etc.).
See the attached ZIP for some of these scripts.
I've posted a page up here that details how I do ITMU deployments. Take a look. Most of the nitty-gritty is in the attached ZIP file.
http://myitforum.com/cs2/blogs/jhuston/pages/how-i-do-patch-management-using-itmu.aspx