I'm a programmer stuck trying to administer an Active Directory setup for a small company. The Domain Controller is running Windows Small Business Server 2008.

We have a staff of field workers using tablet PC's; configuration problems with the tablet's ThinkVantage bloatware will require these users to have Administrator right when using the tablets. That's alright – it's useful for them to have broad privileges when I'm walking them through a fix over the phone, so I'm not looking for a work-around there.

I would like to use Group Policy to set up the following scenario: The users in a particular security group (or organization unit) should be in the BUILTIN/Administrators group when logged in to computers in a certain security group (or organization unit). It's okay if the computers have to be in an OU, but I'd prefer to assign users by group.

Of course, the field workers shouldn't be Administrators on other workstations, and vanilla office staff shouldn't be Admins on the tablets.

Currently, this is being managed locally on each tablet, but as we add new hires, it's becoming more of a hassle.

I feel like Restricted Groups is the answer here, but without a solid grounding in AD concepts and methods, I'm having a hard time making it happen.

What is the proper technique for this task, and how would I go about implementing it?

6 Answers 6


Create a group to encapsulate the users (Local-Admins-Tablets) and add them to this group

Create a sub-OU of the current workstations OU and put the tablets in here (Workstations\Tablets)

Create a GPO (Local-Admins-Tablets-Policy) and link it to the Workstations\Tablets OU

In the GPO, set the following:

  • Comp Config - Policies - Windows Settings - Security Settings - Restricted Groups
  • Right click, Add Group
  • "Administrators", OK
  • Members of this Group: myDomain\Local-Admins-Tablets

Reboot the PCs, and done.

Bear in mind that setting Restricted Groups will overwrite the machines existing list of local Administrators. If you have other users/groups in there already, you will need to add them to this policy too. Other examples would be myDomain\Domain Admins etc

EDIT: Oh, and change the filtering on the GPO and add Domain Computers. The easiest way to do this is to use the Group Policy Management MMC snapin (you can get this from the Remote Server Administration Tools from Microsoft)

  • 5
    +1. Restricted Groups is the solution here. A gpupdate /force on the workstations is enough for the change to take effect, negating the need for a reboot.
    – joeqwerty
    Oct 29, 2009 at 17:43
  • If the tablets are in the field it's usually easier to get the user to reboot than it is to explain the "open cmd, type gpupdate /force /boot" etc :)
    – Izzy
    Oct 29, 2009 at 17:45
  • 1
    Using Group Policy Preferences (technet.microsoft.com/en-us/library/cc731892%28WS.10%29.aspx) you can update a local group without overwriting anything.
    – Zoredache
    Oct 29, 2009 at 17:48
  • 1
    Well, that did the trick! Just two questions: I gather that it will completely blow out all current members of the Admin group, including local users, correct? That could turn out to be a nasty surprise. I assume that the default Administrator account will not be affected by this; is that presumptuous of me?
    – Ibby
    Oct 29, 2009 at 18:05
  • 1
    I've never tested that out, I've always just added Builtin\Administrators to that restricted group. Belt and braces :)
    – Izzy
    Oct 29, 2009 at 20:11

Izzy's answer is fine if you don't care that the Administrators group will effectively be locked out of future changes from the local machine. This will also wipe out any groups that were already members of the Administrators group before the policy setting was applied.

However, you can use the same policy setting in a slightly different way to bypass those annoyances (assuming you even consider them annoyances).

  • Create the OU/Group structure the same way as before
  • When you are in the Restricted Groups section of the group policy object, Add Group, but instead of specifying Administrators, specify YOURDOMAIN\Local-Admins-Tablets.
  • In the "This group is a member of" section, click Add and enter Administrators

It's a subtle but important difference in the way the two sections work. Members of this group effectively works out to be "Group A will only ever contain Groups X, Y, and Z". This group is a member of effectively works out to be "Make sure Group A is a member of Groups X, Y, and Z".

Once you've set policy with Members of this group, the only thing that can modify the group's membership is an overriding policy object that also uses Members of this group or any other policy using This group is a member of.


It seems like all you really need to do is create a group policy that adds a Domain Group to the local administrators group. This is pretty easily to accomplish with a simple startup script or with the Group Policy Preferences.

Simple startup script to add group members.

