In Part 1, and Part 2 of this series we have covered the migration from ADFS v3 to ADFS 2016. In part 3 we have discussed the integration of Azure MFA with ADFS 2016, and in this post (technically part 4) we will cover the migration or better yet upgrade WAP 2012 R2 to WAP 2016.
Again, this blog assumes you already have installed the Web Application Proxy feature while adding the Remote Access role. And have prepared the WAP server to be able to establish a trust with the Federation Service.
In addition, a friendly reminder once again that the domain name and federation service name have changed from swayit.com.au to iknowtech.com.au. The certificate of swayit.com.au expired before completing the lab, hence the change.
Before we begin however, the current WAP servers (WAP01, WAP02) are the only connected servers that are part of the cluster:
To install the WebApplicationProxy, run the following cmdlet in PowerShell:
[code language=”PowerShell”]Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools[/code]
Once installed, follow these steps:
Step 1: Specify the federation service name, and provide the local Administrator account for your ADFS server.
Step2: Select your certificate
Step 3: Confirm the Configuration
Do this for both the WAP servers you’re adding to the cluster.
Alternatively, you could do so via PowerShell:
[code language=”PowerShell”]
$credential = Get-Credential
Install-WebApplicationProxy -FederationServiceName "sts.swayit.com.au" -FederationServiceTrustCredential $credential -CertificateThumbprint "071E6FD450A9D10FEB42C77F75AC3FD16F4ADD5F" [/code]
Once complete, the WAP servers will be added to the cluster.
Run the following cmdlet to get the WebApplication Configuration:
[code language=”PowerShell”]Get-WebApplicationProxyConfiguration[/code]
You will notice that we now have all four WAP servers in the ConnectedServersName and are part of the cluster.
You will also notice that the ConfigurationVersion is Windows Server 2012 R2. Which we will need to upgrade to Windows Server 2016.
Head back to the one of the previous WAP servers running in Windows Server 2012 R2, and run the following cmdlet to remove the old servers from the cluster, and keep only the WAP 2016 Servers:
[code language=”PowerShell”] Set-WebApplicationProxyConfiguration -ConnectedServersName WAP03, WAP04 [/code]
Once complete, check the WebApplicationProxyConfiguration by running the Get-WebApplicationProxyConfiguration cmdlet.
Notice the change in the ConnectServersName (this information is obtained from WAP Server 2012 R2).
If you run the Get-WebApplicationProxyConfiguration from WAP 2016, you will get a more detailed information.
The last remaining step before publishing a Web Application (in my case) was to upgrade the ConfigurationVersion, as it was still in Windows Server 2012 R2 mode.
If you already have published Web Application, you can do this any time.
[code language=”PowerShell”]Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion[/code]
When successful, check again your WebApplicationProxyConfiguration by running
[code language=”PowerShell”]Get-WebApplicationProxyConfiguration[/code]
Notice the ConfigurationVersion:
You have now completed the upgrade and migration of your Web Application Proxy servers.
If this is a new deployment, of course you don’t need to go through this whole process. You WAP 2016 servers would already be in a Windows Server 2016 ConfigurationVersion.
Assuming this was a new deployment or if you simply need to publish a new Web Application, continue reading and follow the steps below.
Publishing a Web Application
There’s nothing new or different in publishing a Web Application in WAP 2016. It’s pretty similar to WAP 2012 R2. The only addition Microsoft added, is a redirection from HTTP to HTTPS.
Steps 1: Publishing a New Web Application
Step 2: Once complete, it will appear on the published Web Applications. Also notice that we only have WAP03, and WAP04 as the only WAP servers in the cluster as we have previously remove WAP01 and WAP02 running Windows Server 2012 R2.
There you have it, you have now upgraded your WAP servers that were previously running WAP 2012 R2 to WAP 2016.
By now, you have completed migrating from ADFS v3 to ADFS 2016, integrated Azure MFA with ADFS 2016, and upgraded WAP 2012 R2 to WAP 2016. No additional configuration is required, we have reached the end of our series, and this concludes the migration and upgrade of your SSO environment.
I hope you’ve enjoyed those posts and found them helpful. For any feedback or questions, please leave a comment below.