# Exchange 2013 Unattended Installation Script v1.1

Coming back from a nice vacation to the beautiful Brittany in France, I thought it was time to collect and process feedback and suggestions on several scripts, starting with the Exchange 2013 unattended installation script for Windows Server 2012.

Changes in version 1.1 of the script:

• When the script was used to also prepare Active Directory, RSAT-ADDS-Tools was uninstalled as part of the cleanup. Per request, I’ve removed the uninstallation of that feature;
• The script now detects pending reboots after installing the required features. When ran in AutoPilot mode, the script will reboot and restart the phase (preparing Active Directory, which can’t be run with pending reboots because Exchange’s Setup won’t like it). When not running in AutoPilot mode, you need to start the script manually. You can omit providing installation parameters as they are saved, even a pending is detected;
• The Windows feature Server-Media-Foundation will be installed explicitly as it is an UCMA 4.0 requirement;
• The credentials provided for AutoPilot mode will be validated;
• The OS version check is changed to a string which should enable installation on non-US Operating Systems.

You can download the updated version of the script via the original Exchange 2013 Unattended Installation Script page or directly from the Technet Gallery. Enjoy!

# Exchange v15 Unattended Installation Script (Updated)

Last version: 2.12, October 26th, 2015.

Note: The script has been renamed to Install-Exchange15 to indicate support for installation of Exchange 2013 as well as Exchange 2016, as the internal major version number is 15 for both.

I’m pleased to announce the availability of Install-Exchange15.ps1, a PowerShell script to perform a fully automated unattended setup of Exchange Server 2013 or Exchange Server 2016.

The script takes care of:

• Installing required Windows Server 2008 R2 SP1 / 2012 / 2012 R2 features;
• Install Exchange Server prerequisites (phase 2);
• Install additional prerequisites and prepare Active Directory (phase 3);
• Optionally install Exchange Server 2013 or Exchange Server 2016 (phase 4)
• Optionally, install required fixes and perform post configuration, like setting your Power Plan to High Performance and if your pagefile is set to System Managed it will reconfigure it to best practices (memory + 10MB with a maximum of 32GB+10MB). Custom post-configuration is possible by modifying the script.
• Finally, the script will clean things up, like removing the state file and setting the startup of Transport Service back to Automatic (phase 6).

Usage
This script version requires a domain-joined Windows Server, an account to perform the installation (and optionally prepare Active Directory) and the location where the Exchange Server 2013 installation files are stored (e.g. an UNC path).

The syntax is as follows:

Install-Exchange15.ps1 -[InstallCAS|InstallMailbox|InstallBoth] -SourcePath  [-Organization ] [-MDBName ] [-MDBDBPath ] [-MDBLogPath ] [-InstallPath ] [-TargetPath ] [-AutoPilot] [-Credentials ] [-NoSetup] [-IncludeFixes] [-InstallFilterPack] [-SCP] [-UseWMF3] [-Lock]

A short description of the parameters:

