So... the user received my test email ...
I think the order of checks if you have problems with iPhone and ActiveSync on Exchange:
1) Check the ActiveSync is working using Microsoft's Online Test Tool
2) Switch on Proactive Scanning and Background Scanning in MSExchangeIS\VirusScan.
3) Check timeout values on all routers under your power. If possible, make the value greater than the MaxHeartbeatInterval registry setting in Exchange. (See previous post). (If not possible, perhaps make the Exchange MaxHeartbeatInterval just lower than the router timeout?)
No doubt he'll update to iOS4.1 soon and we'll get yet another problem...
Showing posts with label ActiveSync. Show all posts
Showing posts with label ActiveSync. Show all posts
Friday, 15 October 2010
Wednesday, 13 October 2010
iPhone and ActiveSync: Antivirus Proactive Scanning
And now I don't just have intermittent scanning... Now it only gets emails when the user opens Outlook...
Something has been cleared up by setting the router timeout to a larger value...
And opening Outlook causes the Antivirus to kick in on the messages. Exchange won't do anything with the messages until they have been scanned.. and they won't be scanned without being accessed first.
Checking the registry for the VirusScan settings...
HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan
The ProactiveScanning should read 1 - BackgroundScanning should read 1... then change ReloadNow to 1 .. and MSExchangeIS will reload... wait a little bit and press F5... ReloadNow will have been changed back to 0.
Now let's see if this works... Finally... (Combined with the timeouts in my last post)
Something has been cleared up by setting the router timeout to a larger value...
And opening Outlook causes the Antivirus to kick in on the messages. Exchange won't do anything with the messages until they have been scanned.. and they won't be scanned without being accessed first.
Checking the registry for the VirusScan settings...
HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan
The ProactiveScanning should read 1 - BackgroundScanning should read 1... then change ReloadNow to 1 .. and MSExchangeIS will reload... wait a little bit and press F5... ReloadNow will have been changed back to 0.
Now let's see if this works... Finally... (Combined with the timeouts in my last post)
Tuesday, 12 October 2010
iPhone and Exchange ActiveSync: Heartbeats
In an earlier post I mentioned there are two Heartbeat settings Min and Max:
- MinHeartbeatInterval - Dword - Decimal 60 (seconds)
- MaxHeartbeatInterval - Dword - Decimal 2700 (seconds)
- HbiSampleSize - Dword - Decimal 200 (samples)
- HbiAlertThreshold - Dword - Decimal 480 (seconds)
My Vigor 2900 router HTTP TCP SYN setting was 900 seconds. But clearly if the maximum Interval can be 2700 seconds (45 minutes), then it is going to fail...? Should I set the router's TCP SYN setting to 2700 seconds?
Ok... at the end of the Heartbeat period... the EXCHANGE server replies to the PHONE with a 200 OK message. This should force the iPhone to send another ping with a new (but more than likely same) heartbeat value.
What if the iPhone does not receive this 200 OK message. Perhaps the signal has dropped in a tunnel, for example? TCP/IP is best effort after all... that is the last message required of the Exchange Server.
The iPhone should assume that the period is up... and resend a new Ping anyway when it can? No? Right.. sort of .. the iPhone also calculates the best Heartbeat based on it's history of connections to the Exchange server.
So what if ... I am in the office... and my phone connects up... iPhone can create a longer and longer heartbeat period, up to 45 minutes (2700s)... and then I leave the office... and now the iPhone is not only waiting 2700s for the 200 OK... the phone has disconnected... the server tries to contact the iPhone in the office... nothing happens.. there must be confusion when switching between WiFi and OTA (over the air) ...
But also the HeartBeat period is continuously being cut off by the Router - set to 900s (15 mins)... So how long will it take before the iPhone's connection algorithm chooses a Heartbeat Interval that is smaller than the shortest timeout along the route to the server? Does it say... ok nothing back in 2700s .. lets try 2640s... lets try 2580s .. lets try 2520s ... and so on... which could take more than 6 hours! until finally reaches the correct value.... or does drop back to 60s then increase until it finds the best timeout value?
If for 6 hours or more... the timeout is greater than the value of the router timeout, then if emails arrive in the inbox after 15 minutes.. the server cannot tell you... because the router has shut the session... and the iPhone won't ask until the Heartbeat is up...
There'll just be the assumption for the iPhone that no emails arrived... and perhaps the Exchange server will just shrug and say, "well, I sent you the emails... don't look at me..."
I'm going to up the router to bigger than 2700s...
iPhone and Exchange ActiveSync: still problems - Heartbeats
ok.. well the one user who had problems has upgraded to iOS 4.0.2 (Apple-iPhone2C1/802.117) and now he has intermittent issues again... (with MS Exchange 2003 SP2)
So time to dig deeper... and the frustration has grown... when you think you have fixed it all and no-one calls for weeks on end... And then it's the same problem yet again... Time to dig even deeper...
HBISampleSize / Heartbeat Intervals
PHONE -> EXCHANGE SERVER - the phone opens a session (connection) with the server, nudges it and gives the server the heartbeat length...
The phone will hold OPEN that session for the length of the heartbeat... and IF you get an email, the Exchange server will use the session to send the email to your phone. IF no emails arrive, the phone will poll the Exchange server again... (not sure if that is immediately or not - or what if not successful? if no signal - does it try?)
If you have a router or firewall between the PHONE and the Exchange server... like your office ISP router... or home router - WiFi... or you are connecting over WiFi in a cafe... and the Firewall/Router times out the HTTP(S) session because it is set to a maximum of 5 minutes not 30 minutes ... (Heartbest could be 15 mins so 30 mins is a safe value) or your WiFi signal gets low and drops, killing the session ... then that session will be lost ... IF Exchange receives an email, then it cannot open a new session to your iPhone to send the emails... it must wait for your iPhone to poll the server again....
So it is vital to check all points along the connection from your iPhone to your Exchange server. We really hope here that there aren't routers along the way at our Phone provider or other third-party, with HTTP(S) timeout values that are "almost 15 minutes"... we'll assume here, first, that if we're having problems then it is under our control (or our IT department)... (Having checked all our hops thoroughly, then we can pester the people responsible for the bits we don't have any control over.)
It's not true PUSH... no... but true push is not simple enough for the average iPhone user to set-up and maintain. And it's really time-consuming if you have 30 phones on different networks ...
I'm going off to investigate time-out values again on the Vigor 2900...
What determines the Heartbeat on the iPhone? Does it get the value from Exchange? I'll let you know in my next post.
So time to dig deeper... and the frustration has grown... when you think you have fixed it all and no-one calls for weeks on end... And then it's the same problem yet again... Time to dig even deeper...
HBISampleSize / Heartbeat Intervals
PHONE -> EXCHANGE SERVER - the phone opens a session (connection) with the server, nudges it and gives the server the heartbeat length...
The phone will hold OPEN that session for the length of the heartbeat... and IF you get an email, the Exchange server will use the session to send the email to your phone. IF no emails arrive, the phone will poll the Exchange server again... (not sure if that is immediately or not - or what if not successful? if no signal - does it try?)
If you have a router or firewall between the PHONE and the Exchange server... like your office ISP router... or home router - WiFi... or you are connecting over WiFi in a cafe... and the Firewall/Router times out the HTTP(S) session because it is set to a maximum of 5 minutes not 30 minutes ... (Heartbest could be 15 mins so 30 mins is a safe value) or your WiFi signal gets low and drops, killing the session ... then that session will be lost ... IF Exchange receives an email, then it cannot open a new session to your iPhone to send the emails... it must wait for your iPhone to poll the server again....
So it is vital to check all points along the connection from your iPhone to your Exchange server. We really hope here that there aren't routers along the way at our Phone provider or other third-party, with HTTP(S) timeout values that are "almost 15 minutes"... we'll assume here, first, that if we're having problems then it is under our control (or our IT department)... (Having checked all our hops thoroughly, then we can pester the people responsible for the bits we don't have any control over.)
It's not true PUSH... no... but true push is not simple enough for the average iPhone user to set-up and maintain. And it's really time-consuming if you have 30 phones on different networks ...
I'm going off to investigate time-out values again on the Vigor 2900...
What determines the Heartbeat on the iPhone? Does it get the value from Exchange? I'll let you know in my next post.
Friday, 30 April 2010
iPhone and Exchange ActiveSync: Router Timeout - cracked it?
The Draytek Vigor 2910 has now had its firmware upgraded to the latest version.
The portmaptime function is now available. Running 'portmaptime -l' to list the timeout values shows TCP SYN as 60 seconds... well below the recommended 540 seconds for ActiveSync.
I have set it, according to some users, to 900: 'portmaptime -s 900' (s for 'tcp Syn')
The iPhone user reports that whatever change I made, appears to have cracked it... I told him I'm going to wait a couple of weeks before I start celebrating... :)
The portmaptime function is now available. Running 'portmaptime -l' to list the timeout values shows TCP SYN as 60 seconds... well below the recommended 540 seconds for ActiveSync.
I have set it, according to some users, to 900: 'portmaptime -s 900' (s for 'tcp Syn')
The iPhone user reports that whatever change I made, appears to have cracked it... I told him I'm going to wait a couple of weeks before I start celebrating... :)
Monday, 26 April 2010
iPhone and Exchange ActiveSync: not yet solved - router update
Following all the links in the chain...
iPhone -- Router NAT -- (Routing and Remote Access Firewall) -- ActiveSync -- Exchange
Error 3033 for ActiveSync suggested checking the router HTTP(S) timeout. The router is a Draytek Vigor 2900. There appeared to be no way to alter the HTTP(S) timeout. I have since been told that there is a command I can run...
Portmaptime -s will alter the TCP SYN Timeout value. From the Draytek forums it appears that this command should work on the 2800 Series (2820) and other Vigor routers too.
Microsoft recommend a value of 900 seconds. But there's still no guarantee that upgrading the router firmware and altering the timeout is going to resolve the iPhone<->Exchange problem altogether. Have to wait and see.
iPhone -- Router NAT -- (Routing and Remote Access Firewall) -- ActiveSync -- Exchange
Error 3033 for ActiveSync suggested checking the router HTTP(S) timeout. The router is a Draytek Vigor 2900. There appeared to be no way to alter the HTTP(S) timeout. I have since been told that there is a command I can run...
portmaptime -s 900So I telnetted into the router... type ? for help... the command is not listed... I had a look at the commands whilst I was there... nothing... firmware is 3.1.2 ... the service tech tells me that the portmaptime command was introduced in a later firmware.
Portmaptime -s will alter the TCP SYN Timeout value. From the Draytek forums it appears that this command should work on the 2800 Series (2820) and other Vigor routers too.
Microsoft recommend a value of 900 seconds. But there's still no guarantee that upgrading the router firmware and altering the timeout is going to resolve the iPhone<->Exchange problem altogether. Have to wait and see.
Wednesday, 21 April 2010
Exchange ActiveSync and iPhone: Messages stopped again
Client reports that ActiveSync has stopped working yet again... checked PoolMon for Non-paged Pool and it's fine...
There's an event in the Application Log for ActiveSync - ID 3033.
Following this article:
http://support.microsoft.com/kb/905013/en-us
I checked the suggested registry key...
There's an event in the Application Log for ActiveSync - ID 3033.
Following this article:
http://support.microsoft.com/kb/905013/en-us
I checked the suggested registry key...
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MasSync\ParametersAnd all four DWORDs are missing... I have set them to:
- MinHeartbeatInterval - Dword - Decimal 60 (seconds)
- MaxHeartbeatInterval - Dword - Decimal 2700 (seconds)
- HbiSampleSize - Dword - Decimal 200 (samples)
- HbiAlertThreshold - Dword - Decimal 480 (seconds)
It suggests changing the HTTP(S) timeout values on the router firewall but I can't find them... so I'm going to do a simple IISRESET and see if that resolves the problem. Trouble is, an IISRESET might just resolve the issue, despite the new registry entries... so I can only warn the client that's a possibility... (when he returns)...
If that doesn't resolve the issue for now... back to the drawing board...
Friday, 26 March 2010
iPhone and Exchange ActiveSync: not solved - reoccurred
So I got a call that the iPhone stopped getting emails... I didn't check till they went home in case I needed to restart their server out-of-hours ...
When I did connect I decided to run MS Exchange Best Practices Analyser... (search on ExBPA).
I knew one of the Best Practices was having an Application Log size in Event Viewer of 40Mb - so I decided to alter that myself first whilst I was waiting... I must have dozed off at that point ... suddenly I was disconnected... RealVNC was suggesting I was connected - it wasn't asking for my username and password - but my connection was getting refused by the server - 'Read/state - Connection disconnected by peer (10054)'
Somewhere I read that 10054 'read/state' might mean that the Application log size was too small and so the server could not accept connections... that was close? Did I type 40kb? I couldn't connect via VNC... but I couldn't connect either via VPN... could that cause that too?
I had to wait until the morning and catch the first person into the office... when I called they said they couldn't log in either... they could log into the server terminal... a quick look at the System log revealed srv errors related to non-paged pool memory.... I got them to reboot so we could all log in ...
When non-paged memory has only 20Mb left then Windows shuts all connections down... IIS6, HTTP.SYS, users are logged out, VPN connections shut down, RealVNC connections... and so on... it does that to prevent resources becoming so low that the system crashes... you are forced to log into the server and sort it out.
David Wang's HowTo post helped point me to Poolmon.exe - a tool that monitors which components are using Paged and Non-Paged memory... Poolmon.exe is one of the Windows Support Tools and can be downloaded from Microsoft.
Once installed, open a cmd window and type: poolmon -b to list by bytes - which is the column to watch...
Because my client's server has just booted this will just tell me initial values... so I am saving to a file: poolmon -b -n datetime.txt. Then I'll import the file into Excel and time stamp each row. I'll run poolmon every now and again and see which values are changing and which aren't.
So far I've got several culprits:
- Irp - - Io, IRP packets
- File - - File objects
- AvgU - an AVG component
- Ntfr - ntfs.sys - ERESOURCE (not to be confused with NtfR)
- MmCa - nt!mm - Mm control areas for mapped files
the largest riser is AvgU, followed by File. That's not surprising considering everyone had been logging in and were now accessing their files...
An hour later:
- FMsl - - fltmgr.sys - STREAM_LIST_CTRL structure
- File - - File objects
- AvgA - an AVG component
- AvgU - an AVG component
- Ntfr - ntfs.sys - ERESOURCE
- MmCa - nt!mm - Mm control areas for mapped files
My bet is that AVG is going to be the culprit... I will stop working on this now. Later I will take one more reading, but I may just remove AVG and install the correct server version - this version looks different to the other servers that I get to look at.
Friday, 19 March 2010
Exchange ActiveSync and the iPhone: Problems Connecting (solved)
I think I have just about tried every trick in the book to get these iPhones connected to my client's SBS 2003 server... from deleting the Virtual Servers in Exchange Admin, removing them from the IIS MetaBase, DS2MB and letting SBS recreate them, checking through all the authentication and access settings, testing SSL, check User-level ActiveSync settings/Outlook Mobile Access and Global-level ActiveSync/OMA settings...
Up for a breather... and ... every time I ran IISRESET it would hang on HTTP SSL service - HTTP Filter.. so then there's no way that IISADMIN would restart... and then IIS is down because W3SVC won't come back up... so it meant a reboot every time...
[One of the problems on the SBS was that 2 updates had failed... .NET 2.0 SP2 (KB976569) was failing over and over - it appeared to take hours (14 hours - I tried to cancel the update and reboot the server - I should have made sure the Update was stopped before rebooting - since I was working on a server 200 miles away I had to wait till the client came in to find the server stuck on shutdown before I could get access again.) - after some investigation into the log files I found it failed because IISADMIN did not restart when asked. The other update was an Intelligent Message Filter for Exchange 2003 SP2 update from Feb 2010 (KB907747). Neither told me why they failed. Both failed due to IISADMIN not restarting (due to HTTP SSL not stopping)... I had to disable IISADMIN, reboot, install the updates, re-enable IISADMIN, reboot. And try to figure out why HTTP SSL was not stopping in a timely fashion.]
So my main focus became digging around in IIS... making sure the OWA and OMA applications in Default Website were attached to the correct ApplicationPool, ExchangeApplicationPool or the ExchangeMobile one...
Errors 3005 3007 for ActiveSync... really just tell me something's up... maybe a timeout... maybe the server is overloaded... but for a big server like that with a handful of users ... hardly likely... must be a setting somewhere... Number of concurrent connections .. in Performance on Default Website properties... that did something.
Check the log files under C:\Windows\System32\LogFiles\HTTPerr and ..\W3SVC1 - go to the end of each file and look for PROPFIND and POST and GET statements from ActiveSync... go to the end of each line and check if you get 409, 207, 403 ... if you're not getting a nice round number like 200, 400 etc then something's up... and it's another pointer in some direction...
You can view which devices have connected by connecting and visiting (using any browser):
https://mail.mydomain.com/exchange//NON_IPM_SUBTREE/Microsoft-Server-ActiveSync
Having fixed a few glitches here and there... and having been up all night and day... mostly waiting for reboots... something was holding HTTP open... and slowing this process down.. people don't reboot every time they make a change to IIS? duh....
I started to run combinations of the installed programs through Google... and there .. lo and behold ...
Antivirus... AVG ... You should not install AVG Online Shield, AVG Firewall and Email Scanner on a Windows Server running Exchange (and definitely not Exchange ActiveSync)
The Online Shield scans HTTP, HTTPS traffic - it has a hook into the HTTP SSL/HTTP Filter service ... and was not specified as a DependsOnService (or vice versa...) so there's no call to it to stop and start... HTTP SSL sits and waits for AVG Online Shield to stop using it for AVG to stop ... but that won't happen...
Avg Email Scanner just adds another layer around POP3 and SMTP ... with it scanning ports 25 and 110 on a machine with Exchange running... adds another layer in the timeout values possibly...
Once Online Shield and Email Scanner were switched off ... IISRESET worked without rebooting .. what a joy I did it several times over and over ...
An hour or two later the client texted me to say his iPhone was getting emails ... marvellous...
These websites were helpful:
Henrik Walther's in-depth Chapter 5 from his book "Securing Exchange Server 2003 & Outlook Web Access" - perfect for understanding the nitty-gritty bits of Exchange HTTP Virtual Folders etc...
AVG - What AVG components are not designed for server operating systems?
Microsoft's Exchange ActiveSync Test Website:
Microsoft Exchange ActiveSync Administration Tool ... a tool that you can use to delete old devices from ActiveSync Administration Tool... I should let my client know about it since his old iPhone that he replaced in December is still in the system.
Microsoft Exchange ActiveSync Certificate-Based Authentication Tool:
GoDaddy SSL Certificates - works well with most PDAs, iPhone, Windows Mobile, Android and Exchange ActiveSync - also quite cheap at the moment for secure authentication...
If anyone still needs help ... leave a comment...
Subscribe to:
Posts (Atom)