Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 10

Creating a package for MSXML 4.0 SP3

Jump to solution


Has anyone created a package to deploy MSXML 4.0 SP3 as an upgrade for systems which it has been installed as an MSI or merge module? Presently have a number of servers and workstations which have this end of life and insecure deployed. We will be reviewing what applications use it but it would be good to have an option to upgrade from SP2 to SP3 which MS never provided using WSUS.



Labels (1)
0 Kudos
1 Solution

I've uploaded my package and it can be found here

View solution in original post

0 Kudos
9 Replies
Level 17

One last note.... this morning we added the MSXML v4 Service Pack 3 package to the Patch Manager catalog.

Level 11

I created a package to install MSXML 4.0 SP3 several months ago and haven't had any issues with it. It was pretty trivial to create once I knew the file location and the version number I was looking for. First I check for the existence of msxml4.dll in Windows\system32 on x86 machines or Windows\syswow64 on 64 bit machines and if it exists but is less than 4.30.2100.0 the patch is installed.

0 Kudos

Cool, Justin!

If you would be willing to export that package (without binaries) and post it to the Patch Manager Content Exchange, I suspect Mike would appreciate that. :--)

0 Kudos

That would be very helpful to myself and any others reading this thread.

0 Kudos

I've uploaded my package and it can be found here

View solution in original post

0 Kudos

Thank-you very much for your help with this.

0 Kudos
Level 17

Greetings Mike

I'm not aware of any specific instances of packages for MSXML4 SP3, but it should be a fairly trivial package to build.

The download bundle provides an MSI installer, so the only real requirement is to set up rules to test the current version of MSXML4 that is installed.

On a 32-bit system, you'll want to test MSXML4.DLL and/or MSXML4R.DLL which should be found in %windir%\SYSTEM32

On a 64-bit system, you'll find those files in %windir%\SysWOW64; MSXML v4 is a 32-bit only product.

Prerequisite Rules:

- test for architecture and windows versions that support MSXML4 SP3

Applicability Rules

- test for File Version of msxml4.dll Less Than or Equal to the File Version of the SP3 msxml4.dll

- test for File Version of msxml4r.dll Less Than or Equal to the File Version of the SP3 msxml4r.dll

Installed Rules

- test for File Exists of msxml4.dll with specified File Version value for SP3's msxml4.dll

- test for File Exists of msxml4r.dll with specified File Version value for SP3's msxml4r.dll

Your inquiry does call attention to an interesting situation. EoL for MSXML4 SP2 was April 13, 2010, which means any security issues that existed in MSXML4 SP2 would not have been fixed in the past 3.5 years. There WAS a Security Update for MSXML4 SP3 released in January, 2013 (MS13-002, which superseded MS12-043, June, 2012), which almost certainly represents a vulnerability that also exists (and is unpatched) in MSXML4 SP2.

I just posted on PatchZone about this. Thanks for asking about it!

Thank-you for the details. Can I assume that I can use x86 and x64 rules in the same applicability rule section?

If I then deploy but not approve the package will WSUS detection work to provide an assessment of the systems requiring it?


0 Kudos

Yes. You'll need to create a structured logic block, that would look something like this:

When Architecuture = x86

     - test msxml4.dll located in SYSTEM32 folder

When Architecture = x64

     - test msxml4.dll located in SYSWOW64 folder

You can see examples of this logic flow in some of the prepackaged update.. I think the Flash update packages use this structure.