Stale printer entries from a retired print server persist after migration (Windows 10/11, AD/GPO)

Hola Konstantinos,

Based on what you've described, I don't think the driver store is the root cause. The strongest clue is that removing the Plug and Play device with pnputil works temporarily, but the same printer comes back after a restart. That usually means Windows still has a printer connection recorded somewhere, and the print subsystem is simply recreating the device node from that connection.

The most likely source is an old per-user or per-computer printer connection left behind from the previous print server. If these printers were originally deployed with Group Policy Preferences, there's another common possibility: the old GPP item may have created the connection without "Remove this item when it is no longer applied" enabled. Microsoft documents that Group Policy Preferences don't, by default, remove previously applied settings when a GPO is no longer applied. That would also explain why you've confirmed no current GPO is deploying the printers, but they still remain.

For your first question, pnputil /remove-device is only removing the Plug and Play device instance. It isn't necessarily the removal of the printer connection that caused Windows to create that instance. On the next restart or spooler initialization, Windows sees the surviving printer connection and enumerates the device again. The driver store may supply the driver, but it isn't what tells Windows that \oldserver\printer should exist.

For per-user printer connections, the connection is stored in that user's profile, commonly under HKEY_CURRENT_USER\Printers\Connections. Per-computer printer connections are stored separately under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Connections.

This also explains why removing the printer while signed in as a domain administrator may not work. A per-user printer connection belongs to the user who has that connection, not to whichever administrator happens to be working on the PC. If the stale printer belongs to another user's profile, removing it from the administrator's session doesn't remove that user's copy of it. For a printer connection belonging to the currently signed-in user, I'd use the supported PrintUI removal rather than deleting registry keys manually: rundll32 printui.dll,PrintUIEntry /dn /n"\oldserver\printershare" Microsoft documents /dn specifically as "Deletes a network printer connection".

If the connection was installed per-computer instead, first check the machine-level connections with rundll32 printui.dll,PrintUIEntry /ge and remove the old one with rundll32 printui.dll,PrintUIEntry /gd /n"\oldserver\printershare". Microsoft notes that /gd removes a per-computer connection and that the removal is applied when the user next logs on.

The local administrator versus domain-user difference is another strong indication that you're dealing with different connection scopes rather than a single broken driver. If the printer appears while logged on as the local administrator but not while logged on as a domain user, I'd inspect that local administrator's HKCU\Printers\Connections. Conversely, if only a particular domain user can see it, inspect it while logged on as that user, or load that user's hive and check the equivalent HKU<SID>\Printers\Connections location.

The Foxit behavior also makes sense in this scenario. Settings > Printers & scanners and an application's Print dialog don't necessarily enumerate the same objects. Settings can still expose a stale printer/device association, whereas an application may enumerate only usable print queues returned by the print subsystem. So, Foxit not showing the printer doesn't mean the Settings entry is imaginary; it suggests that what remains may be a stale device/connection object rather than a fully functioning queue.

I would not start by deleting the driver packages. Remove-PrinterDriver and pnputil /delete-driver are supported tools, but removing the driver doesn't remove the thing that is recreating the printer connection. It can also affect other printers if the new server is using the same driver package.

I'd first remove all references to the retired server at the connection level, restart the Print Spooler or reboot, and then see whether the Plug and Play entries return. If they don't, you've confirmed the root cause. If they do return, the next place I'd check is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider. Windows can retain connection information there as well; I would treat direct registry deletion as cleanup for a broken or orphaned connection, though, not the first removal method. Export the relevant key first and use PrintUI wherever possible.

Thanks,

James

Welcome to Microsoft Q&A!

Thank you for the detailed description and for already checking the GPO deployment and the Let Windows manage my default printer setting.

Based on the behavior you described, I would not start by deleting the printer driver.

The first thing to investigate is whether a stale printer connection or queue registration still exists for the affected user or at the computer level. If it does, removing only the Plug and Play device may not remove the configuration responsible for creating it.

1. Why the PnP printer returns after pnputil /remove-device

pnputil /remove-device removes the device instance, but it does not necessarily remove the printer connection or other configuration that originally created that device.

If the underlying printer connection remains, Windows may enumerate it again after a restart or sign-in and create another device instance. In other words, the presence of the driver package in the Driver Store alone does not necessarily mean that the driver is responsible for recreating the printer.

Additionally, /remove-device separately from /delete-driver. The latter is used to delete a driver package from the Driver Store.

For this reason, I would first try to remove the underlying printer connection or queue rather than repeatedly removing the PnP device.

2. Remove the retired server's printer connections

Sign in as the affected domain user and check what Windows sees:

Get-Printer | Format-Table Name,ComputerName,Type,DriverName

