Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
The printer could not be installed.
|English: Request a translation of the event description in plain English.|
To removes these error messages, use Active Directory users and computers to open users properties and go to environment tab. Under client devices, clean the check boxes "connect client drives at logon", "connect client printers at logon" and "default to main client printer".
I have installed the printer driver on windows 2000 server by switching to "remote administration mode" first then switching back to "application server mode" and all went fine.
Check ME294429 to see how Win2k and Win2k3 Terminal Services redirects a client computer's local printer ports.
If you get these errors on servers where printer mapping is not needed, open the Terminal Server Configuration, and click connections. Right click "RDP-Tcp" and choose properties. Select the "Client Settings" tab and check off "Windows printer mapping". This eliminated one of the last repeated errors in my logs. Bill Hull's comment got me on the right path. I just wanted to clarify this is fixed in "Terminal Server Config" not "Terminal Service Manager".
If you get these errors on servers where printer mapping is not needed, open the Terminal Server Manager, and set the RDP connection to not do local printer mapping. I did this to avoid these errors on servers where local printer mapping was not needed.
As per Microsoft: "When a client logs on, the Windows 2000-based server checks the name of the printer driver on the client and looks for the same printer driver name in the Windows 2000 Ntprint.inf file. If the name of the driver is not found, the error messages are logged and the printer is not redirected.". Installing Service Pack 2 should solve the problem. See the link below for details.
From a newsgroup post (by an MS engineer):
"Here are some thoughts on print driver mapping that should help, I hope ...
The event regarding the 'corruption' error is misleading. There is a bug I found as a result of a previous post where we log ntprint.inf being corrupt when it's the user-defined (ntprintsubs.inf) may have the problem. Anyway, in your case I see a semicolon in the first entry of ntprintsubs.inf. Is this intended?
Also, with regard to usage of the user-defined INF, here are a few comments:
-The left-side of the '=' should be the print driver associated with the client-side print queue that is being redirected to the server.
-The right-side of the '=' should be the server-side driver equivalent that is installed on the TS server machine.
-Yes, the server-side driver indicated in the mapping absolutely needs to be pre-installed on the server for the mapping to work. A network queue on the TS server will cause the appropriate driver to be installed automatically, I believe. This is not the case with TS redirected printers. TS redirected printers require a pre-install of the driver using the Driver tab of the Print Server Properties dialog. You can get to it by right-clicking on the Printers folder from the control panel.
-The format of the [Previous Names] section in ntprint.inf is exactly the reverse of the user-defined INF. That is, in ntprint.inf, the client-side driver is on the right and the server-side driver is on the left. So, directly copying the ntprint.inf mappings into the user-defined INF is not advised.
So, here's how the following mapping from a user-defined INF would be translated in plain-english:
"Print Driver X" = "Print Driver Y"
"When redirecting a TS client-side printer with Print Driver X to the TS server, Print Driver Y should be used as the server-side driver."
Also, I hope this clears things up a bit ... the algorithm that we use for finding a server-side driver is:
If a user-defined INF has been defined in the registry then check for a match to the client-side driver. If one exists then use it. Else if a mapping is defined in the [Previous Names] section of ntprint.inf then use it.
Else try to install the server-side printer using the name of the client-side print driver as a direct map to a server-side driver."
|Private comment: Subscribers only. See example of private comment|
|Links: ME239088, ME294429|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated