Limited time MSExchange.org offer! -- 1.Sep.2008 1:00:00 PM
TechGenix and SolarWinds have partnered to provide free copies of SolarWinds Exchange Monitor to all visitors who join the MSExchange.org Forums. SolarWinds Exchange Monitor is a handy desktop dashboard that continuously monitors Microsoft Exchange to deliver real-time insight into Exchange services, mail queue sizes, and host server health. Learn more about Exchange Monitor and the free offer!
Outlook 2007 / Exchange 2003 slowness ... due to GC acc... - 2.Dec.2008 9:26:39 AM
At my company (~700 employees), we have Outlook 2007 users, accessing a single Exch2003/sp2 server (no front end) ... and frequently, a lot of LAN-based users complain of serious lag/delay when switching between items within Outlook (server-based mailbox, calendar, psts, etc.). Enabling cached mode helps a little, but the problem persists. Users utilize Outlook Anywhere quite a bit, so exact levels of http vs IP access to Exchange is unknown but probably about equal, if not skewed to the http side. Additionally, the Exchange server has its logs and dbs on seperate SAN-based disks, which are 'optimized'. (Raid type, seperate spindles, fiber throughput, etc)
We have 1 domain, with 3 local DCs, 2 of which are GCs. The Exch server auto identifies the 2 local GCs in DSAccess... however, depending on which one is actively serving the GAL, our monitoring software shows the cpu of the GC getting hit very hard. (OS Processor queue length exceeding high thresholds). One word of note: the GC's have 2GB of memory, but the /3GB switch is currently NOT enabled on them.
So my question....
What is causing the extreme Outlook client slowness? Is it due to the (active lookup) GC not being able to handle the load? Should I create another DC/GC, and enable the /3GB switch? Should I manually configure the Exch server's DSAccess to just that GC to test? Should I network-isolate that additional GC so that only the Exchange server can do lookups on it? Or, will having 4 DCs/3 GCs share the load enough such that the clients will no longer see the delays in mail access? Would adding a front-end server help? Should I enable /3GB on all of the GCs?
Just trying to determine what the "problem" is, and what steps will make the biggest speed improvements for the clients....?
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
Exchange is hard on global catalogs, which is why you need them as close to Exchange as possible. However it will only use one, you can have 100s of the the things, but Exchange will use just the one.
The main performance hit with Exchange is usually storage.
However I would start with the Exchange Troubleshooting tool and see if that flags anything. You can download the tool from Microsoft.
Thanks Sembee... we have run the Exch Troubleshooting tool, Best Practices Analyzer, etc... and made most of the changes they recommended. Performance still suffers. FYI... network/LAN appears not to be contributing to the issue.
So if Exchange is hard on the GC, and the 2 systems are on the same subnet, would activating /3GB on the GC dramatically help? Would isolating a DC/GC to the Exchange server (so nothing else hits it) help?
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
The 3gb switch isn't supported on domain controllers, so doing that isn't going to help.
You have to ask yourself why the clients are hammering away at the domain controllers so hard. I have designed and consulted on larger sites than that and the DCs have been the least of my worries.
Have changes been made to the Exchange server, for example reducing the permissions cache time? That can increase the load on the server significantly.
Are the clients using the other domain controllers at all? If you hold down CTRL and then right click on the Outlook icon you can select Connection Status. That will show you what DC is being used (Directory Access).
Hmm... the document on MSExchange.org--10 Tips to Optimize Exchange 2003 by Rui Silva--specifically states that the /3GB should be enabled on all GC's.... ?
Can you elaborate on the "permissions cache time" ? How this is set, and how it could have been reduced as you are stating? (hotfix, service pack, BES-server-related, etc)
Outlook clients use whichever (DSAccess--GC) server the Exchange server is using. Similar to holding CTRL/right clicking the Outlook icon--within Outlook, you can select the Address Book, right-click on the "Global Address List" pull-down menu and select properties. The server listed there is the one (here at my company) that is generating the "OS Processor Queue Length" thresholds being exceeded.... ie, the DC/GC that our "clients are hammering away at"......
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
The 3gb switch is a classic arguing point. I don't even think Microsoft are 100% sure. I have seen KB articles state no you can't and others say yes you can. Its a mess.
Of course the easy way round it is to switch the DCs to 64 bit version of Windows - then the problem goes away.
The setting that I have indicated is not changed by any installation that I am aware of. Even third party, because of its performance hit. My Google fu seems to be off at this time of night, as I can only find the Exchange 2007 version of the article, not the Exchange 2003 version.
I have seen Outlook use other domain controllers in the past, so if everything is going to one DC then that is certainly why there is a performance kit. Is one of the domain controllers quicker than the other? Most clients (including Exchange) will use the first DC to respond.
Simon, yes, I too couldn't locate anything on my searches for that document either.
Doesnt Exchange determine the directory lookup GC to be used based on the DSAccess list, and then pass that to the Outlook clients?
Is there no way to load balance (or round robin) the clients accross the local GCs?
Even at 3:30am this morning, clicking between folders in my Inbox took ~13 seconds to switch between them. I logged onto the DC/GC my Outlook was using for directory lookups, and sure enough, the resources on that GC were getting hit very hard.... yet nothing was running on the server (no backups, scans, tests, replication, etc.)
So, is the slowness simply due to the concentration of Outlook clients hitting that single GC? Even in the middle of the night when no-one is using email...?
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
If you are seeing performance issues in the middle of the night when there are no users on the network, then that would tend to point the problem being elsewhere - not Outlook clients.
Have you tried changing domain controllers? Does this DC hold any other FSMO roles?
I hear you, Simon... it just appears that the DC/GC which is 'actively' handling directory lookups --when its resources get taxed heavily-- Ourlook client performance suffers at roughly the same time.... so, just making the guess here as to the connection.... but at 3am, I guess that wouldnt make sense...
We currently have local 3 DCs, 2 of which are GCs.
The DC/GC which is the current Outlook directory/GAL server, also holds these FSMO roles--domain RID, Schema Master and Domain Naming Master.
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
I would start looking at whether the DC is the cause of the problem, by moving the FSMO roles and GC to another machine and then either restarting the Exchange services to get it to find another GV or forcing to use another GC.
If it does prove to the be DC then DCPROMO it out, drop in to a workgroup and rebuild it.
We have manually forced Exchange to use both DC2 and then DC3, with the same performance results. Whichever of these 2 GCs we point it at, we still see Outlook performance degredation.
DC1 is primary DNS/WINS/PDC/Infrastructure Master DC2 is secondary GC/DNS/RID/Schema/Domain Naming Master DC3 is a GC
I am bringing DC4 online as an additional GC... and I assume we should then spread the FSMO roles across more of the DCs?
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
I believe that Microsoft state that one of the FSMO roles should not be on the same domain controller as the global catalog, unless all of the servers are global catalogs. Personally I don't see the point in having more than two GCs unless the FSMO roles are going to be spread out on to non-DCs, which would mean in theory seven DCs would be required.
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
I have put this problem to another group (which I can't say where due to NDA).
One of the first responses has been to check for restrictions. The example used was:
"If I have 700 mailboxes, and a group that contains 500 of them, and then I put that group on the restrictions of all but a couple mailboxes, then every time anyone sends an email to anyone that has the restriction the categorizer expands the group."
That could mean that every email sent is generating a high number of LDAP lookups.
Another thought was to use netmon to look at the traffic, but as it looks like LDAP, that would mean disabling LDAP signing, which may not be something that you can entertain.
Another issue we discovered recently, which may have had an impact on performance is we had recently consolidated 2 domains into one, and a large number of the groups were Universal groups, which I believe (in one domain) can cause lookup problems/delays.
I will look into your suggestion on restrictions.....
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
The only time that large groups are an issue is when they are expanded. That shouldn't be happening at 3am, unless the groups are used as restrictions on all of the objects and someone sends a single message.
I think you need to use netmon, see what the traffic is. Once you know that, then you can look for the cause.