• Organization (optional): Specifies name of the Exchange organization to create. When omitted, the step to prepare Active Directory (PrepareAD) will be skipped.
• InstallMailbox: Specifies you want to install the Mailbox server role.
• InstallCAS: Specifies you want to install the CAS role.
• InstallMultiRole:Specifies you want to install both Mailbox server and CAS roles.
• MDBName (optional): Specifies name of the initially created database.
• MDBDBPath (optional): Specifies database path of the initially created database (requires MDBName).
• MDBLogPath (optional): Specifies log path of the initially created database (requires MDBName).
• InstallPath (optional): Specifies (temporary) location of where to store prerequisites, transcript and state file. Default location is C:\Install.
• NoSetup (optional): Specifies you don’t want to perform Exchange setup.
• SourcePath: Specifies location of the Exchange 2013 installation files (setup.exe).
• TargetPath: Specifies the location where to install the Exchange 2013.
• AutoPilot (switch): Specifies you want to automatically restart, logon using credentials specified and continue the installation. When not specified, you will need to restart, logon and start the script manually each time (without parameters).
• Credentials (optional): Specifies credentials to use for automatic logon. Use DOMAIN\User or user@domain. When not specified, you will be prompted to enter credentials.
• IncludeFixes (optional).  Depending on operating system and detected Exchange version to install, will download and install recommended hotfixes (e.g. KB2938053 or KB2997355).
• InstallFilterPack (optional). Adds installing Office filters for OneNote & Publisher support.
• UseWMF3 (optional) to install Windows Management Framework (WMF) 3 instead of WMF4 for Exchange 2013 SP1 or later.
• SCP (optional) allows you to reconfigure the Service Connection Point record for Autodiscover after Exchange setup has finished. Specify the full URI, e.g. https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Use $null to clear the SCP entries of the server. • Lock (optional) locks the system when running script. Note that the script uses an XML file to store the (original) parameters used to start the script but also to keep track of the the process. Of course, if required, you can use predefined XML files to run the script without parameters. Note that when not present, the script will try to download the prerequisites from the internet. When that isn’t possible or to save bandwidth, you can put them in the location defined by InstallPath and the script will detect and use them. The post-configuration is currently adding IFilters for OneNote and Publisher (Mailbox) only. There are comments in the script where to add your own additional post-configuration steps. For example, assume we want to start a fully unattended install of an Exchange Server 2013 Client Access server, using a network location for the Exchange Server 2013 source files. After setting the Execution Policy to Unrestricted and storing the script locally, we start the script using:  .\Install-Exchange15.ps1 –InstallCAS –SourcePath ‘\\server\share\isos\Microsoft\Exchange2013\mu_exchange_server_2013_x64_dvd_1112105’ –AutoPilot –Verbose The script will perform some checks and since AutoPilot was specified without using the Credentials parameter, the script will ask for credentials. After entering the credentials, the required features will be installed. Since OrganizationName wasn’t specified, Active Directory preparation will be skipped. After rebooting, the system will automatically log on using the credentials specified earlier and start the script (RunOnce registry key is utilized for this purpose). It will read the last known state from the XML file and will continue with the next phase, which is downloading (when not present) and installing the Exchange prerequisites. Next, after rebooting and the automatic logon, Exchange will be installed from the source location. When done, the system will perform post configuration and finalization steps. When running in AutoPilot mode, the system will automatically perform reboots and logons between the steps. Note that it may seem like a lot of reboots, but rebooting after installing Windows features and Exchange prerequisites is required anyway so I put reboots after the other milestones as well. Customization If you want to perform post-setup configuration of Exchange running Exchange cmdlets from the script, you need to tailor it to your needs. Locate the line which reads: #Load-ExchangeModule Uncomment this line so a proper Exchange Management Shell session will be set up to the local Exchange server. You can insert Exchange-related cmdlets after the Load-ExchangeModule line to configure your server. Be advised that you need to port modifications to new versions of the installation script. Feedback Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form. Download You can download Install-Exchange15.ps1 here from the Technet Gallery. Revision History See Technet Gallery page. # Exchange 2013 Preview: Prerequisites Note: This article is based on a pre-release product and may therefor be subject to changes. Yesterday, the Exchange team released the preview (you can also call this a public beta) of Microsoft Exchange Server 2013. The build version of the Exchange 2013 Preview is 15.0.466.10. You can download the 1,5GB self-extracting Exchange 2013 Preview here. Prior to installing Exchange 2013 preview, you need to install the following prerequisites depending on the targeted platform Note: Clicking the checkmark leads to the download.  Component Windows Server 2008 R2 SP1 Windows Server 2012 .NET Framework 4.5 RC Windows Management Framework 3.0 RC UCMA 4.0 Preview Office 2010 Filter Pack (Mbx) Office 2010 Filter Pack SP1 (Mbx) Windows Identity Foundation (KB974405) KB2619234 KB2533623 Note: When present, uninstall the Visual C++ 11 Beta Redistributable after installing the UCMA component. On Windows Server 2008 R2 SP1 you also need to register ASP.NET after uninstalling the VC++ 11 Beta Redistributable, before installing Exchange 2013, using: %SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable followed by an IISReset. Required Windows Features These cmdlets install the required Windows features:  Cmdlets Windows Server 2008 R2 SP1 Windows Server 2012 CAS Import-Module ServerManager; Install-WindowsFeature RSAT-ADDS; Install-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 Add-WindowsFeature RSAT-ADDS; Add-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, 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 MBX or CAS/MBX Import-Module ServerManager; Install-WindowsFeature RSAT-ADDS; Install-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 Add-WindowsFeature RSAT-ADDS; Add-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, 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 Firewall On Windows Server 2012, create an inbound firewall rule for port 139 when installing Client Access server. Active Directory Requirements Be advised that a minimum of 1 Windows Server 2008 Domain Controller and Global Catalog server is required in each site where you want to install Exchange 2013 Preview. Windows Server 2003 Forest Level is supported. After successfully preparing Active Directory for Exchange 2013, the schema version will be 15132, Forest version 15448 and the Domain version 13236. More information on how to verify those values here. To quickly check the level of your domain controllers, you can use the script provided here which will report the msDS-Behavior-Version attribute (3 = 2008). Order of things Microsoft recommends you install Mailbox servers before installing Client Access servers. IPv6 Like Exchange 2010, Exchange 2013 supports IPv6. However, a pure IPv6 environment isn’t supported, so IPv4 is still required. Co-Existence Everybody who’s still running on Exchange 2003 (many customers are) need to follow an intermediate upgrade path when moving to Exchange 2013 when it goes RTM, as co-existence between Exchange 2013 and Exchange Server 2003 isn’t supported. Note that the preview version isn’t supported in co-existence with any Exchange version by the way. Release Notes Be sure to also check out the Release Notes here. # Exchange Setup and AD Replication Latency When setting up Exchange, by default setup assumes the domain controller it talks to is up to date and replication is working almost instantly. Unfortunately, depending on your Active Directory configuration and replication scheme, this isn’t always guaranteed. In such cases, issues can arise of which one I would like to show below. Note that the problem mentioned due to replication latency may also occur when running cmdlets or scripts. A typical issue caused by replication lag is the following error which is shown when trying to install the Mailbox server role: Active Directory operation failed on dc01.contoso.com. This error is not retriable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. Active directory response: 000020B5: AtrErr: DSID-03152392, #1: 0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200ab (homeMTA) In the Exchange setup log you can notice something like the following pattern (in this case setup takes place from a sub domain): [04/18/2012 09:59:15.0328] [2] Active Directory session settings for 'Enable-Mailbox' are: View Entire Forest: 'True', Configuration Domain Controller: 'dc01.nl.contoso.com', Preferred Global Catalog: 'dc01.nl.contoso.com', Preferred Domain Controllers: '{ dc01.nl.contoso.com }' <snip> [04/18/2012 09:59:36.0945] [1] 0. ErrorRecord: Active Directory operation failed on dc01.contoso.com. This error is not retriable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. You can see the Domain Controller used for updating Active Directory is different than the one used for checking. Assuming replication is working correctly, you have several options to get around the situation, depending on whether you’re running setup or executing a cmdlet or script: First, when running setup, you can use the /DomainController parameter to specify a Domain Controller setup should use, e.g.: setup.com /Mode:Install /Role:Mailbox /DomainController:dc1.contoso.com Alternatively, when running a cmdlet or script you can configure the Domain Controller to use by using Set-ADServerSettings in conjunction with the PreferredServer parameter, e.g. Set-ADServerSettings –PreferredServer dc.contoso.com Of course, there’s also a 3rd option which would be to wait for replication cycle. However, this could take a while, depending on the structure and replication scheme. Note that the (potential) problem mentioned in this blog is the reason why you should let scripts stick to the same Domain Controller after picking one or respect the Set-ADServerSettings setting, preventing potential replication issues like this. For more information on Set-ADServerSettings, consult TechNet here. # Federation Information could not be received .. When setting up federation between Exchange organization using the Hybrid Configuration Wizard, to connect your on-premise Exchange environment with Office 365, you may encounter an error message in the 2nd step of the Hybrid Configuration Wizard, Update-HybridConfiguration: When inspecting the Update-HybridConfiguration results, it reads: Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships. Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings. Federation information could not be received from the external organization. .. The problem lies in the sentence “Federation Information could not be received from external organization”. To see where it goes wrong, you could run Set-HybridConfiguration and Update-HybridConfiguration manually, using additional parameters as shown in the result screen, providing proper credentials and additionally addint the Verbose parameter to increase output logged. Most of the time this problem comes down to one of the following issues, which can be verified by running the following cmdlet, where example.com is to be replaced by the federated domain: Get-FederationInformation example.com –Verbose You’ll probably see the cmdlet going trough the discovery motions using autodiscover, ending up in the same “Federation information could not be received from the external organization” message. When analyzing this output, you’ll see it contains two hints on the potential issues: Get-FederationInformation : The discovery process returned the following results: Type=Failure;Url=https://autodiscover.example.com/autodiscover/autodiscover.svc;Exception=Discovery for domain example.com failed.; … 1. Autodiscover The first issue often overlooked is internal autodiscover not working via DNS or not being set up properly, i.e. split DNS configurations. Some customers don’t configure internal DNS autodiscover records or don’t allow (internal) autodiscover to go through the proxy from inside. Normally, when using regular clients like Outlook, this isn’t an issue because domain joined clients will be using SCP records from AD. However, federation will use DNS records so you need allow it or set it up in DNS; a CNAME for autodiscover.example.com as well as autodiscover.service.example.com pointing to your hybrid server will suffice. Also make sure you enable WSSecurity authentication for autodiscover on your hybrid server using: Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication$true

