I’m still surprised at how often I run into customers and colleagues in the IT world who are still convinced they HAVE to rely on scripts to enforce configuration standards on their Windows computers.
Thumbing back through my notes, I estimated that of the last three dozen client engagements I’ve encountered, only a small number of situations required the use of something other than Group Policy to enforce.
- Startup Scripts
- Logon / Logoff Scripts
- Scheduled Tasks
- Event Triggers
- Third-party Utilities and Agents
Here’s a few that seem to come up most often for me:
- Adding or Removing Desktop Shortcuts
- Creating or Changing Files, Folders and Registry Keys
- Searching for / Connecting to Shared Printers
- Adding Domain Users/Groups to local Administrators
- Blocking Access to Specific Windows Programs
- Establishing a Locked-Down Kiosk environment
There’s quite a few more, but these seem to come back into conversation again and again over the past several years.
Even with the new updates to Group Policy for Windows 10 and Windows Server 2016, many of these issues were always easier to address via Group Policy settings or Group Policy Preferences.
There’s nothing wrong with scripts. But they’re just one tool in a room full of other tools. To me, scripting is like an adjustable wrench. It can be made to fit a wide range of bolts, but it’s not the most efficient tool for pounding nails, cutting wire, or scraping paint. Each of those has other tools which are more efficient.
The 1990’s mindset of relying upon scripting for all configuration management needs is in serous need of overhaul. This has been true for quite some time. Even I have had to undergo my own self-analysis to get myself out of some bad IT habits.
For years I was the go-to person in whatever small group I was in, for scripting needs. Now, when I get contacted by some of those colleagues I stop and try to revise my approach to ask which options make the most sense. Not always from a technology aspect, but financial, organizational, and efficiency point of view.
The Bad and The Ugly
On the flip side of this beast is the all-too common propensity to overuse Group Policy. I’m not referring to the comparison with scripting, but with regards to creating too many GPO’s. I’ve seen environments with hundreds of GPO’s, and if there was anyone officially “in charge” of them, they had no idea who created them, why or what impact they have on their users and devices.
Tip – If you don’t have documentation to explain “what” and “why” for each GPO and each GPO setting: STOP! Do not add any more changes until you review and validate what you have already.
In most cases, the review process alone will result in identifying and removing many redundant (or conflicting) settings. The performance and reliability impacts alone are worth it.
Tip – If you have so many GPO’s and settings that applying your full attention to them would take at least a week to review, then it’s probably time to start over.
Yes. It’s often painful. But in the end, you’ll have a clean set of rules which are justified, and documented. And rather than band-aid approaches to existing settings and GPOs, you get the opportunity to apply current “best-practices” to insure more efficient usage, easier administration, and better performance.
As one colleague I know has said: “If you can’t be sure how good the foundation is, build a new house on solid ground.”
That’s often not as bad as it sounds either. Most often it depends on how much customization has been done to the “Default Domain” GPO. If it’s fairly untouched, you can create a new root-level OU and start fresh. If it has been modified a lot, you’ll need to separate the custom settings first, which can be a bit of a pain – but still worth it.
Do it right – or don’t do it at all.