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.c
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;+M
When logging on to https://exch-fe/exchange/user: GET /exchange/user - 443 - <DMZ Default Gateway IP address> Mozilla/4.0+(compatible;+M
Then: GET /exchange/user - 443 CD3\user <DMZ Default Gateway IP address> Mozilla/4.0+(compatible;+M
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.
Thanks.
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.c
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;+M
When logging on to https://exch-fe/exchange/user: GET /exchange/user - 443 - <DMZ Default Gateway IP address> Mozilla/4.0+(compatible;+M
Then: GET /exchange/user - 443 CD3\user <DMZ Default Gateway IP address> Mozilla/4.0+(compatible;+M
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.
Thanks.
ASKER
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.
HTTP/1.1 500 Internal Server Error
No other codes displayed.
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 .
ASKER
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@
(0xc000005e)".
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.
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@
(0xc000005e)".
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.
ASKER
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: https://www.experts-exchange.com/questions/20248114/Event-ID-1000-occur-in-Event-Log-Domain-Policy-problem.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?
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: https://www.experts-exchange.com/questions/20248114/Event-ID-1000-occur-in-Event-Log-Domain-Policy-problem.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?
ASKER
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
-red
New recommendation - PAQ: Refund
-red
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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?