SkipRearm Setting for SysPrep Failure

Technorati Tags: SysPrep,Windows

Here’s how it goes; you have an un-activated Vista or Windows 7 reference system ready for SysPrep and .WIM harvesting, but SysPrep fails.  You search, and find articles that mutter about adding a “SkipRearm” setting to an “answer file”, but get stuck there if you don’t know how to apply an answer file.

Fortunately, there’s a simpler fix that I found and tested for Windows 7, and it works.  For Vista (which I didn’t test)…

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurentVersion\SL\SkipRearm = 1

…and for Windows 7 (as tested OK):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm = 1

The nice thing is, you don’t have to fiddle with “answer files”, or .WIM mounting and manipulation in WAIK.

This fits with the simplistic way I use .WIM imaging; I use only WinPE 3.0, ImageX, and the GimageX GUI wrapper for convenience.  My WinPE 3.0 is standard other than the addition of GimageX and ImageX, and a setting to prevent the WinPE boot from falling through to boot the hard drive if no key is pressed (sorry, no link for that).

When building a system, I partition via BING, format the prospective C: to NTFS via WinPE, then apply the .WIM, so I have a baseline installation that when booted, will resume Windows Setup as part of what SysPrep did prior to the creation of the .WIM image.  I do the first boot OFFline, and kill the duhfault setting to automatically activate Windows. 

Then I update and install free software to taste, until the new PC is generically fully set up.  I use BING to image the C: partition for safekeeping (in case SysPrep screws up), then run SysPrep and Generalize the new PC.  I then boot WinPE to capture C: as a new and updated .WIM, then I boot BING to restore the partition to the state before SysPrep was run.  At this point I can apply client-specific changes, activate Windows, and ship the new PC.

SysPrep does not maintain undoability, and tends to screw up.  When it does, you can be left with no bootable reference system and no usable new .WIM, so I again stress the need to image-backup C: before SysPrep.  If you’ve done that, you may prefer to restore that image rather than wade through and clean up after SysPrep’s effects.

Key safety

One of the things you want to avoid when working with what you hope to harvest as a reference .WIM, is inadvertently activating the build, especially with the wrong product key:

• Disable the “automatically activate” setting
• Keep new PC offline from build until first backup image of C:
• Re-check “automatically activate” setting before going online
• Do the “image backup, SysPrep, restore C:” sandwich
• Check the current key before activating
• Activate before shipping as new PC

When I tested SysPrep with SkipRearm, I did not enter a product key when prompted, and used Nirsoft’s Produkey tool to check the key.  This showed a key other than that of the client, so SysPrep had stripped that OK, and presumably fallen back to some previous or fake key.  When I restored the pre-SysPrep BING partition image as C:, this showed the expected client’s key, as I’d entered when originally starting the build from the previous .WIM

Final tip; if/as SkipRearm doesn’t reset the full grace period for activation, you may want to minimize the days spent between restoring the previous .WIM and capturing the next one.

Mint/Linux, Sandy Bridge, Blank-screen Intel Graphics

Mint 11.4 64-bit installs on Cold Lake H67 Sandy Bridge motherboard PC OK, hard drive boots to grub2 OK, but Mint boots to a black screen with no mouse pointer.  The OS is running OK, you just can’t see anything – or almost; a close look at the screen shows a pixel-flickering red line down the left edge and a solid short horizontal white line top left, when a 17” CRT is used. 

The problem appears with LCD screens also, and is variable; some boots may be OK.  At present, all 3 of 3 new PC builds have done this on first Mint hard drive boot.

The fix: Plug another monitor into the other graphics socket.  The desktop will immediately appear on both screens; you can then unplug the second screen and it will work OK (at least for that booted session).

Cold Lake motherboards use the H67 chipset, which in turn interfaces the Intel GPU built into the processor, to DVI and HDMI dual display outputs.  Typically I use a DVI to VGA adapter to take the DVI’s analog signal to 17” CRT or more modern LCD, leaving the HDMI unplugged, though from memory I recall similar mileage when a digital-signal LCD was plugged into DVI, or HDMI via HDMI to DVI “pigtail” adapter.

It seems like Linux can’t figure out what display signal to use?

If previous Ubuntu mileage is anything to go by, the “fix” is prolly to wait until the next OS release in the hopes it will use a newer Linux kernel that has a clue about “new” hardware.  Bah!  Still, that should be due later this month, so let’s see how it goes.