Blog They give me a certain flexibility in writing the desktop management blog. The next six articles are marked in my calendar as “something to do with Group Policy Objects (GPOs).”

The topics I write tend to line up with the research I am doing for my day job, and lo and behold, the next couple of weeks I will be deep into GPOs. I’ve spent a few days deciding exactly how to split the topic up, trying to find a non-controversial way to approach it.

The idea of role and policy based management is at the heart of Windows. Windows server and desktop operating systems are designed for it; it is simply the way you do things in a Windows world. Where the topic has the potential for conflict is that it (generally) isn’t the way you do things in the Unix world. I'm choosing the first article to be about why group policy matters, but that has the potential to ruffle a few feathers.

Having managed systems using scripts as well as using policies, I find that there is elegance to the policy approach to management. Policy management systems are usually, (but not always,) integrated into a directory system. The basic idea behind these directory services is to provide a form of Single Sign On (SSO). This isn’t new. Unix operating systems have had them for ages, they range from simple services like NIS to OpenLDAP and Samaba.

The example I am most familiar with is Microsoft’s Active Directory (AD), but I have worked with several others. The bit that makes AD, or Novell’s eDirectory and Zenworks combo, unique is an excellent integration of policy management.

What makes role and policy based management so different from scripts? Being most familiar with AD, I will use the example of Windows clients attached to a Windows domain.

GPOs are all about giving systems administrators a centralized way to modify configurations on groups of systems simply, and all at once. The systems you are managing are “joined to the domain.” This is a process in which these systems are configured to use the AD as a SSO authentication point as well as a repository of system configuration changes which they periodically poll. If they detect a change, the change is analysed to determine at what point it should be applied - now, at logoff, at logon, at system start - and queued up.

Sticking to the script

So far, so much like managing a computer using scripts. The difference lies not so much in how these changes are applied by the systems, but in how easy the process is to manage.

When a computer is joined to a domain, a computer object is created in the directory. This object contains information such as levels of privilege and which policies are applied in what order. Similarly, a user object contains all information about the user context of individuals who authenticate against the domain’s directory. Both these objects can be placed into organizational units or different types of groups.

To illustrate, let’s look at an example of managing the time settings on my network. I have five locations in three timezones, and both domain controllers and edge time servers at each location. I place all computers in a given location into their own group, and configure them to synchronize their clocks against the domain controller local to that site. By default they also share the site local timezone settings.

The domain controller, any virtual servers and all non-Windows devices are configured to synchronize against the edge time server. The edge time server synchronizes against pool.ntp.org, and so the clocks on all devices on the network are kept in sync.

I have a roaming user who has asked me to do him a favour: he visits sites around the country, but keeps himself on the timezone of his native province. He asked if there was a way to make sure that any computer he was logged into would reflect the timezone he chooses.

Timing is everything

Thanks to GPOs, this is not a problem. I apply a timezone policy only to his user. Since the policy that results is based on hierarchical inheritance, this overrides the GPOs assigned to any computer he logs on to. When this user is logged onto the machine, the computer behaves as though it were in his native timezone. When he logs off there is no longer an overriding GPO changing the timezone, and so the system reverts to the timezone settings of the site where it is located.

Configuring this entire setup, from placing the systems into groups, creating OUs and then policies took me perhaps two minutes. As systems are now in groups for this purpose, future changes would probably take less than a minute. As I said earlier, GPOs can be narrowed to modify the configuration of a single user or computer. They can also affect the configuration of thousands with only a few clicks.

Policies are designed to be simple to create and administer. Not only does grouping and hierarchical inheritance make distributing these configurations easier, but virtually no knowledge of scripting languages or programming is required. In fact, very little knowledge of the target operating system is required.

For example; I know how to change the time settings on a Windows 7 computer from the command line. I couldn’t write a VB script to do it, and the powershell syntax is similarly unknown. I’ve been managing time settings on Windows 7 systems for about a year now via GPOs, and I have never needed to know any other method, let alone use one.

The entire idea of GPOs is to add a few layers of abstraction between the systems administrator and the fleets of systems he or she has to administer, to make manageability easier. As the head of an IT department, I find this an incredibly useful business tool. I can offload mundane configuration tasks onto the least skilled people in my staff because they don’t have to be fully versed in the systems they are configuring.

These junior systems administrators can be fresh out of school, green as grass and wet behind the ears. Most importantly, they are cheap. GPO management of a network is the entry level position in systems administration. Along with tasks like patch management, user object maintenance and end-user support it is a way of keeping these junior admins gainfully employed while they are shown the ropes of the more difficult parts of systems administration. It is also one way to vet the capable from those who will never rise beyond their entry level.

Don’t get me wrong; AD admins need to know what they are doing. To properly create a GPO for time settings you have to understand what clock synchronization is, how timezones affect the system. GPOs are about managing the fundamental concepts underlying IT without having to know how to manually configure or script on every different flavour of system on the network.

This is the controversy. Vocal evangelical IT purists believe that no administrator should be allowed near a network where they don’t know how to manually configure, script and recompile every single module of every application on every operating system. Similarly, no users would ever be allowed in the same room as a computer unless they could compile their entire OS from source. How they expect these individuals to gain this knowledge if they can’t touch a computer until they know it is beyond me. You might have some ideas.

For this type of administrator, services halfway between raw scripting and policy administration - like Puppet - have arisen. To use Puppet you still to know pretty much everything about the systems you are administering, and being deft with scripts is important. If you aren’t deft with scripts, then at the very least your script-seeking Google-fu must be strong. There just isn’t the level of abstraction or ease of use that you would find in a policy-based environment.

Puppet and similar services exist entirely to help automate the grunt work for admins who already know everything there is to know about their systems. I would go so far as to say that if you are one of those types of administrators, your time is so valuable that something like Puppet is mandatory. You may be the wizard who writes the scripts, but disseminating them to the systems in your care is properly beneath you.

The truth is: we are not all uber-administrators. We were not born in the fires of a semiconductor fab and trained to etch our commands directly upon hard disk platters with an atomic microscope built from needles, old tyres and sheer willpower. The rest of us are mortals; we start off knowing nothing, and with luck learn continuously until we die.

This, then, is why systems management abstraction services like group policy matter. ®