OWA Error 500 for users in specific Domain

Hi all,

Here's the scenario:
One back-end Exchange 2003 Server (Exch-BE)
One front-end OWA server (Exch-FE) in the DMZ on our firewall
Windows 2000 AD Domain (root.com)
Three child Domains (CD1.root.com; CD2.root.com; CD3.root.com)

There are mailboxes from user accounts in all three Domains on the Exchange server. Users in the CD1 & CD2 Domains can access OWA without a problem, however, users in CD3 receive an HTTP Error 500 after entering their credentials (username in the form of "CD3\%username%").

So far, I've made the following tests:
If I log on to OWA using an incorrect password for a user in CD3, it prompts me again for the logon details. This seems to indicate that the credentials are being passed to a DC for this Domain.
I can successfully log on to http://exch-be/exchange/%username% using the credentials for a user in CD3.

Other information:
Users in CD3 have an SMTP alias in the form of %username%@exchange.root.com. This matches the 'Exchange Path' setting on the front-end virtual server in ESM.
Domain Controllers for CD3 are located in another office. There are DC's for CD1 and CD2 locally.
Although the 'Exchange Path' on the front-end virtual server in ESM is correct, if I click the 'Modify' button, the list shows around 30 entries, a lot of which are duplicates. One of these entries has (default) next to it, which is not the one selected. If I look at the properties of the 'Exchange' folder underneath the virtual server, the Exchange Path shows the one with (default) next to it.
Looking at the properties of the Exch-BE and Exch-FE servers in ESM, specifically the 'Directory Access' tab, I don't see any Domain Controllers for CD3 listed here.
Pings from Exch-FE are going through to Domain Controllers for CD1 & CD2, but not CD3.

The IIS logs show the follwing information:
When logging on to https://exch-fe: GET / - 443 CD3\user <DMZ Default Gateway IP address> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322;+InfoPath.1;+.NET+CLR+2.0.50727;+FDM) 500 0 0
When logging on to https://exch-fe/exchange/user: GET /exchange/user - 443 - <DMZ Default Gateway IP address> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322;+InfoPath.1;+.NET+CLR+2.0.50727;+FDM) 401 2 2148074254
Then: GET /exchange/user - 443 CD3\user <DMZ Default Gateway IP address> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322;+InfoPath.1;+.NET+CLR+2.0.50727;+FDM) 500 0 0

As you may guess, I've spent a while looking into the solution for this, but have run into dead-ends so far. Any suggestions will be greatly received.

Who is Participating?

Improve company productivity with a Business Account.Sign Up

Computer101Connect With a Mentor Commented:
PAQed with points refunded (500)

EE Admin
Please try this and update:

When the Show Friendly HTTP error messages check box is not selected in the Internet Explorer advanced settings (On the Tools menu, click Internet Options, and then click the Advanced tab), you receive the following error message when you try to access the Exchange virtual directory or the public virtual directory:

2147467259 (0x80004005)

Are you getting this error now?
avidglobaladminAuthor Commented:
I disabled 'Show Friendly HTTP error messages', and now see this in Internet Explorer:
HTTP/1.1 500 Internal Server Error

No other codes displayed.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Are you using any Symantec Antivirus on FE Server?
If no other codes are shown, besides the 500 error, then it is probably something IIS can't identify.  See if there is anything written to the server's Event Log when you try to use OWA. Also, try changing the Application Pool on the Exchange VDir, and see if that helps.  Very often, the identity configured for the application pool has insufficient rights.  If it doesn't help, then leave it on ExchangeApplicationPool .
avidglobaladminAuthor Commented:
Yes, Symantec Antivirus is being used on the FE server. I disabled the realtime protection - no difference.

There is something interesting in the System Event Log though. Each time I've tried to log on with the CD3 user account, there seems to be a corresponding 40960 event logged:
The Security System detected an authentication error for the server HTTP/Exch-BE.CD1.root.com@CD1.root.com.  The failure code from authentication protocol Kerberos was "There are currently no logon servers available to service the logon request.

There are also events in the Security log showing a successful logon.

I'm still suspecting an authentication problem with the Domain Controller on the CD3 Domain.
May you please uninstall Symantec Antivirus from FE and then check.
avidglobaladminAuthor Commented:
I'll only uninstall SAV as a last resort. At the moment, I don't think it's anything to do with the issue - if it was, shouldn't we have problems with users in all three Domains?

I've been looking at the possibility that the OWA server is having problems contacting Domain Controllers of the CD3 Domain. We had some DNS problems with this Domain, which are now resolved, but pings to the DC's from the OWA server are timing out. I've also been using the nltest tool, which works for CD1 and CD2, but not CD3:

nltest /dsgetdc:CD3.root.com
DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

I found another EE article which may be relevant: http://www.experts-exchange.com/Operating_Systems/Win2000/Q_20248114.html. In the accepted answer are the following notes:
4. The Net Logon service sends a datagram to the discovered domain controllers ("pings" the computers) that register the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP UDP search.
5. Each available domain controller responds to the datagram to indicate that it is currently operational and then returns the information to DsGetDcName.

We're currently trying to get the nltest issue resolved, and get the CD3 Domain Controllers to respond to pings from the OWA server. There's a few changes to our routers that need to be made though, as the DC's are in a different office, and OWA is in our DMZ (meaning the DC's try to respond to pings over their local Internet connection, rather than redirecting them across the WAN).

In the meantime, can anyone here give confirmation that the front-end OWA server must be able to ping the Domain Controllers?
avidglobaladminAuthor Commented:
We've now resolved this issue. A Domain Controller for CD3 was installed at the site with the OWA server, and users in this Domain are now able to successfully use OWA.
Excellent, thanks for posting back with that

New recommendation - PAQ: Refund

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.