Go to ...

RSS Feed

July 16, 2020

Coping with a small system disk, Part 2 – Relocated Program Files

In August 2018, I wrote about how to cope with a small system disk, using my HP ProBook 470 G5 laptop as an example. This laptop includes both a 128 GB SSD and a 1TB HDD. My required software occupies 70+ GB, which makes it quite impractical to get software installed and user profiles stored on system drive C: (the SSD). In that earlier post, I recommended not to use the registry to relocate Program Files and Program Files (x86) folders to another drive. Instead, my suggestion was to manually change the install location for each piece of software.

A week and a half ago I decided it was time for further testing. I wanted to find a useful way to completely relocate the Program Files to another partition on the HDD, and reserve the SSD and its C: partition purely for Windows.

Capturing a custom Windows image

Windows Insider build 18329 had been released a few days earlier. I clean installed it on a reference machine, in my case a Hyper-V virtual machine. I customized it as always, with custom themes and settings, and installed my preferred software which includes some storage intensive titles such as Visual Studio, Windows ADK & WinPE environment, Office 365 with four language packs, and so on.

When that was finished, I sysprepped Windows using my standard unattend.xml answer file, which automates the OOBE and relocates Windows user profile folder Users to partition E:. To build answer files, see my series about automated, unattended install of Windows: https://win10.guru/windows-10-unattended-install-media-part-1-basics/

When sysprep completed, I captured the resulting custom Windows image to a custom install.wim file.

Edit registry on offline image

Before using that image, I mounted it to edit its registry. For those not familiar with the process, I’ve written a tutorial at TenForums.com:

To relocate Program Files, the highlighted string values in screenshot must be changed, with all references to the C: drive changed. In my case, I changed them to the D: drive instead:

Changing these string values requires editing two different keys:

1.) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
2.) HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

I unmounted the offline image, and replaced the original install.wim on my build 18329 ISO with the customized one, and created a USB install media.

Installing Windows

Booting the laptop from USB, I used DISKPART to partition both the SSD and the HDD. I then copied Program Files with the following command, to get everything including protected system files and folders copied to my software partition D. I ran the same command again to copy the Program Files (x86) folder, too:

xcopy "C:\Program Files" /h / s / e "D:\ProgramFiles"

Only two things remained missing. First, I was now ready to run Windows Setup to install Windows. When that’s done, during the first boot to the desktop, I deleted all third party software folders from Program Files folders on the C: drive as unnecessary, duplicates on the D: drive being now the actual ones. In my first tests, I completely deleted the Program Files folders from C: but that did not work; with that done, Windows became dysfunctional. The Start menu did not work, UWP and PWA apps did not run, and so on. As far as I am concerned, it seems to be best to only delete duplicate third party software folders, but leave native Windows folders as duplicates on the C: drive.

At long last, I was done!


My Windows 10 works perfectly, with the Users folder relocated to drive E: and all software (Program Files) on the D: drive. I only had one minor issue, which was easily resolved:

I am now sure I can recommend this method to save storage space on small system disks. My C: drive on SSD only uses about 36 GB at the moment, including a 12 GB VHD I use as a parent disk when creating Hyper-V virtual machines with differencing disks:

Here’s how the custom setup looks in File Explorer:

Any cons?

Only con in doing this is that upgrade and repair install are not possible:

Luckily, a workaround is easy: when upgrading, or doing a repair install, edit registry and set Program Files folders back to C:, upgrade, then edit registry again after the upgrade to change them back to another drive.

To be best of my knowledge and belief, this works without issues, I am quite happy I decided to test this!






Author: Kari Finn

A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.

Leave a Reply

More Stories From Admin Tools