Feb 17 2020 08:34 AM
Feb 17 2020 08:34 AM
I've got an RDS farm running in Azure. The farm has 2 AD's, 2 CB's and 2 gateways - with 20+ session hosts setup. All the VM's are Server 2019.
We built the farm last summer and have had smooth sailing for the most part. However an issue has now appeared and I'm at a loss as to why, and how to repair it.
We added a new VM and session host last week, and clients logging into the gateway for the RDP link are getting an RDP file that is a fraction of the size it should be.
Normally our RDP files are a little shy of 10KB, now they're about 0.5KB - and they're missing almost all of the arguments that should be otherwise present.
This is affecting all pre-existing hosts, not just the new entry.
Our CB's have a pair of Azure SQL DB's to talk to, both of which appear to be healthy within Azure and replicating between our primary and failover region just fine.
Interestingly, a browse of the registry on CB1 into:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\"session_host_name"\DeploymentSettings
shows all the details I'd expect to see, however browsing that same registry on CB2 and the keys for CertificateHash, CustomRDPSettings, DeploymentRDPSettings & fHasCertificate are all outright missing for the latest host (though they are present for the preceeding hosts).
Thankfully users who have already downloaded the RDP file prior to today are unaffected, so that gives me a bit of grace to investigate and resolve the fault - but currently I'm at a bit of a loss.
Any suggestions would be warmly received.
Feb 17 2020 12:34 PM
Quick addendum. After some brain boosting cheesecake, and playing to a hunch, I shut down CB2. Everything now appears to be working properly. RDP files getting populated with all the right data and such.
So now the question is why the discrepancy between the two CB's, and diagnosing the nature of the fault and how to repair it.
I'm still open to suggestions. Though I'm increasingly leaning towards nuking the services of CB2 and re-doing it.
Feb 18 2020 02:01 AM
Time to pile on the oddities. Having left CB2 offline overnight, I've fired it up this morning to take another crack at the issue.
Now it appears to have synchronised properly with the SQL DB, the registry locations as referenced in my original post are now populated.
Reviewing the event logs in \Applications and Services Logs\Microsoft\Windows\Remote-Desktop-Management-Service\Operational\ I'm now seeing 'Config Sync Succeeded' event ID 263. Rather than the Config sync failed with error: 0x80070057 that I'd been seeing in the \Admin\ folder.
Interestingly, that config error did lead me to an article here: https://social.technet.microsoft.com/Forums/ie/en-US/320a7167-899e-4700-a254-15716c6952c6/remote-des... regarding the license model in use (by device // by user) and ours is actually not set. I looked at setting it, but the system threw a strop. Checking our license manager though, and it is applying them by user (our operating model) not sure if that's default, or if the UI simply isn't reflective of the settings in place underneath. That's a separate topic for investigation though.
As it stands, we appear to be fully operational on both CB's. Will need to dig through the SQL hosts logs, see if I can track down why it wasn't synchronising. Will update again as/when I find time for that particular expedition.
Feb 21 2020 07:42 AM
Another update as of 21/02 - both our CB's stopped sync'ing properly to the SQL DB's around the 18th at 21:39 - having generated many many sync fails over the 17th and 18th.
After 21:39 on the 18th, there are zero \Admin\ or \Operational\ entries in the event logs.
MS are now taking a deeper look. Will update as and when I know more.