As MAPI use the RPC's port, it would be easier to validate in your inventory tool the remote computers to check if is installed or not. That is a pre-req to have your CDO working. I assume you have Office 2007 or later deployed. As any program that use CDO would need it. Beginning in Exchange Server 2007 and Outlook 2007, CDO 1.2.1 will no longer be provided as a part of the install of the product. As a result, there is functionality missing that many applications depend upon. CDO 1.2.1 is a package providing access to Outlook-compatible objects through a COM-based API.
Migrate from Exchange Server 2013 to Exchange Server 2013/2016/2019. MAPI CDO (MAPI Client and Collaboration Data Objects. However, you can change it by clicking Browse and selecting another user's email address from the picker. Do I need the Exchange Server MAPI Client and CDo objects installing on the backup server or the exchange 2010 server?
Check that chart for CDO version bundle with what.
We have recently migrated to Exchange 2013 from exchange 2010 and are experiencing performance issues. Now this has not been a smooth process at all, many issues have occurred but the mailboxes and public folders have been moved. The old 2010 exchange server has not been fully uninstalled due to issues with it uninstalling (got half way through and it tried to get a script from the bin folder instead of the scripts folder where exchange originally installed it.) and may be causing the issue but I'm not sure. The server seems to be performing okay, from task manager CPU usage varies but generally sits below 20% and memory is sitting at 12GB out of 16GB, however users are complaining about the speed of their outlook, switching to calender, making changes and sending emails are all much slower than when it was on exchange 2010. I've had a Google and found this Using the performance monitor i can see RPC Requests are growing in number (currently 141475) and RPC Operations/sec ranging from 0 to 150ish with an average of 15. Now I assume this is bad? Exchange 2013 is sitting on a VM with 4 CPUs (1 core per socket), 16GB RAM system drive 44GB used 60GB total, Mailbox drive 82GB used 100GB total, Log Drive 100MB used 40GB total (Circular logging is still enabled from the migration) There is a total of 65 mailboxes. And the online defrag thing ran successfully (but took nearly 8 hours) Anyone have any suggestions I have tried everything in the above link with the exception of ExMon as I cant find it our exchanger server yet.
![Outlook 2013 mapi setup Outlook 2013 mapi setup](/uploads/1/2/5/3/125383772/454100337.jpg)
I will try it tomorrow and see what it says. Okay so we have been working with Microsoft and we appear to of come to a solution. The i ssue is down to how quickly both server and client are acknowledging packets. Applying this registry described below to both server and client fixes the issue. Start Registry Editor (Regedit.exe). Locate and then click the following registry subkey: HKEYLOCALMACHINE SYSTEM CurrentControlSet Services Tcpip Parameters Interfaces. Click each of the interface GUIDs and for IPAddress or DhcpIPAddress parameters to determine whether the interface is used for email based network traffic.
If not, skip to the next interface. For each GUID that utilises the network for email traffic add a DWORD named TcpAckFrequency and assign it a value of 1. Exit the Registry Editor. Restart Windows for this change to take effect This fixes the following issues. Changing between Mail and Calendar is slow on the first attempt but subsequent attempts are faster. Opening outlook is slow. Attaching email via right click Send to Mail recipient takes a very long time (depending on file size) to open the new mail message, outlook can become unresponsive during this time.
VBA scripts may perform very slowly, hang or no longer work when using MAPI based arguments. Items getting stuck in the Outbox for periods of time. Attaching/sending emails via Microsoft Word take a long time to open the new email window The only issue with this fix is distributing it as the GUIDs on the interfaces are unique. Someone may be able to create a script or something to achieve this.
If so please post it up here for the benefit of others. If the defrag really took that long I would start looking at Disk I/O and see if there is a bottleneck or a bad disk. Another thing you can do as a test is create a new Mailbox database on the Exchange 2013 server on another disk / volume that you know is not being overused. Migrate a few of the problem users from the existing DB to the new one (you can do this online and in operation). If the new DB fixes the issue with the users I would move half of them into this new DB and create another separate DB for the others. A secondary benefit to the migration is that the mailboxes get cleaned, defragged, and compacted during this process so it helps with a ton of performance issues.
Also defragmenting the actual drive inside of the Exchange 2013 server with a tool like Defraggler will get you some idea how much I/O you got coming off the drive in question. Report back your findings. SteveTheITDude wrote: I had some similar issues as well when moving to Exchange 2013. I had to update a few staff to Outlook 2010, and also re-do the outlook profiles on a handful of staff because they were having the same issues. Tried re-doing outlook profiles like you mentioned but it hasn't made any difference and all our clients are outlook 2010 or 2013 (both have the issue), outlook 2007 and lower inst supported with exchange 2013 so that's probably why you had the issue. Gregory H Hall wrote: If the defrag really took that long I would start looking at Disk I/O and see if there is a bottleneck or a bad disk.
Another thing you can do as a test is create a new Mailbox database on the Exchange 2013 server on another disk / volume that you know is not being overused. Migrate a few of the problem users from the existing DB to the new one (you can do this online and in operation). If the new DB fixes the issue with the users I would move half of them into this new DB and create another separate DB for the others. A secondary benefit to the migration is that the mailboxes get cleaned, defragged, and compacted during this process so it helps with a ton of performance issues.
Also defragmenting the actual drive inside of the Exchange 2013 server with a tool like Defraggler will get you some idea how much I/O you got coming off the drive in question. Report back your findings We have been looking at disk I/O and I think its within normal levels? It may be a little bit more than we would like but I cant see this causing the slow down. Users are having a good 1-3 second delay when they switch between email and calendar, opening another email is slow and sending an email can take a while too. (see below for performance monitor) I don't think the 10K SAS hard disk it self is an issue as looking at the host the average disk latency is 0.306 milliseconds and the VM averages at 4.125 milliseconds. Online Defrag ran last night and that took nearly 8 hours again. I will try a second mailbox Database but it requires me to reset the information store service so I will do this out of hours.
Do you mean to defrag the system drive or the mailbox database? I thought you're not suppose to defrag exchange databases with normal defragging tools. Brianinca wrote: Exchange 2010 and especially 2013 are designed to drastically reduce disk i/o. Unless you have some other indicators the disk subsystem is stressed, I would spend time elsewhere.
Have you confirmed everything is cool with your Autodiscover functionality? That's the thing most likely to be screwed up after a migration. Https;//testexchangeconnectivity.com should be at the top of your list to start troubleshooting this. Regards, Brian in CA I haven't really done much with the auto discovery for external connections so not sure if the web tool will work properly but trying it out now. Would the lack of external auto-discovery configuration cause these kinds of issues? I have been off for a few day but back at work now. I cannot get Exmon to work with exchange 2013, it will only show one row and the user field is blank?
Defragged the system drive and it was very fragmented but hasn't made any difference. Attempted to use eseutil of the mailbox db on the off chance that may have some fragmentation and came across another error. One I didn't want to find.
I was trying to run eseutil /d 'database path' /tc:'tempoary location' /p and it returned Operation terminated with error -1022 after 0.125 seconds. More information on that error here What I am trying to do now is figure out how the hell I am going to fix it. Restoring from a backup is not an option:(. To keep this up to date, I have now removed exchange 2010 completely (via adsi edit as we had no other choice) however the original issue is still present. Would someone with Exchange 2013 please tell me what they see on their performance monitor under 'MSexchangeIS Client' and then 'RPC requests' total. Ours in excess of 200000, which I assume is bad, but have nothing to compare this too.
Again everything I have tried has not fixed this. I ask for exchange 2013 specificly as it appears to be different to Exchange 2010 where you would only have 'MSExchangeIS'. In exchange 2013 it is broken down into many MSExchangeIS parts. Loucorriero wrote: I am very interested to hear if you have a resolution. I have had a ticket open with MS for 4 weeks for my Exchange 2007 to Exchange 2013 Migration and have many rpc/latency issues on the new servers. I also cannot use cached mode to hide the latency, so users complain wildly when directly connected.
Microsoft has gone thru every imaginable troubleshooting scenario, taken all logs, network traces, etc. I feel they are pushing me off hard since they cannot find the root cause. This is worrying and reassuring at the same time, I'm glad I'm not the only one in this boat but worried that its been with MS for 4 weeks!
We have already had Microsoft looking at this and they are equally stumped. One thing we have found with Microsoft is that testing a client on a virtual machine which is on the same physical switch and same VLAN it performs fine?! However our network overhead is minimal. We have more than enough capacity in terms of networking. There is also no restriction of communication between these VLAN's.
Does any of what I mention here apply to you to? CU6 has just come out but nothing in the change logs look like it would fix these issues. May install it just in case. Well the issue is on going or should I say issues. We have identified a few other areas that are problematic, microsoft have closed of the ticket with no resolution currently however they are offering to talk to do a telephone conference with vmware in order to help solve the issue. Below is an updated list of symptoms.
Changing between Mail and calendar is slow on the first attempt but subsequent attempts are faster. Opening outlook is slow. Attaching email via right click Send to Mail recipient takes a very long time to open the new mail message, outlook can become unresponsive during this time. VBA scripts may perform very slowly, hang or no longer work when using MAPI based arguments.
Items getting stuck in the outbox for periods of time From discussions with microsoft and some research it has come to light that exchange 2013 has had some big changes under the hood. One which is more well known is the change to MAPI, MAPI connections are no longer available and has been replaced with MAPI/HTTP but this is only available on outlook 2013. So what happens to the old MAPI based connections? Well most of them are now going over RPC/HTTP.
Microsoft are still convinved this is something network based but i found an article relating to this registry key HKLM Software Policies Microsoft Windows NT Rpc MinimumConnectionTimeout Find the article. In short it talks about how exchange 2013 focuses on RPC/HTTP but mentions about how some clients can get disconnected or TCP connections getting dropped.
I also read somewhere else that users that get messages stuck in there outbox have had issues fixed by modifying this same key. I think the default value is roughly 13 minutes (780 seconds) but the article recommends decreasing this down to 3 or even 2 minutes (120 seconds). I am going to test this out tonight and see if it helps. The second change which isn't as well known is an architectural change to exchange 2013. Originally when new messages were created using the right click send to mail recipient and from in word as well i believe, a new message would be created and the file attached.
This was all handled on the client. However with exchange 2013 in place a request is sent to the server first to check to make sure the attachment is not exceeding any quotas. This issue has recently come to light and is known by Microsoft however there is no official work around. I did find this which kind of works but only on very small files and I don't think it fixes word send as attachment function in word either. I found with larger files (2MB+) it would hang or even crash (usually 10MB+) outlook after closing/sending, but it did attach very quickly. Edited Oct 2, 2014 at 11:04 UTC. Fatmanboozer wrote: Exchange 2013 is sitting on a VM with 4 CPUs ( 1 core per socket), 16GB RAM system drive 44GB used 60GB total, Mailbox drive 82GB used 100GB total, Log Drive 100MB used 40GB total (Circular logging is still enabled from the migration) May I recommend changing this to be 4 virtual sockets / 1 core per socket. It has been discussed around these parts many times and can (and most likely will) improve server side performance.
(check out ) The other thing, is I see you state that there are 3 drives separated out OS/Mailbox/Logs but the question i have is, are they physically separated on the actual storage level, or are they all pointing to the same datastore? 3 separate.vmdk's on the same datastore is essentially the same as having exchange installed all on the same drive.