The label printer prints blank labels via RDP Redirect

The problem occurs when trying to print labels of non-standard sizes, such as 58x40 mm or 58x30 mm, from a terminal server to a local printer via the standard RDP Redirect device redirection mechanism. In this setup, the server sends the job not directly to the printer, but through the print redirection mechanism, so some parameters may be processed differently than with direct network printing.

When a label printer starts printing blank labels over RDP

This situation is typical in terminal mode, when the printer is physically connected to the client PC, while printing is initiated from a remote server. This is relevant for Xprinter, Zebra, and Godex printers. Most often, the issue appears specifically when printing labels rather than regular sheets, because for a label printer the exact media size, feed mode, and correct transmission of driver commands are critical.

How to understand that the problem is in RDP Redirect

First, check the same template locally, without RDP. If the printer works correctly locally, but starts failing through the terminal server, then the cause is most likely Redirect or the driver on the server.

• the first label prints correctly, the following ones are blank

• the printer feeds out a long strip of blank paper

• the printer enters an error state after the first job

• the RDP session freezes or disconnects at the moment the print job is sent

Why label printing becomes unstable because of Easy Print and Redirect

Loss of page settings. RDP Easy Print or another redirection mechanism may ignore some of the driver settings on the client side or replace them with session parameters. As a result, the paper size may reset to the default value, and the printer receives the job with incorrect label parameters.

Easy Print driver. Using the universal Microsoft driver instead of the manufacturer's native driver often does not allow correct transmission of specific TSPL or ZPL commands.

Channel instability. Redirect adds another link between the server and the printer. If the channel is unstable, or if the drivers on the server and the client behave differently, the job may complete incorrectly.

How to restore stable label printing

For stable printing, you should remove RDP Redirect from the printing chain whenever possible. Choose one of the options below, from the best to the compromise one.

Option A. Direct network connection of the printer via Ethernet and Standard TCP/IP Port — recommended

This is the main option if the printer has a LAN port. In this setup, the server communicates directly with the printer, without RDP Redirect and without an intermediate PC.

On the store side:

• connect the printer to the router with an Ethernet cable

• assign the printer a static local IP address or set up DHCP reservation in the router

• make sure the printer is accessible on the local network

• if the server is rented in a data center and is not connected to the store via VPN, the printer's local address alone is not enough. In this case, the store side usually needs a public IP address, port forwarding of port 9100 to the printer's local address, and external access allowed only for the server

Connection with the server:

• via VPN — if a VPN is configured between the store and the server, the server will be able to communicate directly with the printer's local IP address

• via external access — if there is no VPN, you can configure access to the printer through the store's router. This usually requires a public IP address at the store and port forwarding of port 9100

On the server:

• install the manufacturer's native driver

• add the printer via Standard TCP/IP Port

• specify the printer's IP address within the VPN or the store's external IP address if port forwarding is configured

• if the model supports direct RAW printing, use port 9100

This is the option that should be considered first if the printer has Ethernet. It is more stable than printing through a client PC, LPR/LPD, and RDP Redirect.

Option B. USB printer via VPN, shared access, or LPR/LPD — a workaround option

This method is suitable if the printer is connected to a local PC via USB and does not have a LAN port. In this setup, the server does not work with the printer directly, but communicates either with the PC that has shared the printer or with the LPD service on that PC.

Via VPN and shared printer:

• share the printer on the local PC

• connect the store and the server via VPN

• on the server, add the printer as a network resource using a path like \\IP_or_PC_name\Printer_name

Via LPR/LPD:

• enable the LPD print service on the local PC

• open port 515 in the firewall

• on the server, create a Standard TCP/IP Port and select the LPR protocol

• specify the PC's IP address and the exact queue or printer name

Important: LPR/LPD works only when the server can actually see the PC with the printer over the network. If the server is rented in a data center, and the store works over the internet without VPN, this option usually requires a public IP address on the store side and port forwarding of port 515. Therefore, for a remote server, LPR/LPD is not a universal solution and is inferior to direct network printing to the printer itself.

Option C. What to do if you have to stay with RDP Redirect

If it is currently impossible to change the connection scheme and you have to keep Redirect, then you need to stabilize RDP printing as much as possible.

• disable Easy Print on the server if you switch to a legacy or native driver. Path in Group Policy: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Printer Redirection → Use Remote Desktop Easy Print printer driver = Disabled

• synchronize the drivers. Install the same driver version on both the server and the client

• do not rely on one “correct” version for all models, because stability depends on the specific printer, connection interface, and printing setup

• check whether the same driver and template print correctly locally on the client PC. If everything is fine locally, but the problem remains only through Redirect, then the cause is almost certainly the print path through RDP

How to verify that label printing works stably

• set the label size in the driver on the node from which the printer actually receives the job: on the server for direct TCP/IP printing, or on the client PC for local printing

• print a series of 5 different labels from Torgsoft

• printing should start immediately, without skips, unnecessary feeding, or stops

• after that, check another longer series to make sure the failure does not occur after the first label

How to avoid repeated label printing problems

• avoid using USB extension cables for printers

• disable power saving for USB hubs in Device Manager

• for постоянной нагрузки use printers with a LAN port instead of USB

• do not leave RDP Redirect as the main label printing scheme if it is possible to switch to direct network printing

What is important to remember

RDP Redirect may work for regular printing, but for labels it often produces unstable results. If the printer has Ethernet, it is best to connect it directly via Standard TCP/IP Port and RAW 9100. If the printer is connected via USB, use VPN, a shared printer, or LPR/LPD only as a workaround. RDP Redirect should be left only when it is currently impossible to implement another connection scheme.