Sunday, July 26, 2015

Exchange 2016 (Preview) - Preparation and Installation

Last week, the release of Exchange 2016 (preview version) was announced:

Announcing Exchange Server 2016 Preview!

Microsoft has provided documentation on the latest version of Exchange here:

Exchange Server 2016

IMPORTANT: this release is for evaluation only. Do not attempt to install it in a production environment and start a migration to Exchange 2016!

In the following lines, I will summarize some of the most important pre-requisites, leaving the reader free to consult the documentation indicated above for further detail, and then attempt to install Exchange 2016.


Here are the various requirements for Exchange 2016:


(This is for the server on which Exchange 2016 will be installed)

  • x64 processor - no GHz specified so probably any new (or recent) server.
  • 8 GB RAM for the Mailbox role (4 GB for Edge role).
  • Paging File - recommendation is still physical RAM plus 10 MB (maximum 32 GB).
  • Disk space: 30 GB (with several hundred extra MB for various purposes). This is for the Exchange install and does not count size of mailbox databases. 

Operating system (for the Exchange 2016 server)

  • Windows 2012 or 2012 R2 (Standard or DataCenter)
  • Management Tools can be installed on the above server OS and on Windows 8.1

Note: Windows 10 is not mentioned but, because of the limited presence of Windows 8.x in the corporate world, and the probable (direct) migration path of Windows 7 to Windows 10, it would seem to make sense that Windows 10 be supported in the near future.

Active Directory

  • Forest Functional Level  - Windows 2008 or above.
This means all the domain controllers must have Windows 2008 (Standard, Enterprise or Data Center) as the operating system (or higher).

Other notes:
  • Do not install Exchange 2016 on a domain controller. It is not clear if this will be discouraged (but supported as in previous versions) or not supported at all.
  • Do not disable IPv4. Sooner or later we will have IPv6-only networks but this is not supported at this time.

Coexistence with previous versions of Exchange

Unless you have avoided using email for the last 20 some years, you probably already have some system in place. Besides Office 365 in a hybrid deployment, Exchange 2016 can coexist with:

  • Exchange 2010 SP3 RU9 (some sources state RU10)
  • Exchange 2013 CU8 (some sources state CU9)
So, coexistence is not possible with earlier version of Exchange (2003 or 2007).

Preview supports co-existence with Exchange Server 2010 SP3 RU10 and 2013 CU9


Preparation for Exchange 2016 install

Before we install Exchange 2016, we must upgrade the Active Directory schema (and domain), then install a number of pre-requisites and Windows features. This should be familiar to Exchange administrators who have installed Exchange 2010 or Exchange 2013.

Active Directory upgrade operations

First, I will upgrade the Active Directory schema. This is also known as a "schema extension". In substance, it adds Exchange (2016) objects and properties to the Active Directory schema. For this operation, I must be a member of the "Schema Administrators" security group. Verify this if you are not certain.

I have downloaded and extracted the Exchange 2016 installation files on my Windows 2012 R2 server named SVR5. I can perform the schema upgrade from the (future) Exchange server provided that I have network connectivity to the schema master (this is domain controller holding the "schema master" operations master role - also known as a "FSMO" role).

In this case, I have to install the RSAT tools for Active Directory Domain Services. Otherwise, this message will display:

"The Windows component RSAT-ADDS-Tools is not installed on this computer and needs to be installed before Exchange setup can begin."

It is a simple matter to resolve this error. All we need to do is install the feature in question (click to enlarge):

Install-WindowsFeature RSAT-ADDS

Note: as long as the feature name is not ambiguous, we can simple enter (in this case) "RSAT-ADDS".

Note: if we copied all the install files to the schema master itself, we would not have to install the RSAT tools - since we are on the domain controller itself.

So, having added the RSAT ADDS tools,  I navigate to the location of the Exchange 2016 setup file...

 and execute the following command (click to enlarge):

setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Next, we prepare "Active Directory" (as if the schema was not part of Active Directory...) with the following command:

setup.exe /PrepareAD /OrganizationName:MYNET /IAcceptExchangeServerLicenseTerms

Note: if we installed Exchange 2016 in an existing Exchange environment, we would not have to specify the organization name.

Note: this operation requires membership in the Enterprise Admins security group.

Note: in a single forest/domain environment, we do not have to prepare the domain separately with additional commands. 

Installation of Windows Features

Next, we install several Windows features with the following command:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, 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

Note: we can copy and paste from the Microsoft Technet article referenced above (or from my blog post). No need to type the names of all the above features manually!

Installation of pre-requisite software.

We then install the following two software items:

  1. .NET Framework 4.5.2
  2. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

In my situation, .NET 4.5.2 was already installed on both the domain controller and the future Exchange server when I installed Windows updates. So I only need to install "UCMA":

Unified Communications Managed API 4.0 Runtime

We simply download the file and execute it, which results in something like this:


Now I will install Exchange 2016 (preview) on a Windows 2012 R2 server. The domain controller of this test environment has Windows 2008 R2 for the operating system. All of the most recent Windows updates (at this time) have been installed on both servers, including .NET 4.5.2.

