Disabling legacy protocols breaks printing predictably

Disabling legacy protocols rarely breaks an entire printer fleet in one move. It exposes different dependencies in sequence: an old job delivery method, an incompatible driver, queue access through an alias, Point and Print installation without elevation, or an MFP feature that the standard IPP driver does not provide. Safe hardening therefore starts with a map of the actual print paths, not with a Group Policy switch.

The most expensive mistake is simple: assuming that every printer shown in the same Windows window works the same way. A \\print01\accounting queue, a direct TCP 9100 port, a WSD device, an IPP queue, and an old LPR port look almost identical until the first policy change. Afterward, one user loses the queue, another sees an administrator prompt, a third can print but cannot select duplex, and a fourth keeps working and creates the false impression that the migration succeeded.

Printing breaks in layers, not through one protocol

You can predict the impact only after separating transport, discovery, authentication, and the driver. These layers are connected, but one checkbox does not replace another. Disabling SMB1 does not prohibit SMB2 or SMB3, blocking RPC over named pipes does not remove a driver, and requiring administrator rights for a driver does not prevent a job from reaching an already installed queue.

A shared Windows queue normally involves a client, the print spooler on a server, a driver, and a port from the server to the device. The client contacts the server over RPC, reads queue information, and transfers the job. Named pipes use SMB underneath, but a modern connection does not require SMB1. If a printer connects directly through a standard TCP/IP port, the print server does not participate at all: the client renders the job locally and sends it to the device's IP address over RAW 9100, LPR, or another selected port monitor.

IPP works differently. The client negotiates capabilities with a device or server through the Internet Printing Protocol, usually on TCP 631, and can use the built-in Microsoft IPP Class Driver. WSD adds network discovery and Windows often selects it automatically, but I do not leave architecture to discovery in a managed network. After an address change or firewall rule change, those queues are harder to explain and reproduce.

It helps to name four different results that support teams often record as "the printer disappeared":

• the queue cannot be discovered or connected;
• the queue connects, but Windows requests elevation;
• the job enters the queue and stalls during transfer;
• the document prints, but the finisher, required tray, PIN printing, or scanning is missing.

Each result has a different owner and remedy. A network engineer checks routes and ports, a Windows administrator checks RPC, policy, and the driver package, and the print service owner checks device functions. If you start reinstalling a driver while RPC is blocked, you can spend hours changing something that was never part of the failure.

There is another important distinction between an "old printer" and an "old path." A ten year old device can sometimes print perfectly over IPP and accept a modern class driver. A new MFP might have been deployed with an old LPR port and v3 driver simply because someone copied a template from the previous server. The age of the enclosure proves nothing. Decide from protocols, firmware, drivers, and required business functions.

Inventory must show every job path

A useful inventory links the user facing queue to its port, driver, server, and functions the department cannot work without. A table containing only an IP address and model is too weak. It cannot tell you who will need an administrator, which queue depends on SMB, or where an IPP move will remove the finisher.

You can collect the first client side snapshot with standard PowerShell cmdlets. Run them in an ordinary user session because that context shows the connections the user can actually access:

$printers = Get-Printer | Select-Object Name, Type, DriverName, PortName, ComputerName, Shared
$ports = Get-PrinterPort | Select-Object Name, PrinterHostAddress, PortNumber, Protocol, Description
$drivers = Get-PrinterDriver | Select-Object Name, Manufacturer, MajorVersion, IsPackageAware

$printers | Export-Csv .\printers.csv -NoTypeInformation -Encoding UTF8
$ports | Export-Csv .\printer-ports.csv -NoTypeInformation -Encoding UTF8
$drivers | Export-Csv .\printer-drivers.csv -NoTypeInformation -Encoding UTF8

In printers.csv, each row should represent a queue and contain at least Name, DriverName, PortName, and ComputerName. In printer-ports.csv, you need to see the port address and protocol. An empty ComputerName is not an error by itself: a locally created direct print queue looks that way. Property names vary slightly across Windows releases and port types, so first run Get-PrinterPort | Format-List * on several representative machines.

The working summary needs more context:

