After hearing a couple of questions from customers and from folks inside of Microsoft, I thought it might be interesting to describe the setup contents and packaging strategy for Update Rollup 2 for Media Center 2005 in a bit more detail.  Most of this information can be gleaned using some of the setup reverse engineering tips and tricks I've posted in the past (here, here and here for example).

The main Update Rollup 2 setup package that can be downloaded here or via Windows Update on MCE 2005 machines contains a setup UI chainer that silently installs a set of update.exe hotfix packages behind the scenes.

The following is a list of the packages that are installed by the Update Rollup 2 setup chainer and the order in which they are installed:

• Windows hotfix KB903157 - this is a hotfix for Windows Media Player (wmp.dll) that fixes some bugs in Media Center-specific scenarios
• Windows hotfix KB891593 - this is a hotfix for DShow (quartz.dll and qdvd.dll) that fixes some bugs in Media Center-specific scenarios
• Windows hotfix KB895961 - this is a hotfix for termsrv.dll that fixes some bugs in Media Center Extender scenarios
• Windows hotfix KB899337 - this is a hotfix that updates the wireless networking control panel to allow joining wireless A/G networks
• Windows hotfix KB899510 - this is a driver update to support one of the types of DVD changers that Update Rollup 2 for MCE 2005 adds support for
• Windows hotfix KB888795 - this is an updated set of IR drivers (also previously released as a separate download and available for MCE 2004 and MCE 2005 without Update Rollup 2 installed)
• Windows hotfix KB902841 - this is a driver update to support another one of the types of DVD changers that Update Rollup 2 for MCE 2005 adds support for
• KB900325 - this is the main Update Rollup 2 package and contains all of the Media Center files that need to be updated
• New digital rights management (DRM) runtime package (wmfdist95.exe)

If you take a look at the KB numbers for each of these packages and cross-reference them against the list of log files produced during Update Rollup 2 setup that I listed in this blog post, you will see a nearly one-to-one mapping.  Update.exe will produce a log file for each hotfix, and the general guideline is that log files produced by update.exe should be named %windir%\kb#####.log.  The logs named %windir%\mcsetup.log and %windir%\mcsetup_ui.log are the log files produced by our setup UI chainer.

Update Rollup 2 has a dependency on the .NET Framework 1.1 and .NET Framework 1.1 SP1 being installed, but setup does not include these 2 dependencies as part of the chained setup package.  Windows Update will automatically check your system and include these packages when you choose to install Update Rollup 2 on a machine that does not have them installed.  Because of this, the download size reported on the Windows Update page will vary depending on the state of your machine at the time you choose to install Update Rollup 2.  If the machine does not have .NET 1.1 at all, thedownload size will be ~62 megabytes on Windows Update.  If it has .NET 1.1 but not SP1, the download size will be ~39 megabytes, and if it has .NET 1.1 and SP1, the download size will be ~29 megabytes.

We decided not to package the .NET Framework 1.1 or SP1 inside our chained setup package for a couple of reasons:

1. We wanted to optimize the download size for customers who already have .NET 1.1 installed.  The overall download size of Update Rollup 2 is 29 megabytes, and that size is approximately doubled if we also included the setup packages for .NET Framework 1.1 and SP1.  Based on our statistics about the download rate and market penetration for the .NET Framework 1.1, we decided that a significant number of Update Rollup 2 customers would already have 1.1 and could save quite a bit of bandwidth by not including them in our chained seutp package by default.
2. We wanted to retain some flexibility so that we could swap out .NET 1.1 SP1 for SP2 whenever that becomes available down the road if we want to.  Managing the download via Windows Update provides us better flexibility than packaging the .NET bits inside our setup package.  For example, if we had included .NET 1.1 SP1 in our chained setup package and wanted to update the bits to SP2, we would have to re-create our setup package and perform a full re-release.  Updating this dependency in Windows Update is much simpler and we can continue to use our currently available Update Rollup 2 setup package.