It worked after I downloaded the installation file again, creating a new intune file and then creating a new app in Intune. I did everything identically to the first time, but this time it worked for some reason.
Hello, Can you help me with updating the Intune apps for example I have packed the Adobe Reader 1902120049 but there is new release and how is the correct path to update the application? I have changed the installation file and just wondering how detection rules can be changed so it can check if its older version?
I would like to point out, that instead of detecting whether Acrobat Reader is installed or not, you can also do detection by version number in Windows registry. That would allow updating existing verisons.
I do it with the following Intune detection rules settings:
We now would like to uninstall Adobe Acrobat Reader DC (all versions) from all devices and install just the latest 64bit version. Do you have a way of achieving this as this seems like a common issue?
With newer powershell versions Get-WMIObject is depreciated and your PS string will not work correctly. This updated one will,
Get-CimInstance -ClassName Win32_Product Sort-Object -Property Name Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize
When .exe file used while packaging and in command line, installation via Intune fails with the error message "The system cannot find the file specified. (0x80070002)" It appears that it could be becuase "setup.exe --silent" command line (as per documentaiton) is not completely silent (see attached screen shot).
When .msi used while packaging and in command line, only Adobe Creative Cloud desktop app gets installed by Intune; Acrobat is not installed. But when the same package is executed in GUI, both get installed.
I discovered that there is another .msi buried in the Build folder under Setup\APRO22.0\Adobe Acrobat. It is called AcroPro.msi This, however, installs Adobe Acrobat Pro DC version 2021.001.20135 not 2022 depite the fact that the folder that contains it is called APRO22.0
I've managed to get a 'workaround' for this, its not ideal but does the job. The only 'downsides' to this are that you dont really have any control over when Adobe DC decides to update itself and turn off the Document Cloud.
Trying to do the same, but for Acrobat 2020 Standard. Downloaded the Acrobat Wizard, opened the .msi file downloaded from Adobe at -install/kb/acrobat-2020-downloads.html, made changes to the .msi including entered the license number, generated the transform file, and then created the .intunewin file with the IntuneWinAppUtil. Once I upload the file to Intune, and setup my install command with msiexec /i "Adobe2020Standard\AcroPro.msi" TRANSFORMS="AcroPro.mst" /
Thank you for your reply. This is what I was hoping for, but I'm a bit unclear on what you meant by "the latest" MSP. How will I know which of the MSP files in this folders is the "latest?" There are four of them, all with the same "Date modified" of 2023-01-07. Their names are: AcrobatDCx64Upd2200320282.msp (would this be the latest based on its name?), Acrobat2015Upd1500630352.msp, AcrobatUpd10116.msp and AcrobatUpd11012.msp
This is no longer the correct answer. The command switch "PATCH" can't find the msp file of any name or designation, but "UPDATE" will. Also, when testing without "/qn" it appears to work as intended, but when I add that back and deploy via Intune, it fails.
3. Open the DC Customization Wizard and point it at the AcroPro.msi within yout extracted folder. The MSI I used was found in AdobeDC\Acrobat\Build\Setup\APRO23.0\Adobe Acrobat\AcroPro.msi
4. Within here, I disabled the Adobe Document Cloud Services within Online Services and Features. At this point I also customise all the other features relevant to me but, the Cloud Services one is what made things work properly. Save your package back into AdobeDC\Acrobat\Build\Setup\APRO23.0\Adobe Acrobat\ you should now have an .mst file.
5. Now package up your installation files using the IntuneWinAppUtil. I pointed to \AdobeDC\Acrobat\Build\Setup\APRO23.0\Adobe Acrobat and used AcroPro.msi as the insatller. Make sure the WinApp file is under 1.6GB otherwise Intune tends to time-out halfway from the download/install which is rather annoying.
Trying to do the same, but for Acrobat 2020 Standard. Downloaded the Acrobat Wizard, opened the .msi file downloaded from Adobe at -install/kb/acrobat-2020-downloads.html, made changes to the .msi including entered the license number, generated the transform file, and then created the .intunewin file with the IntuneWinAppUtil. Once I upload the file to Intune, and setup my install command with msiexec /i "Adobe2020Standard\AcroPro.msi" TRANSFORMS="AcroPro.mst" /qn /l*v "C:\acrobat_standard.log" I then try to install it through Company Portal and each time it fails. I have not found a solution to this issue yet. Any other ideas? The only thing I can think of is I don't have access to Adobe Admin, so I am unable to download a specific build for the .msi file, but I wouldn't think that would matter since I am downloading everything from Adobe at the link above, and including all files in the build folder for IntuneWinAppUtil. Thanks in advance for any help!
I've tested the install command through admin prompt using msiexec.exe /i "c:\acrobat2020standard\acropro.msi" /qn and even that doesn't appear to work. The only way I've gotten the .msi to run is by manually installing by double-clicking the file and going through the installer UI.
I am still testing some things with regard to software architecture (32-bit vs 64-bit), but I can confidentaly report that both Standard and Pro are installing through Company Portal, and even removing any previous installations of Reader, or other Acrobat apps. The upgrade .msp file was included with the package and I can confirm that the installation from Company Portal did upgrade the app to the latest build.
The only thing I changed with my transform file after I opened the .msi in the Acrobat Wizard, was to enter my license number, and accept the EULA, as well as made Acrobat the default PDF viewer, removed installed versions of Acrobat, and Reader, and then under "Run Installation" I chose Silently. I also turn off the upsell under "Online Services and Features."
Once I created the .intunewin package using IntuneWinAppUtil, I uploaded the file to Intune, and set everything up as normal. The difference this time was instead of calling for the .msi file in the install command section, I used the following:
Everything else, including the detection rule set to the .msi file, was left the same. After I launched Company Portal, I was able to see the new app available, and I began installing it. It took a few minutes, but finally said it was successful.
I had Reader DC installed on the device as part of my "required apps" in my AutoPilot deployment policy, and it was removed as part of the upgrade to Acrobat 2020 Standard, which was intentionally set in the transform file.
Well, I've spent way too much time on this, but what ended up working, was @Keith34212009fw6b 's suggestion. Changing the install command installed the proper application instead of the old Acrobat Reader DC, which is riddled with vulnerabilities.
Has anyone been success on deploying Acrobat DC Professional via Intune? I downloaded the package from Adobe and used the IntuneApp to create a package but so far it refuses to install failing with a
(0x80070005) error. I can deploy the reader without issue. Deployed Dreamweaver and Photoshop CC without error but this one is puzzling. This like all of CC is subscription based now, so not sure what I am missing...
My suggestion would be to use psexec to start a command prompt in system context (psexec -i -s cmd) and test your Adobe Professional installation with an PowerShell wrapper in system context and let the setup write additional log files. Normally you get enough indicators in the log file then to resolve the issue. As soon as you have success, use the wrapper and Adobe files and generate a new .intunewin and try again with Intune. Normally a log file and test install in the same execution context (system context) is necessary to troubleshoot these failures.
Right now, I downloaded the package from Adobe. Extracted the files; which creates a folder called Build. In that folder is both a setup.exe and AcrobatDC.MSI. I then ran the Intune WinAppUtil and have choosen both the setup and the MSI without luck. Right now, I have the setup selected and within Intune, I have setup /quiet as the command. I was able to find the uninstall command and that is msiexec /x AC76BA86-1033-FFFF-7760-0C0F074E4100
Not entirely certain what logs Acrobat would produce. Still tracking that one down as I know there is a new feature for Win32 troubleshooting to gather those logs. The Intune logs are so encrypted, I cannot even follow them to figure why it is failing. I have an issue open with MS but they have been slow to respond on this one. This is bugging me as I deploy Dreamweaver and Photoshop nearly identical. But I do now that Acrobat typically requires a restart and also require Outlook to be closed, so there are additional variables that could be causing the problem.
d3342ee215