First published on TECHNET on Aug 19, 2005
Here is some background that led to the decision to take this dependency on Windows Installer (MSI) 3.1v2 in MOM 2005 Service Pack 1. I completely understand how this dependency may complicate or delay your deployment of MOM 2005 SP1 particularly in highly locked down environments.
The primary reason for taking this dependency is that this version of Windows Installer correctly handles the scenario where a minor update package is installed when an obsolete or superseded patch also exists. If MOM 2005 SP1 had not taken this Windows Installer 3.1v2 dependency, this Windows Installer scenario would have meant that any customer who had deployed an agent hotfix would have not been able to correctly update to SP1. More information about this Windows Installer fix can be found in KB article
A second reason is that multihoming an RTM agent with SP1 agent on IA64 was broken. The fact that this only affects customers with IA64 and multihoming certainly makes this a secondary issue.
A side benefit of having to take this dependency is that now customers can uninstall future patches and service packs beyond MOM 2005 SP1. This is a significant supportability improvement that was not possible when were used Windows Installer 2.0x, but was not a driving factor in the decision to move to 3.1v2.
Windows Installer 3.1v2 update
(version 3.1.4000.2435) was released as a High Priority update on 5/12/2005. Installing the Windows Installer update generally requires a reboot following installation. If you have not installed this, it is useful to consider bundling the Windows Installer update with recent security updates that have been released.
Finally, note that it is fine to leave agents at RTM version after the server is updated to SP1. This is a fully supported scenario and allows you to get the MOM servers to SP1 first and then update agents as managed servers get Windows Update 3.1v2.
Feel free to leave comments - I appreciate your feedback.