GPO Deployment of the Print Audit 6 client

Print Audit accepts no liability for the content of this knowledge base article or for the results and consequences of any actions taken based on the information provided. This article is designed as a general guide to using Microsoft's Group Policy objects to deploy the Print Audit 6 Client software.  It is not meant as a step-by-by guide to performing a GPO deployment. Using Microsoft's Group Policy to perform software deployment should only be performed by a qualified Windows System Administrator.

GPO Deployment

A Domain Administrator can leverage Microsoft's Group Policy framework for managing computers attached to that domain.  Through GPO, Domain Admins can enforce security and computer policies, change registry entries (through Group Policy Preferences) map network drives, printers and other resources to specific workstations or groups of workstations, etc.  Group Policy also provides a method to install, update and remove software from workstations and servers attached to the domain.

Understanding Group Policy

Microsoft's Technet site defines Group Policy as:

"Group Policy is an infrastructure that allows you to implement specific configurations for users and computers. Group Policy settings are contained in Group Policy objects (GPOs), which are linked to the following Active Directory directory service containers: sites, domains, or organizational units (OUs). The settings within GPOs are then evaluated by the affected targets, using the hierarchical nature of Active Directory. Consequently, Group Policy is one of the top reasons to deploy Active Directory because it allows you to manage user and computer objects." (

Additionally Group Policy also confers the ability to install, upgrade and remove software from managed computers on the domain as noted previously. The focus of this guide is to provide an overview of the GPO deployment process as it applies to Print Audit, not to provide a step-by-step guide to performing a GPO deployment. Group Policy integrates very tightly with the Domain, and Group Policy designs can become very complex due to various factors, such as the large number of policy settings and preference items available, the interaction between multiple policies, and inheritance options. Because of these, implementing a GPO deployment will typically be a non-trivial task that can be summed up in a single step-by-step procedure. There is no substitute for a qualified Windows Administrator when considering using GPO, and this guide will adhere to that maxim.

Preparing Print Audit 6 for Group Policy Deployment

The followings Print Audit tasks need to be completed before you are ready to deploy Print Audit 6 using GPO.

  • Print Audit 6 setup was run, a database was created and the Database Communicator and Administration tools were installed, see the Step by Step Walkthrough for a detailed guide.
  • Print Audit 6 Administrator was run and Print Audit 6 was activated, and configured to run as desired, see the Print Audit Manual for more information. 
  • Print Audit 6 installer was run and a Network Install was performed. For more information on Network Installs, see the Network Installation Guide for a detailed guide.
  • The network install directory from the previous steps was shared out so that it is available to users on the network.
  • Review the contents of package.ini and pa6inst.cfg in the network install directory.
Review the Contents of package.ini:

Package.ini contains information used by the installer (msiexec.exe) to complete the installation of the client, the application name and description, what msi file to execute, and so on.  One particular statement in this file may need to be edited.  Locate the line that starts with Dir=[Some_PATH].  The path indicated by this statement is where msiexec will look for the pa6inst.cfg file, which contains the information needed to configure the client.  If pa6inst.cfg cannot be found at this location, the installation will proceed, but the client will not be configured.  This at a minimum will mean that tracking is not enabled on this workstation. If the 'Ignore Disconnected' option was not set during extraction of the files (see the Network Installation Guide for the various options available when extracting the msi) this will result in print jobs being canceled and an error displayed on the target workstations.

The path after Dir= needs to conform to the path that the client workstations will be performing the installation from.  So if we're installing only the client, and the repository is on a machine called "INSTALLSERV" then this statement should be:

Dir=\\INSTALLSERV\pa6netinstall\clientonly  (The presumes you took the default share name suggested by the installer.)

If during the initial extraction of the msi and supporting files, you target the repository share as the location to extract the files, this path should be set correctly by the installer.

Review the Contents of pa6inst.cfg:

Pa6inst.cfg contains the information required to configure the client, including the location of the database communicator, the port in use by the communicator, as well as the various installation options selected when you extracted the files.  Below is a sample pa6inst.cfg file:

In the install section a 0 indicates that portion of the application will not be installed, a 1 indicates it will, this configuration file will only install the client.  Database type, though strictly not needed to setup the client should conform to the database backend in use.  2 is SQL or SQL Express, 1 is Access.

In the client section is the data that we want to review, the CommunicatorPort needs to be set to the same port number that the Database Communicator listens on. By default this port is 17520, but if you have changed the port from the default, ensure the correct port shows here.  The CommunicatorLocation should be set to either the bare hostname of the computer running the database communicator or the bare ip address, additionally, if using hostnames, ensure all target workstations will resolve that hostname to the correct address. Examples of good and bad location settings:





In the Advanced section are the statuses of the various installation options chosen when extracting the msi and supporting files, 0 means the option is not set, 1 means the option is set. In general you probably won't need to check or change these, but if you decide an option is not needed/wanted, it may be easier to simply change the 1 to a 0 in the pa6inst.cfg file than to run the installer again.

At this point, the Print Audit portion of the process is done, so we can now turn our attention to the Policy Object itself.

Preparing the Domain for Policy Object Creation:

Prior to creating the Policy Object, we'll want to do a little preparation and make a few decisions first.

Will deployment be based on Users or Computers?

With GP you can target software installation through the computer half of the Policy Object or through the user half of the Policy Object.  If you choose to target computers, then when considering what container to target (see below) you would compare the containers based on the computers populating them, likewise the Security Group chosen or created would need to be populated with computer objects.  Similarly if you choose to deploy via the user half of the Policy Object, you would select the container based on the user account populations, and your Security Group would contain user objects.

Either deployment method works, if there are no Domain considerations/concerns or corporate policies dictating which deployment method you can use, you may want to consider the following when making your decision:

When deploying via the user half of the GPO, the software will be installed after the user logs in, after installation, the client requires a reboot before it will start properly, so deploying by the User half means client tracking will not start until the workstation is rebooted after the installation pass. 

When using the computer half of the GPO, the software installation starts much earlier (under the machine account) and completes before the login, when the user subsequently logs in, the client will be started, no additional reboot required.

There may be additional considerations which need to be factored into the decision as well, again a qualified Windows Administrator with knowledge of the existing policy structure should determine whether deployment will be based on users, or computers.

What Container will the Policy Object be linked to?

As noted above, Policy objects "are linked to the following Active Directory directory service containers: sites, domains, or organizational units (OUs)." So the first task will be to determine if you have a suitable container with all the target workstations/users in it, or do you want to create a new container? The site, domain or OU needs to contain all the target workstations/users, but may contain other computers/users as well (GP allows a policy object to be further filtered by group membership).  It may well be that several containers could be targeted for the policy, if no other criteria dictate what container to use, you may want to consider targeting the container with the fewest members. As the policy object is linked to the container, only those machines/users in the container could be subject to the policy, so a mistake in Security filtering that caused the policy to be over-applied, will still limit the scope of unwanted installations.

Within this container you will also want to identify/create one or more Security Groups.  As previously noted, beyond limiting the scope of a policy object to a specific container, GP affords the capability to further filter the application of the Policy Object to members of one or more Security Groups.  Again, you may be able to leverage existing groups, or you may need to create new groups.  Unlike the container, the Security Group(s) should contain only the workstations/users that you wish to install the client on. 

General Overview of Policy Creation:

Again, as previously noted, we're not going to go into great depth here. Creating and implementing a GP mass roll out should only be attempted by a qualified Windows Administrator.  Additionally that Administrator should be familiar with the Domain structure, and intimately familiar with any existing Policy Objects used on the domain. Because of the large number of policy settings, preference items available, the interaction between multiple policies, and inheritance options, undertaking a GP deployment without being intimately familiar with the existing policy objects is a recipe for problems, possibly disasters.

Having said that, once the application has been installed and configured, the client installation repository setup and the various configuration files vetted, and the required containers and groups have been identified/created, the general process of creating the Policy Object is:

1) Create a policy object in the domain and link it to the desired container.

2) Populate the software installation item in either the computer half or the user half of the GPO as appropriate  .

3) Set any required or appropriate Administrative template policies.

4) Set Security Filtering on the object to the appropriate group(s).

5) Ensure the policy is linked and enabled.

6) Test.

Additional Resources:

There are numerous sources for more information about Group Policy, and many of them focus on software deployment via Group Policy, below are some selected links to sites where you can find additional information:

Microsoft's Technet Page for Group Policy on Server 2012R2 -

How did we do with this article?