IT tutorials
Applications Server

Installing Exchange 2013 : Versions, cumulative updates, and service packs (part 1) - Cumulative updates, Version numbers

11/15/2013 8:37:48 PM
- Windows 10 Product Activation Keys Free 2019
- How to active Windows 8 without product key
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Exchange 2007 marked a new approach to support, delivered in the form of updated code. Previous versions of Exchange focused on regular service packs, which became very large updates similar in many respects to the release of a new version of the product. The current approach divides updates into two kinds of releases for which you can plan:

  • Service packs (SP). Microsoft releases a new service pack for Exchange on average once a year. A service pack typically includes new functionality as well as fixes and is intended to mark a distinct point in a product’s development. In addition, a service pack provides customers with a release that they can target for installation at a suitable point in their maintenance cycle. At the time of writing, Microsoft has indicated that it will release a service pack for Exchange 2013, but code is not yet available.

  • Cumulative updates (CU). Cumulative updates appear roughly every three months and are cumulative in that CU3 includes all the fixes issued in CU1 and CU2. Therefore, you can apply the latest CU to update a product with all the current released fixes or use the latest CU to install Exchange 2013 on a new server. Cumulative updates are issued on the web and announced on the Microsoft EHLO blog. Microsoft might also make some hotfixes or security updates that pertain to specific situations available separately, and it’s worth checking with Microsoft about any important hotfixes that exist for functionality that is important to your deployment before you plan to deploy a cumulative update.

It is sometimes difficult to understand the differences among a cumulative update, a service pack, and a new version of a Microsoft server product. We’ll tease this issue out in this section.

A best practice for server software levels

It is best practice to ensure that all servers in an organization run at the same software level, including roll-up releases. There is no good logic suggesting that servers should run at different software levels for any sustained period. This is especially important when the Active Directory schema is updated by a service pack to introduce new properties for objects Exchange uses. In some cases, feature changes or bug fixes in service packs require you to upgrade all servers to the same service pack level; Microsoft does a good job of documenting these requirements, and you should follow them.

1. Cumulative updates

Software maintenance is an ongoing process. In the case of Exchange, the outcome is a regular update that represents the best current state of the software as updated with whatever fixes are known at the time the update is produced. From Exchange 2013 onward, Microsoft operates a policy of running the same code base in both Exchange Online and on-premises deployments. Microsoft deploys updates within Exchange Online on a frequent basis to fulfill one of the promises of cloud platforms, which stipulates that users have access to evergreen technology that is continually updated and refreshed.

On-premises customers gain access to the code through a complete software build called a cumulative update (CU). Each CU represents the most recent update for Exchange 2013, including all the fixes for known software issues at the time the CU was built. A CU can be used to bring an existing server up to the latest software version or to install Exchange 2013 from scratch on a brand-new server.

Gaining fast access to new functionality can be extremely valuable, especially if the new feature addresses a long-held need for a company. The downside is that changing the way a product works can affect users, sometimes for the worse. Microsoft simply reacts to the competitive demands of an online world when it slipstreams new features into products outside major releases. Users might not realize that an update has happened unless the new software reveals a new feature in the user interface, but many changes might have occurred in the way Exchange functions.

For example, Microsoft released Exchange 2010 SP2 RU4 (roll-up update number 4 for Exchange 2010 service pack 2) in August 2012 and changed the way the Managed Folder Assistant (MFA) processes calendar and task items in user mailboxes. Up to that point, an administrator could create a retention policy that included a default retention tag that, for example, caused all items that did not have a more explicit tag assigned to them to be moved into the Deleted Items folder after 120 days. The MFA did not evaluate calendar and task items and thus did not apply the action assigned by the default retention tag. Exchange 2010 SP2 RU4 updated the MFA to enable it to evaluate calendar and task items; any mailbox that came under the control of a retention policy that included a default retention tag would have items in the calendar and task folders processed the next time the MFA ran following the installation of Exchange 2010 SP2 RU4. The upshot was that MFA could remove items from mailboxes in an unexpected manner.

