Pushing out Updates for Adobe Reader Products via MDM

[harisonb21989751]

Hi all,

We are running Microsoft Intune as an MDM and we are managing a couple of hundred Windows 10 devices with it. Users do not have local administrator access, so cannot install updates themselves.

We are able to deploy the base versions of Adobe Reader (11.0.0 or 10.0.0) without any issues (by uploading the MSIs to Intune and deploying that way), however because of the way the updates are packaged (as an MSI that calls an MSP file) we are not able to push out these updates - Intune does not support EXE or MSP files.

I would appreciate any assistance you can provide with this, due to the distribution of our users (international) we are not able deploy this from a common network location, and from what I have seen Intune does not support this in any case.

Thanks in advance

Harison

[Karan Malik]

harisonb21989751  wrote

We are able to deploy the base versions of Adobe Reader (11.0.0 or 10.0.0) without any issues (by uploading the MSIs to Intune and deploying that way), however because of the way the updates are packaged (as an MSI that calls an MSP file) we are not able to push out these updates - Intune does not support EXE or MSP files.

As per  < .MSP is not offered as a file type when I browse to the location of where the install software is > you would need:

To publish a MSP you need to upload an update, not a software package.  Navigate to "Updates" and on the right side click "Upload".  When you get into the Software Publishing tool please choose "Upload an Update".

You can get Adobe Reader MSP patches from here: Adobe - Adobe Reader : For Windows

Let me know if that helps.

Thanks,

Karan

[harisonb21989751]

Hi Karan,

Thank you for your suggestion, unfortunately, the post you have referenced is from 2012, and the Intune product has changed significantly in that time.

I was hoping there would be a way to create a new MSI with the updates included (similar to the AIP method but with everything fully packaged in the MSI, not referring to a network location).

[Test Screen Name]

Bear in mind, because your company may have policies about this, that Reader X and XI are now EOL (end of life) and will not get fixes for serious security vulnerabilties. In general people have moved to the current Reader instead of these ancient products.

[harisonb21989751]

Thanks Test Screen Name.

I was using those products as examples. Reader DC has the same problem, only it is compounded because the original MSI is something like v15.x.x while the current version is 17.x.x. and all the new versions are only available as MSP files.

[harisonb21989751 · Accepted solution]

I was able to identify a solution, although it is not ideal.

Intune provides the option to include Command-Line Arguments as a part of the properties of the Line of Business app that is being setup. This allows me to install the base version MSI (for DC that is 15.0072.0033) as the Line of Business app, and in the Command-Line Arguments field enter /update "<filepath>\<update1>.msp;<filepath>\<update2>.msp;...;<filepath>\<latest_update>.msp" where <filepath> is a shared network location.

As I said, this is far from ideal, and requires some proactive maintenance to keep the latest update ready to go.

Please adobe, please release your version updates as MSIs. it will solve this problem completely.

[Test Screen Name]

You don't need to apply all the intermediate MSPs, they are cumulative.

[harisonb21989751]

That's only partly true with Reader DC. because the base install is version 15.x.x, you can't go straight to the current version of 18.x.x.

In my testing I had to install the following updates in order to get the latest version:

1. 1502320070
2. 1700920044
3. 1701220098
4. 1801120038

Thanks for trying to help anyway.

[Leo Schoonhoven]

Sorry, for resurecting this thread but i have something that might help. 
In Intune i do not use the LoB anymore with adobe, it gave me too much grief, instead i made a Powershell script that downloads the initial Adobe DC installer and after that updates it to the newest MSP. Hopefully this helps you in some way becuase it actually does update is straight to 18.
It also adds registry settings and removes the lnk from the desktop

# Script created by Leo Schoonhoven
# Fondo IT: https://www.fondo.nl
# Silent install Adobe Reader DC
# https://get.adobe.com/nl/reader/enterprise/


# Path for the workdir
$workdir = "c:\temp\"

# Check if work directory exists if not create it

If (Test-Path -Path $workdir -PathType Container)
{ Write-Host "$workdir already exists" -ForegroundColor Red}
ELSE
{ New-Item -Path $workdir  -ItemType directory }

# Download the installer

