Forum Discussion
Users are getting license warning and are disconnected after 60 minutes from WVD
Hello,
we have a situation that two minutes after logging into a WVD session (Win 10 1903 multi-user), users are getting a warning about an invalid license and they will be logged off after 60 minutes. After 60 minutes the session is disconnected.
After logon there are two error events in the TerminalServices-RemoteConnectionManager/Admin Event Log.
Event ID 50215 : The Remote Desktop Session Host Server was unable to retrieve user license information from AAD. Error: CheckLicensingFromAAD - Read AccessToken Failed: hr=0x80070057
Event ID 50215: The Remote Desktop Session Host Server was unable to retrieve user license information from AAD. User [ADDSDOMAIN\UserName]. hr=0x80070057
The event log entries started in October already. I assume users are now getting the message after a 30 day grace period. The entire deployment is operational without any problems since July.
All users are licensed with M365 E3. The AD DS and AAD are synchronized via AD Connect with Azure Hybrid Join enable. The problem affects all servers in two pools. All servers are registered in AAD and users are able to use SSO when logged in and using Office 365 applications.
I hope anyone can help us with this problem.
Thank you
Sascha Stops
Sascha Stops This is a known issue and we are updating our documentation while working on a fix. The fix will take a couple of weeks, probably looking at early 2020. I'd recommend to redeploy the 1903 (or 1909) hosts where the grace period will be long enough to bridge the gap until the fix is pushed via Windows Update. Sorry for the inconvenience.
24 Replies
- Bump, we just started experiencing this as well.
rmaestas the fix to correct this is expected end of this month. Sorry for the inconvenience.
- We're experiencing this problem too as of today.
Will the fix also solve the problem on current deployments, or only for future deployments?
Sascha Stops Any luck? Supposedly you can reset the timer by deleting a GracePeriod registry key (under 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod').
That might hold us over until a fix is released: https://www.hyper-v.io/reset-120-day-rds-grace-period-windows-server-2016-without-gui/
For those debugging this, we found that we have only 15 days remaining before we hit this bug. You can see remaining time by running, in an elevated powershell:
(Invoke-WmiMethod -PATH (gwmi -namespace root\cimv2\terminalservices -class win32_terminalservicesetting).__PATH -name GetGracePeriodDays).daysleft
Nicholas Semenkovich I've tried that command to find the grace days, it says 469... 🙂 We are getting the license errors and MS Support confirmes we are indeed effected by this bug, but the errors are only in the event logs and users are not effected. Just a little curious about the 469 grace days...
Nicholas Semenkovich That seems to work. At least it will give us some time to rebuild the servers with all legacy applications.
Best regards
Sascha
Sascha Stops Thanks for letting me know! We'll probably do the same until the fix rolls out.
Nicholas Semenkovich Hello, I have been told by the support engineer that there might be long term problems doing this. But I guess it does not matter if we rebuild now or later.
I might give that a try one of the two host groups.
Thank you for your response.
Best regards
Sascha
Sascha Stops This is a known issue and we are updating our documentation while working on a fix. The fix will take a couple of weeks, probably looking at early 2020. I'd recommend to redeploy the 1903 (or 1909) hosts where the grace period will be long enough to bridge the gap until the fix is pushed via Windows Update. Sorry for the inconvenience.
Thank you for the reply. I got the similar response today from the support case I opened. The support engineer mentioned that in 1909 the problem would be fixed but only for new deployments, not for upgrades.
We just saw this in our logs as well; it's likely to hit us hard in a week or two -- and it's very difficult for us to redeploy hosts (due to some painful legacy apps).
Any more info available / alternative workarounds?
