New
#1070
It could have been one of the several hundred Windows updates that caused the duplicate Windows search folder on C:. It wasn't there after I loaded the OS from the distribution DVD and ran the system prep answer file in Audit Mode.
User Profiles - Create and Move During Windows 7 Installation
-
-
New #1071
Kari, I've read that you have indicated that Win 10 isn't compatible with a ProgramData folder on D:. After I loaded the OS and moved the folders, I had about 15 updates fail to install on their first attempt. Most subsequently installed. One error I get in my Windows Logs for Application is related to the Win 10 upgrade updates. Is it possible the Win 10 upgrade updates are causing the duplicate ProgamData folder on C:?
Faulting application name: GWXUX.exe, version: 6.3.9600.18064, time stamp: 0x56042d8f
Faulting module name: ntdll.dll, version: 6.1.7601.19045, time stamp: 0x56259295
Exception code: 0xc0000005
Fault offset: 0x000000000004ac04
Faulting process id: 0x1ddc
Faulting application start time: 0x01d134a2492ae39f
Faulting application path: C:\Windows\System32\GWX\GWXUX.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 87823f99-a095-11e5-8cbe-386077b56e17
-
New #1072
The only way to know for sure is to start from scratch, this time not relocating the ProgramData. As far as I know and judging by my own experience, ProgramData location has nothing to do with your update issue. This is also supported by the fact that you have double ProgramData folders; if the update needs to find the C:\PrograData, it's there.
-
New #1073
Now that I'm aware of this condition that occurred sometime after the system prep operation, I could start over and check to see when it occurs.
I'm thinking that I will install the OS, enter OOBE Mode, then install the Intel Chipset driver, and then all the updates. Then go into Audit Mode and perform the system prep/answer file operation, back to OOBE mode with a disposable User account, reboot to my original User account, delete the disposable User account, and then check the file structure after each application is installed. Also, I think I'll hide all known Win 10 upgrade updates rather than let them install.
-
New #1074
Why on earth would you like to do it that way?
I would do it like this, not apologizing for calling it the correct way:
- Install Windows 7
- Enter Audit Mode before any user accounts have been created
- In Audit Mode, install whatever drivers and software I need to install (as told in this tutorial)
- Create the Answer File to relocate the folders
- Sysprep
Sysprepping an existing Windows installation with existing user accounts is just a workaround, an alternative for those who have already installed Windows and created users but are running low on storage on C: drive.
Sysprep should always be used in Audit Mode on a virgin installation with no existing users. It works in most cases also when users already exist on an existing Windows installation but it is then naturally more prone to various issues.
Kari
-
New #1075
I was thinking that perhaps one of the several hundred Windows Updates changed something that caused the system to create a ProgramData/Microsoft/Search folder tree on C: drive. Since Windows Updates don't install in Audit Mode before the User Accounts are created, if the system was updated and then system prepped, it would resolve the ProgramData folder on C: drive issue, because it would move the folders to D: without subsequent modifications.
Actually, I haven't done anything yet. I'm still investigating this current install.
I did send Hauppauge Support an email inquiring about their program development. I got an interesting response.
My original inquiry:
Hauppauge Support response:Problem description: I installed WinTV v8 on my Win 7 Pro x64 system. During the
OS install, I used the Microsoft AIK to move my User and ProgramData folders to
the D:. I noticed after installing the Hauppauge software, it appears that the
WinTV installer created a new ProgramData folder on C:. I think it also created
some User/Pubic folders on C: as well. I suspect this is a bug in the software.
Perhaps the software developers programed the install to use only a
C:\ProgramData folder. Perhaps it would be better if they used variables to
better adapt to the OS configuration. I would like to know if there is a way to
confirm my suspicion. Also, I would suggest the next version of the software be
fixed to not create its own ProgramData folder. Regards
A screen shot of the key used by Hauppauge WinTV developers to locate folders on my machine after system prepped and updated:Hello,
Response from one of our developers:
we actually check the OS for the path to program data here:
Key=SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Value Name=Common AppData
I suspect the app that was used to move the folders hasn't updated this reg key set.]
The one for C:\Users\Public is found using enviroment variable
%PUBLIC%
If you type this into the explorer bar it will show the value stored
for your PC by the OS
Regards,
Jerry Fox
Technical Support
Hauppauge Computer Works
New York
http://www.hauppauge.com
For more online information please refer to:
http://www.hauppauge.com/site/support/support_faq.html
Please include previous correspondence when replying.
So, the data for that key shows all my folders on C: drive.
Either there is a bug in the AIK/answer file/system prep/move folders method, or something changed that shell folders data back to the c: drive.Last edited by tjg79; 15 Dec 2015 at 15:20.
-
New #1076
If the AIK/answer file/system prep operation is not changing the registry explorer\shell folder location data, then I would think that this conflicting information in the registry is likely the source of programs randomly creating ProgramData folders on the C: drive. There may be a setting in the AIK answer file creation operation that will resolve this issue.
-
New #1077
This is a great tutorial and Kari's personal help has been one of the reasons this is a great tutorial.
As indicated in my previous posts and Kari's assistance, rather than copy or transcribe the answer file, I created it using the Microsoft AIK. There is some slight difference in my answer file and the example posted here, but they are essentially the same.
I followed the tutorial and performed a clean install of OEM Win 7 Pro x64 from the distribution DVD and immediately entered Audit Mode to install drivers, driver software and a few utilities. I then performed the system prep operation and successfully moved my Users folder and ProgramData folder. After I entered the OOBE Mode, I updated the OS, installed a few more utilities and my applications. I then noticed that I had two User folders and two ProgramData folders; one each on C: and D:. One of the C:\ProgramData subfolders was Microsoft\Search. It was small compared to the one on D:, and must have been created by an Windows Update. The following programs also appeared to prefer a C: drive ProgramData folder: Adobe Acrobat, Hauppauge WinTV, Motorola Bluetooth driver software, HP printer drivers and driver software, and NVIDIA driver software. All my other programs seemed to go along with the D:\ProgramData folder. Hauppauge WinTV also preferred Users\Public folders on C:.
As was suggested by Hauppauge Support, it appears that the answer file system prep operation failed to change the drive for a few keys in the registry. Apparently, various software programs used different keys and variables to determine their install configuration. After further investigation of my clean install and Users folder and ProgramData folder move from C: to D:, I observed two registry keys that still indicated C: drive was the correct location for the two folders that were moved to D:
The keys:
Computer\HKey_Local_Machine\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\explorer\Shell Folders
Computer\HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
The C: drive was indicated for various folder paths in the Key Data.
My solution was to delete the programs that installed a C:\ drive Users folder and ProgramData folder and manually edit the registry to change the unmodified Key Data from C:\ to D:\. Also, I cut the C:\ProgramData\Microsoft\Search folder and merged it with the same folder tree on the D:\ drive. I then subsequently reinstalled the programs and they successfully installed with D:\ Users folders and ProgramData folders. Screenshots of the edited key are attached below.
I followed the standard safety precautions before I edited my registry. I had an image of the install, and I backed up the keys before I performed the edits.
This solution was successful and I confirmed by reviewing the Windows Logs and SFC /scannow. I think this solution was necessary, because I was getting an unusual amount of errors in the Windows Logs.
My recommendation is that the first task after entering the OOBE Mode after Audit Mode/system prep is to check the registry keys indicated above and manually edit them before you allow Windows Update to run and before you install any additional software. If you do, you should only have a Users folder and ProgramData folder on D: drive after you perform Windows Update and install additional applications.
These screenshots show the C:\ changed to D:\ for the various paths indicated in the Data column.Last edited by tjg79; 17 Dec 2015 at 23:47.
-
New #1078
What a mess you've created Micro$oft!
I read the OP (actually Change folder/file location - use Move, Symbolic link or Junction?)and a few posts in this thread. Sounds like Kari is very thorough. I admit I haven't used sysprep very much. I am skeptical that using it will yield better results than other (much easier) methods would. I am very open to being proven wrong (not that anyone should feel obligated), but IMnsHO many of the issues I've noticed related to migrating folders in "unusual" ways can be attributed to a very big company not having adequate control over their product management and quality control standards, like testing for hardcoded paths, which often happen b/c programmers are pressured to make schedule deadlines or there aren't adequate review processes to catch them before code/feature freeze.
It's not easy to make all the moving parts behave AND take into account all the legacy considerations AND appease corporate AND consumer interests AND make marketing AND shareholders all happy.
[rant pause]
I have been working on overhauling my system and incorporating an SSD. My perspective about file systems comes mainly from the Unix world, tho I've been a Windows user continuously since the days of DOS, so I've seen the evolution from FAT to NTFS. I haven't had too much respect for M$ engineering "talent" for some time now, and this SSD / overhaul project has not helped to improve it.
There is no good reason that applications should give a hoot about the physical location of data, generally speaking. Sure, characteristics like optical, removable etc are important, but this HDD or that one, why should the app care? That's one of the main reasons for designing links at the filesystem level, so disk space can be managed transparently. But oh no, we can't have users making "arbitrary" decisions on the structure and layout of their hard drive space, why, it would be madness, chaos and sheer anarchy!!!
I started with a clean install, and before I created any users I opened a command shell and created junctions to relocate Program Files + (x86) + ProgramData + Users to HDD drives. I updated 2 major areas of the registry to correspond to the new locations, a step that shouldn't be necessary at all. Initially I used mklink /D, due to the "symbolic link" name, thinking it worked the same as in the Unix/Linux world. Many things just didn't work, like updates and the performance rating tool in system properties. Going back and researching I discovered the way links are resolved in NTFS and that the correct form to use was mklink /J when all elements are on the same host.
I noticed Kari said that Mico$oft "doesn't recommend" relocating Program Files. Why not? That is an obvious place to segregate the core OS from user installed apps, and for developers (and retired devs like me) we install A LOT of software. The registry is such a pain to deal with and makes it so much more difficult to move things around. It is a terrible design approach that just won't die. I would easily fill an SSD in no time at all had I left Program* folders on the SSD.
I followed another's lead in the method I employed to move data off %SYSROOT% and it works OK 98% of the time. I have noticed several "anomalies" that require attention, and can see there are still plenty of spots in the registry hardwired with "C:\Program Files" I may need to fix to eliminate some of these odd behaviors, for example:
- Marking a downloaded update (KBxxxxxxx) as hidden doesn't persist, and the updates get installed anyway, such as those nagging GWX updates to upgrade to Windows 10.
- Sleep doesn't activate (it immediately wakes back up)
- Various user preferences don't retain their settings, but most work as expected.
- Explorer confuses folder names similar to "Program files", whereas they show up correctly in a dir command listing (I renamed the originals before I created the junctions but in explorer it looks like duplicate names).
I admire Kari's systematic and thorough approach, but I'll bet there are issues it doesn't resolve, and that's simply b/c Windoze is a behemoth whose elements are difficult to control. I would be willing to bet that after following this sysprep method you can still find hardcoded paths in the registry contrary to the new locations, or even if that isn't the case for user profile references would have a developers 120 - 240GB SSD filled in no time at all. Actually, relocating Program Files is bar far the most straighforward set of folders to migrate as there are no self referencing junctions in them. Getting the registry to conform is an entirely different matter tho.
-
New #1079
Hi Kari,
I did as per your tutorial but have encountered difficulties in installing several programs after the folders have been successfully moved to the other disk. Specifically, I am unable to install programs that require .NET framework. I tried installing the framework on its own but still received an error as attached. I have also noticed that windows update check is always running but never seem to fetch anything.
I greatly appreciate your tutorial and hope that you can help me in resolving this too.
Thanks!
Quote
Related Discussions