Create Printer on Local Printer Port of Remote Computer

[jkearns]

Currently, in our labs, our SysAdmins add a Local Port printer off of a print server, so all users of that machine get the same printer automatically. I am trying to write a script that I can run from my office that will do something similar to a remote PC. I'm running into some dead ends, and was hoping the group could point me in a direction that will actually work!

What is the best way to go about this? I can find lots of examples of scripts that add a printer to the current PC, but not to a remote PC. When I tried using WSHRemote to run a script on a remote PC, I could never get WSHRemote to run, but now just realized that I probably have to open up the firewall ports to allow WSH/WMI to work. If this way works, I have two questions: Anyone know what ports I have to open? If I add the printer and use the SetDefaultPrinter option, will that set it so *all* users of the machine will have the printer?

I've also just started using the MS-provided printer scripts like prnmgmt.vbs in C:\Windows\System32, but have had problems. It seems like whenever there is ANY kind of error, you get the message "Invalid Parameter".

I've also played with printui.dll, but didn't like the fact that if I set a global printer with /g, I have to use printui.dll to get rid of it. Also, for some reason, the default printer option, /y, never worked for me.

Hoping I can get some help from the experts here! Thanks!

[srochford]

"Best way to go about this?" - don't :-)

use the login script to map printers; that way when you want to map a printer you make one change to the login script and all relevant computers get changed. If you want to change the printer then, again, you just make 1 change - you update the server and next time the user logs on they get the new printer.

Adding a port to a local machine is fine if you have 2 or computers but it's real hard work if you've got more than a few machines!!

[enjay]

Can I ask why you're trying this? There might be another way to achieve the same end result...

[FN-GM]

if you go to the add printer wizard > next > select "local printer connected to this computer" & uncheck the tick box > Create new port - local port > now its asks you to type a port name use the full printer path eg \\server1\printer1 > Install drivers and customise your settings

[FN-GM]

that might not be what your looking for sorry

[jkearns]

Why this method? I thought adding it to the login script would slow down logins. And besides, Microsoft gives us an interface, WSHRemote, that runs a script on a remote computer, so why can't I take a script that adds a printer and sets it to the default, and run it from my office and push it to one or many remote computers? I can't, because even though MS presents it as easy, I've followed all the steps and checklists and it still doesn't work.

It looks like I'm in the minority, and will do it in a login script. It just frustrates me when I'm given an interface and I can't get it to work like it is supposed to.

[srochford]

It's ages since I've played with the WSHRemote (and I've never tried adding printer ports with it) but it can be made to work - I remember that the problems I had were with security (and this was before XPSP2 which tightened up security even more).

There's always more than one way to do things - some are good for a small network; others are better in a big network; some will work anywhere! In my opinion, adding ports in this way is only really suitable for small networks :-)

logon slowdown is an issue - as I've said many times on this web site, you need to measure things to find out what the truth is.

What I've found about mapping printers in a login script is that the first time a user on a particular computer connects to a remote printer, it can take some time to do (a few seconds). From then on, any other user connecting to the same printer is very quick - the drivers are already installed and very little actually happens so there's no real slowdown.

Obviously, you know your network a lot better than anyone here and, ultimately, it's up to you to find the best way to manage it - good luck with that!