It is important to note that in a Terminal Server environment, and due to the way printer redirection works, having just one user with one of the above printers still installed and redirected to the Terminal session, could render Paperless Office printing inoperable for
all users connected to the terminal server.
How to check for this?
While users are logged in to the Terminal Server
1. Go to Control Panel > Administrative Tools > Print Management.
The user must be local administrator
and belong to the "Print Operators" group on the server
2. Click on on "All Printers" and look for any entries that shows something like this: "Sage 100 PDF Converter (redirected #9)"
3. The number after the "Redirected" is the user's session number. Can be found out with a powershell command, but is out of the scope of this article.
4. Do the same for the other printers
5.
Alternatively: the Terminal Server can have 3rd party printing utilities , like TSPrint, triCerat ScrewDrivers, etc... which allows selective exclusion of printers in a terminal server session.
2. Make sure that the default printer is "Online"
3. Change the "Default Printer" on the workstation to be a non-pdf printer
4. Uninstall the PDF Converter using PL_ADVANCEDOPTIONS_UI in Sage, and then re-install it with the "Lock File" option
5. Check the following 2 keys, and clear them:
HKEY_CURRENT_CONFIG\Software\Sage 100 PDF Converter\Jobs
HKEY_CURRENT_CONFIG\Software\Sage 100 PDF Converter\Locks
If there are additional keys similar to the following
HKEY_CURRENT_CONFIG\Software\Sage 100 PDF Converter (redirected #8)
Delete them.
Other General Pointers:
1. Make sure that the Sage users have FULL CONTROL Access of the following registry:
HKEY_CURRENT_CONFIG\Software\Sage 100 PDF Converter
We recommend force propagating permissions to the subkeys
2. Make sure that the Sage 100 PDF Converter security gives full permissions to the users who need access to it.
On a Terminal Server and Traditional Workstation
In the event that the AMYUNI drivers got updated by Microsoft Updates, the above issue may occur.
There are multiple ways to address those, depending on the underlying infrastructure.
1. If using any RMM that supports patching (i.e: Connectwise Automate, Kaseya, WSUS), a policy can be put in place to prevent certain updates from applying on the target machines.
Before completing the next step, make sure you manually
update the AMYUNI driver to the version level that you know works.
2. For those without central management of windows updates, a specific device driver update can be blocked via Group Policy or with the registry:
a. Find the driver hardware ID
- Go to devmgmt.msc and expand "Print Queues"
- Right click on "Sage PDF Converter" > Properties > Details
- Change the drop down to the Hardware ID, and make note of the hardware ID: for example: lptenum\amyuni-amyunidocumentconverter500
b. Now the exception can be made in gpedit.msc or via a GPO depending on the membership of the end user workstations.
- Navigate to Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions
- Enable the policy, then click "Show..." and add the device ID found in the previous step
- Check the box "Also apply to matching devices that are already installed"