19 Replies Latest reply on Jan 14, 2014 1:27 PM by justinm

    Adobe Reader installation problem

    justinm

      I have a custom package that I created to install Adobe Reader 11.0.05 with MSI transforms that we want to use in our company and both 11.0.04 and 11.0.05 MSP files. I can deploy the package as is and it installs as expected on computers that do not have Adobe Reader. However, I want to deploy this to all workstations so that it overwrites the standard Adobe Reader install, removing the Tools pane, disabling Internet capabilities, and so on. The idea I came up with is to use Package Boot Helper to run a batch file after the install finishes to copy a blank text file to a location on the hard drive (I've tried several) to act as a sort of flag to say that the PC had been updated with our customized Adobe Reader install. The batch file contains:

       

      echo f | xcopy rdr11005block.txt "%programdata%\blocks\rdr11005block.txt" /I /E

      pause

       

      The installation appears to work. Adobe Reader is installed, patched, and transformed as one would expect. However, the command prompt window does not stay on my screen, and the txt file does not exist when I go looking for it. Additionally, if I uninstall Adobe Reader, Windows Update never again detects that I require the Adobe Reader install. The only way I've gotten my PC to see the update again is to duplicate the package, nuke the old one, and approve the new one. This is clearly not OK for general deployment, but I can't tell if this is a Patch Manager issue, a WSUS issue, or a Windows Update Agent issue.

        • Re: Adobe Reader installation problem
          Lawrence Garvin

          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.

            • Re: Adobe Reader installation problem
              justinm

              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.

                • Re: Adobe Reader installation problem
                  justinm

                  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.

                  • Re: Adobe Reader installation problem
                    Lawrence Garvin

                    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)

                    1 of 1 people found this helpful
                      • Re: Adobe Reader installation problem
                        justinm

                        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?

                          • Re: Adobe Reader installation problem
                            Lawrence Garvin

                            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.

                              • Re: Adobe Reader installation problem
                                justinm

                                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.

                                  • Re: Adobe Reader installation problem
                                    Lawrence Garvin

                                    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.

                                      • Re: Adobe Reader installation problem
                                        justinm

                                        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.

                                            • Re: Adobe Reader installation problem
                                              justinm

                                              Sorry, but there doesn't seem to be any text in your last post.

                                                • Re: Adobe Reader installation problem
                                                  Lawrence Garvin

                                                  Well... that's not cool. I used the "reply by email" function.

                                                   

                                                  Here's what should have appeared:

                                                   

                                                  Your File Version Applicability Rule should not have the *NOT* flag enabled.

                                                   

                                                  A simple File Version rule will return true if:

                                                  • The existing file is Less Than the specified version, or

                                                  • There is no existing file (i.e. the effective version number of the existing file is 0.0.0.0)


                                                  A NOT File Version rule would only return true (isInstallable) if the existing file were NOT Less Than AND physically present. Of course, the erroneous evaluation of the Installed Rules is precluding the issue with the Applicability Rules to surface. (This package, as defined, should have reported NotApplicable in the scenario you've described.)


                                                  Regarding the unexpected evaluation of the Installed Rule.. is this a *new* package definition or a revision to a previous package. Have you confirmed (WindowsUpdate.log) that the client is evaluating the correct revision of the package?

                                                  1 of 1 people found this helpful
                                                    • Re: Adobe Reader installation problem
                                                      justinm

                                                      Whoops! Duh, of course it shouldn't have NOT enabled. I accidentally left that in from a prior revision when I was looking for the file's existence. With that change, the installer runs when it should based on the version of the DLL file.

                                                       

                                                      So now the problem relates only to the flagfile.

                                                       

                                                      If I have the applicability rule only as stated above, a computer with 11.0.05 installed will show as NotApplicable. Because I want this to install on all computers exactly once, I need the Applicability rule and the Installed rule to check for the flagfile. This is where I'm running into problems with the creation date. If I do:

                                                       

                                                      File Created: Path=c:\flags\rdr11005block.txt Common Path=NONE Comparison=EqualTo Creation Date=12/26/2013 2:58:00 PM

                                                       

                                                      will that work for an Installed rule? I'm a bit confused here because Windows does not list a creation timestamp down to the second, but Patch Manager requires it. And does Creation Date work similarly to File Version in that if it doesn't exist, it picks some default value?

                                                        • Re: Adobe Reader installation problem
                                                          Lawrence Garvin

                                                          The rules as stated, most notably the Install Rule (File Version of nppdf.dll EQUAL 11.0.5.3) should cause the package to return a state of Installed when 11.0.5 has been applied. If it's not, this would be something to evaluate further before introducing the question of the flagfile.

                                                           

                                                          With the flagfile part of the package...

                                                          Add an Applicability rule into an "All of the following", but you'll want to do a Less Than rule (just like you did for npdff32.dll) that tests for the Creation Date LESS THAN the known creation date. This will also account for the scenario where the file does not exist (as it does when you do a File Version rule).

                                                           

                                                          The rule you've specified should work as desired for an Installed Rule, and it may be that the Applicability Rule is not actually required (although best practice says that you should include it anyway).

                                                           

                                                          You can get details about the "seconds" value by using PowerShell -- which will also get you the internally stored value for "seconds"

                                                               Get-Item -Path pathname | Format-List

                                                          will return the Creation Time, Modify Time, and Access Time in MM/DD/YYYY HH:MM:SS format.

                                                           

                                                          Or you can get the Creation Time directly with (Get-Item pathname).CreationTime

                                                           

                                                          Note also that NTFS stores dates internally as UTC, but displays them in the Local Time Zone. As such, I'm not entirely certain (at this moment, but I'll check) whether the rule needs to be specified with a UTC value, or whether the local timezone conversion occurs first. My suspicion is that the test occurs before the conversion. Consider the scenario where you need to check the File Creation date across multiple time zones; in that scenario, you'd want to check the UTC creation date, not the local conversion. You may wish to test this both ways to see which works. (i.e. the existing rule may be failing because it's using a local time stamp, not the UTC value.)

                                                            • Re: Adobe Reader installation problem
                                                              justinm

                                                              OK. With the Applicability rules:

                                                               

                                                              When all of the following...

                                                              • 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
                                                              • File Created: Path=c:\flags\rdr11005block.txt Common Path=NONE Comparison=LessThan Creation Date=12/26/2013 2:58:49 PM


                                                              and the Installed rules:

                                                              When all of the following...

                                                              • 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
                                                              • File Created: Path=c:\flags\rdr11005block.txt Common Path=NONE Comparison=EqualTo Creation Date=12/26/2013 2:58:49 PM

                                                               

                                                              My computer is reporting the package as Installed. The file c:\flags\rdr11005block.txt does not exist on the computer.