The servicing model used for Exchange 2013 means that Microsoft issues cumulative updates on a quarterly basis. Note that “quarter” does not mean “every three months” because it is quite possible that Microsoft will issue an update in July (the first month of the third quarter) and follow it up with the next update in December (the last month of the fourth quarter). The different intervals allow Microsoft to test an update in production by deploying it into its Office 365 datacenters, which means that the code running in Exchange Online is usually a couple of months ahead of what is available to on-premises customers. Assuming that all goes well, the update is then released to on-premises customers with the inherent promise that because it works for Office 365, customers should be confident that the update will deliver acceptable quality and performance when deployed on-premises. In addition, customers who run hybrid deployments will know that after they deploy the latest cumulative update on-premises, essentially they then run the same software version for the on-premises and cloud portions of their deployment.

The new servicing model encourages customers to install updates as they are released by Microsoft. If a customer reports a bug that is fixed in a later release to the software that they run, they must install the latest update before Microsoft will investigate a problem further. If a bug is discovered in an update, Microsoft will fix the problem and release the fix as part of the next cumulative update with the aim being to reduce the number of individual hotfixes released to customers. Put another way, given the regularity of the update release cycle, customers should not have to wait long before they receive an update that contains fixes for any problems that they report. Best practice is to deploy the same update on all servers within an organization because it doesn’t make sense to have different versions in use in different places. In particular, make sure that all the servers in a DAG are brought up to the same software version as soon as practically possible.

Because Exchange 2013 cumulative updates appear on a regular basis, administrators need to be aware that functionality can change and be prepared to test the updates as they appear with this in mind to assess whether changes will affect the way Exchange is used within their company. In addition, administrators must be sure that any third-party software that operates alongside Exchange 2013 is verified to work properly with a CU before it is deployed into production. Note that the installation of a cumulative update will wipe any trace of customized configuration files (for example, to customize Outlook Web App), so some care has to be taken to preserve and reapply these kinds of changes when you deploy these updates.

Given that cumulative updates allow customers to keep their servers updated more frequently than having to wait for an annual service pack, the role of a service pack is different for Exchange 2013 than it was for previous releases. With Exchange 2007 and Exchange 2010, you had no option but to wait for a service pack to appear before you could access new functionality or see new documentation. Now we have quarterly cumulative updates that include bug fixes, new functionality, and documentation updates. The new servicing model is excellent for customers who can cope with such a rapid release cadence, but it can pose very real difficulties for customers who operate highly regimented environments with strict limits on when software updates can be applied. In addition, the need to validate new releases against realistic test environments that mimic the essential characteristics of the operational systems, including alongside third-party and home-grown applications, is often a demanding exercise, especially when considered against the need to provide a service to end users, dealing with vacation, training, other absences of personnel, and other day-to-day problems. This is where a service pack proves valuable because customers can plan for the release of a service pack and incorporate the need for testing and validation into their regular maintenance cycle.

Microsoft has indicated that it will release a service pack for Exchange 2013 in the future. When that occurs, it will be interesting to compare the contents of the service pack and assess its true value. In the interim, the story around quarterly cumulative updates continues to unfold and customers continue to cope with the accelerated cadence.

Testing cumulative updates

Make sure that you test cumulative updates before you deploy them into production because sometimes, in previous versions of Exchange, problems occurred during or after the installation of the update. Sometimes the fault is not exclusively with the Exchange developers and is exposed when customers deploy the new software, as when an Internet Explorer problem caused an issue for the Exchange 2010 Management Console. Predeployment testing is an absolute necessity to detect problems that might sneak past the large Microsoft array of automated tests. It’s also important to install cumulative updates with accounts that have full administrator permission to ensure that all files are properly updated.

2. Version numbers

Exchange build numbers tell you the exact version of the software. The format used is:

<product version>.<service pack number>.<major build number>.<minor build number>

