Today I crossed a milestone. 200th call relating to Group Policy. And the same things pop up so many times that I wonder if maybe Microsoft should commission a team of scientists to form a panel to discuss the creation of a study to identify the members of a panel to study the…. wait a minute. That’s how Group Policy itself kind of works. Or, more accurately, how it’s configured, in many places.
Here’s my revised “top 10” issues:
- Too many settings added to Default Domain Policy
- Too many GPO’s linked at the domain root
- Too many unrelated settings in one GPO
- Unnecessary use of WMI filters in GPO’s
- Unnecessary use of login scripts
- Insufficient planning for resource accessibility (*)
- Too many people in charge of GPO’s
Most of these should be self-explanatory, so I will only delve into the ones I feel need a more harsh beating…
Issue 1 – Keep the Default Domain group policy as MINIMAL AS HUMANLY POSSIBLY. In fact, I would recommend a company policy that says the following:
"Changes to the Default Domain group policy will require the submission of appropriate request form(s), followed by a thorough review and approval process. The review process shall consist of the requester standing naked before the board, wearing nothing more than a funny-looking hat, duct tape covered mouth, and mountain-climbing boots, with hands clasped behind the back in military formation style. Upon approval of the requested changes, the requester will be required to retrieve the approval form without the use of hands, feet or mouth, and without the assistance of any external mechanical devices. The requestor must also exit the review session walking on their hands."
That should minimize stupid changes being made to that precious little GPO.
Issue 3 – Think of a GPO like a meal. The settings are the ingredients. If you want to cook a nice breakfast of eggs, bacon and toast, you DON’T dump oysters, coffee grounds and pureed grapes on it. Keep only the ingredients necessary to make the meal. Then, when the meal comes out tasting like horse shit, you can narrow down the root cause more easily.
Issue 4 – WMI Filters. smh. OMG. Yes, they’re useful. Yes, they’re cool. Fire is cool too, just not under your bed. Never confuse “could” and “should”. In most cases, a proper OU design will eliminate the need for them. Like I said “MOST CASES”, not “ALL” cases. If you absolutely cannot accomplish the task without them, fine. Otherwise, avoid them.
Issue 5 – Very few situations remain in 2016 for login scripts. VERY FEW. VERY VERY VERY VERY VERY VERY FEW. Is that enough “VERY”s? Okay, one more “VERY!”. There. Put it this way, in the past 3 years, I’ve only encountered one (1) case that required a login script. The other 99 were easily solved by GP Preferences or some other approach. Actually, come to think of it, it’s about the same result as that for justifying WMI filtering.
Issue 6 – Do not map drives to shit on another planet. That’s all I need to say for this one. You should be able to figure out the rest.
Issue 7 – Varies by scale of the IT department. Tools cannot fix a broken process. Align the staff to manage the processes first. If it doesn’t roll uphill to ONE PERSON, it’s still broken. That person must also have a backup, just as every key position should. A dozen people making changes to GPO’s is a recipe for disaster, no matter if they answer to the same manager or not.
If you need a team of people to constantly maintain Group Policy, you’re doing it wrong.
There. I’m done for now. I will commence further whining in a few hours. Thank you.