Common Problems when Deploying Printers with Group Policy Objects (GPOs)

When using Group Policy Objects (GPOs) for printer deployments in your network you have the potential to run into a lot headache-inducing problems when things don’t work correctly (after all, this is Windows we are talking about here—things not going right is expected). Unless you’re an avid script kiddie that knows their way around PowerShell, the task of creating the GPOs is a cumbersome and tedious point and click process in a GUI Windows Server environment, and a lot of things could be overlooked and set up incorrectly. Some of the things that might go wrong or be overlooked can include:

  • Point-and-Print Policies not configured correctly
  • GPOs linked to the wrong OU
  • Incorrect security filtering
  • Incorrect GPO permissions
  • OU not matching policy type
  • Disabled GPO links
  • Incorrect or mismatched drivers
  • Incorrect Print Processor being used
  • WMI filter issues

Essentially, you have multiple points of failure that can cause your printer to never make it to its target user or workstation. And even if everything is setup and working correctly, your printers are being installed while your user is logging into their workstation, which can really slow down login times, resulting in unnecessary help desk calls.

With PrinterLogic’s printer management solution, you have the ability to deploy your printers to your end users in a variety of ways beyond the Active Directory memberships, and they don’t require you to set up GPO’s or scripts to accomplish it. PrinterLogic’s deployment options will allow you to push your printers out by any of the Active Directory memberships (user, computer, group, container, organizational unit), an IP Address or IP Address range, Hostname (you can use wildcards * with the hostname), and by MAC address. So not only have your options for deployment expanded, but the printers don’t get installed while the users are logging into their workstations—they get added after they have logged in and they are being installed as direct IP printers. So you’ve eliminated multiple points of failure and solved or avoided the numerous problems you can run into when deploying printers out with GPOs.

Google Cloud Print Problems: Google Cloud Printer Is Missing

Like most cloud-based solutions, cloud printing has become an attractive option for organizations that are looking to slim their infrastructure, increase the mobility of their client base and shift some areas of IT offsite (usually to a subscription model). Those are all very real benefits, but that doesn’t mean there aren’t issues from time to time with solutions like Google Cloud Print.

For example, it’s not uncommon for end users to find that their Google Cloud printer disappeared. One moment they’re printing fine, and the next moment it’s gone.

So what’s the cause of a missing Google Cloud printer? There are several possibilities, and troubleshooting will require a process of elimination.

First, check to see whether the Google Cloud printer is offline. This can be problematic where legacy printers are concerned, because they require an intermediary cloud printing server of some sort (e.g., a 24-7 desktop) that’s associated with your organization’s Google account. Someone might have simply powered down the printer (yes, it happens more often than we’d like), or there could be a more serious connectivity problem with the server. In most cloud printing setups, this can happen when the WAN connection is interrupted.

If, on the other hand, a native Google Cloud printer disappeared, the number of variables is reduced. But only slightly. In this scenario, the cause of the cloud printing issue could be a printer-related bug in Chrome OS, so you’ll want to make sure that your client devices have all been updated to the latest version. Although the beta channel will often receive these fixes first, betas can be unstable and aren’t recommended for production machines.

In the event that you’re still having trouble, try simply restarting the client. That might restore cloud printing, or you might see that the Google Cloud printer disappeared during the next attempt to print. Don’t throw the client out the window just yet! With any luck, we’re getting a little closer to the root of the problem.

Now, using your organization’s admin account, point your Chrome browser to chrome://devices. If the desired Google Cloud printer is offline but visible, click the “Manage” button. That should bring it back online. Should you still find that Google cloud print is not working, click on “Disconnect” to remove the printer, then reinstall it.

If that still doesn’t work and cloud printing remains unavailable, there’s one more possible fix that has worked for some users. Assuming you’re using Chromebooks, you’ll need to power them off, boot into developer mode, disable the OS verification mode, then re-enable OS verification mode. Specific instructions on how to do this are available through Chrome OS support forums. If it’s successful, the Google Cloud printer will be visible and accessible again.

