We know a lot of you have been waiting for this, and so it is with great excitement that we announce that Exchange Server 2013 RTM Cumulative Update 1 (CU1) has been released to the web and is available for immediate download! This is the first release using the new servicing model for Exchange Server 2013. In addition to this article, the Exchange 2013 RTM CU1 release notes are also available.

Note: Article links that may not have been available at the time of this post’s publishing are now available. Updated Exchange 2013 documentation, including Release Notes, is now available on TechNet.

CU1 is the minimum version of Exchange 2013 required for on-premises coexistence with supported legacy Exchange Server versions. The final build number for CU1 is 15.0.620.29. For more information on coexistence, check out the Planning and Deployment documentation, and this Ignite webcast covering deployment of and coexistence with Exchange Server 2013.

Upgrading/Deploying Cumulative Update 1

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.

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 CU1 includes schema changes. Therefore, you will need to execute setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms.
2. Exchange 2013 RTM CU1 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.
3. Exchange 2013 RTM CU1 includes changes to the permissions within the domain partition (e.g., Exchange Servers have been granted the ability to modify msExchActiveSyncDevices class on inetOrgPerson objects). Therefore, you will need to execute setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms in each domain containing Exchange servers or mailboxes.

Coexistence Pre-Deployment Step: OAB Verification

As mentioned in the Exchange Server 2013 CU1 release notes, when you deploy the first Exchange 2013 Mailbox server in an existing Exchange organization, a new default Offline Address Book is created.

Figure 1: The new OAB as shown in an Exchange Server 2010 SP3 & 2013 CU1 environment

All existing clients that rely on an OAB will see this new default OAB the next time they look for an OAB update. This will cause these clients to perform a full OAB download. To prevent this from happening, you can configure your existing mailbox databases to explicitly point to the current default OAB prior to introducing the first Exchange 2013 server. You can do this one of two ways:

Within the Exchange Management Console (EMC), navigate to Organization Configuration –> Mailbox –> Database Management –> Mailbox Database Properties –> Client Settings.

Figure 2: Modifying the default Offline Address Book at the database level in the EMC

Alternatively, if you have many mailbox databases to update, the following Exchange Management Shell command can be used to view all mailbox databases without a default OAB explicitly set on them. If you have both Exchange 2007 and Exchange 2010 deployed on-premises then you will have to run the following commands using the respective Exchange Management Shell version as the Get/Set-MailboxDatabase commands are version specific.

Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} | FT Name,OfflineAddressBook -AutoSize

If no values are returned then you are already prepared. However, if you need to configure some databases, then this next command will find all mailbox databases in an Exchange 2007 or Exchange 2010 environment with no default OAB defined at the database level, and it will set it to the current default OAB in the org.

Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} | Set-MailboxDatabase -OfflineAddressBook (Get-OfflineAddressBook | Where {$_.IsDefault -eq $True})

To confirm all Exchange 2007/2010 mailbox databases now have a defined default OAB, re-run the first command. This time it should return no entries.

Server Deployment

Once the preparatory steps are completed, you can then deploy CU1 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 CU1, 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.

Mailbox Sizes in Exchange Server 2013

As you start migrating your mailboxes to Exchange 2013, one thing you may notice is that your mailboxes appear to be larger post move.

As you can imagine, with hosting millions of mailboxes in Office 365, accurate storage reporting is essential, just like in your on-premises deployments. One of the learnings that we accrued into the on-premises product is ensuring that the mailbox usage statistics are more closely aligned with the capacity usage within the Mailbox database. The impact of reporting space more accurately means that mailbox quota limits may need to be adjusted prior to the mailbox move so that users are not locked out of their mailbox during the migration process.

Our improved space calculations may result in a mailbox’s reported size increasing on average of 30% when the mailbox is moved from a legacy version of Exchange to Exchange 2013. For example, if a mailbox is reported as 10GB in size on Exchange Server 2010, then when the mailbox is moved to Exchange 2013, it may be reported as 13GB. This does not mean that migrating to Exchange 2013 will increase your capacity footprint by 30% per mailbox; it only means that the statistics are including more data about the space the mailbox consumes. 30% is an average value, based on what we have experienced in Exchange Online. Customers with pilot mailboxes should determine what their own average increase value may be as some environments may see higher or lower values depending on the most prevalent type of email within their mailboxes. Again, this does not mean there will be an increase in the size of the database file on disk; only the attribution of space to each mailbox will increase.

