Moblog

In January, I wrote how you can move both your program files and user data folders using Junctions. I have been doing this for years on my XP installations and didn't expect it to cause so much trouble.
In March, the first Windows Updates failed with error code 80070011. I have posted about how you can fix this on a per-failed-update basis manually.
With the release of SP1, this method didn't work any longer. There was no pending.xml, no matter how many updates failed on me. Reader Jiminaus suggested to update the ProgramFilesDir.

Today, my system drive crashed on me and I had to do a fresh install, so I went a different way: Leaving the program files folder alone, I only moved the Users folder - this time, not using junctions, but by updating the relevant registry entries, as suggested by various sources and computer magazines. Continue reading "Windows Vista: Moving Program Files and User Data, Revisited"

In January, I showed you how to move your program files and your profile folder to a different partition using robocopy and mklink. With NTFS junctions, you (and your programs) can transparently use the folders on your C drive, while the actual data lies someplace else.

Unfortunately, today, some Windows Updates where shipped that try to install on every reboot, but fail with error code 80070011. Using GoogleScroogle, I quickly found out why (and how to fix it manually).

Cause: If files cannot be replaced because they're open, updates write XML commands to \SystemRoot\WinSxS\pending.xml (usually C:\Windows\WinSxS\pending.xml, unless you've installed Windows to a different partition). This file will be processed on reboot. To replace files, updates create hard links at the destination, like this:


This will fail if "Program Files" is on a different partition, as files can only be hard linked within the same partition. I highly doubt that Microsoft will ever fix this, because moving program data to a different partition is not officially supported.

Workaround: If you don't want to move your program files back to C: (like me), there seems to be only one way to fix this: By copying the updated files the the same partition as the real program folders, and by changing all HardlinkFile references to this new location, it will work. alantangcs posted a nice step-by-step guide on how to edit pending.xml (you have to change ownership of the file first).

Because I don't expect this to be the last time an update tries to change Program Files, I wrote a little script that does most of the work: It will provide a copy of pending.xml with all necessary replacements and copy the files to a directory called "WUTemp" on the same partition as your real program files. If you don't supply the real location of your program files by command line, the script will ask for it.

A slightly easier workaround might be to replace the affected HardlinkFile commands by CopyFile (not sure if it exists) or MoveFile (exists, but I don't know how it reacts if the target already exists). That way, the files can stay in WinSxS. I haven't tried this, and be warned: If you mess with pending.xml and Vista doesn't boot, it won't even boot in Safe Mode. Try in a VM or keep some recovery disk handy. Continue reading "Vista: Windows Update Error 80070011 Semi-Automated Fix"

I finally managed to purchase a new computer! Well, parts for a new computer. With neither ATI or Nvidia able to ship their latest mid-range video cards, I skipped that one, for now. Fortunately a friend had a spare 7900GT lying around waiting for me to borrow it.
The plan was to migrate to Vista 64bit as my main system, but keep a familiar XP as backup system in case something doesn't work. I went through a series of problems which ate my whole weekend.

Installation

1. AHCI. Determined to install both XP and Vista with AHCI, I enabled the responsible BIOS settings for both controllers of my board. What I didn't know yet was that - for reasons unknown - I managed to buy the wrong board. What I wanted to buy was a P35 DS3, but I got a 965P DS3 instead. Of course I had CPU and cooler already mounted when I found out, and hey, at least it supports my Quad Core! I guess I have to live with it now. Back to AHCI: The onboard intel chipset doesn't support it (although there is a BIOS setting for it?), the Gigabyte controller (JMicron 363) supposedly does. I don't want to mention the problem of getting the drivers loaded, but at least Vista now supports USB drives and CDs for additional drivers (hooray!). Nobody told me that it only detects USB drives if they're connected at startup, so I had to go through the installation process again. But hey, it only takes five minutes to (re)boot the Vista DVD on my new quad core with 4GB of RAM! Finally it detected the hard drive and started to install, but after imaging the drive repeated to reboot again and again. Of course I tried various drivers and wanted to find a real solution, but most installation guides and user comments just told to install without AHCI. After hours without any progress, I gave up. No AHCI for me, then.

2. I wanted to reuse my existing SATA drive, so I moved the previous single partition and created one partition each for Vista and XP (physically before the data partition). The partitioning tool I used defaulted to logical volumes and I didn't look close enough, so I had the following (wrong) layout: 30GB Vista (logical), 10GB XP (logical), data partition (primary). Not that XP or Vista wouldn't let me install, no, but I experienced strange NTFS errors later after everything was configured the way I wanted it to be. Some hours of diagnostics later, I accidentally tried another partitioning tool and saw the mistake. Whoohoo, here we go again. Formatted both OS partitions, set the Vista partition to active and all three to primary.

3. At 5am, I was through with my (third!) XP installation that day (and night). After the first reboot, error, "HAL.DLL not found". **sigh** I knew that message - at least that's the kind of experience you get in 2 years of IT support - and especially that it rarely has anything to do with real files missing. The boot.ini entry was incorrect (on a fresh installation? WTF), I used bootcfg /rebuild to fix it and - voilà - XP continued the installation. It wanted activation again, but didn't allow it over the Internet, so I called the Microsoft hotline (free call). I made it through the tedious process of telling the answering machine that it was the only computer I had that XP version installed on (what a surpise answer...) and got the lengthy confirmation code.

4. Vista installation again. At that point, I wished I had prepared a custom unattended installation DVD... out of no reason, it again kept rebooting after the first part. Superb.

(insert some hours of sleep here)

5. Reformatted the Vista partition. Now, of course, all traces towards a bootable XP on the second partition were gone, but at least Vista installed. I tried FIXBOOT/FIXMBR in the Vista and XP recovery console, but that didn't help. XP repair installation, then Vista automated boot problem repair.

Done! I had a working dual boot with Vista and XP. No, I'm not done yet. XP is only supposed to be a backup system, but for Vista, I wanted the Users directory (all profiles) and the program folders to be on a separate partition. I regard this to be a standard use case, nothing special here - I don't understand why people at Microsoft make it so hard to achieve. Okay, you can invidually move the Documents and Movie folder in your profile, but that's not what I wanted. Turned out that this is possible with a customized unattended installation, but you might understand why I didn't choose that route. After a few trials (and, unfortunately, errors), I managed to move the whole directory structure transparently.
After this, so-called NTFS junctions will point from the original locations to my new folders (in this example, in the root directory of E). This (hopefully) keeps everything intact without having to mess around in the Windows Registry. Afterwards, you can tell your programs to install to C, while they really write to the new location.

Moving "C:\Users" to A Different Partition

Boot into recovery console and execute the following commands.


You might need to repeat the rmdir/mklink for your localized user folders. If you forget the /XJD switch on robocopy (exclude junctions pointing to directories), it will run into an endless loop, so be careful! If everything worked, you can later remove "C:\Users (OLD)".

Moving Program Files to A Different Partition

Again, boot into the recovery console (or any other boot CD). Basically, I have repeated the steps for moving the Users directory for both "Program Files" and "Program Files (x64)". I'm not sure whether /XJD is really required here, but it does no harm either. Edit: You can move the folders using Microsoft's own utilities PendMoves and MoveFile without having to boot into a recovery console. Matthew Wade explains how.


Again, make sure that you remove existing junctions and create new ones if you have a localized version of Vista, or they will still point to the old (moved) directory; you might also want to move c:\ProgramData. By the way, you can list the complete content of a folder including hidden and system files using "dir /a".

You can use the same method to move profile and program data in Windows XP. It doesn't ship with robocopy or a tool to create junctions, but I was able to successfully copy both folders using xcopy32 and create junctions using the Junction utility by Sysinternals.


Edit: Warning! Booting into Windows XP will delete all system restore points of Vista, including file shadow copies (file history). Microsoft is aware of the problem, but does not provide a fix. The only workaround at the moment is to hide the Vista partition from Windows XP (explained in KB926185). What a stupid issue...
Edit 2: Warning! If you move your program files, some Vista updates will not install (error 80070011). There is a semi-automated fix, but you need to use it every time an update fails.
Edit 3: Especially Vista SP1 doesn't install and I haven't found a way to work around this...