Do not trust server data alone. User profiles retain connections to retired names, local queues pointing at old addresses, and drivers that the server no longer shares. I compare the print server export with a sample of clients in every department, including a laptop outside the office network, a standard rights computer, and one rarely used workstation.

Assign one target path and one temporary fallback to every queue. If the old shared queue, a direct TCP port, and a new IPP queue all remain available under similar names, users will choose whichever one "works today." Telemetry splits, print settings differ, and the old protocol survives longer than planned.

Add the installation source to the map. One queue arrives through a user Group Policy, another is created by a computer script, a third was connected manually, and a fourth came from the manufacturer's application. If you delete the queue without disabling its source, it returns after the next sign-in and looks as though the old protocol restored itself. In a domain, save gpresult /h for the pilot machine and check assigned print profiles in device management.

Also record applications that print without a Windows dialog. An ERP, medical system, or reporting service can store a queue name in its own configuration and run under a separate account. An interactive user test does not touch that path. Such applications need an owner, a schedule, a job format, and a method for resending after failure.

RPC hardening exposes server and network errors

After printing moves to RPC over TCP, clients fail when they were allowed to use only SMB, servers fail when listeners are configured incorrectly, and connections fail when they relied on the old named pipe. Microsoft documents the Configure RPC connection settings, Configure RPC listener settings, and separate RPC over TCP port policies for Windows 11. By default, current clients use RPC over TCP with authentication, while the server listener accepts RPC over TCP and applies Negotiate.

A TCP 135 check confirms access to RPC Endpoint Mapper, but it does not prove that the full print session will succeed. After negotiation, the client needs a dynamic RPC port or a static port assigned by the administrator for print components. This is a common failure between VLANs: Test-NetConnection print01 -Port 135 succeeds, but adding the queue waits and then fails because the firewall permits Endpoint Mapper and blocks the negotiated high port.

I save the result of several checks for initial diagnosis:

$targets = @(
    @{Host="print01"; Port=135; Purpose="RPC endpoint mapper"},
    @{Host="print01"; Port=445; Purpose="SMB for named pipes and administration"},
    @{Host="printer-42"; Port=631; Purpose="IPP"},
    @{Host="printer-42"; Port=9100; Purpose="RAW printing"}
)

$targets | ForEach-Object {
    $r = Test-NetConnection $_.Host -Port $_.Port -WarningAction SilentlyContinue
    [pscustomobject]@{
        Host = $_.Host
        Port = $_.Port
        Purpose = $_.Purpose
        Reachable = $r.TcpTestSucceeded
    }
} | Format-Table -AutoSize

The expected output shape contains Host, Port, Purpose, and a Boolean Reachable field. This is not an automatic verdict. A closed 445 does not prevent direct IPP printing, while an open 631 does not prove the device accepts the required document format. The check exists to connect an error to the selected path, not to produce a row of green values.

I do not recommend switching clients back to named pipes as a permanent fix. The measure is popular because it quickly restores the old connection over SMB traffic that is already allowed. It also retains the dependency the team intended to remove and hides incorrect firewall rules. Microsoft keeps the RpcUseNamedPipeProtocol policy for compatibility, but the existence of a setting does not make it a good target state.

If the organization requires Kerberos for incoming RPC connections, test the actual names used by clients. Access through a DNS alias, cluster name, or old migration name might not obtain the right ticket if service names are not registered correctly. Workgroups and untrusted domains also need a separate decision. Do not enable ForceKerberosForRpc first and then treat every naming error as a printer failure.

A static RPC port makes firewall rules simpler, but it creates a point that must be documented and tested when the role moves. If the port is occupied, or the policy reaches the client but not the server, the failure is difficult to read. Apply the setting to a pilot server first, confirm that it is actually listening and inspect the PrintService log, then open the path between specific segments.

Access denied messages also cannot automatically be assigned to queue permissions. The client may have used the wrong authentication protocol, contacted the server through a name it does not recognize as its own, or received the RPC policy before the server. Compare access through the primary fully qualified DNS name with the alias in use, but do not leave users with two permanent addresses for one queue. That test identifies a naming problem; it does not propose a workaround.