2. Proxy rules
In the error message you’ll notice a autodiscover-related request going to /autodiscover/autodiscover.svc. These requests are normally caught by the autodiscover rule (path /autodiscover/*) in ISA or TMG. Issue is, these service requests require unauthenticated traffic. When you turn on logging in TMG, you’ll notice the requests for /autodiscover/autodiscover.svc will be denied.

To solve this issue, and to get federation working, you need to set up an additional ISA/TMG rule pointing to the hybrid server, using the proper public names (don’t forget autodiscover), bound to the OWA listener. You need to allow All Users (as opposed to Authenticated Users), set authentication to “No Authentication, but users can authenticate directly” and configure the following paths:

• /EWS/Exchange.asmx/wssecurity
• /Autodiscover/Autodiscover.svc
• /Autodiscover/Autodiscover.svc/wssecurity

After configuring the rule, you need to put it above all the other Exchange rules, making it the first matching rule when federation traffic hits ISA/TMG.

After applying the rule changes, Get-FederationInfo example.com should work and you can continue with the Hybrid Configuration.

For more information on setting up co-existence, consult the steps provided by the Exchange Deployment Assistent.

# Configuring initial Exchange database

Something which I still see many Administrators do, right after installing Exchange 2010, is renaming the mailbox database or relocating the database or logs files that were created during the setup of Exchange 2010.

To configure the initial mailbox database name, the location of the initial mailbox database (and catalog) files or its log files, you can incorporate the following parameters in your setup command line:

• MdbName is the name of the initially created mailbox database, e.g. MDB01
• DbFilePath is the full path of the initially created mailbox database file, e.g. E:\MDB01DB\MDB01.edb
• LogFolderPath is the folder used to store the database log files, e.g. D:\MDB01LOG
Note that you must use the complete filename of the edb file, including the .edb extension. Also, you don’t need to create the folders; Exchange will do that for you during setup.

So, to setup Exchange with a custom initial mailbox database name and non-default locations of database and log files, you can use the following command line for example:

setup /mode:install /roles:c,h,m,t /mdbname:MDB01 /DbFilePath:E:\MDB01DB\MDB01.edb /LogFolderPath:D:\MDB01LOG

Of course, these parameters are nice to incorporate in your scripted setup to deploy multiple servers.

Today I encountered a strange issue when trying to decommission a DAG member, after properly removing it from the DAG as explained here, and checking services like address book generation server where hosted on one of the other DAG members.

I started the removal process from an elevated command prompt (using the GUI doesn’t work as it complains about the need to use setup.com, which I can’t since I’m using the GUI):

setup /m:uninstall

The output was the following:

Hmm. Without even looking at the Exchange setup log, I noticed there was something strange with the error message:

The term ‘C:\Program Files\Microsoft\Exchange Server\V14\Bin\ManageScheduledTask.ps1’ is not recognized as the name of a cmdlet, function, script file, or operable program.

As you probably know, all Exchange scripts are located in the Scripts folder, not the Bin folder.

I tried a quick and dirty fix, which was to copy the ManageScheduledTask.ps1 and ManageScheduledTask.strings files to the Bin folder, and again started setup /m:uninstall. This time, Exchange uninstalled nicely.

From experience, this isn’t expected behavior, but in case you encounter this problem in the field, you now know how you can easily work around this.

Update: I’ve seen identical issues when retrying an upgrade on Exchange 2010 SP1 to SP2. I think the problem is code-related (i.e. bug), as the uninstall part of the upgrade process should check for those files in “scripts”, not “bin”. Note that with case of the failing SP2 upgrade, the file EnterpriseServiceEndpoints.xml was also MIA (that one should be in bin). I worked around that by copying the file from the installation source.

# Microsoft Office Filter Pack 2010 SP1

Right after launching Office 365, Microsoft released Service Pack 1 for Microsoft Office 2010 (KB2460049) which includes Office 365 support besides a big list of fixes. For those interested, Office 2010 SP1 can be downloaded here (x86) and here (x64). For a full list of changes, check out Microsoft Office 2010 Service Pack 1 Changes Excel sheet.

More interesting for Exchange folks is that there’s also an SP1 for the Microsoft Office Filter Pack 2010, which of course you install during Exchange setup as one of the prerequisites. As you probably know, the Filter Pack is used to index Office documents stored in Exchange databases to speed up queries.

You can download Service Pack 1 for Microsoft Office Filter Pack 2010 x64 Edition here. The related knowledgebase article is KB2460041.

# Exchange & Dynamic Memory : Don’t

With the arrival of Service Pack 1 for Windows Server 2008 R2, Dynamic Memory was introduced. In brief, Dynamic Memory is a memory management enhancement for Hyper-V which allows running virtual machines (VM) to allocate memory from the host and releasing it when possible, giving a minimum and maximum memory boundary. The main benefit is a higher VM density, because each VM will only allocate what’s required and you don’t have to approximate memory allocations.

Now this mechanism works well for many applications, but not for Exchange. Exchange’s goal – at least that of servers holding the mailbox role – is to claim as much memory as possible in order to cache information. This amount depends on the installed of memory (more information here). This cache is used for performance reasons, more cache means less I/O’s, less I/O’s result in better performance. You can guess what happens when you run Exchange with a minimal amount of memory and lots of dynamic memory configured, optionally shared with other Dynamic Memory-enabled VM’s. If Exchange starts up and wants to claim memory for caching or allocate memory for other reasons (transactions), instead of the memory being available instantly the host first needs to allocate it, or worse have other VM’s surrendering it their memory. That doesn’t make sense and will result in significant performance penalty.

Besides it being pointless to configure Dynamic Memory for Exchange, it’s also not recommended. From the Exchange 2010 System Requirements:

Many of the performance gains in recent versions of Exchange, especially those related to reduction in I/O, are based on highly efficient usage of large amounts of memory. When that memory is no longer available, the expected performance of the system can’t be achieved. For this reason, memory oversubscription or dynamic adjustment of virtual machine memory should be disabled for production Exchange servers.

Also, from the paper Implementing and Configuring Dynamic Memory, on applications that may not perform as well after Dynamic Memory is enabled:

• Applications that perform their own memory management by taking over certain aspects of memory management from the operating system. Such applications typically grab as much memory as they possibly can in order to ensure the application’s best performance which can cause the amount of memory allocated to their virtual machine to grow until it reaches the amount specified by the Maximum RAM setting;
• Applications where memory allocation is a one shot operation that is performed either when the application starts for the first time or each time the application starts.

Concluding, yes you can use Dynamic Memory for your lab or testing environment and it works. But don’t use it in production for Exchange Server.