Detecting Office 2003 Security Patch installations

[Sorenson]

One of my responsibilities is to deploy critical Microsoft patches as part of
the installation of our product. Since our product has features that
leverage off Outlook 2003 functionality, we are to deploy MS06-003 through
our product's installation.

To avoid re-installing this patch every time that a customer installs our
software, I need a method to detect whether this patch is already installed
on the target system.

Windows XP Security patches can be detected by inspecting the Registry Keys
beneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\HotFix. Beneath this key will be keys with names
corrsponding to the "KB" (Knowledge Base article) number of the patch. This
particular patch does not take this approach. And I cannot locate any key in
the Registry, after the patch is installed, that contains a reference to
KB892843, nor (as suggested by additional labelling see in Add/Remove
programs) to OLKINTLff or OUTLOOKff.

The technical articles on this patch suggest using the "Microsoft Baseline
Security Analyzer (MBSA)" for this purpose. But the articles also go on to
state that "...you may be able to use...". Since the tool may not apply to
this patch, and since this adds considerable bulk and complexity to our
install, I'd prefer a more compact solution. Another option suggested by the
articles is to user the versions for files that are included in the patch.
This can be problematic, particularly when a subsequent update replaces that
file, when that update may or may not negate the need to the Security Patch.

Does anyone have a solution?

 

[Lawrence Garvin \(MVP\)]

One of my responsibilities is to deploy critical Microsoft patches as part
of
the installation of our product. Since our product has features that
leverage off Outlook 2003 functionality, we are to deploy MS06-003 through
our product's installation.

You might want to check licensing issues on this matter. I believe you may
be restricted from 'redistributing' Office Updates via your product's
installation.

To avoid re-installing this patch every time that a customer installs our
software, I need a method to detect whether this patch is already
installed
on the target system.

Windows XP Security patches can be detected by inspecting the Registry
Keys
beneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\HotFix. Beneath this key will be keys with names
corrsponding to the "KB" (Knowledge Base article) number of the patch.
This
particular patch does not take this approach. And I cannot locate any key
in
the Registry, after the patch is installed, that contains a reference to
KB892843, nor (as suggested by additional labelling see in Add/Remove
programs) to OLKINTLff or OUTLOOKff.

The technical articles on this patch suggest using the "Microsoft Baseline
Security Analyzer (MBSA)" for this purpose.

MBSA cannot be used for detecting non-security updates.

But the articles also go on to
state that "...you may be able to use...". Since the tool may not apply to
this patch, and since this adds considerable bulk and complexity to our
install, I'd prefer a more compact solution. Another option suggested by
the
articles is to user the versions for files that are included in the patch.
This can be problematic, particularly when a subsequent update replaces
that
file, when that update may or may not negate the need to the Security
Patch.

Does anyone have a solution?

Uh.... how do you ensure the customer has a licensed installation of Outlook
2003???

 

[Sorenson]

You might want to check licensing issues on this matter. I believe you may

be restricted from 'redistributing' Office Updates via your product's
installation.

I'll check into this. I would think we'd be covered, given that we were the
ones responsible for deploying licenced copies of Office 2003 on the end-user
systems before shipment. Certain features of our software leverage off of
Outlook functionality. When customers order a system with those features, we
include a licensed copy of Outlook on their systems before we ship the
system. Now that these systems are in the field, corporate policy dictates
that we are to keep them up-to-date with respect to critical security
updates. They may or may not be connected to the internet. We are to
provide the updates when we upgrade our software.

MBSA cannot be used for detecting non-security updates.

Lovely. In my mind, microsoft's deployment of MS06-003 appears to be
incomplete.

Uh.... how do you ensure the customer has a licensed installation of Outlook
2003???

See above.


The question remains. Is there a method for detecting the installation of
this patch that's any better than checking for a particular version of a
particular file updated by this patch?

Our best attempt to date:
1. Get the Office 2003 install path by reading the value "Path" from the key
<HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Common\InstallRoot>
2. Get the file version from the file "Addrpars.dll" in that path.
3. If that version is at least 11.0.6550.0, then consider the patch already
installed.

Being an undocumented approach, I want some assurance that this method is
appropriate, or some other method that's more reliable, authorized or both.




--
Roger Sorenson
Software Engineer
GE Healthcare - Lunar

One of my responsibilities is to deploy critical Microsoft patches as part
of
the installation of our product. Since our product has features that
leverage off Outlook 2003 functionality, we are to deploy MS06-003 through
our product's installation.

You might want to check licensing issues on this matter. I believe you may
be restricted from 'redistributing' Office Updates via your product's
installation.

To avoid re-installing this patch every time that a customer installs our
software, I need a method to detect whether this patch is already
installed
on the target system.

Windows XP Security patches can be detected by inspecting the Registry
Keys
beneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\HotFix. Beneath this key will be keys with names
corrsponding to the "KB" (Knowledge Base article) number of the patch.
This
particular patch does not take this approach. And I cannot locate any key
in
the Registry, after the patch is installed, that contains a reference to
KB892843, nor (as suggested by additional labelling see in Add/Remove
programs) to OLKINTLff or OUTLOOKff.

The technical articles on this patch suggest using the "Microsoft Baseline
Security Analyzer (MBSA)" for this purpose.

MBSA cannot be used for detecting non-security updates.

But the articles also go on to
state that "...you may be able to use...". Since the tool may not apply to
this patch, and since this adds considerable bulk and complexity to our
install, I'd prefer a more compact solution. Another option suggested by
the
articles is to user the versions for files that are included in the patch.
This can be problematic, particularly when a subsequent update replaces
that
file, when that update may or may not negate the need to the Security
Patch.

Does anyone have a solution?

Uh.... how do you ensure the customer has a licensed installation of Outlook
2003???

 

[Lawrence Garvin \(MVP\)]

Our best attempt to date:
1. Get the Office 2003 install path by reading the value "Path" from the
key
<HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Common\InstallRoot>
2. Get the file version from the file "Addrpars.dll" in that path.
3. If that version is at least 11.0.6550.0, then consider the patch
already
installed.

I think that's the best you're going to be able to do, unless you want to
dig into writing COM+ code to use the WUA API to do the 'detection'. But
even then you're dependent on the availability of Microsoft Update or a WSUS
server for the catalog.

Being an undocumented approach, I want some assurance that this method is
appropriate, or some other method that's more reliable, authorized or
both.

Out of curiosity... how is your application dependent on the presence of
this update?

Is making your application dependent on the presence of this update
absolutely necessary?

btw, according to the sec bulletin, you -can- use MBSA v2 to test for this
update. I jumped the gun when I assumed it was not a sec update, though I
certainly /should/ have assumed it /was/, since it has an MSRC number!!!

Can I use the Microsoft Baseline Security Analyzer (MBSA) 2.0 to determine
whether this update is required?
Yes. MBSA 2.0 will determine whether this update is required for Office XP,
Office 2003, Office XP Multilingual User Interface Packs, Office 2003
Multilingual User Interface Packs and Exchange 2000 Server. MBSA 2.0 can
detect security updates for products that Microsoft Update supports. For
more information about MBSA, visit the MBSA Web site.

MBSA 2.0 does not support the detection of Exchange 5.0 Server, Office 2000,
Office 2000 MultiLanguage Packs or Office 2003 Language Interface Packs. You
should use MBSA 1.2.1 to determine if this update is required. MBSA 2.0 can
detect security updates for products that Microsoft Update supports. For
more information about the programs that Microsoft Update and MBSA 2.0
currently do not detect, see Microsoft Knowledge Base Article 895660.

--
Roger Sorenson
Software Engineer
GE Healthcare - Lunar

One of my responsibilities is to deploy critical Microsoft patches as
part
of
the installation of our product. Since our product has features that
leverage off Outlook 2003 functionality, we are to deploy MS06-003
through
our product's installation.

You might want to check licensing issues on this matter. I believe you
may
be restricted from 'redistributing' Office Updates via your product's
installation.

To avoid re-installing this patch every time that a customer installs
our
software, I need a method to detect whether this patch is already
installed
on the target system.

Windows XP Security patches can be detected by inspecting the Registry
Keys
beneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\HotFix. Beneath this key will be keys with names
corrsponding to the "KB" (Knowledge Base article) number of the patch.
This
particular patch does not take this approach. And I cannot locate any
key
in
the Registry, after the patch is installed, that contains a reference
to
KB892843, nor (as suggested by additional labelling see in Add/Remove
programs) to OLKINTLff or OUTLOOKff.

The technical articles on this patch suggest using the "Microsoft
Baseline
Security Analyzer (MBSA)" for this purpose.

MBSA cannot be used for detecting non-security updates.

But the articles also go on to
state that "...you may be able to use...". Since the tool may not apply
to
this patch, and since this adds considerable bulk and complexity to our
install, I'd prefer a more compact solution. Another option suggested
by
the
articles is to user the versions for files that are included in the
patch.
This can be problematic, particularly when a subsequent update replaces
that
file, when that update may or may not negate the need to the Security
Patch.

Does anyone have a solution?

Uh.... how do you ensure the customer has a licensed installation of
Outlook
2003???

 

[Sorenson]

I'll look into integrating MBSA into our installation.

Our application has the ability to interface with the Outlook Address Book.
The data contained in the Address Book can be used to select the target for
sending reports. These reports contain the results from an exam taken with
our instruments. This is not my area of expertise in the application. I do
not know the specifics of why this led to the selection of Outlook 2003 as
the application to provide the Address Book.