In today’s blog we will discuss the issue that we have been experiencing with Adobe Acrobat Reader (64-Bit) when updating devices from Intune using Pckgr.

The Issue
The primary challenge we encounter when attempting to update Adobe Acrobat Reader using Winget lies in its inability to distinguish between Adobe Reader, Standard, and Pro editions. Typically, our detection scripts rely on Winget commands to ascertain whether an application has been successfully installed. For example, if Winget detects the ID “Adobe.Acrobat.Reader.64-bit” on a device, we consider the installation successful.

Herein lies the problem. Adobe has transitioned to a one-size-fits-all installation approach for Acrobat, which creates complications during updates. For instance, on a device where Adobe Acrobat Standard is installed, Winget still identifies it as “Adobe.Acrobat.Reader.64-bit.” Consequently, when attempting to update, the system mistakenly tries to upgrade Adobe Reader, resulting in a failure because Standard or Pro editions are actually installed on the device.

The Cause

The root cause of this problem can be attributed to Adobe’s shift towards a unified installation approach for Acrobat Reader. In the past, Adobe offered distinct versions of their software, such as Adobe Reader, Acrobat Standard, and Acrobat Pro, each tailored to different user needs. However, in recent updates, Adobe has streamlined its installation process into a single package. While this simplification may appear efficient, it has inadvertently introduced complexities when it comes to updating the software.

The Fix

Adobe has fortunately provided a method to determine the specific version of Acrobat (64-bit) installed on a device, and this can be accessed through the “SCAPackageLevel” value. By leveraging this value, we can distinguish whether Adobe Reader or Adobe Acrobat is present on the device. If the value is equal to 1, it confirms the presence of Adobe Reader, while a value greater than 1 indicates the installation of Adobe Acrobat.

Leveraging this information, we have successfully devised a method to validate that Adobe Reader is indeed installed on a given device before initiating the update process. Thanks to the collaboration with Andy Hamm (one of our power users), we’ve developed a new requirement script tailored for the “Update Only” deployment of Adobe Acrobat Reader 64-Bit through Pckgr. This script will conduct a pre-check on the device, ensuring the presence of Adobe Reader before proceeding with the update. This proactive approach addresses the issue we encountered earlier and guarantees a smoother update experience for users.

# Define the registry path and key for 64-bit Adobe Reader

$registryPath = "HKLM:\SOFTWARE\Adobe\Adobe Acrobat\DC\Installer"

$registryKey = "SCAPackageLevel"



# Check if the registry path exists

if(Test-Path $registryPath) {

    # Get the value of SCAPackageLevel

    $SCAPackageLevel = Get-ItemPropertyValue -Path $registryPath -Name $registryKey -ErrorAction SilentlyContinue



    # Determine the installed application based on SCAPackageLevel

    if($SCAPackageLevel -eq 1) {

        Write-Host "Application Found"

        Exit 0  # Exit code 0 indicates success in Intune

    } else {

        Write-Host "Requirement not met: Non-Reader Adobe product detected or Adobe Reader is not installed."

        Exit 1  # Exit code 1 indicates failure in Intune

    }

} else {

    Write-Host "Adobe Acrobat/Reader is not installed or the registry path does not exist."

    Exit 1  # Exit code 1 indicates failure in Intune

}

You can test it out by redeploying your Adobe Acrobat 64-bit deployments in Pckgr. Once the redeployment has completed, you can verify the new script is visible in Intune via the Requirements section.