>>>My clients Hardware people loaded a service pack to their Windows 95 machines to make them "y2k" compliant. Since then they have been getting error 1958 sporadically when printing. Anybody have experience with this issue, or know why a service pack would start this behavior? TIA.
>>>
>>
>>I've seen it; one way to cause it to happen consitently is for the driver for the referenced printer to reside on another system, and that system to not be available at the moment. It's not the only time I've seen it. What's worse, it may not be the system that got the SP applied to it that sees the error; it might be something that got fried in File and Printer Sharing on the machine that owns the copy of the driver. IOW, either the host (server) or the client PC might be at fault here.
>>
>>Windows may reference the current driver installed on another system with a printer that was shared through the MS Networking Client; if several similar printers are defined on the network, your own system relies on a networked copy of the driver and the system that has the printer driver is cooked (it might not be the system sharing the printer you've switched to, just the first place that the affected system found that referenced that driver), this error appears consistently. It seems to happen a lot less if each machine has the drivers defined locally rather than inherited from the machine sharing the printers. It also seems to happen a whole lot more with peer-to-peer environments.
>>
>>Reinstalling the printer drivers locally seems to help.
>
>Thanks for taking so much time to answer my question. Are you saying that when I install a printer over a network share and it asks me if I want to "keep" the driver, it is actually using the driver on machine sharing the printer? As a rule of thumb should I say no, and choose to install the driver thereby loading the driver into the local machine?
>
No, if it asks about 'keeping' the driver, it means that there's already an instance of the driver on the system, shared or otherwise, and it gives you the option of installing an updated/different driver.
The clue that you're using a driver from another system is that you don't have to go through the exercise of specifying the printer type from a list - if the MS Networking system has a driver for your operating system on it associated with the shared printer, it will tell that the printer model is already known (you didn't have to tell it what type of printer it is) and it
may give you the option of using the remote driver for that printer. If you didn't have to identify the printer type, and weren't asked to put in a driver disk on the local station or point to them place to find the driver without explicitly selecting a printer type, the source for the driver is the driver installed on the other system for your operating system.
It appears to be a problem with peer-to-peer environments primarily; for example, Win98 workstations Marty and Bobby each have an Epson Stylus 600 inkjet on them, shared to the network through File & Printer Sharing for MS Networking. If another Win98 box on the network adds one of their printers (let's assume it's \\MARTY\EpsonInk), it'll inherit the drivers from the \\MARTY system. So far, so good - the shared printer is only on-line when the system \\MARTY is up and running.
The place where things crap out on me at least, is where the station subsequently adds \\BOBBY\InkJet as a windows printer on their system. The printer drivers are identical, and the user is given the choice ofd taking the drivers from \\BOBBY, or using the ones it already has from \\MARTY. Let's assume that it keeps the one from \\MARTY.
The error 1958 seems to pop up later when the printer output is sent to \\BOBBY\InkJet, but \\MARTY isn't up and running. If the printer driver had been loaded from the Epson Stylus CD locally on the system, we don't seem to get the error 1958, and if both \\MARTY and \\BOBBY are both up and happy, we don't seem to get the 1958. The problem is that at times, the 1958 doesn't appear even when \\MARTY is down, so I've worked on the assumption that the driver had already been pulled across at some point and loaded, so the current status of \\MARTY didn't enter the picture.
I haven't proven out this scenario in detail. We've avoided this in large part by sharing printers through the NetWare client (this is advantageous for us because it makes printer pooling easier, where you want to send a print job to a particular type of printer, and don't care which of several actually gets the output. NetWare print queues, at least with NetWare through 3.20, which we run in-house, doesn't pass along printer type details, forcing you to instlal the drivers locally on each system.)
>Thanks again,
>Marcus.
