If I had any hair left, I would be pulling it out right now. I can’t seem to figure out why my Outlook 2007 keeps disconnecting from Exchange 2007 running on Windows Server 2008 every 10 seconds. I didn't have any connection problems until I injected 700MB pst file in to a users mailbox (cached mode) So here is the scenario: Server: Windows 2008 x64 with Exchange 2007 Enterprise (Virtual on ESXi 4.1 Server) 192.168.30.5 Client: Windows Ultimate x86 with Outlook 2007 192.168.20.107 As soon as I imported the PST file in to outlook I started getting Event IDs 9646 on the server Mapi session "/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=tom" exceeded the maximum of 32 objects of type "session". Increasing the limit in the Registry to 512 didn't fix the connection problem, but took care of the event 9646 on the server. Clearing Download shared folders (excludes mail folders) in outlook on the client pc didn't fix the problem. Event id 26 gets logged on the client every 10 sec Connection to Microsoft Exchange has been lost. Outlook will restore the connection when possible. then Connection to Microsoft Exchange has been restored. Client is located at the remote location with a hardware VPN between locations (Linksys RV082 & RV042) Symantec EndPoint Protection is installed on the client, but shutting it down does not make any difference. This is not a network problem, as I can copy 300MB file from the client to the server and back without any problems. Client is connected to a Linksys SRW2008 switch. I spanned its port and captured outlook traffic using another computer (promiscuise mode) Looking at the trace, I am seeing ACKs packets to the server from the client, but no SYN ACKs back Can anyone spot where the problem is in this trace? P.S. Also new emails are coming in and going out while disconnects are happening. What’s causing the disconnects are outlooks attempts to sync its Mailbox with the server. Why it’s happening is still a question. Click here to download Trace File Thanks asked 26 Oct '10, 07:00  net_tech edited 26 Oct '10, 08:04 |
One Answer:
Copying files via (Explorer/CIFS?) doesn't necessarily rule out a network issue. Different apps behave differently when packet fragmentation has to occur. The question I have is what is the MTU between the to path? For some reason, someone is not honoring the do-not-fragment bit in the packets (lot of devices do this, including Cisco routers). The MTU from 30.5 to 20.107 seems to be limited as can be seen in packet #59. Although previous smaller packets (with DF bit set) makes it across, this packet does not). Presumably, it too had the DF bit set, so we can reasonably assume that someone is munging it. Also, in pkt #1012, you can see that the fragment goes missing causing the communication to go "wonky" Notice that ip.id= == 30384 in 1012 doesn't have a corresponding fragment. So this fragment and the next two packets went missing for some reason. The next packet has ip.id==30386 (two fragmented packets that make up the first original packet). So someone ate the fragment for ip.id==30384 and the two packets that make up id 30385. Ensure someone isn't ACL'ing ICMP messages. Especially ICMP type 3, code 4 (fragmentation required but DF bit set) which is critical for path mtu discovery process. Good luck Hansang PS: in the future, give us quick ascii layout of the land. What IP represents the server/client, where the capture was taken etc. Although it can be figured out by looking at the traces, it's a hinderance and folks may not take the time to review the trace files. answered 01 Nov '10, 16:04  hansangb edited 01 Nov '10, 16:09 Thanks Hansang! You are 100% right on the money. The problem was in the transport layer with MTU. All application error messages were misleading. Server side router had MTU set to 1500, client side was set to 1492. Changing server side router to 1492 fixed the problem. (big thanks to Laura & SYNbit) I didn't get anywhere in this thread, so started another one http://ask.wireshark.org/questions/748/wireshark-placement-question (01 Nov '10, 19:01) net_tech |
As I live in the world of packets, I focused in on your sentence regarding the trace file.
You see ACKs, but no SYN ACKs back...
The SYN/ACK would be seen only in the handshake process - we'd expect to see SYN, SYN/ACK, ACK for the 3-way TCP handshake.
Since you see a MAPI error message, consider checking out http://support.microsoft.com/kb/842022 which lists possible causes for this issue. Seems to point to an application issue.
Consider looking at the line about adding a large additional mailbox to a profile.
You might ask over in one of the Exchange/Outlook forums as well.
Hi Laura and thank you for your response.
I posted this problem in Exchange forum, but got no help so that's why I am here. I spent some time on Microsoft site and saw the article you mentioned 842022.
As I said in my original post "Clearing Download shared folders (excludes mail folders) in outlook on the client pc didn't fix the problem"
Also if I fire up a 2003 exchange server on the same virtual hardware and don't make any other changes the problem does not exist.
I don’t think I knew what I was talking about. (ACKs, but no SYN ACKs back) So please let me rephrase. 47 sec in to the trace (packet 2898), Vista Client sends an ACK to the server with a Sequence # 10552. 4 packets come back from the server, client send another ACK with the same sequence number (10552) another 4 packets come back. This process repeats 9 times then finally client sends another ACK with the same sequence # (Packet 2941) but this time wiresharks marks it as a DUP ACK for packet 2937 then I see another 34 DUP ACK packets for 2937 and then client gives up and sends a RST, ACK
just taking another guess here, but DUP ACKs seem to be a result of torn down MAPI session which was requested in packet 2777 by the client and acknowledged by the server in 2778
can anyone comment on that?