PrinterLogic SaaS (formerly PrinterCloud) neatly avoids problems with missing and disappearing printers because it establishes direct IP connections between clients and printers while providing all the advantages of a next-generation cloud printing solution. Direct IP printing is also what makes it possible for your end users to continue printing as usual during a WAN outage—an event that would normally knock a Google Cloud printer offline.

Furthermore, with PrinterLogic SaaS you can enjoy powerful centralized administration, self-service printer installation and the elimination of all your printer servers. That has the potential to save an incredible amount of time, headache and costs, resulting in unprecedented ROI from a print management solution. Why not try PrinterLogic SaaS free for 30 days and see what it can do for your organization?

A Guide to Solving Citrix Printing Problems (Hint: There’s a Better Way)

Well over 300,000 organizations around the world rely on virtualization, networking and cloud solutions from Citrix. With such a massive and diverse global installed base, they’re clearly doing lots of things right. Many of those organizations would be lost without Citrix’s powerful and scalable virtualization software like Virtual Desktops.

Printing in Citrix, however, remains a sore spot for server administrators. To give credit where credit’s due, there’s no doubt that Citrix printing has seen incremental improvements over the years as new versions of Citrix Virtual Desktops have been released. But that still doesn’t mean that printing with Citrix is anywhere close to as easy or as straightforward as it ought to be. Even the most skilled admins still have to jump through an inordinate number of hoops to deploy printers properly and carefully monitor the print environment to maintain standard printing functionality. And for their part, end users continue to struggle with routine printing on account of default printers being habitually reset due to policy conflicts, for example, or crashes due to driver incompatibilities.

The list of Citrix printing problems you might encounter is a long one. That’s because virtualization software of any kind introduces extra variables into the print environment, and each of those variables—such as basic printer compatibility with the Citrix software or how drivers are deployed in the session—spawns an almost exponential number of potential flashpoints. Yet there are some print-related problems in Citrix that are more common than others. Let’s take a look at some of them as well as their causes and possible solutions:

Citrix server print spooler crashes: This is one of the most longstanding issues in Citrix print environments. Symptoms include the print spooler hanging or server CPU usage suddenly spiking—and, of course, end-user printing is impacted, prompting angry or exasperated calls to the service desk.

The go-to solution for this issue is usually to restart the print spooler using the Services Console. Sometimes that works, but occasionally the spooler will continue to be unresponsive and CPU activity (visible in the Task Manager) will continue to max out. If this is the case, a specific printer driver could be at fault. To restart the spooler successfully and avoid it hanging again, the problematic driver will need to be identified. To do so, an admin will need to hunt for the driver that has stuck jobs associated with it. Then the driver should be removed before resuming printing.

Unfortunately, removal of the driver is rarely a perfect or permanent fix because clients still need to access the printer. Instead you can try using a different version of the driver or force the affected client machines to use the Universal Print Driver (UPD) in Citrix, which is slightly more forgiving as it is designed for maximum compatibility. Switching to the UPD where possible can clear up some of the driver clutter on the Citrix server and reduce the risk of driver conflicts, although you should first make sure that the UPD supports all the functionality your end users require from a particular model of printer.

Printing policies are ignored: Whereas print spooler crashes are a longstanding Citrix printing issue, properly configured but non-applied printing policies can be one of the most frustrating. What typically happens in this scenario is that there is a conflict with an existing group policy object (GPO) or a related Citrix policy, which then causes the intended policy to assume a secondary role and be overridden.

As anyone who’s worked with GPOs and Citrix policies already knows, these assignments can be an impenetrable tangle of priority and precedence. Admins have even been known to sketch them out on paper like Venn diagrams just to make sense of which subgroup is affected by which overlapping policy.

