Ubuntu 10.04 and Windows XP Dual-Boot: GRUB2 Woes

I was installing Windows XP SP3 and Ubuntu.  I encountered some error messages early in the process.  This post describes the steps I took in an attempt to resolve those problems.

First, I got this error:

Setup did not find any hard disk drives installed in your computer.

In my search for a solution, I found a thread offering a number of suggestions.  The one that worked for me was to go into the BIOS (hit Del at startup) and make sure the SATA controller was set to ATA, not AHCI.  Mine had started out as ATA, but a notice had popped up when I was first booting it, offering to change it to the AHCI, and I had accepted.  After I fixed this, the next bootup problem was this message:

Windows could not start because the following file is missing or corrupt:

\system32\hal.dll
Please re-install a copy of the above file.

My search on that led to a page offering a number of suggestions.  I started with just rebooting.  That didn't fix it.  suggesting that I go into the BIOS and switch the order in which the BIOS would try to boot my hard drives.  This led to a new message:

error: no such device: [UUID number]

grub rescue>

This apparently happened because I had previously installed Ubuntu on that hard drive.  For this one, I took the advice to boot from the WinXP installation CD, choose R to repair an existing installation, choose the existing installation (no administrator password), and type this sequence of commands:

D:\WINDOWS> C:

C:\> CD \

C:\> FIXBOOT C:

C:\> FIXMBR

C:\> BOOTCFG /rebuild

The last one led to an offer to add D:\WINDOWS to the boot list.  I took that offer.  But then it asked "Enter Load Identifier" and "Enter OS Load Options."  I didn't know what to add, so I just hit Enter for each.  This led to a new error message:

Error: Failed to add the selected boot entry to the boot list.

I guessed that the system was seeing the Windows installation on drive D because I had reversed the boot order in the BIOS.  I did think I had cabled them correctly, with the Windows drive going to SATA0 (i.e., the first SATA connector) on the motherboard.  I looked into Load Identifier and found a Microsoft page with information on that and other parts of this situation.  It told me to type the name of my operating system:  Microsoft Windows XP Professional, though apparently anything would do.  For OS Load Options, it said, type /fastdetect.  Unfortunately, this was not satisfactory.  I got the "failed" error again.

The responses to this seemed to lean in the direction of editing the boot.ini file.  A thread on that gave me the idea of just copying my boot.ini file from another computer.  A Microsoft page gave information on editing it if I was already in WinXP, which I wasn't.  A webpage devoted to boot.ini said it should be possible to just delete the boot.ini file in order to boot the system.  The webpage also gave some sample boot.ini files.  I typed "help" at the prompt and got a list of options.  There didn't seem to be an editor in the Repair Console.  I typed "dir" to verify that boot.ini was there, and then typed "type boot.ini" to see what was in it.  It didn't look very complicated.  What's more, it looked like my XP Pro entry was already there, which could explain why my BOOTCFG command didn't work.  I pressed the up arrow to retrieve my BOOTCFG command and hit Enter to run that again, just in case.  It failed again.

I typed "exit" and shut down the computer and swapped cables so that maybe this drive would show up as C rather than D.  That merely resurrected the "no such device" GRUB error.  I decided to explore that one for a while.  A search led to some commands that I could have entered, but then I saw a suggestion that maybe I could fix it by just installing Ubuntu, which I had planned to do anyway, and let it sort itself out.  So I went ahead with that, following the Ubuntu installation approach I had worked out previously.  But at this point I only did the initial installation from the CD, and then rebooted to see what the Windows situation was now.  Sadly, I still had the "no such device" error.

I guessed that the problem was that I was using two drives.  One of them had perfectly reasonable Windows and Ubuntu installations on it.  The other had leftovers from some previous Ubuntu installation.  I didn't know for sure, but on that hunch I unplugged the second drive and rebooted.  But no, that gave me the "no such device" error either way, no matter which disk I plugged in.  I plugged in both drives, rebooted with the live CD, and ran System > Administration > GParted to take a look.  Interestingly, it showed that a partition on the second drive was marked as a boot drive, when it should not have been.  I changed that.  It didn't make a difference.

