Exchange 2003 Activesync HTTP 500 Error

Further to my Exchange 2003 / Activesync Troubleshooting Guide which can be found here, I was working remotely on a Windows 2003 Server with Exchange 2003 SP2 installed over the weekend having been asked to try and make Activesync work as they had read through my guide and not managed to get everything working properly.

Initially the server needed to have it’s DNS configuration fixed so that the server could talk to the Internet and allow me access, so once their IT department had resolved that issue I was given credentials and started to look at the problems on the server.

Checking the settings against my article, everything appeared to be set properly, but the test on the test site was throwing HTTP 500 errors (my least favourite!), so I followed Method 2 of KB883380 (remove and re-create the Exchange IIS Virtual Directories) and once they had been recreated and the IIS settings re-checked, I re-ran the test on the test site and still received the HTTP 500 error.  At that point I was debating a call to Microsoft, but started to check the Event logs on the server and saw various DNS related errors which were of some concern.

Outlook 2007 was also installed on the Exchange 2003 server, so I wasn’t convinced that I had a simple fix on my hands.

I ran the Exchange 2003 Best Practises Analyzer tool and that reported that Exchange could not be contacted, which suggested a DNS issue.  In the DNS logs there was an Event ID 800 error:

The zone <zone> is configured to accept updates but the A record for the primary server in the zone’s SOA record is not available on this DNS server. This may indicate a configuration problem. If the address of the primary server for the zone cannot be resolved DNS clients will be unable to locate a server to accept updates for this zone. This will cause DNS clients to be unable to perform DNS updates.

The suggested fix for this was to run dcdiag /fix followed by netdiag /fix and then to restart the Netlogon Service.  I did this but nothing changed.

Running the netdiag /fix threw up the following error:

DNS Error code: DNS_ERROR_RCODE_SERVER_FAILURE [FATAL] Failed to fix: DC DNS entry xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx._msdcs.internaldomainname.local. re-registeration on DNS server ‘Server IP Address’ failed.

I checked the DNS zones and saw that both the _msdcs.internaldomain.local zone and internaldomain.local zones were not showing all that they should have been so I deleted both zones and recreated them manually (referring to another Windows 2003 server for the relevant entries.  Once all that could be manually created was created, I re-ran dcdiag /fix and netdiag /fix and still received the error above.

I then tried searching for a way to fix this problem but drew a blank.  Looking through the other event logs, I came across the following error in the System Log:

Event ID: 5788
Source: Netlogon
Description: Attempt to update Service Principal Name (SPN) of the computer object in Active Directory failed. The following error occurred: The attribute syntax specified to the directory service is invalid.

Searching for this error landed me here and upon checking the Computer Name / Domain Name,  I saw that the computer name was simply computername. not computername.internaldomain.local.  Never seen that one before.

Following the resolution in the MS article, I created a VB Script file and ran it on the server and rebooted.

Following the reboot, I re-ran the dcdiag /fix and netdiag /fix and the errors had gone.  In addition, some of the DNS records that I wasn’t able to create manually were magically back, so that seemed to have resolved the DNS issues – hurrah!

I then decided to re-test Activesync and happily received a complete pass on all tests – so now that Exchange could talk to itself, Activesync could actually work!

Running the Exchange Best Practices Analyzer again I was happy to see that Exchange could now talk to itself and the results showed a much happier server with only a few minor issues.

So – if you are seeing the dreaded HTTP 500 error and have gone through my Guide, followed KB883380 method 2 and still get the same error – it just might be a good idea to run the Exchange BPA and check your DNS settings are 100% happy.


KB883380 Fails To Regenerate IIS Virtual Directories on Exchange 2003 / SBS 2003

I was working on a server yesterday so that I could change the certificate name from to

After generating a new Certificate Signing Request and submitting it to the certificate authority (, I verified the certificate, downloaded it and installed it onto the server in the usual manner and that was when everything went wrong.

I could not browse to the Exchange virtual directory, nor the exchange-oma virtual directory (this was an SBS 2003 server) and Actvesync / RPC over HTTPS was broken too!

So, as this was SBS, I decided to re-run the Connect To The Internet Wizard and let SBS work its magic to reset everthing back to normal. The wizard failed the Firewall section of the Wizard and my virtual directories were vaguely working. Resetting the virtual directories back to the required settings from my Exchange 2003 / Activesync article, this seemed to break IIS further!

So, following method 2 of KB883380, I deleted the IIS virtual directories, ran the Cscript command (adsutil delete ds2mb) and then ran “net stop msexchangesa && net start msexchangesa && net start msexchangeis” to stop and restart the System Attendant and then start it and the Information store (which stops with the System Attendant) and waited for 1 minutes.

After waiting 15 minutes and seeing that the virtual directories had not magically reappeared, I rebooted the server as recommended in the KB article.

So the server woke up again from its reboot and yet still no virtual directories.

What to do?

I then decided to re-install Exchange 2003 Service Pack 2 on the server as this quite often fixes things that are a little broken with Exchange / IIS, so I downloaded the Service Pack and installed it.

Bingo! The virtual Directories were back!!

In addition, I decided to re-key the new certificate just in case that was causing me some issues, so generated a new Certificate Signing Request, re-keyed the certificate and re-installed in onto the server.

I then re-ran the Connect To The Internet Wizard one more time, modified the IIS settings as per my article and then tested Activesync and RPC over HTTPS which was working perfectly.

So, in summary, if your IIS virtual directories do not re-appear after following any method from KB883380 and you have waited for 15 minutes, rebooted the server all to no avail, simply download and re-install Exchange 2003 Service Pack 2 and you should be back up and working again in no time.

Forefront Threat Management Gateway and Activesync – Password Prompt Issues on Windows Phones

Since installing Microsoft Forefront Threat Management Gateway in Front of my Exchange 2010 server, my Windows Mobile Phone has been regularly prompting me to enter my password (I have an HTC HD2). If I hit Cancel instead of entering the password, the phone will continue to sync (of course I could have entered my password, but I felt that it wasn’t necessary).

So – presumably there is a problem with a rule somewhere or a rule missing that is causing this problem.

After my business partner (Mark) had done some digging, he discovered a potential fix for this and emailed me a link. On checking the link, I did some research and there appeared to be a setting in my OWA / Activesync Publishing Rule that when de-selected (it is set by default), seems to happily solve the problem. To change the setting, please do the following:

Open up Forefront TMG Management, Click on “Firewall Policy” in the tree in the left-hand pane and then find your OWA / Activesync rule.

Double-click on your OWA / Activesync Publishing Rule, then click on the Listener Tab, then the Properties Button for the Listener, then click on the Forms Tab, then the Advanced button on the Forms Tab and you will see a Check box call “Apply Session Timeout to Non-Browser Clients”.

Untick this check box, click on OK 3 times, Apply the rule changes and then the Password Prompt on your Windows Mobile phone should have stopped and syncing will resume normally.

As Activesync needs to keep a connection open with the Exchange server, with this setting selected, the connection is dropped and thus the phone thinks it needs to re-authenticate with the server. With the setting not selected, then phone is allowed to keep a connection open with the Exchange server and thus the password prompt doesn’t pop up.