Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Accélérer la stratégie de groupe, et quel impact aura l'implémentation des préférences de stratégie de groupe sur le temps de connexion ?

ayi

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:

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?
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?
How does the performance/overhead of GPP compare to using a kixtart or vbscript for things like mapping drives and installing printers?
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.
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?
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.
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.

ayi

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.