?
Solved

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

Posted on 2008-02-01
21
Medium Priority
?
1,365 Views
Last Modified: 2012-05-05
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.
0
Comment
Question by:Tud
  • 15
  • 6
21 Comments
 
LVL 15

Assisted Solution

by:JimboEfx
JimboEfx earned 2000 total points
ID: 20799675
Sounds you have multiple issues here.

You should be able to http/https direct to backend server - just use internal IP. Does this work - the front end is just a proxy to the appropriate backend server.
0
 
LVL 15

Expert Comment

by:JimboEfx
ID: 20799701
0
 

Author Comment

by:Tud
ID: 20799881
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.
0
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

 
LVL 15

Expert Comment

by:JimboEfx
ID: 20799939
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
0
 

Author Comment

by:Tud
ID: 20799972
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.  
0
 

Author Comment

by:Tud
ID: 20801854
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.
0
 

Author Comment

by:Tud
ID: 20802040
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.
0
 

Author Comment

by:Tud
ID: 20802209
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.
0
 

Author Comment

by:Tud
ID: 20802576
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?
0
 

Author Comment

by:Tud
ID: 20804268
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.
0
 
LVL 15

Assisted Solution

by:JimboEfx
JimboEfx earned 2000 total points
ID: 20804931
The active sync error is probably related to this and is often seen in a single backend server deployment:
http://www.petri.co.il/problems_with_forms_based_authentication_and_ssl_in_activesync.htm

I would also like to get this sorted.

I have attached a comprehensive guide from MS on front end/backend configuration. I suggest you read it, or just the relevant bits, and come back with any questions.

Or post errors (event logs) and screen shots until we tidy this off.


E2k3FrontBack.doc
0
 

Author Comment

by:Tud
ID: 20807408
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.

0
 

Author Comment

by:Tud
ID: 20820128
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.
0
 

Author Comment

by:Tud
ID: 20866484
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.
0
 
LVL 15

Expert Comment

by:JimboEfx
ID: 20866640
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.
0
 

Author Comment

by:Tud
ID: 20874502
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.
0
 
LVL 15

Accepted Solution

by:
JimboEfx earned 2000 total points
ID: 20878415
you may be on to something...http://support.microsoft.com/kb/154596

Really you should eliminate firewall port issues by not restricting the firewall rules between front and backend until you have it working normally...
0
 

Author Comment

by:Tud
ID: 20880803
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.
0
 

Author Comment

by:Tud
ID: 20883643
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.
0
 

Author Comment

by:Tud
ID: 20884233
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.



0
 

Author Closing Comment

by:Tud
ID: 31427182
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.
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In my humble opinion (IMHO), TouchDown from Symantec is the best in class for this type of application, but Symantec has end-of-lifed it and although one can keep using it, it will no longer be supported or upgraded.  Time to look for alternatives t…
There’s hardly a doubt that Business Communication is indispensable for both enterprises and small businesses, and if there is an email system outage owing to Exchange server failure, it definitely results in loss of productivity.
This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online) The email signat…
Whether it be Exchange Server Crash Issues, Dirty Shutdown Errors or Failed to mount error, Stellar Phoenix Mailbox Exchange Recovery has always got your back. With the help of its easy to understand user interface and 3 simple steps recovery proced…
Suggested Courses

601 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question