Ultimately, I plugged in a USB drive while booted with the Ubuntu live CD, copied over the data files, wiped both of the drives in the machine, and reinstalled WinXP and Ubuntu, in that order.  That solved the problem.

Installing Windows XP SP3 in VMware Workstation 7.1 on Ubuntu 10.04

I had decided to stay with VMware Workstation 7.1 for a while longer, adopting a wait-and-see strategy toward VirtualBox and whatever other virtualization developments might be underway.  A couple of years had passed since I had first installed Windows XP on VMware Workstation in Ubuntu.  My old virtual machines (VMs) were creaking and malfunctioning.  It was time to create a new WinXP VM.

I had obtained mixed results from efforts to use VMware Converter to build VMs from existing WinXP installations or other sources.  I decided to build a fresh installation, installing XP within a newly created VM.  I had already installed VMware Workstation.  Now I started it as root user by typing "sudo vmware," and then I went into Ubuntu's Applications > Accessories > Terminal.  In Workstation, I went into Edit > Preferences and adjusted the settings that would apply to all VMs, some of which could only be set by root.  In the Preferences > Workspace tab, I went with the default settings for the most part.  For the default location of my VMs, I chose a partition on a separate hard drive for better performance.  In the Display tab, I selected the three Autofit options.  I selected all of the Updates options.  In the Memory tab, I left about 1.5GB of RAM for the system; the rest was for VMs.

When I was done with the settings, I killed that session and restarted VMware as a normal user.  I created a new VM with these characteristics:

• I started with a 40GB independent, persistent SCSI VM, but ran into some problems when I tried to shrink it, and ultimately had to start over.  Since it was easier to grow a VM than to shrink it, I decided on 20GB to start.  Although I initially created this as a preallocated space, it seemed that clones (which I made from time to time as backup, as the installation and tweaking process went along) would default to being non-preallocated, and I decided that was actually better until things got settled, because non-preallocated drives were smaller and therefore easier to clone and to back up.
• A 4GB independent, persistent IDE virtual drive, within this VM, for the paging file (VM > Settings > Hardware > Add).  This, I discovered, was best created after WinXP was installed.  Otherwise, WinXP was quite capable of brainlessly installing itself into this little partition and leaving the 20GB partition unused, thereby providing yet another reason to start over from the beginning.  Also, this drive was best created when the VM was powered down; only a SCSI (not preferred) drive could be created while the machine was powered up.  Note also that, as soon as you start down this path, Workstation may create a miniature version of a file for such a hard drive, even if you then abort the process -- in which case your later attempts to create that file may trigger strange results, until you investigate and delete any such runt file.
• 1.5GB RAM.  I had opted for 32-bit Ubuntu and WinXP after numerous previous hassles with 64-bit systems.  The discovery of PAE-enabled kernels meant I could go above the ordinary 32-bit limit of 4GB of RAM, so I was comfortable with this 1.5GB allocation for a single VM.  I could have gone higher, but I had almost never reached the point of using even this much.
• One single-core CPU.
• Based on my own usage, I set "Don't automatically connect" for floppy, USB devices,  or printer.
• Power:  enter full screen mode after powering on; close after powering off.
• Shared folders:  always enabled, map as network drive, make read/write only those that needed to be written to in Windows.
• No AutoProtect.
• Guest isolation:  enable drag and drop; enable copy and paste; don't enable VMCI.
• VMware Tools Updates:  use application default (currently update automatically).

Then I inserted the Windows XP CD and installed Windows XP, using a slipstreamed CD with Service Pack 3 (SP3) on it.  In my first attempt at this, I had to deal with the problem of making the VM boot from the CD.  I had just learned how to do this.  First, in Ubuntu's Terminal, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM, and then I went to the end of that file and added bios.bootDelay = "10000" and saved the edited file.  This gave me a ten-second delay on VMware's splash screen.  So then I had time, on reboot, to read the options and choose F2 for BIOS setup.  In BIOS setup, I chose Boot, moved the CD-ROM drive up to be first in the boot sequence, and then hit F10 to save and close.  Then I installed WinXP.  The process was completely automatic, this time; apparently the latest version of VMware Workstation was able to detect my settings from the underlying Ubuntu installation.

Once WinXP was done with its basic installation process, I right-clicked on the VMware Tools icon in the system tray (i.e., the lower-right-hand corner of the WinXP desktop), chose "Open VMware Tools," and selected all three items in the Options tab, and then closed that.  To get the Windows desktop to stretch all the way across the monitor, I used VMware's View > Stretch Guest (using the menu at the top of the screen), and then returned it to View > Autofit Guest, and for some reason that did it.  I had to map my network drives after listing them in Workstation's VM > Settings > Options > Shared Folders.  Then I turned to the process of tweaking my WinXP installation.  There are some additional VM-related notes in my post on that.  When I tried to open a PDF file from within the VM, I got a Default Host Application error message.  Another post discusses that problem.

I wanted to use Acronis TrueImage to make periodic images throughout the installation process, so as to capture each working state of the system in a single snapshot.  On a standalone WinXP installation, that would have been just a matter of inserting the Acronis CD and making the backup to a separate partition.  In the VM context, though, Acronis was only willing to recognize only those partitions that were defined as part of the VM.  What I did instead, then, was to power down the VM, use Nautilus to copy the entire VM's folder to an NTFS drive, boot Acronis, and make an image of that VM folder.  (I also made a .zip of it in 7zip, just in case.)

To get the system to pause before loading Windows within VMware, so that I would have time to make a decision to adjust the BIOS or choose boot devices, I edited the individual virtual machine as described in a previous post.  Basically, I set Workstation's VM > Settings > Hardware tab > CD/DVD > "Connect at power on" and "Use a physical device" (though I was intrigued by the "Use ISO image" option).  In Terminal, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM; and at the end of that file I added a line that said this:

    bios.bootDelay = "10000"

and that bought me ten seconds instead of one or two, when that vmware logo came up.

*** NOTE ***

At this point, I stopped developing this post.  Several other system issues had to be taken care of first, and those were superseded by non-system tasks.  When I returned to this post several months later, my purpose was just to close it down.  I had decided, by that time, to stop working on VMware within Ubuntu.  The following fragments are the other notes I had left over, in incomplete form, when I ceased working on this post.

Fragmentary notes continue as follows:

*  *  *  *  *


At some point in the process, I started getting an error message when I was trying to shut down the WinXP VM:

End Program - VMwareUser.exe
This program is not responding.

I did a search and found that virtually nobody was having this problem.  That was not a good sign.  A different search suggested that lots of people were having problems of one sort or another with VMwareUser.exe.  That was not a good sign either.  I didn't have an answer for this problem at this time.

After adding another program, Windows Explorer began flashing, refreshing itself every couple of seconds, in what appeared to be a different network drive problem.  I have written up the process of solving that in a separate post.

After tweaking the WinXP installation, I began adding programs.  I installed Copernic Desktop Search as one of those programs.  VMware Workstation treated my data drives as network drives, and Copernic regarded network drives as a sign that I was in a workplace, so I could not use their free version with VMware.  I downloaded their professional version ($40 to buy) and used it on a trial basis.  It was not able to save its index to a network drive.  Its index, I heard somewhere, would be about 10% of the total size of the files being indexed.  So if I had 100GB worth of files, I would have a 10GB index.  I definitely did not want that kind of monster sitting on my drive C.  But there seemed to be no alternative.  I decided to add a third virtual hard drive (30GB max, not preallocated) to the VM, made it drive Q, and told Copernic to save its index there.  When Copernic was done with its indexing, that drive

