Win 2008 R2 Terminal Server and printing

Question

Seal

Sadness, not print.

In short, there is a server from 2008 R2. Terminal such, good. Users sit on it, about 200 pieces. They go back and forth, they drive one program.

Users, their mother so, want to print. In order to make them happy, I decided to use a thing called EasyPrint in Win2008R2. If the client has the .NET Framework 3.5 SP 1 installed and the XPS viewer then the terminal server will take over the client's local printers and allow the client to print to any printer that is installed locally. It is very pleasant and convenient.

At first, 10 customers lived and did not complain.

After them started more. Unfortunately, Win XP SP3 (.NET FW 2.0 + 3.5.1 + 4.0, latest upgrades) has one nasty feature. It finds all shared printers on the network and hooks them with the Auto prefix into the system. Ie, each client gets hold of 10-20 printers over the network + local. All this crowd of printers is sucked on a terminal server.

And here the seal turns into sadness.

200 clients * 20 printers is a terrible 4000 printers.

If you go to the server, you can see messages from a spooler that is bent, that it cannot hold so many printers.

If you go into the printer settings and look at the port to which the virtual printer is connected, you will notice that the ports for them are called TSxxxx and the last one ends with TS1024.

In fact, there are no big problems with this. Things are good. Printers suck and print. Log slowly overgrown byakoy, but printing goes on.

And here is the fiasco. We have people who like to print from a notebook. And the seal goes in the strangest way. The first page prints very well. But starting from the second - third page, the printing is in the most terrible font, in which the distance between the letters is not respected at all and it is not possible to read this mess at all.

The same thing happens when programmers print IE9 source code from a page with a PRE tag.

At the same time, Word does not detect such a problem in itself. Only monospaced fonts are affected by the infection.

Deep google gave me the idea that there is a similar bug and it is solved in SP1 for .NET FW 3.0 ( kb946411 )

Installation of this goodness on clients did not work, because clients are updated to the very eggs and all service packs are not in them.

Only server reboot helps.

Question. How to deal with it?
(PS. I still need to serve more than 1024 printers, so don't suggest disabling Auto* printers on the client. I need them to print.)

Is there any third party development? Of course, the solution is welcomed by means of MS itself, because putting something on the server is lousy. By the way, the server itself has not been updated for a long time. Maybe put a hotfix on it?

Answer 1

With a much smaller number of printers and users, we disabled auto-connection of client printers and auto-detection of shared printers on the terminal server itself . The printers are simply connected to the server. If the printer is not in LAN - vpn.

Answer 2

Look at Screw Drivers, although it is paid ... it-bezpeka.org.ua/1c/tricerat-screw-drivers.html

Answer 3

Same problem, just smaller scale. Here I have a problem, of a different nature. A client connects to the terminal server on win2003 remotely, but does not pick up the printer point-blank, what should I do? If you put all this in NET FW 2.0 + 3.5.1 + 4.0, will the latest upgrades on the client help?