Point and Print no longer promises installation without an administrator

A standard user can connect a queue without a credential prompt only when Windows already trusts the required driver or uses a built-in modern driver that needs no third party package installation. Since the Windows updates of August 10, 2021, the default RestrictDriverInstallationToAdministrators value requires administrator rights to install or update any driver through Point and Print.

KB5005652 states this plainly: a value of 1, or an absent value, restricts installation to administrators, while 0 reduces protection. Microsoft also says that a combination of extra restrictions does not provide protection equivalent to 1. Permanently disabling the restriction for user convenience is therefore an accepted risk, not a repair.

The correct route for an existing fleet is to stage an approved driver package through device management, the OS image, or software deployment running with system rights. This example uses a prepared directory:

pnputil.exe /add-driver ".\ApprovedPrinter\*.inf" /subdirs /install
pnputil.exe /enum-drivers /class Printer

The first command needs an elevated context, so an administrator or management system runs it, not the user. From the second command's output, retain Published Name, Original Name, Provider Name, Class Name, the date, and the driver version. The INF name in the package differs from the published oemNN.inf name, which often confuses removal and verification scripts.

After staging, the user connects the queue and Windows matches it with the available driver. Test a fresh installation and a queue update after changing the version on the server. A fleet can pass the first test and then prompt every employee a month later when an administrator replaces the server driver and clients see a different package.

The displayed driver name matching is not proof that the package matches. Two versions may have the same name but different INF files, signature catalogs, and file sets. On the control sample, compare the provider, date, version, and published package name. Otherwise, the team sees a familiar DriverName string and misses the update that triggers elevation.

There are three safe patterns for operation without a local administrator:

1. Preinstall an approved driver on managed computers.
2. Move compatible devices to Microsoft IPP Class Driver plus the manufacturer's support application when it actually retains the required functions.
3. Create the queue centrally in system context with a fixed port and driver.

A temporary RestrictDriverInstallationToAdministrators=0 setting is acceptable only as a controlled window with an exact machine list, a restoration time, and a verified server. Giving users local administrator rights is worse because it extends risk far beyond printing and does not solve driver version management.

Check old v3 drivers, package awareness, signatures, and architecture separately. The name "universal driver" does not guarantee that the package supports unattended deployment. Some installers first copy the driver and then add services, port monitors, or applications. pnputil installs the INF package but does not reproduce every action performed by a vendor installer. If a queue depends on such a component, record the dependency instead of hiding it under the word "driver."

SMB1 and LPR/LPD need replacement, not permanent exceptions

Disabling SMB1 should not break a current Windows shared queue because supported Windows versions use SMB2 or SMB3. Microsoft has not installed SMB1 by default since Windows 10 version 1709 and Windows Server version 1709. If printing stops specifically after SMB1 removal, you have found an old client, network gateway, device with an embedded share, or server that already needed replacement.

A named pipe and SMB1 are not synonyms. RPC over named pipes can work on SMB2 or SMB3. That distinction matters during investigation: enabling SMB1 "just in case" sometimes fixes nothing while returning an obsolete protocol to the host. Inspect the negotiated SMB version and the particular path, not the word SMB in a diagram.

LPR and LPD also require precise terms. LPD is the service that receives jobs, LPR is the client side submission, and the Windows Standard TCP/IP Port Monitor can contact a device in LPR mode. Microsoft deprecated LPR/LPD starting with Windows Server 2012 and now explicitly advises UNIX clients to move to IPP before component removal. A Windows client can still print to a UNIX compatible queue through the standard port monitor, so first identify which side is acting as LPD.

A poor migration plan looks like this: the security team removes the LPD component from the server, tests printing for one Windows employee, and closes the change. Overnight, a UNIX batch system sends reports to the same LPD queue and receives a failure. In the morning, the warehouse has no documents. The inventory did not include the job source because the team looked only at installed Windows printers.

Choose a target replacement for every dependency:

• replace an old SMB1 share with a queue on a supported SMB2/3 server or with IPP;
• replace LPD intake from UNIX clients with IPP and verify queue names in scripts;
• replace direct LPR to a device with IPP or RAW 9100 when segmentation and protection requirements allow it;
• replace a vendor port monitor with a standard method only after testing accounting, PIN printing, and consumable status.