Set oShell = WScript.CreateObject("WScript.Shell")
Set oProcsEnv = oShell.Environment("Process")
ComputerName = oProcsEnv("COMPUTERNAME")
Set oGroup = GetObject("WinNT://" & ComputerName & "/" & "Administrators")
If Not oGroup.IsMember("WinNT://"&DomainName&"/_Group_Tablet_Admins") Then _
    oGroup.Add ("WinNT://"&DomainName&"/_Group_Tablet_Admins")
  • Assuming he's using W2K8, which I can't tell based on his question.
    – joeqwerty
    Oct 29, 2009 at 17:52
  • Client Side preferences are supported on a 2003r2 domain. I just didn't have a link a 2003r2 article handy.
    – Zoredache
    Oct 29, 2009 at 17:58
  • Edited the question to add the OS. GPP seems like a good fit for this scenario, since the users are unlikely to modify their groups afterward, making its temporary nature a moot point. That said, deploying the prerequisites to every client machine seems like a huge headache.
    – Ibby
    Oct 29, 2009 at 18:13
  • 1
    Thats why doing this with a simple startup script is also a simple option. I find preferences useful for many other things as well. It may be worth installing them for other things you will be able to accomplish in the future.
    – Zoredache
    Oct 29, 2009 at 18:28

The only problem with the solution listed is that it grants local admin rights to all machines where that policy applies. Typically you would want to grant admin rights to a specific machine only. What I've observed is when a user realises they have local admin rights they go installing software for all their mates.

There are a number of different ways you can do this but I might just suggest one. So complete the steps as above but also create a group for each computer where users need additional rights. Each of these "Computer Groups" is added to the myDomain\Local-Admins group.

Users are then added to the group that corresponds to the machine they need access to.

So they are an admin but only of that machine.


You say adding new hires is what's a hassle, but shouldn't it be adding new tablets that would be a hassle?

I'd be doing something along these lines:

Have a domain security group that contains all the users that should be administrators on the tablet PCs (i.e. TabletAdministrators).

On each tablet, add that group to the Administrators group.

Whether this is the proper technique or not, I don't know. It's just the first idea that comes to me on how to implement.

  • 2
    It should not be added manually to each machine. This is what Group Policy is for
    – Izzy
    Oct 29, 2009 at 17:36
  • 1
    When setting up a new tablet, I have to add add 15 users to one tablet. When adding a new employee, I have to add one user to 20 tablets. Both are a hassle, but the mechanics of walking from machine to machine make the latter process tedious and slow. Your approach would alleviate that substantially, though, even if it's not especially elegant.
    – Ibby
    Oct 29, 2009 at 17:46
  • 1
    +1 on this vote to bring it back up a little bit. This might not be the best solution but it is a valid solution. People shouldn't be down voted for proposing a valid solution just because it's not the preferred solution. The only thing missing from this solution is the use of Restricted Groups to automate the process of adding the group to the Local Admins group. I say +1 for effort and for contributing to the answer.
    – joeqwerty
    Oct 29, 2009 at 19:12

I wrote a script which runs as a computer policy with administrative rights on the local workstation. It checks the last logged on user's Description in AD which a Domain Admin can set from "Active directory Users and Computers", if it contains the workstation name, the script adds the user to local admin group, if the workstation name is not in the user's Description, it removes the user from the local admin group. A Description can include more than one computer name, like this:

The user's Description: "Local Admin on WKST-E445R and WKST-VM398"

So to make someone a local admin on just one machine, I just have to add this computer's name to the user's Description in AD and ask user to reboot, and removing the computer's name removes the local admin rights.

Isn't that the neatest solution ever? :-)

Here is the script:

    @if "%debug%" neq "%username%" echo off
set ver=MakeLocalAdmin.cmd henrik@c o m m o r e.se 20150423
:: Adds last logged on domain user to local Administrators group if run by computer GPO with Administrative rights and the user's Comment contains Computername

set log=nul
:: or set log=c:\logs\MakeLocalAdmins.txt

:: Check who was last logged on user
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI" /v LastLoggedOnUser') DO (
set DomainAndUserName=%%G)

:: Remove the spaces
set DomainAndUserName=%DomainAndUserName: =%

:: Get only username part
set LastLoggedOnUserName=%DomainAndUserName:*\=%

:: Check OS language, so we can adapt to localized name of Admin group and Comment
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\system\controlset001\control\nls\language" /v Installlanguage') DO (
set Language=%%G)

echo %date% %Time% ; %0 ; %computername%; %LastLoggedOnUserName%; %DomainAndUserName%, %Language% >> %log%
goto %Language%

:: Add any langauage specific part below, but if an unknown install language is found,
:: an error 'label not found' should mean script terminates, but anyway make sure it terminates. 
goto end

:: English
net user /domain %LastLoggedOnUserName% | find "Comment " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrators /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrators /del "%DomainAndUserName%" >> %log%
goto end

:: Swedish 
:: †„” åäö (Swedish char's)
net user /domain %LastLoggedOnUserName% | find "Kommentar " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrat”rer /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrat”rer /del "%DomainAndUserName%" >> %log%
goto end


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .