Category: OS Deployment

Applying KB2506143 to an offline Windows 7 SP1 WIM = Windows Setup fail

comments Comments (7)
By , January 4, 2013 12:36 pm

We use the offline servicing features of the Windows Automated Installation Kit (WAIK) to patch our images. It’s a great feature that usually saves us time and enables us to update images without constantly unsealing and resealing. But after applying the latest and greatest patches to a base Windows 7 SP1 WIM yesterday and then testing it, I began to encounter this dreaded error during Windows Setup:

Windows could not configure one or more system components. To install Windows, restart the computer and then restart the installation.

Bummer. Fortunately, since the image was serviced offline and nothing else had changed, I could reasonably assume that one of the patches was the culprit. But which one? To find out, I rebooted the system into Windows PE and opened C:\Windows\Panther\setuperr.log. Here’s what I found…

2013-01-03 18:11:12, Error                 CSI    000000fb (F) Done with generic command 8; CreateProcess returned 0, CPAW returned S_OK
    Process exit code 4294967295 (0xffffffff) resulted in success? FALSE
    Process output: [l:117 [117]"ERROR - .NET 4.0 is not installedERROR - CLRCreateInstance call failed, 0x80004001.
ERROR - Initialization failed.
"][gle=0x80004005]
2013-01-03 18:11:12, Error      [0x018007] CSI    000000fd (F) Failed execution of queue item Installer: Generic Command ({81a34a10-4256-436a-89d6-794b97ca407c}) with HRESULT HRESULT_FROM_WIN32(14109).  Failure will not be ignored: A rollback will be initiated after all the operations in the installer queue are completed; installer is reliable (2)[gle=0x80004005]
2013-01-03 18:11:14, Error                 CSI    00000107 (F) Done with generic command 9; CreateProcess returned 0, CPAW returned S_OK
    Process exit code 4294967295 (0xffffffff) resulted in success? FALSE
    Process output: [l:117 [117]"ERROR - .NET 4.0 is not installedERROR - CLRCreateInstance call failed, 0x80004001.
ERROR - Initialization failed.
"][gle=0x80004005]

It turns out that one of the updates that was installed in the offline WIM had a .NET 4.0 dependency, but the base Windows 7 SP1 image does not have .NET 4.0 installed. I would have expected the DISM utility to simply detect that .NET 4.0 was a prerequisite and skip over the update, but apparently it didn’t, or maybe there’s an issue with the update itself. At any rate, there’s no way to inject .NET 4.0 into an offline image – it requires unsealing, installing .NET 4.0, and resealing. Instead, I opted to remove the misbehaving update. To figure out which one it was, I opened setupact.log and looked for additional details that weren’t in the error log. I found these lines prior to one of the errors:

2013-01-03 18:11:12, Info                  CSI    000000f2 Begin executing advanced installer phase 38 (0x00000026) index 59 (0x0000003b) (sequence 98)
    Old component: [l:0]""
    New component: [ml:344{172},l:342{171}]"Microsoft.PowerShell.Commands.Utility-Gac.Resources, Culture=en-US, Version=7.1.7601.16398, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=x86, versionScope=NonSxS"
    Install mode: install
    Installer ID: {81a34a10-4256-436a-89d6-794b97ca407c}
    Installer name: [15]"Generic Command"

Using Google-fu, I was able to determine that the failing component was part of KB2506143: Windows Management Framework 3.0 for Windows 7 SP1 and Windows Server 2008 R2 SP1. From there, I just needed to mount the WIM and remove the update using DISM:

dism /image:TEMP\entx64mount /remove-package /packagepath:Updates\x64\Windows6.1-KB2506143-x64.cab

After that, Windows Setup continued happily ever after

[del.icio.us] [Digg] [Facebook] [StumbleUpon] [Twitter] More »

categories OS Deployment, Troubleshooting, Windows 7

Injecting Intel Matrix Mass Storage Drivers into a Windows XP WIM

comments Comments (29)
By , May 26, 2009 8:33 am

In Classroom and Lab Computing, we use sysprep in our Windows XP imaging process so that we can support the various computer models that comprise the 4000+ computers participating in CLM, both at University Park as well as several other campuses at Penn State. Using the tools and techniques that we have developed, we are able to apply our single OS image to a machine in about 5 minutes using a USB drive. After that, the USB drive can be removed and the machine will continue to build completely unattended. Not only is the process really cool, it saves a lot of time. However, sysprep for Windows XP isn’t perfect, and with newer hardware we have run into a few caveats.

The Problem

While updating our XP image last year, we ran into a snag where the new model (a Dell Optiplex 755) refused to build when SATA operation was set to AHCI in the BIOS. This was due to a missing Intel Matrix Storage driver. Normally, drivers can easily be added to a sysprep image by injecting them into a folder within the image and then adding them to OEMPnPDriversPath in Sysprep.inf. However, these drivers are not applied until midway through the mini-setup process that runs the first time Windows boots. Without having the correct Mass Storage Driver for booting the first time, Windows will blue screen (with stop error 0x0000007B) before it can even enter mini-setup. Now that many of Dell’s newer systems come with eSata ports, it is recommended that AHCI is used for SATA operation. There is a way to insert Mass Storage Drivers when sealing a sysprep image. However, we already sealed our image for this year and wanted to avoid another reseal. Fortunately, there is a way to manually inject the drivers into the image. It’s a bit tedious, but it does work.

Manually Injecting the Intel Matrix Storage Drivers into an Windows XP image

  1. Download the Intel Matrix Storage driver (be sure it’s the latest version) from the Intel website or from the system manufacturer website. If using the Intel website, you will probably need to extract the drivers from the executable. This can be done by calling <filename>.exe -a -0 <folder path>. Folder path is the folder where the drivers will be extracted to.
    • Make sure that you have the following files: iaahci.cat, iaahci.inf, iastor.cat, iastor.inf, and iastor.sys.
  2. Open iaahci.inf with a text editor. First, look in the [version] section for the ClassGUID. Copy and paste this somewhere. Next, look for the [INTEL_HDC] section. You will see syntax similar to this: 
    %PCI\VEN_8086&DEV_2681&CC_0106.DeviceDesc% = iaStor_Inst, PCI\VEN_8086&DEV_2681&CC_0106

    The portion of the line that is in red is the HardwareID. Copy and paste the HardwareID portion of each entry in [INTEL_HDC] to a separate line in an empty text file. They will be important later on.
    Note: The [INTEL_HDC.ntamd64] section below, which is below this section, can be skipped. They are the same.

  3. Open iastor.inf and note the ClassGUID.  Look for the [INTEL_HDC] again. The formatting should be the same. Once again, copy and paste each of the HardwareIds to a separate line in an empty text file.
  4. Mount your Windows XP image using imageX (imagex.exe /mountrw <path-to-wim-file> <image index #> <mount-folder-path>) . If using Ghost, you will probably have to apply the image to a separate hard drive. Last time I checked, Ghost couldn’t edit disk images that were in NTFS format. By the way, now may be a good time to look at switching from Ghost to ImageX for capturing and applying your image.
  5. Copy the driver files to the following folders:
    • Copy iaahci.inf and iastor.inf to <mount-folder-path>\Windows\inf
    • Copy iaStor.sys to <mount-folder-path>\Windows\system32\drivers
    • Copy iaahci.cat and iastor.cat to <mount-folder-path>\Windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
    6. The HKLM\systemxp\ControlSet001\Control\CriticalDeviceDatabase key

    The HKLM\systemxp\ControlSet001\Control\CriticalDeviceDatabase key

  6. Next, the SYSTEM registry hive from the image must be loaded. Open the Registry Editor (Start->Run->regedit.exe). Click on HKEY_LOCAL_MACHINE and then go to File->Load Hive… browse to <mount-folder-path>\Windows\system32\config and select the file named SYSTEM. When prompted to give the hive a name, type systemxp. The systemxp registry hive should not appear below HKEY_LOCAL_MACHINE.
    Note: At this point, you should take a moment to browse to <mount-folder-path>\Windows\system32\config and make a backup of your SYSTEM file in case the registry changes break something.
  7. Now that the driver files are in the right spot, a registry key must be created for each of HardwareIDs that we retrieved from iaahci.inf and iastor.inf.  The easiest way to do this is to create a .reg file that will add all of the entries to the hive. Create a blank text file and name it IntelMSD.reg. From a text editor, open IntelMSD.reg and set the first line to this: 
    Windows Registry Editor Version 5.00

    Next, we need to create an entry for each of the HardwareIDs that we are adding. Here is what the syntax for each entry will look like:

    [HKEY_LOCAL_MACHINE\systemxp\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_8086&dev_2929&cc_0106]
"Service"="iaStor"
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"

    The parts in bold are what will be changed for each entry. On the first line, the red text is where the HardwareID for each entry will go. The second line is the same in each entry. The third line is where the GUID associated with that entry will go. The two ClassGUIDs that were retrieved in steps 2 and 3 will be used here. Make sure that the GUID you put is the one that was in the same .inf file as the HardwareID.

    Note: I realize that this part was a bit tricky. You can compare your .reg file with mine here to make sure your syntax is correct. Keep in mind that yours may have more entries, especially if it’s a newer version of the driver. Also, be sure that you have made a backup of your SYSTEM file in case the registry becomes corrupt.

  8. In the registry editor, go to File->Import… and browse to the IntelMSD.reg. This will load all of the registry entries into the systemxp hive. To be sure, you can browse to HKEY_LOCAL_MACHINE\systemxp\ControlSet001\Control\CriticalDeviceDatabase and check for the entries yourself.
  9. In addition to the entries created in CriticalDeviceDatabase, an entry for the iaStor service must be created. This registry file should apply the entries that are needed to HKEY_LOCAL_MACHINE\systemxp\ControlSet001\Services. To import it, go to File->Import… and browse to iaStor.reg.
  10. In regedit, click the systemxp registry hive and then go to File->Unload Hive… This will unload the XP Image SYSTEM hive so that the image can be unmounted.
  11. Unmount the image (or if using Ghost, recapture it). Test it on machines that have AHCI enabled (and use the Intel Matrix Storage Driver).

Other Mass Storage Drivers

Although I haven’t tested this, I am pretty sure that this process will work with other Mass Storage Drivers. The key to getting them to work is being able to read and understand what the inf file is doing. The Intel Matrix driver only required registry edits, and so it was fairly easy to do. For more information on inf file syntax, look at this MSDN page.

[del.icio.us] [Digg] [Facebook] [StumbleUpon] [Twitter] More »

categories OS Deployment, Scripting, Troubleshooting

Deploy Vista install.wim on any drive you like (as long as it’s D:\)

comments Comments (0)
By , December 3, 2008 11:34 am
Source: xkcd.com

Source: xkcd.com

While designing and testing a deployment process for Windows Vista using System Center Configuration Manager 2007 I ran into a seemingly obscure problem: Vista refused to use drive letter C as the OS Volume and instead chose D as the system drive letter. The result is that the root of the system drive was D:\ instead of C:\, which is something that legacy applications are not fond of.

This would seem like an easy problem to resolve. Surely, it is caused by the way the disk is partitioned or perhaps the drive letter that SCCM applies the image to is incorrect. Perhaps it’s a registry setting in the image file that needs to be modified offline. I experimented with all of these things, with no luck. Finally, I came across a technet blog entry that I had missed with previous Google search queries:

Several people have tried to use the install.wim from the Windows Vista installation media in an Install an existing image package task sequence.  They are surprised to discover that, upon completion, the operating system is on the D: drive instead of the C: drive. The short explanation for why this happens is that the operating system volume for the images in install.wim is D:.  In other words, when the image was captured, the reference machine had the operating system on volume D:.  Why this is the case for the install.wim that ships on the Windows Vista installation media is beyond the scope of this blog.

So essentially, you can’t use the install.wim image from Vista in SCCM if you want to use C for the system drive letter. That would have been nice to know….

[del.icio.us] [Digg] [Facebook] [StumbleUpon] [Twitter] More »

categories OS Deployment, System Administration, Troubleshooting | tags , , , , ,

Super Talent Pico Drive

comments Comments (0)
By , November 20, 2008 1:16 pm

For deploying Windows XP to computers in our lab environment, we use 2GB 200x USB drives manufactured by Apacer. The reason for using these drives is simple: They are much faster and more reliable than DVD media. For Vista, we need to upgrade to 8GB drives (4GB would probably work for now, but having some padding is nice). The 8GB version of thet Apacer drive is very expensive (some retailers have it listed at over $100). Since we will eventually need to buy a lot of 8GB drives, I decided to look for some chreaper alternatives that have similar performance. I came across the Super Talent Pico Drive, which has fairly good performance reviews when compared to the Apacer drive. At $26, it’s a bargain. I decided to order one for testing.

I was shocked at how small this drive was. I would be reluctant to put most USB drives on my keyring because they are too bulky but this drive is really perfect accessory to your keys. The USB connector folds out of the casing. The one thing I dislike about the connector is that it allows you to put the key in to a USB slot backwards, so you have to pay attention when plugging it in.

In terms of performance, it is plenty fast for what we need. It is definitely faster than DVD media and may even have faster reads than the Apacer models we have used. If I have time someday I will do a side-by-side comparison. Writes to drive, while not blazing, are definitely fast enough for our needs since we only need to read data from the drive during our build process.

The verdict is still out for the sturdiness of this device. The USB connector is constructed of plastic that seems to scratch easily. I’m not sure if this will cause problems down the road. When the connector is folded into its case it seems to be fairly safe from unintentional damage.

Overall, I am really impressed with this USB drive. Having a USB drive with both gobs of space and great performance is spectacular, especially at this price. Super Talent has several other models that we may look at in the future.

[del.icio.us] [Digg] [Facebook] [StumbleUpon] [Twitter] More »

categories OS Deployment | tags , , , ,

Panorama Theme by Themocracy