[This blog posting was written with knowledge based on Windows Server 2016 TP4. Things may change in RTM.]
Some more investigations with ADFS in Windows Server 2016 TP4 – you have to start somewhere, right?
There are two ADFS servers that I mean to replace with two new ones on 2016 TP4, and then raise the farm behavior level. Easy enough – or so.
- Swap ADFS servers
- Use the Test-ADFSFarmBehaviorLevelRaise CMDlet to test the procedure
- Raise the ADFS Farm Behavior Level with Invoke-ADFSFarmBehaviorLevelRaise
The installation worked identical to installations with 2012 R2, when adding new nodes to an existing farm – in the end, there’s no difference between adding 2012 R2-based ADFS nodes to an existing farm or 2016-based nodes.
- join to the domain
- install the Service Communication cert on the new boxes
- install ADFS role
- add box to Load Balancer (probing will only activate it, when the service starts responding)
- join to ADFS farm
- Verify installation went good, event log is clean, WID replication worked
There is a CMDlet to test-run a farm behavior level raise. It will go through all the motions and verifications and – attempt to contact the ADFS servers to raise the behavior correctly. It’s called without parameters:
On my first attempt, it went through the tests and threw a number of errors back at me:
Okay, so what I gather is that the raise will do the following:
- Get the farm configuration from the primary ADFS node (WID)
- Check if the CMDlet is run on the primary ADFS node (WID)
- Contact all ADFS servers using the WinRM service to raise the farm level – implies that all ADFS servers are online and have WinRM configured
- Check if the Active Directory Schema is updated to Windows Server 2016
Fine, I can live with that. After some work on Active Directory to upgrade the Schema and enabling WinRM on all ADFS servers (I did a manual “winrm quickconfig” on the two boxes that I owned), another test-run was in order:
Looking better now. I feel confident to upgrade the farm behavior level now. Let’s get it going:
The CMDlet asks for confirmation – and I proudly answer “Y”.
Off it goes:
Notice the warning. Apparently there’s functionality in ADFS on Windows Server 2016 that requires that my ADFS Service Account is in the AD group “Enterprise Key Admins”. Sadly, the group didn’t exist by the time I executed the ADFS farm behavior.
The “Enterprise Key Admins” group will be created, when a Windows Server 2016-based Domain Controller assumes the PDC-E FSMO role. We’ve seen this with other groups before in previous OS versions, but it’s worth mentioning. The ADFS Service Account isn’t added to the group automatically after the raising, so I added it manually.
What the “Enterprise Key Admins” group is for – I don’t know. We’ll find out in another blog post.