The only tweak that didn't seem to work was the one where I went into Internet Explorer and tried to save its Temporary Internet Files folder to some drive other than C.  It wouldn't save to a network drive.  But it also wouldn't even save to the little drive that I had created to serve as a paging file.  Possibly there wasn't enough disk space available for it there.

In the interests of improving performance, I worked through a VMware document on that subject.

Windows Explorer Fails to Retain Multiple File Selection

I was installing Windows XP SP3.  I had just installed some basic utilities, mostly related to the user interface.  After doing so, I noticed that Windows Explorer would allow me to highlight files and folders, but when I right-clicked and hit Cut (or when I used Ctrl-X), the folder icons would fade for a second, as they would typically do when files were being cut and pasted; but then the fading effect would end.  And if I went to another folder and tried to paste, there was no right-click (context menu) paste option.  I could move them only by dragging them to that other folder.  The choice of view (e.g., Detail view, Icon view) did not seem to make a difference.  The problem occurred in a variety of folders.

I went back to a previous backup of this Windows installation and started over, installing those same programs again.  This time, the fading effect ended as before, but now cutting and pasting did work properly.

I did a search, initially, on the problem of being unable to select multiple files.  That led to a post discussing some solutions.  It looked like Vista users were having this problem too.  But when the problem recurred in the different form just described, I opted to try a different search.  There were no obvious solutions on the first several pages of that.  So I decided to work back through the programs I had recently installed, to see if one of them was responsible.

What I found was that the effect of the offending program was not immediate.  The problem didn't appear until after I had rebooted.  This was why I did not notice it right away, and just kept on installing other stuff.  So I installed them one at a time, rebooting and testing after each one.  This procedure established that the problem was due to the M8 Free Clipboard program.  I proceeded with installing my other programs.  The problem did not recur.

Windows XP in VMware Workstation 7.1: Windows Explorer Keeps Refreshing

I was running Windows XP SP3 as a guest in a virtual machine (VM) in VMware Workstation 7.1.1 on an Ubuntu 10.04 (Lucid Lynx) host.  I had just installed a couple of freeware utilities when suddenly Windows Explorer began refreshing itself about every two seconds.  More specifically, it was refreshing the right-hand pane, showing files and folders, but not the left pane, showing the folder tree.

I thought at first it was a virus, but I was running antivirus software, and a scan with a different antivirus program turned up nothing.  Besides, I had just downloaded those programs from reputable sources (e.g., CNET) that supposedly certified them to be virus-free.

A search suggested this was a relatively common problem.  Several posts made me think it had to do with network drives, which in this case would mean the link between Windows and VMware.  I killed the VM, reverted to a previous snapshot, and started that, but the same thing was happening there as well.  I powered up a different VM in a different session of Workstation.  The problem was not occurring there.  I closed all sessions of Workstation and powered up the misbehaving VM in a new session of Workstation.  The problem recurred -- but then, after a minute or two, it stopped.  But then, after I used Windows Explorer some more, it resumed; but then it stopped again.

I downloaded the "Prevent Automatic Folder and Icon Refresh" registry edit from Kelly's Korner and ran that, and then rebooted Windows within the VM.  The problem was still there.  I took this to mean that *automatic* refresh was not the problem -- that, presumably, something was manually refreshing Explorer.

I tried displaying different drives' contents in Explorer, on the theory that maybe this was happening in connection with just one particular network drive.  That was not the case; it happened on all of them.

I wondered if a program installation was responsible for the problem.  But it was not clear to me how any of these would have been responsible for the fact that the flashing occurred within a snapshot that I had taken before installing them.

Then I came closer to what seemed like a possible answer.  I tried again to install the Microsoft Task Switch Powertoy.  I had tried before, and it had given me an error message, and the same thing happened again.  The error message was "Error 1606.  Could not access network location [gibberish]."  The gibberish was actually just a set of five squares with no characters in them.  It appeared that the installer was trying to access a network location whose name did not consist of valid characters.  Following advice, I checked the following registry keys for incorrect addresses:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

