I recently had an interesting problem which I couldn’t find anything about on the Internet.
(Which probably isn’t that weird…)
After running inplace upgrade to Windows 10 1607 a lot of our machines suddenly had broken environment variables resulting in an totally broken OS.
C:\Windows\system32 was now C:\Users\<username>\Documents\Windows\System32 and so on.. All paths had changed to the documents folder of the primary user.
After digging through literally millions of lines of log I found this in $Windows.~BT\Sources\Panther\setupact.log
It seems that Windows is changing the paths of all executables to my documents-folder.
After some more searching i stumbled across this:
and the %CSIDL_MYDOCUMENTS% kinda gave it away.
This variable is the same as the “Personal” value in Shell Folders/User Shell folders which Points to Your documents folder. Only my doesn’t…
It’s kinda hard to show with a censored image, but all the paths containing C:\Users\<username>\Documents is actually not the same user..
MY variable for “MyDocuments” is C:
Which led me to the solution..
When the setup is remapping folders, it uses this variable “kinda backwards”.
C:\ in this example is my documents folder.. so everything under C:\ should be mapped to the new Documents-folder in “inplace-upgrade-logic”.
I reinstalled my test-client with 1511, changed the “Personal” reg-key, started the upgrade and crossed my fingers. I have tried replicating this problem on my test client for a while and have probably reinstalled and upgraded it 15 times without any problems, but when it was finished this time everything was broken as I hoped for.
It turns out we used to change the personal-variable because this is where default save location points to and we didn’t want users to save files in local documents.. it seemed like a good idea at that time..
To resolve this problem, I created a configuration baseline in ConfigMgr that checks the personal value in shell folders/User shell folders of each profile in HKU:\ and changes it to %userprofile%\Documents.