Introduction to Troubleshooting Logon Script Problems
Are you too intelligent for your own good? When you tackle a logon script problem do you change several
variables at once and carry lots of information in your head? Or are you organized, and change only one step at a time and write down what you do. What we need is a check
list, a progression of practical tasks. Where possible, each task or test should divide the search area in half.
What I like to do when troubleshooting is keep halving the search area until I see the problem. The way I narrow the search area is to
ask a series of questions, for example, is the error a syntax error or a logical error. A logical error would be trying to connect to a server or share that does not exist, whereas a syntax error
would be a missing bracket or ampersand.
Here are pairs of questions each of which narrow the search area. The problem is 'Why does my logon script not work?
Should we look at the VBscript or to Group Policy settings.
Is the problem Logical or Syntax.
Server or Client.
Is the error consistent or intermittent.
Another of my troubleshooting strategies is to go back to basics. Build your script in section. Get each scriplet working, then bolt all the parts together and so re-create the
final script. If you embrace this this strategy, then find a similar script on the web (this site) copy and paste the script, tune to your circumstances then get that section working before moving
to the next section.
Always remember that scripts mimic real life. Run through the actions mapping a drive, or creating a network printer, as you run through the task manually make a note of
the precise steps. Then go back to the script, can you find a missing item.
Can you run the script successfully on the very Windows 2003 server? Simply double click
the VBScript in isolation, away from a Group Policy. This test will determine if your facing a pure VBScript problem, or if the error is assigning the script via Active Directory Users and Computers.
In terms of strategy, break the script down into sections. Get each section working
in isolation, then paste all the sections together and so build the final script.
If absolutely nothing happens, check the file extension. You need to save as
with a .VBS extension. Is security so tight that VBScript files are forbidden from executing?
After you get the script working on the server, the next step it to run the script on the
client. Does it work on an Vista Client? Is the
fault only with XP machines?
Do you get an error message in a Windows Script Host box? When the VBScript fails, research each of the clues supplied in the message box. Read the Error: message. Check the Line number
in the message against the line number in your script. Count all blank lines and comments. For a short term fix, add this command to your script: On Error Resume Next.
Windows Management Instrumentation (WMI) is one of the hidden
treasures of Microsoft operating systems. Fortunately, Solarwinds
have created a
Free WMI Monitor so that you can discover these gems of performance
information, and thus improve your scripts. Take the guess work out of which WMI counters to use when scripting the
operating system, Active Directory or Exchange Server.
On Error Resume Next For a quick fix, try adding the command 'On Error Resume Next'.
This tells the script to ignore the error and continue. In my opinion this is seldom a permanent solution, however it will allow the script to get past the fault and possibly execute useful
commands. One possible use would be mapping zillions of network drives, if the script maps all the drives except one then you may have a satisfactory outcome.
Option Explicit This
command forces you declare all variables. Where Option Explicit helps with troubleshooting is where you misspell a variable later in the script. For example you start off calling it strUser,
then call it strUserS.
Err.Number Err.number is the first stage in introducing proper error correcting code. Combined with If ..then... End If, Err.number offers real
solutions to your problem. The only trouble is that you need experience both of the If ..then structures and the possible logical outcomes. Perhaps my ideas for err.number are best explained
by an example:
' Sub Routine Sub GuyCase()
' Select Case (Not Case Select!) errLogonScript = err.number Select Case errLogonScript Case vbEmpty strError = "No Problem " Case -2147024811 strError = "Drive already in use " Case -2147023665
strError = "Check server name " Case -2147023693 strError = "Check share name " Case -2147024829 strError = "Another share name problem " ' Finish with Case Else in order to catch exceptions Case
Else strError = "Research this number: " End Select WScript.Echo strError & err.number ' Wscript.Echo "Errors = " '& err.count err.clear err.number = vbEmpty End Sub
Thus utility makes it easy to check the health of your router or
firewall. Check the real-time performance, and availability statistics, for any device
on your network.
Get started with an extensive collection of "out-of-the-box" monitors for
popular network devices.
Symptoms
that point to a problem at the Active Directory end, the script
produces the desired result when you double click the .vbs file. However, when you assign the Windows logon script via an Active Directory Group Policy it does not execute at all, or does not execute
properly.
Wrong OU Trap
Make sure that the Group Policy is applied to the user who you are testing. The commonest error is that you apply the Group Policy to one OU, but the user who test the script in a different OU. Two variations of this
trap are, firstly, the computer account is not in the OU where you assign the policy. Secondly, you are applying a
script to the computer section of the Group Policy, not the user section of the policy.
Gpupdate (Or Secedit) It's always
worth a refreshing the Group Policy with Gpupdate /force or the older Secedit command. This is more likely to solve the problem when the script works on the server but not on the client. If
you have numerous domain controllers then you may get latency problems if the domain controller that holds the PDC emulator is a long way from the machine you are testing.
Try Remote Desktop I always like to logon at the very Windows server. If necessary, I connect via remote desktop, or terminal services. Then I double click the .vbs if it runs as expected, I progress to assigning the logon script to the
administrator.
Intermittent Problems - Add WScript.sleep You always hope that intermittent problems will just go away, but they never do. One fix is to add a delay at the start of
the script with WSCript.Sleep 20000. This command instructs the script to wait 20 seconds. My idea is to give the time for the client to initialise properly, and only then to attempt to map
the network drive, or what ever the VBScript instructions demand.
Assigning the logon script via Group Policy As
I mentioned earlier, always check that you are starting from the correct place in Active Directory Users and Computers. Only you know if you should be at the Domain level, or the OU level. Once you
have navigated to the appropriate part of Active Directory then created a Group Policy. If you are truly stuck then it is worth starting from scratch. Create a new user in a new OU, then
assign them a new Group Policy
To find the logon script settings start by clicking Edit, then navigate to the User Configuration, expand the Windows Settings folder, Scripts and Logon. Now for
my secret ingredient; my top tip is to copy your logon script into memory, so that it is ready to paste.
From the Logon Scripts window, click Add, in the Script Name dialog box, click Browse.
Now for the crucial part, right click and Paste. Your script should now appear in the window. My point is that by assigning the script using this technique the VBScript ends up in the correct
folder. If you examine that long path seen from the Look in: dialog box you should see your VBScript.
What this Paste method does is make sure that domain controllers can replicate the logon
script because it's in the correct folder. If you simply add a script using a local path, I doubt that your VBScript will be replicated to other domain controllers.
VBScripts in the Correct Path Observe the Polices folder structure on the domain controller.
The screen shot was taken from under the %windir%\sysvol\ folder. Strangely, there are two sysvol folders. Under the second sysvol you will see your domain name, and further down the actual
group policies. Each policy has sub menus with its templates and scripts.
Concentrate on the folders called Scripts. Do not worry about the {AC17C } hex names. Check that your VBScripts are in the respective Logon or Startup folders.
Earlier I said
observe because I do not want you to rename the group policies with Windows Explorer. If you change those strange hex names, the policies will not work and the new names will give you nothing but
grief.
Add another Group Policy Whilst in the overall strategy, I believe in keeping troubleshooting simple, in terms of tactics, I have one extra suggestion for you to try. Create
an ordinary Group Policy, for example, disable the
Run command. My thinking is that if client obeys disable the Run command part of the policy, but not the logon script part of the same Group Policy, then you have narrowed your search for the problem. If even the disable the Run command does not work, then you maybe logging on as a user in the wrong OU.
Guy Recommends: Solarwinds' Free Bulk Import Tool
Import users from a spreadsheet. Just provide a list of the
users with their fields in the
top row, and save as .csv file. Then launch this FREE utility and match
your fields with AD's
attributes, click and import the users. Optionally, you can
provide the name of the OU where the new accounts will be born.
There are also two bonus tools in the free download, and all 3 have been approved by Microsoft:
Assign the logon script the NT 4.0 way To short circuit
Active Directory Group Policy, assign the logon through the user's properties sheet, Profile tab. I don't like this old NT 4.0 method as the final solution, but it narrows down the problem when you are troubleshooting logon scripts.
Incidentally, Profiles tab method is the only way to get logons scripts to work for Windows 9x clients.
Be, methodical, be disciplined and try only one remedy at a time. Above all start simply, get the basic logon script working, then add complexity to get to the final production script.
The extra features you get in your eBook
include, more pages full of detailed examples. Also, ten 'how to...'
sections, with screen shots showing which menus to use. Go for Guy's
eBook - and get a printable version with copy enabled and no expiry date.
Windows Management Instrumentation (WMI) is one of the hidden
treasures of Microsoft operating systems.
Fortunately, Solarwinds
have created the
Free WMI Monitor so that you can actually see and understand these gems of
performance information. Take the guess work out of which
WMI counters to use for applications like Microsoft Active Directory,
SQL or Exchange Server.
When the VBScript fails, research each of the clues supplied in the message box. Read the Error: message. 
