Slow access to PFs after migrating from E2K to E2K7   

Here's my scenario. We have a 3rd party CRM that runs in IE. One of the 
features of the app is client e-mail management. All e-mail communications to 
our clients run through this app and the app leverages Outlook/MAPI and 
Exchange public folders to do so. Each of our clients gets their own public 
folder and all e-mail communication to and from the client goes into their 
public folder. We have just over 30,000 client e-mail folders in the public 
store, all under a single hierarchy.

Previously, when our public folders were hosted by an Exchange 2000 server, 
access to those public folders via our IE-hosted CRM app was close to 
instantaneous. Now that I have migrated all of the public folders over to our 
new Exchange 2007 (SP1) server, it takes 10 seconds or more to list the 
contents of the client's public folder. Once you're in everything is fine, 
but that 10+ second initial content listing is killing my users.

Interestingly, if I type in the URL to any of our public folders an OWA 
session opens and it lists the contents of the folder instantly. However, our 
CRM app uses MAPI I believe and that seems to be the problem. Although, if I 
open my whole mailbox in OWA and try to navigate to the public folder from 
within OWA then the content listing is slow again. Very odd.

I have run the Performance Troubleshooter tool and it reported that we were 
seeing high RPC response latency (gee, ya think??). I have also noticed that, 
under test conditions (when no one else is on the system), when I try to list 
the contents of a client public folder in our CRM there is a CPU useage spike 
on the LSASS.exe process as well as the Store.exe. LSASS goes up to between 7 
and 8 percent (from 0). Store goes to about 4 (also from 0). Once the 
contents get listed in my CRM app the corresponding CPU spike on the server 
drops.

It seems pretty clear that the cause of my RPC response latency is due to 
something that the LSASS process is doing. What I don't know is how to fix 
it. 

Since I believe the LSASS process is responsible for security and 
authentication, I have considered re-propagating client permissions to all 
30K+ public folders. So my questions are:

1. Do you think resetting client permissions on my public folders will fix 
my problem?
2. Is there a way to do this automatically in Exchange 2007? Or is it okay 
to use my old Exchange 2000 ESM (my E2K server is still in place, it just has 
no mailboxes or folders left on it) and its "Propagate Settings" function?
3. If resetting my client permissions is not advisable or is not likely to 
fix my problem, what other things might I try to resolve this?

Thank you for any help or advice you can give.

-Jeff VanBishler

date: Thu, 24 Jul 2008 15:49:03 -0700   author:   Jeff VanBishler Jeff

RE: Slow access to PFs after migrating from E2K to E2K7   

Before I use the Exchange 2000 ESM to propagate permissions down my Exchange 
2007 public folder tree, I'd really like to know if that is likely to break 
anything. Does anyone know? Or is there a better way to propagate public 
folder settings in Exchange 2007 and I just can't find it?

Thank you for any help.

-Jeff VanBishler


"Jeff VanBishler" wrote:

> Here's my scenario. We have a 3rd party CRM that runs in IE. One of the 
> features of the app is client e-mail management. All e-mail communications to 
> our clients run through this app and the app leverages Outlook/MAPI and 
> Exchange public folders to do so. Each of our clients gets their own public 
> folder and all e-mail communication to and from the client goes into their 
> public folder. We have just over 30,000 client e-mail folders in the public 
> store, all under a single hierarchy.
> 
> Previously, when our public folders were hosted by an Exchange 2000 server, 
> access to those public folders via our IE-hosted CRM app was close to 
> instantaneous. Now that I have migrated all of the public folders over to our 
> new Exchange 2007 (SP1) server, it takes 10 seconds or more to list the 
> contents of the client's public folder. Once you're in everything is fine, 
> but that 10+ second initial content listing is killing my users.
> 
> Interestingly, if I type in the URL to any of our public folders an OWA 
> session opens and it lists the contents of the folder instantly. However, our 
> CRM app uses MAPI I believe and that seems to be the problem. Although, if I 
> open my whole mailbox in OWA and try to navigate to the public folder from 
> within OWA then the content listing is slow again. Very odd.
> 
> I have run the Performance Troubleshooter tool and it reported that we were 
> seeing high RPC response latency (gee, ya think??). I have also noticed that, 
> under test conditions (when no one else is on the system), when I try to list 
> the contents of a client public folder in our CRM there is a CPU useage spike 
> on the LSASS.exe process as well as the Store.exe. LSASS goes up to between 7 
> and 8 percent (from 0). Store goes to about 4 (also from 0). Once the 
> contents get listed in my CRM app the corresponding CPU spike on the server 
> drops.
> 
> It seems pretty clear that the cause of my RPC response latency is due to 
> something that the LSASS process is doing. What I don't know is how to fix 
> it. 
> 
> Since I believe the LSASS process is responsible for security and 
> authentication, I have considered re-propagating client permissions to all 
> 30K+ public folders. So my questions are:
> 
> 1. Do you think resetting client permissions on my public folders will fix 
> my problem?
> 2. Is there a way to do this automatically in Exchange 2007? Or is it okay 
> to use my old Exchange 2000 ESM (my E2K server is still in place, it just has 
> no mailboxes or folders left on it) and its "Propagate Settings" function?
> 3. If resetting my client permissions is not advisable or is not likely to 
> fix my problem, what other things might I try to resolve this?
> 
> Thank you for any help or advice you can give.
> 
> -Jeff VanBishler

date: Mon, 28 Jul 2008 13:53:02 -0700   author:   Jeff VanBishler