Reading a useful Technet link here: http://technet.microsoft.com/en-us/library/cc540464(EXCHG.80).aspx and had some questions: 1. Does anyone know if there is an RPC Perfmon counter that will display number pending RPC requests? If users were saying they were having problem, this would be a good counter to show whether the problem was on the server side? 2. In terms of any RPC Perfmon counter, is it possible to drill down to per DB? I mean, we could have an issue with just one store, but the average maybe ok because we have 49 other stores that are functioning well? 3. When using Exmon, is it possible to show/illustrate where RPC delays and what's causing it 4. Anything on the Outlook side that would show whether the problem was client related if users were experiencing slow connections to Exchange? All for Exchange 2007.

On Mon, 7 Mar 2011 23:53:01 +0000, Sheen1990 wrote: >Reading a useful Technet link here: http://technet.microsoft.com/en-us/library/cc540464(EXCHG.80).aspx and had some questions: 1. Does anyone know if there is an RPC Perfmon counter that will display number pending RPC requests? MSExchangeIS \ RPC Requests >If users were saying they were having problem, this would be a good counter to show whether the problem was on the server side? There isn't one. You need to look at the whole server. Memory, paging, IOPS, how long read and writes take to complete, etc. >2. In terms of any RPC Perfmon counter, is it possible to drill down to per DB? I mean, we could have an issue with just one store, but the average maybe ok because we have 49 other stores that are functioning well? RPCs just measure the tasks to be done, not the actual work needed to complete the task. In other words, they're just an indicator that things are running smoothely or not. >3. When using Exmon, is it possible to show/illustrate where RPC delays and what's causing it No. That's what all those other PerfMon counters are for. >4. Anything on the Outlook side that would show whether the problem was client related if users were experiencing slow connections to Exchange? All for Exchange 2007. Make sure the server's perfroming as expected. If the problem is with one client it's unlikely to be server-related (unless you count having, say, 100,000 items in the Inbox). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

>>Reading a useful Technet link here: http://technet.microsoft.com/en-us/library/cc540464(EXCHG.80).aspx and had some questions: 1. Does anyone know if there >is an RPC Perfmon counter that will display number pending RPC requests? >MSExchangeIS \ RPC Requests I thought RPC Requests= "number of MAPI RPC requests currently being serviced by the Microsoft Exchange Information Store service". I guess what I'm saying is that isn't it possible that the number of RPC Requests is high because. for example a lot of people were carrying out high load tasks, but if the server h/w could handle the load that would be fine. Whereas, if we had a counter that measured *pending* RPC requests, this would indicate that the server couldn't handle the load since these requests are still queued for action. Do you know if there is anything similar to what I'm looking for? >>If users were saying they were having problem, this would be a good counter to show whether the problem was on the server side? >There isn't one. You need to look at the whole server. Memory, paging, >IOPS, how long read and writes take to complete, etc. Do you know what counter I'd use to measure how long read and writes were taking to complete? >RPCs just measure the tasks to be done, not the actual work needed to >complete the task. In other words, they're just an indicator that >things are running smoothely or not. From what I understood, RPC's were a unit of measure of an Exchange task? Am I correct?

On Tue, 8 Mar 2011 09:54:01 +0000, Sheen1990 wrote: >>>Reading a useful Technet link here: http://technet.microsoft.com/en-us/library/cc540464(EXCHG.80).aspx and had some questions: 1. Does anyone know if there >is an RPC Perfmon counter that will display number pending RPC requests? >>MSExchangeIS \ RPC Requests >I thought RPC Requests= "number of MAPI RPC requests currently being serviced by the Microsoft Exchange Information Store service". It is. >I guess what I'm saying is that isn't it possible that the number of RPC Requests is high because. for example a lot of people were carrying out high load tasks, but if the server h/w could handle the load that would be fine. The "load" is the work generated by the RPC, not the RPC itself. >Whereas, if we had a counter that measured *pending* RPC requests, this would indicate that the server couldn't handle the load since these requests are still queued for action. There's no "pending" RPC, just as there's no "pending" function call. The RPC is accepted and the work begins. >Do you know if there is anything similar to what I'm looking for? The counter I gave you measures what you asked for. >>>If users were saying they were having problem, this would be a good counter to show whether the problem was on the server side? >>There isn't one. You need to look at the whole server. Memory, paging, >>IOPS, how long read and writes take to complete, etc. >Do you know what counter I'd use to measure how long read and writes were taking to complete? Look at the physical disk counters. The "seconds per read", "seconds per write", and "seconds per transfer" measure those. >RPCs just measure the tasks to be done, not the actual work needed to >complete the task. In other words, they're just an indicator that >things are running smoothely or not. >From what I understood, RPC's were a unit of measure of an Exchange task? Am I correct? It's not a measure, it's just a count. Just like your boss telling you to do something. His telling you doesn't measure the work you expend in doing the task, just that there's one task to complete. When you see a delivery truck on the road it's just one delivery truck. You don't know if it's empty or carrying a couple tons of freight. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP