NERR_DestInvalidOp 0X0000086F: Printer Destination Request Fix

Quick answer: The spooler handed the port monitor a control function it doesn't implement — almost always after a driver change or a port reconfiguration. Delete the printer, delete its port, reboot, and re-add both cleanly.

What's actually happening here is a mismatch between three layers that have to agree: the print driver, the port monitor, and the print processor. When you send a job, the spooler routes it to the port monitor for the selected port. That monitor only accepts a defined set of control functions — things like StartDocPort, WritePort, EndDocPort, ReadPort. If the driver asks for something the monitor doesn't recognize (for example, a vendor-specific function like SetPortTimeOuts or EnumPorts being called on a monitor that never implemented it), the spooler returns STATUS_INVALID_PARAMETER, which the RPC layer translates to NERR_DestInvalidOp. 0X0000086F is just that NetBIOS-style name resolving to error 2159 in the Win32 namespace.

I've hit this most often in two situations. First, on print servers running Windows Server 2016 or 2019 where someone replaced a HP Universal Print Driver v6 with a type-4 driver (or vice versa) without removing the old port. Second, on RDP or AVD sessions where a redirected printer appears, then the user reconnects and the session tries to reattach to a port name that no longer exists. The spooler's port record is stale, the driver still thinks it can talk to it, and every job fails with 0X0000086F.

The error is persistent, not intermittent. If you're seeing it once and then it goes away, you probably have a race condition on session startup and a reboot of the client will clear it. If it's every job, work through the steps below.

Fix steps

1. Stop the print spooler and clear the queue. Open an elevated command prompt:

   net stop spooler
   del /F /Q %systemroot%\System32\spool\PRINTERS\*
   net start spooler

   If files won't delete, a job is still holding a handle. Use Process Explorer or handle.exe from Sysinternals to find the lock holder — usually spoolsv.exe itself hasn't fully released. Reboot if you have to.

2. Remove the printer. Don't just delete it from Devices and Printers. Go to Print Management (printmanagement.msc), find the printer under the relevant server, right-click, and choose Delete. This removes the per-printer registry key under HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers\<PrinterName> properly.

3. Remove the port. In Print Management, expand Ports. Find the port the failed printer was using. If it's a Standard TCP/IP port, delete it. If it's a WSD port, delete that too. WSD ports are notorious for this error because the WSD monitor implements a smaller control function set than the TCP/IP monitor, and type-4 drivers often assume the fuller set.

4. Remove the driver package. In Print Management, Drivers. Find the driver, right-click, Remove Driver Package. Tick the box to remove the driver files. If it refuses because a printer still references it, you missed one in step 2 — go back and check other queues on the same server.

5. Reboot the server. Yes, really. The spooler caches port monitor handles in kernel memory, and a restart of the service doesn't always flush the port monitor registry state at HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors. A reboot does.

6. Re-add the printer cleanly. Use Add Printer and pick the TCP/IP port creation wizard directly. Enter the IP, let Windows detect the driver, and if you're using a vendor driver, install it from the vendor's current package — not from Windows Update. Windows Update's driver catalogue is often a version behind and has cost me more hours than I'll admit.

7. Send a test page. If it prints, you're done. If you still get 0X0000086F, jump to the alternative fixes below.

If the main fix doesn't work

Two things left to check, and both are common in larger environments.

RDP / AVD redirected printers

If the failing printer is a redirected one (name usually starts with something like Microsoft Print to PDF (redirected 3) or a vendor redirect), the problem is on the session side. Disable printer redirection temporarily to confirm:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDisableCpm /t REG_DWORD /d 1 /f

Sign out, sign back in, and see if the error stops. If it does, you know the redirect is the trigger. The permanent fix is usually to update the Easy Print driver or, better, to install the matching native driver on the host and disable Easy Print fallback in the RDP client (RedirectPrinters:i:0 in the .rdp file, plus install the printer driver on the session host).

Type-4 driver on a legacy port monitor

If you're using a v4 (type-4) driver on an old LPR or custom port monitor, it will fail with 0X0000086F every time. v4 drivers call a wider set of monitor functions than v3 drivers do. The real fix is either to use a v3 driver from the vendor, or to replace the port with a Standard TCP/IP port (raw, port 9100). Check with:

Get-PrinterPort | Format-Table Name, Description, PrinterHostAddress

If you see an LPR port, that's your culprit. Recreate it as TCP/IP raw.

Prevention

Don't upgrade a driver in place on a production print server. Install the new driver as a separate package, create a parallel printer object using a different name and a different port name, test it, and only then migrate users. In-place driver upgrades leave the port monitor association in a half-state that nothing short of the full delete-and-recreate above will clear. Also: keep WSD discovery turned off on print servers. It looks convenient in the wizard, but the WSD monitor is the single biggest source of 0X0000086F I see in the wild.

One more thing worth knowing: 0X0000086F is not a driver error and not a network error, even though it shows up in both contexts. It's a spooler-to-monitor contract violation. If you diagnose it as anything else, you'll chase the wrong layer for hours.