Speeding up Group Policy, and how will implementing Group Policy Preferences impact logon time?

Question

I'm looking for some advice on speeding up and upgrading our logon system to make it more robust and faster.

I inherited an older logon system, which was migrated over from Novell Netware originally. We are currently running Windows Server 2008 R2, but the domain version is still Windows 2000 (on the theory, if it ain't broke, don't fix it). We would like to eventually upgrade to Windows 7, but we will have a mix of Windows 7 and Windows XP SP3 for at least a few years. We have some SP2 machines, but we can afford to replace those if it's not possible to upgrade to SP3.

Currently, we rely primarily on logon scripts, mostly written in Kixtart, but with some written in VBScript, and with a Windows BAT wrapper. Logon scripts map drives and printers, install quick workarounds for security issues or minor bugs when there is no official patch (like the recent winhelp.exe security issue), install software, and do miscellaneous tasks like backup some settings like IE Favorites in case machines need to be reimaged.

We also have a small number of group policies enabled. Those implement some security settings, mostly. I was experimenting with using GPO to install software, but I have not found this to be practical. Too much of our software does not use an MSI, and the hours I spent trying to do an MSI capture were unrewarding on the one occasion I tried it. It ended up being easier simply to use a script to do the unattended install. What's more, maintenance is a pain, as is dealing with delayed bootups if a machine has been turned off for too long. I don't mind revisiting this, but it seemed that scripts were working fine, so I've never been compelled to invest more time into this.

Our system works OK, but it's a little inflexible. It was designed to log information on every logon to a centrally stored file on a per-login ID basis, and permissions issues (such as with a simultaneous logon with one user name) trip this up every so often. We rely on flags to determine if software has been previously installed, which can be fragile and sometimes results in unnecessary installs (if a new user logs on to a workstation, for example). It's somewhat slow, especially the group policy side. I tried doing a profile, and I think this takes about 300 seconds (could be somewhat off). A typical user would have about 8 small policies applied. We have about 12 OUs but make use of WMI filtering for a few of the group policies.

We map about 8 shared drives (based on group membership, not OU), and about 20 printers (everyone gets every printer, but a different print server for each site). Software needs vary pretty dramatically based mostly on OU, but a few folks outside of an OU may need the software too.

My questions:

1. How hard is it to deploy GPP? Given that Windows XP does not natively support this, right? We need to install the client side extensions?
2. Is GPP reliable on Windows XP SP3? Googling, I turned up some references to bugs and slow performance. Does this match the current status of this product?
3. How does the performance/overhead of GPP compare to using a kixtart or vbscript for things like mapping drives and installing printers?
4. What's a good practice to use for keeping track of successful/unsuccessful logins? Our current system seems to have too much overhead. Should this be stored in the Event log? On which machine? Centrally, or on the local desktop? We do use the logs as a debugging tool currently, and also to determine when a user last logged on to the domain.
5. What should I try to speed up our current Group Policy infrastructure? I think this is what takes a long time at startup. Any ideas for where to start troubleshooting this?
6. What are best practices for creating a modern logon system to deal with the tasks I mentioned? Map drives, map printers, install software, install patches and perform miscellaneous backup routines and the like. What tools do you like and recommend for this job?
7. What's the best way to install software that isn't neatly packed in an MSI already? We are a non-profit and could get some software donations from Tech Soup of things like SCCM. But, I really don't know if this is worthwhile.
8. What are the implications of upgrading our domain to Server 2008 R2 version, to allow us to make use of GPP? I should mention that we have two member servers on our domain that are running Windows NT. These are basically appliances used only for our voicemail system. I don't want these to break. We did have an issue with upgrading our domain controllers with SMB, but I was able to find the workaround of lowering security settings. Any gotchas if we upgrade domain version? It seems like the answer should be no, but I am hoping to learn about some real world experiences.

Sorry to be so long-winded, this turned out to be more involved than I thought it would be to ask. Any thoughts on your personal experiences would be helpful. I'm the only technical person on our IT team.

Answer 1

Greetings from another non profit IS person. :)

How hard is it to deploy GPP? Given that Windows XP does not natively support this, right? We need to install the client side extensions?

GPP are pretty much straight forward if your systems are XP SP3 and recently patched. I've rarely seen problems related to the preferences. If you have WSUS already you should be able to check that all your systems have the necessary client installed.

Is GPP reliable on Windows XP SP3? Googling, I turned up some references to bugs and slow performance. Does this match the current status of this product?

I haven't had any major reliability problems after the client side extension issues listed above were worked out.

How does the performance/overhead of GPP compare to using a kixtart or vbscript for things like mapping drives and installing printers?

