GPOs are not AD, AD is not GPOs.
GPOs are an application that utilize AD, say like Exchange. AD really doesn’t need GPOs but GPOs absolutely can’t without AD because that is where all of the information is. It is sort of like the relationship between AD and ESE… ESE doesn’t need AD but AD sure would be in a lot of trouble without ESE.
The GPO client has to look things up in AD and it finds out from AD what text files to pull out of sysvol to apply. That’s the connection, period, have a nice day.
This also means that just because you are an AD Expert it doesn’t mean you are a GPO expert and if you are a GPO expert it doesn’t mean you are an AD expert. Just like being an AD expert doesn’t make you an Exchange expert and being an Exchange expert doesn’t make you an AD expert. Some of us AD folks look at GPOs with disgust, I won’t mention Exchange other than “its special”. A big reason for this is because people treat GPOs (and Exchange for that matter) like a hammer and then solve all problems as if they are nails by using GPOs (or Exchange apps) to try and solve the problems. Me, I like a simple set of GPOs, 12 per domain setting basic security settings for a series of base platform configurations (from open developer to kiosk) for say a Fortune 5 company sounds about right for me with a sysvol at about 2MB tops. No I don’t like delivering Office and every other damn app under the sun with GPOs, I look for software delivery tools for delivering software – call me crazy.
Another big reason I don’t like GPOs is because they screw with people’s ability to logon. You get some rocket scientist looking to solve the world’s problems in a GPO and you get a user whose logon time is measured in cups of coffee and the help desk ticket comes in saying someone can’t log on and it isn’t that they can’t log on… it is because someone who should have been smacked made GPOs do far more than they likely should be doing.
Don’t get me wrong, GPOs can do some cool things and it appears to be getting even cooler with Longhorn, but it isn’t the right tool for all of the jobs people try to force it into.
I guess if there was a nice little popup that showed up on workstations AFTER a user authenticated and was truly logged in that said, “You are officially logged in fine, anything after this that screws up is not a logon problem but something else so complain to the appropriate people.”. If they had that, it would pop up within milliseconds of you entering your password in most cases. In large orgs, GPO support and logon script support is usually handled by the client group, logon support is handled by the Domain Admins and the Domain Admins don’t care what happens on your client after those first few milliseconds after you enter your password.
joe
Joe you are right and I’ve seen you post this on the activedir list too, but what I’ve seen is that it is usually the AD guys that end up designing, testing, & deploying the group policies so they also become the default group policy team at their organization.
Exchange seems to be a different animal; I’ve seen exchange guys that are also the AD guys but I’ve also seen them split out in their own group.
This is generally in smaller orgs. Once you get to org sizes where client support starts breaking out on its own they also tend to get GPO support. I mean why would you have two different groups supporting your clients like that, that is just asking for support issues and tossing the ball back and forth.
But if DAs are doing it all, then they get to be smart and limit how much they do. They don’t deploy Adobe and everything else through GPOs, if they do and it becomes a huge pain in the ass, then the DAs can blame themselves.
When another group does all of that and your sysvol starts getting measured in GB’s and you start doing D2 restores all of the time you need to say enough is enough.
We split out the software duties to our SMS team. That is one thing I’m glad we don’t do using group policy.
Been at a bunch of places where desktop support handles the GPOs but AD issues them w/ a delegation/custom acl.