Group Policies in Windows Server 2003

Do you use Group Policies?

 

Is your server running slowly?  Check with SolarWinds ipMonitor

Get a free evaluation copy of ipMonitor

 

Best Practice (Litmus Test)

Professionals: Use Group Policies to configure the desktop

Amateurs: Use mandatory profiles to control the users

Group Policy

In Windows Server 2003, Group Policies are second in importance only to Active Directory.  Group Policies are also fun to configure.  The key thinking behind Group Policies is 'prevention is better than cure'.  Restrict users settings and so prevent them from causing problems.  Group Policies are like putting blinkers on the users.  Policies make users concentrate on their job tasks, while stopping them from playing with all the extra Windows settings that there is no business case for using.  As a result of a good group policy the users are more productive and you get less support calls to the help desk.

Professionals master Group Policies.  Amateurs either ignore them or get into a mess because the do not appreciate the intricacies of setting a good policy.

With Group Policies not only can you be Mr Nasty (screwing down the desktop), but you can also be Mr Nice.  Mr Nice provides just the programs users need, but no extras.  So when an accountant logs on they get office XP and accountant software.  When ordinary users log on they get only the office suite.  What is more if the program break then the intellimirror software automatically restores the original settings.

Having established the need, the next problem with setting up System Policy is time to experiment.  You need a week experimenting with a group of test machines before you think of rolling out to the production network.

Policies can be applied at the Domain, OU and Site level.  My advice is to set your security at the domain level, but control the desktop at the OUs.  Avoid setting policies at the Site level, it is not necessary and only adds an extra layer of complexity.

Tips to make you a Group Policy expert

• When you experiment with Group Policies, create and use a special test account
• Create a special OU (Organisation Unit) for testing Group Policies
• Take the time to investigate all the Group Policy settings
• Consider mastering the Group Policy templates to apply your settings at the Domain level
• Use 'No Override' and 'Block Inheritance' to isolate a problem
• Create a 'VISION' of the desktop your users should have

Group Policies v Logon Script Strategy

In my opinion logon scripts are gradually being replaced by system policies.  For example, mapping home drives via a logon script, can now be replaced by policy which redirects the 'My Documents' to a server.  However, it is often a case that there is more than one way to achieve the desktop that you want. If a logon script gets it done then fine, but if not then do consider a policy. Group policies are here to stay, Windows 2000 has about 400 and XP has an extra 200 policies.  Now in Server 2003, there are yet more policies and the splendid GPMC to manage the settings.

Many large companies write their own policies, once you remember that policies control either the USER or HKLM part of the registry then you can see that virtually any registry setting can be written into a policy.

Troubleshooting Group Policies is tricky

As an MCT trainer, I can thoroughly recommend TrainSignal because they provide practical hands on training.  In particular, I like the way TrainSignal cover all learning methods, instructor lead, video and of course text material.  You can either take one module, for example Group Policy or go for a combination of modules.  See more about Group Policy training here

Click here for new features of Group Polices in Windows Server 2003

Try another Litmus Test

Sign up to my new Ezine and get a free Best Practice ebook.

 *