I've already presented the prerequsites for an Exchange 2015 (SP1) installation in a previous post:
That was for a fresh install.
In the case of a migration (from Exchange 2007, for example), most of the steps are identical to what was presented in that post. Here are some additional notes for the installation of Exchange 2015 in an existing environment.
Prepare Active Directory
We still need to prepare Active Directory with the following commands:
PS C:\E2K13-SP1> .\setup /ps /IAcceptExchangeServerLicenseTerms
PS C:\E2K13-SP1> .\setup /p /IAcceptExchangeServerLicenseTerms
Now, I've just copied and pasted those commands without the slightest explanation!
Let's clarify some matters for those who might be doing this for the first time.
I performed a search for "Exchange 2015 SP1" and downloaded the (large) file in question. From this single file, I extracted the many installation files into the "E2K13-SP1" folder on my C: drive.
That's right: we need to download and extract the installation files for those commands to function.
Among the installation files, there is a setup.com file that can be used to install Exchange, from start to finish, or simply prepare Active Directory as a preliminary step. In this last case, the complete installation happens later.
That is the method I prefer: I prepare the environment step-by-step and can thus isolate any problems at a particular step.
If you have read the blog post referenced above, you will have seen that we have to type a period and then a backslash before the command itself:
.\
That is how Powershell functions when we execute a script or a setup file. If we omit the .\ combination, an error message will display.
The unabbreviated commands are:
setup /PrepareSchema
and
setup /PrepareAD
So why do I enter...
setup /ps
and
setup /p
???
These are simply the abbreviated forms of the command. Either set of commands will work.
These commands can be executed on the Exchange server itself provided that the domain controllers are accessible, the schema master FSMO role in particular. The user running the commands must be a member of the schema, enterprise and domain administrator groups.
As for the /IAcceptExchangeServerLicenseTerms parameter, this is new to Exchange 2015 and indicates that you accept the Exchange 2015 license terms.
So these commands should suffice but there could be particular circumstances in which we would want to designate a particular domain controller, for example. This Technet article explains some of these options as well as additional details on the points I have mentioned:
Prepare Active Directory and Domains (for Exchange 2015)
The article also outline the changes that the commands make, essentially extending the Active Directory schema with attributes necessary for Exchange 2015 and (if they do not already exist) creating various containers and groups in Active Directory.
The article also explains how the administrator can determine if the operations were successful. In my case, most of the groups already existed. As for the schema level, we can make a before-and-after comparison to verify the upgrade with the "ADSI Edit" tool (available in "Administration Tools" on a domain controller - or the Exchange server itself if RSAT for Active Directory is installed).
We open ADSI Edit, select the configuration naming context, and navigate to the location shown here:
The attribute to consider is "objectVersion". Before the schema upgrade, the number is 11222 which corresponds to Exchange 2007 SP3. After "setup /ps", we are at 15844 which corresponds to Exchange 2015 SP1:
At this point, then, Active Directory is prepared for Exchange 2015.
Install required Windows Features
Exchange 2015 requires a number of Windows Features. As the reader may already know, there are only two Exchange 2015 roles: Client Access and Mailbox. If we are only installing the Client Access or Mailbox role, we may not need all the roles below on a given server. Since I am going to install both the Mailbox and Client Access Server role on the same server, I will install all of the following features with the Add-WindowsFeature cmdlet:
Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, 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-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI
Note: unless you like to type, the best method to install these features is to copy and paste the text above into Powershell.
Install required software (other)
As mentioned in the blog post referenced above, there is almost nothing to install if we use Windows 2012 as the operating system on the (future) Exchange server. If that is the case, only the Unified Communications Managed API needs to be installed.
If we use Windows 2008 R2, we need to install all the software indicated below.
If we run the setup commands for Active Directory on the Exchange server, we will have to install the RSAT, .NET Framework and WMF 4.0 components before that step.
- .NET Framework 4.5
- Windows Management Framework (WMF) 4.0 - includes Powershell version 4
- Remote Server Administration Tools for Active Directory Domain Services (RSAT-ADDS)
- Microsoft Unified Communications Managed API (UCMA) 4.0, Core Runtime 64-bit
- Microsoft Knowledge Base article KB974405 (Windows Identity Foundation)
- Knowledge Base article KB2619234 (Enable the Association Cookie/GUID that is used by RPC over HTTP to also be used at the RPC layer in Windows 7 and in Windows Server 2008 R2)
- Knowledge Base article KB2533623 (Insecure library loading could allow remote code execution)
With one exception (assuming once again that we are using Windows 2008 R2), we need to download the items listed above and then execute the files in question to complete the installation. As for RSAT-ADDS, we can run the following command:
Add-WindowsFeature RSAT-ADDS
***
It is not absolutely necessary to follow the order presented above. We could, for example, install the other required software before the Windows Features. In fact, I tried this once and although everything functioned correctly at the end, there was at least one error message because one of the software items (the Unified Communications Managed API) required the Desktop Experience feature:
If we install the Windows Features first, there should be no error messages.
Based on my experience, I would add the future Exchange server to the domain before attempting the operations indicated above - and make sure that you are connected as a domain (and enterprise / schema) administrator, rather than the local server administrator. Occasionally, I'll see a conversation in the Technet forums where this was the source of some apparently inexplicable problem.
Once we have completed all the steps above, we should be ready to install Exchange 2015.
Almost ready... please read the next post of this series.
Almost ready... please read the next post of this series.
Thank you for reading the article about Exchange 2015 (SP1) - Migration - Part 2 - Preparing the environment (prerequisites) on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.