Windows 10 – Microsoft Teams and Skype for Business Lagging UI – Fixed


For far too long I’ve felt like a frog slowly being boiled by my, admittedly, aging laptop and Windows 10. In particular, I’ve found certain programs, like Microsoft Teams and Skype for Business, caused my computer to either experience long UI freezes or long load times. And I claim without proof, that the delays were getting longer yet more frequent. S4B would take minutes and minutes to load, but once loaded, ran ok, while Teams would load quickly but the UI would freeze all of the time. The Teams app became unusable.

I chalked up my issues to an aging system—my Surface Pro did not have similar issues. Teams in a browser ran fine, but the final nail in the coffin was when I discovered that OneDrive for Business was locking synced files and I started losing work. This was unacceptable; there must be a fix to my problems.

Microsoft Teams and a Freezing UI

I can deal with long load times, but I cannot deal with continued UI freezes. Further, my company went all in with Microsoft Teams. I needed the Teams app to work, so I focused on that issue.

It did not take long for me to find that a lagging Teams app was not uncommon. There was, and still is, an active User Voice discussion on this issue.

Long story short, a major improvement was made to the Teams App near the end of 2017 that brought system load way down. This did solve Teams app issues for many in my office, but not for me. If you too are in a similar boat, Teams, S4B, or possibly OneDrive causes extremely long system delays and commonly proposed solutions have not worked for you, I might have another answer for you.

I started to think all of my problems must be related, but how?

Reach out to the community when you get stuck

The Office 365, SharePoint, and Azure community never ceases to amaze me. I posted my issues to a few peers I know in the O365 and Teams community and my bud, Thorbjørn Værp, a fellow Microsoft MVP and Microsoft Teams wizard offered to take a peek. It did not take him long to find my issue.

Orphaned Domains and their repercussions

Thorbjørn quickly helped me determine that my issues must certainly be related and he noticed that the delays are likely timeout related. My laptop was making a request to communicate with “something” and was waiting. The rest of my system, in general, worked well, solid internet, DNS working, no odd VPN’s. It must be domain related.

Sure enough, my laptop used to be a part of local domain. However, while I had moved all of my accounts to AAD, I left my primary laptop login with my no-longer-active AD account. Don’t get me started on the idiocracy of that move. Long story short, I did not want to have to recreate my local profile.

How did we determine this?

  1. Open a command prompt and run “Set”
  2. Check out your “USERDOMAIN” and if the listed domain is not active, you are likely having the same issue I had.

The fix is in

The fix to my problem was both simple and complex. Simple because all I needed to do was remove my laptop from the domain. Complex because you cannot migrate your local profiles, I will need to create a new profile and re-sync all of my settings and more importantly my data (OneDrive, OD4B, Dropbox, etc).

First, I removed my workstation from the inactive domain:

I used the base answer here to join a local workgroup for now.

Note: I did ensure my local Administrative account was active and that I knew the password. This way I could log back into my workstation once my domain account was deactivated.

Second, since PixelMill is an AAD / O365 shop, I wanted to join my workstation to our AAD.

That was easy:

Finally, I was able to log back into my workstation using my AAD account. Ok, not “finally” as now I had to re-setup my profile, syncing, and more but I can tell you, this solved my issue with Microsoft Teams, S4B, OneDrive syncing/locking, and general system performance.

In the following command prompt screen capture, I ran the command “set”. You can see the “USERDOMAIN” is now AzureAD. Before this value was the name of a local, defunct AD Domain.


Ok, back in the pool.


  1. Glad I could help 🙂
    More tip on same matter: there is a MS Teams log file located here : %AppData%\Microsoft\Teams\logs.txt
    Take a look at it if you experience similar problems.

    Best regards

Speak Your Mind