I've been using Group Policy heavily in my Customer sites since mid-2000 when I started deploying Windows 2000 Server and Windows 2000 Professional clients. Group Policy is one of the most compelling features to the Windows Server / Active Directory platform over other Samba and other single-sign-on mechanisms that are compatible with Windows client operating systems.
What have you learned when implementing Group Policy?
Asynchronous policy processing provides for a non-deterministic experience. It was turned off by default in Windows 2000 Processional but turned on by default in all later versions of the Windows client operating system. I highly recommend forcing the process back to synchronous to provide a deterministic experience.
There is tremendous value in understanding how the settings in GPOs are selected and applied to computers and users. The algorithm is really, really simple (and "Block Inheritance" and "No Override" only slightly complicate the algorithm). Most policy application problems end up being a mismatch between the sysadmin's understanding of the algorithm used to apply group policy and what the OS actually does. Relying on tools like RSoP or GPRESULT rather than having a solid understanding of how the feature works is a bad idea.
Don't forget site-level GPO links. They can be very, very handy. Be wary of settings that may cause major events to occur (like software installation with mandatory removal when computers "fall out of scope") when portable computers are moved between sites.
Plan and test in lab OUs and with test computers before deploying to production-- especially with the software installation functionality. Test, test, test and then test again. Group Policy can allow you to damage the configuration of hundreds or thousands of computers very, very easily if you make a mistake.
Don't look at Group Policy as doing anything for security, per se. Group Policy can help in a "defense in depth" strategy (turning on features like AppLocker, enforcing group memberships, etc), but if someone gains "Administrator" rights on a machine it's going to be easy for them to "kill off" Group Policy on that machine.
Make sure you understand how "Block Inheritance", "No Override", and WMI and security group filtering work. These features can allow you to manage scenarios that simply linking GPOs at OUs can't handle. Try not to over-use these features because they can be non-intuitive to reverse-engineer months later or for other sysadmins to understand.
Backup critical GPOs before making changes. The GPMC tool added this functionality and it's very, very handy. You should be doing System State backups of AD anyway but restoring an individual GPO from backup using GPMC is much handier than a System State restore.
I frequently take advantage of scripts that work as a "trap door". Clients can apply the scripts so long as they're not a member of a given group. The last line of the script puts the client into that group such that on the next boot the client no longer executes the script. This is very handy behavior.
What would you have changed?
Not much. I have various different Customers with various different "revisions" of my group policy application "style". I wouldn't "do anythign different", per se, but I do work toward getting everything normalized into one very similar configuration. For me, that's just a matter of tweaking the "style" of the GPOs not so much making any kind of broad, sweeping changes. Mainly changes I've had to make have been a result of not testing enough before going into production. Did I mention you should test early and often?
How did you design it to work with both clients and servers?
Just like I'd segregate different classes of users or client computers. I segregate client computers and servers computers into different OUs and link different GPOs to those OUs. Servers of different roles may be further segregated (or put into security groups and the GPO application filtered). I have common GPOs that apply to both types of computers (usually with only a select few settings in them).
How did you handle or accommodate various operating systems?
WMI filtering is one way to handle the various Windows versions. It works fine but I dislike it, personally.
I generally deploy a startup script (that I've written on Customers' time, unfortuantely, so I can't share it here) to detect the Windows version of Group Policy clients (as well as their 32/64 bit-ness and whether they're bare-metal or running on a given hypervisor) to populate groups such that I can use security group filtering rather than WMI filtering. Because WMI filtering is atomic only to the GPO, whereas I can use security group filtering in individual software installations within a GPO, I prefer security group filtering.
I have no experience with client software to allow non-Windows clients to use Group Policy so I can't speak to that at all.
Are there generally accepted group policy designs that one should follow?
I come from the "old school", so I learned to design Active Directory based on recommendations made by Microsoft "back in the day". I think about Group Policy very heavily when I'm laying-out my OU structure (along with Delegation of Control, which is my first concern re: OU structure).
Personally, I prefer to have as few GPOs as possible to get the job done w/o repeating common settings in multiple GPOs. I make as limited use of "Block Inheritance", "No Override", and security group filtering (especially with "Deny" permissions) as possible. I try and name GPOs verbosely such that they are "self documenting". I never modify the default GPOs that come "out of the box" with Active Directory such that I can disable all other GPOs in an "emergency" situation and return the product back to "stock" behavior.
Is it a good idea to nest policies to create a hierarchal tree like model?
That's my general strategy and it's worked well for me. I may link the same GPO at multiple places (say a GPO named "Common Settings for Member Server and Domain Controller Computers" that's linked at a "Member Servers" OU and the default "Domain Controllers" OU). I'd then link addt'l GPOs that have more specific settings as I move down into my OU hierarchy. Linking a "silly" number of GPOs (many tens or hundreds) is going to impact performance. I have Customers with clients that link 7 - 12 GPOs with no ill performance effects.
Are there any concerns to login slow downs for client machines in relation to the design of the policy structure?
Some of the group policy Client Side Extension (CSE) modules can be slow. In some cases (like Folder Redirection or Software Installation Policy) it might only be a one-time slowdown. In other cases (like IE Policy in Windows XP SP3) it can add a couple of seconds to each logon. In general, try to be conservative and link as few GPOs as you need. Run as few scripts as you need (they can really add up if you're processing them synchronously). Testing logon times should be part of your testing.
Since there are Windows XP and Windows 7 machines, is there a difference between ADM files and ADMX files? How do I know when to use one over the other? Does it even matter?
There is no difference in the REGISTRY.POL files created by ADM files versus ADMX files. If you're going to manage Group Policy from Windows 2003 or Windows XP then you need to keep ADM files around. If you're going to limit your GPO administration to Windows Vista or newer OS's then you can ditch the ADM files. Personally I haven't worried about it, but then my largest SYSVOL is only about 400MB. If I had hundreds of GPOs then I'd probably want to migrate away from ADM files ASAP.
Is loopback processing a good idea to use?
If you need the feature it provides then it's absolutely a good idea. There are some scenarios that you can't configure without it. Loopback policy processing works fine provided you understand how it works. It's very useful for the purpose it's meant to serve (applying consistent user settings to computers regardless of the user logged-on).
Someone told me that I should look at utilizing the user configuration settings are disabled or the computer configuration settings are disabled option within a Group Policy Object. Is this a smart thing to do? Does it matter if this is set?
This ties into the question re: logon times. You can benchmark it and see in your environment but, frankly, I've seen no performance difference. I don't worry about it in my Customer sites.