Skip to main content

Setting Up Your Print Server

The print server architecture is ScrewDrivers Pro's workhorse: session hosts hand jobs to a ScrewDrivers Print Server, which renders and routes them to Windows print queues. This tutorial builds yours properly and — more importantly — teaches you the pipeline, so print problems become diagnosable instead of mysterious.

You'll need: the Administration tutorial completed, a Windows Server for print serving, at least one network printer, and about 90 minutes (plus a second server if you want to do the failover step).

The pipeline you're building​

Every step below maps to one arrow. When a job fails later, you'll ask "which arrow broke?" — and each has its own check.

Step 1: Prepare the Windows side​

On your print server, install the Print and Document Services role, create queues for your printers in Print Management, and — this matters — test-print from the server itself. The rightmost arrows (queue → printer) are pure Windows; prove them before ScrewDrivers enters the picture.

Checkpoint: a test page from the print server reaches paper.

Step 2: Install the ScrewDrivers Print Server service​

Follow the install guide — run the Pro/Enterprise installer on the print server with only the Print Server Service component selected: Installing the ScrewDrivers Print Server Service. Come back when Get-Service -Name "Tricerat*" shows the service running.

Checkpoint: the service is running on the print server.

Step 3: Register it and add its printers​

In ScrewDrivers Administration, confirm your print server appears as a Print Server object (add it by hostname if not). Open it, refresh its information, and add its print queues as printer objects — then assign one to your test user, exactly as you practiced in the Administration tutorial. The Print Server Printers reference covers every option you'll see.

Checkpoint: the print server's queues are visible as objects, and one is assigned to your test user.

Step 4: Follow a job through the pipeline​

Log on as the test user, print a document, and narrate the diagram to yourself: session agent hands off (5550–5553), service renders to the queue, queue delivers to the printer. Then confirm the evidence trail: the job appears in ScrewDrivers Reports, and the printer produced pages.

If it didn't arrive, check the arrows in order: service running? Cached printer information current? Queue printing from the server (Step 1 still true)? Firewall allowing 5550–5553 from session hosts?

Checkpoint: a session print job reached paper, and you found it in Reports.

One print server is a single point of failure. If you have a second Windows server, make it identical — same queue names character-for-character, same drivers and versions, same OS — install the service on it, then open your primary Print Server object's Failover Print Servers tab, add the second server, and Test Connection. The failover reference explains ordering and the identical-configuration rules.

To see it work: stop the ScrewDrivers service on the primary, print as your test user, and watch the job route through the failover. Start the primary again afterward.

Checkpoint: with the primary service stopped, jobs still print.

What you've learned​

You built the pipeline, watched a job traverse it, and made it survive a server failure — which means you can also reason about it when something breaks.

Where next: Testing Your Deployment finishes the path with systematic validation; multi-server ordering and priorities when you grow beyond two servers; Direct IP for the serverless alternative.