Skip to main content
Participating Frequently
January 24, 2020
Question

Controlling Adobe Acrobat DC 2017 Pro with Group Policy

  • January 24, 2020
  • 1 reply
  • 8713 views

Has anyone used the Group Policy/Active Directory instructions Adobe provides to control Adobe Acrobat DC 2017 Professional?  Here is the webpage Adobe provides users who want to do this.

 

https://www.adobe.com/devnet-docs/acrobatetk/tools/DesktopDeployment/gpo.html

 

I have downloaded their admin templates and installed them in my Active Directory domain.  I can make the setting changes i want in the Group Policy but Adobe Acrobat doesnt pay attention to them.  For example, the Group Policy template has a setting that lets you disable automatic updates. When i enable this setting (which means 'disabled automatic updates'), Adobe Acrobat still does its own automatic updates.  It isnt doing what the policy is telling it to do.  

 

I have called Adobe support and its like they dont even know anything about it.  Or want to test it to ensure it works.  They keep telling me to hack the registry with Group Policy instead.  

This topic has been closed for replies.

1 reply

ls_rbls
Community Expert
Community Expert
January 25, 2020

Hi, 

 

Let me begin by apologizing for a long reply,  and perhaps because it may sound as  ridiculuous as uneccessary lecturing. But Adobe support is right about hacking the registry.

 

I personally wouldn't call it hacking though.

 

Sadly, there's  too much negative connotations associated to that word (and this is probably in great part to the stereotypes in movies and TV shows that in great part are also fueled  with ignorant media outlets who appear to behave irresponsibly when an editorial staff gives zero rats about the content that  hard-news journalists are occasionaly talking about).

 

Oxford Online Dictionary defines Hacking as:
the gaining of unauthorized access to data in a system or computer.

 

You have to ask yourself if this is really what editing registry keys in a windows box means.

 

Thomas-Fenner-Woods Agency, Inc.  explains on CyberAwareness:
People tend to treat “hacker” and “cyber-criminal” as interchangeable terms. The truth is that legal hacking isn’t the exception to the rule, illegal hacking is the exception. All hacking really consists of is cracking a system, and not all systems are illegal to crack.

Computer hacking refers to the practice of modifying or altering computer software and hardware to accomplish a goal that is considered to be outside of the creator's original objective. Those individuals who engage in computer hacking activities are typically referred to as “hackers.”

 

So basically,  in this wide and generic context everyone in these forums are hackers.

 

Morover, the Computer Misuse Act 1990 defines hacking as:
Unauthorised access to computer material, punishable by up to two years in prison or a fine or both. Section 36. Unauthorised acts with intent to impair operation of computer, etc. ... Making, supplying or obtaining articles for use in computer misuse offences, punishable by up to two years in prison or a fine or both.

 

And now that that part is out of the way, I may add that editing the registry settings has nothing to do with "hacking" in the context of the Oxford Online Dictionary and the Computer Misuse Act of 1990.

 

As a matter of fact, knowing how to document yourself to become a professional in this area literally separates you from the jungle in contrast to  whatever evreybody else talks about registry.

 

The same would apply if someone who performs as a network administrator needs to  use packet sniffers, port-scanning vulnerability tools, password cracking and decryption tools with remote administration capabilities to be able to enforce the desired  security standards of their organization. This includes, but is not limited to,  harnessing routers and firewalls to improve the overall security of the network they're responsible for.

 

In that context, those activities  doesn't make a network admin professional a "hacker" as defined " by  the Oxford Online Dictionary and the Computer Misuse Act of 1990.

 

Anyone who performs in an IT management-level role is supposed to know enough in order  to be able to change the generic manufacturer configurations that were shipped with the operating system when it was installed for the first time.

 

And in your case,  if some of the things are not working properly for a particular deployment, then yes;  there are times that you will find that some settings are locked by default so the users are not allowed to modify them. When this is the case you may need to get under the hood to perform "repairs" or enhancements.

 

This brings me to ask you if you're using the appropriate administrative rights to unlock some of the settings that you're trying to modify via Group Policy.

 

My other observation is that you are correct in using the Group Policy / Active Directory templates but, since it looks like we may be missing a step somewhere,  you may also  need to combine Group Policy editing with the Customization Wizard and the Preferences Reference  https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/preferences.html

 

See  Updater-Win (Windows Updates)  section here: https://www.adobe.com/devnet-docs/acrobatetk/tools/PrefRef/Windows/Updater-Win.html#idkeyname_1_26575  and evaluate this note:  Updater (basic settings)

These preferences turn the Updater on and off.

