Explorer size and location cache no longer works after migrating local profile to domain profile

All,

I want to preface this inquiry with the following: this is a home lab environment and does not affect production systems in any way. Any information provided will be tested in a test VM prior to execution on any critical system.

I recently joined my primary home system to my lab domain. I wanted to retain all of the settings and configurations of my local system but use a domain account to login. I followed this migration write-up:

Step by Step : Migrate Local User Profile to Domain User Profile with all Settings

The gist of the migration involves adding the domain user to the ACL for the C:\Users\localUser with Full Control and propagate those permissions through the folder. This step worked without issue. Then, modify the ACL for the HKCU hive by adding the domain user to the ACL with Full Control and propagate those permissions through the hive. This step appears to work, but some keys cannot be modified. Finally, we change the ProfileImagePath for the domain user SID under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and reboot.

The change appears to have worked without issue. All of my settings are intact, and the look and feel is as expected. One very significant problem, however, is that the window (explorer.exe) size and location cache is not functioning. If I click on File Explorer, the window opens as usual, but the layout is using tiles while I prefer the Details view. I change to the details view and make some other changes, close the window, re-open the window, and it's back to the initial layout with tiles and the size is set back to a smaller default.

I did some research and significant reading on the Shell Bags and BagMRU registry hives and how they work. I read Annanya Podder's response to remove the Bags and BagMRU folders and recreate them with default configurations:

Windows 8 doesn't remember size and position of previously opened programs

This does not resolve the issue, however. I opened ProcMon and started a trace while opening, resizing, closing, and re-opening a File Explorer window, and there are no registry queries or writes of data to any of the bag hives which leads me to believe there's something corrupt with the registry. If I perform the same trace on a functioning Windows 8.1 VM or even with another profile on the affected machine, I see queries and even writes to the Shell/Bags registry hive. The affected profile doesn't even try to query those hives or otherwise write to them, and there are no 'ACCESS DENIED' or 'NAME NOT FOUND' results in the ProcMon output.

I exported the HKCU hive prior to making any changes, but I cannot update a loaded hive with the export. I receive an error that the key or subkeys could not be updated. I did not, however, save a copy of the old NTuser.dat file, but the HKCU export should have that data, no?

I'm at the point now where I can go along to get along, but I'm curious if anyone could guide me down any additional troubleshooting routes to figure this out? The size and location cache used to work without issue, but after the migration, it's not functional. As a system admin, I use file explorer a lot, and having to resize the window every time I open it is going to be painful. Any suggestions or assistance would be greatly welcome.

Regards,

Ron Arestia, MCSA (Server 2012)




September 7th, 2015 5:46pm

I figured out my own issue. Don'tcha love it when that happens?

I logged into the affected machine as the domain administrator, and when I loaded the ntuser.dat hive for the affected user, I noticed that the \Software\Classes key didn't exist. It did, however, exist for the logged on user and it appears to correlate directly to the key under HKU\[SID]_Classes.

On a hunch, I logged back into the affected profile, drilled down to HKU\[SID]_Classes, and when I checked the permissions, I noticed that the domain user did not have explicit permissions to the key and subkeys. I added Full Control permissions, propagated them through the key and subkeys, rebooted, et voila! Everything is back to the way it should be.

I'll be leaving a comment for Mahdi Tehrani to ensure this is done to prevent issues like I had.

Free Windows Admin Tool Kit Click here and download it now
September 7th, 2015 6:13pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics