(adobereader) 'Applying Patch' always being called...overwriting user parameters

[drumnj]

Checklist

• I have checked for similar opened and closed issues.
• The issue title is in the format (<PACKAGENAME>) <ISSUE SUMMARY>.

Chocolatey Version

2.2.2

Chocolatey License

None

Package Version

v2024.2.20687

Current Behaviour

This is the same thing I posted on the Chocolatey page discussion...

It looks like the custom parameters get overwritten when the package runs it's "Applying Patch" section. This is always called, even in new installations since this command always returns true
$ApplyPatch = $InstalledVersion -lt $UpdaterVersion
$UpdaterVersion is defined at the top of the script, as so
$UpdaterVersion = $Matches[1]
Not sure where $Matches is coming from, but I'd assume that is defined through a chocolatey function. Anyway, as it goes through all set parameters are correct until after
adobereader (installer) has been installed. is posted. The Applying patch. part of the code will revert back to all the defaults. If you want the Desktop Icon removed, it will show up at that part. Same with update mode key in registry, will be whatever you set until the patching part.

Expected Behaviour

No response

Steps To Reproduce

New install

Environment

Microsoft Windows NT 10.0.19045.0
5.1.19041.4291
PS

Chocolatey Log

https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889

Anything else?

No response

[github-actions]

Thanks for raising this issue!

The packages within this repository are maintained in my spare time. My spare time, like yours is important. Please help me not to waste it.

To help me, and to have the issue resolved more quickly, please see CONTRIBUTING for how to raise a pull request to resolve the issue yourself.

Thank you.

[pauby]

$matches is a PowerShell variable that is populated from the regular expression match that is taken from this line. It will always be true for an upgrade. Won't always be true for a forced install, for example. It's trying to protect you from installing the same version again and the installer failing.

I'm not saying there is no issue, and I will test this later with your command line choco install adobereader --params /UpdateMode:2 -y, but the package has been downloaded 529M times. And the current version, 2024.2.20687, released on 12 April, 3M times. If there was an issue, I'd expect it to be brought up before now.

[pauby]

Looking at the gist again, this line adds the UPDATE_MODE=2 installer argument. This is then added to the calls to the installer(s) on these lines:

1. https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889#file-gistfile1-txt-L745
2. https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889#file-gistfile1-txt-L750
3. https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889#file-gistfile1-txt-L752
4. https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889#file-gistfile1-txt-L753
5. https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889#file-gistfile1-txt-L762
6. https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889#file-gistfile1-txt-L764
7. https://gist.github.com/drumnj/9cb64e2b74dbed4ab666b7b0b89f5889#file-gistfile1-txt-L765

So I can't see there being an issue with the package.

But I did install with the command line choco install adobereader --params /UpdateMode:2 -y and although there was a new version available, it didn't prompt me. If you can tell me the registry entry to check I can do that here, but everything looks fine to me.

[drumnj]

Desktop icon stays away for you? I'm not sure what else to test, it's a clean Windows, not on a domain.

I'm referencing this:

https://www.adobe.com/devnet-docs/acrobatetk/tools/PrefRef/Windows/Updater-Win.html#idkeyname_1_29796

Mode section. That key will go from 2 to 3 in the course of the install. Again, desktop icon shows up at the applying patch part. Shouldn't that host output not even show up since I'm not forcing it? No other installs of reader, again a clean Windows install.

[pauby]

Desktop icon stays away for you? I'm not sure what else to test, it's a clean Windows, not on a domain.

No, the desktop icon is added to the desktop. However, note two things:

1. As per this line (and others), DISABLEDESKTOPSHORTCUT=1 is being passed to the installer.
2. The documentation, taken from this line in the code states that (emphasis mine):

Shortcuts 10.1 & later DISABLEDESKTOPSHORTCUT

10.1 and later. Reader only: When set to 1, the desktop shortcut will not be created at the initial install or after any updates.
11.0 and later. Customize the behavior by using the SUM of any values.
null (property is not set): All shortcuts except AAM are created.
0: Create all shortcuts.
1: Disable all shortcuts. This is the only valid value for Reader.
2: Disable all Acrobat shortcuts, but not AAM or FormsCentral shortcuts.
4: Disable AAM shortcut only.
8: Disable FormsCentral shortcut only. (See note below)

