How to Deploy Printers via GPO and Fix Deployments That Fail

1. Install and share the printer on your print server, with a signed, package-aware driver.

2. Open Group Policy Management (gpmc.msc), right-click the OU that holds the target users or computers, and create and link a new GPO.

3. Edit the GPO and go to User Configuration (or Computer Configuration) > Preferences > Control Panel Settings > Printers.

4. Right-click Printers, select New > Shared Printer, set Action to Update, and enter the share path (for example, \\printserver\PrinterName).

5. Optional: use Item-level targeting on the Common tab to limit the printer to a security group or location.

6. Run gpupdate /force on a test PC, or sign out and back in, to apply the policy.

If the printer doesn't appear, it is usually one of the reasons below.

GPO printer deployment usually fails for one of four reasons: users can't install the driver, the OU doesn't match the policy type, a name is mistyped, or drivers conflict.

The truth is GPO printer deployments offer a lot of limitations and potential failure points, often resulting in calls to the helpdesk to resolve the deploy printer via GPO issue. This article will cover some basic reasons for failed GPO deployments and provide alternative methods of printer deployment to help you out.

One common problem is due to the Point and Print Restrictions policy not being configured correctly for a deployed printer. This will commonly result in users not being able to download a specific printer driver from a print server. This setting can be configured in the control panel settings under Computer Configuration > Policies > Administrative Templates > Printers. This should be configured in one of two ways:

Disable the policy

This is the easiest and fastest method, but it doesn't allow for granular control over which print servers can be connected to.

Enable the policy

You will need to modify the following settings at a minimum: Set “When installing drivers for a new connection" to "Do not show warning or elevation prompt”.Set “When updating drivers for an existing connection” to “Do not show warning or elevation prompt”.Unless you want to restrict these settings to a particular set of print servers for a user configuration, uncheck “Users can only point and print to these servers” and “Users can only point and print to machines in their forest."

Another reason printers might not be deployed properly is if the linked OU doesn’t match the policy type. If you are deploying a printer using User Group Policy Preferences in a Group Policy Management Console, the linked OU should contain users who need to have the printer installed. If you are deploying a printer using Computer Group Policy Preferences, the linked OU should instead contain computers that need to have the print drivers installed. Linking a User GPP to an OU that only contains computers, or vice versa, will have no effect. When deploying a printer to an OS that is a different architecture than the print server (such as 32-bit Windows 7 connecting to a 64-bit Windows Server 2008 R2 print server), make sure the correct drivers are installed on the print server. Both the 32-bit and 64-bit drivers must have the exact same name for them to associate properly. Deploying a printer will fail if the appropriate driver for the printer can’t be found.

Remember your elementary school days when your teacher would make you double-check your work before you turned it in? The same principle applies to printer deployments. It’s important to make sure there are no typos. It’s a simple concept, but having even a single character off in the print server name, printer share name, etc., will cause the print deployment method to fail even if all of the settings are correct.

If you want to bypass the problems of deploying printers via Group Policy entirely, a simple alternative is to eliminate your print servers and migrate to a centralized direct IP printing platform. Not only are deployments faster and easier, but printers can be delivered to end users with just a few clicks, with no GPOs or scripts required. PrinterLogic's serverless print management integrates with Active Directory and is managed from a web-based console. Set up automatic deployments based on user, computer, container, or IP addresses, use universal drivers instead of working with individual manufacturers, and eliminate frustrating driver problems and policy conflicts once and for all.