UPDATED March 2026 -- This post has been reviewed and updated to reflect current Microsoft product names, portal locations, and technology status. See inline notes for specific changes.

In this short blog post I will explain a solution for fixing an FSLogix slow sign-in process.

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!

NOTE (Updated 2026): Windows Server 2016 reached end of mainstream support in January 2022 and end of extended support on January 12, 2027. If you are still running FSLogix on Windows Server 2016, plan your migration to Windows Server 2022 or 2025. FSLogix is fully supported on current Windows Server versions.

TL;DR;

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 GPOs.
• 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 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"

Conclusion

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.