So it all looks good. However, the last bit is important:

Note: The property can only be used with a MSI (full) installer; it cannot be used with when applying an MSP update. FormsCentral has been retired and is no longer supported.

I don't know if we are using the MSI, as the code has this line but also includes /msi in the silentArgs on this line. So this may no longer work. But if it doesn't it, would seem most people don't care as nobody has reported it before now, BUT that is assuming it's not just changed for this version.

I'm referencing this:

https://www.adobe.com/devnet-docs/acrobatetk/tools/PrefRef/Windows/Updater-Win.html#idkeyname_1_29796

Mode section. That key will go from 2 to 3 in the course of the install. Again, desktop icon shows up at the applying patch part.

See above for the desktop shortcut. For the /UpdateMode the documentation says this:

Updates 11 & later
UPDATE_MODE Reader only. If updates have not been disabled, use this property during initial installs and patches to control how the product updates. While 11.0 introduces a new install dialog which allows users to set this preference, the installer can be pre tuned with the desired setting via UPDATE_MODE. This property sets HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Adobe ARM\1.0\ARM\iCheckReader

Possible values include:

0: Manually check for and install updates
2: Download updates for me, but let me choose when to install them
3: Install updates automatically
4: Notify me, but let me choose when to download and install updates

We are passing UPDATE_MODE=2 to the installer. What it does with that we have no control over. If it's ignoring it or overwriting it with something else, that would be something to take up with Adobe unless you can tell me where in the Package code we are doing it. I can't see it.

Adobe have a track record for breaking things with the updates to their installers, so it wouldn't surprise me if this was a bug.

Shouldn't that host output not even show up since I'm not forcing it?

I'm not sure what you mean here?

Three further things I wanted to point out. You may know this, so apologies if you've 'heard it before'.

1. I can only have control over the package code.
   a. If the code is doing the wrong thing, or, in the case of the desktop shortcut, doing something that is no longer possible, then I can amend or remove that. That would be a package problem.
   b. If we are passing the right things to the installer and the installer ignores them, there isn't anything I can do. That would be an Adobe problem that you would need to raise with them.
2. I didn't create this package. I picked it up because it wasn't being updated regularly. So while the code is just PowerShell and I understand what it's doing, the why it's doing something is sometimes an educated / uneducated guess. There is a lot going on in it and it's a pretty comprehensive package. So while I can see from the documentation that the desktop shortcut only works for the MSI, I don't know if the EXE is an MSI under the hood. But I would guess that as it's used 500M+ times that it likely worked before now at some point.
3. This repository is updated when I have time so any changes are welcomed as a PR. Having said that, if there is an issue I need to be able to reproduce it so I need detailed steps. But, as I said many times, if the mass of people who have downloaded the package 500M+ times are happy with the way it is, I am very reluctant to make any sweeping changes.

[drumnj]

I agree, this is the most popular package in the Chocolatey community. It seems very unlikely I'm the only one with this issue. However, there is a very slim chance people aren't using the parameters and/or don't care (default is good enough).
What I found is, as stated, the part of the Chocolatey package that does the "apply patch" should not be running, if I'm doing a clean install.

If I could just omit this:

if ($ApplyPatch) {
   Write-Host 'Applying patch.'

   $UpdateArgs = @{
      Statements     = "/p `"$mspPath`" /norestart /quiet ALLUSERS=1 EULA_ACCEPT=YES $options" +
      " /L*v `"$env:TEMP\$env:chocolateyPackageName.$env:chocolateyPackageVersion.Update.log`""
      ExetoRun       = 'msiexec.exe'
      validExitCodes = @(0, 1603)
   }
   $exitCode = Start-ChocolateyProcessAsAdmin @UpdateArgs
}

...then, my parameter settings would be successful. Why is this even running? Is it necessary for new installs? I know this is beyond the scope of the bug report, but is it possible to trick Chocolatey in letting me run the chocolateyinstall.ps1 after editing it?

