Exchange 2016 on Server 2016 – A reboot from a previous installation is pending

Recently I was attempting to install Exchange 2016 on Server 2016. On attempting to run the setup.exe /preparealldomains /iacceptexchangeserverlicenseterms command, I was receiving a failure when checking prerequisites which stated that:

PS E:\> .\Setup.EXE /preparealldomains /iacceptexchangeserverlicenseterms

Performing Microsoft Exchange Server Prerequisite Check

Prerequisite Analysis FAILED

A reboot from a previous installation is pending. Please restart the system and then rerun Setup.
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.RebootPending.asp

I had rebooted the server a few times and ensured that no restarts were pending.

In versions of Server prior to Server 2016, I would be looking for the UpdateExeVolatile registry key and the PendingFileRenameOperations registry key under HKEY Local Machine. However these didn’t appear to be in their normal place. Eventually I did a search of the Registry and discovered that PendingFileRenameOperations has moved to:

HKLM\System\ControlSet001\Control\Session Manager\PendingFileRenameOperations

The previous location of this key was:

HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Removing the entries in PendingFileRenameOperations resolved the problem in this case.

 

DNS Traffic Management Policies

This awesome new Server 2016 feature can be used to create a DNS policy which responds to a query for the IP address of a web server with a different IP address based on the source subnet of the client.

Let’s take an example; we have ADFS configured in Azure using the following settings:

Hostname: sts.misstech.co.uk
Internal IP: 192.168.9.11
External IP: 57.119.128.179 (this is made up so don’t try and go there!)

There are 2 sites, London and Manchester. London has a VPN link to Azure, however Manchester has no route to Azure. Both sites are connected to each other and the Domain Controller is located in London.

This means that London users (on 192.168.10.0/24) can access ADFS, however Manchester users (on 192.168.11.0/24) cannot access ADFS using the internal IP. We need to route Manchester users to ADFS via the external ADFS IP, but how to do this when they are resolving DNS records via the same Domain Controller? Host files can do this but that is complex and doesn’t allow for mobility. Enter Traffic Management using Server 2016.

To do this, the following steps need to do performed.

·       First, add the subnets which you want to use for traffic management.

AddDnsServerClientSubnet Name “Manchester” IPv4Subnet “192.168.11.0/24” PassThru

·       Next, add the subnet associated zone. The zone must already exist for this command to work.

Add-DnsServerZoneScope -ZoneName “eacsdemo.online” -Name “Manchester” -PassThru

·       Add the DNS Resource Record

Add-DnsServerResourceRecord -ZoneName “eacsdemo.online” -A -Name “sts” -IPv4Address “52.169.178.129” -ZoneScope “Manchester” -PassThru

·       Add the Traffic Management Policy to route Manchester requests through to

Add-DnsServerQueryResolutionPolicy -Name “ManchesterPolicy” -Action ALLOW -ClientSubnet “eq,Manchester” -ZoneScope “Manchester,1” -ZoneName “eacsdemo.online” -PassThru

These policies are very versatile, allowing you to combine multiple parameters (using AND/OR) such as client subnet, protocol, or time of day to create complex policies which can help you direct clients to the correct location.

I’ll finish this post with a small tip; if you want to remove or get the policy, make sure you specify the zone name or a null value will be returned. For example:

Get-DnsServerQueryResolutionPolicy -ZoneName “misstech.co.uk” -PassThru

remove-DnsServerQueryResolutionPolicy -ZoneName “misstech.co.uk” -PassThru