Introduction to Troubleshooting VBScript Errors
By best advice when troubleshooting VBScript is to go back to basics. Build your script in sections. Get each scriplet working, then bolt all the parts together and so re-create your script. If you embrace this strategy, then search for a similar script, on this site, copy and paste the script, fine tune the commands to your circumstances and get that section working. Repeat for the next section of your script.
Topics for Troubleshooting VBScript Errors
- Basic Principles of Troubleshooting VBScripts
- Simple Tests for VBScripts
- Three VBScript Troubleshooting Commands
- OU problem – No such object
- Troubleshooting VBScripts Summary
What I like to do when troubleshooting is keep halving the search area until the problem emerges. The way that I narrow the search area is to ask a series of questions, for example, is the error down to syntax or logic. 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 doesn’t my VBScript work?’
- Is the problem Logical or Syntax
- Should we look at the VBscript or to Active Directory
- Server or Client (especially Win 9x)
- Is the error consistent or intermittent
Always remember that scripts mimic real life. Therefore, walk through the actions manually and record all the steps. For example, open Active Directory Users and Computer and manually create the user or amend the property sheet. Now go back to the script and see if you can find the 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 you’re facing a pure VBScript problem, or if the error is assigning the script via Active Directory Users and Computers.
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?
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.
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: Xyz message.
Check the Line number in the message against the line number in your script. Count all blank lines and comments.
To determine the underlying cause the Code Number is the key, for example, Code 800A01B6 in the screen shot. Lookup YOUR error Code: 800 number here
Windows Management Instrumentation (WMI) is one of the hidden treasures of Microsoft’s 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. Give this WMI monitor a try – it’s free.
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 of this strategy is when you are mapping multiple network drives. On Error Resume Next would skip the fault and at least VBScript will map the other drives.
This command forces you declare all variables. Where Option Explicit helps your troubleshooting is where you misspell a variable later in the script. For example, you start off calling it strUser but then call it strUserS.
Err.number is the first stage in introducing proper error-correcting code. Combined with If ..then… End If, Err.number offers professional solutions to your problem. The only trouble is that you need experience of both the If ..then structures and the possible logical outcomes. Perhaps my ideas for err.number are best explained by an example:
‘ Sub Routine
‘ 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: "
WScript.Echo strError & err.number
‘ Wscript.Echo "Errors = " ‘& err.count
err.number = vbEmpty
I like thePermissions Analyzer because it enables me to see WHO has permissions to do WHAT at a glance. When you launch this tool it analyzes a users effective NTFS permissions for a specific file or folder, and takes into account network share access, then displays the results in a nifty desktop dashboard!
Think of all the frustration that this free SolarWinds utility saves when you are troubleshooting authorization problems for user’s access to a resource. Give this permissions monitor a try – it’s free!
When you try to connect to a specific folder in Active Directory, you get a specific message:
Error: There is no such object on the server
I am going to take a wild guess here, there is something wrong with the line in the script that references the OU, if it’s one of my scripts, the line referencing:
strContainer = "OU=Droitwich,".
Your problem could be as simple as a missing comma, or it could be that you don’t have an OU called Droitwich.
There can be two causes of this problem.
The reason for clarifying the difference between OU and CN (Container) is when you start building Active Directory scripts. It is easy to make a mistake and try to script CN=Accounts, or OU=Users, when it should be OU=Accounts and CN=Users.
A reminder that the variable strContainer is part of a longer string, for example
If you are scripting a child OU, then the correct syntax would be "OU=Child,OU=Droitwich," The way I remember the sequence is to imagine the user’s full DN (distinguished name), the syntax would be:
"CN=guyt,OU=Child,OU=Droitwich,DC=CP,DC=com". (Name), CHILD OU, PARENT OU, (Domain)
If you need a temporary work-around to the child / parent problem, create a test OU, with a test user off the root of your domain. My idea is to build on success, get this simpler example working then revisit the child / parent OU relationship.
I mention as this because so many people create ridiculously long paths that say to me: you are bound to make a mistake somewhere; this is by no means the longest example that I have seen:
"OU=Maybe a space,OU=sub-hyphen,OU=Child,OU=Droitwich,DC=CP,DC=com".
Be, methodical, be disciplined and try only one remedy at a time. Above all start simply, get the basic VBScript working and only then add complexity to get to the final production script.