Hi Forum, I recently asked a question about a Marketing application that we were thinking of introducing into our environment: http://social.technet.microsoft.com/Forums/en/exchangesvrgeneral/thread/75928b68-24e8-4d3a-89b4-7c8b4bd7a12a Basically, this appliction will run against Exchange 2003. It will connect using MAPI and will be able to copy messages/move them to folders etc. I had two further questions I was looking for insight on: Question 1: The vendor talks of "RPC Calls" to Exchange a lot, could someone define what an RPC call actually is? Is it when their application connects to Exchange using MAPI and performs some sort of task? Question 2: I assume the lower the number of "RPC calls" the application carries out, the better? Question 3: Is an RPC Call the same as a MAPI connection? Or can you have several RPC calls within the same MAPI connection? Question 4: If the application is coded badly, could even a few RPC calls have a significant effect on Exchange, or is an RPC call the same as an Outlook client connecting to Exchange?

1. RPC calls are the same thing Oulook does to perform tasks on your mailbox. 2. In terms of load on the server, yes. 3. MAPI is an API that uses RPC. MAPI rides on top of RPC per se. 4. I suppose a badly coded application could have disastrous effects. Some time ago, my (former) employer was considering an RPC-based applicationt that had to have service account rights on the Exchange server because it was going to write tasks and appointments into everyone's mailbox. When I protested to management the effect that just one bug could have on the mail store, they backed off. A properly designed application should perform these kinds of tasks with messaging, i.e., send users messages that they act on, not place data into mailbox folders for them. I don't know what your application is going to do or whether RPC access to the mailstore is appropriate, but it's something you might want to think about. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Sheen1990" wrote in message news:2d69c0b9-2e44-4167-b9b0-f4849c0326b4... Hi Forum, I recently asked a question about a Marketing application that we were thinking of introducing into our environment: http://social.technet.microsoft.com/Forums/en/exchangesvrgeneral/thread/75928b68-24e8-4d3a-89b4-7c8b4bd7a12a Basically, this appliction will run against Exchange 2003. It will connect using MAPI and will be able to copy messages/move them to folders etc. I had two further questions I was looking for insight on: Question 1: The vendor talks of "RPC Calls" to Exchange a lot, could someone define what an RPC call actually is? Is it when their application connects to Exchange using MAPI and performs some sort of task? Question 2: I assume the lower the number of "RPC calls" the application carries out, the better? Question 3: Is an RPC Call the same as a MAPI connection? Or can you have several RPC calls within the same MAPI connection? Question 4: If the application is coded badly, could even a few RPC calls have a significant effect on Exchange, or is an RPC call the same as an Outlook client connecting to Exchange? Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Thanks Ed. Regarding #4, the application won't be able to add tasks/appts, but it will certainly be able to move messages between folders and such. The vendor is saying that the application makes RPC calls to Exchange to carry these out and that an RPC call was essentially what Outlook does. As such, their application won't have that great an effect on Exchange load - if the app is running against 20 mailboxes, it will simply be the same as an extra 20 Outlook connections. I am thinking that, yes, an RPC call maybe a low stress activity between Outlook and Exchange, but that is because MS coded both, and coded them both well. If the vendor's app sucks, then there could be a massive difference between an Outlook user moving a message in their mailbox to a different folder, and their application moving a message in someone's mailbox to a different folder. But the vendor is saying that they will be the same. Who is right? Is it possible that if their app is coded badly, even such a simple task could have higher stress on Exchange?

On Sat, 5 Jun 2010 18:37:46 +0000, Sheen1990 wrote: > > >Thanks Ed. > >Regarding #4, the application won't be able to add tasks/appts, but it will certainly be able to move messages between folders and such. The vendor is saying that the application makes RPC calls to Exchange to carry these out and that an RPC call was essentially what Outlook does. As such, their application won't have that great an effect on Exchange load - if the app is running against 20 mailboxes, it will simply be the same as an extra 20 Outlook connections. > >I am thinking that, yes, an RPC call maybe a low stress activity between Outlook and Exchange, but that is because MS coded both, and coded them both well. If the vendor's app sucks, then there could be a massive difference between an Outlook user moving a message in their mailbox to a different folder, and their application moving a message in someone's mailbox to a different folder. > >But the vendor is saying that they will be the same. > >Who is right? Is it possible that if their app is coded badly, even such a simple task could have higher stress on Exchange? Why not ask for specifics from the vendor? My guess is that they know how much RPC traffic they create for a single transaction (whatever that is). You'll know the volume of transactions and a simple multiplication will give you the answer. But RPCs alone aren't a problem. If they cause disk activity they contribute to the I/O workload on the server (a.k.a IOPS). If there are capacity problems on your server already, or the addition of the application causes the IOPS to rise dramatically, you'll see the number of RPCs waiting for completion rise. That's where you'll spot the problem. The *number* of RPCs submitted to Exchange isn't a problem until the capacity of Exchange to handle the work becomes a problem. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Well, it isn't what you asked, but the kind of god-like rights you will have to confer that application means that it can, accidentally or on purpose, wreak havoc. I hope things go well for you. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Sheen1990" wrote in message news:38ac5a24-c6d8-4450-966c-040185222628... Thanks Ed. Regarding #4, the application won't be able to add tasks/appts, but it will certainly be able to move messages between folders and such. The vendor is saying that the application makes RPC calls to Exchange to carry these out and that an RPC call was essentially what Outlook does. As such, their application won't have that great an effect on Exchange load - if the app is running against 20 mailboxes, it will simply be the same as an extra 20 Outlook connections. I am thinking that, yes, an RPC call maybe a low stress activity between Outlook and Exchange, but that is because MS coded both, and coded them both well. If the vendor's app sucks, then there could be a massive difference between an Outlook user moving a message in their mailbox to a different folder, and their application moving a message in someone's mailbox to a different folder. But the vendor is saying that they will be the same. Who is right? Is it possible that if their app is coded badly, even such a simple task could have higher stress on Exchange? Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."