Absolutely on many of your points. This design was out of the client group as they "own" the entire GPO process since we only do GPO's for clients (well and domain controllers obviously). Everyone looked at it though and no one thought up the possible issues/consequences. It seemed linking at the domain level was the closest they could get because they didn't know for sure what Ous users would end up in. I have to admit to not caring a whole lot about GPOs and mostly consider them a pain in my back side with all of the other stuff we manage so didn't put the time and effort into understanding them and what they could do for/to us at the time. That attitude changed considerably after I started getting called and paged by people literally ALL over the world in a short time span.
Our new user GPO design that I was involved in breaks the users out into 7 levels, Level0000 to Level0600. Level0000 has no GPO linked, Level0100-Level0600 have various GPO's linked. No site admins have native rights to move anyone, they all have to go through our provisioning/management system and select the level they want for a user and that user has to be someone they are listed as having control for (usually by building number). This way a user can only be in one GPO and no one can put say a domain admin or everyone into one of the policy OUs. The only thing linked at the Domain level now is the Domain GPO which is nearly blank. It simply sets password policy type stuff. Change management is pretty big in our company. Obviously. We are a mainframe/unix/super computing facility. As you say, the mainframe people are very very big into change management like that. We follow it in pieces as a lot of the change management doesn't quite fit us as well as it fits say the Exchange Servers or the Web servers where any change (esepcially anything with a reboot) on a single machine can really impact people. We try to gauge the potential damage and go from that. The ranges of the change control are 1. No announcement, no followup 2. Annouce after the fact 3. Announce in advance 4. Announce in advance requesting specific feedback 5. Data Center change control 6. 4 and 5 combined. The first would be group memberships changes, additions/removals of servers/groups/sites/OUs/subnets/users/contacts normal day in day out stuff that many companies delegate out to admins. The second would be spinning up a new domain controller. After it is completed we send out notification to our domain changes list. Also demotion of DCs follows the same. Moving of FSMO roles if done in a hurry (say hardware failing). The third could also be spinning up of a new DC or removal of a DC depending on its location. For instance Data Center DCs we tend to give more heads up for for folks doing bad things like hard coding certain DCs into calls, etc. Hot fixes tend to fit in this category unless high level security issues and then they will be a #2 like for instance the RPC fix. The fourth has happened when we started discussing reducing our lockout policy from a 60 minute lockout to a 15 minute lockout. It can't really hurt anyone however some of our divisions are banks and we did want to test the waters on how they felt about it and more importantly how their auditors felt about it. We did expect some push back as most people don't understand the intent of lockout policies so they tend to fight things like that change. The fifth is anything that we want serious CYA for. Such as Service Pack updates. OS upgrades. Schema updates. Large replicating changes such as mass security descriptor changes high up in the tree. Discussions are going as to whether GPO updates should be listed there as well. This is a formal process that has a committee and folks publishing the changes like crazy. As a whole, it is worthless. I say that because the people involved except us have no understanding whatsoever of what we are talking about. This is a data center mainframe change control system and when we describe a domain as a cluster of 50,60, 100+ servers they just get confused. You need to change something in RACF, they are all over it and understand, you say you are upgrading this or that GPO or adding two attributes the schema they look at you waiting for a third eye to grow out of your forehead. The big benefit is that you can say you followed the process when everything hits the floor. The sixth is how we correct the fifth. We do the CYA, then announce it to our domain changes distribution list and see how many people perk up. We definitely do this for schema changes and OS upgrades. Most changes in the company through the data center change control mechanism are supposed to be made Sunday morning 4AM to 10AM... However we have several issues with that... What TZ should it be in? We are one of the few truly global environments in the company. 10AM our time and New Zealand is getting close to starting their Monday after they had a weekend of changes... And no one but no one wants to work Sunday afternoons on changes gone bad. Especially with Charmed coming on at 8PM EST on Sundays. Also most folks doing changes during that time frame don't like us doing changes at the same time as it can skew their results. Plus I hate making changes on a Sunday and walking in Monday to a ton of issues from everyone elses' changes wondering if we caused any of them. So we tend to do our changes on Wednesday Change Windows usually around 6-8PM EST. This gets out through the initial issues of the week, through Europe and America business days (mostly) and is not too bad for Asia Pac. If we can split the changes up we do Asia Pac Wed AM EST, Europe Wed afternoon EST, and America 8PM EST. ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Sunday, March 28, 2004 11:27 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Linking other GPO objects to Domain Controllers Ouch. Joe, I feel that pain. Talk about denial of service. I think this brings up a few good points about a few things near and dear to my heart. First off, I always council to link GPOs as close to the target audience as possible. In your example below where Everyone gets added to some sec. group, thus affecting EVERYONE, this is only a big problem if the GPO is linked at the domain level, which is generally not a good thing if its only intended for a subset of the domain population. I don't think its ever a good idea to use sec. group filtering as an alternative for proper linking. I would rather have a single GPO linked to 6 OUs than have that GPO linked to the domain and then have to manage sec. group filtering in complex ways. The second point this brings up is one that I think most folks miss out on--that of proper change management. In the Unix and mainframe worlds in which I have worked, people would never think to make a change to a production system without some change control process in place. And yet, in the AD world I know that it happens all the time. Something as innocent as a group membership change, as you point out, can have sweeping and unknown ramifications if not done according to some plan, with some prior testing. I always recommend to folks that when making changes to GPOs, or changes to a computer or user object that may affect GPO processing, to just run a RSoP Modeling report to make sure they know what to expect on the GPO side of things. Its easy and painless and can sure save a lot of grief down the line. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 28, 2004 5:58 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Linking other GPO objects to Domain Controllers LOL. I did, we got burned when the ACE for authenticated users didn't properly get removed by the script our client group sent over and everyone in the world on the 5 main account domains (only about 250,000 userids in those domains) got locked down to Kiosk mode (clients and servers) and able to do nothing on the machines. On top of that, if you do do filtering in that way, you need to maintain very strict control over who can modify the groups because if you are saying only people/computers in a certain group can get a policy (or even if certain groups are denied) and you allow that group's membership to be modified by someone who doesn't realize the full consequences (or maybe someone who does) of that they could say put someone like authenticated users in the group or Everyone or if they are really targeting someone with say a complete lockdown policy or something that runs code maybe the Domain Admins group. Our structure was going to be 6 groups for every site and each group was a filter for one of 6 user policies; users went into those groups on the basis of what the local site thought they wanted for them since all user objects were centrally managed and placed in another single container managed by the provisioning system - all 6 policies were applied to the root of the domain. This was combined with 6 OUs in each building code OU that workstations could be placed in. Obviously local site had the ability to move workstations between OUs, they also had the ability to modify membership of the GPO groups in their OUs. Once we had the "accident" with the ACLs we also realized the overall possibility of mistake in that method... I.E. Say an admin at a site things, well I have no PCs here I don't want used in a non-kiosk way so I am going to just set my OU's GPO model to Level0600 Kiosk Mode so I add all machines to the workkstation OU for that policy and I stick Everyone group into the Level0600 GPO group... Only everyone doesn't just mean everyone for that building, it means everyone in the domain so the entire domain locks down to kiosk mode. This can definitely be a useful method and people can go ahead and do this type of filtering but have to be very aware of the consequences. Group membership delegation is probably one of the more common ones however in this case, maybe that membership should only be changed by very few people or a provisioning system that has business rules with one of them being, you can't add certain groups like the admin groups or everyone, authenticated users, etc. Group policy is one of the more powerful features in an AD enabled world. I also consider it one of the more dangerous due to the far reaching scope of control and ability to change things and general confusion surrounding them and how they work. ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Sunday, March 28, 2004 12:45 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Linking other GPO objects to Domain Controllers Oh get over it Joe. Don't be such a weenie. Live life on the edge and use security group filtering on GPOs. Its good fun and good for you :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, March 27, 2004 6:47 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Linking other GPO objects to Domain Controllers Hey Michael, looks like you got an answer from Darren (though I dislike processing GPOs based on group memberships). However, would it be ok to ask WHY you would want to do this? Setting up DCs as one offs is usually a great way to court a troubleshooting problem that is a pain in the butt to resolve later. 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 Thommes, Michael M. Sent: Wednesday, March 24, 2004 2:33 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Linking other GPO objects to Domain Controllers Related question: Because of some testing we are doing in a production environment (yes, I know - ahem, ah try a test environment; can't in this situation), we would like to override the policy "Microsoft Network Server - digitally sign communications (always)" that is set in the Default Domain Controllers policy by using the local Domain Controller policy on a particular DC. But it appears not to be "overrideable". Is this the expected behavior? If so, how could we accomplish this? TIA! Mike Thommes -----Original Message----- From: Darren Mar-Elia [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 12:14 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Linking other GPO objects to Domain Controllers Agreed. Not much downside to this as long as you're not putting policies on these other GPOs that conflict with any set in the DDC policy. Even in that case, you just have to manage the conflicts. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rutherford, Robert Sent: Wednesday, March 24, 2004 9:14 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Linking other GPO objects to Domain Controllers It's common practice to add other GPO links to the DC OU. -----Original Message----- From: Devan Pala [mailto:[EMAIL PROTECTED] Sent: 24 March 2004 15:44 To: [EMAIL PROTECTED] Subject: [ActiveDir] Linking other GPO objects to Domain Controllers Hi all, Question: Has anyone experienced issues or know of any 'gotchas' with linking other GPO objects to the Domain Controllers OU in addition to the Default Domain Controllers Policy. Rationale: I would like to have a GPO ready that essentially has Windows Update enabled for deploying approved updates from a central SUS server. When an update is available, tested and if required, the GPO is linked to the Domain Controllers OU and available for install depending on each DC's detection cycle and configured parameters. Why not modify the Default Domain Controllers Policy? At least this way, I will have complete control of when updates are pushed and importantly, if I would like to retract the updates unlinking this 'other' GPO is easier and I believe safer than changing configuration settings on the Default Domain Controllers Policy. Another nice feature would be that the by unlinking this policy the update would also be removed from the Windows Update folder on each client (the DC). Your thoughts, suggestions and comments are as always, appreciated. Thanks, Devan. _________________________________________________________________ Find a broadband plan that fits. Great local deals on high-speed Internet access. https://broadband.msn.com/?pgmarket=en-us/go/onm00200360ave/direct/01/ 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/ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any use (including retransmission or copying) of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient of this transmission, please contact the sender and delete the material from any computer. The sender is not responsible for the completeness or accuracy of this communication as it has been transmitted over a public network. Any replies to this email may be monitored by the MCPS-PRS Alliance for quality control and other purposes. 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/ 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/
