[German]In Windows, there are always problems with printers no longer being found or no longer working after updates. I have published numerous articles on this topic in different variations on the blog. A blog reader contacted me because he sees a single reason for the various printer problems in the network. He blames the errors on the users and administrators who integrate the printers incorrectly. I'll deal with the issue here in the blog.
Problem 1: Incorrect network printer integration
Users and administrators are facing the issue, that network printers under Windows disappear from the device list or are suddenly no longer available for print jobs. A blog reader, who wishes to remain anonymous, believes that the reason for all the trouble surrounding network printers lies with the users or administrators. His statement: "Network) printer problems are basically caused by a single fact for which Microsoft isn't responsible".
Variants for printer configuration
The reader writes that, according to his observations, the network printers are simply set up incorrectly in Windows. Network printers can be set up in Windows in the following ways:
- Incorrect: \\server name\printer name
- Correct: \\Servername.ad.local\PrinterName
The first (incorrect) variant usually uses the name of the print server to connect the device. The second (correct) variant binds the network printer via the Fully Qualified Domain Name (FQDN).
Why this matters?
The reader wrote that it causes issues, if the wrong path is taken via the integration via print server names. Especially if all the security precautions of the past years are activated or will be activated by MS at some point, trouble is inevitable (RPC, SMB hardening, protocol adjustments, Kerberos connection, etc.).
The reader notes that there are numerous tips online on how to circumvent the precautions. However, this is actually nonsense, as holes are torn in the security and the solutions are not permanent anyway.
The background: Kerberos
The reason for the persistent network printer problems with "wrong" bindings is simple, according to the reader. Kerberos and almost all newer security features actually require an FQDN and are aligned to Kerberos. Microsoft has built in various workarounds to support the entry of network print server names, the reader wrote. This is because the company has found that most users are unable to integrate network printers properly.
Communication should continue to work via NTLM, even if it has actually been deactivated. But this does not work reliably, the reader wrote. Network print connections set up in this way are often lame and the use of the workarounds mentioned is not really the point.
Problem: Too many devices already set up
The problem, according to the reader's observation, is that there are many printers already configured/connected, both at user and computer level., in a wrong way. Unfortunately, users hardly ever enter an FQDN to access a print server, the blog reader observes. His tip would be to always connect network printers at user level and to throw out printers connected at computer level. According to the observation, these connections also often cause issues.
Problem 2: Duplicate devices
The blog reader pointed out a second problem to me: If the same printer is connected once by name and once by FQDN, then not every function/listing can handle it. This is because sometimes the same entry is used. According to the reader, Microsoft has improved this somewhat over time. But this approach does not work reliably either. Especially on terminal servers where people are working on one machine at the same time, there are always problems, the reader has observed.
His solution was to set up a link to the print server as the FQDN on the desktop. Since then, he has had no more problems in any environment, writes the reader. He notes that he works in the classic way with login scripts to connect the usual printers in a department. This causes the least trouble.