There are two bUpdater preferences: One for disabling services plugins and one for other product updates.
DC Continuous track web and desktop updates are released in tandem to ensure cloud and desktop features and functionality remain synchronized and compatible. Failure to update desktop components while leaving services enabled may lead to an unsupported configuration. In other words, set both bUpdater preferences to the same value.
Updater preferences in the UI have been changed to only show the "Auto" and "Off" options. The Continous track of Reader does not provide any UI options and the default is "Auto".
Both bUpdater and Mode can be used to disable the Updater, but only bUpdater removes the update UI.
Most other updater registry settings have been deprecated and only apply to 11.x and earlier.

 

See also full Preferences Reference here: 

https://www.adobe.com/devnet-docs/acrobatetk/tools/PrefRef/Windows/index.html  and check  for other additional details  here: https://www.adobe.com/devnet-docs/etk_deprecated/tools/QuickKeys/index.html#updates

  

 

jwckaumanAuthor
Participating Frequently
January 25, 2020
Hi. Thanks for the clarification. I won't use the term hack. I'll use edit. 
 
Can you take a look at this Adobe webpage for me? 
 
 
So in my original post, I mentioned that Adobe provides two starter templates for Acrobat and Reader. These templates contain a few of the most important settings, but we can use the Preference Reference to extend them further if needed. I only need to manipulate settings that these templates can manage and have no use for the Preference Reference. Should I expect these templates to work? 
 
We use Acrobat DC 2017 (Classic track). 
 
On the web page I posted at the top, scroll down to 'GPO registry template'. You'll see the starter template for DC 2017 Classic. 
 

DC 2017 (Classic track only)

 

Should I expect that starter template to work with Adobe Acrobat DC 2017 Professional? Should I expect Adobe Acrobat DC 2017 Pro to do what the template policies to do? If it doesn't, should I expect Adobe support to fix it or explain why it isn't working anymore? 
 
What bothers me is that Adobe provides a solution to control their product. When I use it and it doesn't work, they don't help me troubleshoot. They just tell me to use something else. If you bought a car with air conditioning and it wouldn't cool the car in the summer, would you expect the car manufacturer to fix the air conditioning or would you be ok if they told you to roll down the windows instead if you wanted to cool off. Because that is what support basically did to me. 
 
Appreciate you listening and your feedback
ls_rbls
Community Expert
Community Expert
January 26, 2020

Yes, totally understood and all you said is acknowledged.

 

Before I post my next reply, I need a little more info about what OS your clients are running in  your network.

 

Which MS Windows Server version(s) are you using for this deployment? 

 

Are you also using Configuration Manager to handle Group Policies, and Security Policies in the Active Directories?

 

In how many machines  are you pushing out this installation of Acrobat Classic 2017, and what is the average of  user accounts that are autorized  per machine in that domain?

 

NOTE: You should also post this same question in a Microsoft support forum since the scenario that you're replicating for your Acrobat  Pro 2017 Classic Track  was tested only with Windows Server 2012 (or earlier) and Windows 8 clients or earlier. If you're still using Windows Server 2008  & 2008R2 version,  Micrososft support  reached its EOL just a few days ago  this month.

 

Both Adobe and Microsoft  also recommend  specific standards for this deployment.

 

Key detail here is that Adobe recommends to move to Named User License from a seriliazed licensing installation of their product, and the fact that this deployment is only supported with per-machine installs, not  for per-user installs.

 

See here: https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/licensing.html 

 

Adobe also indicates in the Preferences Reference that most of the registry editing options that used to work in earlier versions of Acrobat are now deprecated (it doesn't mean discontinued, mainly just unsupported and at your own risk).

 

But like I said earlier in my first reply, maybe we're missing a step, and it would be a good idea to keep in mind a migration path backup plan to move to Acrobat DC Named User License install model in the near future (just a suggestion).

 

If you remain patient and read a little more, the Admin Reference Guide that I posted for you above basically suggests getting rid of the headache when trying  to disable automatic updates.

 

It won't be necessary since the actual action of applying updates to Acrobat  would handled by the users  in  a per-machine install setup,  giving them  access to the Acrobat application only when they're logged in with their roaming profile credentials (which you can control with GPO in an Active Directory domain by removing access for the user to all updating features at the OS level see here: https://support.microsoft.com/en-us/help/4014345/how-to-block-user-access-to-windows-update-on-windows-server-2016 ). 

 

See also this older thread for  machine-wide disabling updates here: https://helpx.adobe.com/creative-suite/kb/disable-auto-updates-application-manager.html#main_user_account 

 

You can also test before deploying using something like the Windows Management Instrumentation (WMI)  watchdog script with GPO  https://gallery.technet.microsoft.com/WMI-service-watchdog-script-4fab1282  (now talking about real hacking ! 😁  )

 

 

If you don't mind replying back with a brief description of the steps that  you've  followed when applying the  Group Policy templates in your installation, it would be helpful.