Today the long-awaited Cumulative Update 1 for Exchange Server 2013 was released by the Exchange Team (KB2816900). This update raises Exchange 2013 version number to 15.0.620.29.
The Exchange Team provided a description of the major changes in CU1 in the CU1 announcement here; Here are some of the major changes in CU1:
Includes Address Book Policy Routing Agent (info);
Allows group memberships to be managed by groups (again, as it was possible in Exchange 2007 but not in Exchange 2010);
Access to Public Folders you have added as favorites via your favorites menu either in Outlook or Outlook Web App (still no regular Public Folder tree access though);
EAC has been enhanced and now includes Unified Messaging management and migration options;
Get-HealthReport cmdlet has been streamlined and its performance has been optimized;
Supports the Exchange Server 2013 Management Pack for SCOM 2007 R2 and SCOM 2012 (due at a later date);
High Availability changes (reported on by Scott Schnoll here).
Note that CU1 includes schema changes. Like Service Packs for earlier versions of Exchange, the Cumulative Update is indeed cumulative (hence the size of 1.3 GB) and you can install it directly, i.e. no need to install RTM first. Also, once installed you can’t uninstall CU1 or any of the installed roles. The order of upgrading servers doesn’t matter, unlike with earlier Exchange versions.
You can download Exchange 2013 Cumulative Update 1 here.
Update 3rd April, 2013: Meanwhile, the TechNet documentation has been updated; relevant sections for upgrading are:
Today the Exchange Team announced postponing the release of Exchange 2013 Cumulative Update 1 for a few more days. Originally, CU1 was scheduled for Q1 2013, but the date has been set now at April 2nd, 2013.
While it may sound disappointing when you’re waiting for Exchange 2013 RTM CU1, it makes sense to postpone it a bit. As the team indicated,the time is used to add functionality required for coexistence scenarios with Exchange Server 2010 which otherwise had to be put in an update for Exchange 2010 Client Access servers. I expect people to be less happy as Exchange 2010 Service Pack 3 was heralded as the Exchange 2010 product level for coexistence support with Exchange 2013 (running CU1).
Also, looking at time frames involved with testing and accepting updates in production environments, I personally applaud this decision as putting that code in Exchange 2013 at the cost of a few days may in the end be faster than adding that code to Exchange Server 2010, requiring customers to initiate test an acceptance tracks for production updates.
So, until further notice we’ll have to wait just a few more additional days to see what Cumulative Update 1 will bring us.
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, Exchange Server 2016, or Exchange Server 2019 (Desktop and Core) is supported).
The script takes care of:
Installing requires Windows Server features
Install Exchange Server prerequisites, e.g., .NET Framework 4.5.2/4.6.1/4.6.2/4.7.1/4.7.2/4.8/4.8.1 and Visual C++ Runtime 2012 or 2013, depending on roles, OS, and Exchange version to install.
Install additional prerequisites and prepare Active Directory.
Optionally install Exchange Server 2013 / 2016 / 2019.
Optionally, install required fixes and perform post configuration, like setting your Power Plan to High Performance, reconfiguring the pagefile to best practices (memory + 10MB with a maximum of 32GB+10MB) if it is system managed, and performing .NET framework optimizations. Custom post-configuration is possible by modifying the script.
On Windows Server 2016 and later, it will configure Windows Defender exclusions when present.
For Exchange 2016 CU22 and Exchange 2019 CU11 and later, will install the required URL Rewrite 2 module.
Finally, the script will clean things up, like removing the state file and setting the startup of Transport Service back to Automatic.
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/2016/2019 installation files are stored (e.g., a UNC path).
Organization (optional): Specifies the 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. This applies to Exchange 2013 as well as Exchange 2016.
InstallCAS: Specifies you want to install the CAS role. This applies to Exchange 2013 only, ignored when installing Exchange 2016.
InstallMultiRole: Specifies you want to install both Mailbox server and CAS roles. Applies to Exchange 2013 only.
InstallEdge: Specifies to install the Edge Transport rule (Exchange 2013/2016).
MDBName (optional): Specifies the name of the initially created database.
MDBDBPath (optional): Specifies the database path of the initially created database (requires MDBName).
MDBLogPath (optional): Specifies the log path of the initially created database (requires MDBName).
InstallPath (optional): Specifies (temporary) location of where to locate – and when downloaded store – prerequisite files, the state file, and log files. The default location is C:\Install. You can also use a UNC path to use a central location, given the credentials have sufficient permissions to write at this location. This is ideal when you want the script to use previously downloaded hotfix files, for example, as some required hotfixes are quite large (e.g. KB3206632 for WS2016 ~ 1GB, KB2919355 for WS2012R2 ~ 700MB).
NoSetup (optional): Specifies you only want to install prerequisites (and optionally prepare the Exchange organization), Exchange setup and post-configuration steps are not performed. You still need to specify SourcePath because the Exchange version will determine the prerequisites to install.
Recover: Specifies you want to install this server in Recovery mode. The script will check if an Exchange server object is already defined.
SourcePath: Specifies the location of the Exchange 2013 installation files. This can point to the location of setup.exe, or you can specify the Exchange ISO file.
TargetPath: Specifies the location where to install the Exchange 2013.
AutoPilot (switch): Specifies you want to automatically restart, log on using the credentials specified, and continue the installation. When not specified, you will need to restart, log on, 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 the operating system and detected Exchange version to install, will download and install recommended hotfixes.
DiagnosticData (optional): This switch determines the initial Data Collection mode for deploying Exchange 2019 CU11, Exchange 2016 CU22, or later builds.
DoNotEnableEP Do not enable Extended Protection on Exchange 2019 CU14+
DoNotEnableEP_FEEWS Do not enable Extended Protection on the Front-End EWS virtual directory on Exchange 2019 CU14+
SCP (optional) allows you to reconfigure the Service Connection Point record for Autodiscover after the Exchange setup has finished. Specify the full URI, e.g. https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Use ‘-‘ to clear the SCP entries of the server.
Lock (optional) locks the system when running script.
NoNet481 (optional) prevents installing .NET Framework 4.8.1 and uses 4.8 when deploying Exchange 2019 CU14+
NoNet48 (optional) to use .NET Framework 4.7.2, even when installing an Exchange version that is supported with .NET Framework 4.8.
NoNET471 (optional) to use .NET Framework 4.6.2, even when installing an Exchange version which is supported with .NET Framework 4.7.1.
NoNET472 (optional) to use .NET Framework 4.7.1, even when installing an Exchange version which is supported with .NET Framework 4.7.2.
NoNET461 (optional) to use .NET Framework 4.5.2, even when installing an Exchange version which is supported with .NET Framework 4.6.1 or higher.
DisableSSL3 (optional) to disable SSL3 protocol as per KB187498.
DisableRC4 (optional) to disable RC4 cipher as per KB2868725.
SkipRolesCheck (optional) to bypass membership checks for Schema Admin and Enterprise Admin roles.
EdgeDNSSuffix specifies the DNS suffix to configure on the primary NIC.
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:
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 also put reboots after the other milestones.
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.
Recovery The script also supports recovery mode (/mode:RecoverServer). After checking the Exchange server object is present in Active Directory, installation will proceed as normal, with the exception of running setup in recovery mode. For example:
Update The script also supports update mode (/mode:Update). After checking the Exchange server object is present in Active Directory, and checking for presence of Exchange installation, installation will proceed as normal, with the exception of running setup in Update mode.
Feedback Feedback is welcomed through the comments. If you have scripting suggestions or questions, do not hesitate to use the contact form.
Download You can download Install-Exchange15.ps1 from TechNet or GitHub.
A quick post as the Exchange 2013 Help (.CHM) files on the Microsoft Download Center have been updated. The offline help files files are convenient if you’re on the road or in a location without internet connection.
You can download the updated files dated January 18th, 2013 for On-Premise and Hybrid deployments of Exchange 2013 here.
On another note, there’s a new Office Visio 2013 stencil for Exchange 2013, including on-premise and hybrid deployments. You can download it here.
When creating a Database Availability Group (DAG) in Exchange 2010 or Exchange 2013 you leverage Fail-over Clustering from the operating system, e.g. Windows Server 2008 R2.
Behind the scenes Kerberos authentication is used, for which a so called Cluster Name Object (CNO) has to be created in Active Directory. This CNO will be associated with the Cluster Name Resource.
Depending on the situation, like having the ability to create computer accounts in the domain, you may need to create – or pre-stage – the cluster name object as computer account upfront. For Exchange 2013 on Windows Server 2012, pre-staging the CNO is a requirement. This manual task is described here.
However, there may be circumstances where having the ability to automate the process would be more appropriate, like when you want a fully automated setting up a DAG for example. For this purpose I have created a small script, Create-CNO.ps1. The syntax is as follows:
The Identity is used to specify the name of the CNO;
The optional Computers parameter can be used to specify the computer account which should be granted permissions on the CNO. You can specify multiple accounts seperated by commas (when for example you’re not sure which your will be used to create the DAG). When the Computers parameter is omitted, the Exchange Trusted Subsystem will be granted permissions on the CNO;
OU is the name of the container to create the CNO in. When not specified, the default container for computer accounts will be used. This is done by querying for the Well-Known GUID for the computers container, aa312825768811d1aded00c04fd8d5cd (more on Well-Known GUIDs here). Note that when specifying the OU, you need to enclose it in quotes otherwise PowerShell will assume the parameter is an array;
The Verbose parameter is supported.
So, for example assume you want to create a DAG called DAG001 and the first Mailbox Server will be L14Ex1. The computer object for the cluster is to be stored in the OU ou=Temp,dc=litware,dc=com. In that case, you would call the script as follows: