Centrally-managed direct IP printing: Is PrinterLogic breaking new ground or exposing new problems?

PrinterLogic's centrally-managed direct IP printing seems refreshingly simple, but will it work across all of desktop virtualization?

For someone who works from home, printing tends to fly under the radar. In fact, I tried to print a few days ago only to learn that the ink in both of my inkjet printers had dried out. Oddly enough, that same day I had a call with PrinterLogic, a company that I chatted with briefly at BriForum after I saw their sign that said “Eliminate Print Servers”. They can’t help with my dried up ink cartridges (I’m currently on the market for a laser printer), but they did show me a new approach to centralized print management.

PrinterLogic has bucked the 20-year trend of centralized print servers, instead choosing to use a centralized management server to configure individual, direct IP printers on endpoints via an agent. On the surface, this approach seems refreshingly simple, and I wanted to take a minute to outline it here in hopes that it can spark a discussion on the benefits and drawbacks of the solution.

Direct IP printing has been a staple of my life for many years, dating back to when I was a consultant. With my laptop on the corporate network but not part of the domain, the easiest way to print was to just hop over to the printer, find the IP and model number, then set it up manually on my machine. It’s fine for me, but unmanageable as a corporate printer management strategy. PrinterLogic’s agent and centralized management was designed to give you the ease of direct IP printing with the management that companies need.

When you roll out PrinterLogic, you set up the printers either manually or by importing them from Active Directory. As part of this process, you can specify the location, capabilities (duplex, color, etc..), device drivers per OS, and printing profiles. What you configure on the management server is then pushed down to the client when the agent fires up.

From there, you can assign the printers to your users, deploy the client, and turn off your old printing environment (you can do it in parallel with your existing environment and flip the switch when you’re ready). Users can connect to their printers in a few ways: Push and Pull. The Push method is what you would expect: you assign printers to users via the management console, and they appear as printers on the endpoint or in their RDSH/VDI session. Pull, on the other hand, is a self-service method whereby users pull up a web page and choose a printer from a map of their floor. This map is created during the setup process, and the specific area a user is shown is based on the client’s IP address and the IP range assigned to that are of the map.

For Push deployments, the client IP is used by the printer deployment rules, which can deploy printers based on user, group, AD container, IP range, and other attributes. Their agent is also aware of whether or not it’s on a Citrix server and what the remote client’s IP address is. This allows you to still take advantage of the client’s location when setting up a printer in addition to using the printing virtual channel if you want (of course, it can also set up the printer in the Citrix session).

The management console itself provides some insight into the print queues that reside on the individual printers as well as the ability to generate reports across your corporation. Based on information in the reports, you can see how much printing you actually do and what settings your users are using. You can also use that information to identify some bad habits and tweak you printer settings to encourage users to use black and white printers, for example, or duplex printing instead of simplex.

PrinterLogic also supports badge-based and mobile printing via additional modules, the latter of which can be done either by sending a document to an email address or by using a virtual AirPrint/Cloud Print queue. In fact, this print queue is the only time that PrinterLogic actually provides their own print queue–everything else relies on the printers themselves.

My thoughts

At this stage, I can see the benefits of managed direct IP printing, especially when it comes to physical desktops or persistent VDI. By directly connecting the client to the printer, the local print spooler is used and there is no WAN traversal of print jobs in branch offices that don’t have a print server. Plus, there are no universal print drivers limiting the feature set of the printer.

What I’m concerned about, probably because I don’t actually have to deal with printing every day, is how this solution behaves in a non-persistent VDI or RDSH environment. With non-persistent VDI, the drivers would presumably get set up every time a user logs in, which I can see taking quite a while. Though it won’t affect the logon time, it might be a while before the printers are ready to be used. Perhaps this isn’t any different than the time it takes to map a user to a printer, though.

The other thing I wonder about is what kind of impact this has on RDSH-based servers. If I have 200 users on a server and each of them has their own printers set up, that’s a lot of drivers on the system. Since I started working with this stuff back in the 1900’s, I’m sort of programmed to avoid that even though I know it’s not as big of a deal anymore. Is this kind of situation ok on a system with 200 users and maybe 50 different printers? I’m not sure, and I’m wonder what you think.

Overall, I think there’s something to this. Like I said, centrally-managed direct IP printing is a refreshingly simple concept, but it’s not like direct IP printing is brand new. Nobody has done this before, which makes me wonder why. That's not a bad thing, though, so we'll just have to see.

The good news is that PrinterLogic is easy to stand up, and you can test it out yourself on a slow afternoon. You have to register with them to get the trial software as opposed to just downloading it, but it’s worth a look, especially if you don’t have anything to help with printing right now.

Pricing is done on a per-printer basis and can be bought as a subscription or as a perpetual license. The subscription price retails for $38/yr per printer, and the perpetual price retails for $84 with annual maintenance that includes support. The Mobile printing and Pull printing modules are priced separately.

If you do take a look, let me know what you think in the comments.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Great article. In a Citrix Provisioning Server environment where you have to worry about a write cache size because the OS drive is actually read only, you don't want print spooling to happen locally. You'd run out of space quick. Or you'd have to buy more expensive write cache disk...usually it's SSDs.