RAW 9100 is not a "new secure version of LPR." It is a simple job delivery channel and usually lacks the authentication and encryption properties expected from a modern service. It can be a reasonable temporary target inside an isolated segment, but do not declare it equivalent to IPP with protected transport.

An SMB1 exception in a separate VLAN can sometimes buy time to replace an industrial device. Such a decision must include blocked routing to user segments, fixed peers, an owner, a removal date, and traffic observation. "The printer is still needed" defines neither the risk boundary nor the exit plan.

Direct IP printing removes the server and its controls

A direct TCP/IP port restores printing quickly during a server problem, but it also moves the driver, queue, and job processing onto every workstation. This is tolerable as an emergency measure for ten identical computers. Across hundreds of devices, it creates a distributed fleet where addresses, tray settings, and driver versions drift apart.

A print server provides more than a single point of failure. It centralizes queue publication, permissions, driver versions, and some job logging. With a direct port, the network printer must be reachable from the user segment, which increases the number of hosts that can contact the device. If the firewall previously permitted connections only from the server, the new design needs a different rule.

In practice, the bypass often appears during an incident. An administrator adds a Standard TCP/IP Port to an executive's computer, selects an available universal driver, and gets a test page. A week later, the address belongs to another device, the old driver remains, and nobody remembers why that computer bypasses the queue. When the organization adds PIN printing or accounting, the bypass does not support the new function.

If you must use direct printing, deploy it as managed configuration:

Add-PrinterPort -Name "IP_10.40.12.42" -PrinterHostAddress "10.40.12.42"
Add-Printer -Name "Warehouse-42" -DriverName "Microsoft IPP Class Driver" -PortName "IP_10.40.12.42"
Get-Printer -Name "Warehouse-42" | Format-List Name,DriverName,PortName

This example shows the shape, not a universal command for every device. A Standard TCP/IP Port is normally intended for RAW or LPR, while an IPP queue is better added through its IPP URI and a supported Windows mechanism. Do not combine an IPP driver name with an arbitrary RAW port without testing. The device and driver must agree on the job format.

Set an expiry and a return method for the emergency path. The deployment script must be able to find the created queue by exact name, verify that no other queue uses the port, and remove only its own configuration. A manual note saying "delete the printer later" almost always leaves remnants.

Direct ports are often unacceptable in environments that require document accounting, PIN printing, or held jobs. A port can bypass server authorization and event collection. Before deployment, ask the process owner what evidence must remain and where the release decision is made. A working test page does not answer that question.

Driverless IPP changes the feature set

Moving to IPP and the built-in Microsoft IPP Class Driver reduces dependence on installed packages, but print compatibility does not mean every old driver feature is identical. Basic paper sizes and duplex often work through capabilities advertised by the device. Finishers, special accounting, secure release, custom color profiles, and some scanner functions need separate verification.

The modern Windows print platform is designed around Mopria compatible devices, IPP, and print support applications. Microsoft has also published a plan to end servicing for third party v3 and v4 drivers through Windows Update. This does not mean an old driver suddenly stops printing on one date. Existing packages can still be installed, but designing new architecture around endless updates to those drivers is no longer sensible.

Windows protected print mode draws a harder boundary. When enabled, Windows uses Windows Ready Print, removes printers that use third party drivers, and prevents incompatible queues from being added while the mode remains active. A Mopria compatible device that previously used a vendor driver may be removed and then needs to be reinstalled through the modern stack. Microsoft separately warns that some scanners, XPS, Fax, and software printers require validation or disappear in this mode.

Do not enable this mode through one broad policy as a way to "clean up drivers." Removing incompatible queues is expected behavior, not an error a restart will fix. First list the queues that disappear on pilot computers, prepare modern replacements, and tell the support team which changes to expect. Software printers need their own replacement process.

The pilot must therefore test a specific set of operations, not a printer model in general. Accounting might need ERP output, selection of the correct tray, and secure release. An engineering group cares about large formats, scale, color, and complex PDF rendering. A clinic reception desk needs automatic document feeder scanning and label printing. A single Test Page: OK result is insufficient.

