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.
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.
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
"Name","Edition","AdminDisplayVersion","ServerRole"
"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:
$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).
