Mr. Roboto

Members Only

Skip the Group Policy administration -- here's a free and simple way to set a unique policy for multiple computers.

• By Jeffery Hicks
• 02/01/2007

Here's the situation: You have a certain user who needs to become a member of the local Administrator group on a specific computer. As the administrator, you need to maintain unique granular control of the local group membership. Usually, a Group Policy object configuring restricted groups is the best way to handle this type of issue. But how can you set a unique policy for multiple computers without a great deal of Group Policy administration? What solution is the easiest to implement and manage?

The solution I developed uses a VBS script designed to run as a startup script, along with a little Active Directory configuration. I'm well aware that there are many other ways to solve this problem, especially with third-party tools. But I wanted to present you with a solution that's flexible, simple and -- most importantly -- free. It's certainly not a one-size-fits-all solution, but it can help you out in particular situations.

Upgrade to Admin
Here's how this works: For every computer you're managing, add the name of the user who you're going to make a local administrator to the description property of the computer accounts in AD. The format should be domain \ username. You can also specify a group, as long as you keep to the same format. This is required for the script, but it also lets you specify users or groups from trusted domains. If you want to specify multiple users or groups, separate each one with a comma. For example, to make jhicks and the Techs group local administrators of XPDESK01 in the MYCO domain, find the computer object. In the description field enter myco\jhicks,myco\Techs.

Get the Update Local Admin script (see "Roboto on Demand"). Create a Group Policy object that runs this as a startup script. Link the Group Policy object to the highest container so you can have it applied to all the modified computers. You could safely link it to the domain level if all your computer objects have either a blank description or one defined with user and group names. If you leave the description field blank, the script will quickly run but won't do anything. Otherwise, it will parse out each name or group in the description field and try to add it to the local administrator's group.

The script will log an event in the local computer's application log in the event of an error or when a user is added. If the user already exists, the script keeps going. The only ongoing management is modifying the description field when you add a new computer to the domain.

This script is flexible enough for you to modify it to configure membership lists of the local Power Users group or any other local group. However, the script isn't a panacea. As it's written, it only adds users to the Administrators group. It cannot remove users (although I might add that feature at some point). I'm also assuming you have the Description property available. If you're using Description for other purposes, you could rewrite the script to use another computer object property. However, you'd have to develop a tool or script to expose that property, as Description is the only property in AD Users and Computers that's available by default.

As with any automation solution, especially one involving Group Policy, I strongly urge you to test it thoroughly in a non-production environment. It's better to be safe than sorry when it comes to these types of changes.