Adobe Reader installation problem

However, the command prompt window does not stay on my screen, and the txt file does not exist when I go looking for it.

To provide for user-interactivity with the installation experience, you will need to enable the "Advanced Option" for Install can request user-input. Please note, however, that when this option is enabled, you cannot install the package as a scheduled event on the client, or using Patch Manager. The installation must be initiated by a logged-on user at the local machine. If you're only doing this as a testing exercise, then this option will give you the ability to complete the test.

Unless you have some specific need for awareness to the user, the preferred option here would be to run the XCOPY (or ROBOCOPY) in silent mode. If you need actual confirmation that the file was copied, add a rule to the Installed Rule ruleset to check for the existence of that file where it should be. If the file is not there, the package will be reported as "NotInstalled". It may take a bit more investigation on that account, but when it is reported as "Installed", you'll know for certain that it includes the customization file.

Additionally, if I uninstall Adobe Reader, Windows Update never again detects that I require the Adobe Reader install.

This would suggest a defect in one of the rules in the package and/or an incomplete uninstallation of the product. The objective will be to observe the state reported for the package in the console ("NotApplicable" or "Installed") and then determine which rule it is that's causing the WUAgent to return that state.

Worthy of note... we did not publish a package for 11.0.05, which suggests that Adobe did not release a full-installer for that version (or else we missed it), so I'm curious whether it's a typo in your message, or how you're applying transforms to a v11.0.05 package.

To answer your questions...

1. It was showing as Not Applicable post-uninstallation.

2. I found in another thread that simply calling the batch file from Package Boot won't work. I changed that now to call cmd.exe with the parameter /C %modulepath%\block.bat, run from %windir%\system32. Unfortunately, I then ran the test again without thinking, and it got stuck waiting for user interaction because of the "pause" statement that I forgot to remove from the batch file. Again, I uninstalled Adobe Reader so I could run the test again, and I'm back to the non-detection thing.

3. Yes, I mean 11.0.05. The version of the setup file I have is 11.0.4.63, which corresponds to 11.0.05 (why they have a different version number in the exe and in the About screen baffles me). And just in case, I have AdbeRdrUpd11004.msp and AdbeRdrSecUpd11005.msp included in the package and called from the setup.ini file. This part, I should clarify, works as I expect it to. My problem is purely with the text file getting put where I want it and, after uninstalling, Windows Update not redetecting the update.

To add a little bit more, I don't see why duplicating a package and approving that one would suggest an incomplete uninstallation. The rules are identical from the old package to the duplicated one, and the cruft . The only thing that should change is the package ID, right? And Windows Update shouldn't care what the package ID is if the applicability and installed rules are met (or not).

I tried reduplicating the package again and this time it didn't work. Ignore what I said above.

The only applicability rule in place for this package is:

NOT File Exists: Path=%programdata%\blocks\rdr11005block.txt Common Path=NONE Version= Size=0 Modified Date=N/A Creation Date=N/A Language=Language Neutral

I've checked. That file does not exist. This package should be detected as needed and then installed.

1. It was showing as Not Applicable post-uninstallation.

Then you'll want to examine each of your rules in the Prerequisite and Applicability rulesets and determine which rule(s) are not returning a true value, thus causing the update to be NotApplicable when it should be.

3. Yes, I mean 11.0.05. The version of the setup file I have is 11.0.4.63, which corresponds to 11.0.05 (why they have a different version number in the exe and in the About screen baffles me).

Most interesting. I'm not aware of this snafu. I'll have to investigate. From what I can see on the surface our 11.0.04.63 package downloads AdbeRdr11004_en_US.exe, and (as stated), nobody here is aware of a full-installer for 11.0.05. Interestingly, I'm observing (just now) on systems in my lab that both our 11.0.04.63 and Adobe's 11.0.05 Update show as installed on exactly the same systems, and that obviously makes no sense. Normally my inclination would be to not trust the Adobe MSP package; they're known for having defective logic. In fact, while the Reader About->Help screen says it's 11.0.5, the AcroRd32.exe is actually still 11.0.04.63 -- meaning, among other problems, that the 11.0.5 MSP is not detecting as NotInstalled, when it should be.

Regarding the duplicated package scenario, the reason duplicating a package can make a difference is because a duplicated package generates an entirely new UpdateID, and the WUAgent sees that as an entirely new update package. The original update package is still cached in the local datastore, along with the last known installation state of the package. Which begs this question.... after you uninstalled the package from the client... Was a reboot required? Did you reboot the client? Did you re-run a WUAgent detection so that it could re-evaluate the package detection logic?

