I have noticed that relevance for most MS Office Patches usually only evaluates if the name of the complete Office Suite exists
Ex
Microsoft Office 2000 Professional
Microsoft Office 2000 Premium
Microsoft Office 2003 Professional Edition
However when an Office Standalone application is installed on a system (lets say Outlook 2003) all fixlets for Office 2003 including Service Packs do not show up as relevant for this system as Oulook 2003 uses a different registry key and name from that of the complete Office 2003 suite.
Name: Microsoft Outlook 2003
This is the case for every standalone office application installed. We workarround this issue by creating custom fixlets to include the name and/or registry key of standalone office applications, however this is a great task to complete considering the number of patches out there. This is preventing several systems in our enviroment from being patched, not to mention unaccurate missing patches reports.
We have had a policy for quite a while to support all Office suite patches, but we didn’t offer patches for stand-alone Office applications because of lack of demand (we surveyed some customers a few years ago and we found that all the customers we talked to used full Office versions). It seems that at least two of our customers use standalone Office components now… are there others out there that can chime in? Supporting standalone Office components is a very large task initially and ongoing and the more customers that would benefit from this helps justify the case for adding support.
Also… HGA81, you mentioned you did a relatively simple change to the existing Office Fixlet to support the different Office componetns? Can you give us all some details about the changes you make? I think this will help others and also can help us investigate further.
We support standalone office apps as well. We do a standalone Outlook install and then multiple versions of the Office suite. Not sure why we do it, but we do!
Lets take the MS Office 2003 SP2 Upgrade Fixlet, Relevance (Section 6):
((exists key “HKEY_CLASSES_ROOT\Installer\Products” of registry) AND (exists key whose ((value “ProductName” of it as string contains “Office”) AND (value “ProductName” of it as string contains “2003”) AND ((value “ProductName” of it as string contains “Professional Enterprise Edition”) OR (value “ProductName” of it as string contains “Standard Edition”) OR (value “ProductName” of it as string contains “Basic Edition”) OR (value “ProductName” of it as string contains “Small Business Edition”) OR (value “ProductName” of it as string contains “Professional Edition”))) of key “HKEY_CLASSES_ROOT\Installer\Products” of registry))
We use Microfost Outlook 2003 stand-alone and the rest of the Office suite is MS Office 2000 pro. So if you evaluate the code above our Office 2003 Product will never show up as relevant as the “ProductName” value does not contain none of the values listed.
The actual “ProductName” for Outlook 2003 stand-alone is “Microsoft Office Outlook 2003” so in this case i will need to edit the relevance so it checks for its existance by adding the following line: OR (value “ProductName” of it as string contains “Outlook”). The Modified Relevance which includes Outlook 2003 Stand-alone looks like this:
((exists key “HKEY_CLASSES_ROOT\Installer\Products” of registry) AND (exists key whose ((value “ProductName” of it as string contains “Office”) AND (value “ProductName” of it as string contains “2003”) AND ((value “ProductName” of it as string contains “Professional Enterprise Edition”) OR (value “ProductName” of it as string contains “Standard Edition”) OR (value “ProductName” of it as string contains “Basic Edition”) OR (value “ProductName” of it as string contains “Small Business Edition”) OR (value “ProductName” of it as string contains “Professional Edition”) OR (value “ProductName” of it as string contains “Outlook”) )) of key “HKEY_CLASSES_ROOT\Installer\Products” of registry))
Sure, this sounds like a simple change. But imagine doing that for every Fixlet, for Every Office Stand-Alone app. of every MS Office Version… … I know this also is a lot of work for BigFix, but I’ll bet there are clients out there that don’t even know (yet) that they are affected by this! So it might not be a bad idea to include stand-alone Office apps in the relevance.
Actually, the main burden is ensuring high quality by testing all these combinations… but your relevance of just adding
OR (value “ProductName” of it as string contains “Outlook”)
looks pretty straightforward.
Is it correct to say that in your experiences so far, the BigFix Actions don’t need to be changed and that simply adjusting the relevance to detect the presence of the standalone application works in every case you have seen?
The above was just a quick example on how to modify the relevance to target the individual components, a pretty simple one. In some cases we have added code to the relevance to check for the existance of the registry key names of individual components along with the “ProducName” just to make sure we target the correct systems.
We have done this for Outlook 2003 (deploying SP2 and Office 2003 updates), and for Office 2000 stand-alone components (deploying SP3 and Office 2000 updates). So far we haven’t experienced any problems, modifying the relevance does the trick for for us, as long as we have the clients pointing to our original Installation points in our Null Session Shares.
I’ll keep my eyes open and will let you know if I see issues with these custom fixlets.
… I know this also is a lot of work for BigFix, but I’ll bet there are clients out there that don’t even know (yet) that they are affected by this! So it might not be a bad idea to include stand-alone Office apps in the relevance.