New Functionality Included in Cumulative Update 1

Exchange 2013 RTM CU1 includes a number of bug fixes and enhancements over the RTM release of Exchange 2013. Some of the more notable enhancements are identified below.

Address Book Policies

As discussed recently, an Address Book Policy Routing Agent has been included in Exchange 2013 RTM CU1. For all the juicy details, see Address Book Policies, Jamba Jokes and Secret Agents.

Groups can once again manage groups!

In Exchange 2010 you could not use a group as an owner for another group for membership management. Instead you had to deploy explicit permissions on groups or use a script as a workaround.

Since Exchange 2010’s release both Microsoft Support and the Exchange Product Group received resounding feedback on the need for this capability. The good news is that with Exchange 2013 RTM CU1 groups can once again be owners of groups for membership management.

Public Folder Favorites Access through Outlook Web App

In Exchange Server 2013 RTM there was no way to access Public Folder content through Outlook Web App. In CU1 you will now have access to Public Folders you have added as favorites via your favorites menu either in Outlook or Outlook Web App. However, this access is limited to Public Folders stored on Exchange Server 2013.

Figure 3: Adding a Public Folder as a favorite in Outlook Web App in Exchange Server 2013 RTM CU1

Remember, you cannot start creating Public Folders on Exchange Server 2013 until all users have been migrated to Exchange Server 2013. For how to migrate from legacy Public Folders to Exchange Server 2013 Public Folders, see Migrate Public Folders to Exchange 2013 From Previous Versions.

Exchange Admin Center Enhancements

The Exchange Admin Center (EAC) has been enhanced and now includes Unified Messaging management, improvements in the migration UI allowing more migration options reducing the gap between PowerShell and the UI, and general overall improvements in the user experience for consistency and simplification based on customer feedback.

High Availability and Monitoring Enhancements

There are have been several enhancements in the high availability and Managed Availability space. In particular:

• The Best Copy Selection algorithm now honors MaximumActiveDatabases.
• Auto-reseed now supports disks that have Bitlocker encryption.
• Many probes, monitors, and responders have been updated and improved over the RTM release.
• Get-HealthReport cmdlet has been streamlined and its performance has been optimized.
• Exchange 2013 RTM CU1 will support the Exchange Server 2013 Management Pack for System Center Operations Manager (SCOM); this management pack will be available at a later date. This management pack is supported on SCOM 2007 R2 and SCOM 2012.

Exchange Server 2013 Cumulative Update 1 (CU1) has been released and is now available for download!  CU1 is the first release to use the servicing model introduced with Exchange 2013.  CU1 includes new features, new functionality and bug fixes, including in the area of high availability.  The announcement post on the Exchange Team Blog already has some great information on what’s new in CU1, but I wanted to augment that announcement with some additional details.  Below is a list of some of the high availability-related changes in CU1.  This is by no means an exhaustive list; just a list of some of the changes that we have made.

Witness Server Warning Message When Using Certain Database Availability Group Tasks

I first wrote about this issue back in June 2011.  This is where the system displays an incorrect warning message when you are using a non-Exchange server as your witness server, even when you have configured things correctly.  This issue was eventually fixed in Exchange 2010 Service Pack 2 RU5, but it didn’t make it’s way into Exchange 2013 RTM.  Fortunately, the fix did make its way into CU1.

Self-recovery Behaviors

Exchange 2013 continues the innovation introduced in Exchange 2010 by including functionality that allows the system to self-recover from failures that affect resiliency or redundancy. In addition to the Exchange 2010 self-recovery behaviors, Exchange 2013 RTM includes additional behaviors for long I/O times, excessive memory consumption by the Microsoft Exchange Replication service (MSExchangeRepl.exe), and severe cases where threads can’t be scheduled. For example, every 30 seconds, the Exchange Replication service heartbeats the crimson channel, as it is a required component for normal operations. If this heartbeat fails, an indication that the crimson channel is inaccessible for some reason, the Exchange Replication service self-recovers the server by forcibly rebooting the server, thereby triggering a server failover.

