Replacing Logon Scripts with Group Policy Preferences

I’ve droned on about this many times, but I just drank a triple grande mocha and had an epiphany.  Maybe that was a bowel movement, who knows.  Probably the same thing.  In any case, I thought about what the most common uses for logon scripts are, and how they map into Group Policy Preferences (GPP) with Windows 7 and a Windows Server 2008 (WS08) Active Directory domain. 

Note that you can leverage GPP without having a WS08 AD environment.  You can use it with a Windows Server 2003 AD environment as long as you have at least one WS08 domain controller in your domain.  GPP settings are only applied to Windows Vista and Windows 7 clients.  Windows XP and WS2003 clients are only affected if you install the GPP client update.  Computers which do not recognize GPP settings just ignore them.  No harm done.

The most common uses for logon scripts I’ve seen (after years and years of writing them) are:

1. Drive Mappings
2. Printer Mappings
3. Logon Banners
4. File Downloads
5. Registry Changes
6. Setting Environment Variables
7. Software Installations
8. Inventory Collection

(1) Drive and (2) Printer mappings are so simple in GPP.  They literally become checkboxes and a few keystrokes.  That alone removes many lines of code (for properly developed scripts with error checking) and at least a handful (for dumb scripts with no error checking).

(3) Logon Banners are easy to do with Group Policy settings actually.  This hasn’t changed since Windows 2000 as far as I know.  Edit a GPO and navigate to Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / Security Options.  Then edit the two policies “Interactive logon: Message text for users attempting to log on” and “Interactive logon: Message title for users attempting to log on”.  Most often this is performed on the “Default Domain” group policy.

(4) File downloads often incur many lines of code, if coded properly.  Things like checking for existing files, date stamps, contents, etc.  With GPP it’s a few clicks and type in the source and target file paths.  Go to Computer Configuration (or User Configuration, if the policy is user-related) / Preferences / Windows Settings / Files.  Then right-click and choose New –> File and fill-out the form.  Done.

(5) Registry changes are similar to file downloads in that script code often involves checking for the existence, and value of keys and then performing the actions to update them and check for errors.  With GPP: Computer (or User) Configuration / Preferences / Windows Settings / Registry.  Right-click and choose New –> Registry Item, Collection Item, or Registry Wizard, and fill-out the form.  Done.

Setting (6) Environment Variables can be done in several ways depending upon the scripting language being used.  KiXtart uses SET, SETM and SETL commands, with SETM being used for making System Variables (rather than User variables).  However, setting System Variables during a logon script requires the user to have Administrative rights, otherwise, only User Variables can be configured.  GPP allows you to set environment variables regardless of user permissions.  With GPP: Computer (or User) Configuration / Preferences / Windows Settings / Environment.  Right-click and choose New –> Environment Variable.  Fill-out the form and click OK.  Done.

Software Installation is something demonstrated in classes to show what Group Policy “can” do.  As I’ve always said: never confuse “can” with “should”.  In very small environments (a handful of computers) you can expect to deploy very small applications (like WinZip or Acrobat Reader) as long as they’re all connected on a fairly fast LAN.  Beyond that and you’re trying to haul boulders up a mountain on the roof of a SmartCar.  Seriously, don’t do it.  I won’t go into this here, but in general, software deployments to more than 20 computers, especially if on a WAN or 10/100 Mbit LAN should be done with other tools, or do them using custom scripts, not logon scripts.

Inventory Collection is something often done with logon scripts when you can’t afford a more robust tool like Microsoft SMS or System Center Configuration Manager.  There’s nothing wrong with that either.  Those products are worthy of every cent as long as you plan on leveraging most (if not all) of what they offer.  If they are overkill, you have to weigh the cost vs benefit to your environment.  For large environments they make sense more often than not.  For very small environments, you may want to look at System Center Essentials or something like that, or continue using custom scripts and logon scripts. 

Inventory Collection is one aspect of network management that Group Policy and Group Policy Preferences don’t really offer much benefit.  If you’re interested in free logon script solutions for inventory collection and reporting, just search the Internet. There are quite a few.  I wrote one myself called DCIS actually, which is available with a web reporting package from http://sites.google.com/site/skatterbrainz  under “file downloads”.

Conclusion

Of all these common tasks described above, only two (2) fall outside of the realm of Group Policy or GPP.  However, the vast majority of situations I’ve seen over the years leads me to say that those two are relatively rare in most environments.  I haven’t seen (or heard of) many situations where System Admins are installing software with logon scripts, or collecting inventory either.  In most small business environments these are done the old fashioned way: sneaker-net.  In some, where the SA feels inclined to automate things, they use custom scripts (usually .BAT or VBscript files) to push things out, rather than have each client pull.

Overall, if you look at most logon scripts you will find they usually focus on the first six(6) tasks I’ve described above.  If you replace those tasks with GPP you can often reduce your logon script files to almost nothing, if not completely eliminating them altogether.  The best part of this is that you’re not only replacing a script, but the ability for another person to be able to troubleshoot these settings without having to be familiar with scripting languages.