I will install the mailbox server role which is the only remaining role of the former Exchange 2010 three-role Client Access - Hub Transport - Mailbox triad.


First, I execute the setup.exe file that we used earlier to upgrade Active Directory. This time, I simply double-click on it. The first screen prompts us to "Check for Updates". I opted to check for updates later (yes. even though the first option is selected in my screenshot):

Note: we click "Next" on each screen as needed.

Setup copies files...

And we can read the introduction to Exchange 2016:

We accept the license agreement (if we want to continue):

We select some settings here for feedback to Microsoft:

We then select the server role. As mentioned earlier, of the previous Cleint Access, Hub Transport and Mailbox roles, only the Mailbox role remains (besides the optional Edge role which would be installed in a DMZ):

We select the location where Exchange 2016 will be installed. For this first look at the product, I'll simply install it on the C: drive with the Windows 2012 R2 operating system:

We can enable malware protection if we do not have another product for this purpose or disable it in the opposite scenario:

Setup then performs a Readiness Check which fails. As sometimes encountered with earlier versions of Exchange, notably 2013, we are informed that a reboot from a previous installation is pending. Like others (you'll see what I mean if you search for this problem online - Exchange 2013), I rebooted several times with no result:

Here is an example of a conversation on this problem:


Since this is only a first look at the product (and I was becoming impatient) I finally deleted the values (there were two) in this registry key:


Even then, I had to reboot once more to continue.

Note: in this article (below) Microsoft recommends that we do NOT delete registry items. If this were a production server, I would have  been more inclined to respect that recommendation. In this situation, I'm more interested in having a first look at the product and not willing to pay MS $499 (yes, it's $499 now) for technical assistance.

The computer needs to be restarted before Setup can continue

Finally, I can proceed (the message below is informative and will not block the installation):

Setup progesses. Notice that the former Client Access role is now installed as a simple service (this is also true for the former Hub Transport and Unified Messaging roles):

If all goes well, we should see this screen at the end:

But how do I open the EAC (Exchange Administration Console) or EMS (Exchange Management Shell) after installation? On a Windows 2012 (R2) server, we can find the Exchange icons among the other "Apps":

Comments - and problems encountered

After several attempts to open Exchange 2016 with less than the recommended 8 GB of RAM (2 GB, then 4 GB), I allocated the full 8 GB to my virtual machine. So, instead of error messages like this (System.OutofMemoryException):

I was able to open the EMS and execute various commands, for example:

[PS] C:\>Test-ServiceHealth

After triggering the start of the WinRM service with the Test-WsMan cmdlet, I was able to obtain the result of "True" (for all necessary services running) although I had to wait a while for the "MSExchangeDelivery" service.

As the reader can see, I was able to open the EMS and execute some commands. On the other hand, I was never able to open the EAC. Besides the expected certificate error...

This error prevented me from using the EAC:

That is where I stopped for the time being.

Saturday, July 18, 2015

Windows Server 2012 R2 - Hyper-V - a look at VHD features (Part 3) - Pass-Through Disks

In my two previous posts, I examined some aspects of Hyper-V virtual disks which are essentially a file with a .vhd or .vhdx extension and can be moved from server to server (manually or using methods such as Live Migration). Operating systems installed on virtual disks constitute virtual machines (along with other "ingredients") and, being able to move from host to host,  enjoy a great deal of flexibility.

Another scenario is possible and in which a virtual machine accesses a "raw" or physical hard disk directly. There are only two reasons I am dedicating a blog post to this option. First, I have seen it addressed in test prep documentation for Microsoft certification exams. It may be useful to know something about it. Second, it is the subject of a discussion among Hyper-V users: should we use pass-through disks? Aidan Finn, Hyper-V MVP and noted author on the subject, is a critic of the pass-through disk option:

Aidan Finn blog - comments on passthrough disks

Two remarks:
  • I have seen the term written both with and without a dash.
  • Aidan refers the reader to other experts who recommend against the use of pass-through disks. There is also a discussion on the subject in the comment section.
At this point, I suppose I could end this blog post with a simple recommendation on pass-through disk use:

Just don't do it!

But just what is a pass-through disk (you may not know, after all) and how would we configure one if we had to (for a certification exam of course...).


A pass-through disk is a physical hard drive to which the virtual machine has exclusive access.

It is an entire physical hard disk (not virtual) and not just part of a physical disk (partition or volume).

Why would we even think about using a pass-through disk?

The pass-through disk is supposed to provide better performance, unhindered by the overheard of virtualization.

However, critics of the pass-through disk would argue that performance is not significantly better than that of a virtual fixed disk.

Why would we opt against using pass-through disks?

We loose the flexibility of migration from host to host (not impossible but not optimal either) and cannot use checkpoints (snapshots in VMware language).

The use of pass-through disks assumes an already existing virtual machine (guest). It is inside this virtual machine that we will add the pass-through disk.

The primary pre-requisite is the existence of a physical disk that is offline

