Released: Exchange Server 2013 RTM Cumulative Update 2

[Ross Smith IV]

• download
• release notes
• UM language packs

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.

Servicing Model Update

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:

1. If during the course of a support incident it is determined that the solution is available in a published CU (e.g., CU2), the customer will be required to install the update that contains the fix. We will not be building a new fix to run on top of a CU published earlier (e.g., CU1).
2. If during the course of a support incident it is determined that you have discovered a new problem for which we confirm a fix is required, that fix will be published in a future CU that you can then install to correct the problem reported.

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.

Upgrading/Deploying Cumulative Update 2

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.

Important: To prevent issues during the installation or upgrade of Exchange 2013 RTM CU2, you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted”. Failure to do so could cause the Exchange 2013 server to be in an unusable state and some downtime could occur. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the Exchange 2013 Server(s). If the policies are NOT set to Unrestricted you should use the resolution steps in the following article to adjust the settings KB 981474.

Active Directory Preparation

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:

1. Exchange 2013 RTM CU2 includes schema changes. Therefore, you will need to execute setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms.
2. Exchange 2013 RTM CU2 includes enterprise Active Directory changes (e.g., RBAC roles have been updated to support new cmdlets and/or properties). Therefore, you will need to execute setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms.

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.

Server Deployment

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.

Note: Unlike previous versions, in Exchange 2013, you cannot uninstall a single role from a multi-role server. For example, if you deploy the CAS and MBX roles on a single machine, you cannot later execute setup to remove the CAS role; you can only uninstall all server roles.

Changes in Exchange 2013 RTM CU2

In addition to bug fixes, Exchange 2013 RTM CU2 introduces enhancements in the following areas.

• Per-server database support
• OWA Redirection
• High Availability
• Managed Availability
• Cmdlet Help
• OWA Search Improvements
• Malware Filter Rules

Per-Server Database Support

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.

OWA Redirection

Depending on your deployment model, Exchange 2013 RTM CU1 supported the following redirection or proxy scenarios:

1. In environments where Exchange 2013 and Exchange 2010 coexist, Exchange 2013 CAS proxies OWA requests to Exchange 2010 CAS for Exchange 2010 mailboxes.
2. In environments where Exchange 2013 and Exchange 2007 coexist, Exchange 2013 CAS redirects the request to the Exchange 2007 CAS infrastructure’s ExternalURL. While this redirection is silent, it is not a single sign-on event.
3. In native Exchange 2013 environments:
   1. Exchange 2013 CAS proxies the OWA request directly to the Exchange 2013 Mailbox server when in a single site.
   2. Exchange 2013 CAS proxies the OWA request directly to the Exchange 2013 Mailbox server when the Mailbox server exists in a different site and the CAS infrastructure in the target site has no ExternalURL defined.
   3. Exchange 2013 CAS proxies the OWA request directly to the Exchange 2013 Mailbox server when the Mailbox server exists in a different site and the CAS infrastructure in the target site has an ExternalURL that matches the source site’s ExternalURL.
   4. Exchange 2013 CAS redirects the OWA request to the CAS infrastructure in the target site when the target site’s ExternalURL does not match the source site’s ExternalURL. While this redirection is silent, it is not a single sign-on event.

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:

1. Silent redirection is the default behavior in Exchange 2013, meaning that if FBA is enabled on source and target OWA virtual directories, the redirection will also be a single sign-on event.
2. You can disable silent redirection on the source CAS via the web.config file located at <ExchangeSetupDir>\FrontEnd\HttpProxy\owa by adding the following line in the <appSettings>section:

   <add key="DisableSSORedirects" value="true" />

High Availability

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.

Managed Availability

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.

RecoveryAction	Enabled	Per Server			Per Group
		Minutes Between Actions	Max Allowed Per Hour	Max Allowed Per Day	Minutes Between Actions	Max Allowed Per Day
ForceReboot	True	720	N/A	1	600	4
SystemFailover	True	60	N/A	1	60	4
RestartService	True	60	N/A	1	60	4
ResetIISPool	True	60	N/A	1	60	4
DatabaseFailover	True	120	N/A	1	120	4
ComponentOffline	True	60	N/A	1	60	4
ComponentOnline	True	5	12	288	5	Large
MoveClusterGroup	True	240	N/A	1	480	3
ResumeCatalog	True	5	4	8	5	12
WatsonDump	True	480	N/A	1	720	4

Cmdlet Help

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.

OWA Search Improvements

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:

1. Conversation items are auto-expanded that have hits in them.
2. Whenever you search for a term and select a conversation from the result list, OWA will move the scroll position of the reading pane so that the first item part with that search term is in view.
3. Hit navigation within a conversation – you can jump between search hits quickly using a control built into the reading pane.

Malware Filter Rules

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.

Looking Ahead

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.

Conclusion

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

Updates

• 7/11/13: Added info about PowerShell Execution Policy and KB981474.
• 7/11/13: Exchange 2013 Release Notes on TechNet have been refreshed.
• 7/29/13: Added pointer to updated build of CU2 and updated article.
• 8/2/13: Added link for CU2 Unified Messaging Language Packs.