The only applicability rule in place for this package is: NOT File Exists: Path=%programdata%\blocks\rdr11005block.txt Common Path=NONE

This will be problematic for many reasons. A "NOT File Exists" rule is a challenging choice to use as an Applicabilty Rule in any case. The better choice here is to version the FlagFile and use a FileVersion rule to test for older file versions. (In the FileVersion rule, a missing file is considered to be version 0.0.0.0 and will always return TRUE when the file is missing.)

In addition, you cannot specify environment variables in the Path value -- this is what the Common Paths value is designed to permit; however, there is no Common Path identifier for the C:\ProgramData folder. Also, I'd suggest that C:\ProgramData is probably not the place to put this file, since this is actually a user-defined (you, being the user) file, not a program defined file. (I'm not even sure if the WUAgent has visibility into the ProgramData folder.) As I understand the plan .. this is merely a FlagFile that indicates that your customized Reader has been installed. I would suggest putting that file IN the Adobe Reader program files folder right along with the AcroRd32.exe, or in the \Users\Administrator folder tree.

Regarding your detection logic.... you'll want to check for the FlagFile ONLY in the Installed Ruleset. If the FILE EXISTS and AcroRd32.exe = <theCorrectVersion>, then the package isInstalled. End of Story.

If the file does not exist, then isInstalled=FALSE, and whatever else you have configured in the Applicability Rules will detemine if the update is required (e.g. AcroRd32.exe < 11.0.04.63)

LGarvin wrote: This will be problematic for many reasons. A "NOT File Exists" rule is a challenging choice to use as an Applicabilty Rule in any case. The better choice here is to version the FlagFile and use a FileVersion rule to test for older file versions. (In the FileVersion rule, a missing file is considered to be version 0.0.0.0 and will always return TRUE when the file is missing.)

OK, so in that case, would it be equivalent to check File Version equal to 0.0.0.0?

No, you need to give it a real version number, e.g. 1.0.0.0, and then the implicit test that occurs when the file is not present (e.g. the assumption that the file version is 0.0.0.0 because there is no other file version attribute to actually obtain from an existing file)... will take care of the rest.

Okay, I've discovered something. It seems that the 11.0.05 patch alters one file in two locations

:

C:\Program Files\Adobe\Reader 11.0\Reader\AIR\nppdf32.dll

C:\Program Files\Adobe\Reader 11.0\Reader\Browser\nppdf32.dll

The date/time stamp changed from 9/5/2013 10:04 AM to 9/26/2013 2:00 PM

The file version stamp changed from 11.0.4.63 to 11.0.5.3

The product version stamp changed from 11.0.04.63 to 11.0.05.3

Considering what the patch actually fixed, this makes sense. The .exe file was not touched during the patch. That would explain why the version number didn't change.

This would help to identify which PCs have the 11.0.05 security patch installed and create a set of applicability/installed rules. Unfortunately, it doesn't fix the flagfile problem. I saw your post on SpiceWorks (sorry, I wasn't trying to do an end run around the support here, but I figured that was enough of a separate issue to ask the minds there for help), but I can't get file creation date to work, either. This is really starting to become a problem. I really do not want to have to do the initial push by hand.

Ouch. That certainly complicates the applicability testing!

Good catch, Justin!

Hey.. no problem with the SpiceWorks post; that was actually a great place to ask the more generic question about file version attributes and managing that information.

I just happen to be active in both communities. :-)

What issues are you having using the File Creation date?

Happy to help track those down.

I've seen you over at SpiceWorks, but I never put two and two together to realize it was the same person.

So it seems we've got a couple separate issues going here. How to test for applicability, and how to get the flagfile to work properly. Let's break this down and get the package working without the flagfile first. Here's what I have currently:

Applicability Rule

NOT File Version with registry value: Hive=HKEY_LOCAL_MACHINE Registry Path=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe Registry Value=Path Use 32-bit registry=true File sub-path=AIR\nppdf32.dll Comparison=LessThan Version=11.0.5.3

Installed Rule

File Version with registry value: Hive=HKEY_LOCAL_MACHINE Registry Path=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe Registry Value=Path Use 32-bit registry=true File sub-path=AIR\nppdf32.dll Comparison=EqualTo Version=11.0.5.3

This does not work. I have 11.0.04 installed for testing purposes (v11.0.04.63 on that .dll) and it's reporting as Installed to Patch Manager.