I'm assuming that you are referring to the desktop performance.. If so the speed between the two has been negligible in my environment.

What's a good practice to use for keeping track of successful/unsuccessful logins? Our current system seems to have too much overhead. Should this be stored in the Event log? On which machine? Centrally, or on the local desktop? We do use the logs as a debugging tool currently, and also to determine when a user last logged on to the domain.

We have a couple systems in place, a legacy system (very much like what you describe, I'd like to see it retired) and event log auditing for successful and failed login attempts. Enable the auditing on your domain controllers would be enough. I suggest using Splunk to collect your logs but that is a matter of choice.

What should I try to speed up our current Group Policy infrastructure? I think this is what takes a long time at startup. Any ideas for where to start troubleshooting this?

What are best practices for creating a modern logon system to deal with the tasks I mentioned? Map drives, map printers, install software, install patches and perform miscellaneous backup routines and the like. What tools do you like and recommend for this job?

I've had extremely good luck with the GPP listed above. The vast majority of startup tasks can be accomplished with a handful of GPP settings.

What's the best way to install software that isn't neatly packed in an MSI already? We are a non-profit and could get some software donations from Tech Soup of things like SCCM. But, I really don't know if this is worthwhile.

I highly recommend EminentWare. It's a paid product but not too expensive. It will deploy updates for your non MS products (I love the Java and Adobe updates) and allows you to package and deploy software.

What are the implications of upgrading our domain to Server 2008 R2 version, to allow us to make use of GPP? I should mention that we have two member servers on our domain that are running Windows NT. These are basically appliances used only for our voicemail system. I don't want these to break. We did have an issue with upgrading our domain controllers with SMB, but I was able to find the workaround of lowering security settings. Any gotchas if we upgrade domain version? It seems like the answer should be no, but I am hoping to learn about some real world experiences.

I can't comment, I'm still on 2003 functional level.

Answer 2

8.

Member server don't affect function level of your domain. Only DCs will require this. If all of your DCs are 2008 and above, you can raise the Functional Level to 2008 with out any issues.

Answer 3

Moved from 30,000 lines of logon script on 4,000 PC's to pure GPP with little to no issues on XP SP2 with GPP add-on. We used GP Security filters and GPP filters to control most policies via AD Universal Groups rather then OU's. OU's being linear don't allow the flexibility you may eventually need, whereas pure Security filters allows a design that is free from the constraints of your OU design.

Looking back, with GPP's being so flexible, I would have probably put all user-based GPP's in a single GPO to save on loading time. We initially implemented GPP's with a new GPO for each GPP feature: one for drive mappings, one for favorites, etc. It was hundreds of setting but I imagine would have been quicker to process as a single GPO (which is a XML file for GPP).

For speed, in XP keep your Computer and User settings in separate GPO's and disable at GPO level which ever you aren't using in that GPO. In Windows 7 this is not an issue.

Answer 4

About a year and a half ago my firm went through this process. We were all XP (about 700 seats), server 2003 (domain also), with a bunch of scripts like everyone else. We also had ScriptLogic which I didn't like. We deployed GPP to our XP machines, upgraded functional levels, and started migrating things done via script to GPP and had great success. Since then we've added many dozens of items into GPP. All drive mapping is done there, plenty of file copies, shortcuts, regkeys etc. I can certainly say we are very heavy users of GPP. We use the item-level targeting on the large majority of items (with no noticeable impact). We migrated to Windows 7 and also using WMI filtering linked appropriate GPOs also filled with GPPs and have had very few problems. Nothing serious. From cold boot to a ready-to-use desktop we are at 3 minutes or less.

1. Deploying GPP to XP was simple for us. We just made sure it was on our image (or in the image process) and got to all PCs before we starting using GPPs.
2. At the time we were on XP SP2
3. 3 minutes or less from powered off to usable desktop with a lot of GPOs and a lot of GPPs. I think that's pretty good. One caveat - we do not deploy printers using GPP - this is I guess one area where we did have some problems, but mostly performance based. This slowed down login quite a bit in some instances so we turned that off.
4. We track bootup and logon times (via native desktop event log entries) using a custom script writing to remote SQL DB.
5. The event log is your friend. If you're going to be migrating, that is the time to clean up, don't re-use GPOs. Create new ones with only what you need. Use WMI filtering where possible and just follow best practices (i.e. turn off User Settings on GPOs only applied to computers... etc.)
6. We use a combination of GPOs with GPP, SCCM, WSUS and AppV. We turned on folder redirection (with VSS), turned off roaming profiles and everyone is pretty happy with the environment.
7. For you, depending how large or small, I would probably not recommend SCCM although I like it, but I certainly highly recommend AppV. Can't recommend it highly enough.
8. no comment