If the stale printer is returned, remove that connection:

Remove-Printer -Name "<printer name>"

The important point is to perform the removal in the context of the user who has the stale connection. Removing it while signed in as a different administrator does not necessarily remove another user's per-user printer connection.

For a traditional network printer connection, you can also use PrintUI:

rundll32 printui.dll,PrintUIEntry /dn /n \\oldserver\printer

/dn as the option to delete a network printer connection.

For per-computer printer connections, you can first enumerate them:

rundll32 printui.dll,PrintUIEntry /ge

Then remove the confirmed obsolete connection:

rundll32 printui.dll,PrintUIEntry /gd /n \\oldserver\printer

/ge for enumerating per-computer printer connections and /gd for deleting them.

3. Why the printer can appear for the local administrator but not the domain user

This behavior suggests that you may be dealing with different per-user printer state, rather than a printer that is installed identically for every user on the computer.

A connection created in one user's context may not be present in another user's context. Therefore, what you see while signed in as the local administrator may differ from what the domain user sees.

For troubleshooting, I would run the below from each affected account and compare the results:

Get-Printer

If registry inspection becomes necessary, I recommend backing up the relevant keys first and examining the affected user's hive rather than deleting Print-related registry branches broadly. For legacy printer connections, HKCU\Printers is one area worth examining, but supported printer-management methods should be preferred whenever they can still identify and remove the connection.

4. Why Settings and Foxit Reader can show different printer lists

The fact that Settings > Printers & scanners shows the printer while Foxit Reader does not necessarily mean that either view is incorrect.

Windows Settings, the Windows printing subsystem, and individual applications do not necessarily enumerate and display printers in exactly the same way. An application can also provide its own print interface or filter the queues it considers available.

For that reason, I would use Get-Printer, PrintUI/Print Management, and PnP enumeration to determine what still exists rather than relying on one application's print dialog as the authoritative inventory.

5. Remove the driver only after the printer connections are gone

Once the obsolete connections have been removed and you have confirmed that no other printer needs the driver, you can review the installed printer drivers:

Get-PrinterDriver

An unused driver can then be removed with:

Remove-PrinterDriver -Name "<driver name>"

Remove-PrinterDriver for removing printer drivers and notes that administrator credentials are required.

If you specifically need to remove a third-party package from the Windows Driver Store, first identify its published oem#.inf:

pnputil /enum-drivers

After confirming that the package is no longer required, it can be removed using:

pnputil /delete-driver oem##.inf /uninstall

I would be cautious with /force on production systems, since the same driver package may still be required by another printer.

Recommended cleanup order

I suggest testing the following on one affected workstation first:

1. Run Get-Printer as the affected domain user and as the local administrator and compare the results.
2. Remove any \\oldserver\... connection in the context of the user who owns it using Remove-Printer or PrintUI`` ``/dn.
3. Check for per-computer connections with PrintUI /ge and remove confirmed obsolete entries with /gd.
4. Sign out or restart the computer and check both Get-Printer and Printers & scanners again.
5. If the queue/connection is gone but an orphaned PnP device remains, remove that device.
6. Remove the obsolete driver package only after verifying that no remaining printer requires it.

This approach is safer than starting with pnputil /delete-driver, because removing a driver package and removing the printer connection that may be recreating the device are two different operations.

Also, disabling Let Windows manage my default printer would not normally remove an existing \\oldserver\printer connection. That option controls default-printer management, so the fact that disabling it did not resolve the stale entries is not unexpected.

References:

rundll32 printui.dll,PrintUIEntry | Microsoft Learn

PnPUtil Command Examples for Windows Driver Management - Windows drivers | Microsoft Learn

PrintManagement Module | Microsoft Learn

Remove-PrinterDriver (PrintManagement) | Microsoft Learn

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Dear all,

After some troubleshooting, I managed to resolve the issue by deleting the following registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Print\Providers
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Print\Providers

Since these keys are system-protected, I had to launch Registry Editor under the SYSTEM account using PsExec:

psexec -i -s regedit.exe

On some computers, the antivirus software (eScan) blocked the operation and returned an "Access is denied" error, even when logged in as a local administrator. The workaround was to temporarily disable the antivirus, delete the keys, and then re-enable it.

A note about the registry keys: The affected keys contained subkeys, including entries related to print servers. I deleted the root keys (e.g., PRINTENUM) and recreated them with the same names. Windows then correctly recreated the required subkeys, and the issue was resolved.

For reference, the solution was based on this Server Fault discussion: https://serverfault.com/questions/604161/deleted-printers-keeps-coming-back-and-multiply

Thanks to everyone who contributed their suggestions and support.