We've been having some issues with 2010 IMAP (SP1). In production we have 3 physical machines, all are Dell R610's with 48GB RAM and 2 sockets/8 cores each running ESX 4i. Each host has 1 (total of 3) 64-bit 2008 EE VM's with 4 vCPU's and 12 GB RAM running CAS & HT roles. Additionally, each host has 1 (total of 3) 64-bit 2008 EE VM's with 4 vCPU's and 32GB RAM running mailbox roles. Total of 9 mailbox stores, 3 on each mailbox VM's.
Our 2003 environment is still operational as we're still migrating users to 2010. Some of the users going through the 2010 IMAP instance have 2003 mailboxes; in fact, most of the Faculty are still homeMDB'd on 2003. Sitting in front of the CAS machines are a pair of F5 LTM's (10.x software) that host the IMAP 993 instance, we don't support customer facing non-SSL IMAP (port 143). I configured the F5 virtuals based on F5's Exchange 2010 design guide and they're really quite basic. The pool behind the F5 virtual points to port 143 on each of the CAS systems. SSL certificate is installed on the F5 and attached to the 993 IMAP virtual. We essentially support any IMAP client but the majority of them are Apple clients and mobile devices that don't support ActiveSync. I also know a good amount of Faculty run Thunderbird remotely. The IMAP4 process on any of the CAS systems will run using 600MB or so RAM but will rise to perhaps 1.1-1.2GB resident size. We have monitors in place to watch the banner string returned by port 143 on each of the CAS hosts as well as 993 on the F5 interface. At times we receive alerts with no banner string returned by 143 on one or more of the CAS hosts and when I manually telnet to that port it connects but receive no banner. If I leave that telnet connection open sometimes it will eventually return the IMAP banner and sometimes it just times out. Sometimes it appears to "recover" itself yet at other times we have to restart the IMAP service to kick it into working again. One of our other admins has noticed that this seems to happen when the size of the process reaches a larger resident size, somewhere in the 1.2GB range. No proof on that though, just an observation. There's no apparent rhyme or reason as to when or why this happens, could be 1:00 in the afternoon or 2:00 in the morning. We had this problem with the RTM version and it was causing so many problems we moved the IMAP DNS name back to the 2003 front-ends. I ran the Exchange load generator against 2010's IMAP after we installed SP1 and never had an issue. Now it's back. Prior to SP1 we phoned Microsoft when this was occurring and they had me watch the process for any crash information. As I told them, it never actually "crashed", it simply stopped processing client requests and sometimes would recover, and other times would not. Since it was not a "production down emergency" they wanted us to pay for escalation to perform root cause analysis. At the time we were receiving intense pressure from Faculty to make it stable which is why we pointed the IMAP DNS name back to the 2003 F5 front-end interface. Exchange 2003 IMAP has no issues. Anyone have any thoughts? We're sort of at our wits end with this and I don't believe a new call to MS will yield better results. Darren Young Systems & Security Architect Computing Services University of Chicago Booth School of Business 5807 South Woodlawn Avenue Chicago, IL 60637 Voice 773.702.0331 | Fax 773.702.0233 --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe exchangelist
