Showing posts with label Vigor 2900. Show all posts
Showing posts with label Vigor 2900. Show all posts

Sunday, 14 November 2010

SBS2008 and the mysterious DNS drops: Resolved

I finally managed to get onto the router... a Draytek Vigor 2900... I looked through all the settings and found nothing timing out.

Looking through the Ethernet log... I could see one PC calling up numerous destinations on the internet, TCP/UDP port 16650 and destination in the 50,000s... 57874.?

I found out the PC name on the network and connected via Explorer to the admin share to look at Program Files and see if there were any nefarious software installed... 

BitTorrent... oh dear... Dates of the files appear to match the times of the DNS dropping out.

I was called at the time, their DNS has been down for 2 hours whilst I was investigating.  So I blocked all traffic from that PC's IP address to the internet.  Immediately I could browse to www.google.com on the server.

My colleague gets a call from one member of staff... everyone's internet has come back except hers... he let her know we'd look into it...

So I blocked all traffic up from 1024 to 65535 from that IP address... at least she'll get mail, DNS, web surfing... but I think she might have a few more problems... downloading large files on company ISP.. killing an online application used by others that is the vital for the company... furthermore the size of the files over only 25 days could have had their ISP block all further traffic... Business Usage Policies n all that...

The router was still showing DNS calls to the internet... the Forwards were working.. but because of all the heavy torrent traffic, all DNS calls were timing out.  The DNS Forwarding has a timeout of 3 or 5 seconds.

BitTorrent is known to kill a connection when it's not been limited in the torrent app... 

So restarting the DNS Server on the SBS2008 box was simply killing the torrent connection and then it would all start going again .. and perhaps the only reason it's starting getting worse is because the user's PC was set to go directly via the router?  SBS2008 was limiting the Torrent connections.. once it was out of the picture the torrent was allowed to keep the connection killed and restarting the DNS Server no longer had a lasting effect.

Staff should be kept aware of the company's internet policy... and some should know better.

The answer is always so simple in retrospect.

Friday, 15 October 2010

iPhone and ActiveSync: Message received

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...

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)

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.

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 900
So 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.