Tuesday, October 30, 2018

Exchange 2010 > 2016 migration - Part 1

In this next series of blog posts, I will migrate from Exchange 2010 SP3 (RU24) to Exchange 2016 CU11 (or maintain a hybrid 2010-2016 environment for a while - TBD). I have experimented with many Exchange 2016 features in previous blog posts but this is the first time I will perform a migration to this version of Exchange from a previous version.

Scope of the operation

In this first post of the series, I will install prerequisites and update the schema and domain. For the time being, I only have a single Windows 2016 / Exchange 2016 server and I will not configure a DAG. In reality, we would most likely require some level of redundancy. We have a small test environment with only one "real" user (myself) so hardware requirements will be minimal. In reality, we may want to determine the exact level of necessary resources with the Exchange Server Role Requirements Calculator:

 Exchange Server Role Requirements Calculator

Otherwise, even with several dozen users, minimal requirements may suffice. These requirements can be found here and I have already presented them in previous blog posts:

I'll only summarize some of the more notable criteria:
  • 8 GB of RAM - minimal for the mailbox role (the only remaining role - not counting the optional and rarely (?) used Edge Transport role).
  • Domain controller OS, DFL and FFL: 2008 R2 minimum.
  • Exchange Server OS: Windows 2012, 2012 R2 or 2016 (possibly 2019 in the future).

  • Exchange 2016 CU10 and above requires .NET Framework 4.7.1 minimum.
  • We no longer install stand-alone versions of WMF but use only the version built in the Windows OS.
  • The most significant change is the addition of Visual C++ Redistributable Packages for Visual Studio 2013 as a prerequisite (since Exchange 2016 CU10 - June 1, 2018).

Schema upgrade

I will perform the schema/domain upgrade on the future Exchange server where I have already downloaded the necessary files.

We need the following to update the schema:
  • .NET Framework 4.7.1
  • C++ Redistributable Packages (this is in the latest list of prequisites although I was able to upgrade the schema before installing it).
  • Remote Tools administration pack

I would suggest a search online to locate and download the first two installation files. As for the third, we can install it with this command: 

Install-WindowsFeature RSAT-ADDS

We then upgrade the schema with these commands (we navigate to the Exchange setup files where setup.exe can be found):

setup /ps /IAcceptExchangeServerLicenseTerms

setup /p /IAcceptExchangeServerLicenseTerms

If we have only one domain, those two commands are enough. Otherwise, further details can be found here:


Next, we install the prequisites for Exchange 2016 CU11 (on Windows Server 2016).

We install the following Windows features with the Install-WindowsFeature cmdlet:

Install-WindowsFeature NET-Framework-45-Features, Server-Media-Foundation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

Note: yes, you can copy and paste rather than retype.

And then the following software (we already installed those mentioned above for the schema upgrade):
  • .NET Framework 4.7.1
  • Microsoft Knowledge Base article KB3206632
  • Visual C++ Redistributable Packages for Visual Studio 2013
  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

Note: we can download KB3206632 here:


More details here:

December 13, 2016 — KB3206632

We can also see if it is already installed with this command:

wmic qfe | find “3206632”

In my case, when I attempted to install this update, a message appeared, indicating it was already installed:

Otherwise, I will not illustrate the step-by-step installation of the software above. It is usually a matter of running an installer that someone managing an Exchange server should be able to handle.

In my next blog post, I will present the installation of Exchange 2016 (CU11) itself.


Of course, this is not the first blog post about a migration to Exchange 2016. In the past, I have consulted other sources, in particular (and besides Microsoft documentation), Paul Cunningham's PluralSight course on Exchange 2016:


The environment used in this course is somewhat different, with a combination of Exchange 2010, 2013 and 2016, and does not incorporate a load balancer, which will make a difference when we adjust client access settings. Also, some time has passed since the creation of the videos and some of the information is naturally out of date. For example, the minimal .NET version for the latest versions of Exchange 2016 (CU10, CU11, etc.) has changed and more notably Windows Server 2016 was not a supported OS for Exchange 2016 at the time.

Thursday, October 25, 2018

w32tm - the /reliable switch and a review of some other useful commands

In previous blog posts, I've configured Windows Time to sync with an outside source which is the typical configuration on the domain controller holding the PDCe role (primary domain controller emulator).

This one, for example (in French):

Active Directory - NTP et la synchronisation horaire

The command most often used (with possible variations) is the following:

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual

Some sources have us add two additional parameters at the end:

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual /reliable:yes /update

