I think there is a typo in there where you are specifying the permutations, you say OUs when you mean groups. However I understand what you are saying.
The reasoning is management and safety. Management in terms of less confusion and having everyone that has power to understand the implications and much more obvious what is going on. Safety, well for safety and the partitioning mentioned. To set it up, we have centralized administration of userids in terms of there is a provisioning system, we do not place userids over a large OU structure, they previously went into a single location and now can be in one of 8 locations (plus a location for high level administrative IDs) per domain. We actually encountered an issue with group based management a couple of years ago when we had all user GPOs managed via group membership. During a fresh scripted import into production (we do not manually modify/link GPOs in production) some ACLs got reset and the reapplication of removing authenticed users didn't occur properly. All users on all machines locked down to full kiosk mode because they had all GPOs applied to them up to and including the kiosk GPO. The reason for the failure wasn't immediately apparent as it had worked fine in the lab and was a direct scripted process so we had to backout. That backout was to unlink all GPOs until we had the time to specifically go through and verify everything, it was more important for the tens of thousands of people around the world impacted to be able to do their work again. Luckily it was in our "lull" time so impact was relatively small. In the review we realized that doing things via group was both confusing and dangerous. We had delegated to local site admins the ability to add/remove people from their groups to apply various GPOs. It was never considered previously that someone could add authenticated users, domain admins, domain users, everyone, etc to the groups they managed. Additonally the mindset of the local admins wasn't taken into account. If you have an admin of a specific building, everyone to them is the people in that building, not the everyone that it truly is. Once we went looking for it we saw it on security groups all over and again, it was the mindset of the local admins, they wanted everyone in their building to have the access. Generally the farther you go down in a management chain for admins the less overall understanding they have of the design and the whys and hows. Realistically we would never be able to properly train (and get true understanding for) all of the admins that could possibly have the ability to harm us using groups. To continue to use group filtering would mean having both a complicated OU and group layout versus just a basic OU setup. The larger the organization, I think, the less flexibility you really want in your setup like this. The exception is when you have the money to have a lot of very knowledgeable admins working in a very decentralized "we like to manage one-offs" way. Otherwise you have to lock down hard on a few specific standards as any centralized knowledgeable group is not going to be able manage all of the different permutations of possible configurations. Additionally trying to troubleshoot many permutations can be trying. If you can look at the OU a machine or user is in and then know exactly based on that OU what they should have and not then also have to go look at what groups they are in and filter out or in the specific GPOs granted/denied by those groups life is much easier in general. Again, while you could most likely train top level admins and even medium level admins how to do this, the turnover you get and the number of low level admins in a large company as such that it would still be confusing and difficult to manage any other way. Plus when building up new labs or rebuilding due to disaster, the simpler the setup the easier it is to duplicate. Sure you can have tools that can do this stuff for you, but in the case where the tool for some reason doesn't work and you have to fall back to a manual setup, much easier if you followed KISS methodology the whole time. Anyone who likes to build one-offs in your organization should be generally looked at with suspicion. Doing so enhances their value to the company in a harmful way simply because they are the only ones who understand the one offs and the decisions behind it. Very often you can look at a one off and try to figure out what is going on based on accepted standards because, well, it is a one off. You have to look at it from the ground up. When following accepted standards and you are troubleshooting, you have a known good to start with and go from there. Does it sacrifice flexibility? Absolutely, however in general practice in ops it is more important to be easily supportable and less confusing than it is to be flexible. Flexibility is what people ask for before they run into problems and confusion with it. Once things are broken, they are complaining about how long it took to fix or rebuild and you can't blame it on them wanting flexibility unless they don't allow anything else. Don't get me wrong, I am not saying vendors should make their products inflexible. Absolutely not the case. Vendors should be very flexible because they don't know what standards the company will standardize on and should support any configuration the companies would like to go with. It is once the product is deployed in the medium to large company that flexibility should be restrained. Unless of course, the company is willing to pay for a lot of good/strong admin capability and keep it. For this specific case, and especially because it is a test, I think that a separate OU is the way to go. Both because of the reasons above and so that it is extremely obvious when people do a casual look that a test is going on. The DC being in a group could very easily be overlooked if the guy who did it is fired, quits, or gets hit by a bus. If you have some 80,000 groups in a domain, people aren't always going to go, hey why is this DC in this group called TestGPO. In fact, how many people know what groups their DCs (or any machines) are in? That DC sitting in a special subou will be obvious when people go to look at the domain controllers, irregardless of the tool they are using to browse. My final word I guess is that Group Policies are very powerful. Very powerful in that they can make any changes you want in a very easy quick way over a wide customer base. That is how they are advertised right? My general rule is anything that can make changes is dangerous and needs to be closely controlled. By that general rule, group policies are very dangerous and I wholeheartedly believe that. I am a cynical person when it comes to systems management though. It has saved my ass more than once. joe ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SysPro Support Sent: Sunday, April 04, 2004 5:32 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Testing other GPO's to DC's I am interested in the comment that OU's are a better way to manage Policies than using group based filtering. Is this for performance reasons, management reasons or safety reasons? I could see a very small improvement in performance, using OU's is a little easier to see what is going on and it is a little safer since if you make a mistake it only messes up the servers in that OU. In this case the main argument for using a separate OU would seem safety but I wonder if I have missed something? I personally would probably use group filtering, especially since it is only for testing. We tend to use OU's to delegate management of the workstations. We have a single domain managed centrally, but delegate day to day management to staff in the region. If you are in Eastern region, you go in the Eastern OU's and the Eastern staff manage you. I find managing policies by OU much more of a headache than using Group Filtering. If you have one policy, you only need two OU's. However, if you have 5 policies, you need (potentially) 32 groups to cover every permutation. 5 groups can be used to manage 5 policies and if you use a name to make clear it is only for Policy management, it is all pretty easy to follow. Alan Cuthbertson Policy Management Software:- http://www.sysprosoft.com/pol_summary.shtml ADM Template Editor:- http://www.sysprosoft.com/adm_summary.shtml ----- Original Message ----- From: "joe" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, April 04, 2004 3:50 AM Subject: RE: [ActiveDir] Testing other GPO's to DC's Yes, this would be my preference as well. Avoid group based filtering. ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Wednesday, March 31, 2004 10:12 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Testing other GPO's to DC's or create a sub-ou underneath the domain controllers OU which you link the GPO to. then put those DCs into the sub-OU. not only good for testing purposes... /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Mittwoch, 31. M�rz 2004 19:36 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Testing other GPO's to DC's Yes, that's exactly it. Grant those specific DCs the Read and Apply Group Policy rights on the GPO. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Devan Pala Sent: Wednesday, March 31, 2004 12:08 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Testing other GPO's to DC's Hi, I'm sure this has been covered in previous posts but how can I create a GPO object and link it to the Domain Controllers OU but only apply it to a couple of domain controllers for testing purposes? Is it removing the authenticated users group and adding the specific domain controllers to the ACL's? Thanks, _________________________________________________________________ Check out MSN PC Safety & Security to help ensure your PC is protected and safe. http://specials.msn.com/msn/security.asp List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