I did find several bad entries in the second of those five locations.  I corrected those and rebooted the VM.  I was now able to install the PowerToy.  Unfortunately, the flashing was still going on.  I went into VM > Settings > Options > Shared Folders and switched that to Disabled > Save.  The flashing stopped.  In Windows Explorer, I tried to go to another network drive, but got the message that it "is not accessible.  The network path was not found."  I went to drive C (not a network drive).  Its contents displayed OK.  No flashing.  I set Shared Folders back to Always Enabled.  No flashing on drive C.  Flashing on drive D.  I tried C again.  The folders there would refresh once, immediately after being selected, but then not again.  In Windows Explorer's menu, I went to Tools > Disconnect Network Drive and disconnected drive D.  Drive E was still flashing.  I went to Tools > Map Network Drive and mapped D again.  It was flashing.

A Microsoft Knowledgebase webpage said that a somewhat related problem (flickering in the left-hand pane of Windows Explorer) could be repaired at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer.  I had only a lowercase "policies" (not "Policies") key at that location.  Regedit would not let me create the uppercase version.  So I went into the lowercase "policies" key.  It did have an Explorer subkey.  I went in there and created a new key, NoRemoteRecursiveEvents, of REG_DWORD type, and gave it a value of 1.  I exited regedit and rebooted.  This step did not solve the problem.

I closed this VM and went back to the previous version, the one that did not flash.  I corrected the incorrect registry addresses (above) first.  Then I started reinstalling the programs that I had been installing when the problem began.  I went down the list and, what do you know, the flickering started when I installed FolderSize, and it stopped when I uninstalled it.  FolderSize calculates the size of folders, and apparently refreshes the screen while it does so.  After I uninstalled it, the problem went away.

Windows XP: Unspecified Potential Security Risk Dialog

In Windows XP SP3, I was encountering this message when I right-clicked on a .zip archive file:

Internet Explorer
This page has an unspecified potential security risk.
Would you like to continue? 

It took several tries before I found an approach that worked for me.

One approach:  in Control Panel > Internet Options > Security tab > Local Intranet > Sites > Advanced, add "file://[computername]" using the name of the computer found at Control Panel > System > Computer Name > Change.  So, for example, if your computer was named COMP, you would add file://COMP.  This did not work.

