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.

Alan

Yet more Bad IT Support Companies!

Following on from my earlier Blog Post about bad IT Support Companies (here) I visited a potential new customer today to look over their IT.  The background information I got from the company was that they had used their existing IT Support Company (a one-man band) for the past 5 years or so and whilst mostly happy with their service, there were some outstanding issues that were being neglected and this was causing some concern to the company.

They had recently installed a ‘server’ and their IT wasn’t running as smoothly as they had anticipated, so wanted to get a 2nd opinion about their setup and my company (IT Eye Ltd) was recommended by a mutual company.

Once I arrived, I had a quick look over their IT and came across 4 PCs and a Netbook.  Asking where the server was, I was directed towards an HP xw6600 Workstation with a label on it suggesting it had come out of a company in New York City (NYC-XXXXXXXXX)!  I then used Remote Desktop to connect to the server and discovered that it was running SBS 2008.  This prompted the question about when the server was purchased and I was told May of 2012.  I then asked how much they had paid for the server and they advised me £2,500.

Okay – so they had a recently installed SBS 2008 server of which Exchange 2007 was now no longer supported by Microsoft because the Mainstream Support had now expired!  That begged the question why SBS 2011 wasn’t installed and to that there wasn’t an answer.  I then looked for a license sticker and couldn’t find one, so that also begged the question if they were actually legal.  This conversation continued to the other workstations and no conclusive evidence was available to suggest that they were even remotely compliant.

Looking at one of the XP workstations I saw that it was running XP pro, so checked to see if it was part of the Domain and saw that it was still configured as a Workgroup.

Data was being shared from the server, so at least the server was being used for something other than a drain on their electricity bill, but data was still being held on the Netbook and the data wasn’t being copied to the server or backed up, so was at risk of being lost.  No evidence of server backup was visible either.

I then asked about emails and found out that they were being hosted externally (1and1) and were being collected via Outlook configured as an SMTP/POP3 account and to allow for shared calendars to be accessed, they had turned to Google Mail.

I then pointed out that their server had Exchange built-in and that they need not pay for mail to be hosted externally or use Google Mail for shared Calendars as they could do everything on their own server.

At this point – I think they had decided that they were not being well looked after by their existing IT Support Company and I left them pondering my findings.  We will wait to hear from them and see how they want to proceed.

Alan