Exchange 2010 SP1 Prerequisites on 2008 R2 SP1


After Exchange 2010 SP1 became publicly available I wrote, apart from the SP1 changes, also on the prerequisites differences, comparing Windows Server 2008 with Windows Server 2008 R2. Note that these prerequisites are additional to the server roles and features required to install Exchange 2010 server roles.

With the recent release of Windows Server 2008 R2 Service Pack 1 a new operating system level was introduced to the spectrum. It would be interesting to see what impact R2 SP1 has on these prerequisites. When we put that Exchange 2010 SP1 prerequisites in a table, comparing them to Windows Server 2008 R2 prerequisites, we get the following:

Component Windows Server
2008 R2
Windows Server
2008 R2 SP1
AD RMS KB979099
.NET Framework 2.0 KB979744

KB977020 (CAS)

.NET Framework 3.5 KB982867
ASP.NET 2.0 KB983440
UCMA (UM) UCMA Runtime 2.0 UCMA Runtime 2.0
Content Filtering

(Hub, Mbx)

Office 2010 Filter Pack Office 2010 Filter Pack

That’s excellent, no hotfixes to install upfront and the required reboot that goes with it. For the suspicious, here’s a what Setup reported missing on a freshly installed Windows Server 2008 R2 SP1 server:

image

So, we can conclude going straight to Windows Server 2008 R2 SP1 with Exchange 2010 SP1 should make the job of deploying Exchange 2010 SP1 easier and save you some time.

Error 0x00f0818 or 0x800b0100 installing Windows Server 2008 R2 SP1


As the guy behing WorkingHardInIT blog pointed out here, there are people experiencing issues when installing Service Pack 1 on Windows 2008 R2 (or Windows 7) related to missing or corrupted files in the WinSXS\Manifests or Servicing\Packages folders. The related error code is 0x00f0818, but from personal experience I can say may also apply when Windows Update produces error code 0x800b0100.

The missing or corrupted files can be viewed by the System-Update-Readiness-Tool which will generate logfiles at %SystemRoot%\Logs\CBS. For example, a failing SP1 installation might produce the following CheckSUR.log (excerpt):

Checking Package Manifests and Catalogs
(f)    CBS MUM Corrupt    0x800F0900    servicing\Packages\Package_1_for_KB2416471~31bf3856ad364e35~amd64~~6.1.1.0.mum        Line 1:
(f)    CBS Catalog Corrupt    0x800B0100    servicing\Packages\Package_1_for_KB2416471~31bf3856ad364e35~amd64~~6.1.1.0.cat
..
Checking Component Store
(f)    CSI Manifest All Zeros    0x00000000    winsxs\Manifests\amd64_wpf-presentationhostdll_31bf3856ad364e35_6.1.7600.16542_none_cc28a17e399280f3.manifest    amd64_wpf-presentationhostdll_31bf3856ad364e35_6.1.7600.16542_none_cc28a17e399280f3
..

The blog mentioned gives a nice writeup on how to solve this issue by (temporarily) fixing ACLs and then replacing the files mentioned in CheckSUR.log by copying them off a second – identical – installation. But this may get clumsy when the section “Unavailable repair files” mentions a lot of Manifests and Packages, and prone to error with these long filenames.

Fortunately, we can automate this process a bit as I’ll describe below. Before doing this, follow the steps contained in the mentioned blog to set up permissions correctly (don’t forget to reverse changes afterwards). Note that in this procedure I’m going to use a drive letter X: for storing the repair files.

First, copy the CheckSUR.log to a file named files.txt. Edit files.txt and remove the line “Unavailable repair files:” and everything before that. Save the file.

Then, open an command prompt on the system we’re going to copy these files off and enter the following:
for /f %f in (files.txt) do @copy %SystemRoot%\%f X:\%f /y

Next, on the system with issues, open an elevated command prompt and enter the following to make backup copies of the corrupt files:
for /f %f in (files) do @move %SystemRoot%\%f %SystemRoot%\%f.bak /y

Finally, enter the following command to replace the missing or corrupt files:
for /f %f in (files) do @copy X:\%f %SystemRoot%\%f /y

Of course, this procedure can be adjusted to your liking; you could for example copy the repair files directly off another system using the system share.

Windows Server 2008 R2 SP1 RTM’ed


Service Pack 1 for Windows Server 2008 R2 (and Windows 7) being released to manufacturing (RTM) today.  This is great news after an extensive beta period. Organizations can now plan for SP1 deployments. With SP1, organizations can use new features like Dynamic Memory, for increased virtual machine density, and RemoteFX for an enhanced Remote Desktop experience.

The availability of Service Pack 1 may also encourage customers with “SP0 anxiety” to start implementing Windows Server 2008 R2 or Windows 7.

Availability of SP1 is scheduled as follows:

  • February 16:  Available to TechNet/MSDN subscribers and Volume Licensing customers;
  • February 22:  General availability through Download Center and Windows Update.

Update: The Exchange Team blog published an item stating Windows Server 2008 R2 SP1 support for:

  • Exchange 2007 SP3
  • Exchange 2010 RTM
  • Exchange 2010 SP1

So, unlike earlier rumors, you don’t need to wait for Exchange 2010 SP2. What this means for the list of hotfix prerequisites remains to be seen. Note that the Exchange 2010 Supportability Matrix doesn’t mention Windows Server 2008 R2 SP1 yet.