Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Adobe Acrobat v11 Applicability and Installed Rules

Anyone out there figured out how to get Patch Manager to work properly with Applicability and Installed Rules with regards to Acrobat Std/Pro?

Applicability:

Is Acrobat v11 installed (any version)?

Is Acrobat v11.0 thru 11.0.5 installed?

Installed:

Is Acrobat v11.0 thru 11.0.5 installed?

The only things I have been able to get working...

Applicable:

Acrobat v10 installed (any version)

With MSI Rule: Product Installed, Code: {AC76BA86-1033-F400-7760-000000000005}, Max Version: 10.1.9, Min Version: 10.0

Installed:

Acrobat v11.0.6 installed

With MSI Rule: Product Installed, Code: {AC76BA86-1033-FFFF-7760-000000000006}, Max Version: 11.0.6, Min Version: 11.0.6

Any suggestions are more than welcome.

Thanks!

Find more posts tagged with

Accepted answers

ak00

So since the Acrobat package is large, fortunately, i've only been using a "patch" that does nothing but check to see if the applicability and installed rules are working.

Also, what I didn't make clear was that I do actually have 2 separate packages.

One simply does the upgrade to v11 that includes the patch to 11.0.6, and the other is just the patch for those with older versions of 11.

The problem I was seeing is that because the applicability and installed rules weren't working right, those with v10 were getting the patch for v11, and those who just needed the patch were getting the whole v11 package.

Anyway, I think I figured out a set that worked.

Hopefully, someone else will find value, but holy c*r*a*p what a pain.

(So much easier when you just took the ruleset provided, added the install package, and published the package.)

For v11 Full

Applicability: MSI Product Installed Rule (Not)

ProductCode={AC76BA86-1033-FFFF-7760-000000000006}

Installed: Reg DWORD Value

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-1033-FFFF-7760-000000000006}

Registry Value: VersionMajor (enable 32-bit)

Comparison: GreaterThanOrEqualTo

DWORD Value: 11

For v11 Patch

Applicability: Reg DWORD Value

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-1033-FFFF-7760-000000000006}

Registry Value: VersionMajor (enable 32-bit)

Comparison: GreaterThanOrEqualTo

DWORD Value: 11

Installed: Registry String Value

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-1033-FFFF-7760-000000000006}

Registry Value: DisplayVersion (enable 32-bit)

Comparison: GreaterThanOrEqualTo

DWORD Value: 11.0.06

All comments

strict

i have this working, but i don't use msi rules, instead i use registry as thats what i find is most consistent. in addition i use the adobe customization wizard, which i find awesome, but should not affect what you are trying to do.

for prereq:

i just use the generic is x86 or is x64 arch.

for applicable:

FileVersionPrependRegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe" Value="Path" RegType32="true" Path="AcroRd32.dll" Comparison="LessThan" Version="11.0.6.70"

for installed:

note i am checking for the version of the dll as opposed the exe. this actually mattered with 11.0.5 because only the dll was updated to 11.0.5 whereas the exe was still at 11.0.4. so i found version checking the dll to be more reliable.

LGarvin

When you first wrote

instead i use registry as thats what i find is most consistent.

I immediately started writing (in my head) my response as to why using the registry is the least preferential option for building detection rules...

But then I noted you're actually using File Version with Registry rules, which is the normal type of rule to be used for this purpose.

note i am checking for the version of the dll as opposed the exe. this actually mattered with 11.0.5 because only the dll was updated to 11.0.5 whereas the exe was still at 11.0.4. so i found version checking the dll to be more reliable.

In reality, every update may be different, and you should build the package according to the actual file(s) being changed, not necessarily the EXE vs DLL.

ak00

That's exactly the help I needed. I recall having some issues with v10 using the file and registry - then settled on the msi - especially since it worked. Then on v11 - that exact issue you described with v11.0.5 still having the .4, led me back to the msi. But, I will give your settings a try and report back.

Many thanks for the quick response!

Edit #1

First observation:

Computers that already have the patch installed are still getting the patch presented to them for installation, but still showing as installed in PM (so at least the installation rule is working)

So what's wrong with my applicability rule for computers with v11 thru v11.0.5:

Using the AND operator and in this order....

FileVersionPrependRegSz Key="HKEY_LOCAL_MACHINE"Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe"

Value="Path"RegType32="true"Path="AcroRd32.dll"Comparison="GreaterThanOrEqualTo"Version="11.0.0.0"

FileVersionPrependRegSz Key="HKEY_LOCAL_MACHINE"Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe"

Value="Path"RegType32="true"Path="AcroRd32.dll"Comparison="LessThan"Version="11.0.6.70"

Thanks!

ak00

OK so definitely something isn't working right with the applicability rule:

Machines with the 11.0.6 patch are still showing up as applicable and then wanting to install the patch, but those with 11.0.5 are indicating that the patch is not applicable.

FileVersionPrependRegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe" Value="Path" RegType32="true"

Path="AcroRd32.dll" Comparison="LessThan"Version="11.0.6.70"

So now I'm back with not being able to use PM to deploy Acrobat - which is very frustrating.

Anyone else out there with suggestions?

LGarvin

Perhaps the first question of relevance is what the actual file(s) are that are changed in the 11.0.6 update. Those are the files that should be used to drive the logic rules. Most notably, if this is an Acrobat update... why are you testing the AcroRd32.dll?

