Now more than ever, scripting in the Microsoft world has extended the administrative abilities of an IT pro well beyond the simple use of built-in tools. You have, in essence, an unlimited ability to automate just about any part of the administration of your Microsoft environment — including Active Directory — with Powershell and other scripting languages.
Many IT pros think that they can simply script a problem away; and it is true that scripting is certainly a means to an end. Every IT professional should be capable of accomplishing some amount of their repetitive tasks with scripts. In the case of managing Active Directory groups, there’s plenty of functionality found in PowerShell cmdlets.
That said, it is a common mistake to assume that the more complex tasks can be handled with scripting alone. Nothing could be further from the truth. While it’s certainly possible to automate just about every action with a PowerShell script, is that really the right way to automate Active Directory group management?
There are several reasons why scripting isn’t always the answer:
- Scripting eventually may increase management costs. Many IT pros see scripting as a way to lower costs because of all the time savings a well-written script can bring to the IT organization. However, in the long run, once management realizes that they are scripting to solve problems, that realization is accompanied with the understanding that the development and maintenance of more and more scripts — each one incapable of self-adapting to changing business needs — may actually be costing the company more. It’s therefore understandable why scripts are often viewed upon poorly.
- Scripting won’t trump purpose-built tools. Scripting is designed to address edge cases or create custom solutions for problems that would not otherwise be achievable. When a purpose-built tools exists, the use of scripting is considered bad practice, simply because a one-off script will not achieve the depth of functionality needed.
- Scripts cannot address the exceptions. Scripts are built for a specific purpose and have no ability to dynamically understand or address one-off needs outside that of the script’s specific function.
- Scripts don’t allow for delegation. When deploying a group lifecycle process that properly manages Active Directory groups, IT pros understand that it’s good practice to delegate the management of groups to line-of-business managers. Scripts cannot facilitate this delegation of responsibility without writing individual scripts for each delegation scenario.
- Scripts don’t empower end users. Portions of Active Directory group management can be achieved by empowering users to self-service their group membership (in the form of requests). Using scripts, it would be nearly (if not downright) impossible to fully automate a user-initiated group management request, get approval, and perform the task requested.
- Scripting does attestation poorly. Group memberships, their assigned permissions, and their very existence need to be attested to by users who are closest to a given group’s use (and who can be either inside or outside of IT). While you could create a script to somewhat dynamically add and remove users from a group (based on Active Directory user account attributes, for example), that attestation would be limited in scope and would never be able to address the attestation of the groups that need to continue to exist within Active Directory.
Don’t get me wrong; scripts aren’t bad. They are the right solution when the task to be completed is a repetitious task — with little variation each time it’s run. But when you’re looking to actually manage an entire subset of Active Directory, the focus changes from simple one-off tasks to a set of policies, processes, procedures, and stakeholders that take you to a point far beyond where scripting could ever be useful.
So, when you need to automate one step, definitely consider scripting. But when you’re trying to automate every aspect of managing groups, it’s time to consider a purpose-built solution.