$source = "ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/1500720033/AcroRdrDC1500720033_en_US.msi"
$destination = "$workdir\AcroRdrDC1500720033_en_US.msi"
Invoke-WebRequest $source -OutFile $destination

$source = "ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/1901220035/AcroRdrDCUpd1901220035.msp"
$destination = "$workdir\AcroRdrDCUpd1901220035.msp"
Invoke-WebRequest $source -OutFile $destination

# Start the installation

msiexec /i "C:\temp\AcroRdrDC1500720033_en_US.msi" /lv "$workdir\Adobeinstall.log" /qn

# Wait XX Seconds for the installation to finish
Start-Sleep -s 35

#Start update
msiexec /p "$workdir\AcroRdrDCUpd1901220035.msp" /lv "$workdir\AdobeUpdate.log" /qn

# Wait XX Seconds for the installation to finish
Start-Sleep -s 35

Reg ADD "HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\AVAlert\cCheckbox" /v iAppDoNotTakePDFOwnershipAtLaunch /t REG_DWORD /d 00000001 /f

# Remove the installer

rm -Force $workdir\*.msi
rm -Force $workdir\*.msp
rm -force C:\Users\Public\Desktop\Acrobat Reader DC.lnk

[davidb123456]

This is great.  Researching how to deploy this with INTUNE right now.  Will give your script a try.  

Can I ask, how do you apply ongoing updates after the initial deployment when users don't have admin rights?

[Leo Schoonhoven]

Sure you may ask, and I will answer! 
with this script you can just check on the ftp site to see if there is a new .msp package and deploy it to your users. If  you have more in-depth questions about Intune I could answer your questions better via email, so if you want drop me a private message and I try and help you the best I can.

[davidb123456]

So are you saying we can keep the same exactly PowerShell Script and update the line in the script for the MSP file?  Do I just deploy it as a new powershell script or edit the original assignment?  Can you elaborate on the process for going from the originally deployed version to a new update?

[daltonr84497748]

Did you have any luck with this?

I'm trying that script out now with a test profile, doesn't appear to be doing anything though.

Did you just create a .ps1 with script and upload it to Intune?

[Leo Schoonhoven]

I have this working in production. Copy past this code on to a text file and change it to a .ps1 file. Upload this to Intune in the scripts section and allocatie this to users or devices. That should work. 

Check of the folders where the installers and updates are being downloadend exist and or are being created. Also bear in mind it is a slow process as it is quite some data that needs to be downloded. 

[Leo Schoonhoven]

If you only want to update you'd only need to update the msp path to the newest msp and reupload the script to Intune. OR you could

make a second script with only the bottom commands to update every adobe deployment as long as you change the .msp path

[Jubilant_think5FF3]

For anyone still struggling with this. I may have found another workaround that was successful for me. Below is a batch file named "install.cmd" that I have in a top-level folder. That top-level folder also contains a folder named "Acrobat_Pro_20", which has all of the needed install files for both the msi installer and the msp update. In addition to the install files, The "Acrobat_Pro_20" folder also has two more batch files. One is named Install_Acrobat_Pro_DC_20_app (which handles the silent install of the msi) and Install_Acrobat_Pro_20_update (which handles the silent install of the msp update). 

I package up the folder containing the install.cmd batch file and the folder with the install files using the Intune Packaging Tool. The install.cmd file name is used as the install command. The MSI product code is used for the uninstall and detection. This all installs in the system context.

What this batch file does is copy all of the install files locally to the C:\Windows folder. It then does a cd to that directory and starts running my install batch files. I put a timeout between them to give the msi enough time to install before the update starts to run.

RoboCopy "Acrobat_Pro_20" "C:\Windows\AdobeAcrobatDC" /E /FFT /Z /XA:H

cd "C:\Windows\AdobeAcrobatDC"

start Install_Acrobat_Pro_DC_20_app.cmd
timeout /t 100 /nobreak > nul
start Install_Acrobat_Pro_DC_20_update.cmd

I know this isn't the prettiest solution, but the application installs successfully and updates to the latest version. Intune recognizes this as a successful install. Hopefully this helps someone out! Sorry for any typos, I'm drafting this up quickly between tasks.