PDF XChange Forum

As many of you may already know, we have made Active Directory Administrative Templates for the PDF-XChange Editor, PDF-Tools and the Tracker Updater.

In an effort to make these as useful to as many clients as possible we are asking for feedback on what you want to see managed by Group Policy via Administrative Templates.

So tell me:

* What do you use AD Administrative Templates for?
* What would you have us add to the existing templates?
* Any other suggestions for more effectively managing PDF-XChange products across your domain?

We will collect the responses and implement those we can that are most in demand.

Let us know what you want.

As an example, would it be a popular idea to have the ability to set default SharePoint (or other could service) credentials?

This could allow your users to immediately connect to your cloud server, without needing to enter credentials individually for each connection.

Hi there, literally just purchased Editor Plus for our organisation and am looking to push out policies to the users when I noticed you have ADMX templates which is great.

However, they are only computer based templates and not user-based (unless I've missed something), meaning I can't target specific users for specific policies, it's an all or nothing approach per machine.

Are there any plans to introduce user based policies or do you recommend another method?

Thanks in advance.

Hello Castleland,.

Paul is our residential ADMX expert - so I've requested him to review this topic once again and post his feedback on your enquiry. He is in our Canadian office though - so the reply will be a bit later in the day!

Regards,
Stefan

No problems Stefan,

Thanks for getting back to me

Hi Castleland,

you are correct in that we currently only have per machine templates and I am not aware of plans to make them available per user. I will need to consult with the development team as to how practical or even possible it is to do something about applying these per user. I know that Adobe's templates are only per machine:

Adobe:
https://www.adobe.com/devnet-docs/acrob ... e/gpo.html

Note
The product only supports per MACHINE installs. It does not support per-USER installs.

I am just not sure whether that is due to a technical limitation or not. Let me get you a definitive answer, hopefully today.

Hi again Castleland,

we will look into this. The initial response from the development team was luke warm I must admit. There is some concern with how to handle conflicts between per machine policies and per user policies.

What specifically would you want to set per user may I ask?

Paul - Tracker Supp wrote: ↑Tue Feb 19, 2019 11:58 pm Hi again Castleland,

we will look into this. The initial response from the development team was luke warm I must admit. There is some concern with how to handle conflicts between per machine policies and per user policies.

What specifically would you want to set per user may I ask?

Hi Paul,
Thanks for the quick response.

I understand, especially if the software doesn't get installed in a user context, but rather a roaming system one.

However, a lot of software has this ability which is very useful when pushing policies out as it allows to target different groups & operational units.

e.g. you may wish to target the admin group and unrestrict all settings, whilst also allowing general users a more limited list of settings (e.g. managers/volunteers) etc.

If the settings are all editable via registry key you could target the keys directly per user with custom regedits when they log on/off but obviously an admx template is a far superior solution to create depending on the amount of staff in your organisation.

A good example could be with license locking:

In our building we have 20 machines and a desk hopping environment, but we only really have about 3 staff (we bought 5 licenses) that would use the pro features. With a user policy setting, we could target the other 7 staff and hide the pro features and install the software on 20 machines - ensuring we are license compliant because only the users licensed to do so would be able to access the pro features via policy.

At present I've deployed the software to 5 machines, but the other 15 don't have access to the software to remain license compliant, but it means the stafff members have to use those machines if they want to use Xchange Editor.

Hi Castleland,

thanks for the explanation of your situation and needs.

I can see the value in having per user templates myself, however I am told it is not a trivial thing to accomplish. Without getting into the details of why our development team are reluctant to take this on, may I ask if, in your "desk hopping environment" you are using roaming profiles? As I understand it, when using roaming profiles, if you have the license available in HKCU for user A on machine A, then when user A logs into machine B his registry settings should follow him and his PDF-XChange license along with it.

So that begs the question of how to apply the license in these cases. If you apply the key during installation, it will be applied to HKLM as the installer does not have access to users' HKCU hive. If our serial key is in HKLM it is accessible to "all users", if only in HKCU then only that user is licensed. This is often done on terminal servers to have a mix of licensed and unlicensed users, it is also applicable to any multi-user machine.

You can deploy the software to all 20 machines without a license, then give the key to your 5 and have them apply it in session by simply double clicking the xcvault file. You can download the xcvault license key file from your Tracker Account. Then after logging out of that machine and into any another, assuming roaming profiles, their license key should follow them.

Will that work for you?

Paul - Tracker Supp wrote: ↑Wed Feb 20, 2019 5:04 pm you are using roaming profiles? As I understand it, when using roaming profiles, if you have the license available in HKCU for user A on machine A, then when user A logs into machine B his registry settings should follow him and his PDF-XChange license along with it.

Unfortunately, for performance reasons I shy away from roaming profiles so this isn't possible for us. However,

Paul - Tracker Supp wrote: ↑Wed Feb 20, 2019 5:04 pm If you apply the key during installation, it will be applied to HKLM as the installer does not have access to users' HKCU hive.

That explains it as I deployed the vault file using the KEYFILE= parameter.

Instead of having the user click the xcvault file to register the key, is it possible to add the key with a policy reg/file operation at login/logout instead?

i.e. what key entries would be needed in the HKCU path to ensure the license is picked up when launching the app?

I could keep the xcvault file in a central store on the network with permissions for the users licensed set, then add the key path at log and out - just the formatting/syntax is needed from you if that's possible.

Cheers

Hi Castleland,

that's a good approach. Rather than pushing the HKCU keys directly however, I suggest you run
from the user context. So a login or similar script that runs as the target user and as such has access to said users' HKCU. That will not only create the correct keys for you in your user' HKCU but will also encrypt the key. Just be thorough with your permissions on the file. The vast majority of failures here relate to not having appropriate read access on the key file.

Details on the usage of the XCVault utility can be found here: https://help.pdf-xchange.com/pdfxe ... edpub.html

/AddKeys
This command installs all license keys from .xcvault files.

Syntax
xcvault.exe [/AddKeys] [/M|/S|/R] <xcvault_file>
/M – specifies that new keys are added in the HKEY_LOCAL_MACHINE registry section and administrative rights are required.
/R – specifies that new keys will be unencrypted when added. Please note that this does not affect existing keys.
/S – specifies that the command is not permitted to show error/information messages.

Examples
xcvault.exe /AddKeys "c:\Personal.xcvault"
xcvault.exe "c:\Personal.xcvault"