Link to home
Start Free TrialLog in
Avatar of baleman2
baleman2

asked on

Add multiple printer drivers to Windows Server 2008

I need to add drivers for HP 2015, HP 2055, and HP m401n printers to a Windows Server 2008 server - Terminal Server.

In our domain, we have end users who have these printer models connected directly to Windows 7 Professional computers via USB cables.

I'd like to insure that the 64 bit drivers for those models listed above are installed on the Server.

If I use the "Add Printer" Wizard, what port do I choose for installation?  These printers are NOT physically connected to the server.
Avatar of Mase2k
Mase2k
Flag of United States of America image

It sounds like what you want to do is just add the drivers so that when your people connect through Remote Desktop their printers will map successfully. To do this your best bet is the following:

1. Click on any printer installed on the terminal server
2. At the top of the window should appear "Printer server properties"
3. Click that and then the Drivers tab. Here you can see a nice layout of all drivers currently installed as well as their processor type (x32/x64)
4. Click Add to install the drivers selectively that you desire

That should do it for you.
Good grief! Don't go near the "Add printer" wizard! You need to enable the "Print Server" role and then use that. This is the *only* way to manage multiple printers on a Terminal Server for users to use - definitely don't add fake printers to the local printers option. Aside from being unmanageable, that would also display to users a bunch of garbage printers that will confuse them.

1. Go to the Server Manager and enable the Print Server role.
2. Once enabled, go to that new role and in there you can see a section called "drivers". You can add both 32 bit and 64bit drivers in here, regardless of the OS. These drivers remain available to RDP users from then on. You can add all the variants, like PCL, XPS, PS, etc, too.
Avatar of Dirk Kotte
i think you should not install the print server role ...
the only the TS need is the driver with the name like the driver at the client.
i install the printer at the server (i use lpt1 or another fake port) and then delete the printer.
the driver remains at the system ... that's enough.
These printers are NOT physically connected to the server.
In that case I assume they're network connected. You need to create a Standard TCP/IP port for each printer, each with the IP address of the associated printer. Apart from the IP address, you can give the port a name that reflects the name of the printer, or something else to remind you which printer it belongs to.
Sorry, with all due respect to the two experts above, those are both not good pieces of advice.

Firstly, if you add a fake printer to LPT 1 and then delete it, as dkotte suggest, instead of using the print server role, you cannot add printers of both 32 and 64 bit driver type and you will have a massive, painful process to add dozens of printers of type XPS< KV, PCL, PS< etc, etc, etc. You will have no GUI method to manage the printer removal and changes and you will have no idea what drivers exist.

Secondly if you add a *real* prtiner, like hdhondt suggests, you will wind up with dozens of printers all users by RDP will see... and this important... which will be completely useless to them because they are not connected to these printers. Your RDP users are not in the same LAN, so they're connecting via RDP Easy Print, to their own printer. Unless they also have MPLS or a VPN, you can't use TCP ports to print - you have to print over RDP via Easy Print.  So that method will not work *at all* but it will flood the users with printers.

Please use the Print Server role because this is *precisely what it is made for*. Don't try to bodge up your own hacked together method. Microsoft made the Print Server role *exactly* for this reason -and it's free. It's like 2 clicks to install it. It's built into the OS. Please use it.
ASKER CERTIFIED SOLUTION
Avatar of hdhondt
hdhondt
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The print server role is a good solution also though adds some extra steps. It's also designed for a bit more than just adding drivers like baleman2 wants. To each his own though...Both HostOne and my solutions will work winningly for what you are trying to accomplish.
Dkotte,
     My instructions are almost word for word Method 2 on your link. Thanks for sharing!
Avatar of baleman2
baleman2

ASKER

Will use the instructions from HostOne to add the Print Server role today.  Will report back results asap and award points.
Have installed the Print Server role on the Terminal Server.  When I logon to the Terminal Server via RDP (as an Administrator), I'm not seeing what I expected to see.

What I expected to see (and be able to control) is a list of printers, i.e., the printers (default printer installed on the client PC) from other end users who have logged into the same Terminal Server.  When I drill down to:  Print Management->Print Servers->TS1(Terminal Server)->Printers, what I see are the printers installed on my own PC.  Nothing else.

However, under: Print Management->Print Servers->TS1(Terminal Server)->Drivers, I see  dozens of different drivers listed.

Should I also see the printers of our end users listed somewhere on these screens?
By default you will only see/be able to manage your own redirected printers. If you want to see all redirected printers you need to add yourself to the Print Operators group on the server. You may find this article extremely valuable!

http://blogs.msdn.com/b/rds/archive/2007/10/05/introducing-terminal-services-easy-print-part-3.aspx
How do I add myself to that group?  
Do I add myself to that group on the Domain Controller? . . . or,
Do I add myself to that group ONLY on the Terminal Server?
Add yourself to that group on the Terminal Server local users and groups.
Got it.  Have done so and can now see all printers.  Will test a few things now and report results later in the day.
This may need to be addressed with another question altogether.