Also something that may be relevance is which version of Acrobat is installed (is there a 64-bit version?). I see here that you're doing all of your testing in the 32-bit hive; if the installed instance of Acrobat is an x64 instance, these rules will fail because there wouldn't be any entries in the 32-bit hive.

ak00

Good point about which version - the clients are all Win 7 x64, but the application is the 32-bit version.

I'm using the AcroRd32.dll, simply because it was suggested. If someone happened to suggest that checking for bigbird.txt in the C:\ProgramFiles(x86)\SecretFolder works, I'd give that a shot too.

So I am back to the original question of how to get applicability rules working for Acrobat v11.0.6 (or .06).

Is Acrobat v11 installed (any version)?

Is Acrobat v11.0 thru 11.0.5 installed?

With Adobe Acrobat, every patch seems to change the detectability by any consistent means. It doesn't help that the File version is 11.0.6.70, but the Product Version is 11.0.06.70.

I recall when Patch Manager was able to detect Adobe Acrobat, but if it can't be done, then that's an answer too.

Thanks!

LGarvin

I'm using the AcroRd32.dll, simply because it was suggested. If someone happened to suggest that checking for bigbird.txt in the C:\ProgramFiles(x86)\SecretFolder works, I'd give that a shot too.

Well... testing the wrong file ... whether suggested or not, won't likely produce positive results. Last year I did a pair of webcasts on building packages. I'm pretty sure in the first webcast I talked about installing the update to a test machine and documenting both the pre-installation and post-installation scenarios, which are then used to derive the necessary detection logic for an update package. Unless you're getting explicit observations from another person who has built and tested successfully the exact same update you're working on, I'd say that "because it was suggested [by somebody on the Internet]", is probably a contributing factor to your issues with this package.

With Adobe Acrobat, every patch seems to change the detectability by any consistent means

Acrobat is not unique in this regard. EVERY package should be assumed to be unique until proven otherwise.

I recall when Patch Manager was able to detect Adobe Acrobat, but if it can't be done, then that's an answer too.

A very long time ago, before Adobe did, the EminentWare Extension Packs provided Acrobat v9 updates. (They're still in the catalog, so perhaps reviewing that logic might prove helpful?) Acrobat v10 was released by Adobe in late 2010, and they started publishing their own Acrobat catalog. There was no reason for EminentWare (then), nor SolarWinds (a year later, January 2012) to continue to package Acrobat updates. It's the same reason we don't package Reader v10 or v11 updates (except FULL installers, when released).

strict

1. Version checking the dll, as opposed to the exe, is right way to go in my experience of successfully patching adobe reader and adobe pro from versions 10.0.1 through 11.0.6. Sometimes referencing the exe works just fine. Again, like Lawrence said, it can vary and only testing will produce reliable results. With that, I use the DLL and it has worked reliably for me since 10.0.1. Additionally I am pretty sure PM references the DLL as opposed to the EXE when they have created their own Adobe packages for our patching pleasure.

2. I dont know if there is a 64bit instance of reader/pro, nor have I ever seen PM reference a 64bit instance on any Adobe package they have ever released? The 64bit OS architecture should not play a role in terms of registry when its a 32bit app. Stick with 32.

3. I agree the AND modifier you are using should rectify this, however that AND modifier has failed me before. In addition, I do have one more applicability rule, that I did NOT list above. The rule being: does the regkey exist for "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe" (32-bit). This rule is my 'upgrade' rule, so I am only patching computers that have the software. Note this rule is not specific to version obviously.

My first suggestion would be to just upgrade all your v10 clients, getting rid of the second rule you added. Is there any compelling reason to keep your v10's or v9's around? I can tell you from experience upgrading to v11 from v10 works great.

My second suggestion would be to completely start over, building this package from scratch. There have been MANY times where modifiers, version checks, and/or whatnots are just not doing what I expected them to do. I would copy whatever info i could out to notepad, delete the package, create a new package, and start over copying whatever i could back in, to save time. This start over approach has worked for me.

Another idea might be to 'group' your two version checks outside of your 'exists' rule. Maybe that will make the AND modifier do what it is supposed to?

ak00

So since the Acrobat package is large, fortunately, i've only been using a "patch" that does nothing but check to see if the applicability and installed rules are working.

Also, what I didn't make clear was that I do actually have 2 separate packages.

One simply does the upgrade to v11 that includes the patch to 11.0.6, and the other is just the patch for those with older versions of 11.

Anyway, I think I figured out a set that worked.

Hopefully, someone else will find value, but holy c*r*a*p what a pain.

(So much easier when you just took the ruleset provided, added the install package, and published the package.)

For v11 Full

Applicability: MSI Product Installed Rule (Not)

ProductCode={AC76BA86-1033-FFFF-7760-000000000006}

Installed: Reg DWORD Value

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-1033-FFFF-7760-000000000006}

Registry Value: VersionMajor (enable 32-bit)

Comparison: GreaterThanOrEqualTo

DWORD Value: 11

For v11 Patch

Applicability: Reg DWORD Value

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-1033-FFFF-7760-000000000006}

Registry Value: VersionMajor (enable 32-bit)

Comparison: GreaterThanOrEqualTo

DWORD Value: 11

Installed: Registry String Value

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-1033-FFFF-7760-000000000006}

Registry Value: DisplayVersion (enable 32-bit)

Comparison: GreaterThanOrEqualTo

DWORD Value: 11.0.06