In addition to the behaviors in Exchange 2013 RTM, CU1 includes new behaviors:

• Bus Resets – Event 129 is logged in the System event log when a bus reset occurs.  Bus resets, particularly the rare but possible bus reset storm, can often result in storage issues, such as hung IO. When these events occur, it typically requires administrator intervention to resolve the issue. To obviate the need for administrator intervention, CU1 includes new functionality that triggers a forcible reboot of the server when event 129 is detected in the System event log.
• Replication service endpoints not responding – Exchange periodically verifies that the TCPListener component in the Exchange Replication service is responding to connection requests by periodically heart beating the local instance of the Exchange Replication service.  If the TCPListener does not respond, the system will automatically self-recover by forcibly rebooting the server.

Autoreseed

Automatic reseed, or AutoReseed, is a feature that’s the replacement for what is normally administrator-driven action in response to a disk failure, database corruption event, or other issue that necessitates a reseed of a database copy. When properly configured, AutoReseed is designed to automatically restore database redundancy after a disk failure by using spare disks that have been provisioned on the system.

CU1 includes numerous fixes to AutoReseed, including fixes for issues around AutoReseed not detecting spare disks correctly and AutoReseed not using detected spare disks.  In addition, the following enhancements have been made to AutoReseed:

• GetCopyStatus now has a new field ‘ExchangeVolumeMountPoint’, which shows the mount point of the database volume under C:\ExchangeVolumes (or a custom folder if you are not using the default setting of C:\ExchangeVolumes).  This is useful information to know because in a configuration that uses multiple disks per volume, the LogicalDisk performance counters show up as the first mount point (which would be the one under C:\ExchangeVolumes) instead of as the database path like they used to in Exchange 2010 with a single disk per volume.
• We now have better internal tracking around mount paths and the ExchangeVolume path.
• The limits for AutoReseed have been increased from 4 databases per volume in Exchange 2013 RTM to 8 databases per volume in CU1.
• AutoReseed properties have been added to Active Directory that allow you to enable and disable automatic reseeding and the DiskReclaimer function (which formats Exchange volumes). The two new properties are:
  • AutoDagAutoReseedEnabled – Setting AutoDagAutoReseedEnabled to false turns off AutoReseed (including automatic resume, sparing, and in-place reseeds).
  • AutoDagDiskReclaimerEnabled – Setting AutoDagDiskReclaimerEnabled to false turns off the DiskReclaimer, which formats exchange volumes. The default setting is true, and it only tries to format volumes mounted under C:\ExchangeVolumes.
• The unused AutoDagFailedVolumesRootFolderPath property was also removed from the DAG object.

As a result of these and other changes, the workflow for AutoReseed in CU1 has changed.  The primary input condition for the AutoReseed workflow is still a database copy that is in an Failed and Suspended (F&S) state for 15 consecutive minutes.  When that condition is detected, the following AutoReseed workflow is initiated:

1. The system will first try to resume the database copy up to 3 times, with 5 minute sleeps in between each try.  Sometimes, after an F&S database copy is resumed, the copy remains in a Failed state. This can happen for a variety of reasons, so this first step is designed to handle all such cases; AutoReseed will automatically suspend a database copy that has been Failed for 10 consecutive minutes to keep the workflow running. If the suspend and resume actions don’t result in a healthy database copy, the workflow continues.
2. Next, AutoReseed will perform a variety of pre-requisite checks. For example, it will verify that a spare disk is available, that the database and its log files are configured on the same volume, and in the appropriate locations that match the required naming conventions. In a configuration that uses multiple databases per volume, AutoReseed will also verify that all database copies on the volume are in an F&S state.
3. Next, AutoReseed will attempt to assign a spare volume up to 5 times, with 1 hour sleeps in between each try.
4. Once a spare has been assigned, AutoReseed will perform an InPlaceSeed operation using the SafeDeleteExistingFiles seeding switch.  If one or more database files exists, AutoReseed will wait for 2 days before in-place reseeding (based on the LastWriteTime of the database file).  This provides an administrator with an opportunity to preserve data, if needed.  AutoReseed will attempt a seeding operation up to 5 times, with 1 hour sleeps in between each try.

