RPC error with Logon Script

We have a simple three line vbscript that adds a default printer for a
user when they log in:

Set objWSHNet = CreateObject("WScript.Network")
objWSHNet.AddWindowsPrinterConnection "\\PRINTSERVER\A_Printer"
objWSHNet.SetDefaultPrinter "\\PRINTSERVER\A_Printer"

We have used this script successfully for years and years. Today,
though, we moved printing services on to a new server. The only
change we made to the script is changing the server name to the new
server. Now, when a user logs in for the first time, it attempts to
run that script and we get a "Remote Procedure Call Failed Error
#800706BE".

If the user, after getting to the desktop, runs this VERY SAME script
by hand...it works. Further, if that user logs out, and another user
logs in, the script will run at log in for that second user just
fine!! o_0

It's almost as if, the first time it attempts it, it can't find the
server, but then it can on the second and subsequent attempts, but I'm
unsure why that would be. Anyone have any thoughts?

Hello aaron,

Did you check "Always wait for the network at computer startup and logon"
for the clients in GPO. Maybe this helps. Seems tht the network is not complete
prepared before the script runs.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

> We have a simple three line vbscript that adds a default printer for a
> user when they log in:
>
> Set objWSHNet = CreateObject("WScript.Network")
> objWSHNet.AddWindowsPrinterConnection "\\PRINTSERVER\A_Printer"
> objWSHNet.SetDefaultPrinter "\\PRINTSERVER\A_Printer"
>
> We have used this script successfully for years and years. Today,
> though, we moved printing services on to a new server. The only
> change we made to the script is changing the server name to the new
> server. Now, when a user logs in for the first time, it attempts to
> run that script and we get a "Remote Procedure Call Failed Error
> #800706BE".
>
> If the user, after getting to the desktop, runs this VERY SAME script
> by hand...it works. Further, if that user logs out, and another user
> logs in, the script will run at log in for that second user just
> fine!! o_0
>
> It's almost as if, the first time it attempts it, it can't find the
> server, but then it can on the second and subsequent attempts, but I'm
> unsure why that would be. Anyone have any thoughts?
>

I don't think that's an issue here. We tried it anyway, though, but
it didn't make a difference. The really maddening part is that we
don't always get this error. Sometimes, you log in for the first time
and it works just fine!

On Mar 22, 10:30 am, Meinolf Weber <meiweb(nospam)@gmx.de> wrote:
> Hello aaron,
>
> Did you check "Always wait for the network at computer startup and logon"
> for the clients in GPO. Maybe this helps. Seems tht the network is not complete
> prepared before the script runs.
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and confers
> no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!!http://www.blakjak.demon.co.uk/mul_crss.htm
>
> > We have a simple three line vbscript that adds a default printer for a
> > user when they log in:
>
> > Set objWSHNet = CreateObject("WScript.Network")
> > objWSHNet.AddWindowsPrinterConnection "\\PRINTSERVER\A_Printer"
> > objWSHNet.SetDefaultPrinter "\\PRINTSERVER\A_Printer"
>
> > We have used this script successfully for years and years. Today,
> > though, we moved printing services on to a new server. The only
> > change we made to the script is changing the server name to the new
> > server. Now, when a user logs in for the first time, it attempts to
> > run that script and we get a "Remote Procedure Call Failed Error
> > #800706BE".
>
> > If the user, after getting to the desktop, runs this VERY SAME script
> > by hand...it works. Further, if that user logs out, and another user
> > logs in, the script will run at log in for that second user just
> > fine!! o_0
>
> > It's almost as if, the first time it attempts it, it can't find the
> > server, but then it can on the second and subsequent attempts, but I'm
> > unsure why that would be. Anyone have any thoughts?

On Mar 22, 10:30 am, Meinolf Weber <meiweb(nospam)@gmx.de> wrote:
> Hello aaron,
>
> Did you check "Always wait for the network at computer startup and logon"
> for the clients in GPO. Maybe this helps. Seems tht the network is not complete
> prepared before the script runs.
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and confers
> no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!!http://www.blakjak.demon.co.uk/mul_crss.htm
>
> > We have a simple three line vbscript that adds a default printer for a
> > user when they log in:
>
> > Set objWSHNet = CreateObject("WScript.Network")
> > objWSHNet.AddWindowsPrinterConnection "\\PRINTSERVER\A_Printer"
> > objWSHNet.SetDefaultPrinter "\\PRINTSERVER\A_Printer"
>
> > We have used this script successfully for years and years. Today,
> > though, we moved printing services on to a new server. The only
> > change we made to the script is changing the server name to the new
> > server. Now, when a user logs in for the first time, it attempts to
> > run that script and we get a "Remote Procedure Call Failed Error
> > #800706BE".
>
> > If the user, after getting to the desktop, runs this VERY SAME script
> > by hand...it works. Further, if that user logs out, and another user
> > logs in, the script will run at log in for that second user just
> > fine!! o_0
>
> > It's almost as if, the first time it attempts it, it can't find the
> > server, but then it can on the second and subsequent attempts, but I'm
> > unsure why that would be. Anyone have any thoughts?

The other odd thing is that if I take that script and change it BACK
to point to the old print server, it works flawlessly every single
time. The old server is Server 2000 where as the new server is Server
2003 R2. Could that be causing a difference?

On Mar 21, 11:37 am, Aaron <Aaron.Sm...@kzoo.edu> wrote:
> We have a simple three line vbscript that adds a default printer for a
> user when they log in:
>
> Set objWSHNet = CreateObject("WScript.Network")
> objWSHNet.AddWindowsPrinterConnection "\\PRINTSERVER\A_Printer"
> objWSHNet.SetDefaultPrinter "\\PRINTSERVER\A_Printer"
>
> We have used this script successfully for years and years. Today,
> though, we moved printing services on to a new server. The only
> change we made to the script is changing the server name to the new
> server. Now, when a user logs in for the first time, it attempts to
> run that script and we get a "Remote Procedure Call Failed Error
> #800706BE".
>
> If the user, after getting to the desktop, runs this VERY SAME script
> by hand...it works. Further, if that user logs out, and another user
> logs in, the script will run at log in for that second user just
> fine!! o_0
>
> It's almost as if, the first time it attempts it, it can't find the
> server, but then it can on the second and subsequent attempts, but I'm
> unsure why that would be. Anyone have any thoughts?

Don't know if this will help, but we did put one of the client
machines on a hub shared with a laptop running a packet sniffer. We
ran a packet capture while having someone log in. When they logged
in, they got the script error. After that, they ran the script
manually and it ran just fine. Looking at that packet capture, one
thing we noticed is traffic going to and from the client and the print
server with print requests etc so they two machines can talk to each
other. On the failed attempt, there is a ton more traffic, most of
which appears to be the client downloading (attempting?) the printer
driver. No printer drive related traffic is seen on the successful
attempt. We have had occasional reports of people adding printers on
some of our new print servers that have not automatically gotten the
printer driver from the server. Don't know if this is related to our
script error or not.