TLS 1.2 on plain WSE 2016
Many thanks for this article:
Enabling TLS 1.2 On Windows Server Essentials
I found it after using another approach for locking down my 2016 Essentials server (without the RemoteApp enhancement), only to discover that my client backups were no longer running.
I used Nartec IIS Crypto 3.2 to lock down the server until I was getting an “A” rating from SSL Labs. This included disabling TLS 1.0 and 1.1.
After that, RWW and RDP Gateway work fine, but on a client computer, in “C:\ProgramData\Microsoft\Windows Server\Logs\RunTask-Client Computer Backup.log”, backups failed with this message:
Backup: Exception calling the provider: System.TimeoutException: This request operation sent to net.tcp://localhost:65532/Microsoft.WindowsServerSolutions.wssg_pc_backup_client
/Microsoft.WindowsServerSolutions.DataProtection.PCBackup.BackupUtil.
WcfContracts.IPCBackupClientProvider did not receive a reply within the configured timeout (00:01:00).
After importing DotNetFrameworkTlsSettings.reg on the client, a manual backup succeeded immediately. No client reboot was required.
Assuming the automatic backups also succeed, is there anything else I need to check?
- mcbsys asked 3 years ago
- last edited 2 years ago
- You must log in to post comments.
Glad to hear that you got it working.
I’m not familiar with the tool that you’ve used on your server and so I can’t speak as to what it does (or does not do) I’m afraid. You might simply want to compare everything that it does against what’s going on in the Hass Alexander script that I suggest folks use.
That being said… I do know that if you disable TLS 1.0 on your Essentials server, then you MUST enable the SchUseStrongCrypto and SystemDefaultTlsVersions .NET Framework settings on ALL of your (domain joined and/or SkipDomainJoin) connected client computers in order for their Essentials components to be able to continue to communicate properly with the Essentials server (over TLS 1.2/1.1 instead of TLS 1.0). I also believe that a reboot of both the server and the client computers is required in order for the settings to fully take affect. Other than that, I’m not aware of anything else that’s required.
- Mike answered 3 years ago
- last edited 3 years ago
- You must log in to post comments.
I used this program to convert the .reg file to a PowerShell script:
Registry to PowerShell converter
This allows simple deployment to multiple machines with an RMM tool.
I’ve tested now on two Windows 10 machines. Once the registry is updated, backups succeed without a client reboot, whether initiated client-side or server-side. This makes sense–the client only establishes a connection when required, and uses the current registry values when it does. Servers on the other hand have persistent services listening with the specified parameters; a server reboot is the simplest way to re-initialize those services. Of course a client reboot doesn’t hurt, but backups seem to work even without one.
- mcbsys answered 3 years ago
- last edited 3 years ago
- You must log in to post comments.
Coincidentally, I just learned that the same registry fix must be applied to the server to allow it to connect as a client to the dynamic DNS services. See this thread:
It seems TLS hardening is going around…
- mcbsys answered 3 years ago
- You must log in to post comments.
Thanks for the heads up on the Registry to PowerShell converter tool. Pretty cool.
In my experience, the client reboot was always required in the long run (maybe not for client backup to succeed, but for other server to client communications to succeed). Good to know though. Thanks.
Yes, the .NET Framework secure cryptography registry settings are indeed required on BOTH the server and the clients in order for things to work properly (i.e. in order for TLS 1.2 hardening to be successfully implemented across all required server to client communications in Essentials). This is pointed out in my original article, that you linked folks to, and is implemented on the server side as part of the Hass Alexander script.
- Mike answered 3 years ago
- last edited 3 years ago
- You must log in to post comments.