To determine which GPO is causing the desired policy behavior to be ignored, the best course of action is to run a dedicated test server within its own organizational unit (OU). All policy inheritance should be blocked during this phase. You can then log in using a new user account and confirm that the desired policy takes effect when no others are there to override it. If so, then it’s safe to begin the process of logging out and logging back into the test account—each time adding another layer of existing policy. Sooner or later you’ll notice that the desired policy was ignored, at which point you will have identified the conflicting GPO.

Improper printer deployment: Printer deployment might seem like one of the most fundamental tasks in any print environment, but even today it’s not without its problems in Citrix. Before you even begin deploying printers using a Citrix virtualization solution, you have to choose one of two deployment methods:

  • Auto-create printers: This redirects printers already installed on the endpoint device into the Citrix session. The larger challenge here is not deploying the printers to the Citrix server but rather deploying them to the endpoint device to begin with.
  • Session printers: Printers are initially deployed directly to the Citrix server. Here the challenge is how to get the printers installed for use within the session, whether that be a deliberate manual action on the part of the end user or automation through the use of a logon script or GPOs.

Without a solid print management solution, neither method of deployment is ideal. As noted above, GPOs can be complex and cause policy conflicts that are difficult to troubleshoot, especially in large and distributed organizations. Scripts have to be custom coded and can slow down login times considerably. And unless end users have a simple, one-click route to printer installation, the intricacies of mapping printers can test the limits of their computer skills and leave them relying on routine calls to the service desk for support.

Generally, the only solution for reliable deployments involves increased attention from the Citrix admins—either in the form of babysitting deployments on the backend or holding end users’ hands on the frontend.

The single solution to Citrix printing problems: PrinterLogic

Just as Citrix solutions fulfill organizations’ requirements for enterprise-level virtualization, PrinterLogic fulfills their need for reliable, robust and trouble-free printing in Citrix environments. With its powerful centralized management, its targeted deployment features that don’t require scripts or GPOs, and its ability to empower end users through an intuitive self-service portal, PrinterLogic’s print management software solves the most common and persistent Citrix printing issues in one package. Here’s how:

  • When using auto-created printers, the PrinterLogic software client can be installed directly on the end-user workstation. Through PrinterLogic’s easy-to-use deployment tools, printers can then be automatically deployed to the workstation and redirected in the session through the Citrix policy of printer auto-creation. This method leverages the UPD in Citrix, ensuring broad compatibility and maximum stability.
  • If opting for session printers, admins deploy the PrinterLogic client in the session itself. The intelligent software client is then able to gather information about the end-user workstation from the Citrix session. The correct printers are installed automatically. Because PrinterLogic establishes direct IP connections between the workstations and nearby printers, session printing allows end users to print using the full-featured native printer drivers.

PrinterLogic’s next-generation print management software integrates seamlessly with Citrix environments, so it feels and functions more like a natural enhancement of Citrix printing than a third-party solution. And it’s been carefully engineered, rigorously field-tested and repeatedly proven to deliver more streamlined print management, maximum printing reliability and dramatic print-related efficiencies that save time and costs in both the near and long term, thanks to reduced hardware infrastructure and less need for technical support and oversight. PrinterLogic is not only the single solution to Citrix printing problems, it’s the single solution to enterprise print management.

How to Manage Printer Servers in an Epic Environment

Managing printers in an Epic environment can be rather tricky. In common setups of Epic, there are multiple print servers which you need to have the printers installed on. You also need to have a copy of each printer on each print server. This means that if you have 2000 printers, each print server has all 2000 printers. This can cause major headaches when it comes to being able to manage or update these printers and print servers.

Normally if you were to add or modify a printer, you would need to log into each print server individually and setup up or change the printer on each printer server manually. This can be time consuming and tedious, and it dramatically increases the chances of making a mistake during the setup.