I made a video (screen capture):
https://www.youtube.com/watch?v=ta95cbgHiYE
Sped up, slowing at the adobe install part, and the registry change and desktop icon part.

I recorded from installing Windows to loading Chocolatey and installing the adobe package to prove this is easily reproducible.

As you can see at 1:43 (https://www.youtube.com/watch?v=ta95cbgHiYE&t=103s) mark, registry will change that key (2 -> 3) and the desktop icon shows up. Even though Adobe Reader has already been properly installed, as shown by the adding of all the other Adobe subkeys. If I were to kill the PowerShell script after it posts "adobereader (installer) has been installed." then I'd be set. No other intervention needed, Adobe Reader is running, my settings are active. I can make this video if you want, let me know.

Now as you mentioned above, it's possible Adobe broke stuff and any future updates will reset any custom settings made. Based on their documentation, this should not be the case and we can only follow what their dev guide says. I'm not as knowledgeable as you, but my guess is that section of code stated above is causing the problem. Even though it's just running Adobe's file, it takes it from expected results to unexpected. Can this section be optional?

[drumnj]

So, the choco package installs an old version then updates it to the latest version. I guess I missed that before. This seems a bit more convoluted, so I'm going to chalk this up to... it is what it is. Thanks for your help, appreciate your time dedicated to Chocolatey. Take care.

[pauby]

I know you closed this, but there are a couple of things I wanted to pick up either for you or future people who come along.

What I found is, as stated, the part of the Chocolatey package that does the "apply patch" should not be running, if I'm doing a clean install.

If I could just omit this:

if ($ApplyPatch) {

Just for clarity, here is this line. This block of code is only run if $ApplyPatch is $true

$ApplyPatch is, by default, $false. It is only set to $true in two places:

1. Here if you already have Adobe Acrobat Reader installed, but it's name does not match 'Adobe Acrobat Reader DC MUI'
2. Here if you already have software with the name 'Adobe Acrobat Reader DC MUI' and the version of that software is less than version in the $MUImspURL filename.

So if neither of those conditions apply, $ApplyPatch is not set to $true and it [doesn't run this code](https://github.com/pauby/ChocoPackages/blob/master/automatic/adobereader/tools/chocolateyinstall.ps1#L279-L296].

But Adobe only releases base versions and then patches. It doesn't release a base version each time, so you always have to install a base version and then patch it.

...then, my parameter settings would be successful.

Note that I said above:

I don't know if we are using the MSI, as the code has this line but also includes /msi in the silentArgs on this line. So this may no longer work. But if it doesn't it, would seem most people don't care as nobody has reported it before now, BUT that is assuming it's not just changed for this version.

Well the patch is an MSI, which we can see here as it's running msiexec.exe so according to the documentation from Adobe it will accept the parameters.

As you can see at 1:43 (https://www.youtube.com/watch?v=ta95cbgHiYE&t=103s) mark, registry will change that key (2 -> 3) and the desktop icon shows up. Even though Adobe Reader has already been properly installed, as shown by the adding of all the other Adobe subkeys. If I were to kill the PowerShell script after it posts "adobereader (installer) has been installed." then I'd be set. No other intervention needed, Adobe Reader is running, my settings are active. I can make this video if you want, let me know.

Thanks for putting that together. What that shows is the installer is changing the registry (as it's still running when it changes), not the package. There is nothing I can do about that. If that value should not change then that should be taken up with Adobe. I only control the package code and it is passing UPDATE_MODE=2 to the installer, and it's choosing to ignore it.

I'm not as knowledgeable as you,

Just to be clear and repeat what I said in a previous comment, I didn't create this package. I only maintain it.

but my guess is that section of code stated above is causing the problem.

From my understanding of the code, it should only run if it's needed to.

So, the choco package installs an old version then updates it to the latest version.

Yes. It has to. But we don't provide any update mechanism for when Adobe releases a new base release version so that is something we need to track. As I understand it though, the current versions are correct.