Start a discussion

Thank you.  I still can't make this work on renewal, but I have some more information.

After an automatic certificate renewal, the following script was launched by the Certify application:

# Update RRAS and RD Certificate.ps1
Param($result)

# Use the RDS PowerShell module, if available.
# If not, we'll have to set it manually via WMI.
Import-Module RemoteDesktopServices -ErrorAction SilentlyContinue
$RDSPath = "RDS:\GatewayServer\SSLCertificate\Thumbprint"
If (Test-Path $RDSPath) {
    Set-Item -Path $RDSPath -Value  $result.ManagedItem.CertificateThumbprintHash -ErrorAction Continue
} Else {
    # Convert the certificate thumbprint from a String into a Byte[] that WMI can understand.
    # The next line is courtesy of: http://www.beefycode.com/post/Convert-FromHex-PowerShell-Filter.aspx
    $ByteArray = ($result.ManagedItem.CertificateThumbprintHash -Split "(?<=\G\w{2})(?=\w{2})" | ForEach {[Convert]::ToByte($_,16)})
    $wmi = (Get-WmiObject -Class "Win32_TSGatewayServerSettings" -Namespace "root\cimv2\terminalservices")
    $wmi.SetCertificate($ByteArray)
}
# Uncomment the next cmdlet to automatically restart the RD Gateway service.
# This is required to apply the new certificate, but it will briefly disconnect all users.
Restart-Service TSGateway -ErrorAction Continue

# Update certificate after renewal for SSTP VPN

#Param($result) #Commented because this is already done above.

# Store certificate in variable
$certificate = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -match $result.ManagedItem.CertificateThumbprintHash}

# Update RRAS with new certificate
Import-Module RemoteAccess
Stop-Service RemoteAccess
Set-RemoteAccess -SslCertificate $certificate
Start-Service RemoteAccess

But, at this point, VPN connections stopped working properly.  They can connect, but no traffic is passed.  The Remote Desktop Gateway is still allowing connections to other machines.  

Rebooted the server at this point.  After the system was back up, the Dashboard showed a critical notification: "Remote Desktop Services is not configured correctly."  Using the context menu and selecting "Try to repair" makes the notification disappear, but the problem is not resolved.

Rebooting after that, I found that the Routing and Remote Access service was not running once the server was back up.  Attempts to start the service manually resulted in the service starting and stopping immediately.

At this point, the Dashboard showed no errors, but with no RRAS, attempts to connect to the VPN failed, timing out on connect.

I then went to the Dashboard, went to "Anywhere Access" in the settings menu and clicked "Repair".  After a few minutes, this resulted in a message that the repair was successful..  At this point, VPN connections once again were routing traffic normally.  No reboot was required.

Did I mess up merging the  scripts?  Is there something else I may be missing?  The event log shows an error complaining that "The thumbprint (cert hash) of the certificate used for Secure Socket Tunnelling Protocol (SSTP) is different than the certificate bound to the Web listener (HTTP.sys)." before the repair is run from the Dashboard settings.  It seems like I must have done something weird with the script, but I'm not sure what.

As always, thank you for all of your help.  One other thing...  How did you make your code block so pretty in your reply?

Yes, I was called yesterday with the same issue. I am baffled why this does not work and a reboot does.

I'm having the same issue with having to reboot the server to get the VPN working. Unfortunately, I haven't come across a solution to that yet.

However, in relation to the 'Remote Desktop Services is not configured properly', this is a falsely reported error and is actually down to the binding order in IIS - it took me AGES to discover that.

To work around the problem, I use the following in my script:

#Remove and re-add local binding to overcome false error with RDP
#This issue is down to the ordering of the bindings - this puts it back at the end of the list
$computername = $env:computername
Get-WebBinding -Name "Default Web Site" -HostHeader $computername | Remove-WebBinding
New-WebBinding -Name "Default Web Site" -IPAddress "*" -Port 443 -Protocol HTTPS -HostHeader $computername -SslFlags 1
 

That will stop the issue with that error message, but I still haven't managed to get past this issue of having to reboot to get the VPN working again.

Just thought I'd add my full script if it's of any use to anyone:

param($result)

Import-Module RemoteDesktopServices
Import-Module RemoteAccess

$NewCertThumbprint = $result.ManagedItem.CertificateThumbprintHash

# Apply certificate to RDS Gateway Server
Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value  $NewCertThumbprint -ErrorAction Stop
Restart-Service TSGateway -Force -ErrorAction Stop

#Apply certificate to Remote Access
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -match $NewCertThumbprint}
Stop-Service RemoteAccess
Set-RemoteAccess -SslCertificate $cert
Start-Service RemoteAccess

#Remove and re-add local binding to overcome false error with RDP
#This issue is down to the ordering of the bindings - this puts it back at the end of the list
$computername = $env:computername
Get-WebBinding -Name "Default Web Site" -HostHeader $computername | Remove-WebBinding
New-WebBinding -Name "Default Web Site" -IPAddress "*" -Port 443 -Protocol HTTPS -HostHeader $computername -SslFlags 1
 

By chance has another solution been found yet other than reboot of server?  Thanks.

I still need to pay attention to this and reboot the server every time the Certify app updates the cert.  If I don't, the VPN stops passing traffic.  This is becoming more of an issue with a greater number of people needing to work from home.  I'm considering dropping the Anywhere Access VPN and setting up the VPN on the pfSense firewall.  I like the idea of a transparent process - log in to your computer and it's like you're in the office - but it's beginning to be a support problem.  They can click one more icon if it makes this more stable.

I'm tempted to set up a different clean server and see if it has the same issues.

Whilst I haven't implemented this myself, just yet. I'm planning the following to overcome the VPN reboot issue.

Set the CertifyTheWeb service to manual.
Add a reboot command to the script
Set up a scheduled task to start the CertifyTheWeb service when a renewal is due and at a date/time that I'm happy for a reboot to occur - eg every 9 weeks on Sunday at 1am.

The theory is that if the CertifyTheWeb service is not running, no renewal will take place.
When the task runs 9 weeks later and starts the service (during a maintenance interval), it will renew, run the script and reboot - all should then be working.
After reboot, the CertifyTheWeb will still be set to Manual and therefore not running.
Renewal won't happen again for another 9 weeks.

The only slight issue would be if somebody starts the CertifyTheWeb service (or it somehow switches back to Automatic), and then you might get an unexpected reboot possibly during working hours.

Like I say, I haven't implemented this yet, but that's my plan!

I also thought about a solution that includes a server restart but I find that a bit too much to be honest. Last quarter of this year I will rewrite the Lets Encrypt tutorial and hopefully find another solution then. Just a thought...restarting the network stack could also do the trick

Hi Mariette.

I've got a live server that's currently exhibiting the problem. Fortunately, the users don't need the VPN, so it's perfectly fine to leave it in that state. 

I've currently tried
restart-netadapter -Name "Ethernet"

No joy with that.
I've also tried net stop sstpsvc (which also stops RRAS) followed by net start RemoteAccess (which brings back up the SSTPSvc)

Still the same issue - client connects OK, but no traffic flows over the VPN.

if you've got anything else you'd like me to try, I can feedback the results to you.

Try this:

Restart-Service IAS -Force

Network Policy Server and Remote Desktop Gateway Service both restarted, but still no joy.

This became an issue for one of my clients again today, so I finally put together a full script to handle this.
With the latest version of CertifyTheWeb, it's possible to have the certificate renew automatically, but have the script run on a schedule.

I've made two changes to CertifyTheWeb:

1) On the Deployment section, I've set the Deployment Mode to 'Certificate Store Only'
This places the new certificate in the Certificate Store, but does nothing else with it

2) On the Tasks section, I have a Post-Request script which is set to manual.
When the script is set to manual, you are given a command line to run which looks something like this:

certify deploy "dda81398-5b46-4112-a3ba-76edd8219870:1" "17a199e4-0fdd-43fd-a447-1cf3e07f4f01"

(This is an example command line, when you set your script to manual, you will be given your own).
Using task scheduler, I set this to run on a Sunday at 5am every two weeks.

My script within CertifyTheWeb now looks like this:

param($result)

Import-Module RemoteDesktopServices
Import-Module RemoteAccess

$NewCertThumbprint = $result.ManagedItem.CertificateThumbprintHash

#Get currently assigned RDS Certificate
$CurrentCertThumbprint = (get-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint).CurrentValue

if ($CurrentCertThumbprint -eq $NewCertThumbprint) {
	echo "Latest certificate already installed, nothing to do..."
}
else {
	echo "New certificate available. Installing..."

	$computername = $env:computername

	#Remove the previous certificate
	echo "Removing old and adding new certificate..."
	& netsh http delete sslcert ipport=0.0.0.0:443
	& netsh http delete sslcert ipport=[::]:443
	& netsh http delete sslcert hostnameport=${computername}:443
	#Add the latest certificate
	$guid = [guid]::NewGuid()
	& netsh http add sslcert ipport=0.0.0.0:443 certhash=$NewCertThumbprint appid=`{$guid`} certstorename=My
	& netsh http add sslcert hostnameport=${computername}:443 certhash=$NewCertThumbprint appid=`{$guid`} certstorename=My
	$guid = [guid]::NewGuid()
	& netsh http add sslcert ipport=[::]:443 certhash=$NewCertThumbprint appid=`{$guid`} certstorename=My

	# Apply certificate to RDS Gateway Server
	echo "Applying certificate to RDS Gateway Server..."
	Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value  $NewCertThumbprint -ErrorAction Stop
	Restart-Service TSGateway -Force -ErrorAction Stop

	#Apply certificate to Remote Access
	echo "Applying certificate to Remote Access SSTP..."
	$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -match $NewCertThumbprint}
	Stop-Service RemoteAccess
	Set-RemoteAccess -SslCertificate $cert
	Start-Service RemoteAccess

	echo "Rebooting server so that VPN functions normally"
	Restart-Computer -Force
}

Brief overview of the script:

It checks the Thumbprint of the certificate currently assigned to RDS (I found this the easiest one to get hold of !!), and if it matches the Thumbprint of the most recent CertifyTheWeb certificate, then the latest certificate is already configured and nothing happens.

However, if they're different, it removes the current certificate bindings, and then recreates bindings with the new certificate (the configuration in the script is for a 2016 Essentials setup). It then assigns the new certificate to RDS and Remote Access, and finally reboots the server.

I now have everything fully automated (with server reboot), and it only happens at 5am on a Sunday which works great for me.

Incidentally, during testing today, I discovered that it might not be an SSTP issue with RRAS. I attempted to switch over to PPTP instead, and still had the same issue where no traffic was being passed. It seems that it's just a simple case of stopping and starting the service causes RRAS to break. Unfortunately, we need to restart the service for the SSTP certificate to take effect.

It would be nice to not have to reboot the server, but this is a good enough workaround for me, and will hopefully be useful for others.

Chad, in the above solution where is DHCP hosted? Is it on the Essentials server or is it on a router?

In both cases that I'm using this for clients, DHCP is provided by the server, however, I don't think this would make much difference to the running of the script.

I've just checked something, and can now confirm that the VPN issue has nothing to do with the certificate changeover. Quite simply, just stopping and starting the RRAS service causes the VPN to stop routing traffic across the connection.
I have no idea why - the RAS client receives exactly the same networking configuration from the DHCP server, it just won't pass any traffic until the server has been rebooted.

So, like I say, it seems to have nothing to do with the cert changeover, it just happens that as part of that process, we reboot RRAS which then causes the problem.
I've seen this issue on at least three 2016 Essentials servers, and even on an SBS 2011 machine - I never linked it to an RRAS problem, though; it was either thought to be a one-off glitch, or linked to the cert change.

I'll look into researching this issue separately and report back if I find anything. It's rare that RRAS needs a restart, but as far as I'm aware, we need to do it for this cert changeover.

I'll let you know if I find anything out.

Happy New Year :)

Mind numbing headache accomplished.