QuickPost – FSLogix “user’s Registry hive was missing” error at logon

This will probably be the quickest of QuickPosts in the history of my 9-year blogging career, but I encountered this error today and realized that there were a lot of Google hits matching it, but not much of a solution.

Problem

When a user was logging in for the second time using FSLogix Profile Containers as the profile management solution, all of their settings were disappearing. If you were fortunate enough (as I was) to be actually looking at the file share holding the containers during the logon process, you would see that the user’s profile container was actually marked as “CORRUPT” (so you would spot it being renamed with a CORRUPT_ prefix), and then the original renamed container was deleted and replaced with a vanilla, default one.

Logs

If you were to check the FSLogix logs (which would obviously be the most sensible thing to do), you would see an error similar to that shown below

[12:16:29.131][tid:00000e64.00002e80][ERROR:00000002]   Creating new user profile disk (user's registry hive was missing) (The system cannot find the file specified.)
[12:16:29.131][tid:00000e64.00002e80][INFO]             Renaming corrupt user profile disk. From: \\dc001\fs\profiles2\jrankin_S-1-5-21-678947852-976068900-399424051-1103\Profile_jrankin.VHDX To: \\dc001\fs\profiles2\jrankin_S-1-5-21-678947852-976068900-399424051-1103\CORRUPT_38a0c16c-9e98-492d-9cbb-c56df29e7e65_Profile_jrankin.VHDX

This is indicating that the user’s NTUSER.DAT file, which is the user’s Registry hive, simply cannot be found. If FSLogix encounters a profile container without any Registry settings, it does what is natural – marks the profile as corrupt and creates a new one. It also deletes the corrupt profile afterwards, which seems kinda drastic, but I guess keeping a profile around that has no Registry hives isn’t much use (unless you could maybe restore them, sort of like Citrix UPM does with the “LastKnownGood” copy of the DAT file).

When the user logged out after their first logon, I mounted their VHDX and found that it was almost completely empty, despite the fact that I’d copied a whole host of large files into it. Either something was preventing the write-back occurring (which would be odd, given that the profile was successfully mounted in the first place), or something was emptying the profile and FSLogix was simply doing its job and replicating the empty container back to the server.

Solution

Thanks to the clever bods over on the World of EUC Slack channel, I was quickly pointed in the right direction and resolved the issue, rather than wasting my entire afternoon troubleshooting.

This can be caused by another profile management solution existing alongside FSLogix. If you’ve Citrix UPM, Ivanti UWM, Microsoft UE-V, VMware DEM, LiquidWare, Scense or any one of the other myriad profile management solutions installed alongside FSLogix, you may want to check that the two aren’t conflicting. If the “other” solution gets in first and processes profile changes, you may find that there is nothing for FSLogix to copy.

Obviously another cause would simply be a failure to write the files back to the container, so check that something hasn’t changed with permissions or share access. It’s always worth mounting the VHD(x) container offline and seeing what you can see within it if this problem manifests.

Also be careful that no-one has gotten too creative with the redirections.xml file, which as I’ve said on many times already, is not something you should be leaning too heavily on. If you’re constrained by storage, then FSLogix probably isn’t the profile solution for you.

In my case, I’d forgotten to unlink a GPO that marked the profile for deletion (this was intended to remove local profiles, rather than to be used on FSLogix profiles). Any messing with the profile state key or simply using something like delprof2 to purge the profile would obviously do this as the user was logging out, and FSLogix would then faithfully write the empty folders back to the container, creating the missing Registry hive error.

Summary

if you get this error, something is stopping the ntuer.dat being written back to the container, and quite possibly a lot of other stuff as well. Check for conflicting profile solutions (especially ones that might have lingered around), access permissions, and anything that deals with purging the user’s profile.

Stay tuned for more logon optimizations, and maybe even me stepping out of my comfort zone with some cloud stuff(!)