However, most of these problems have a quick solution—PrinterLogic Web Stack (formerly Printer Installer)! With PrinterLogic Web Stack you have the ability to create a printer within a centralized printer management console. Once created you can then deploy or push the printer to the print servers automatically by server name or IP address. This can help manage and update printers on all of the servers by updating the information in one centralized location that you can access from any web browser. With PrinterLogic Web Stack you can centralize your Epic printer management and save time when working with Epic printing.

For more information on how PrinterLogic can simplify your Epic printing environment, download our whitepaper here: /resource-center/

How To Migrate From Windows 2003 to 2008 R2/2012 R2 Print Server

Posted by Jordan Lindsey

Migrating print servers. Not the task every IT person wants. In a growing technological world, you need to support 32- and 64-bit Windows, Mac, Linux, Unix, Mobile and Tablet. Being stuck on a Windows 2003 print server can hinder your productivity as a company and a department. Your server needs to be able to support your growing environment.

When migrating from a windows 2003 print server, you have a few obstacles to overcome. You need to bring over or setup the printer/printer queue’s, 32-bit drivers, add 64-bit drivers, printing defaults (i.e. duplexing, color, paper size), permissions, GPO’s, along with anything else you need on that new print server. The migrating can take place in a couple different ways, but I can tell you now, you are not going to like the driver process.

I don’t think there is a single person reading this blog that would disagree with me saying, driver setup and installation just never works quite right. Here’s what’s involved in the process:

  • Get your 32-bit drivers installed on your new 64-bit server
  • Download and add all of your 64-bit drivers
  • Set up all of your printing defaults (for both 32- and 64-bit)
  • Give out proper permissions
  • Start adding printers (or start modifying your GPO and scripts to automatically modify everyone’s computer)
  • All the while, hoping that it goes smoothly and you don’t get any support calls.

Currently, the most common method used when migrating print servers is to export then re-import the printers through the Print Management Console. The GUI will run the PrintBrm.exe, which can be found in C:WindowsSystem32spooltools. This is not a sure fix, as the 0x80070705 and 0x80070057 – driver not found”errors are very common during a Windows server migration process. I could go on for paragraphs about options, issues and scenarios for migrating your print server this way, but instead I’d like to introduce you to a far easier solution that solves the headaches mentioned above.

Here at PrinterLogic, our application was designed specifically to eliminate all of these headaches for you by enabling you to eliminate your print server (and the single point of failure it creates) altogether, while still maintaining full management capabilities of your entire print environment.

PrinterLogic provides an on-premise, web-based application that fully manages your entire direct IP from one single location, eliminating the single point of failure since everyone is direct IP. There are a ton of features included with PrinterLogic, but I am just going to mention those that are pertinent to the migration/import process.

After you have installed the PrinterLogic application (which only takes 5-10 minutes), you simply go into “Tools”, select “Import/Export” and then select “Import Microsoft printers into Printer Installer as Direct IP printers.” At this point you can browse out through Active Directory or specify the hostname of the print server(s). It will give you a drop down list of every printer/queue setup on the server, that you can then import/copy into Printer Installer by simply clicking on one printer or all of them, selecting a destination folder on the right (from Folder structure you create within Printer Installer) then hit a green arrow in the middle. It will then copy into Printer Installer your entire printer setup including, but not limited to, Printer name, location, comment information, IP, port, 32- and 64-bit drivers, and all the profile information and printing defaults (i.e., paper size, trays, color, duplexing, etc.).

Once imported in, you have two options:

  1. You can then add your 64-bit drivers and profiles (if needed) and push everything out to a brand new server. You will have then migrated from an old to new server.
  2. The other, more effective method is to keep everything in Printer Installer and use a server-less print environment. With Printer Installer you can manage, create, deploy and organize all of your printers, drivers, and who has access to them.

So, why migrate when you don’t need a single point of failure (a print server), when you can become server-less, all while enjoying the direct IP benefits and having centralized management for your entire corporation?

If you’d like to learn more, contact us here for a demo and a free trial.