-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows Server Essentials 2016 Access Anywhere Certificate renewal script #519
Comments
Thanks is there a complaint somewhere we should be addressing? We also have a built in Deployment Task for this but it currently only does this, are the other service restarts essential?:
|
As an aside you can also now use our built in Deployment Task to stop/start/restart services, so scripting isn't the only way to do it. |
Hello Christopher,
On Windows Server 2016 Essentials, if you don’t restart Network Policy Server, VPNs do connect but here is no traffic allowed on the network.
For people using the SSTP protocol, you must restart the SSTVSvc service AFTER restarting the TSGateway.
Note that there is a significant delay during these restarts: on a lightly loaded server, expect a two minutes delay.
Regards,
Serge Caron
|
Hello Christopher,
I am not certain how to control the exact restart sequence using separate tasks.
Regards,
Serge Caron
|
Thanks Serge. Regarding Tasks, they are executed in the order that they appear on the list and you can drag/drop them to re-order. |
Hello Christopher,
Yesterday was too hectic to reply.
The task “Deploy to RAS (Direct Access, …” does not document which services are restarted and in what order.
Over the years, I have not seen a recommendation to restart IAS, the now “Network Policy Server”, in he various forums concerned with Windows Server 2016 Essentials.
The same goes for SSTPSvc.
So, does your “Deploy to RAS …” task restart these services, in which order, and does it do anything else ?
Kind regards,
Serge Caron
|
Hi Serge, no currently it only runs the following, but I'm happy to update it. Ideally the script would work for everyone and could be combined with other actions for users who need to to do more:
|
Hello Christopher,
This does not work for WS2016 Essentials.
Working backwards so you have a better understanding:
3. SSTPSvc relies on the certificate in use by TSGateway to accept SSTP VPN connections. If this service is not restarted following a TSGateway update, incoming VPN connections will succeed but will dropout almost immediately because of the lack of SSL/TLS support resulting from a certificate mismatch.
2. TSGateway will honor incoming connections but the remote end will not pass traffic: you can’t even ping the WS2016 server even if you have a valid IP provided by the TSGateway/SSTPSvc pair.
1. Internet Authentication Service (IAS) was renamed Network Policy Server (NPS) with the introduction of Windows Server 2008. This is the service responsible for allowing VPN traffic on the local network.
Please note that restarting IAS is a long process and you will find many lines in your log. On a less powerful machine, you are looking at two minutes overall delay.
I am presently testing a replacement server and I will gladly use your new functionality if it does the above. Again, please note that I had added a <Write-Host “Done!” > at the end of my script in the hope that it would be part of the log ;-) Perhaps your version could add this simple safeguard.
Kind regards,
Serge Caron
|
Hello Christopher,
Yesterday, I came across a client configuration where the static script did not work. Our friends at Microsoft are somewhat creative…
Below is a script that will recursively walk the dependencies for the “Network Policy Server” and the “Secure Socket Tunneling Protocol (SSTP) service” : note that these two are not directly or indirectly related, one more of Microsoft’s idiosyncrasies.
Kind regards,
Serge Caron
PS: this is a preliminary version with little or no validation.
param($result)
Import-Module RemoteDesktopServices
# Apply certificate
Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop
# Restart services required for "Access Anywhere"
$global:ServicesToStart = @()
Function CollectDependent($TargetService)
{
$wmidependents = (get-service $TargetService).dependentservices
$wmidependentservices = Get-WmiObject Win32_Service | Select-object name,state,startmode | where {$wmidependents.name -contains $_.name}
# Write-Host $TargetService
foreach ($service in $wmidependentservices){
if($service.startmode -eq "auto" -or $service.status -eq "Running"){
# Write-Host "-> $($service.name)"
# Caution: no effort done to prevent circular definitions
CollectDependent($service.name)
}
else{
Write-Host "Omitting $($service.name) : service is $($service.state) with the startmode: $($service.startmode)"
}
}
stop-service $TargetService -ErrorAction SilentlyContinue
$global:ServicesToStart += $TargetService
}
CollectDependent("IAS")
CollectDependent("SSTPSvc")
#Write-Host "----"
[array]::Reverse($global:ServicesToStart)
foreach($service in $global:ServicesToStart ) { start-service $service -ErrorAction SilentlyContinue }
Write-Host "Done!"
|
Thanks Serge, this is quite extensive, I think I'd be tempted to leave the exercise of stopping and starting related services to the user (i.e they would specify tasks to restart the correct services) as clearly it depends on their environment to some extent. |
Hello Christopher,
Indeed, it is quite extensive.
The issue is that you don’t know for sure which services are running (i.e. some services start-up are set to “Manual” and have dependencies of their own) AND you don’t know the VPN configuration in use. Some dependent services are not in use in every installation.
So the user must research the exact sequence of services they need to stop and start : a simple restart of TSGateway will not do. And this depends on the “configuration du jour” ;-). As you can see in the code, TSGateway is not explicitly named: it is a dependent service of the Network Policy Server.
I am going to add a little protection against circular dependencies and I will live with this for a while.
Kind regards,
Serge Caron
De : Christopher Cook <[email protected]>
Envoyé : 18 août 2020 23:43
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Thanks Serge, this is quite extensive, I think I'd be tempted to leave the exercise of stopping and starting related services to the user (i.e they would specify tasks to restart the correct services) as clearly it depends on their environment to some extent.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4AOXQ6IDZ4FDEIBQBDSBNC5FANCNFSM4PYY2OMQ>.
|
Hello Christopher,
Production script below : enjoy ;-)
Regards,
Serge Caron
PS : I have changed “Write-Host” to “Write-Warning” so these actions can be seen in the Certify The Web log file.
##******************************************************************
## Revision date: 2020.08.19
##
## Copyright (c) 2020 PC-Évolution enr.
## This code is licensed under the GNU General Public License (GPL).
##
## THIS CODE IS PROVIDED *AS IS* WITHOUT WARRANTY OF
## ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING ANY
## IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR
## PURPOSE, MERCHANTABILITY, OR NON-INFRINGEMENT.
##
##******************************************************************
# Certify The Web Deployment Script for Windows Server 2016 Essentials (Your Mileage May Vary ;-)
# Restart the "Network Policy Server" as well as the SSTP protocol : all dependent services are
# stopped and started in the exact reverse order they were stopped.
# Note: the Write-Warning is used so that messages will appear in the Certify The Web log file.
param($result)
Import-Module RemoteDesktopServices
# Apply certificate
Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop
# Restart services required for "Access Anywhere"
$global:ServicesToStart = @()
Function CollectDependent($TargetService)
{
# Caution: minimal effort done to prevent circular definitions
if ($global:ServicesToStart -match "$service.name") {
Write-Warning "Caution! Service $service.name is involved in a circular definition."
}
else {
$wmidependents = (get-service $TargetService).dependentservices
$wmidependentservices = Get-WmiObject Win32_Service | Select-object name,state,startmode | where {$wmidependents.name -contains $_.name}
# Write-Host $TargetService
foreach ($service in $wmidependentservices){
if($service.startmode -eq "auto" -or $service.status -eq "Running"){
# Write-Host "-> $($service.name)"
CollectDependent($service.name)
}
else{
Write-Warning "Omitting $($service.name) : service is $($service.state) with the startmode: $($service.startmode)"
}
}
stop-service $TargetService -ErrorAction SilentlyContinue
$global:ServicesToStart += $TargetService
}
}
CollectDependent("IAS")
CollectDependent("SSTPSvc")
#Write-Host "----"
[array]::Reverse($global:ServicesToStart)
foreach($service in $global:ServicesToStart ) { start-service $service -ErrorAction SilentlyContinue }
Write-Warning "Done!"
De : Serge Caron
Envoyé : 19 août 2020 05:50
À : 'webprofusion/certify' <[email protected]>
Objet : RE: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Hello Christopher,
Indeed, it is quite extensive.
The issue is that you don’t know for sure which services are running (i.e. some services start-up are set to “Manual” and have dependencies of their own) AND you don’t know the VPN configuration in use. Some dependent services are not in use in every installation.
So the user must research the exact sequence of services they need to stop and start : a simple restart of TSGateway will not do. And this depends on the “configuration du jour” ;-). As you can see in the code, TSGateway is not explicitly named: it is a dependent service of the Network Policy Server.
I am going to add a little protection against circular dependencies and I will live with this for a while.
Kind regards,
Serge Caron
De : Christopher Cook <[email protected]<mailto:[email protected]>>
Envoyé : 18 août 2020 23:43
À : webprofusion/certify <[email protected]<mailto:[email protected]>>
Cc : Serge Caron <[email protected]<mailto:[email protected]>>; Author <[email protected]<mailto:[email protected]>>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Thanks Serge, this is quite extensive, I think I'd be tempted to leave the exercise of stopping and starting related services to the user (i.e they would specify tasks to restart the correct services) as clearly it depends on their environment to some extent.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4AOXQ6IDZ4FDEIBQBDSBNC5FANCNFSM4PYY2OMQ>.
|
Just wanted to drop a short note to say a huge thank you for Serge for writing and sharing this script. I've successfully deployed this on my personal WSE 2016 and my Access Anywhere install is now running the current cert (instead of the original one I deployed manually). I'll keep an eye on this thread in case additional improvements to the script are added. |
Hello Christopher at al.,
There are hidden dependencies between the SSTPsvc and IAS services or there is a race condition of some sort between these two on faster servers.
This is a small revision where declared dependencies for these two services are enumerated SSTPSvc first, IAS second.
The renewal log now shows the exact order in which services are restarted. IAS will now start before SSTPSvc, provided there is no other black magic involved.
Regards,
Serge Caron
2020-12-20 12:09:18.836 -05:00 [INF] Executing command via PowerShell
2020-12-20 12:09:29.884 -05:00 [INF] Omitting RasMan : service is Stopped with the startmode: Disabled
Omitting rqs : service is Stopped with the startmode: Manual
Attente de l’arrêt du service « Routage et accès distant (RemoteAccess) »…
Omitting rqs : service is Stopped with the startmode: Manual
Waiting for powershell to complete..5s
Attente de l’arrêt du service « Network Policy Server (IAS) »…
Attente de l’arrêt du service « Network Policy Server (IAS) »…
Restarting services in the following order:
IAS
TSGateway
SSTPSvc
RemoteAccess
Waiting for powershell to complete..10s
Done!
2020-12-20 12:09:29.884 -05:00 [INF] Run Powershell Script :: Task Completed OK
De : devast8tor <[email protected]>
Envoyé : 24 septembre 2020 01:11
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Just wanted to drop a short note to say a huge thank you for Serge for writing and sharing this script. I've successfully deployed this on my personal WSE 2016 and my Access Anywhere install is now running the current cert (instead of the original one I deployed manually). I'll keep an eye on this thread in case additional improvements to the script are added.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4EO7TUADCZMYPLVVHDSHLIG5ANCNFSM4PYY2OMQ>.
|
Serge, Did you post your revised code in this thread or as a commit to the project? Looking to test your updated code as the service dependencies have been causing issues for the Remote Desktop Gateway cert application (it keeps holding on to the prior cert instead of applying the latest renewal). |
Merry Christmas to All ;-)
The revised code was attached to my previous email : I was not intelligent enough to update the GitHub project … shame on me!
The “revision” is simply changing the order in which the dependencies are enumerated: SSTPSvc is enumerated before IAS and the side effect is that IAS is restarted before any of the other services. Microsoft does not enumerate IAS as a dependency for SSTPSvc, so the point at which it picks up the new certificate is unknown.
As a simple test, here is a scenario where the same certificate is issued at a 15 minutes interval.
* The ACTIVE certificate (as displayed in a web browser) is valid from “20 décembre 2020 11:09:15 to 20 mars 2021 11:09:15”;
* The first invocation of the renewal process shows
In the Certify The Web log file : “2020-12-20 11:55:47.942 -05:00 [INF] Task [Run Powershell Script] :: Task is enabled and primary request was successful.”
In the MMC Certificate console, the “friendly name” of the certificate is “passerelle.[secretdomain].com [Certify] - 2020-12-20 10:55:44 to 2021-03-20 11:55:44”
* The second invocation of the renewal process shows
In the Certify The Web log file : “2020-12-20 12:09:18.836 -05:00 [INF] Task [Run Powershell Script] :: Task is enabled and primary request was successful.”
In the MMC Certificate console, the “friendly name” of the second certificate is “passerelle.[secretdomain].com [Certify] - 2020-12-20 11:09:15 to 2021-03-20 12:09:15”
So, there is a small bug in the naming of the “friendly name” of the certificate, the “to” part is one hour later probably as the result of some daily savings time discrepancy.
However, the SSTPSvc service picks up the new certificate on all the servers on which this was tested. On December 30th, I still have 5 different installations to update to CTW 5.2.1 and I will report if all is fine with those as well.
Christopher may have fix the naming bug by then ;-)
Kind regards,
Serge Caron
De : devast8tor <[email protected]>
Envoyé : 24 décembre 2020 01:04
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Serge,
Did you post your revised code in this thread or as a commit to the project? Looking to test your updated code as the service dependencies have been causing issues for the Remote Desktop Gateway cert application (it keeps holding on to the prior cert instead of applying the latest renewal).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4GHAKNCK5FM4OT77JLSWLKULANCNFSM4PYY2OMQ>.
|
Merry Christmas to you too! I must be missing something here, because your
email attachment didn't seem to make it into the comment thread. Perhaps
Chris is able to see it as the project administrator though...
Can you repost the updated code via an in line script block?
- Ryan
…On Thu, Dec 24, 2020, 8:41 AM SergeCaron ***@***.***> wrote:
Merry Christmas to All ;-)
The revised code was attached to my previous email : I was not intelligent
enough to update the GitHub project … shame on me!
The “revision” is simply changing the order in which the dependencies are
enumerated: SSTPSvc is enumerated before IAS and the side effect is that
IAS is restarted before any of the other services. Microsoft does not
enumerate IAS as a dependency for SSTPSvc, so the point at which it picks
up the new certificate is unknown.
As a simple test, here is a scenario where the same certificate is issued
at a 15 minutes interval.
* The ACTIVE certificate (as displayed in a web browser) is valid from
“20 décembre 2020 11:09:15 to 20 mars 2021 11:09:15”;
* The first invocation of the renewal process shows
In the Certify The Web log file : “2020-12-20 11:55:47.942 -05:00 [INF]
Task [Run Powershell Script] :: Task is enabled and primary request was
successful.”
In the MMC Certificate console, the “friendly name” of the certificate is
“passerelle.[secretdomain].com [Certify] - 2020-12-20 10:55:44 to
2021-03-20 11:55:44”
* The second invocation of the renewal process shows
In the Certify The Web log file : “2020-12-20 12:09:18.836 -05:00 [INF]
Task [Run Powershell Script] :: Task is enabled and primary request was
successful.”
In the MMC Certificate console, the “friendly name” of the second
certificate is “passerelle.[secretdomain].com [Certify] - 2020-12-20
11:09:15 to 2021-03-20 12:09:15”
So, there is a small bug in the naming of the “friendly name” of the
certificate, the “to” part is one hour later probably as the result of some
daily savings time discrepancy.
However, the SSTPSvc service picks up the new certificate on all the
servers on which this was tested. On December 30th, I still have 5
different installations to update to CTW 5.2.1 and I will report if all is
fine with those as well.
Christopher may have fix the naming bug by then ;-)
Kind regards,
Serge Caron
De : devast8tor ***@***.***>
Envoyé : 24 décembre 2020 01:04
À : webprofusion/certify ***@***.***>
Cc : Serge Caron ***@***.***>; Author <
***@***.***>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Serge,
Did you post your revised code in this thread or as a commit to the
project? Looking to test your updated code as the service dependencies have
been causing issues for the Remote Desktop Gateway cert application (it
keeps holding on to the prior cert instead of applying the latest renewal).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
#519 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AQROU4GHAKNCK5FM4OT77JLSWLKULANCNFSM4PYY2OMQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJWUSHEF6V2F5S4Q7KJQVTSWNVLZANCNFSM4PYY2OMQ>
.
|
Serge, Are you able to post your most updated script? |
Here is the production script: Revision date: 2020.12.20Copyright (c) 2020 PC-Évolution enr.This code is licensed under the GNU General Public License (GPL).THIS CODE IS PROVIDED AS IS WITHOUT WARRANTY OFANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING ANYIMPLIED WARRANTIES OF FITNESS FOR A PARTICULARPURPOSE, MERCHANTABILITY, OR NON-INFRINGEMENT.##****************************************************************** Certify The Web Deployment Script for Windows Server 2016 Essentials (Your Mileage May Vary ;-)Restart the "Network Policy Server" as well as the SSTP protocol : all dependent services arestopped and started in the exact reverse order they were stopped.Note: the Write-Warning is used so that messages will appear in the Certify The Web log file.2020.08.19 : Initial version2020.12.20 : Change order of CollectDependant calls to addres some hidden dependencies.param($result) Import-Module RemoteDesktopServices Apply certificateSet-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop Restart services required for "Access Anywhere"$global:ServicesToStart = @() Function CollectDependent($TargetService) {
} CollectDependent("SSTPSvc") CollectDependent("IAS") Write-Warning "Restarting services in the following order: " foreach($service in $global:ServicesToStart ) { start-service $service -ErrorAction SilentlyContinue } Write-Warning "Done!" |
(I have issues with this #!$ browser) Here it is again: ##****************************************************************** Revision date: 2020.12.20Copyright (c) 2020 PC-Évolution enr.This code is licensed under the GNU General Public License (GPL).THIS CODE IS PROVIDED AS IS WITHOUT WARRANTY OFANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING ANYIMPLIED WARRANTIES OF FITNESS FOR A PARTICULARPURPOSE, MERCHANTABILITY, OR NON-INFRINGEMENT.##****************************************************************** Certify The Web Deployment Script for Windows Server 2016 Essentials (Your Mileage May Vary ;-)Restart the "Network Policy Server" as well as the SSTP protocol : all dependent services arestopped and started in the exact reverse order they were stopped.Note: the Write-Warning is used so that messages will appear in the Certify The Web log file.2020.08.19 : Initial version2020.12.20 : Change order of CollectDependant calls to addres some hidden dependencies.param($result) Import-Module RemoteDesktopServices Apply certificateSet-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop Restart services required for "Access Anywhere"$global:ServicesToStart = @() Function CollectDependent($TargetService) {
} CollectDependent("SSTPSvc") CollectDependent("IAS") Write-Warning "Restarting services in the following order: " foreach($service in $global:ServicesToStart ) { start-service $service -ErrorAction SilentlyContinue } Write-Warning "Done!" |
Serge, Thank you so much! |
Dumb question as I'm still learning - do I just copy and paste the script into a ps1 file? |
Yep!
Save the script in some directory other the CTW directory.
Regards,
De : latinkreationz <[email protected]>
Envoyé : 3 février 2021 23:24
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Dumb question as I'm still learning - do I just copy and paste the script into a ps1 file?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4BBW7S5GJAQ7GJSAITS5IOPTANCNFSM4PYY2OMQ>.
|
Great! Thanks again!!! |
It doesn't look like either of Serge's posts formatted correctly in the forum thread... I took the liberty of cleaning up the code and applying the order and dependency logic changes per his revisions. Hope this helps!
|
Thanks devast8tor! |
Hey Serge, Just wanted to let you know that the updated script still isn't working right for me, even though the log didn't show any errors. After my last cert update on 2/24, the remote access server started throwing cert errors again. I ended up applying the same manual fix I've used before, which was to export the new cert from IIS and then re-rerun WSE remote setup through the wizard. |
Hello Ryan,
That’s interesting.
We are running Windows Server 2016 Standard (v1607, OS Version 14393.4169): I have 7 different instances running and serving roughly 200 users.
These instances are using only SSTP to access the VPN. On one of these instances we had a month ago a situation where the Terminal Services Gateway was working perfectly following the certificate renewal but not the SSTP service which uses the same certificate.
We believe that there is some undocumented relationship between all these services: in the case above, everything was back to normal following a reboot. Manually stopping all the KNOWN services are restarting in the correct order was no help: reboot was the only solution that worked in this case.
The issue is on my TODO list.
I can’t report any error on the six other servers.
Regards,
Serge Caron
De : devast8tor <[email protected]>
Envoyé : 28 février 2021 23:14
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Hey Serge,
Just wanted to let you know that the updated script still isn't working right for me, even though the log didn't show any errors. After my last cert update on 2/24, the remote access server started throwing cert errors again. I ended up applying the same manual fix I've used before, which was to export the new cert from IIS and then re-rerun WSE remote setup through the wizard.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4CCTXBSXLVYO6C6V53TBMH73ANCNFSM4PYY2OMQ>.
|
Serge,
Appreciate your reply and I totally understand. I agree that there seems to
be some undocumented shenanigans occurring in steps that are hidden behind
the setup/repair wizard. I am happy to enable additional logging or to
setup tracing (either of ctw or the wse setup wizard) to see if we can't
tease out the voodoo occurring behind that setup progress bar.
If you'd like to collaborate, just let me know. I also have access to
Unified Support via my employer, so have been considering opening a support
case to capture this detail if it would help?
Regards,
Ryan
…On Mon, Mar 1, 2021, 4:27 AM SergeCaron ***@***.***> wrote:
Hello Ryan,
That’s interesting.
We are running Windows Server 2016 Standard (v1607, OS Version
14393.4169): I have 7 different instances running and serving roughly 200
users.
These instances are using only SSTP to access the VPN. On one of these
instances we had a month ago a situation where the Terminal Services
Gateway was working perfectly following the certificate renewal but not the
SSTP service which uses the same certificate.
We believe that there is some undocumented relationship between all these
services: in the case above, everything was back to normal following a
reboot. Manually stopping all the KNOWN services are restarting in the
correct order was no help: reboot was the only solution that worked in this
case.
The issue is on my TODO list.
I can’t report any error on the six other servers.
Regards,
Serge Caron
De : devast8tor ***@***.***>
Envoyé : 28 février 2021 23:14
À : webprofusion/certify ***@***.***>
Cc : Serge Caron ***@***.***>; Author <
***@***.***>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Hey Serge,
Just wanted to let you know that the updated script still isn't working
right for me, even though the log didn't show any errors. After my last
cert update on 2/24, the remote access server started throwing cert errors
again. I ended up applying the same manual fix I've used before, which was
to export the new cert from IIS and then re-rerun WSE remote setup through
the wizard.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
#519 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AQROU4CCTXBSXLVYO6C6V53TBMH73ANCNFSM4PYY2OMQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJWUSGMJS3KGAG5COXOV7DTBOB2ZANCNFSM4PYY2OMQ>
.
|
While the script works for me, the only issue I have is with SSTP VPN routing not working until a server reboot as Serge pointed out. So until a solution is mentioned, I went ahead and added a task within CTW to run a reboot after the script completes. It makes sense to have 3-5 minutes of down time vs. hours of not knowing it's down. |
Hello Ryan,
I like « shenanigans » : magic is always a nice escape also …
It is the architecture that I don’t fully grasp.
Once the certificate is renewed, the SSTP service will process incoming connections. The network stack will assign an IP and maintain the connection with keepalives (this is an oversimplification but the gist is that the VPN is established). In the snippet below, you can see that both users got exactly 343 bytes out of the server, regardless of connection duration.
The culprit seems to be NPS (the “Network Policy Server”) which does not seem to allow any incoming traffic on the connection.
In Install and Configure the NPS Server | Microsoft Docs<https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-nps>, there is documentation concerning “Autoenroll the NPS Server Certificate” and a required Group Policy Update that I don’t fully understand. Just out of curiosity, I added a “invoke-gpudate” command in my script to see if this had any effect (and yes, the -force parameter is specified ;-).
At this point, this is the most plausible culprit. I just don’t understand why the issue is not the same on all servers.
So, if you want to further this … be my guest ;-)
Regards,
Serge Caron
PS C:\Windows\system32> Get-RemoteAccessConnectionStatistics | fl *
ClientIPv4Address : 172.16.0.70
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.70
AuthMethod : MSChapv2
ConnectionDuration : 2019
ConnectionStartTime : 2021-03-04 19:37:25
ConnectionType : Vpn
HostName : -
TotalBytesIn : 6683429
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 91
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user1}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess : RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress, ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties
ClientIPv4Address : 172.16.0.72
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.72
AuthMethod : MSChapv2
ConnectionDuration : 4393
ConnectionStartTime : 2021-03-04 18:57:50
ConnectionType : Vpn
HostName : -
TotalBytesIn : 50809
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 12
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user2}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess : RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress, ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties
PS C:\Windows\system32>
De : devast8tor <[email protected]>
Envoyé : 3 mars 2021 11:34
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Serge,
Appreciate your reply and I totally understand. I agree that there seems to
be some undocumented shenanigans occurring in steps that are hidden behind
the setup/repair wizard. I am happy to enable additional logging or to
setup tracing (either of ctw or the wse setup wizard) to see if we can't
tease out the voodoo occurring behind that setup progress bar.
If you'd like to collaborate, just let me know. I also have access to
Unified Support via my employer, so have been considering opening a support
case to capture this detail if it would help?
Regards,
Ryan
On Mon, Mar 1, 2021, 4:27 AM SergeCaron ***@***.******@***.***>> wrote:
Hello Ryan,
That’s interesting.
We are running Windows Server 2016 Standard (v1607, OS Version
14393.4169): I have 7 different instances running and serving roughly 200
users.
These instances are using only SSTP to access the VPN. On one of these
instances we had a month ago a situation where the Terminal Services
Gateway was working perfectly following the certificate renewal but not the
SSTP service which uses the same certificate.
We believe that there is some undocumented relationship between all these
services: in the case above, everything was back to normal following a
reboot. Manually stopping all the KNOWN services are restarting in the
correct order was no help: reboot was the only solution that worked in this
case.
The issue is on my TODO list.
I can’t report any error on the six other servers.
Regards,
Serge Caron
De : devast8tor ***@***.******@***.***>>
Envoyé : 28 février 2021 23:14
À : webprofusion/certify ***@***.******@***.***>>
Cc : Serge Caron ***@***.******@***.***>>; Author <
***@***.******@***.***>>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Hey Serge,
Just wanted to let you know that the updated script still isn't working
right for me, even though the log didn't show any errors. After my last
cert update on 2/24, the remote access server started throwing cert errors
again. I ended up applying the same manual fix I've used before, which was
to export the new cert from IIS and then re-rerun WSE remote setup through
the wizard.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
#519 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AQROU4CCTXBSXLVYO6C6V53TBMH73ANCNFSM4PYY2OMQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJWUSGMJS3KGAG5COXOV7DTBOB2ZANCNFSM4PYY2OMQ>
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4C3KS57YA3L3Y2XXWLTBZQGRANCNFSM4PYY2OMQ>.
|
Hello Ryan,
Sometimes, you need to read the documentation the way it is written. What needs to be done is to update the group policies the same way the update would happen on a reboot.
In the script, add the following line in the history:
# 2020.12.20 : Change order of CollectDependent calls to address some hidden dependencies.
# 2021.03.07 : Force NPS to update the shared secret that is the server certificate
Add the following lines after the services are stopped and before they are restarted (the first and last lines are duplicated here just to be certain ;-) :
[array]::Reverse($global:ServicesToStart) <--- after this line
Write-Warning "Updating group policies"
# The following command does not yield any output :
# Invoke-GPUpdate -RandomDelayInMinutes 0 -Force
$GP = gpupdate /force
foreach($line in $GP ) { Write-Warning $line }
Write-Warning ""
Write-Warning "Restarting services in the following order: " <--- before this line
Save the updated script and proceed to a certificate renewal. You should be able to ping your domain default gateway from the VPN client ;-) (Actually, I waited about 10 seconds after the VPN connected to do that).
By the way, it so happens that on all other servers, the first VPN connection was more than two hours following a certificate renewal.
Kind regards,
Serge Caron
De : Serge Caron
Envoyé : 4 mars 2021 23:25
À : 'webprofusion/certify' <[email protected]>; webprofusion/certify <[email protected]>
Cc : Author <[email protected]>
Objet : RE: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Hello Ryan,
I like « shenanigans » : magic is always a nice escape also …
It is the architecture that I don’t fully grasp.
Once the certificate is renewed, the SSTP service will process incoming connections. The network stack will assign an IP and maintain the connection with keepalives (this is an oversimplification but the gist is that the VPN is established). In the snippet below, you can see that both users got exactly 343 bytes out of the server, regardless of connection duration.
The culprit seems to be NPS (the “Network Policy Server”) which does not seem to allow any incoming traffic on the connection.
In Install and Configure the NPS Server | Microsoft Docs<https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-nps>, there is documentation concerning “Autoenroll the NPS Server Certificate” and a required Group Policy Update that I don’t fully understand. Just out of curiosity, I added a “invoke-gpudate” command in my script to see if this had any effect (and yes, the -force parameter is specified ;-).
At this point, this is the most plausible culprit. I just don’t understand why the issue is not the same on all servers.
So, if you want to further this … be my guest ;-)
Regards,
Serge Caron
PS C:\Windows\system32> Get-RemoteAccessConnectionStatistics | fl *
ClientIPv4Address : 172.16.0.70
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.70
AuthMethod : MSChapv2
ConnectionDuration : 2019
ConnectionStartTime : 2021-03-04 19:37:25
ConnectionType : Vpn
HostName : -
TotalBytesIn : 6683429
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 91
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user1}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess : RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress, ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties
ClientIPv4Address : 172.16.0.72
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.72
AuthMethod : MSChapv2
ConnectionDuration : 4393
ConnectionStartTime : 2021-03-04 18:57:50
ConnectionType : Vpn
HostName : -
TotalBytesIn : 50809
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 12
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user2}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess : RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress, ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties
PS C:\Windows\system32>
De : devast8tor <[email protected]>
Envoyé : 3 mars 2021 11:34
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Serge,
Appreciate your reply and I totally understand. I agree that there seems to
be some undocumented shenanigans occurring in steps that are hidden behind
the setup/repair wizard. I am happy to enable additional logging or to
setup tracing (either of ctw or the wse setup wizard) to see if we can't
tease out the voodoo occurring behind that setup progress bar.
If you'd like to collaborate, just let me know. I also have access to
Unified Support via my employer, so have been considering opening a support
case to capture this detail if it would help?
Regards,
Ryan
On Mon, Mar 1, 2021, 4:27 AM SergeCaron ***@***.******@***.***>> wrote:
Hello Ryan,
That’s interesting.
We are running Windows Server 2016 Standard (v1607, OS Version
14393.4169): I have 7 different instances running and serving roughly 200
users.
These instances are using only SSTP to access the VPN. On one of these
instances we had a month ago a situation where the Terminal Services
Gateway was working perfectly following the certificate renewal but not the
SSTP service which uses the same certificate.
We believe that there is some undocumented relationship between all these
services: in the case above, everything was back to normal following a
reboot. Manually stopping all the KNOWN services are restarting in the
correct order was no help: reboot was the only solution that worked in this
case.
The issue is on my TODO list.
I can’t report any error on the six other servers.
Regards,
Serge Caron
De : devast8tor ***@***.******@***.***>>
Envoyé : 28 février 2021 23:14
À : webprofusion/certify ***@***.******@***.***>>
Cc : Serge Caron ***@***.******@***.***>>; Author <
***@***.******@***.***>>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Hey Serge,
Just wanted to let you know that the updated script still isn't working
right for me, even though the log didn't show any errors. After my last
cert update on 2/24, the remote access server started throwing cert errors
again. I ended up applying the same manual fix I've used before, which was
to export the new cert from IIS and then re-rerun WSE remote setup through
the wizard.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
#519 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AQROU4CCTXBSXLVYO6C6V53TBMH73ANCNFSM4PYY2OMQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJWUSGMJS3KGAG5COXOV7DTBOB2ZANCNFSM4PYY2OMQ>
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4C3KS57YA3L3Y2XXWLTBZQGRANCNFSM4PYY2OMQ>.
|
I added and tested the group policy update that you indicated and it didn't work for me. I checked the log and it ran successfully so not sure why it didn't work. Rebooting the server does make it work again so I guess I'll just continue using that extra task since it does work. |
Hello,
I am beginning to think the behavior on a “Windows Server 2016 Essentials” edition is not exactly the same as on a “Windows Server 2016 Standard” edition with the “Essentials Experience Role” installed.
I manage 4 servers of the first type and 3 of the second using this “Essentials” software.
I added some details concerning the renewed certificate and VPN configuration in the output log. Below is a sample log.
The revised code is:
[array]::Reverse($global:ServicesToStart) <--- after this line
Write-Warning "-----------------------"
Write-Warning "Updating group policies"
# The folloing command does not yield any output :
# Invoke-GPUpdate -RandomDelayInMinutes 0 -Force
$GP = gpupdate /force
$GP = [string]::Join([Environment]::NewLine, ($GP | ?{$_ -match ".."}))
$GP | Write-Output
Write-Warning ""
Write-Warning "Restarting services in the following order: "
foreach($service in $global:ServicesToStart ) { Write-Warning $service }
Write-Warning ""
foreach($service in $global:ServicesToStart ) { start-service $service -ErrorAction SilentlyContinue }
Write-Warning "Active certificate details: "
$Status = Get-RemoteAccess | fl SSLCertificate, VPNStatus, VPNConfiguration | Out-String
$Status = [string]::Join([Environment]::NewLine, ($Status | ?{$_ -match ".."}))
$Status | Write-Output
Write-Warning ""
Write-Warning "Done!" <--- before this line
On a “Windows Server 2016 Essentials”, OS version 14393.3930, I can assure you that the certificate is renewed and the VPN connections are normal hereafter. These are simple domains.
On a “Windows Server 2016 Standard” edition with the “Essentials Experience Role”, OS version 14393.4169, I can assure you that the VPN DOES NOT PASS TRAFIC, although the certificate is renewed and the VPN connections are normal hereafter. This is a more complex domain with 2 domain controllers but this should not be a variable in this issue.
Both tests are run from the same physical client and from the same user account: obviously, this should not have an effect on the remote server but I just wanted to be sure that the client did not interfere.
I will let the second domain alone for two hours in case the domain GPO refresh is significant, but I believe the issue is elsewhere.
Regards,
Serge Caron
Sample log output:
-------------------------
2021-03-08 15:57:54.071 -05:00 [INF] Executing command via PowerShell
2021-03-08 15:58:27.527 -05:00 [INF] Omitting RasMan : service is Stopped with the startmode: Disabled
Omitting rqs : service is Stopped with the startmode: Manual
Attente de l’arrêt du service « Routage et accès distant (RemoteAccess) »…
Attente de l’arrêt du service « Routage et accès distant (RemoteAccess) »…
Omitting rqs : service is Stopped with the startmode: Manual
Attente de l’arrêt du service « Network Policy Server (IAS) »…
Attente de l’arrêt du service « Network Policy Server (IAS) »…
-----------------------
Updating group policies
Mise … jour de la strat‚gie...
La mise … jour de la strat‚gie d'ordinateur s'est termin‚e sans erreur.
La mise … jour de la strat‚gie utilisateur s'est termin‚e sans erreur.
Restarting services in the following order:
IAS
TSGateway
SSTPSvc
RemoteAccess
Active certificate details:
SslCertificate : [Subject]
CN=passerelle.<Domain.TLD>
[Issuer]
CN=R3, O=Let's Encrypt, C=US
[Serial Number]
03A8059FBxxxxxxF6A41528D6926E6058CDE
[Not Before]
2021-03-08 14:57:50
[Not After]
2021-06-06 15:57:50
[Thumbprint]
684004887xxxxxx8F639D58CC8D3F387F594911C
VPNStatus : Installed
VPNConfiguration : VirtualPrivateNetworkConfiguration
Done!
2021-03-08 15:58:27.527 -05:00 [INF] Run Powershell Script :: Task Completed OK
2021-03-08 15:58:27.534 -05:00 [INF] Request completed
De : latinkreationz <[email protected]>
Envoyé : 7 mars 2021 23:53
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
I added and tested the group policy update that you indicated and it didn't work for me. I checked the log and it ran successfully so not sure why it didn't work. Rebooting the server does make it work again so I guess I'll just continue using that extra task since it does work.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4ECZJSGZRLCU2NW75LTCRJ2XANCNFSM4PYY2OMQ>.
|
Very interesting. I'm actually running Windows Server 2016 Essentials version 14393.3930 and the SSTP VPN was still not routing after a successful renewal. Just to confirm - is the revised code specific to Server 2016 Standard or should it work regardless? I can continue to do some further testing on my end as well. I'm not as technical as you guys are but I'll do what I can. Let me know. |
Hello,
Well, you are running the same edition and version as the server for which the revised code is working at my end.
Quick tip: you can update the code and rerun the deployment task without requesting a new certificate. This way, you can test an external client against you server.
I am currently updating the test server to the latest (and greatest!) Windows Server 2016 patches. I still expect this will work tomorrow morning.
Regards.
Serge Caron
De : latinkreationz <[email protected]>
Envoyé : 8 mars 2021 19:24
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Very interesting. I'm actually running Windows Server 2016 Essentials version 14393.3930 and the SSTP VPN was still not routing after a successful renewal. Just to confirm - is the revised code specific to Server 2016 Standard or should it work regardless? I can continue to do some further testing on my end as well. I'm not as technical as you guys are but I'll do what I can. Let me know.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4DYJMFELJD7CVIQEUDTCVTA5ANCNFSM4PYY2OMQ>.
|
I'd recommend raising a ticket with Microsoft for specific instructions regarding your version of Windows server. Clearly you've got your certificate OK and the problem (which is specific to Microsoft services) is how to apply it cleanly. I'd wager that they'd will tell you to apply the certificate then restart the server. Note again that Deployment Tasks can be setup to run Manually, this lets you have certificate be auto-renewed by Certify but the actual deployment can be a manual task during a maintenance window (e.g. monthly patching). |
Hello Christopher,
Thank you for the suggestion.
That is where I am actually heading. I would like to avoid the manual reboot if at all possible but if everything else fails …
I would also like to have a clearer understanding of the “improved” RRAS at the SSTP level: I have a number of technical staff travelling the world and HTTPS is often the only protocol allowed out of hotels and other public places. Clearly, SSTPSvc is disjoint from NPC (IAS) at the surface level but seems to be connected through some other mechanism.
Kind regards,
Serge Caron
De : Christopher Cook <[email protected]>
Envoyé : 8 mars 2021 20:12
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
I'd recommend raising a ticket with Microsoft for specific instructions regarding your version of Windows server. Clearly you've got your certificate OK and the problem (which is specific to Microsoft services) is how to apply it cleanly. I'd wager that they'd will tell you to apply the certificate then restart the server.
Note again that Deployment Tasks can be setup to run Manually, this lets you have certificate be auto-renewed by Certify but the actual deployment can be a manual task during a maintenance window (e.g. monthly patching).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4ETESUPKOBREQK2SX3TCVYVZANCNFSM4PYY2OMQ>.
|
Yes I think to fully solve this issue you'd need specialist advice from the part of the Windows product team at Microsoft who manage this feature. It's entirely possible that the process cannot be cleanly automated in all versions of windows server, because around 2016 it was normal for certificates to only be replaced every year or two. |
Serge,
FWIW, I'm running Windows Server 2016 Essentials (v1607, OS Version
14393.4225). There must also be some differences between the Standard
version with the role and the Essentials version because using your script
always results in an error being tripped for Terminal Service Gateway using
the old cert.
- Ryan
…On Mon, Mar 1, 2021 at 4:27 AM SergeCaron ***@***.***> wrote:
Hello Ryan,
That’s interesting.
We are running Windows Server 2016 Standard (v1607, OS Version
14393.4169): I have 7 different instances running and serving roughly 200
users.
These instances are using only SSTP to access the VPN. On one of these
instances we had a month ago a situation where the Terminal Services
Gateway was working perfectly following the certificate renewal but not the
SSTP service which uses the same certificate.
We believe that there is some undocumented relationship between all these
services: in the case above, everything was back to normal following a
reboot. Manually stopping all the KNOWN services are restarting in the
correct order was no help: reboot was the only solution that worked in this
case.
The issue is on my TODO list.
I can’t report any error on the six other servers.
Regards,
Serge Caron
De : devast8tor ***@***.***>
Envoyé : 28 février 2021 23:14
À : webprofusion/certify ***@***.***>
Cc : Serge Caron ***@***.***>; Author <
***@***.***>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Hey Serge,
Just wanted to let you know that the updated script still isn't working
right for me, even though the log didn't show any errors. After my last
cert update on 2/24, the remote access server started throwing cert errors
again. I ended up applying the same manual fix I've used before, which was
to export the new cert from IIS and then re-rerun WSE remote setup through
the wizard.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
#519 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AQROU4CCTXBSXLVYO6C6V53TBMH73ANCNFSM4PYY2OMQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJWUSGMJS3KGAG5COXOV7DTBOB2ZANCNFSM4PYY2OMQ>
.
|
Serge,
Thank you for supplying the GP update lines for the script. I just wanted
to point out I might still be using an older version of the script as my
code does not have the following line:
[array]::Reverse($global:ServicesToStart) <--- after this line
Logically, I inserted this after the CollectDependent("IAS"), but before
the service restart section. Is there a newer version of the script where
you've rewritten the service dependencies collection and stop logic?
- Ryan
…On Sun, Mar 7, 2021 at 6:31 AM SergeCaron ***@***.***> wrote:
Hello Ryan,
Sometimes, you need to read the documentation the way it is written. What
needs to be done is to update the group policies the same way the update
would happen on a reboot.
In the script, add the following line in the history:
# 2020.12.20 : Change order of CollectDependent calls to address some
hidden dependencies.
# 2021.03.07 : Force NPS to update the shared secret that is the server
certificate
Add the following lines after the services are stopped and before they are
restarted (the first and last lines are duplicated here just to be certain
;-) :
[array]::Reverse($global:ServicesToStart) <--- after this line
Write-Warning "Updating group policies"
# The following command does not yield any output :
# Invoke-GPUpdate -RandomDelayInMinutes 0 -Force
$GP = gpupdate /force
foreach($line in $GP ) { Write-Warning $line }
Write-Warning ""
Write-Warning "Restarting services in the following order: " <--- before
this line
Save the updated script and proceed to a certificate renewal. You should
be able to ping your domain default gateway from the VPN client ;-)
(Actually, I waited about 10 seconds after the VPN connected to do that).
By the way, it so happens that on all other servers, the first VPN
connection was more than two hours following a certificate renewal.
Kind regards,
Serge Caron
De : Serge Caron
Envoyé : 4 mars 2021 23:25
À : 'webprofusion/certify' ***@***.***>; webprofusion/certify
***@***.***>
Cc : Author ***@***.***>
Objet : RE: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Hello Ryan,
I like « shenanigans » : magic is always a nice escape also …
It is the architecture that I don’t fully grasp.
Once the certificate is renewed, the SSTP service will process incoming
connections. The network stack will assign an IP and maintain the
connection with keepalives (this is an oversimplification but the gist is
that the VPN is established). In the snippet below, you can see that both
users got exactly 343 bytes out of the server, regardless of connection
duration.
The culprit seems to be NPS (the “Network Policy Server”) which does not
seem to allow any incoming traffic on the connection.
In Install and Configure the NPS Server | Microsoft Docs<
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-nps>,
there is documentation concerning “Autoenroll the NPS Server Certificate”
and a required Group Policy Update that I don’t fully understand. Just out
of curiosity, I added a “invoke-gpudate” command in my script to see if
this had any effect (and yes, the -force parameter is specified ;-).
At this point, this is the most plausible culprit. I just don’t understand
why the issue is not the same on all servers.
So, if you want to further this … be my guest ;-)
Regards,
Serge Caron
PS C:\Windows\system32> Get-RemoteAccessConnectionStatistics | fl *
ClientIPv4Address : 172.16.0.70
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.70
AuthMethod : MSChapv2
ConnectionDuration : 2019
ConnectionStartTime : 2021-03-04 19:37:25
ConnectionType : Vpn
HostName : -
TotalBytesIn : 6683429
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 91
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user1}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess :
RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress,
ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties :
Microsoft.Management.Infrastructure.CimSystemProperties
ClientIPv4Address : 172.16.0.72
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.72
AuthMethod : MSChapv2
ConnectionDuration : 4393
ConnectionStartTime : 2021-03-04 18:57:50
ConnectionType : Vpn
HostName : -
TotalBytesIn : 50809
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 12
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user2}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess :
RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress,
ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties :
Microsoft.Management.Infrastructure.CimSystemProperties
PS C:\Windows\system32>
De : devast8tor ***@***.***>
Envoyé : 3 mars 2021 11:34
À : webprofusion/certify ***@***.***>
Cc : Serge Caron ***@***.***>; Author <
***@***.***>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Serge,
Appreciate your reply and I totally understand. I agree that there seems
to
be some undocumented shenanigans occurring in steps that are hidden behind
the setup/repair wizard. I am happy to enable additional logging or to
setup tracing (either of ctw or the wse setup wizard) to see if we can't
tease out the voodoo occurring behind that setup progress bar.
If you'd like to collaborate, just let me know. I also have access to
Unified Support via my employer, so have been considering opening a
support
case to capture this detail if it would help?
Regards,
Ryan
On Mon, Mar 1, 2021, 4:27 AM SergeCaron ***@***.***<mailto:
***@***.***>> wrote:
> Hello Ryan,
>
> That’s interesting.
>
> We are running Windows Server 2016 Standard (v1607, OS Version
> 14393.4169): I have 7 different instances running and serving roughly
200
> users.
>
> These instances are using only SSTP to access the VPN. On one of these
> instances we had a month ago a situation where the Terminal Services
> Gateway was working perfectly following the certificate renewal but not
the
> SSTP service which uses the same certificate.
>
> We believe that there is some undocumented relationship between all
these
> services: in the case above, everything was back to normal following a
> reboot. Manually stopping all the KNOWN services are restarting in the
> correct order was no help: reboot was the only solution that worked in
this
> case.
>
> The issue is on my TODO list.
>
> I can’t report any error on the six other servers.
>
> Regards,
>
> Serge Caron
>
>
> De : devast8tor ***@***.***<mailto:
***@***.***>>
> Envoyé : 28 février 2021 23:14
> À : webprofusion/certify ***@***.***<mailto:
***@***.***>>
> Cc : Serge Caron ***@***.******@***.***>>;
Author <
> ***@***.******@***.***>>
> Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
> Anywhere Certificate renewal script (#519)
>
>
> Hey Serge,
>
> Just wanted to let you know that the updated script still isn't working
> right for me, even though the log didn't show any errors. After my last
> cert update on 2/24, the remote access server started throwing cert
errors
> again. I ended up applying the same manual fix I've used before, which
was
> to export the new cert from IIS and then re-rerun WSE remote setup
through
> the wizard.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub<
>
#519 (comment)>,
> or unsubscribe<
>
https://github.com/notifications/unsubscribe-auth/AQROU4CCTXBSXLVYO6C6V53TBMH73ANCNFSM4PYY2OMQ>.
>
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#519 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AIJWUSGMJS3KGAG5COXOV7DTBOB2ZANCNFSM4PYY2OMQ>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
#519 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AQROU4C3KS57YA3L3Y2XXWLTBZQGRANCNFSM4PYY2OMQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJWUSGOQZOV5Q3R2XJKR5DTCOE43ANCNFSM4PYY2OMQ>
.
|
Hello Ryan, Christopher ad all ;-)
First, there is a missing piece in the puzzle. In the “Essentials” internal architecture, there seems to be some dependencies on IPv6 and Configure IPv6 for advanced users - Windows Server | Microsoft Docs<https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/configure-ipv6-in-windows> recommends leaving it on.
There is a service, IPHelpSvc, that translates protocols between IPv4 and IPv6, including IP-HTTPS. Which means that this service depends on the certificate being replaced, whatever the way it gets it.
So I decided to add this service (and dependents) to the list and updated the script.
Second, we have this issue across Windows Server 2016 editions. It is not so obvious:
* Tests against a Windows Server 2016 Standard OS version 14393.4169 running the “Essentials Experience” role show that the VPN does NOT pass traffic.
* Tests against a Windows Server 2016 Standard OS version 14393.4225 show that the VPN DOES pass traffic: this one is a member server of the same domain as the one above which is also a domain controller.
* Tests against a Windows Server 2016 Essentials OS version 14393.4225 show that the VPN DOES pass traffic: this one is obviously holding the FSMO rights (i.e., it is a “primary” domain controller)
So, I am going to upgrade the recalcitrant server just to see if this issue is OS version related. Basically, I know that .4169 is only a month older than .4225 but I would like to have identical server versions that yield different result for the same configuration.
In the meantime, you can ask Christopher to unlock the attached file ;-)
Kind regards,
Serge Caron
De : devast8tor <[email protected]>
Envoyé : 9 mars 2021 00:40
À : webprofusion/certify <[email protected]>
Cc : Serge Caron <[email protected]>; Author <[email protected]>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Serge,
Thank you for supplying the GP update lines for the script. I just wanted
to point out I might still be using an older version of the script as my
code does not have the following line:
[array]::Reverse($global:ServicesToStart) <--- after this line
Logically, I inserted this after the CollectDependent("IAS"), but before
the service restart section. Is there a newer version of the script where
you've rewritten the service dependencies collection and stop logic?
- Ryan
On Sun, Mar 7, 2021 at 6:31 AM SergeCaron ***@***.***> wrote:
Hello Ryan,
Sometimes, you need to read the documentation the way it is written. What
needs to be done is to update the group policies the same way the update
would happen on a reboot.
In the script, add the following line in the history:
# 2020.12.20 : Change order of CollectDependent calls to address some
hidden dependencies.
# 2021.03.07 : Force NPS to update the shared secret that is the server
certificate
Add the following lines after the services are stopped and before they are
restarted (the first and last lines are duplicated here just to be certain
;-) :
[array]::Reverse($global:ServicesToStart) <--- after this line
Write-Warning "Updating group policies"
# The following command does not yield any output :
# Invoke-GPUpdate -RandomDelayInMinutes 0 -Force
$GP = gpupdate /force
foreach($line in $GP ) { Write-Warning $line }
Write-Warning ""
Write-Warning "Restarting services in the following order: " <--- before
this line
Save the updated script and proceed to a certificate renewal. You should
be able to ping your domain default gateway from the VPN client ;-)
(Actually, I waited about 10 seconds after the VPN connected to do that).
By the way, it so happens that on all other servers, the first VPN
connection was more than two hours following a certificate renewal.
Kind regards,
Serge Caron
De : Serge Caron
Envoyé : 4 mars 2021 23:25
À : 'webprofusion/certify' ***@***.***>; webprofusion/certify
***@***.***>
Cc : Author ***@***.***>
Objet : RE: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Hello Ryan,
I like « shenanigans » : magic is always a nice escape also …
It is the architecture that I don’t fully grasp.
Once the certificate is renewed, the SSTP service will process incoming
connections. The network stack will assign an IP and maintain the
connection with keepalives (this is an oversimplification but the gist is
that the VPN is established). In the snippet below, you can see that both
users got exactly 343 bytes out of the server, regardless of connection
duration.
The culprit seems to be NPS (the “Network Policy Server”) which does not
seem to allow any incoming traffic on the connection.
In Install and Configure the NPS Server | Microsoft Docs<
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-nps>,
there is documentation concerning “Autoenroll the NPS Server Certificate”
and a required Group Policy Update that I don’t fully understand. Just out
of curiosity, I added a “invoke-gpudate” command in my script to see if
this had any effect (and yes, the -force parameter is specified ;-).
At this point, this is the most plausible culprit. I just don’t understand
why the issue is not the same on all servers.
So, if you want to further this … be my guest ;-)
Regards,
Serge Caron
PS C:\Windows\system32> Get-RemoteAccessConnectionStatistics | fl *
ClientIPv4Address : 172.16.0.70
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.70
AuthMethod : MSChapv2
ConnectionDuration : 2019
ConnectionStartTime : 2021-03-04 19:37:25
ConnectionType : Vpn
HostName : -
TotalBytesIn : 6683429
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 91
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user1}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess :
RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress,
ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties :
Microsoft.Management.Infrastructure.CimSystemProperties
ClientIPv4Address : 172.16.0.72
ClientIPv6Address : ::
ClientExternalAddress : [ snipped ]
ClientIPAddress : 172.16.0.72
AuthMethod : MSChapv2
ConnectionDuration : 4393
ConnectionStartTime : 2021-03-04 18:57:50
ConnectionType : Vpn
HostName : -
TotalBytesIn : 50809
TotalBytesOut : 343
TransitionTechnology : None
TunnelType : Sstp
Bandwidth : 12
RoutingDomain :
UserActivityState : Active
UserName : {DOMAIN\user2}
PSComputerName :
CimClass : root/Microsoft/Windows/RemoteAccess :
RemoteAccessMonitoringConnection
CimInstanceProperties : {AuthMethod, ClientExternalAddress,
ClientIPv4Address, ClientIPv6Address...}
CimSystemProperties :
Microsoft.Management.Infrastructure.CimSystemProperties
PS C:\Windows\system32>
De : devast8tor ***@***.***>
Envoyé : 3 mars 2021 11:34
À : webprofusion/certify ***@***.***>
Cc : Serge Caron ***@***.***>; Author <
***@***.***>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
Anywhere Certificate renewal script (#519)
Serge,
Appreciate your reply and I totally understand. I agree that there seems
to
be some undocumented shenanigans occurring in steps that are hidden behind
the setup/repair wizard. I am happy to enable additional logging or to
setup tracing (either of ctw or the wse setup wizard) to see if we can't
tease out the voodoo occurring behind that setup progress bar.
If you'd like to collaborate, just let me know. I also have access to
Unified Support via my employer, so have been considering opening a
support
case to capture this detail if it would help?
Regards,
Ryan
On Mon, Mar 1, 2021, 4:27 AM SergeCaron ***@***.***<mailto:
***@***.***>> wrote:
> Hello Ryan,
>
> That’s interesting.
>
> We are running Windows Server 2016 Standard (v1607, OS Version
> 14393.4169): I have 7 different instances running and serving roughly
200
> users.
>
> These instances are using only SSTP to access the VPN. On one of these
> instances we had a month ago a situation where the Terminal Services
> Gateway was working perfectly following the certificate renewal but not
the
> SSTP service which uses the same certificate.
>
> We believe that there is some undocumented relationship between all
these
> services: in the case above, everything was back to normal following a
> reboot. Manually stopping all the KNOWN services are restarting in the
> correct order was no help: reboot was the only solution that worked in
this
> case.
>
> The issue is on my TODO list.
>
> I can’t report any error on the six other servers.
>
> Regards,
>
> Serge Caron
>
>
> De : devast8tor ***@***.***<mailto:
***@***.***>>
> Envoyé : 28 février 2021 23:14
> À : webprofusion/certify ***@***.***<mailto:
***@***.***>>
> Cc : Serge Caron ***@***.******@***.***>>;
Author <
> ***@***.******@***.***>>
> Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access
> Anywhere Certificate renewal script (#519)
>
>
> Hey Serge,
>
> Just wanted to let you know that the updated script still isn't working
> right for me, even though the log didn't show any errors. After my last
> cert update on 2/24, the remote access server started throwing cert
errors
> again. I ended up applying the same manual fix I've used before, which
was
> to export the new cert from IIS and then re-rerun WSE remote setup
through
> the wizard.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub<
>
#519 (comment)>,
> or unsubscribe<
>
https://github.com/notifications/unsubscribe-auth/AQROU4CCTXBSXLVYO6C6V53TBMH73ANCNFSM4PYY2OMQ>.
>
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#519 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AIJWUSGMJS3KGAG5COXOV7DTBOB2ZANCNFSM4PYY2OMQ>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
#519 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AQROU4C3KS57YA3L3Y2XXWLTBZQGRANCNFSM4PYY2OMQ>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJWUSGOQZOV5Q3R2XJKR5DTCOE43ANCNFSM4PYY2OMQ>
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4FAODZDJQZOWAHMTA3TCWYETANCNFSM4PYY2OMQ>.
|
@SergeCaron thanks for your investigation! To attach files you need to replying using the github user interface, I don't get your attachment either and there is no option for me to unlock it etc. |
Hello Christopher, I finally broke down and got myself a network trace of a SSTP VPN client connection both before and after a certificate renewal. In the samples below, the remote client is pinging the Google DNS 8.8.8.8. Both before and after the certificate renewal, we can see the Client/Server key exchange (packets 4 to 9 and 181 to 187). Now, each ICMP request from the client is a TCP "conversation". Before the certificate renewal, you can see a full Echo/Reply over packets 148 to 152 and then 153 to 157. These are conversations #15688 and #15837. After the certificate is renewed, you can see that the network stack does not RETURN the information to the VPN client. In packets 388 to 390, you can see the ping request coming from the VPN client, going over the destination and returning to the server. However, the resulting frame is not going to the VPN client: this and all subsequent packets are all part of the SAME conversation #5127. The network stack does not seem to be able to handle the certificate replacement even if it properly processed the handshaking using the new cetificate. A reboot appears to simply restart the network stack in healthy conditions. We have this issue on two servers out of 8. I do not know what the discriminaton factor is. What I do know is that users should be aware of this issue. Regards, Serge Caron No. Time Source Destination Protocol Length Info 148 39.907930 [ VPNClient ] 192.168.33.4 TLSv1.2 203 Application Data 153 40.919939 [ VPNClient ] 192.168.33.4 TLSv1.2 203 Application Data No. Time Source Destination Protocol Length Info 388 326.284106 [ VPNClient ] 192.168.33.4 TLSv1.2 203 Application Data 392 327.275837 [ VPNClient ] 192.168.33.4 TLSv1.2 203 Application Data 396 331.148776 [ VPNClient ] 192.168.33.4 TLSv1.2 203 Application Data |
Thanks for the detailed analysis @SergeCaron I really do think you should raise this directly with Microsoft for a support escalation, linking them to this github issue. Rebooting the server isn't really a solution and only Microsoft can really investigate this in detail. Technically the issue is not with Certify because you already have your certificate. Although this is an interesting topic, the point at which we stop providing direct support (with the exception of IIS website bindings) is when you have the certificate then want to use it with another service (there are of course thousands of ways to use a certificate and they all have their own interesting problems). We try to provide the basic mechanism for you to apply certificates automatically but we don't directly support issues with individual services (because we don't have domain knowledge for every service). |
Hello Christopher,
You are, of course, entirely correct.
The documentation and support material is provided to make sure there is a valid certificate renewal and that this certificate is installed correctly and in use.
The fact that SSTP goes haywire has nothing to do with the certificate renewal, be it manually with some other supplier or using Certify The Web.
However, if the clients expect SSTP to work, then they MAY need to reboot their server. As they say, “Your mileage may vary.” ;-)
I will see if I can open a ticket with Microsoft: out of 8 servers, the only two for which I have this issue are production servers with very little maintenance windows.
Kind regards,
Serge Caron
De : Christopher Cook ***@***.***>
Envoyé : 16 mars 2021 22:26
À : webprofusion/certify ***@***.***>
Cc : Serge Caron ***@***.***>; Mention ***@***.***>
Objet : Re: [webprofusion/certify] Windows Server Essentials 2016 Access Anywhere Certificate renewal script (#519)
Thanks for the detailed analysis @SergeCaron<https://github.com/SergeCaron> I really do think you should raise this directly with Microsoft for a support escalation, linking them to this github issue. Rebooting the server isn't really a solution and only Microsoft can really investigate this in detail.
Technically the issue is not with Certify because you already have your certificate. Although this is an interesting topic, the point at which we stop providing direct support (with the exception of IIS website bindings) is when you have the certificate then want to use it with another service (there are of course thousands of ways to use a certificate and they all have their own interesting problems). We try to provide the basic mechanism for you to apply certificates automatically but we don't directly support issues with individual services (because we don't have domain knowledge for every service).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#519 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQROU4D3NYZQLR3BRWO7BJDTEAHMZANCNFSM4PYY2OMQ>.
|
I see various complaints regarding WSE 2016 and certificate renewals.
I have been using the script below for years without issues. You have to be patient it takes at least two minutes for everything to restart but it does work.
Regards,
Enable certificate for RDP Gateway
param($result)
Import-Module RemoteDesktopServices
Apply certificate
Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop
Restart Network Policy Server, TSGateway, and SSTP Protocol
Restart-Service IAS -Force -ErrorAction Stop
Restart-Service TSGateway -Force -ErrorAction Stop
Restart-Service SSTPSvc -Force -ErrorAction Stop
Write-Host "Done!"
The text was updated successfully, but these errors were encountered: