Link to home
Start Free TrialLog in
Avatar of Tud
Tud

asked on

HTTP Error 500 with OWA, but only for some user accounts

I've been having problems with certain users and OWA, some can login without an issue and others are getting an error 500.  In attempting to fix the problem I've likely gone from bad to worse, but this is where I think I am:

Exchange 2003 Enterprise Backend Server running on a Windows 2003 server on the LAN
Exchange 2003 Enterprises Frontend Server running in DMA (I know, there's no use in putting in the DMZ, but that's where is).

From inside our network I've been able to open Outlook Web Access with me account by going to:
https://mail.domainname.ca/exchange and logging in with domainname\username and password.

If I shut down IE (I'm using 6 but the same this is happening with IE 7 and firefox)  and relaunch it and try it with another user account, one that's having the problem, I get an error 500.

Now, the very last thing I just tested was to clear my cookies and deleted my temp files from Tools->Internet Options of IE6 and now I can no longer log into OWA with my own username, which up until now was working.  If I put in https://backendservername/exchange (I'm on the LAN) I can get into OWA.

Additional error messages:

On the front end server if I open up the Exchange System Manager and then drill down to the backend server and the protocols I get the following message
The RPC Server is unavailable
Facility: Win32
ID no: 800706ba
Exchange System Manager

On the front end server in Event Viewer:
Event 40960
The Security System detected an authentication error for the server HTTP/backendservername.domainl.loc@domain.loc.  The failure code from authentication protocol Kerberos was "There are currently no logon servers available to service the logon request.
 (0xc000005e)".

No changes have been made on our firewall from the time this was working until now.  During my initial troubleshooting I removed the virtual directories on the frontend server and reinstalled them according to a link from Microsoft.  We aren't using forms based authentication.  I've got the proper Application Pool for the virtual directories under IIS, but I can't be sure that I have all the proper security settings setup.

 I read at one time that on the backend under the Enable anonymous access for the directory security that I should set it to administrator and then set it back to IUSER_servername.  I did this but when I set it back I didn't have a password.  I manually reset the IUSER_servername users password and then matched in it the IIS direcotry security seetings.  I'm not sure if that could have screwed things up.

Also, I'm not sure which virtual directories under the Default Web Site should have anonymous login enabled, for either the frontend backend, and which ones should have the Integrated Windows Authentication enabled, or basic authentication.  We're using SSL.  I'm thinking this directory security might be my issue but I'm not sure.  Any help would be appreciated.

Without really knowing what it's for, I ran rpcping -s backendservername and got a reply, FWIW.
SOLUTION
Avatar of James Montgomery
James Montgomery

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of James Montgomery
James Montgomery

Avatar of Tud

ASKER

I just tried with the following from a PC on the LAN:

https://backendservername/exchange

With my username is seems to be working fine.  With a different user I'm just getting the place holders and "loading", which I've in a few other threads while researching this, so I'm going to go track down those threads, but first let me follow that link you posted and see what happens....that looks like what I did on the front end server, but I haven't done it on the backend server because of the reboot required.  I'll give this a try this evening and report back.
Let me know how it goes, although it does also remind me of this old article:

http://kbalertz.com/831464/Compression-Corruption-Causes-Access-Violations.aspx
Avatar of Tud

ASKER

Will do, I'll be rebooting in about 2 hours.  As for that last link, I checked the c:\windows\IIS Temporary Compressed Files directories on both servers but they were both empty.  
Avatar of Tud

ASKER

Reinstalling the virtual directories on the backend server hasn't made a difference.  I can still login to OWA with my account, but some other accounts are still giving an error 500.  I'm logging in from the same workstation, but now I'm on IE7.  I'm also still getting the RPC error when going through the Exchange System Manager from the frontend server to view the backend server's protocols.
Avatar of Tud

ASKER

Something might not be installed right.  If I go to System Manager on the FE and BE servers it shows that I'm running version 6.5.7638.1 on both (under help and about), but under Exchweb in IIS I see a 6.5.7638.1 AND a 6.5.7651.60 directory.  I would think that the System Manager should report the later version, but I could be wrong.
Avatar of Tud

ASKER

I downloaded the patch associated with 6.5.7651.60 and installed on BE and FE server with no difference, and it still says 6.5.7638.1 in the Help->About sections of System Manager.  Still in the same boat and still seeing LSASVR error 40960 in Event Viewer on the FE server.
Avatar of Tud

ASKER

Latest news.  I enabled Forms Based Authentication and I was able to login with the username that's been giving me problems.  I enabled on the backend and frontend, not sure if it's needed on both.  I was already using SSL, so I didn't touch that.  So forms based authentication obviously uses a different authentication method than non-forms based.  Aside from the GUI, do you what might be different that is causing my problem with non-forms based?
Avatar of Tud

ASKER

I noticed this morning that Active sync on my phone is no longer working.  I turned off FBA on the backend server and left it on for the front end server and it's working again, as well as the mailboxes using the FBA which is still enabled on the front end server.  I'm still getting Lsasvr errors on the front end server.  I could likely leave things be but something isn't setup right and I'd like to get it sorted out.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Tud

ASKER

I'm going through the document now.  My login issue is back for certain accounts.

One thing I've tested is to breifly open all the ports between the FE and BE servers.  This didn't help the problem user accounts but it did allow me to view the HTTP settings on the backend server from the frontend server using the Exchange System Manager.  If I close the ports again I get the RPC Server unavailable error (ID 800706ba).  I'm leaving open the ports I need but there must be another besides the ones I've seen documented, I'll be checking into this.  

So I've got at least one firewall port issue, just a matter of determining which one is required for that function.  Like I said, having them all open didn't help the login issue, so I'm still going through it and will report back.

Avatar of Tud

ASKER

The firewall port may have been a red herring.  I reinstalled Exchange's SP2  on both the FE and BE servers and rebooted them and I can now go to System Manager on the FE server and open the HTTP protocol settings on the BE without getting the  RPC Server unavailable error (ID 800706ba) error.  I haven't applied any other patches since reinstalling SP2.  I'm still having the login issue and still seeing Lsasvr 40960 errors on the FE server.
Avatar of Tud

ASKER

I haven't had a chance to look at this in the past few days, but it is still an open issue.  I am currently using forms based authentication and I am getting an error 500 in OWA for some users, but not all users.  I'm not sure if it's related but I am also still getting Error ID 40960 in the Event Viewer on the front end server.

I wasn't using forms based authentication before I started trouble shooting, and now if I turn it off I get an error 404 "File or directory not found".  This is just by turning it off and running iisreset on the FE server.  I suspect this has to do with security setting I changed while configuring FBA.

In any event, I'm still having the Error 500 issue and can't seem to find a fix for it.
IMO I would advise that you contact microsoft PSS.

While I would relish the chance to sink my teeth into this - I am realistic to know at this point that forum based help is probably not quite specific enough.

http://support.microsoft.com/oas/default.aspx?ln=en-gb&x=8&y=9&prid=6001&gprid=35178

You will find their per inident rate is actually reasonable - and you will learn alot from the call.
Avatar of Tud

ASKER

Thanks, I may do that.  I fortunate in that non of our execs are having a problem with OWA (knock on wood), so I've got time to play with it.  I'm beginning to think it may be a port issue somewhere.  I was just talking to a user that couldn't get it, when I tried it from my workstation it didn't work, after a few minutes I tried it again and it worked.  I'm not sure if maybe it's using different ports for something like RPC and it's possibly using a port that's not open on the firewall.  I'm still searching through documentation to see if I can narrow it down.  I noticed in our installation manual from when this was put in a few years ago that it shows the following info in the registry:

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc

Under that it shows an "Internet" key with the RPC ports setup for 5000-5020.  I checked the BE server and it doesn't have the Internet key.  It should, as it appeared to be part of the install.  I'm not sure if an upgrade could have reqmoved it or not.  We've gone from Exchange 2003 Standard to 2003 Enterprise a few months back.  I added the Key and values back in but the page indicates that it will require a reboot, which I can't do until this evening.  I'm hoping that it requires this key and without it the system is trying to use ports outside the 5000-5020 range that aren't open on the firewall.  It maybe that it works occassionally for some users because they keep getting a valid port.  This is just a shot in the dark.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Tud

ASKER

I've opened all the ports in both directions with no change and rebooting the BE, FE and firewall hasn't changed anything, but I think I found something.  In the logs for the firewall I'm seeing the following message, which seems to corrospond to the failed login attempts through OWA:

Fragmented Packet Dropped <be-server-ip>, 17, LAN <fe-server-ip>, DMZ Protocol: 17
The protocol listed as 17 on the firewall is for LDAP, which is using port 389.  

So now I'm switching gears and trying to find out why LDAP packets are being dropped as fragmented packets.
Avatar of Tud

ASKER

Some mis-information above, it's protocol 17, not rule 17.  So it's a UDP protocol but not necessarily LDAP that's getting dropped.  I'm thinking this will require a new topic that more accurately describes the problem since it's not necessarily an OWA issue, but I'll work on it a bit this morning before doing that.
Avatar of Tud

ASKER

I may have found the a fix to the problem, but not the reason for why it broke in the first place.

In my firewall rules there is an option for each protocol/port to allow fragmented packets.  I opened all ports between the front end and back end server with a single rule and checked off "Allow fragmented packets".  I tested it with the one user that has consistantly been failing and it didn't work.  I believe the individual rules for each port over ride the blanket rule that I setup.  I removed the blank rule that opened all ports and then edited the rule for LDAP to allow fragmented packets.  OWA still failed.  Next, since I was getting the Kerberos errors on the front end server I edited the rule for Kerberos and allowed fragmented packets.  Bingo, the one user account that has consistantly been failing is now working.

I'm not sure if this is a coincidence or if that fixed the problem.  I'll be monitoring the Event Viewer on the FE server to see if anymore LSASVR errors appear, and the log on the firewall to see if anymore fragmented packets are getting blocked, as well as periodically checking OWA.  Thanks for your help and the suggestions.



Avatar of Tud

ASKER

Your responses, while not providing the exact fix, where very clear and easy to follow.  Thanks again for the time and effort you put into assisting me.