A version number such as 15.00.0516.032 means:

  • Product version 15. Exchange 2013 is a component of the Office 15 wave of products. Exchange 2007 was version 12, and Exchange 2010 was version 14. There was no version 13.

  • Service pack 00. No service packs have been applied, so you know that this is the original (RTM) version of the product.

  • Major build 516. Microsoft builds new versions of the product on an almost daily basis, and the build number increments sequentially, so this is build 516, the build used for the RTM version of Exchange 2013. Build numbers differ from version to version, so there is no sequential update from the builds used for Exchange 2010 to those for Exchange 2013.

  • Minor build 032. Thirty-two minor updates have been applied to major build 516. The number of minor updates is accounted by the way Microsoft tweaked the last major build of Exchange 2013 with a series of minor fixes as it drove to complete the product.

If you view server details through the Server node of EAC, you can see the version number of every server in the organization. This is broadly equivalent to executing the following EMS command:

Get-ExchangeServer | Select Name, ServerRole, AdminDisplayVersion

For administrative purposes, you might want to capture the software edition that’s installed on each server and output this information to a comma-separated-value (CSV)–formatted file that you can later analyze with Microsoft Excel, Microsoft Access, or another program that is capable of reading CSV data:

Get-ExchangeServer | Select Name, Edition, AdminDisplayVersion, ServerRole | Export-CSV C:\TEMP\Servers.CSV

The data exported should look similar to this:

#TYPE Selected.Microsoft.Exchange.Data.Directory.Management.ExchangeServer
"EXSERVER1","Enterprise","Version 15.0 (Build 516.32)","Mailbox, ClientAccess"
"EXSERVER2","StandardEvaluation","Version 15.0 (Build 516.32)","Mailbox, ClientAccess"

Version 516.32 is the RTM release of Exchange 2013. The development team released this version to manufacturing on October 11, 2012. The first production customer deployments were already in progress before this time as part of the Microsoft Technology Adoption Program. General deployments in the wider customer base began in March 2013 after the release of Exchange 2013 RTM CU1 and Exchange 2010 SP3 and Exchange 2007 SP3 RU10, the versions needed to interoperate with Exchange 2013. The code build number for Exchange 2013 RTM CU1 is 620.29 while the value for Exchange 2013 RTM CU2 is 712.22.

Exchange also writes information about version numbers into the system registry (Figure 1). You can retrieve this information with some Windows PowerShell code to identify the major and minor builds that are installed on a server. In this instance, MsiBuildMajor is 516, and MsiBuildMinor is 32, so this server runs version 516.32, or the RTM release of Exchange 2013. The following example shows Windows PowerShell code you can use to fetch the Exchange version information from the system registry:

A screen shot of the Registry Editor showing where Exchange stores details of its version number (HKLM\Software\Microsoft\ExchangeServer\V15\Setup).

Figure 1. Installation information in the system registry

$RegExSetup = 'Software\\Microsoft\\ExchangeServer\\v15\\Setup'
$Server = (Get-Content env:ComputerName)
$Registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $Server)
$RegKey = $Registry.OpenSubKey($RegExSetup)
$V1 = "MsiBuildMajor"
$V2 = "MsiBuildMinor"
$BuildMajor = ($RegKey.GetValue($V1))
$BuildMinor = ($RegKey.GetValue($V2))
Write-Host $Server "runs version" $BuildMajor "." $BuildMinor

Exchange also stores information in the system registry about updates that are installed on a server. These data are held in a series of entries (one for each update) at HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\AE1D439464EB1B8488741FFA028E291C\Patches. The subkeys that provide information about each roll-up update are called DisplayName (the name of the update) and InstallDate (the date it was installed on a server).

- Exchange Server 2013 : Deploying an Exchange 2013 server (part 3) - Recovering a failed server
- Exchange Server 2013 : Deploying an Exchange 2013 server (part 2) - Setup logs, Uninstalling Exchange
- Installing Exchange 2013 : Deploying an Exchange 2013 server (part 1) - Running Setup
- Installing Exchange 2013 : Creating the Exchange 2013 organization
- Installing Exchange 2013 : Types of Active Directory deployment that support Exchange
- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 4) - General Application Settings, Apps, Navigation
- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 3) - Backup and Restore, Security
- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 2) - System Settings, Monitoring
- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 1) - Application Management
- Monitoring Microsoft Lync Server 2010 : Installing Operations Manager 2007 R2 (part 2) - Importing Management Packs, Deploying OpsMgr Agents
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
Popular tags
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS