Scenario: You want to upgrade your ADFS 2.0 or 2.1 farm using WID (Windows Internal Database) from Server 2008 R2 to Server 2012 R2. In this scenario, I have 2 ADFS servers (one as the primary and a second for failover purposes), and 2 ADFS Proxy servers (for load balancing/failover purposes).
NOTE: Prior to writing this article I had only found limited documentation provided by Microsoft on a proper upgrade path for this. Since then, it apperas that tools had been included with the Server 2012 installation media which will greatly cutdown on the number of steps needed as well as provide as little downtime as possible. I would highly recommend giving this article a read before proceeding with my article: http://blogs.technet.com/b/askpfeplat/archive/2014/03/31/how-to-build-your-adfs-lab-part4-upgrading-to-server-2012-r2.aspx
My article should still work, but it is definitely not the most efficient way to do an upgrade as pointed out in the technet article above. My guide essentially goes over cutting over to a completely new ADFS deployment "an upgrade", side-by-side to your production environment. As pointed out below, you cannot add a Server 2012 R2 machine to a Server 2008 R2 ADFS farm as documented in their earlier help articles.
Tutorial
- Login to one of your slave ADFS nodes (secondary server) running Server 2008 R2
- Remove the node from your load balancer
- Stop the AD FS 2.0 Windows Service
- Click Start -> Administrative Tools -> Internet Information Services (IIS) Manager
- Select your server and double click on Server Certificates
- Right click on your certificate and select Export...
- Export the certificate to your desktop, type in a password to protect the exported certificate/private key, and select OK
- Copy the pfx (exported certificate/private key) to your local machine; we will import this on our new server later.
- Disjoin the ADFS machine from the domain
- Turn the ADFS machine off and retire it
- Create a new Server 2012 R2 machine with the same name and IP as your Server 2008 R2 ADFS machine
- While the new ADFS machine is being created, login to one of your ADFS proxy servers
- Remove the proxy from your load balancer
- Stop the AD FS 2.0 Windows Service
- Turn the machine off and retire it
- Create a new Server 2012 R2 machine with the same name and IP as your Server 2008 R2 ADFS Proxy machine
- While the new ADFS proxy machine is being created, login to your new ADFS Server 2012 R2 machine.
- Open up Server Manage and select Manage -> Add Roles and Features
- On the Before You Begin screen, click Next >
- Select Role-based or feature-based installation and click Next >
- Select your server and click Next >
- Check Active Directory Federation Services and click Next >
- Click Next > on Features
- Click Next > on AD FS
- Click Install
- Click on the Configure the federation service on this server. link once the installation has completed successfully.
- Check Create the first federation server in a federation server farm on the Welcome screen for the Active Directory Federation Services Configuration Wizard and then click Next >
- Please see my notes below on why we did not check Create the first federation server in a federation server farm.
- Click Next > on the Connect to AD DS step
- Copy the .pfx file we exported from the ADFS server earlier to the new ADFS server
- On the Specify Service Properties screen, click on the Import... button
- Select your certificate and click Open
- Type in the password to the exported certificate and click OK
- Type in a Federation Service Display Name that will be shown to your users when they login to the ADFS service (this can be anything), and click Next >
- On the Specify Service Account screen, click the Select... button
- Type in the name of your service account you wish to use for ADFS, click the Check Names button to verify you don't have any typos, and click OK
- Type in the password for the ADFS service account and click Next >
- Click Next > on the Specify Configuration Database
- Note: I choose to continue to use WID, you can switch to SQL if you would like now, however that is outside of the scope of this document.
- Click Next > on the Review Options screen
- Click the Configure button once all the prerequsite checks have passed successfully
- Click Close once the server has successfully been configured
- Open up Internet Explorer on the new ADFS machine and navigate to https://localhost/adfs/ls/IdpInitiatedSignon.aspx to ensure the service is properly running
- Note: you should receive an invalid ssl certificate error; that is OK, we will switch the DNS records over once we are ready to transition from our old farm to the new one.
- Next, login to your Server 2008 R2 primary ADFS server and recreate the federation trusts on the new Server 2012 R2 primary ADFS server
- Start -> Administrative Tools -> AD FS 2.0 Management; select Trust Relationships -> Relying Party Trusts
- Recreate all the rules/trusts from your original ADFS server on your new Server 2012 R2 ADFS machine
- Note: If you are recreating rules for Office 365, you will need to wait until you switch over our new Server 2012 R2 environment to production. The reason is when you setup the new ADFS instance, some of the certificates will change causing a certificate mismatch/preventing your users from logging in. You will need to make sure you follow the following steps when resetting up the Office 365 trust to ensure your users don't receive "Error 80041317": http://support.microsoft.com/kb/2647020/en-us
- Login to your new ADFS Proxy server
- Import your SSL cerficate from your old ADFS server (from step 8) onto the server's Local Machine certificate store
- Right click on Start and select Run
- Type MMC and click OK
- Click File -> Add/Remove Snap-in...
- Select Certificates and click Add >
- Select Computer account and click Next >
- Select Finish
- Click OK on the Add or Remove Snap-ins screen
- Expand Certificates (Local Computer), select Personal, and right click, select All Tasks -> Import...
- Click Next on the Certificate Import Wizard
- Click the Browse... button
- Select your certificate and click Open
- Note: You may need to click on the dropdown box in the bottom right and select All Files for your pfx file to show up.
- Click Next on the File to Import screen
- Type in the password to the pfx file, check Mark this key as exportable, and click Next
- Ensure Place all certificates in the following store shows Personal and click Next
- Click Finish
- Click OK on the Certificate Import Wizard successful dialog box
- Right click on Start and select Run
- Edit the hosts file to point your DNS record to your new ADFS server
- Open Notepad as an Administrator
- Open the following file: C:\Windows\System32\drivers\etc\hosts
- Add in your DNS entry and point to your new ADFS server
- Save the file
- Note: We will come back to this later and update it to point to our load balancer once we switch over everything. For now, this lets us test our new deployment while switching things over.
- Open up Server Manager
- Click Manage -> Add Roles and Features
- Click Next > on the Before you begin screen
- Select Role-based or feature based installation and click Next >
- Select your server and click Next >
- Check Remote Access on the Server Roles screen
- Click Next > on the Features screen
- Click Next > on the Remote Access screen
- Check Web Application Proxy
- ClickAdd Features on the Add Roles and Features Wizard dialog box
- Click Next > on the Roles Services screen
- Click Install on the Confirmation screen
- Click on the Open the Web Application Proxy Wizard link once the installation succeeds
- Click Next > on the Welcome screen
- Type in the FQDN to your ADFS server, the credentials of an account with local admin privileges, and then click Next >
- Select your certificate on the AD FS Proxy Certificate screen and click Next >
- Click Configure on the Confirmation screen
- Click Close once the Web Application Proxy has been successfully configured.
- After you click close a new window should open. On the Remote Access Management Console, select Publish
- Click Next > on the Welcome screen
- Select Pass-through and click Next >
- Enter in a name, external URL, and internal URL for your federated server (mine were both the same since I use split-dns). Click Next >
- Click Close
- Add the new Server 2012 R2 ADFS machine to your load balancer and remove your Server 2008 R2 machine.
- Add the new Server 2012 R2 ADFS Proxy machine to your load balancer and remove your Server 2008 R2 proxy machine.
- Update the hosts file on your Server 2012 R2 proxy machine to point to your load balanced Server 2012 R2 ADFS environment
- Retire your Server 2008 R2 ADFS environment
- Disjoin the ADFS proxy server from the domain and recycle the machine
- Open up PowerShell as an Administrator
- Execute the following commands:
- Stop the service on your Server 2008 R2 ADFS machine running the old ADFS farm
- Execute the following command to remove the ADFS Farm info from AD (substituting in the information from the Get-AdfsProperties command):
- Disjoin the ADFS machine from the domain and recycle the machine
- Add a new Server 2012 R2 machine and WAP machine to your new ADFS environment for redudnancy (same steps as above, except in Step 27, you will select Add a federation server to federation server farm
Notes: Here is the upgrade compatibility matrix for upgrading ADFS from a specific version to Server 2012: http://technet.microsoft.com/en-us/library/jj647765.aspx
Why did I not check Add a federation server to a federation server farm on the Welcome screen for the Active Directory Federation Services Configuration Wizard?
The reason behind not checking this is I believe Microsoft has a bug in their discovery tool in adding another machine to a farm running ADFS 3.0. When adding a Server 2012 R2 machine to a farm with only Server 2008 R2 machines running ADFS 2.0, you will receive the following error:
The primary federation server was contacted successfully, but the configuration data was not valid. Ensure that the primary federation server is running Windows Server 2012 R2 or later. Unable to retrieve configuration from the primary server. The primary federation server was contacted successfully, but the configuration data was not valid. Ensure that the primary federation server is running Windows Server 2012 R2 or later. Prerequisites Check Completed One or more prerequisites failed. Please fix these issues and click "Rerun prerequisites check"
Symptom: You receive the following error while setting up the WAP (proxy) server:
An error occurred when attempting to establish a trust relationship with the federation service. Error: Not Found
Resolution: Make sure you update the DNS records of your ADFS deployment to point to your new ADFS server. Both the ADFS proxy and ADFS server must be running the same OS version (in this case, Server 2012 R2).
Hi!
In step 11. Why do I need to use the same IP-address and servername?
/Henrik
You are not required to use the same IP address and hostname as your previous server, this was documented as an asumption you wanted to upgrade your previous environment, keeping the deployment as similar as possible.
Jack
Pingback: ADFS 3.0 (on W2k12 R2) | Jacques DALBERA's IT world
Re: Step 42-2. If you have the Server 2012R2 media, navigate to the support folder, there is an ADFS folder within the support folder. In this folder that are powershell scripts (export-federationconfiguration.ps1 & import-federationconfiguration.ps1) which will allow you to export your federation configuration. This includes your token signing and token decrypting certs and all your trust configuration (RPT & CPT.)
Run the export script on your old ADFS2 server, then run the import on your new ADFS3 server. You will need to use the same federation name (sts.domainname.com) and ADFS service account. (as this data is migrated across in the federation configuration)
By doing this your Office 365 Relying party trust will work in a side by side configuration (and minimise your outage time.) So you can complete end to end testing of your ADFS 3.0 before cutting over your DNS records, making it live. Overall I have found this process much cleaner and painless in my experience 🙂
Hey Josh!
Really appreciate the response, had no idea the Server 2012 media had these powershell scripts. Great tip, much appreciated for sharing! 🙂
Jack
Hi ,
We like to " migrate" to ADFS 3.0 so I configured ADFS 3.0 on two servers with NLB succesfully and started to configure ADFS proxy.
Before we go live and change the DNS we like to set it up and do some testing using host files. which are in place.
Configuring the adfs proxy returns the following error event id 393.
---
The federation server proxy could not establish a trust with the Federation Service.
Additional Data
Exception details:
Unable to connect to the remote server
User Action
Ensure that the credentials being used to establish a trust between the federation server proxy and the Federation Service are valid and that the Federation Service can be reached.
----
Cerificates are in place but no bindings since ADFS 3.0 on server 2012 R2 is not using IIS.
The adfs account is in the local admin group of the on-premise server and ADFS service is also running under this account. I can ping all servers as well as de federated service name.
Do you have any idea what I'm missing or should check?
Kind regards,
Rogier
Hi Rogier,
There is a step where you need to enter credentials of a service account you created on the domain to communicate between the proxy and the ADFS server on your internal network. I would verify that the account is unlocked and the password has not expired. If both of those are true, you may need to uninstall the proxy role, reinstall it, and go through the wizard again to configure this account.
Hope this helps!
Jack
Hi Jack,
For some reason the NLB IP address I want to use was not in the firewall allow access list so that's why it couldn't configure adfsproxy.
Kind regards,
Rogier
Hi Jack,
The account is not locked and the password is also not expired.
The adfs service on the adfs domain server is running with this account as well.
I will uninstall and reinstall the adfs proxy role to see if it works.
Kind regards,
Rogier
Hi Jack,
One question regarding msolservice.
We have currently adfs2.0 running and federated our domain and the dirsync tool is installed on another 2008 R2 server.
The new adfs3.0 servers are installed and use a new SQL database/farm.
ADFS3.0 is having the same configuration, account and federated domain name as the current adfs2.0 servers.
Do you know if we still need to Update-MsolFederatedDomain -DomainName " or enable SSO on the for the adfs3.0 servers?
Kind regards,
Rogier
Hi Rogier,
If you change the website address of your federated server or certificates used to communicate between the Microsoft Online Services (Azure or Office 365), you will need to rerun the command.
Hope this helps,
Jack
Hi Jack,
All configuration we currently have on our ADFS 2.0 will be the same on the new ADFS 3.0 environment.
Only the new on premise and proxy server names for adfs 3.0 are different and we use of course another SQL server with the default database name.
We have separate server for dirsync and Microsoft Online assistant which we will keep running as it is now.
Our domain is already federated so I assume we don't have to do this.
But will it give problems if we run the command Update-MsolFederatedDomain etc again?
Our goal is that we only need to change ip address on the dns host (a) record when we switch over to ADFS 3.0.
I have just one more question about Web application Proxy and publish.
Do we need to publish?
If this is needed, can I just enter our federated domainname.com URL?
Kind regards,
Rogier
If you are only changing just the A record's IP address and not the certificate or FQDN, things should go fairly well. Just remember that it does take awhile for DNS to propagate on the internet, so there could be time where federation may not work because Microsoft's server hasn't pulled the new A record in. If you are using NAT, I would recommend using the same external IP address and just changing the firewall to point to your new internal server.
If you are talking about step 64 of my guide, yes you will need to hit the publish button.
Jack
Hi Jack,
Thanks for the info.
Yes we use NAT and will point the external IP to the new DMZ servers as well as the same certificate (service communication).
The IP address on the internal DNS host A record will be changed so that it point to the new ADFS servers (NLB).
Regarding publish do I use our federated.domainname.com URL?
Kind regards,
Rogier
Hi Jack,
I really appreciate your advice.
Thanks
Rogier
Yes
My client has 2 ADFS 2.0 servers, primary and secondary on 2008R2. They built a new datacenter, and want to have the ADFS servers relocated there, and want to go to 3.0 What i need clarity is,
If i install server 2012 with ADFS3.0, do i have to upgrade the production active directory schema to support 2012 server? ADPREP/FORESTPREP
If yes, we will not go that route.
So then can I download ADFS 2.1, and build 2 new ADSF servers on 2008R2, and install 2.1 on those, promote 1 to primary, then decommission the others. From what im reading, 2.1 is only available on 2012 server
ADFS 2.1 is integrated into the OS in Server 2012, so as you said, you will be unable to install it on a 2008 R2 box 🙁
I haven't personally tried, but I think you will be able to get away with adding a server 2012 r2 machine to a 2008 domain without extending the schema as long as you aren't doing device registration via ADFS.
Curious why your client wouldn't want to extend the schema? Extending the schema is much different than upgrading the forest or domain functional level. It mearly adds the attributes to AD to add the functionality.
Hope this helps!
Jack
On Monday, I will give 2012 a try, just as a domain joined server, no schema changes. I will follow your doc, and hopefully can get this all working. Of course I will keep you up to date if it works without schema changes.
Sounds good! Looking forward to hearing how it goes! 🙂
Hi,
I have a question. We have a client with a Server 2008R2 ADFS 2.0 installed (1 single server). We now want to upgrade to server 2012 ADFS 3.0. Is it possible to leave the 2008R2 intact but turn it off so that there is a cold copy when the new server gives some troubles. So there is Always 1 server from the clients site. When the new server is down we want to able to startup the old one, so that there is minimal user impact.
Thanks Willem
Hi Willem,
You could spin up a seperate instance and then just change the DNS records to point to the new ADFS farm. That would minimize downtime.
Additionally, you could try Josh's method in the comments above. That seems like a more efficient way on replacing an existing instance.
Jack
Is there any document which outline including Pros & Cons the steps to perform ADFS 3.0 migrations across multiple forest. There is a migration going on where 5 AD forest are getting merged to one and all the source forest has ADFS installed.
Any Blog for such senerio which can help me is appreciated
Will wait for response.
As long as a two-way transient trusts exists between the forests, ADFS 3.0 is smart enough to use domain suffix routing to be able to authenticate users from multiple forests. Otherwise, I'd look at deploying ADFS in each forest and federating each corresponding domain name to their corresponding endpoints.
Jack