Can I still install the LPD Print Service feature on Windows Server?

In current Windows Server builds the LPD Print Service optional feature still exists, but it is deprecated, receives no development, and administrators report installation and reliability problems. Building a print pipeline on a component that Microsoft has publicly scheduled for removal is a risk each new server build increases.

What is the replacement for the Microsoft LPD service?

Microsoft's suggested path is for clients to use IPP instead. Where the sending side cannot change — common with AS/400, mainframe and older ERP systems — a drop-in LPD-compatible Windows service such as AmazeLPD receives the same LPR jobs on port 515 (and IPP on 631) so the sending systems need no changes at all.

Microsoft has deprecated the Windows LPD service. Here's what actually breaks — and what to do about it.

Q: Is the Windows LPD service deprecated?

Yes. Microsoft deprecated the Line Printer Daemon (LPR/LPD) protocol starting in Windows Server 2012, and in February 2025 published a reminder that removal is approaching. When the feature is removed, clients that print to a Windows server using LPR — such as UNIX, AS/400, SAP and mainframe systems — will no longer be able to connect or print to it.

Q: What happens to AS400, SAP and Unix printing when LPD is removed?

Any system that sends print jobs to a Windows server over LPR (port 515) stops printing to that server the day the LPD component is removed or breaks. The sending systems themselves keep running; their jobs simply have nowhere to land. Options are to change every sender to IPP where supported, or to install a third-party LPD-compatible receiver such as AmazeLPD on the Windows side so nothing changes on the senders.

If print jobs from AS/400, SAP, Unix, Linux or a mainframe land on one of your Windows servers, they almost certainly arrive over LPR/LPD on TCP port 515 — a Windows component Microsoft deprecated years ago and has now flagged for removal. This page explains the timeline, exactly what stops working, and the three realistic options.

What Microsoft has said, in their own words

The Line Printer Daemon protocol was deprecated starting in Windows Server 2012. In February 2025, Microsoft's official deprecated-features list added a courtesy reminder:

"As removal of the line printer daemon protocol nears, we'd like to remind customers to ensure their environments are prepared for removal. When these features are eventually removed, clients that print to a server using this protocol, such as UNIX clients, won't be able to connect or print. Instead, UNIX clients should use IPP."
— Microsoft, Deprecated features for Windows client

Read that carefully: the day the component is removed, clients "won't be able to connect or print." Not degraded — gone. Deprecated Windows components also receive no development in the meantime, which is why administrators already report LPD Print Service installation failures and update-related breakage on current builds.

Who this hits

If you have…	…this is what stops
IBM i / AS400 remote output queues (RMTOUTQ) pointing at a Windows server	Spooled files stop leaving the output queue — invoices, statements, pick slips, labels
SAP output devices using the LPR access method	SAP spool requests fail to deliver
Unix / Linux / AIX systems printing to Windows with `lpr`	Jobs error or vanish; nothing arrives on the Windows side
Mainframe z/OS JES spool LPR output	Batch print output stops arriving
Oracle EBS Concurrent Manager LPR printing	Concurrent request output fails to print

These pipelines are invisible until they fail. The sending systems keep running happily — their output just never comes out the other end.

Your three options

1. Convert every sender to IPP

Microsoft's recommended path. Works if every sending system supports IPP and you're able to touch each one. In practice, AS/400 output queues, mainframe JES and older ERP systems either can't speak IPP or nobody wants to reconfigure hundreds of queues on a production system of record. Cost is in change management and risk, not licences.

2. Keep the deprecated feature and hope

The LPD Print Service optional feature still exists in current builds — deprecated, undeveloped, and already showing install and update problems. Every Windows Update and every new server build is a fresh chance for it to disappear or break. This is a countdown, not a plan.

3. Replace the Windows side with a drop-in LPD service

Install an independent, actively-maintained LPD/LPR + IPP receiver on the same Windows server. It listens on the same port 515, speaks RFC 1179 itself, and the sending systems never know anything changed. This is what AmazeLPD is — and it also adds the durable spooling, audit trail and per-queue routing the Microsoft service never had.

Why option 3 usually wins

Zero changes on the sending side, one installer on the receiving side, and the deprecation risk is gone permanently because nothing depends on Microsoft's component. The head-to-head stress test is a bonus: 99.8% of jobs succeeded under a load where Microsoft's LPD delivered 4.1%.

Migrating off Microsoft LPD in five steps

Inventory the senders. On the Windows server, check which systems connect to port 515 (firewall logs, netstat -an | findstr :515, or your senders' queue configs). Each remote queue name becomes a queue in the replacement.
Install AmazeLPD on the same server (or a new one). The service starts automatically and listens on ports 515 and 631. The 7-day trial is the full product — no credit card.
Stop or remove the Microsoft LPD service so port 515 is free — or run AmazeLPD on a new host and repoint DNS/IP when ready.
Recreate the queues. In AmazeLPD Manager, create a queue matching each sender's remote printer queue name and set its destination — a Windows printer or a REST endpoint. Hundreds of queues can be bulk-imported from CSV.
Send a test job from each sender. Jobs appear in the job history as Received → Processed → Completed, with a full audit trail. Nothing on the sending side was touched.

Printing from an AS/400? The companion guide walks through the OS/400 side: Printing from AS400 / IBM i to Windows via LPR.

Frequently asked questions

Is the Windows LPD service deprecated?

Yes — deprecated starting in Windows Server 2012, with a February 2025 reminder from Microsoft that removal is near. When removed, LPR clients won't be able to connect or print to the server.

What happens to AS400, SAP and Unix printing when LPD is removed?

Any system sending print jobs to a Windows server over LPR (port 515) stops printing to it. Either every sender moves to IPP, or the Windows side gets an independent LPD-compatible receiver like AmazeLPD so senders need no changes.

Can I still install the LPD Print Service feature?

In current builds, yes — but it's deprecated, receives no development, and admins already report install and update problems. It's a countdown, not a plan.

What's the replacement for the Microsoft LPD service?

Microsoft says "use IPP." Where senders can't change — AS/400, mainframe, older ERP — a drop-in Windows LPD service such as AmazeLPD receives the same LPR jobs on port 515 (plus IPP on 631) with zero sender-side changes.

Start the free 7-day trial See the benchmark