A while back, I was having serious issues implementing a conversion from User Profile Disk (UPD) to FSLogix Profile Containers on a Windows Server 2016 Remote Desktop Session host Collection. The FSLogix user sign-in process was not just a few seconds but several minutes prolonged!
Long story short. I spent more time on this than I care to admit. In the end, all I had to do, was delete the notifications registry key. You can find the script I made, at the end of the article.
Debugging FSLogix slow sign-in.
I was obviously double-checking the configuration and returning to a fundamental configuration with only the essential defaults set. But the issue remained.
The FSLogix log files indicated that it was doing absolutely nothing after the “Prep1” step. And then, after a long wait, it completes “Prep2” in a second!? What the heck is going on, I thought?
I whipped out my good old friend the Process Monitor from Sysinternals but could not really see anything stealing resources or delaying the login process (I had obviously excluded the FSLogix process and containers from the Antivirus software).
I decided it was time for some sparring and called up my colleague Morten Pedholt who has extensive knowledge of FSLogix from countless Azure Virtual Desktop implementations. Together we confirmed that every bit of the configuration was correct. So now we were stuck and started to try everything we could think of.
- Checking the VM performance.
- Trying every crazy combination of settings.
- Unlinking all GPO’s.
- Testing on every single different session host in the collection.
- Using the FSLogix Support tool
- Trying out even the most obscure suggestions from Reddit and the tech community.
The reason why sharing your experiences online is important!
Lo and behold! We found the culprit after reading a few places about some minor login delays caused by the notifications area part of the registry.
I initially dismissed this information because the delays I was experiencing were not minor but rather extreme. Nevertheless, we tested the solution on a Session Host and found that just opening the registry area of the notifications in Windows took us 6 minutes! About the same amount of time it took to sign in!
This was no coincidence! And there is even an old support article from Microsoft about it which applies to an older Operating System, but it is the same problem.
The registry key for the notifications is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications
To give you an idea of just how horrific an experience this was. I recorded this video in real-time (It’s the same experience for the FSLogix slow sign-in).
Shutdown script to the rescue.
Naturally, I deleted the useless notifications key and recreated an empty one. And Once I had done that, I rebooted the Session Host.
To ensure this never happens again, I created a Group Policy containing a shutdown script so that the notifications registry key would get cleared on every reboot of the Session Hosts.
The simple script contains the following code which you can run once and then reboot, or like me, have it run on every reboot.
The script that fixes FSLogix slow sign-in
Remove-Item "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications" -Recurse New-Item "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications"
Upgrading to FSLogix profile containers on a set of well used Session Hosts can be more trouble than it is worth. But in this case it was unavoidable. Planning for road bumps like this is key to making your deadlines.
As always I hope you will add your comments below and follow on twitter to show your support.