Troubleshooting Logon Script Problems

Introduction to Troubleshooting Logon Script Problems

Guy recommends:
VBScript Training Video on CD

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.

Topics for Troubleshooting Logon Script Problems

• Basic Principles of Troubleshooting VBScripts
• Simple Tests for VBScripts
• Three VBScript Troubleshooting Commands
• Assign Scripts in Active Directory
• Wrong OU Trap
• Gpupdate (or Secedit)
• Try Remote Desktop
• Intermittent Problems add WScript.Sleep
• Assign the logon script via Group Policy
• VBScripts in the correct path?
• Assign the logon script the NT 4.0 way
• Troubleshooting Logon Scripts Summary

Basic Principles of Troubleshooting VBScripts

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 (especially Win 9x)
• 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.

Simple Tests for VBScripts

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 XP Client?  Is the fault only with Windows 9x 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.

To determine the underlying cause the Code Number is the key, for example Code 800708CA in the screen shot.  Lookup YOUR error Code: 800 number here

Three VBScript Troubleshooting Commands

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:

Assign Scripts in Active Directory

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.

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.

Troubleshooting Logon Scripts Summary

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.

See Also

● Logon Script Home

Home Copyright © 1999-2008 Computer Performance LTD All rights reserved

Please report a broken link, or an error.