Another approach:  go into the Trusted Sites rather than the Local Intranet, click Default Level, set Allowed Levels to Low, click Sites, and type "\\[computername]" in the Add box.  (Note that you could also get to Internet Options via Start > Run > inetcpl.cpl.")  But this gave me an error:  "Sites added to this zone must use the https:// prefix.  This prefix assures a secure connection."

A third approach:  Start > Run > services.msc > scroll down and double click on Security Center > Startup Type.  Make it Disabled > Stop > Apply > OK.  This did not work.

A fourth approach:  Control Panel > Internet Options > Security tab > Local intranet > Sites > uncheck Automatic and check all three "Include all" boxes.  This worked!

Still another approach, which I didn't try, would involve using the domain name.

VMware Workstation 7.1: No Bootable Device Was Detected

I was using VMware Workstation 7.1 in an Ubuntu 10.04 host.  I had two Windows XP virtual machines (VMs).  One of them would start up and run without a problem.  The other one had done so previously, but was now failing to do so.  Both were pretty basic Windows installations.  There had been some hardware crashes and freezes, due to other system components, and apparently that had screwed up the one that was not starting.

Or so I thought.  I deleted the VM that was not working and recreated it from scratch, with a new WinXP installation in it.  But the problem was still there.  So, OK, I thought, the problem must be with Workstation.  So even though Workstation was still running the other VM without a problem, I uninstalled Workstation.  To do that, I used this command:  "sudo sh /usr/bin/vmware-installer --uninstall-product=vmware-workstation."  Then I reinstalled Workstation, using the same downloaded .bundle file that I had used for previous successful installations.  I opted to keep my configuration files.  Then I opened the two VMs.  Once again, the one VM ran fine; the other did not.

The one that was not functioning properly was proceeding as follows:  first, it would start in a nearly black screen with the VMware logo, as VMs typically did.  But then, instead of starting WinXP, it would take me to a screen that said "Network boot from AMD [number]" and "No boot filename received" and "Operating system not found."  It also flashed a message at the bottom right corner of the screen that said, "No bootable device was detected."

What caused this, I think, was that I was running a disk check from the WinXP CD on the other (working) VM, and then I attempted to start this (nonworking) VM without disabling its access to the CD drive.  So it latched onto the CD and started wanting to do its own disk check too, or something like that, and I killed it in a most awkward fashion, and now it was among the undead.

By process of elimination, the steps taken above seemed to suggest that Workstation's configuration files were holding a grudge against the nonworking VM, or anything bearing its name.  (I had created the new VM from scratch, but had given it the same name as the one that was previously nonworking.)  To test this, I could see what would happen with a new VM with a different name, or I could delete the VMware configuration files when I was reinstalling it.  Taking the easiest step first, I tried just right-clicking on the dud, in Workstation, to rename it.  That didn't work, so since Workstation had been nagging me to upgrade from 7.1.0 to 7.1.1 anyway, I shut down and uninstalled Workstation again, this time including the config files.  I ran "sudo vmware" and configured the program as root, and then I tried to start the nonfunctioning VM.  No dice.  And the other VM still ran.

But now I was aware of an additional difference.  I had saved the other VM in suspended mode, whereas I had shut down the nonworking one altogether.  What would happen if I tried to reboot the one that was still on its feet?  I tried it.  It rebooted fine.  Being in a suspended mode had somehow protected it, maybe.

Trying the other option, I created a new WinXP VM from scratch, but this time I gave it a different name, before deleting the other new (nonworking) one.  But I couldn't.  I got as far as the installation screen that says, "Install operating system from," and it wouldn't let me go any further.  The Next button was greyed out.  But then, duh, I thought maybe that was because I had set the system to not recognize the CD at bootup, not that that quite sense.  Or, I thought, maybe I screwed up the CD drive, or maybe I should do a cold restart.  So, OK, I shut down the computer altogether for 30 seconds, and then fired it back up.  That didn't work.  I killed Workstation.

It occurred to me to insert the WinXP CD back in the drive, setting the CD-ROM to connect at power on, and then start the VM.  That looked like it may have been the solution.  I got the Windows Setup screen, leading to WinXP's Recovery Console.  Evidently something in Ubuntu or Workstation or the VM got the idea that life was not going to be complete until it could lovingly caress that Windows installation CD one last time.  So when Windows Setup was done singing its song, it rebooted on its own and tried restarting the previously nonworking VM.

At this point, I realized I had made a dreadfully stupid mistake.  Although I knew better from previous experience, somehow I had assumed that WinXP was already installed on the VM.  It wasn't, and I think if I hadn't been so bored and burned out on computer stuff by this point, I would have realized that immediately.  What was actually going on was that I was trying to start a VM that did not yet have an operating system loaded on it.  Problems and solutions don't get much more obvious than this.  So anyway, now it was in the process of installing WinXP, as it would have done some time earlier if I'd had the WinXP CD in the drive and had enabled the drive in Workstation before those various reboots.

Microsoft Office 2003 Updates in 2010 and Beyond

Introduction

At one point, I had installed Microsoft Office Professional 2003, and I wanted to know what updates were available.  Once upon a time, that was easy to determine.  You would just go to the Microsoft Office Updates webpage and let it take a look at your computer and tell you what you needed.  But that webpage was no longer available.

Microsoft was apparently still supporting Office 2003, and it was still possible to get updates from the general-purpose Microsoft Updates webpage.  But under various conditions, that would not work either.  For instance, Microsoft might decide to cut off that source of automated updates for Office 2003, just as it had cut off its Office Updates automatic detector.  Or you might not be able to go online when you were doing your installation.  Or if you did go online, as I had sometimes experienced, that webpage might not be willing or able to detect the condition of your computer and figure out which updates you needed.  Or you might be trying to install all available updates at once -- that is, you might not be willing to wait around until the webpage did detect all of the updates you might need.  That was the situation at present.  I was trying to convert Office 2003 into a set of portable applications, and for that purpose I needed to do all of my updates at once if they were to be included in the portable executable package.

To figure out what updates I needed, I went to the general-purpose Microsoft Office Downloads webpage and glanced at its hundreds of downloads, including many that were unnecessary and even obsolete.  Then, taking a different approach, I looked at another computer, where Office 2003 had been installed in March 2009.  (On that machine, all Office programs were installed except InfoPath, and Outlook 2007 had been installed in lieu of Outlook 2003.)  On that machine, I went into Start > Settings > Control Panel > Add or Remove Programs > Show Updates.  Under Microsoft Office Professional Edition 2003, it listed a number of updates.  Those updates had been installed automatically by Office Update between March 12, 2009 and March 10, 2010.  With one exception, all of the updates listed there were newer than Office Pro Service Pack 3 (SP3).  That one exception had not been included in SP3, so apparently Office Update knew that it still had to install it separately.

Armed with that information, I went back to the full list of Office updates.  At this writing, there were 3,204 items on that list.  I sorted them by Release Date and skipped ahead to the page for September 2007, when SP3 was released.  I noticed that there were other SP3 packages released at about that same time, for a variety of Microsoft products, including some that were related to Office 2003 tools or capabilities (e.g., Office 2003 Proofing Tools) that I had not installed and/or had not been using on that other computer, and that therefore had not been updated.  So the list that I was developing in this post would probably not be sufficient for all purposes and all users of Office 2003.

I decided to assume that the automatic Office updating feature had been giving me what I needed, for my Office 2003 installation, up through that last update on March 10, 2010.  Therefore, I skipped ahead again, in the Microsoft webpage list, to the page showing updates released on or after that date.  That page was very near the end of the list.  (I tried, here in this post, to provide links to these points in the list, so that other users would not have to page through the list manually, but I found that Microsoft had structured the pages so that the links invariably led to the start of the list.  Microsoft did not itself bother to provide a button leading to the end of the list.)  From that point forward in the list, starting in March 2010, there were not any other updates pertaining to Office 2003.  So it seemed that the March 2010 updates were the state of the art.

But that could hardly be correct.  After thinking a moment, I remembered that, because of a broken installer or some other problem that I had been unable to fix, that other computer had ceased to install updates from the regular Microsoft Update webpage.  So now I asked that webpage to examine that computer and indicate what other updates it needed.  It came back with a list that included several more updates specifically related to Office 2003.  I did not know why these additional updates had not appeared in that list of 3,204 updates on the Microsoft Office webpage.

The List of Updates Generally

I combined that list of uninstalled updates, from the Microsoft Update webpage, with the list of updates that had been installed successfully.  Here is that combined list, with links to the relevant KnowledgeBase pages:

Release Date	Programs Affected	KB Number
11/08/05	Excel, Word	KB907417
09/17/07	All Office 2003 (SP3)	KB923618
12/08/07	Outlook	KB943649
02/11/08	All Office 2003	KB945185
02/12/08	Works File Converter	KB943973
05/12/08	Publisher	KB950213
08/08/08	Access Snapshot Viewer	KB955439
08/08/08	All Office 2003	KB921598
09/08/08	All Office 2003	KB953404
11/07/08	All Office 2003	KB951535
10/09/09	Outlook	KB974554
10/09/09	Outlook	KB973705
10/13/09	All Office 2003	KB972580
10/22/09	Web Components	KB947319
11/09/09	All Office 2003	KB973443
12/07/09	All Office 2003	KB975051
12/17/09	All Office 2003	KB978551
02/04/10	PowerPoint	KB976881
03/05/10	Outlook	KB979771
03/05/10	Excel	KB978474
05/10/10	All Office 2003	KB976382
06/04/10	PowerPoint	KB982157
06/04/10	Publisher	KB982122
06/04/10	All Office 2003	KB982311
06/04/10	InfoPath	KB980923
07/07/10	Access	KB981716
07/08/10	Outlook	KB980373
08/05/10	Word	KB2251399
08/04/10	Outlook	KB2279246
08/04/10	Excel	KB2264403

Again, this list would vary if one were to install other components from Office 2003.  My purpose here is primarily just to sketch out what seems to be one way of determining what updates are needed for one Office 2003 configuration.

The List of Updates for Word 2003 Specifically 

This list of updates, and the other information provided above, seemed to provide a straightforward guide to the updates that would be needed for individual components within Office 2003.  I tested that assumption, starting with Word 2003.  That is, I installed only Word 2003, without any other Office 2003 components beyond those that were automatically installed for any Office configuration.

I expected, from the foregoing information, that the Microsoft Update webpage would detect and install all of the items from the foregoing list that pertained either to Word specifically or to Office generally,  I expected, in other words, that when the dust settled and all the updates were installed, Control Panel > Add or Remove Programs would show me just the following updates under Microsoft Office 2003:

Release Date	Programs Affected	KB Number
11/08/05	Excel, Word	KB907417
09/17/07	All Office 2003 (SP3)	KB923618
02/11/08	All Office 2003	KB945185
08/08/08	All Office 2003	KB921598
09/08/08	All Office 2003	KB953404
11/07/08	All Office 2003	KB951535
10/13/09	All Office 2003	KB972580
10/22/09	Web Components	KB947319
11/09/09	All Office 2003	KB973443
12/07/09	All Office 2003	KB975051
12/17/09	All Office 2003	KB978551
05/10/10	All Office 2003	KB976382
06/04/10	All Office 2003	KB982311
08/05/10	Word	KB2251399

That, however, is not quite how it had worked out.  After installing only Word 2003, the Microsoft Windows Update webpage was telling me that I had no other updates to install.  I thought maybe this was because it was a brand-new installation and it needed some stimulation to get busy and figure out where it stood.  In hopes of triggering some action, I started Word and fiddled with it for a minute, and then I rebooted the system.  But the Update webpage still showed no other updates available.  Likewise when I powered down the system and left it alone for a couple of days.

I wasn't sure what that meant.  Was the Windows Update webpage never going to detect that updates were needed?  Or did I just have to use Word for a while, triggering some unknown functions, before it would become aware of its desperate need for an update?  Did it matter that I was doing this inside a VMware virtual machine (VM), rather than in a native WinXP installation?

The alternative to the automated online update, of course, was to just go ahead and install that list of Word-specific updates manually.  So I did that.  I uninstalled and reinstalled Word; and when it ended, I accepted its offer to go online and check for updates.  Without the old Office Update webpage, however, that option just delivered me to the general-purpose webpage mentioned above.  I killed that and started down the list of updates, installing them one by one, beginning with SP3 (KB923618).

After doing that, I went into Control Panel > Add or Remove Programs > Show Updates and verified that those updates were all listed under Microsoft Office 2003.  They weren't.  KB945185 wasn't listed.  I ran it again, and it said, "This update has already been applied or is included in an update that has already been applied."  That puzzled me:  how would I have gotten its number in the first place, if it hadn't been listed previously?  Same thing with KB953404.  Anyway, then I went to the Windows Update website to double-check that there were no others.  There weren't.

Conclusion

I could have continued with the same approach for Excel 2003 and other components of Office 2003.  In the meantime, however, it had developed that the underlying goal of creating a portable version of Office 2003 was not feasible with existing programs and resources.  So I did not continue on to explore what updates would be needed for those other Office components.