I use a compact compatibility record:

If the modern path covers 95 percent of jobs, you do not have to retain the old driver for everyone. Give the entire department the primary IPP queue and keep a special managed queue for the small group that needs the finisher. Calculate the percentage from your own jobs rather than accepting it as a universal threshold.

When GSE.kz designs workplaces and system integration, it can connect client computer choices, network segmentation, and print infrastructure in one migration plan. That is especially useful when a fleet must be renewed in stages and servers, workstations, and MFPs cannot all be replaced at once.

A pilot must reproduce failure, not only success

A reliable pilot proves that the new path works and that the prohibited old path is no longer needed. If you test only successful output after the change, you can miss an off domain laptop, a driver update without privileges, an overnight LPR flow, or an application that addresses the queue through an old name.

Build the matrix from real differences: Windows 10 and Windows 11, standard user and administrator, office network and VPN, shared queue and direct port, new profile and a profile with the previous connection. You do not need every possible combination. Select representatives for each unique dependency found in the inventory.

The change sequence must be reproducible:

1. Record the original queue, driver, port, applied policies, and a control document.
2. Prepare the new driver or IPP queue without removing the old path.
3. Apply one group of restrictions to the pilot ring and restart only where the setting requires it.
4. Run functional jobs and a standard user test.
5. Remove the old connection, sign in again, and confirm that another GPO or script does not restore it.

The control document should be unpleasant enough for the printer: several fonts, transparency, an image, mixed page orientation, a selected tray, and duplex. A label or drawing needs its own reference file. Compare more than the presence of paper in the output tray. Check scale, page order, color, finishing, and the time the job appears.

The Microsoft-Windows-PrintService/Admin log and the optional Operational log help distinguish a driver failure from spooler communication. Record the time, client name, queue, and user action. An error code without context often leads to the wrong support article because different layers can produce the same general result.

Rollback also needs a test. Reverting the RPC policy will not restore a third party driver removed by Windows protected print mode, and reopening a port will not restore a queue that a script deleted from the profile. For every change, document what policy can restore, what requires reinstallation, and what jobs will remain in the queue.

A stalled job can corrupt the result of the retest. Before switching paths, record the owner and queue state, then remove only agreed test jobs. Do not delete a queue that still contains unprocessed business documents because batch printing may have no automatic retry. After rollback, send a new document with a unique name so an old job is not mistaken for proof of recovery.

I consider the pilot complete after a driver or configuration update, not after the first installation. The update is what reveals whether an administrator prompt will appear later. Then expand rings by department, leaving enough time between them for one full business cycle, including overnight and weekly jobs.

Every exception needs an owner and removal date

You can keep a fleet operational without restoring legacy protocols indefinitely when every exception identifies one flow, an access boundary, and a closure condition. "Allow SMB1 for printers" is too broad. "Host 10.40.8.15 contacts gateway 10.40.8.20 on TCP 445 until gateway replacement; access from other VLANs is blocked" can be configured and verified.

The minimum exception record contains the business process owner, technical owner, traffic source and destination, protocol, incompatibility reason, compensating controls, next review date, and target replacement. If a replacement date is unknown, assign a review date. Otherwise, the temporary rule becomes part of the network and nobody remembers where it came from.

Do not mix emergency rollback with risk acceptance. Rollback restores a known state for a short time after a failed change. An exception permits one specific old dependency until an agreed event. A permanent global RestrictDriverInstallationToAdministrators=0, SMB1 on every client, or the entire RPC range between all segments fits neither careful definition.

Tie the work plan to dependencies, not printer models. Remove unused queues and old names first. Then stage drivers and target IPP paths. Open the required RPC routes next, run the pilot, and only then disable the previous transport. This order preserves diagnosability: when something fails, the team knows which single change caused it.

Perform the final check with the exception disabled in a test segment. If nobody can explain traffic that appears on the old port, do not enable the rule automatically. Find the source, owner, and job. Print infrastructure becomes safer when the team can name the path of every important document and remove every other path without surprises.