We need to talk about Microsoft's universal print solution. Yes, I know printing is not an exciting topic, but we need to talk about it anyway. To be honest, we’ve needed to talk about it for the past decade, but we’re finally in a place where we can do more than just talk—we can offer a solution to the problem(s) by implementing Microsoft's universal printing solution.
Nobody likes supporting printers, but like it or not, they’re here to stay. Traditionally that meant we were compelled to leave some server or pile of servers lying around in our datacenter, chugging along (semi) quietly, keeping us tied firmly to the 1990’s. It’s been 21 years since the Digital Signature Act was signed on June 30, 2000, an act that should have almost immediately signaled the end of the document printing era, and yet we’re still serving up printers exactly the same way, trying to solve exactly the same problems.
So let’s talk about what printing is, why it’s so vexing, and how we can finally start to solve those ancient problems so we can move on to modern ones.
Printing is composed of many parts:
Print device: the physical object that spits out paper and words and images
Printer: the logical representation of that device, as seen by the computer
Print queue: the list of jobs waiting for the printer
Print spooler: the service that manages printers and queues
Print server: a remote computer running a print spooler and presenting printers to users
Printer driver: the code that runs on your computer and enables the full range of functionality of the print device
Printer port: the interface between the printer and the print device. This can be a network name, an IP address, or a local physical port. It can be assigned to a printer and shared by a print server.
Print job: the stuff you expect to see on the output tray by the time you get to the print device
There’s also generally a network in play, permissions to certain printers, and occasionally the publishing of printers to a directory service.
In ye olden days, all of this was extremely difficult to manage, and this infrastructure was born of a necessity to manage at scale. Prior to Windows 2000, deploying drivers was hit-or-miss, and generally had to be done machine by machine. A print server could host multiple versions of a driver for a given printer, and when clients accessed those printers the server could deliver the appropriate driver for the client’s operating system. This was a godsend that remained remarkably relevant through the mid 2000’s, as even modern Active Directory environments still had a huge mix of client OS’s, and most “enterprise print device” manufacturers didn’t make their print drivers available for download.
Additionally, print devices of the time were generally slow, only occasionally network-attachable, and rarely had enough onboard memory to hold more than a couple of print jobs. Forget about queuing multiple jobs from multiple employees, prioritizing, canceling, or restricting.
And there was literally never ever in the whole history of ever anything at all intuitive or convenient about the management of printer ports. Come at me.
So print servers were a great idea, even if their favorite hobby was crashing. True story: at one job we set a scheduled task to restart the spooler service daily, and at another we actually built a physical cluster server, with shared storage and Windows enterprise licensing and everything, just for printing.
But it’s 2021, and it’s time to retire all of those tired justifications. First of all, Windows 10 is a heck of a lot smarter than ye olden client OS’s. It can find network printers by itself—in fact it will, even if you don’t really want it to. That means we don’t really need that complicated overhead of managing printer ports.
And most companies stopped being weird about their drivers about 6 years ago, so we don’t need to pretend everything’s an HP LaserJet 4+ any more. Nor do we need to serve up drivers for Windows XP, Windows 7, or anything legacy since (ahem) there are no supported Windows client operating systems below 10. They also started building a lot more intelligence and speed into those devices, so what might have been a 2-ppm device in 1998 is probably closer to 60-ppm today, which means it has more RAM to store jobs locally and can handle at least a portion of its own queuing.
Oh and did I mention they’re almost all network devices now? Seriously: can you even still buy a non-network print device?
So what, exactly, is your print server doing that users can’t do for themselves?
If your answer is that it’s simplifying the discovery and management of printers, I have exciting news for you:
Universal Print is here. I’ll give you a moment to collect yourself.
Universal Print allows us to combine the better parts of print management from Windows 10 with cloud-published queues to finally turn off that buggy old print server. Licensed on a per-user basis as part of Microsoft 365 Enterprise or Business Premium, Windows 10 Enterprise, or stand-alone ($4/month), it enables administrators to register and publish printers through an online portal to be discovered and used by Azure AD users. Each licensed user gets 5 jobs per month, but they’re pooled, so if you have 100 users, you’ll have 500 jobs, and the job counter (1) only increments on success, and (2) doesn’t care how many pages OR COPIES are part of the job.
500-print-job add-on packs can be purchased and added to the pool, but let’s be honest: there are probably only a handful of your users actually printing, so if you can stop that one user from printing literally every email they receive, you probably won’t go over your built-in limits.
And yes, I’ll admit that when I first heard about the per-job structuring of print pricing, I was…unimpressed. But then, last month, my 7-year-old printer died and (SHAME! SHAME!!) I had to buy a new one. I have kids: they have to print stuff for school (that’s my story and I’m sticking to it). But that new printer came with a bundled subscription service that allows the printer to order its own supplies for a monthly fee. I did the math on it and discovered that at our printing rate over the 7 year life of the old device, we would have spent 4x the cost of the subscription service on consumables. I’ll take a 4x reduction in cost and the convenience of never having to memorize cartridge numbers for my next run to the store—why wouldn’t I take that same convenience for managing corporate devices?
Crucially, though, Universal Print ends my reliance on Active Directory. To support legacy devices I still have to deploy an on-prem connector near my print devices so they can be published in Azure AD, but that device (server or workstation) doesn’t have to be AD-joined. That means I can finally (FINALLY!!) start work on decommissioning Active Directory on-prem without worrying about orphaning the bane of all existence. I can’t tell you how many organizations I’ve spoken to in the past 3 years who’ve said, “I’d love to get rid of AD and go pure cloud, but my printers...” I might be paraphrasing, but it’s a pretty common refrain.
Once that connector is deployed, print devices can be registered thru it to Universal Print, published to Azure AD, and deployed to end users through Intune.
Printers then can be managed from the Universal Print dashboard, made discoverable or assigned to users, with reporting and advanced feature management much like what you’d expect from a traditional print server, except without daily crashes of the spooler service.
Having played with it, I’m super excited. There’s no question the product is still a little raw, but as with many things v1.0 focuses on functionality, with UI enhancements just a month or two behind. There are .CSV files in play, pre-packaged .INTUNEWIN files for desktop deployment, and as mentioned: legacy devices (currently all “in-market” print devices) require that print connector device. But I expect all of that will improve over the coming months, and by Autumn we’ll be wondering why we weren’t doing all of this 10 years ago.