QuickPost – ImportProfileRegistry error when mounting FSLogix container

Just a very quick one for everyone today, I wouldn’t expect to see this particularly frequently out there, but just in case you do, I’m going to document it.

Had a very odd issue with FSLogix Profile Containers over the past couple of days. Users would log in and receive a “vanilla” Windows profile – all of their previous customizations were gone. Originally, as we had an ongoing issue with it, we suspected Symantec Endpoint Protection was to blame – in fact there is a documented issue here with SEP holding open files in profiles which prevented them being used at next logon. However, the SEP issue usually manifested itself by continued retries in the logs, as below

This issue appeared to be different to the standard “file lock”. Looking at the logs revealed a different error. Most of the profile load routine appeared to be successful, but there was an error apparent in the logs right at the end of the process

You can see the error (which I’m going to type in here so that it can be indexed and searched more easily)

ProfileData.reg failed. Attempting to use .bak file. (Element not found)

Status set to 20: Cannot import Registry information

Now I ran this past the big brains on the FSLogix channel in the World of EUC Slack space, and nobody had seen it before. That’s when I knew it was something very odd.

In case you didn’t know, the user-specific HKLM information that makes up a profile (specifically, the entries in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\[USERSID]) can’t be captured from the user’s profile – for obvious reasons. To get around this, FSLogix uses a .reg file in %LOCALAPPDATA%\FSLogix to import this back in. It’s at this stage that the profile load appears to be failing.

I tried many things focused around the Registry file – checking for file locks, corruption, etc. – but to all intents and purposes it seemed absolutely fine. It seemed to happen regardless of the userid or the state of the VHD, the driver was loaded and functional, rules were being successfully processed – nothing out of the ordinary. I was at the desperate stage of starting to think about opening a case with Microsoft – usually not a great idea, given the shocking state of FSLogix support since the takeover – when something occurred to me.

One thing this environment had that wasn’t usually in the components that I come across was Citrix App Layering. Now, given that App Layering and FSLogix both use filter drivers, it is best practice to adjust the FSLogix filter driver level to 138010, as recommended by Microsoft, so that it does not conflict with the App Layering driver. I was pretty sure this had been implemented – after all, I’d recommended it – but something that I recalled was that if it wasn’t implemented, you’d get oddities about mounting the profile. Usually it involved mounting an empty VHD – but this weirdness didn’t seem too far way from it, so (clutching at straws), I went to check out the altitude value in the Registry.

The Registry value is HKLM\SYSTEM\CurrentControlSet\Services\frxdrvvt\Altitude, and it needs to be set to 138010. The Microsoft/FSLogix recommendation for this is in this article and it’s also referenced by Citrix.

At first glance, it all looked correct – but then I compared it with a working machine in the lab, and the difference became apparent

Pretty obvious now – the value has been inserted as a REG_DWORD, rather than a REG_SZ.

Fortunately, we were able to change the value back to the correct type of a string, and once Group Policy update had completed, users could log out and back in and their profile would be mounted correctly. As these Registry keys apply to the driver, I was expecting to have to restart, but none was required.

So as I said, something that’s unlikely to be a common error, but just in case you do get bitten by it, make sure you’ve configured the right type for your Registry value to set the altitude when using FSLogix with App Layering. In fact, it’s a point I’d like to make in that neither the FSLogix forum post or the Citrix article actually mention that the Altitude value needs to be of type REG_SZ. I know it’s already a REG_SZ and the implication is that you just edit the existing value, but I think it could do with being called out more clearly in the documentation, as especially when people are deploying using GPO, a mistake could easily happen.

That’s all for me now (it’s been a busy few days) but next week I hope to have some more Microsoft Teams fun for you – I know a lot of people are struggling with it and it’s about time I posted an update.