Today, we released Exchange Server 2013 RTM Cumulative Update 2 (CU2) to the Microsoft Download Center. In addition to this article, the Exchange 2013 RTM release notes (updated for CU2) are also available.
The final build number for Exchange 2013 RTM CU2 is 15.0.712.24. If you previously installed the 712.22 build, please upgrade to 712.24 to ensure you are not affected by the following issue.
Note: Some article links may not be available at the time of this post's publication. Updated Exchange 2013 documentation, including Release Notes, will be available on TechNet soon.
In the new Exchange servicing model customers will continue to receive assistance from Microsoft Support for the lifecycle of the Exchange server product - a customer is not required to be at the most current CU to receive assistance. There are two scenarios that we would like to clarify though:
An important benefit of the Exchange servicing model is that it provides the ability to receive independent security releases outside of the CU or Service Pack (SP) process. What this means for you is that future security fixes will not require you to install a CU to get the individual fix for a reported vulnerability. This allows you to quickly validate and install a security update with confidence knowing that only the fixes which address a particular security problem will be included as part of that release.
Exchange Server Cumulative Updates are scheduled to be released quarterly. We realize that some customers spend several months validating environments, third-party products, etc., and require more time for testing. Therefore, we will continue to ship a Service Pack which provides all of the updates included in prior cumulative updates in one installation and acts as a logical milestone for updating your servers.
Customers who are using Exchange Server 2013 and Office 365 together in an Exchange Hybrid scenario get a rich set of capabilities to manage and run mailboxes on-premises and in the cloud. Updates come to Office 365 frequently and thus customers in hybrid scenarios are strongly recommended to stay current as Cumulative Updates are released. Keeping current will allow your on-premises Exchange Server to be running the same code as the Office 365 Exchange servers. This helps keep consistency between on-premises and Office 365 users and puts you in the best position to take advantage of new features as they are made available in the service. This always updated approach is available for everyone and is the recommend approach for all customers to obtain fixes and new features as soon as they become available.
Overall, the new Exchange Server servicing strategy provides a predictable pattern for releases and provides customer control options for on-premises customers. Each CU receives extensive validation as the builds released in a CU have been deployed in the Office 365 service – you can deploy a CU knowing it has already had datacenter scale validation in the world’s largest and most demanding Exchange environment.
Unlike previous versions, cumulative updates do not use the rollup infrastructure; cumulative updates are actually full builds of the product, meaning that when you want to deploy a new server, you simply use the latest cumulative update build available and do not necessarily need to apply additional Exchange Server updates.
Prior to upgrading or deploying the new build onto a server, you will need to update Active Directory. For those of you with a diverse Active Directory permissions model you will want to perform the following steps:
Note: If your environment contains only Exchange 2007, and you upgrade to Exchange 2013, keep in mind you cannot deploy Exchange 2010 in that environment at a later time. If you foresee a need to deploy Exchange 2010 servers into your environment, deploy an Exchange 2010 multi-role server (with all four servers roles) prior to executing Exchange 2013 setup.exe /PrepareAD. As long as you retain at least one role of each legacy server, you will continue to be able to install additional servers of that version into your coexistence environment. Once you remove the last server role of a legacy version, you will no longer be able to reintroduce that version into the environment.
Once the preparatory steps are completed, you can then deploy CU2 and start your coexistence journey. If this is your first Exchange 2013 server deployment, you will need to deploy both an Exchange 2013 Client Access Server and an Exchange 2013 Mailbox Server into the organization. As explained in Exchange 2013 Client Access Server Role, CAS 2013 is simply an authentication and proxy/redirection server; all data processing (including the execution of remote PowerShell cmdlets) occurs on the Mailbox server. You can either deploy a multi-role server or each role separately (just remember if you deploy them separately, you cannot manage the Exchange 2013 environment until you install both roles).
If you already deployed Exchange 2013 RTM code and want to upgrade to CU2, you will run setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms from a command line after completing the Active Directory preparatory steps or run through the GUI installer. Deploying future cumulative updates will operate in the same manner.
In addition to bug fixes, Exchange 2013 RTM CU2 introduces enhancements in the following areas.
As mentioned previously, Exchange 2013 RTM CU2 increases the per-server database support from 50 databases to 100 databases in the Enterprise Edition of the product. Please note that this architectural change may not provide any additional scalability as CPU may be a bottleneck, thereby limiting the number of mailboxes you can deploy per-server.
As promised, the Exchange 2013 Server Role Requirements Calculator has been updated for this architectural change.
Depending on your deployment model, Exchange 2013 RTM CU1 supported the following redirection or proxy scenarios:
Exchange 2013 RTM CU2 changes this behavior by providing a single sign-on experience when Forms-Based Authentication (FBA) is used on the source and destination OWA virtual directories by issuing back to the web browser a hidden FBA form with the fields populated. This hidden form contains the same information as what the user had originally submitted to the source CAS FBA page (username, password, public/private selector) as well as, a redirect to the target Exchange specific path and query string. As soon as this form is loaded it is immediately submitted to the target URL. The result is the user is automatically authenticated and can access the mailbox data.
Many of you may be familiar with this functionality in Exchange 2010 SP2. However, there are differences in the Exchange 2013 RTM CU2 implementation:
<add key="DisableSSORedirects" value="true" />
Exchange 2013 RTM CU2 introduces a new service, the DAG Management Service. The DAG Management service contains non-critical code that used to reside in the Replication service. This change does not introduce any additional complexities in event reporting, either – events are written into the Application event log with the source of MSExchangeRepl and crimson channel.
In addition to improvements in various probes and monitors, there have been changes to the responder throttling framework. Prior to Exchange 2013 RTM CU2, many responders were only throttled per-server (e.g., RestartService). Now, these responders are throttled per group. For example, originally RestartService was throttled based on the number of occurrences that occurred on a server; in Exchange 2013 RTM CU2, RestartService can execute every 60 minutes DAG-wide, with a maximum of 4 restarts per day DAG-wide.
Minutes Between Actions
Max Allowed Per Hour
Max Allowed Per Day
Exchange 2013 RTM CU2 introduces the capability for administrators to get updates to Exchange Management Shell cmdlets without needing to deploy a new service pack or cumulative update. Administrators can launch the Exchange Management Shell and run the Update-ExchangeHelp cmdlet to update their local Shell help.
Previously searching for keywords within OWA did not give indications of the location of the keyword in the search result set. Exchange 2013 RTM CU2 improves OWA’s search results highlighting in three ways:
Exchange 2013 RTM CU2 introduces the –MalwareFilterRule cmdlets. You can use the –MalwareFilterRule cmdlets to apply custom malware filter policies to specific users, groups, or domains in your organization. Custom policies always take precedence over the default company-wide policy, but you can change the priority (that is, the running order) of your custom policies.
The Exchange Product Group is in the final validation stages to support Windows Azure for Witness Server placement. Specific guidance on using Windows Azure for the Witness Server placement will be available via TechNet at a later date. Support for this scenario will occur once the guidance has been released.
We understand that some features delivered in CU2 were available in Exchange 2010 and haven’t been available until this update. The lack of single sign-on capability in OWA redirection and the reduced per-server database support were due in part to the complete re-write of these components in Exchange 2013. Holding back these features were necessary to meet our code stability and performance criteria for release. It was your feedback which helped prioritize the return of these features. Our new servicing model allows us to add incremental improvements to the product at a faster cadence than the previous model.
As always, we continue to identify ways to better serve your needs through our regular servicing releases. We hope you find these improvements useful. Please keep the feedback coming, we are listening.
Ross Smith IV Principal Program Manager Exchange Customer Experience