Skip the Group Policy administration -- here's a free and simple way to set a unique policy for multiple computers.
- By Jeffery Hicks
While browsing through a number of different support forums recently, I've
seen numerous requests for an automation solution to the same specific problem.
Never fear -- Mr. Roboto has heard the call and is on the case.
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.
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.
Jeffery Hicks is a Microsoft MVP in Windows PowerShell, Microsoft Certified Trainer and an IT veteran with over 20 years of experience, much of it spent as an IT consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He works today as an independent author, trainer and consultant. Jeff writes the popular Prof. PowerShell column for MPCMag.com and is a regular contributor to the Petri IT Knowledgebase and 4SysOps. If he isn't writing, then he's most likely recording training videos for companies like TrainSignal or hanging out in the forums at PowerShell.org.
Jeff's latest books are Learn PowerShell 3 in a Month of Lunches, Learn PowerShell Toolmaking in a Month of Lunches and PowerShell in Depth: An Administrators Guide.
You can keep up with Jeff at his blog http://jdhitsolutions.com/blog, on Twitter at twitter.com/jeffhicks and on Google Plus (http:/gplus.to/JeffHicks)