Printer Spool stops : The problem? Me!!

[contink]

You'd think after years of working with printers and deploying them on networks using login scripts and the like that I'd have learned a few things about what not to do, or rather what not to forget....

... apparently not.

Anyway, for the satisfaction of those who like to know others are indeed all too human and to avoid someone else making the mistake or just feeling a numpty in company here's one to watch out for.


Scenario:
- Printers were seeing more and more problems with documents failing to print, printers disappearing and various other rather bizarre and weird goings on.

Actions:
- Amongst other things I tracked down some of the issues to what I thought were VB6 runtimes and re-installed them all which seemed to cure some part of the issue
- Further to that, rewrote the login scripts for users and these seemed to successfully deploy the printers although there were some small errors they would appear in the relevant place fine unless the spooler had crashed earlier in the day, in which case rebooting was required.
- Issues with nvidia machines trying to add a run command to the users registry were resolved with a fix that sorted one issue with clashes but again still not quite there.

Clarity, Silliness and the Solution
- It's all well and good adding printers via a login script for users but unless you've actually deployed the printers as a startup, at some point the drivers will not have been installed properly.
- Quickly writes up a startup script to do just that and guess what... it works!

Ahah! Yes, yes... idiot alert... Good grief, what a goof ball!

[srochford]

I can understand that what you've done has worked but you definitely don't need to add the printers through a startup script - one of the major features of Windows is that a connection to a network printer is made on a user basis and the user doesn't need to have any special rights to install the printer.

I can't be sure if that's true for all printers (wouldn't surprise me if HP managed to break that rule!!) but any user ought to be able to browse to \\server\printer and just connect; a script which does "addwindowsprinterconnection" ought to do the same thing!

[contink]

I can understand that what you've done has worked but you definitely don't need to add the printers through a startup script - one of the major features of Windows is that a connection to a network printer is made on a user basis and the user doesn't need to have any special rights to install the printer.

I can't be sure if that's true for all printers (wouldn't surprise me if HP managed to break that rule!!) but any user ought to be able to browse to \\server\printer and just connect; a script which does "addwindowsprinterconnection" ought to do the same thing!

Hmm... I obviously need to brush up on my permissions but as you say HP tend to ignore protocol and fubar things their own way.

Hard to say at this point if the "fix" has indeed fixed things as there's been other things too but I'll feedback if/when I figure it out.

[m25man]

Have you checked this out:
The Print Spooler process (Spoolsv.exe) crashes while it is copying print driver files on a computer that is running Windows Server 2003 or Windows XP

[contink]

Interestingly enough a couple of days on it seems that my "fix" has worked.. Perhaps it was the HP drivers..

Either way, I'll keep my mind and ears open for repeat issues... Thanks for the suggestion m25man.. I wasn't aware of that bug.

[DMcCoy]

I can understand that what you've done has worked but you definitely don't need to add the printers through a startup script - one of the major features of Windows is that a connection to a network printer is made on a user basis and the user doesn't need to have any special rights to install the printer.

While true for adding printer objects, it isn't the case for the driver files itself which need copying to system32 folder which users have no write permission on.

[contink]

While true for adding printer objects, it isn't the case for the driver files itself which need copying to system32 folder which users have no write permission on.

That's what I thought... Thanks for restoring my faith in my addled memory.

Just out of interest would setting "install with elevated permissions" work to allow a user login script to complete the install successfully? I appreciate it's a risk thing but was just interested.