What is the difference? Apparently, when we add the /reliable parameter, that explicitly defines the domain controller as a "good" or "trustworthy" time source. This distinction is observable if we execute the following nltest command:

nltest /dnsgetdc:<domain_name>

For example, if my domain is called "mynet.lan", I would use "mynet" (with or without .lan):

nltest /dnsgetdc:mynet

One of the flags is TIMESERV which is common to all domain controllers.

This is the output on DC2 which is not the PDCe. Observe that it does not have the PDC flag:

This is the output on DC1 which is the PDCe. Both the PDC and TIMESERV flags are present:

If my sources are accurate (and if I understood correctly...) we could define one domain controller as a "good" time source with the bitwise mask 0x4 or with the /reliable switch. The flag would then be GTIMESERV.

Since this flag is not present (even on the PDCe), I must conclude that I did not use the /reliable switch when time services were configured for the first time. If I execute the command with the /reliable switch (please see above), resync and restart the w32time service, the GTIMESERV flag replaces the usual TIMESERV flag:

So the complete sequence of commands would be:

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual /reliable:yes /update

w32tm /resync /rediscover

net stop w32time
net start w32time

Or if you prefer (for the service restart):

net stop w32time && net start w32time

Or with PowerShell:

Restart-Service w32time

Note: keep in mind that this is the recommended sequence for configuring time services on a PDCe with or without the reliable switch. It may not be necessary to restart the w32time service if we use the /update switch, as I have seen it presented as an alternative to that operation, for example (executed separately):

w32tm /config /update

To be honest, I was surprised to see the GTIMESERV flag appear because one source claims that with the 0x8 bitwise mask:

"0x08 will cause the service to automatically advertise as reliable when the DC is a) the PDC in the root domain of the forest, and b) when it is unable to locate a time source. The reason for this flag is to allow the root domain PDC to self-elect as the authoritative time source for the forest, allowing all other DCs to use it for time."

To be (reliable) or not to be (reliable)

I am quite sure the time source was available because (as you can see in the screenshot above) the command completed successfully and I know from experience that there is an error when it is inaccessible. Since the article is ten years old, behavior may have changed (I am using Windows 2016 domain controllers).

I also read that if we move the PDCe role, it is preferable to designate the new role holder as a reliable time source before we transfer the role itself. We should also remember to configure the former PDCe (if it remains an active domain controller) to sync from the new PDCe rather than the external time source:

w32tm /config /syncfromflags:domhier /update

Some sources add the /reliable switch here as well but in this case with the value "no":

w32tm /config /syncfromflags:domhier /reliable:no /update

We would also execute the resync/rediscover command shown earlier and restart the time service.

Other useful commands

The following commands allow us to view the time source, configuration, or determine the difference in time between two domain controllers.

w32tm /query /source

This command shows the time source for the server in question.

On a member server (or workstation), it would be the authenticating domain controller, for example:


On the PDCe configured to sync with an external source, we would see something like this:



w32tm /query /configuration

This command shows many parameters such as:

Type: NT5DS (Local)

This would be the expected (and correct) type for the domain controllers that are NOT the PDCe.

For the PDCe (if configured to sync with an external time clock), it would be:

Type: NTP (Local)


w32tm /monitor

This command indicates the time source of the computer as well as some delay and offset information. In the screenshot below, I run the command on the domain controller with the PDCe role (DC1), configured to sync with an external source. Notice the reference to port 123 toward the end of the second line (NTP uses port 123). In the following line, ICMP indicates the ping delay (0ms) on the local machine and the offset (several zeros on the local computer and -0,5099100 on DC2, compared to DC1). The RefID shows the source: DC1 for DC2 and a NIST time server for DC1:


w32tm /stripchart /computer:DC1 /samples:5

This command (with the /stripchart switch) allows us to evaluate the difference in time between two computers. On the local computer, we indicate the remote computer and then the number of samples to be taken. The result of a single sample will look like this:

14:10:21, d:+00.0002071s o:+00.0000310s

We have the local time (14:10), the delay (d) between the sending and receiving of UDP packets and then the offset (o) between the two computers. The offset can be positive or negative (the local computer time can be ahead or behind). In the exemple above, the offset is practically non-existent. In the example below, the difference is much more important but still only to the tenth of a second:

w32tm /tz

Last of all, we can see the time zone at the command line with this command.

Other sources:

NTP and Reliable Time Sources in a Windows Active Directory Environment

Configuring the Windows Time Service in an Active Directory Forest – A step by step with a Contingency Plan