Friday, October 9, 2009

When it’s OK to use Scripting in lieu of Group Policy Preferences

If you’ve been unfortunate enough to have read this blog very long, you already know what a HUGE fan I am of Group Policy Preferences (GPP) in Windows Server 2008 Active Directory.  With Windows 7 it’s an incredibly powerful tool that just happens to be dirt simple to figure out and to use.  I already described how you can replace legacy logon scripts with GPO and GPP settings.  However, I also mentioned that there are situations when it makes better sense to use scripting instead.  I provided a crack-infested comparison chart of this stuff also.  This does not in any way devalue the importance or power of GPP.  I’m just trying to put into perspective the difference of when to use a hammer and when to use a screwdriver.  Each is a worthy tool for its own intended purposes.

Collecting Inventory

I mentioned this in the previous post, but to further clarify: It’s for situations when you do not already have a software product in use that collects this information for you.  If you don’t have something in your environment to automate the chore of collecting hardware and software information from all of your computers, and you don’t have the budget or time (to learn a new tool), scripting is an excellent solution as long as you are ready to dive into scripting.  There are plenty of ready-made scripting alternatives to help you do this, even my own, but you can just as easily build your own with a little time and solitude.

Conflicting Configuration Models

By this, I mean when your intended configuration scheme goes contrary, or perpendicular to, your existing configuration model.  What that fuck does that mean?  A good example is mapping drives and printers for users.  In many environments, this is done by grouping settings against domain group memberships.  Users within a given group are assigned a common set of drive letters and maybe a common set of printers, and so on.  However, it’s also common to see user accounts which are not stored under a common OU in Active Directory.

GPP makes it as simple as breathing to map drives and printers against an OU or a Site.  You can employ WMI Filtering to add some flexibility to this to work with user group memberships, but it’s a little tricky and adds some additional processing overhead as well.  The bigger and more complicated your WMI query (WQL) becomes, the more overhead it incurs as well.

Scripting makes this easy.  However, if you happen to have user accounts organized into OUs in such a way that groups don’t really control your drive mapping requirements, then by all means: go with GPP settings.  It’s the better way to go for that situation.  For other folks who use domain groups to control mappings, but happen to have groups that contain user accounts which reside in different OU’s and overlap with other users in different groups, then you need to focus on using the group membership model first.

Launching Things as the User

Group Policy is great for deploying configuration settings.  It can also tweak the registry, add and edit files, create and update shortcuts, and so on.  But sometimes you want to run a process at logon as the logged-on user.  There is an endless list of reasons why you may want (or need) to do that, but it isn’t at all uncommon.  For these types of tasks, a logon script is the easiest approach.

Conclusion

When I say “scripting”, it doesn’t really matter what you use.  KiXtart, VBScript, Javascript, BAT/CMD, or a roll of duct tape and some KY jelly, whatever.  It just refers to YOU writing a set of instructions to be executed when called upon.  This can be during computer startup, during user logon, called explicitly by double-clicking on a file, or run from a scheduled job.  I suppose you could justify defining a “script” as being an order yelled at a surbordinate as well.

Regardless, overall, in the grandest of grand schemes of network administration in a Windows Active Directory environment: Group Policy and Group Policy Preferences should be your FIRST candidate for implementing any mass-deployment settings.  If you CAN do it with another method, fine, but always research the comparison to see which option gives you the most flexibility, control and easy of use.

No comments: