Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was curious when a person should use Machine Groups within Active Directory? What are the common uses cases for them? How does one keep them up to date as machines are shuffled by a multi-tiered IT operation? Are there any implications for machine groups if a person does not have access to the user objects to move around in relation to applying policy, etc.

share|improve this question
up vote 3 down vote accepted

Machine groups are useful when certain local SYSTEM things happen and you want such events to affect off-machine resources, such as logging software installs pushed by GPO in a central location. If you have a machine group that's doing the installs, and you set that machine group to allow writes to the log directory, those software installs will be logged centrally.

The same holds for a startup-script. If you're doing data-gathering in that script and want to drop the files some place central, a machine group is handy for that.

The thing to remember is that users don't inherit any privs from the machine they log in to. AD considers them two separate entities. This can be both good and bad depending on what you're trying to do, but you do need to remember it.

share|improve this answer

Honestly, the only use I've found for Groups in AD for Computers, is to limit the scope of group policies applied to workstations. Microsofts best practices suggests that you should apply policies to OUs, and then place workstations into said OUs... but I find that frequently, this is less than ideal... Groups allows me to refine it a bit more so I can set roles on specific machines.

share|improve this answer

I occasionally use groups of machines, for apply Group Policies. With some more advanced policies, applying based on OU alone wouldn't work. I have policies, that should a set of servers that have about 40 policies applied to them. But a couple of those policies, is only applied to a subset, and in some cases, those subsets of machines overlap, so doing it purely on OU would result in an ugly OU structure like this (I have seen this in production on a clients network).

  • foo
  • foo\policya
  • foo\policyb
  • foo\policyc
  • foo\policya+policyb
  • foo\policyb+policyc
  • foo\policya+policyc
  • foo\policya+policyb+policyc

It is much cleaner, to just leave the polcies, at the top, and just have the polices apply only to specific groups, and the group member-ship include the machines, that the policy should apply to.

It really bugs me when I see people with insanely ugly OU structures because they are trying to make policies work. Microsoft called the technology Group Polices, and not OU polcies for a reason.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.