We found a couple of the Kemp settings that needed to be changed. We made the IIS changes to the servers, but will not be able to do the IIS reset until scheduled maintenance next week.
I'll update you when we have an answer about if these changes helped. Thanks much for the input. Robert On Sat, Dec 27, 2014 at 5:05 AM, ccollins9 <[email protected]> wrote: > We also decreased the overall HTTP connection time-out on the CAS servers > > Increase the Http Connection Time-Out > > > > 1. Right-click the Default Web Site > > 2. Select Manage Web Site > Advanced Settings… > > 3. Under the Behavior section, expand the Connection Limits > > 4. Set the Connection Time-Out (seconds) to 300 > > 5. Click OK > > 6. Do an IISReset > > > On Sat, Dec 27, 2014 at 5:02 AM, ccollins9 <[email protected]> wrote: >> >> We also recently migrated to EX2013 and have Kemp LoadBlancers in front of >> the CAS servers. We had several issues with iPhones including sporadic push >> email failures and battery drain. There were a few things we had to setup on >> the Kemp and in IIS to iron them all out. >> >> One was Idle Connection Timeout. The trick is to make sure the timeout is >> GREATER on the Kemp than it is in IIS (it isn't by default). The suggestion >> to me was to make IIS 15 minutes and make sure the Kemp is greater. In the >> Kemp, the Idle Connection Timeout is under the Virtual Service, I think the >> default is 660 and we set it to 1800 (30 minutes). >> >> >> The key on the CAS server was: >> >> HKLM\SYSTEM\CurrentControlSet\Services\tcpip\Parameters >> >> · In the right hand pane, look for the KeepAliveTime entry >> >> o If you do not see a KeepAliveTime entry, that means your CAS server >> is set to use the default of 2 hours. >> >> · If the KeepAliveTime entry is not present, you should add it >> with a value of 900,000 (15 minutes) >> >> >> >> Name: KeepAliveTime >> >> Type: DWORD >> >> Data: 900,000 (decimal) >> >> http://technet.microsoft.com/en-us/library/dd349797%28v=WS.10%29.aspx >> >> >> The battery issue was due to a Global setting on the Kemp that we disabled >> called "Enable TCP Keepalives". This is found under "Network Configuration" >> on the Kemp. >> >> >> Hope this helps! >> >> >> >> On Fri, Dec 26, 2014 at 12:35 PM, Guyer, Don <[email protected]> wrote: >> > >> > I’d like to see this too…If this were the case, our HD ticketing system >> > would be full of nothing else but phones... >> > >> > >> > >> > Regards, >> > >> > >> > >> > Don Guyer >> > >> > >> > >> > >> > >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of Candee >> > Sent: Tuesday, December 23, 2014 7:50 AM >> > To: [email protected] >> > Subject: Re: [Exchange] Ex2013 - iPhone Connectivity Issues >> > >> > >> > >> > Hi Jonathan, >> > >> > I had not heard about the authentication issue - do you have a link? >> > I would like to see if it has anything to do with the problems we've >> > been having. >> > >> > Thanks, >> > >> > Candee >> > >> > >> > >> > On Tue, Dec 23, 2014 at 7:24 AM, Jonathan Raper <[email protected]> >> > wrote: >> > >> > Robert- first off my thought here has to do with wireless authentication >> > on the iPhone. My understanding is that if an iPhone is connected to a >> > wireless network that requires authentication (not a pre-shared key, but >> > actual username/password, or even just an acknowledgement page, such as >> > from >> > Cisco lobby ambassador) that the phone will de-auth every time it goes to >> > sleep (same is true of iPad, or any iOS device). This is a feature designed >> > by Apple....and would cause the behavior you are describing. I have seen it >> > cause some constrrnation with an iphone user of mine when we started >> > locking >> > down our network. >> > >> > >> > >> > Second thought is that there is a list of ActiveSync implementation >> > issues as long as my arm (not kidding), which could cause any number of >> > issues (granted, it only focuses on 29007pm & 290102, but still....sheesh! >> > - >> > url is below). This is probably one of the driving factors of why Microsoft >> > recently bought Accompli....they were tired of everyone screwing up >> > ActiveSync. >> > >> > >> > >> > http://support.microsoft.com/kb/2563324 >> > >> > >> > >> > >> > http://blogs.microsoft.com/blog/2014/12/01/microsoft-acquires-acompli-provider-innovative-mobile-email-apps/ >> > >> > >> > >> > Not sure what else, but that's my first two guesses. Good luck and let >> > us know what you find! >> > >> > >> > >> > >> > >> > Jonathan >> > >> > >> > >> > Sent from my Verizon Wireless 4G LTE smartphone >> > >> > >> > >> > -------- Original message -------- >> > >> > From: Robert Cato >> > >> > Date:12/23/2014 6:39 AM (GMT-05:00) >> > >> > To: exchange >> > >> > Subject: [Exchange] Ex2013 - iPhone Connectivity Issues >> > >> > >> > >> > We recently upgraded to Ex2013 (CU6) from Ex2007. The new environment >> > includes Kemp hardware load balancers sitting in front of two physical >> > servers that have both CAS and mailbox roles. There is a DAG, with >> > databases split between the two servers. >> > >> > We have several reports of users not getting emails. The users will >> > get a flood of emails after manually opening the mail app (even though >> > they are configured for push) or sometimes they have to hard reboot >> > the phone. >> > >> > I have seen it first hand on my phone. I tried turning off wifi, >> > toggling airplane mode. Nothing worked until I rebooted the phone. >> > >> > For the most part messages get delivered to phones, but there are too >> > many reports of the issue to ignore. >> > >> > Appreciate any insight on how to troubleshoot this issue. >> > >> > Thanks, >> > Robert >> > >> > >> > >> > ________________________________ >> > >> > Note: This message and any attachments is intended solely for the use of >> > the individual or entity to which it is addressed and may contain >> > information that is non-public, proprietary, legally privileged, >> > confidential, and/or exempt from disclosure. If you are not the intended >> > recipient, you are hereby notified that any use, dissemination, >> > distribution, or copying of this communication is strictly prohibited. If >> > you have received this communication in error, please notify the original >> > sender immediately by telephone or return email and destroy or delete this >> > message along with any attachments immediately. >> > >> > >> > >> > >> > Confidentiality Notice: >> > This e-mail, including any attachments is the property of Trinity Health >> > and is intended for the sole use of the intended recipient(s). It may >> > contain information that is privileged and confidential. Any unauthorized >> > review, use, disclosure, or distribution is prohibited. If you are not the >> > intended recipient, please delete this message, and reply to the sender >> > regarding the error in a separate email. > >
