![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(211.20000000000002, 0%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESS%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(89.60000000000001, 96%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETV%3C/text%3E%3C/svg%3E)
Hi Saeng,
YÝe, this matches a known RDS failure mode when the deployment is using the built-in Windows Internal Database and TLS 1.0 gets disabled. Microsoft says that in this setup, an existing RDS deployment can fail, RDMS will not start, and the Connection Broker/RDS components can become unusable.
The stable fixes are the same ones Microsoft documents: re-enable TLS 1.0 on that single-broker/WID deployment, or move the Connection Broker to a high-availability setup that uses a dedicated SQL Server instead of WID. Microsoft also notes that upgrading the RDS hosts to Windows Server 2019 avoids this particular dependency.
The monthly “works again after rebuild, then breaks later” pattern makes me suspect something is re-applying a hardening baseline or GPO that disables TLS 1.0 again after the rebuild. That is an inference, but it fits the documented symptom pattern very well.