Can I install PaperCut on a Domain Controller?

THE PAGE APPLIES TO:

Contents

Overview
It muddles up your infrastructure
It won’t work with Mobility Print
Domain Controllers just don’t make good print servers
Where should you install PaperCut instead?

Q We’re new to PaperCut and we’re trying to decide where to install the PaperCut software. Can we install it on our Domain Controller?

Yes… but that doesn’t mean it’s a good idea.

While there are a number of scenarios where it would be perfectly okay to install PaperCut on a Windows Domain Controller, this is something that we would not recommend for a number of reasons which we’ve detailed below.

It muddles up your infrastructure

Note that the following advice doesn’t just apply to PaperCut, but could apply to any 3rd party software suite.

Imagine if you start having a problem with need to install updates and need to reboot the server, or have a problem that requires taking the print server offline temporarily. What normally should be a quick and easy job now gives you gray hairs because you have to worry whether your users will still be able to log in, or whether your Active Directory will continue to replicate successfully.

Also consider that whether you configure PaperCut to run as a service account or run as the default SYSTEM account, PaperCut also need local administrator rights to do it’s job. If this server is also your Domain Controller, it also would mean that the PaperCut service account automatically gets Domain Admin rights. Giving this level of access for your domain to any 3rd party software would tingle the spider sense of cybersecurity expert and violates the principle of least privilege.

Ideally your Domain Controllers should have one role in your organization, which is to manage your Microsoft Windows Domain. Listen to the voice of experience and don’t make the mistake of letting this critical piece of infrastructure perform other roles.

It won’t work with Mobility Print

Domain Controllers often also act as DNS servers. When the Mobility Print application and the DNS service are both running on the same machine, they will often end up fighting over the traffic on port 53, with mixed results. Just don’t do it.

Domain Controllers just don’t make good print servers

We have heard it on good authority and seen several anecdotes firsthand that configuring a print server as a Domain Controller can cause issues. Apparently the act of promoting a server to domain controller resets the permissions on the Windows spool folder and will interfere some rendering tasks necessary for Windows printing, causing print jobs to fail in specific scenarios. †

Where should you install PaperCut instead?

Set up a dedicated print server in your environment to install PaperCut on. This can be a virtual machine or an old desktop. Separating out server roles in your environment onto separate machines is widely regarded as common sense IT. Installing PaperCut on a separate server just for printing will give you piece of mind that printing and Active Directory won’t adversely affect each other and will be much easier to troubleshoot if things go awry.

If your only Windows server is the domain controller and you cannot add any other physical servers, then consider adding the Hyper-V role to this server so that you can set up a virtual machine to act as a dedicated print server. At the time of this writing, a Standard Windows Server license allows you to set up two additional Windows servers as virtual machines. This is a no-cost solution that won’t require purchasing any additional licenses from Microsoft and uses your existing infrastructure.

Still have questions?

Let us know if you need assistance! We’re happy to help. Feel free to leave a comment below to ask questions or reach out to us directly if you’re unsure. We can get you connected with experts to help you set up PaperCut in your organization in the best possible way.

† Firsthand examples from Microsoft’s forum:

Here’s your answer

Did this solve your issue?

Oops!