When troubleshooting logon scripts we are often reminded that it is important to get back to the basics. We can literally spend hours, days or weeks troubleshooting what in retrospect can ultimately be discovered to be a relatively simple, straightforward problem. But then, retrospection is always accorded the benefits of hindsight. It is fairly easy to look at the components pieces of a completed puzzle to understand why those pieces ultimately fit where they do. But it can be very difficult to begin with the pieces of that same puzzle in a jumbled mess and have to fit them together in order to resolve a given problem.
Resolving any technical problem can be difficult if there are many component pieces involved but it can be a significantly more challenging task where scripting is involved due to the numerous variables that can be introduced and the inherent nature of scripting; some of the pieces of the puzzle may be missing. There might be multiple pieces that could fit if only certain other variables were in play. There may even be pieces to the puzzle that never get added to the completed puzzle even after it is resolved and deemed a satisfactory resolution.
The best method to find out what pieces form the complete picture when troubleshooting is to simply ask questions and then to see which pieces fit and which do not. Procedurally, there are three main points that I find helpful to employ when getting back to basic effective troubleshooting as it relates to Desktop Authority and logon scripting:
Firstly, it would be wise to ensure that you can manually create the settings that you are instructing the script to automate before attempting to automate them through the script. If one cannot create settings manually, then attempting to automate them through a logon script is an exercise in futility.
Secondly, ask for a recreation or a restatement of the problem as it currently exists in order to narrow the issues and variables. If the problem can be summarized in a sentence, then it is probably distilled and defined enough to be addressed properly.
Thirdly, employ the “5 Ws”; Who, What, When, Where, Why (and How). This line of questioning will typically result in eliciting at least the required parameters and will more often than not stimulate additional questions or considerations that will be useful in narrowing the issues considerably during a troubleshooting session:
Who is the target of the desired setting?
What is the desired result of the setting?
When is the setting being applied?
Where on the target does the setting manifest itself?
Why is the setting being set?
How is the setting being set?
More often than not, the source of the problem becomes evident when the most basic questions are answered. Just consider what happens if we change the answer on only the first parameter above. It should be readily apparent to all that if the target is a machine, as opposed to a user, that this one variable will drastically alter the other parameters involved, as well as the effectiveness or the viability of the proposed setting.
So, don’t be reluctant to ask those basic questions and ensure that the pieces of the puzzle all fit together logically as you proceed. You will probably find that your problems are often solved well before the supply of questions and answers have been exhausted. But even if you run out of questions, at minimum, the issue will then have been defined enough to indicate if the pieces fit the puzzle or if they just look similar to the ones that are the correct fit.