Editor's note: When you're trying to get into the fast lane of Windows performance, it's easy to get sidetracked...
by confusing traffic signs and complex directions. Never fear. In this part of our three-part series on Windows performance, Chris Amaris and Kenton Gardinier -- authors of "Windows 2000: Performance Tuning and Optimization" -- offer a guide to handling Group Policy and traffic analysis. In part one of the series, they provided tips on planning and testing, tune replication, and schema management. In part two, they gave advice about switching to native mode, network monitoring, and Exchange and Active Directory Storage.
Do analyze traffic to determine what the impact will be on the network. Use protocol analyzers when you're deploying a new technology.
Whenever you deploy new technology, be sure to include a protocol analysis to check what types of packets, how many and in what pattern they will be generated. A great time to do this is when you are doing lab testing of a new technology in the prototype or proof of concept stages of a project. The lab is set up, you?re focused on the technology and the lab is typically isolated from all other traffic. Looking at common operations and seeing what type of network traffic they generate will give you a profile of the normal behavior of an application to compare to later on. Establishing this profile in advance in an isolated test lab will save you hours of optimization time later.
I worked with an engineering firm with offices worldwide and relatively slow links between offices. They were deploying a centralized Exchange messaging system with Outlook clients. They had tested the clients prior to deployment in a local lab with a simulated WAN link and had gotten great performance. After deployment, they started getting reports from the end-users of delays. It was a difficult situation to troubleshoot, as all the users that were complaining were at remote offices with no IT staff. They reviewed the traffic pattern of the incoming requests and could see no real delays or unusual patterns.
After a detailed review, I realized that the clients were configured with the wrong protocol binding order. It was timing out the protocol after several seconds, then trying the correct TCP/IP protocol. After reordering the protocol binding (RPC_Binding_Order) order in the registery (HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchangeExchange Provider), clients were able to connect quickly.
If they had tested the client locally using a protocol analyzer during the prototype phase, they would have realized the initial requests were using the wrong protocol and adjusted the configuration prior to deployment.
Don't get too complex with Group Policy.
Windows 2000 Group Policies are a really cool way of delivering desktop level configuration setting through Active Directory. You can change the default setting for users, enforce policies on the desktops, deliver software, lockdown setting and even set security. This is all delivered and managed through Active Directory, allowing an incredible degree of control over users and desktops.
However, there can be performance impacts of the delivery of these Group Policies if they are not tuned and optimized correctly. In addition to being applied at the site and domain level of the hierarchy, group policy is applied at the OU level. That means that group policy can be applied at each level of OU. Group policies can take up to 15 seconds at user login to apply at each level and thus can scale proportionally to the number of levels in the OU tree. So, if an OU hierarchy has eight levels and group policy is applied at the every level, the total login time to apply group policy is 135 seconds (15 s for domain GPO + 8*15 s for OU GPOs = 135 s total). That's over two minutes!
To simplify, you can either not apply group policy at all levels of the OU tree or don't go design your OU tree with more that three levels. This will keep the maximum login time to under a minute.
One situation that I was brought in to optimize was for a large financial institution. They had deployed Active Directory and Windows 2000 throughout the organization about six months prior and everything had been working great. They had slowly begun to see degradation in login performance, to the point where it was taking close to two minutes to login. However, they reported that there was no problem with functionality and the servers were very lightly loaded. After a quick review of their architecture and performance stats, I determined that the problem was group policy application.
They had created an initial OU hierarchy with seven levels based on the organization, region, departments, sections, groups, users, computers, etc. Group policy had been created at the departmental level during the initial deployment and at the computer level. Over time, group policy objects had been created for each of the other levels, sometimes only containing a single group policy setting. As these group policies were added, login times got worse and worse in 15-second increments.
The solution was to merge the existing group policy setting into fewer group policy objects and apply them lower down in tree to allow customization at the department and section levels. The result after the optimization was a huge decrease in login times, with no change in functionality.
For more information:
Read part one of this series.
Check out part two.
Is your Win2000 performing at its peak? Learn how to control your environment and substantially improve system performance from authors Chris Amaris and Kenton Gardinier in this SearchWindowsManageability online event Maximizing Windows 2000 Performance Thursday, May 23 at 2 pm EDT.
About the authors: Chris Amaris is CTO and Kenton Gardinier is senior consultant for Oakland, Calif.-based Convergent Computing, which provides IT consulting and technical services. They are co-authors of the book, "Windows 2000: Performance Tuning and Optimization."