MSEndpointMgr
FSLogix slow sign-in

FSLogix slow sign-in (fix)

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!

Waiting forever for something to load, can drive a person nuts.

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 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.

Registry bloat causes slow logons or insufficient system resources error 0x800705AA in Windows 8.1 (microsoft.com)

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).

Notification areas registry key was bloated on this system!

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"

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.

As always I hope you will add your comments below and follow on twitter to show your support.

(19593)

Michael Mardahl

Michael Mardahl is a seasoned IT pro with over 25 years of experience under his belt. He's a Microsoft Certified Cloud Architect at APENTO in Denmark, where he helps customers move from traditional infrastructure to the cloud while keeping security top of mind. When he's not working, Michael's either spending time with his family and friends or passionately blogging about Microsoft cloud technology. His expertise in this area has even earned him the prestigious title of Microsoft Most Valuable Professional (MVP) in both the Enterprise Mobility and Security categories. In short, Michael is the IT equivalent of a rockstar, but don't expect him to act like one - he's way too down-to-earth for that.

11 comments

  • Hi guys,

    just one little hint: Please do not delete the Notification Registry Key when RDSH2019 or 2012R2 is used.
    It does only work with RDSH 2016.
    The problem with deleting the Notifications Reg Key is that all scheduled tasks and the Server Manager Performance Monitor under PerfMon on RDSH 2019 and RDSH 2012R2 stop working (All Scheduled tasks will be queued and not executed and the Server Manager Performance Monitor cannot be started anymore).
    The following Microsoft Technet Link references to a blog post from a colleague who has had similar problems regarding queued scheduled tasks which won’t be executed anymore:
    https://docs.microsoft.com/en-us/answers/questions/217971/windows-server-2019-rds-task-scheduler.html

    Best,
    Stefan

  • Hi guys, just one little hint: Please do not use that if you have enabled scheduled tasks in place on Server 2019 RDSH systems.
    The tasks are queueing and queueing and do not execute anymore because of the deleted and recreated “Notifications” registry key.
    Here is on link where another guy had a similar task scheduler problem after deleting the “Notifications” registry key: https://docs.microsoft.com/en-us/answers/questions/217971/windows-server-2019-rds-task-scheduler.html.

    Best,
    Stefan

    • Thanks for Sharing Stefan,

      This is why testing is important 🙂
      Though I have not seen this issue on 2019 RDSH.
      I guess that is why we say “it depends” all the time 😉

  • Hi. I am unable to delete that notifications registry key even though I am an admin. Is there a service that must be stopped first???

  • Thank you for your article!
    I found out this issue by investigating the fslogix profiles log

    I found out that “Cleaning out notifications” taking too long and than in server event log you could find errors 6005 and 6006 login taking too long frxsvc

    small example from fslogix profiles log file
    [16:49:26.390][tid:000008ec.000002e4][INFO] Configuration setting not found: SOFTWARE\FSLogix\Profiles\CleanOutNotifications. Using default: 1
    [16:49:26.390][tid:000008ec.000002e4][INFO] Cleaning out notifications
    [16:50:48.634][tid:000008ec.000002e4][INFO] Load user classes hive to perform operations for roam

    if you add the registry HKLM:SOFTWARE\FSLogix\Profiles\CleanOutNotifications and set the value to 0 you could avoid this issue too but your way is probably better solution to this problem

    • Thanks for that insight Jiří,

      The FSLogix team has read my article and are working on the issues, so probably things will change in newer versions.
      The fact is that they need to be cleaned out, so it’s best to just help that process along IMHO.

  • Legend – had this issue today after migrating UPD to FSlogix and I was stumped why it was taking 5 minutes to log in. One oditty is it has broken the start menu for local users – but fslogix users still have a working start menu, considering there is no local users beyond administrators we can work around that! login is about 5 seconds now. thanks!

    • Thanks Matt!

      I might not have emphasized it clearly enough. but you have to recreate the Notifications Key in the registry again, after deleting it. then you MUST reboot.

    • I had this. I deleted my admin profile and logged in again and it was fine.

Sponsors