Users are getting license warning and are disconnected after 60 minutes from WVD

[Sascha Stops]

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

[#2 · Accepted solution]

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

[#3]

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?

[#4]

@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

[#5]

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.

[#6]

@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

[#7]

@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

[#8]

@Sascha Stops Thanks for letting me know! We'll probably do the same until the fix rolls out.

[#9]

Having the same issue on deployment made this weekend.
Users getting notification that they will be logged out in 2 minutes.
Following eventlog: (sorry for dutch)
Er kunnen geen licentiegegevens voor gebruikers door de Extern bureaublad-sessiehostserver uit AAD worden opgehaald. Fout User DOMAIN\user , hr = 0x80070057

Er kunnen geen licentiegegevens voor gebruikers door de Extern bureaublad-sessiehostserver uit AAD worden opgehaald. Fout CheckLicensingFromAAD - Read AccessToken Failed: hr = 0x80070057

[#10]

@knowlite Hello,

according to Microsoft this is known bug in 1903 and 1909. It will possibly fixed in January 2020.

The official guidance is to redeploy all servers so that you get a grace period (120 days) that ends later than the patch release date.

The method of resetting the grace period in the registry of an already working system mentioned previously in this thread is not support by Microsoft and might have long-term effects.

Probably not the response you were hoping for, but this is the information we received through this channel and Premier Support.

Best regards

Sascha

[#11]

120 days should suffice until a fix is there. We deployed the servers this weekend 😉
Though the issue is resolved now and was not related to this problem but due to the registry tweaks that were previously mentioned on MS Docs about the Active Session limit (set to 3 hours?!). I've changed the parameters and sessions are now disconnecting without loosing their data and can stay active for 16 hours without issues. I hope we do not bump into this topics grace period ending before there is a fix from MS.

[#12]

@knowlite This will be part of the (end of) januari fix. It's caused by the VM not being able to reach out to AAD (firewall?), the fix will remove the check and need to contact AAD at all. Let me see what URL's/IP's etc. are needed so you could white-list in the interim.

[#13]

@knowlite We've looked at the code path and it looks like https://graph.windows.net (TCP/443) is being queried. Would you be able to test if this URL is accessible from your RDSH hosts? A simple test is pasting the URL in your browser and see if there's a response. 

Thanks,
Pieter

[#14]

Bump, we just started experiencing this as well.

[#15]

@rmaestas the fix to correct this is expected end of this month. Sorry for the inconvenience. 

[#16]

We're experiencing this problem too as of today.
Will the fix also solve the problem on current deployments, or only for future deployments?

[#17]

@tomdw It will fix existing deployments - thanks.

[#18]

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

[#19]

Can anyone confirm the fix for this is in KB4528760?

[#20]

@Nicholas Semenkovich I have an open ticket with MS Support, and they told me yesterday that the fix is scheduled to late january, so i think its NOT in the fix you mentioned.