Note: this is the view of the physical disks available on the host server (above). Disk 0 is online and besides the operating system hosts a virtual machine on the F: drive. We will start this virtual machine and add Disk 1 as a pass-through disk.

In my case, the disk in question is a SCSI (in fact SAS) disk so, when we open the properties of our virtual machine (Svr5), we must select the SCSI controller and then, in the right pane, click on the "Add" button:

Now, in Disk Management (but in the virtual machine, not the host), we must put the disk in the "online" state:

At this point, we create a volume as we would with a physical disk (which is, in fact, what we have, but managed from inside the virtual machine). A "Simple Volume" will suffice for this demonstration:

We configure the disk as we normally would (following screenshots):

This is the result in Disk Management:

And this is what we see in My Computer (or File Explorer):

So, from the guest operating system, the pass-through disk appears just like any other disk.

Thursday, July 16, 2015

Windows Server 2012 R2 - Hyper-V - a look at VHD features (Part 2)

Now that we have created a virtual disk and created a virtual machine (please see my previous blog post), I will examine some aspects of virtual disk management.

First of all, how can I view the characteristics of a virtual hard disk (or "VHD")? This will be very useful later in the post when we attempt to resize a disk and want to verify the results. We can view the properties of a VHD with the "Inspect" option. We open Hyper-V Manager, open the properties of the virtual machine (Svr5 in this case), highlight the virtual disk (or hard drive) that interests us and finally, in the right pane, click on "Inspect":

We can now see (above) the format, type, location, name and size of our virtual disk.

We can also select the "Inspect Disk" option at the host level. It would then be necessary to locate the virtual disk in question:

Here is where we locate it:

At this time, my virtual machine is running (it's "live") and apparently that does not leave me with many configuration options:

At most, we can expand the virtual disk:

For example, we could increase the size to 56 GB (which I will not actually do at this point):

Note: this is with a "Fixed Size" disk and with a live operating system. In the following lines, we will have a look at other combinations.

Now I will turn the virtual machine (VM) off, repeat the process above and see if we have more options:

Well, now it looks like I can convert the virtual disk to another type or another format.

Important: read the description in the screenshot above carefully. Print too small? You can click on the image to enlarge.

When we convert a VHD, Hyper-V does not adjust a parameter in the virtual disk properties that changes its nature. Instead, Hyper-V will copy the entire contents comprising the virtual disk and essentially create a new copy with (possibly) different parameters. This means that we must have sufficient space on the physical media where we are storing the VHD files.

I'll select the "Expand" option and we'll increase the size of the disk to 60 GB:

The virtual disk size is increased:

Now if we look at our options again, we see that there is now a third option: Shrink

Note that, while we can indeed shrink the virtual disk, we cannot shrink it to less than its original size (in this case, 48 GB):

So, to summarize our experiments so far, we can both expand and shrink a fixed disk when it is offline (when the OS installed on it is not running). However, while we can shrink a virtual disk that was expanded, we cannot shrink to less than its original size.


Next I will convert the virtual disk from fixed size to dynamically expanding.

I could convert the disk format from VHDX to VHD but there is no reason to do so (unless I have to use the VHD with a legacy version of Hyper-V, that is, before Windows 2012). So I will keep the VHDX format...

As for the type, I will convert it from fixed size to dynamically expanding:

Conversion implies the creation of a brand new disk so we need to select a location for the converted disk with sufficient space for the file:

This is the summary of the operation:

Note the advantage in storage use below. The original 48 GB disk consumed an equal amount of space on the E: drive while the converted dynamically expanding drive only consumes about 9 GB of space on the F: drive, roughly the size of a fresh Windows 2012 installation (before updates or addition of roles and features):

Now I will attempt a compact operation. As we add programs and files to the expanding disk it will increase in size. If I later delete these programs and files, the disk will not automatically decrease in size. However, I can compact the virtual disk so it reverts back to its original size. For this demonstration, I will start with a virtual disk that consumes 8.85 GB:

After adding files, the size of the disk increases to almost 11 GB:

Here is another perspective:

Now I will delete the files.

In the properties of the C: drive, we see that the amount of used space has decreased to its original size (more or less):

However, the size of the virtual disk does not decrease at all:

Now let's try to compact the virtual disk while the disk is in use:

This is not possible (at least not on the virtual disk with the operating system):

Now I will turn off the virtual machine and attempt the operation again. This time, I am able to compact the virtual disk:

Likewise, we cannot convert a virtual disk when the virtual machine is running (the option does not appear):

But if we turn off the virtual machine, the option does appear:



By far, I have not tested all the features and options of virtual disk technology in Hyper-V. For example, I have not examined in this blog post differencing disks and checkpoints. On the other hand, I can draw the following conclusions:

  • We can resize a virtual disk (expand or shrink) if it is in the VHDX format.
  • It can be a fixed disk or a dynamically expanding disk.
  • However, the virtual disk must be offline.
  • We may not be able to shrink the virtual disk below its initial size (in my case, the size of the fixed disk before it was converted to dynamically expanding).
  • We can compact a virtual disk of the dynamically expanding type if it is in the VHDX format and offline.