11-13-2019 05:47 PM - edited 11-13-2019 05:49 PM
11-13-2019 05:47 PM - edited 11-13-2019 05:49 PM
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.
11-25-2019 11:25 AMSolution
@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.
11-26-2019 10:52 AM
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?
11-26-2019 12:32 PM
@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
11-26-2019 02:09 PM
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.
11-26-2019 02:10 PM
@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.
11-28-2019 04:55 AM
@Nicholas Semenkovich That seems to work. At least it will give us some time to rebuild the servers with all legacy applications.
11-28-2019 11:28 AM
@Sascha Stops Thanks for letting me know! We'll probably do the same until the fix rolls out.
12-09-2019 04:59 AM
12-10-2019 05:21 AM
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.
12-10-2019 05:26 AM
12-16-2019 02:26 PM - edited 12-16-2019 02:28 PM
@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.
12-17-2019 04:25 PM
01-03-2020 01:10 PM
@rmaestas the fix to correct this is expected end of this month. Sorry for the inconvenience.
01-08-2020 04:38 AM
01-08-2020 03:21 PM
@tomdw It will fix existing deployments - thanks.
01-10-2020 12:48 AM
@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...
01-14-2020 10:24 AM
Can anyone confirm the fix for this is in KB4528760?
01-14-2020 11:27 AM
@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.
01-14-2020 11:44 AM
@Mtollex70 you are right. It's not part of KB4528760 but instead will be part of the next cumulative update.
01-30-2020 09:50 AM
@Pieter Wigleven (WINDOWS) Hi Pieter, any new on the fix for this issue? I have the same for one of my clients.
01-30-2020 04:20 PM
@tomv_ips This should be part of the next cumulative update, which is scheduled for Feb 11.
02-13-2020 02:35 PM
@Pieter Wigleven (WINDOWS) So is it confirmed that the update from tuesday fixes this issue?
02-13-2020 03:20 PM
@Mtollex70 Looks like it. Not tested extemsively but certainly not appeared in my session at the moment.