i have a vb script that maps 3 networked printers and also sets one as default
they are
hp 2300n
hp cp 1700
oki 9600
The 2300 is set as the default
If i log onto the workstation with the script assigned with the domain admin account I am able to print to the oki and 1700 and 2300. However if I log on as a standard user I am only able to print to the 2300. In the print queue for the oki and 1700 any job that is sent by the standard users appears as would be expected.
We only had the oki and 2300 previously and they were mapped at workstation level. All users were able to print them. I have checked the permissions set on the oki and 1700.
I also use the same script (edited) for other printers and they work without any issues.
Server = 2000 running as a DC
Clients = xp pro sp2
The printer are setup with IP addresses and are shared at server level
the printers are on the 2000 server and the script is connecting users by \\servername\printersharename
script =
the script i am using is
Set WshNetwork = CreateObject("WScript.Network")
WshNetwork.AddWindowsPrinterConnection "\\server\rdclaser"
WshNetwork.AddWindowsPrinterConnection "\\server\rdccolour"
WshNetwork.AddWindowsPrinterConnection "\\server\rdca3laser"
WshNetwork.SetDefaultPrinter "\\server\rdclaser"
i have checked the share permissions of the 2300 laser and the other two, all are set the same
I set the 1700 as a the default stil no luck
help!
Odd problem you seem to have there it sounds like a permissions problem but as you say you've already checked that... Just out of curiosity, try this(if you havent already) - Login into the workstation remove all the printers added by the script then manually add then in and see if you can print to them. Also try changing the default printer at this point and see if it has any effect (i doubt this would have a different result to be fair but worth a check). You can also temporarily assign local admins rights (on local machine) for the user and see if that has an effect.
how are you applying the script, as a logon script or a startup script because it sounds like you are assigning the script on the domain admin user configuration as a logon / logoff script.
the scripts are startup ones.
i have a few rooms with two or more printers, i have used the same script (modified printername) and they work fine.
It is rather strange as the they are able to print to the 2300 laser but not the other two that are in the same script.
apeo
i will try that at lunchtime and get back top you
thanks for taking time out to reply.

You need to assign the script as a login script - printers are a per user resource and so a startup script isn't ideal.
You may also find it helpful to scrub the drivers and re-install them. I found I had a similar problem with a OfficeJet K850dn which refused to work for regular users until I had scrubbed the drivers (with the HP uninstall tool) and re-loaded the latest and greatest one.
thanks Ric
did you remove the drivers from the server as well or just workstation level?
We use cse Network management software and it is there we allow the script to excute on start up.

i think it was both... started a fresh so to speak.
We use CSE too, and I would check that the script is applied to the correct groups in Workspace Admin. You can assign the printer script to run for any groups you add there. Have you spoken to Tony at CSE about this problem- I'm sure he would be willing to help out.Originally Posted by projector1
We moved recently to Server 2003 R2 print management, and it seems to be pretty good. Our scripts are now assigned using that tool through computer configuration/startup scripts. So there should be no problem there.
Paul
And we had this problem straight after instaling R2 print management Ric and fixed it by re-installing drivers on the server to the latest and then letting PMC push out the latest to clients. Seems to have worked. Admin users would be able to see the printer but normal users wouldn't- and like I said, updating the drivers fixed that "glitch" nicely. I hope.Originally Posted by Ric_
Paul
i logged onto all the workstations in the three rooms and used the microsoft printer driver
cleanup utility to clean the drivers. i then manually installed all three printers and then
added the unc port for the printer.
By this method all users are able to print to the three printers.
This proves that they have permission to print.
I checked the cse side of things for confirmation. The vbscript was assigned to the correct
workstations and to the staff and student group.
The printers are mapped when users log on so the script is being applied. I am also able to
print to one of the printers so, i am struggling to put my finger on it.
I also deleted the script and recreated a new one.

With the CSE stuff, are you able to apply a logon script to an OU? If you can, you could try that and see if it is the CSE manglement software screwing things up.
Good suggestion actually. What with CSE autostart scripts not aherm..."autostarting" all the time, that's what I did initially. It works fine. Worth a go though, because each setup is different so there might be some "manglement" at work.Originally Posted by Ric_
"Where there's trouble, there's a troll"
:-)
lol @ ahem
what is really annoying is that when users send a job to the 1700 or 9600 they appear in the print queue as
spooling
deleting printing
just as expected.
Therefore the script must be appllying in order for the jobs to reach the print server.
We have about 15 autostarting scripts that have never been an issue and the CSE network toolkit is a very reliable product.
All other scripts are fully functioning and i have edited a working script, added these printers, yet still no luck
I added a user to the print operators group and then was able to print, so could it be a permissions issue?
If so why would the job even register in the print queue?
Sinking fast!
There are currently 1 users browsing this thread. (0 members and 1 guests)