We've been having a terrible problem with TS printing when attempting to print from 3rd party software.  

The software vendor has been pushing me toward this resolution:   Install the exact same driver version of over 75 different printer models - HP, Brother, Kyocera, Ricoh, Konica Minolta, etc.  Under the brand names just mentioned, there are varying models.  For instance, HP 2015, HP 2055, HP m401n, are connected to several end users' computers.  Some are networked with an IP Address assigned and some are connected to the local end user PC via a USB cable.  Some computers are running 32 bit OS and some are running 64 bit OS; so, there could be two different drivers per model.

Anyway, that solution has been a nightmare to implement and the results are not good.  There are sometimes long delays in print job completion - even a 1 page print job can take 5 minutes.  The very next print job from the same PC can complete in 5 seconds.  This is a random occurrence that happens to over 400 end users in our domain.

Since adding myself to the Print Operator's Group, I can now see that the Driver for every printer listed is "Terminal Services Easy Print".  Documentation from some of the links provided in this thread of messages explains that this is correct.  

The printers listed now correctly show those model names that the print job should go to.  In addition to those printers, I also see the following names under the "Printer Name" column:  1) Fax, 2) Microsoft XPS Document Writer, 3) HP ePrint, 4) PDF Complete, 5) Nitro PDF Creator.  I'm assuming these are printers that are in the end users' local "Devices and Printers" folder and are being created on the Terminal Server as the end user logs in via RDP.  Is the creation of these additional printers "taxing" the resources of the Terminal Server in any way?  Do any of these printers NEED to be created for other printing processes to be completed?  If not, do I need to have the end users delete any of these printers from their own "Devices and Printers" folders so that they no longer get created on the Terminal Server?

Thanks for all your help!
Every mapped or redirected device taxes the system to some extent. If the others are not needed I would definitely get rid of them. They would need to be removed on the users end.
Have spent much of the day testing this "new" setup.  Still have random incidents of extended "wait" times before a document prints.  The attached file is from the Event Viewer.  

Any help on this error?
3.bmp
As I mentioned above, all RDP clients (which can support it) will use RDP Easy Print wherever possible. This means you're less likely to require a mirrored printer on your system - but your best option is indeed to have a printer driver installed, using the Print Server option I spoke about above, for each and every printer end users will require. Many of these printers are already covered by the OS but yes, you should indeed find out all the printer models and driver types people are using and make them available on your server. All you need to do is drag the print driver file into the Print Server GUI. You absolutely do not and should not add an actual printer. That's not how remote desktop clients print.

Using this approach allows you to add 32 bit and 64 printer drivers and yes, you should do both, where necessary. Even on a 64bit OS, you can and should add the 32 bit driver to the Print Server for the end clients who require it.

As for users logging in with say 5 local printers, and having them all map as RDP Easy Print, does this put load on the server? Yes but it's negligible.

So, as to your question about why print jobs are taking time, my first guess would be bandwidth. As you may or may not be aware, many printers will require raw print files to be spooled to them - go and try this yourself. Print a file that is say 100k to your printer (local) and watch the print queue on your machine. You'll see the print file going to the printer ends up being 10MB or 50MB or something, because its uncompressed raw TIFF or BMP. If you're not using Easy Print or if the end printer requires this, this will happen to printers over RDP and if the end user is on ADSL, then printing will indeed take a damn long time.

So now I've said all that - finally, I need to address your posted image of the log file error "the print spooler failed to load a plug-in module...." and this pretty much throws out everything I and everyone else said above. This is your actual problem and it's serious and it's not related to RDP. I believe you will find that if you go sit on that server itself (the RDP one) you will find even it struggles to print locally.

That's a general printing error from the server and it relates to pretty much what it says in the error message. You need to fix that, and your RDP issues will go away (as much as RDP printing issues ever go away, anyway).
What he said. Might be time to setup a new question for the additional follow-on issues not covered by your original issue.
@baleman2  Thanks for the points, but you have accepted my comment where I said I was wrong. Can you please explain what solved your problem?
To HostOne, my mistake.  It was this post: 2014-05-03 at 04:45:58 that put me on the right track.

Your suggestion to install drivers on the server for each and every printer that our end users have at their disposal was the key to resolving my printing issues.  That alone, however, did not completely allow all printers to print as they should.

I found another Microsoft document that suggested enabling the policy that allows the OEM printer drivers to be used FIRST, with Remote Easy Print drivers coming into play ONLY when the OEM drivers could not be found.  I don't know why enabling that policy worked, but it did resolve all other printing issues.
Interesting, baleman2.

I've had to set the same setting myself, but only on sites where the end users where all on Mac, not Windows. Usually, EasyPrint is pretty solid for Windows users but older printers can be a bit of a pain with it, to be honest.