Modifying PaperCut NG Client to install in the system context via Microsoft Intune

Overview

This post builds on my previous post about PaperCut NG Client. You may want to go read that post first to get some context.

PaperCut NG Client’s Windows Installer (MSI) file has had a bug for months and months, over several version releases, where it is not recognized by Intune as a system-installable app. From the product manual:

There is a known issue with the .msi file not allowing an Administrator to specify in Microsoft Intune which context an Administrator can install the application to.

This would be easy for the company to fix, but for whatever reason, it has not done so. To fix it yourself for your organization, continue reading!

The Cause

The Windows Installer file does not set the ALLUSERS property. For most MSI files, the ALLUSERS property should be set to 1 to specify a system-level installation. If the value is an empty string, then Windows Installer treats it as a per-user installation. Because this property is not even defined in the PaperCut NG installer, it is treated as if it were set to an empty string. The installer itself is coded in such a way that the files are written to per-computer locations anyway, so the installation works fine when run manually.

When you run the Microsoft Win32 Content Prep Tool to generate an INTUNEWIN file for upload into Intune, though, that tool notes the lack of the ALLUSERS property (just like Windows Installer itself would) and generates metadata in the INTUNEWIN file limiting the installer to per-user installations. That’s what causes the problem with Intune, and that is what you are manually changing when you follow the published workaround (described in a video on the same web page right below the notice of the bug).

The Solution

Normally, you can pass any property to a Windows Installer file on the command line at the time of installation. Unfortunately, the Win32 Content Prep Tool is not capable of accepting properties as parameters; it only reads what is built into the file. We can’t even make a transform file like last time because, again, a transform file is specified on the command line at the time of installation as a property parameter. To fix this issue, we must directly edit the MSI file.

The following steps assume that you have the environment described in my previous post set up. You don’t have to follow these steps exactly; for example, I am removing the original MSI file from the source and replacing it with a differently-named file, but you could leave both there if you wanted to.

Move the MSI file to a new folder and make a working copy:
md "%USERPROFILE%\Downloads\PCClient\Original MSI"

move "%USERPROFILE%\Downloads\PCClient\win\pc-client-admin-deploy.msi" "%USERPROFILE%\Downloads\PCClient\Original MSI\"

copy "%USERPROFILE%\Downloads\PCClient\Original MSI\pc-client-admin-deploy.msi" "%USERPROFILE%\Downloads\PCClient\Original MSI\pc-client-admin-temp.msi"
If you made the transform file described in my previous post, I suggest that you move it as well:
move "%USERPROFILE%\Downloads\PCClient\win\PCClientAutorun.mst" "%USERPROFILE%\Downloads\PCClient\Original MSI\"
Run Orca.exe
Open “%USERPROFILE%\Downloads\PCClient\Original MSI\pc-client-admin-temp.msi”.
Since we’re editing the MSI file, we are defining a new package, so we must specify a new package code. Navigate to View menu > Summary Information…, and click New GUID to replace the package code. Then click OK.
Select the Property table.
Tables menu > Add Row…, and create a new row with these values:
- Property: ALLUSERS
- Value: 1

Optional: Merge the MST Settings

Now here is the optional part. Since we are creating a new MSI file anyway, there is no reason to keep depending on a transform file for other behavior. If you want the program to run automatically at user sign-in, and if you created the transform file as described in my previous post, you can apply the transform file the MSI file. Then you won’t need the transform file at installation time because its settings will be baked into the MSI itself.

Transform menu > Apply Transform…, and choose the PCClientAutorun.mst file. You should see green bars beside the Component, FeatureComponents, Property, and Registry tables, indicating that changes are present.
File menu > Save Transformed As…, and save the file with a new name, such as “pc-client-admin-myorg.msi” (replacing “myorg” with an abbreviation for your organization). Be sure not to overwrite the original file from the vendor, as that is your unchanged reference version.

Finishing Up

If you skipped the optional steps above: File menu > Save, then close Orca, and rename the file to something without the word “temp” in it, such as “pc-client-admin-myorg.msi” (replacing “myorg” with an abbreviation for your organization).
If your organization has a code-signing certificate, I recommend signing the new MSI file.
Copy the new MSI into the folder with the rest of the installation files:
copy "%USERPROFILE%\Downloads\PCClient\Original MSI\pc-client-admin-myorg.msi" "%USERPROFILE%\Downloads\PCClient\win\"

That’s it! You fixed the Intune issue by adding ALLUSERS=1, and you optionally integrated the transform file settings from the previous post directly into the new MSI. You should be able to upload the new MSI into Intune following the normal procedure.

Posts in this series: