Trying to distribute the Adobe Reader DC Update 21.001.20135 to a larger group of machines,
by means of SCCM (but also manually donwloaded and installed)
I receive the following error message:
"Product: Adobe Acrobat Reader DC MUI -- Error 1722.There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action InstallWebResources, location: C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrServicesUpdater.exe, command: 21.001.20135 20.013.20074.0"
I use a different solution for software deployment (not sccm). But I have the same problem. It seems like the installation fails whenever you install while no user is logged on. If I execute the installation while someone is logged on it works without problems.
We tryed so far:
Deployment of a patched administrative installation (we patched the installation with msiexec /a adobereader.msi /p adobereaderpatch.msp).
Deployment of a msp on a machine with a base installation (15.007.20033).
I also tryed deactivating the WebResources by adding the parameter REMOVE=ReaderBrowserIntegration to no avail.
Same issue for me, Error 1722 - RdrServicesUpdater.exe. Have tried redownloading and slipstreaming the msi and msp again but same error when deploying.
The classic track (Adobe Acrobat Reader 2020 MUI) seems to work...
Base files for administrative installation: https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/classic/dcclassic2020base.html#dc...
msp for patching: https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/continuous/dccontinuousfeb2021.htm...
I could install that with powershell app deployment toolkit in the system context without anyone logged on.
I am having trouble with the same error. The offline installer does not change.
Environment is Windows 10 Pro 20H2 64bit, RAM 16GB. VC++ Runrime is installed on 2013 x86, 2013 x64, 2015-2019 x86, 2015-2019 x64.
Thank you for reaching out.
For Error 1722, you may try the solution mention in this help document out: https://helpx.adobe.com/in/acrobat/kb/error-1722--there-is-a-problem-with-this-windows-installer-pac...
Thanks, but that doesn't help. As mentioned the installation works as long as some user is logged on to the machine. The problem only occurs when no user is logged in. I can reproduce this on the same machine.
Step 1: install Adobe Acrobat Reader DC while some user is logged on (rdp or local logon). It doens't matter if you install the package from that session (using gui) or by some other means like powershell remoting (using different credentials).
=> Installation succeds.
Step 2: After successfull installation, uninstall Adobe Acrobat Reader DC.
Step 3: Close all GUI-Sessions (Local Login, RDP, Hyper-V Console etc.).
Step 4: Connect yourself to the machine using psexec, psremoting and start the installation of the same msi you used before (msiexec /i ... /qn /l "<logpath>" /<whateveroptionyoulike>) / or use some kind of configuration manager.
=> Installation Fails with 1722.
Hello Tariq, thank you for your response.
We have already read the article and tested the provided solution but this does not work for us. The latest provided Adobe update won't install, we currently use Windows 10 version 1909 (x64).
Kind regards, Daan
Im having this same problem deploying Reader DC 21.001.20135. I am running the install using the MSI with a transform, then running the MSP file. This is how I've done every Adobe update and it's always worked. There is something wrong with the installer for this new version.
As others have said, installation works only when a user is logged on.
Adobe, please look into this.
Same issue here. It fails through WSUS, installing from an AIP, but works fine when I install manually. I removed all versions of adobe reader, pulling my hair out... but it appears to only install interactively. I have the exact same error in my event log.
I'm working with machines that have Windows 10 20H2, fully patched with windows updates through January. I'm going to guess there might have been changes when installing using the SYSTEM account or during machine startup.
We are having the issue as well. Its a fundalmental issue with this particular patch
Same issue here as well. Including relevant log output from MSI install below:
Executing op: CustomActionSchedule(Action=InstallWebResources,ActionType=3090,Source=C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrServicesUpdater.exe,Target=21.001.20135 ,) Note: 1: 1722 2: InstallWebResources 3: C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrServicesUpdater.exe 4: 21.001.20135 CustomAction InstallWebResources returned actual error code 91 (note this may not be 100% accurate if translation happened inside sandbox) Product: Adobe Acrobat Reader DC -- Error 1722.There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action InstallWebResources, location: C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrServicesUpdater.exe, command: 21.001.20135 Error 1722.There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action InstallWebResources, location: C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrServicesUpdater.exe, command: 21.001.20135
I've also tried using remote methods of installing (RemotePS, PSexec, remote patch management software), and only an interective user installation works properly. Silent installation commands still work fine, but require being logged in to succeed. I've also tried complete uninstall and reinstall with the patch and have the same problem.
I am getting same 1722 error, and I am using the same method that has worked for years. My log file looks like the one that tlskinneriv0618 has posted in this thread. I looked at the fixes provide by Tariq, and that will not fix the issue for me. I am just posting this with hopes that the support team will see that this issue is not affecting just a handful of admins/techs.
Copy link to clipboard
Confirmed that this issue is not limited to Reader and occurs on Acrobat DC Pro using this new update.
- Windows 10 1909 and 20H2 Enterprise, both existing and clean installs of the operating system
- Visual C++ 2013 versions 12.0.30501, 12.0.40060, and 12.0.40664, including no version of Visual C++ 2013 previously installed
- Existing and clean installs of Acrobat DC Pro
- Utilizing SYSTEM or administrator accounts
As others have mentioned, machines with at least one interactive logon will install the update successfully either the first or second installation attempt.
I can also confirm this issue. It occurs during an SCCM Task Sequence when attempting to Build and Capture (thus, no one is signed in).
Reproduced when attempting to install on Windows 10 20H2 with February 2021's updates already installed.
Same error when no user logged on. The msp (21.001.20135) is succesfully installed if user is logged on.
Distributing with SCCM and has worked fine for many years.
C:\windows\temp error log on client machine
There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action InstallWebResources, location: C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrServicesUpdater.exe, command: 21.001.20135 20.013.20074.0
Copy link to clipboard
Thanks a lot!
"INSTALLUWPAPP=NO" worked in my test environment. Gonna test a bit before rolling that out.
I'm not using any proxy. However there are multiple levels of NAT (don't ask). We are using the System Account too.
Please do not use INSTALLUWPAPP=NO over the command line. This can lead to a corrupted install of the latest version of the application. It is strongly not recommended to use this to install Reader or Acrobat.
Adobe is already aware of this issue and it is being worked upon.
Thank you for letting us know NOT to use the INSTALLUWPAPP=NO.
FYI: This "workaround" is already being spread around, so in case it breaks something, you might consider having a "fix" included int he upcomming relase.
Why then is this property available in the MSI for more than 2 years?
Is your statement maybe more related to the (marketing) fear, that admins could disable the notorious notification popups?
Then this is what is one of the results of this setting.
There is absolutly no evidence for such problems.
i think, the worst scenario, that could occur, would be that one have to extra uninstall the UWP app (c:\Program Files\WindowsApps\AdobeNotificationClient....), as it is maybe not in version sync anymore, if it is not updated now.
We are aware of this issue and the issue is currently being worked upon. I will keep this discussion updated as soon I get an update about the fix.
Thank you for your patience and for your valuable feedback.
Your colleague MohdKashif mentions that it is strongly not recommend to apply our workaround, INSTALLUWPAPP=NO over the command line.
As this update provides a mitigation for several security risks (see Adobe security bulletin) and we have no way to mitigate these risks other than to install the update, can you give an estimate when the fix will be available?
Kind regards, Daan
When do you expect to post a new update file?