Forum Discussion
Users are getting license warning and are disconnected after 60 minutes from WVD
- Nov 25, 2019
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.
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.
- knowliteDec 09, 2019Iron ContributorHaving 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- PieterWiglevenDec 16, 2019Former Employee
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.
- PieterWiglevenDec 17, 2019Former Employee
@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
- Sascha StopsDec 10, 2019Brass Contributor
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
- knowliteDec 10, 2019Iron Contributor120 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.