It has been a couple of months since I installed Windows 7 on a relatively small but fast SSD, with the program files on a fast modest sized conventional hard drive and user data on a large average speed hard drive, which I wrote about in a previous blog. This is a review of the experience and some tweaks I have had to make since.

The consistently most impressive aspect is the start up time of Windows itself, once the computer’s BIOS and its messages have finished loading Windows brings up its login screen in a few seconds – the BIOS screens take the longest. Resuming Windows from hibernation is also incredibly fast.

Programs generally load faster, although some seem to take more time than I would expect.

Generally, I am happy with the performance of this configuration as compared with just a single large hard drive.

Was it worth the effort?

If I had been able to find reliable guides to doing this before I started, then it would probably have been worth it or if I had a number of machines with the same configuration. If I had known that it would have taken so much work when starting the project then perhaps I might not have embarked on it. On the basis of start up time alone compared to the time it took me to do it, it still owes me a lot of time, however I feel I have other benefits, but there are some disadvantages.

Although the ProgramFiles, ProgramW6432, and ProgramFiles(86) environment variables are set to D:\Program Files and D:\Program Files(x86) many programs installations install to the C: drive by default. This means the registry is littered with references to C:\Program Files etc. The Junctions I created during he istallation I describe in the previous blog in the C: drive pointing to the respective folders still ensure that the programs are installed in the right place, but nonetheless I expected programs to be better behaved than that.

Even more surprising was Microsoft’s own Office application, as it by default wanted to install in the C:\Program Files(x86), so I did a custom install to D:\Program Files(x86). Remarkably though Microsoft’s installers keep putting in registry entries to C:\Program Files(x86), despite that never being listed as the installation location.

Generally though these misplaced registry entries do not cause an issue in every day operation, and backups which I was worried about traversing the links has not been a problem.

When installing some applications to their default locations I got errors about not being able to install to a reparse point, and then prompted for a new location and when I correctly pointed things to the D: drive everything was fine. Developers should take note, that Windows provides a a few ways of determining the path to certain features and rather than hard coding these into your installation software you should install them where the environment variable tells you they should go.

When it comes to Windows Updates and Office Updates I got many errors, and many installs would not install. This was far more concerning. Fortunately I was able to overcome this, but it was fiddly, time consuming, and potentially dangerous as it involved changes to the registry. Whenever you fiddle with the registry there is always a risk that once small slip and you delete or damage a vital part of the registry which might even stop Windows from booting. You should always take a backup of the registry. The easiest way to back up the registry is to Create a Windows System Restore point, however you can also export the registry to a file. To be extra sure, if I am majorly editing the registry I will do an Acronis TrueImage backup of the partition.

The aspect of the Registry that was most like to be creating problems was the HKLM (HKEY_LOCAL_MACHINE). After running Regedit.exe as Administrator I exported the HKLM to a file. To do this highlight the Key name, and either [Right Button] – Export or use the menu File – Export… and save it as a file.

Open this file in an text editor – Notepad is fine. Replace all occurrences of “C:\\Program Files” with “D:\\Program Files” (ie the backslash is escaped, you can also find and replace any references of “C:\Program Files” with “D:\Program Files” although you are more likely to find the unescaped form of the backslash “C:\Program Files” in the Users hives rather than in the HKEY_Local_Machine hive.

When I did this there were about 2000 entries, and so after replacing these I imported the file back into RegEdit and restarted the machine.

I repeated this process to check that all the entries had been changes, and it was only roughly half that were. One of the issues is that if a program is holding part of the registry open, you cannot make changes to that area.

Using Task Manager, I closed down as many of the processes that I dared, and repeated the export, edit, import process. I found there were about 200 entries that I couldn’t change.

This time when I did the Windows and Office Updates everything went smoothly, and so far I have not had to do edit the registry again, although I just checked and I am back up to about 1500 entries. I suspect one day I will need to tidy up the registry again.

So unless you are comfortable with these caveats, then I would probably recommend against trying to set up Windows on a SSD partition, and relocating the Program Files and User data, but if you want to improve performance and these issues are not so great for you then go ahead – knock yourself out.