Contents of Guy’s Scripting Ezine No 4 – Troubleshooting Logon Scripts.
This Week’s Secret
I will let you into a secret; at the start of their career, most people have trouble assigning logon scripts through group policies. In fact, it is my belief that you have not ‘earned your spurs’ until you have locked yourself out with a group policy.
When I was a newbie, I made the mistake of putting a pause statement in the machine section of a logon script. Naturally there was no-one available to press any key, so the machine hung. Fortunately, I was able to logon to another machine not in the scope of the pause script and correct the line of code.
This edition of my ezine is devoted to troubleshooting problems assigning logon on scripts. Even if your scripts are executing O.K, check out ideas for improving your logon script performance. For example, disable settings that you never use and so speed up logon. Alternatively, look out for tips on configuring group policy for settings other than logon scripts.
Guy Recommends: The Free IP Address Tracker (IPAT) 
Calculating IP Address ranges is a black art, which many network managers solve by creating custom Excel spreadsheets. IPAT cracks this problem of allocating IP addresses in networks in two ways:
For Mr Organized there is a nifty subnet calculator, you enter the network address and the subnet mask, then IPAT works out the usable addresses and their ranges.
For Mr Lazy IPAT discovers and then displays the IP addresses of existing computers. Download the Free IP Address Tracker
7 recommendations for troubleshooting and testing logon scripts.
0) Getting Started
1) Creating a test OU
2) Checking that your users are in the same OU as the group policy
3) Assigning computer settings with startup scripts (not logon policies)
4) Tools to refresh policies
5) Policy permissions.
6) Block Inheritance and No Override.
7) Speeding up logon
For Windows Server 2003 get the Group Policy Management Console (GPMC) from Microsoft’s site.
The scenario is that you have created logon script, when you double click the .vbs file it works just fine. Now you want to find the menus to assign your logon scripts through group policy.
Assigning logon scripts through Group Policies
a) Getting Started – Windows 2000.
Navigate to the Active Directory Users and Computers. right-click the OU (or Domain) object, Properties, Group Policy (Tab) now ‘click’ the Edit (button) and you will see the policy settings.
b) Getting Started – Windows Server 2003.
Assuming you have installed the GPMC from Microsoft’s site.
Navigate to the Active Directory Users and Computers. right-click the OU (or Domain) object, select open. Next, right-click the OU select Create and Link a GPO from here.
If you have not installed the GPMC ,then use method a) above.
Create a special user in a special OU. Now test your logon group policies in this OU. Why do I suggest this method? With group policies, people get carried away and create ever more severe group policies. It is easy to forget that if they use the default policy at the domain level, the settings apply to all authenticated users and that includes the administrator
2) Checking that your users are in the same OU as the group policy.
The situation is that you have a wonderful script; when you double click the .vbs file, it works fine. However, when you assign it to a group policy – nothing happens. The reason for the failure is you forgot to move the user into the OU where you are applying the policy. A variation on this is that you forget to move the Professional machine into the OU, so the computer scripts fails.
3) Assigning computer settings with startup scripts (not logon policies).
I have had several emails from people who cannot get printer scripts to apply to machines. The reason was, that they were assigning the computer scripts to a logon policy instead of to the startup section of group policy. Realizing that there are 4 types of script will avoid this problem. There are logon and logoff scripts which apply user settings and there are computer startup and shutdown scripts which apply HKEY local machine settings.
Gpupdate and secedit solve problems where you change the script in Active Directory, but still the settings are not being applied to the user or computer. Failure to refresh the group policy on the client can mean that it takes up two hours for the new setting to come into effect. Gpupdate is the refresh command for XP and Server 2003; while on Windows 2000 machines you need to execute the very awkward SECEDIT commands: secedit /refreshpolicy machine_policy /enforce. secedit /refreshpolicy user_policy /enforce.
If you just want the policy to apply to particular users, then remove authenticated users from the access control list and add the group you wish to receive the policy. In Server 2003 permissions are controlled through the Delegation tab, in Windows 2000, click on the Properties button.
Adjusting permissions is essential when applying restrictive group policies at the domain level, otherwise you risk locking down everyone including the administrator. This technique is also useful for fine tuning and troubleshooting policies in OUs.
6) Block Inheritance and No Override.
Block Inheritance is a feature I use mainly in troubleshooting. My strategy is to isolate group policies by preventing settings at the Domain or Site level applying to my test OU. This feature is designed to give OUs autonomy by breaking away from domain level settings. Technically Block Inheritance applies to the whole OU.
Another setting to check is No Override, or ‘Enforced’ as it is called in Server 2003. My point is if No Override is set higher up the tree, then group policies may not work at the OU level. This feature enables administrators at the domain level to make sure their settings will not be changed at the OU level. Technically No Override is set on a policy rather than the whole OU.
The default situation is that the client operating system checks every setting in every defined policy before the user can logon. This is why the ‘best practice’ is to have few policies with lots of settings, rather than numerous policies each with one setting.
You can use this knowledge to speed up logon by disabling unused portions of the policy. Admittedly this is crude as you can only disable the user settings or the machine settings. Nevertheless this could half the time it takes ‘Checking Group Policies’. Technically what you are doing is disabling the HKEY Local Machine or the HKEY User section of the policy. Where do you find this setting? In Server 2003 by clicking the Detail tab, GPO Status. In Windows 2000, click on the Options tab.
As with the rest of these tips, knowledge of the group policies are assigned will help you troubleshoot why they are not working as you intended.
See more about logon scripts
• Logon Arguments • Logon Map Network Drive • Logon Scripts • PowerShell Com Shell
• Ezine 3 Map Network Drive • Ezine 4 Logon • Tool Kit • Import Users From AD – Free CSVDE Tool
• Ezine 25 map • Ezine 30 Map Simple • Ezine 31 Mapnetworkdrive • Ezines • PowerShell Logon Scripts
