windows 2003 sbs currently patched
clients are a mix of windows xp, vista, and windows 7.
Here is a simple login script I created. If I manually run the script it works just fine and they are no errors. If I set the loginscript under the users profile for the AD account. it does not appear to be running. Non of the printers get map, nor does the drive mappings occur. What am I doing wrong here. The issue happens on XP, I have yet to test on vista or windows 7 yet.
one more thing yes I am calling the script from \server.local\NETLOGON\tmg_login.vbs
Option Explicit
Dim WSHShell, wshNetwork
Set WSHShell = CreateObject("WScript.Shell")
Set wshNetwork = CreateObject("WScript.Network")
wshNetwork.AddWindowsPrinterConnection "\\server.local\TMG-HP3600"
wshNetwork.AddWindowsPrinterConnection "\\server.local\TMG-xerox2240"
'wscript.sleep 30
wshNetwork.MapNetworkDrive "S:","\\server\DATA", True
WScript.Quit
Try calling it without the full path. Just having "tmg_login.vbs" in Login Script should also work if the script is at the root of netlogon.
Are you saving this script in the NETLOGON share, and then calling it from via the full path? (eg.
\\myDomain.loc\NETLOGON\myLogonScript.vbs
)EDIT:
I'm wondering if it's a context issue. Sometimes the mappings will be made as the account running the script (System) and thus as a regular user you can't see the mappings.
Two things to try:
Add a
MsgBox
line to your script. If this message does appear when you log in, then it's a context issueTo confirm it's a context issue, after you log in, and you clear the messagebox, open a CMD window and type
Net Use
. You should not see any mappings. Then, typeNet Use S: \\server\DATA
. You should get an error message saying the drive is in useIf this is the case, let me know, and I'll tell you how to fix it.
If this isn't the case, the script isn't being called at all.
If it's only happening on Vista (and possibly Windows 7) you may need to lower or disable your UAC. This can interfere with logon script processing (UAC really should have been made Domain-aware, but oh well...)
Why not add the script to the users GPO? Setting the script on the user object and putting it in the netlogon folder is a legacy method for running scripts. I'm not saying it's causing your problem but try running it from the GPO and see if anything changes.