Beware running a script which creates 'Objects' for a second time.
It that's your problem you are
likely to get a WSH message: Code 80071329
- Object Already Exists
Firstly, and most importantly, believe that you can solve this
problem! Guy says, 'You will beat this VBScript problem'. So take 5
seconds to get into 'state'. Visualise another script problem you solved,
remember the elation you felt when beat it.
A well defined problem really is half the solution. Something magical
happens when you write down precisely what is wrong. Just collecting the
symptoms triggers your brain to start searching for causes. As a bonus, if
you write down the problem it will prepare you for other strategies.
3) Ask: 'what has changed recently?'
What have you just added? Which line did you copy and paste? If so
reverse engines, revert to how it was and see if that cures the problem.
Pattern recognition is a vital troubleshooting skill. Look for patterns,
spot what is out of the ordinary, such as file name that is different, or a
spelling misNake in a variable.
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.
Guy
Recommends: Permissions Analyzer - Free Active Directory Tool
I like the
Permissions Monitor because it enables me to see quickly WHO has permissions
to do WHAT. When you launch this tool it analyzes a users effective NTFS
permissions for a specific file or folder, takes into account network share
access, then displays the results in a nifty desktop dashboard!
Think of all the frustration that this free utility saves when you are
troubleshooting authorization problems for users access to a resource.
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.
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.
Option Explicit
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
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 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
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.
