after much testing and hundreds of tries and hours invested I decided to consult you experts here.


I want to apply some GPO to our users which will add some specific site to the Trusted Sites in Internet Explorer settings for all users. However, the more I try the more confusing the results become. The GPO is either applied to one group of users, or to another one. Finally, I came to the conclusion that this weird behavior is cause rather by the poor organization in Users and Groups in Active Directory. As such I want to kick the problem from the root: Redesign the Active Directory Users and Groups.


There is one Domain Controller, and we use Terminal Services (so there is a Terminal Server as well). Users usually log on to the Terminal Server using Remote Desktop to perform their daily tasks. I would classify the users in the following way:

  • IT: Admins, Software Development
  • Business: Administration, Management

The current structure of the Active Directory Users and Groups is a result of the previous IT management. The company has used Small Business Server which has created multiple default user groups and containers.

Unfortunately, the guys working before me have do no documentation at all. Now, as I inherit this structure I am in the no mans land. No idea which direction to head first.

enter image description here

As you can see, the Active Directory User and Groups have become a bit confusing. There is no SBS anymore, but when migrating from SBS to the current Windows Server 2008 R2 environment the guys before me have simply copied the same structure.

The real question:

Where should I start cleaning from, ensuring that I won't break totally the current infrastructure? What is a nice organization for the scenario that I have explained above?

Possible useful info about the current structure:

  1. Computers folder contains Terminal Services Computers user group

    • Members: TerminalServer computer located at Server -> Terminalserver OU
    • Member of: NONE
  2. Foreign Security Principals : EMPTY

  3. Managed Service Accounts : EMPTY

  4. Microsoft Exchange Security Groups : not sure if needed, our emails are administered by external service provider

  5. Distribution Groups : not sure if needed

  6. Security Groups : there are couple of groups which are needed

  7. SBS users : contains all the users

  8. Terminalserver : contains only the TerminalServer machine

  • 1
    Where should I start cleaning from, ensuring that I won't break totally the current infrastructure? What is a nice organization for the scenario that I have explained above? - is really only going to lead to opinion-based answers. Tim Brighton's answer is right and basically says the same thing...that it's largely up to the admin in charge. If you are looking for ideas/opinions on this, it may be better to setup a chat room and discuss there.
    – TheCleaner
    Aug 18 '14 at 13:21
  • yeah you are right, but I was rather wondering if there is a "rule of thumb" or "best practices" when doing this stuff. I'd like to hear from people who have had similar experience and see what they've done Aug 18 '14 at 14:12
  • 1
    Following Tim's advice below is a good start. After you've moved the objects from all of the SBS OU's under My Business you can simply delete that OU and its sub-OUs. At that point you'll have a very basic OU structure to build from. You can check out: technet.microsoft.com/en-us/library/bb727085.aspx#EFAA section for tips on OU design.
    – TheCleaner
    Aug 18 '14 at 14:15
  • 1
    Yes it is...and you can delete it IF you've properly removed Exchange or if it's already gone, make sure you do the metadata cleanup for an Exchange server in adsiedit before removing the OU. I don't think it'll hurt anything to simply delete the OU if you aren't using Exchange, but you may get eventvwr errors in the app log, and you might have strange issues if you ever do decide to use Exchange again in the future.
    – TheCleaner
    Aug 18 '14 at 15:29
  • 1
    If your 3rd party provider is hosted Exchange of some flavor, and you're using some sort of federation, ask the vendor before removing it in addition to your own internal diligence.
    – mfinni
    Aug 18 '14 at 15:51

I've dealt with similar problems in the past.

That being said your organization doesn't look too far from ordinary. A lot of small business are built just like you outline.

If you really want to restructure the best solution I have found is setting up an OU with block group policy inheritance at the root of your domain. Build your new structure under this OU and apply your group policies there as well. You can then move your computer and user objects in a controlled fashion.

As far as design - use whatever works. Don't try to emulate the physical arrangement of the business too closely. Group your systems to make them easy to administer.

Edits for clarification:

'Block Inheritance' is an option that allows you to set up an OU that won't accept any policies which are defined above it. This allows for a totally blank slate. Any objects which are later moved here will have none of the existing policies applied, even if they otherwise would be. Any objects left in their original homes will still have their current policies applied.

Although a bit dated the logical modeling here provides some excellent guidance on overall AD structure.

One additional point, which is extremely important - document everything you are doing. Include why it is done this way as well as how it is configured. The exact method you chose for this doesn't matter, but I personally really prefer one of the various Wikis out there. Building detailed history for your environment is a godsend.

Additional edit in response to Joe Qwerty

I don't necessary advocate a restructure. Doing so can be time intensive and serious pain in the ***. I am just advising how to do so if that is the route the OP chooses. Personally that'd be a last resort. I've contracted places that everyone was a domain admin and the accounts / group policies were total mess and a restructure is the most viable option.

Given the choice I would opt to work within the existing AD structure. If the naming conventions, etc bother you they can always be changed. The OUs, group names, etc all have GUIDs that won't be broken by a rename. The SBS entries were likely not copied from the old SBS server. SBS includes Active Directory. A common migration path as organizations expand is is adding a 2008 R2 / 2012 server, promoting it to domain controller, moving the FSMO roles and then demoting the original SBS server. If the old admin had spent a lot of time in the original SBS AD console I could see why you wouldn't want to change the naming convention.

  • 1
    +1 for document everything, much important than it seems Aug 18 '14 at 15:59

I'm going to differ with Tim's answer and say that you ought to look at solving your problem by figuring out why your intended GPO settings aren't working, not by "restructuring" your current setup. Restructuring your current setup isn't going to solve your problem if you're configuring the wrong GPO to begin with. With the exception of a few additional OU's, the "structure" looks typical for SBS. Just because you don't have SBS anymore doesn't mean you need to throw out the baby with the bath water. Asking whether or not you can delete the Microsoft Exchange Security Groups OU leads me to believe that you lack the appropriate knowledge and experience to take on a redesign.

I suspect your real problem is that you're trying to configure some settings for your users when they log onto the Terminal Server but that you're configuring the settings in the GPO linked to the users OU instead of configuring the settings in the GPO linked to the Terminal Server OU and using Loopback Policy Processing, which would be the way to do that if that's your scenario.

So, are you trying to configure settings for the users for when they log onto the Terminal Server? If so, in which GPO are you configuring those settings?

  • you are correct with your assumption about my previous experience. As far as the GPO stuff is concerned, I found the problem. The GPO is actually linked to the proper OU, as you note, the one that has the terminal server. The problem with the GPO processing was rather specific. It is a GPO for internet explorer. and IE does not read the GPO properly, although RSOP gives the wanted result. The IE only reads the GPO after resetting IE settings to default which requires me to do this: serverfault.com/questions/622165/… Aug 18 '14 at 15:53
  • I would like to read something extra about loopback policy processing if you have any suggestions Aug 18 '14 at 15:56
  • 1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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