Once all retries are exhausted, the workflow stops.  If, after 3 days, the database copy is still F&S, the workflow state is reset and it starts again from Step 1.  This reset/resume behavior is useful (and intentional) since it can take a few days to replace a failed disk, controller, etc..

Update-MailboxDatabaseCopy

The Update-MailboxDatabaseCopy cmdlet includes some new parameters in CU1 that are designed to aid with automation of seeding operations.  These parameters include:

• BeginSeed – This is useful for scripting reseeds, because with this parameter, the task asynchronously starts the seeding operation and then exits the cmdlet.
• MaximumSeedsInParallel – This is used with the Server parameter to specify the maximum number of parallel seeding operations that should occur across the specified server during a full server reseed operation. The default value is 10.
• SafeDeleteExistingFiles – This is used to perform a seeding operation with a single copy redundancy pre-check prior to the seed. Because this parameter includes the redundancy safety check, it requires a lower level of permissions than the DeleteExistingFiles parameter, enabling a limited permission administrator to perform the seeding operation.
• Server – This is used as part of a full server reseed operation to reseed all database copies in a Failed and Suspended state. It can be used with the MaximumSeedsInParallel parameter to start reseeds of database copies in parallel across the specified server in batches of up to the value of the MaximumSeedsInParallel parameter copies at a time.

Set-DatabaseAvailabilityGroup

The Set-DatabaseAvailabilityGroup cmdlet includes a new parameter named SkipDagValidation.  It is used to bypass the validation of the DAG’s quorum model and the health check on the DAG’s witness during certain DAG configuration operations.  While this parameter has some usefulness for us in Exchange Online (and that is why it was introduced), and while it is enabled for on-premises use, it won’t be of much use to on-premises environments. I’m only pointing it out because, as I said, it is enabled for on-premises use.

Managed Availability: Get-ServerHealth and Get-HealthReport

The Get-ServerHealth and Get-HealthReport cmdlets are used to get and process raw health set data from Managed Availability, the new monitoring and recovery framework used by the various components within Exchange. Get-ServerHealth can be used to view the various health sets and their current status.  In Exchange 2013 RTM, the Get-HealthReport cmdlet consumed results from Get-ServerHealth to produce a summary rollup of health.  But the way in which it was implemented made it very slow and inefficient.

With CU1, instead of piping Get-ServerHealth to Get-HealthReport, Get-HealthReport is now capable of reporting the consolidated results on its own, and it now takes an Identity parameter that enables you to specify a server instead of InputObject/InputEntries.  Get-HealthReport also includes a new HealthSet parameter, which is used to return the health state for a group of monitors. However, to use a rollup group, a list of names must be pipelined to Get-HealthReport. Unfortunately, Get-HealthReport -Identity does not support an array of names, so our recommended way to do this is to simply get the list of DAG members and pipe that to Get-HealthReport. For example to display a rollup summary of transport health on members of a DAG, you would run:

(Get-DatabaseAvailabilityGroup DAG1).Servers | Get-HealthReport -RollupGroup -HealthSet HubTransport

There are a couple of changes for Get-ServerHealth in CU1; namely, two parameters have also been added:

• HaImpactingOnly – This is used to display only monitors that have HaImpacting set.
• HealthSet – This is used to return the health state of a group of monitors.

Best Copy and Server Selection Changes

Best Copy and Server Selection (BCSS) is the algorithm used by Active Manager in Exchange 2013 to select the best database copy to activate in response to a failover or a target-less switchover. In CU1, a change was made so that the Primary Active Manager (PAM) now keeps track of the number of active databases per server, so that during BCSS it can honor the value of MaximumActiveDatabases, if configured.  The server holding the PAM role now keeps an in-memory state that tracks the number of active databases per server. When the PAM role moves or when the Exchange Replication service is restarted on the PAM, this information is rebuilt from the cluster database.

This change allows Active Manager to exclude servers that are already hosting the maximum amount of active databases when determining potential candidates for activation.  Prior to this change, Active Manager would not evaluate whether a potential server candidate for activation was already at its configured active database limit. Thus, if such a server were selected for activation, the activation process would fail during the mount attempt, and a new server would have to be selected (if available). This scenario is now avoided as a result of this change.

Other CU1 Changes

Of course there are other changes in CU1 besides the above, so be sure to read the Release Notes and other appropriate documentation when everything is released.