Recently a customer’s phones had stopped receiving email while their email clients on the pc’s were still working fine.  Time to investigate what’s going on!

First some simple troubleshooting, can I get to the exchange server externally using either telnet on port 25 to the companies MX record (or external facing IP address) or get access to OWA (Outlook Web Access).

Opening up a Command prompt, (from an external computer) and using the command telnet mx.record.com 25  checks that we can connect through the firewall externally, which in this case, we can and makes sense.

My bets were on OWA or IIS being the culprit.

Easy check – open up your favourite web browser and typing in the OWA address which is normally something like https://mx.record.com/owa  Hopefully if it’s all been setup correctly you shouldn’t get any certificate errors but if you do, and you know what your doing you can continue regardless since we’re just seeing if we can get to the OWA login page.

In this instance we can’t and we get an HTTP error!  My betting odds are looking good.

image

Next check is to look at a) the firewall rules – which shouldn’t have been changed anyway.  b) IIS on the server to ensure that the Default Web Site is started and accessible internally.

a) Firewall check – done, all looking good there.
b) IIS – uh oh, Default website isn’t started, this would be the cause of the error and why phones aren’t receiving email.

Simple, just start the Default Web Site….. but no, life isn’t that simple and I receive the following error:

image

So now we need to find out what process is using either port 443 or 80.

A quick command will show you:
netstat -aon | find “:80”
netstat -aon | find “:443”

image

We’re specifically looking at 0.0.0.0:80 and 0.0.0.0:443 Here we can see that PID 4 is using port 443 and PID 20508 is using port 80
Opening up Task manager we can see what processes come under that PID

image

PID 4 – Was the System, this is standard.  However PID 20508 was attached to a process called DevManBE.exe by Right clicking this and opening the file location I found that it was the HP power Manager using this port.

image

By opening this application and reconfiguring it to another port, IIS was then able to start and all was well again.

Hope this gets you out of a sticky Quibble.