CSDDI
asked on
RPC over HTTP has quit working - Small Business Server 2003 / Exchange 2003
All,
We have a server that has been running for well over a year with no problems. It is a Small Business Server 2003 with Exchange 2003. Everything has been working until today. For some reason RPC over HTTP connections no longer seem to be working. If my clients connect using a VPN client everything works fine. I thought it might be a password issue or an Outlook profile issue, but I have eliminated these as causes by resetting the password and creating a new profile. The issue persists. I have looked in the event logs and do not see anything that indicated specific issues with RPC or Exchange.
I do however see the following error in the event logs:
ogon Failure:
Reason: Unknown user name or bad password
User Name: username
Domain: DOMAIN
Logon Type: 3
Logon Process: IAS
Authentication Package: MICROSOFT_AUTHENTICATION_P
Workstation Name:
Caller User Name: SERVERNAME$
Caller Domain: DOMAIN
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 988
Transited Services: -
Source Network Address: -
Source Port: -
In addition there is the following event that is showing up. It shows to be there every day so I am not sure that it is related.
RPC Proxy successfully loaded in Internet Information Services (IIS) mode 6.0.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
All Exchange services seem to be working fine. I can connect to OWA and if I establish a VPN connection first, Outlook works fine as well.
In the Exchange Server Connection Status box both mail and directory show to be connected when I am using the VPN. However, if the VPN is not connected they show offline or disconnected.
When I open Outlook without the VPN I get the login credentials box, but it does not accept the credentials I supply even after I reset the password.
We have a server that has been running for well over a year with no problems. It is a Small Business Server 2003 with Exchange 2003. Everything has been working until today. For some reason RPC over HTTP connections no longer seem to be working. If my clients connect using a VPN client everything works fine. I thought it might be a password issue or an Outlook profile issue, but I have eliminated these as causes by resetting the password and creating a new profile. The issue persists. I have looked in the event logs and do not see anything that indicated specific issues with RPC or Exchange.
I do however see the following error in the event logs:
ogon Failure:
Reason: Unknown user name or bad password
User Name: username
Domain: DOMAIN
Logon Type: 3
Logon Process: IAS
Authentication Package: MICROSOFT_AUTHENTICATION_P
Workstation Name:
Caller User Name: SERVERNAME$
Caller Domain: DOMAIN
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 988
Transited Services: -
Source Network Address: -
Source Port: -
In addition there is the following event that is showing up. It shows to be there every day so I am not sure that it is related.
RPC Proxy successfully loaded in Internet Information Services (IIS) mode 6.0.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
All Exchange services seem to be working fine. I can connect to OWA and if I establish a VPN connection first, Outlook works fine as well.
In the Exchange Server Connection Status box both mail and directory show to be connected when I am using the VPN. However, if the VPN is not connected they show offline or disconnected.
When I open Outlook without the VPN I get the login credentials box, but it does not accept the credentials I supply even after I reset the password.
ASKER
Sembee,
Thanks for the quick response. I just checked the certificate, which is homegrown BTW, and the expiration date shows to be in 2010. In addition, it says that the certificate status is 'ok'. I checked the directory security tab for the RPC virtual directory in IIS and here is what it has:
Enable anonymous access (unchecked)
Integrated Windows Authentication (checked and grayed out)
Digest Authentication for Windows domain server (checked and grayed out)
Basic Authentication (password is sent in clear text) (checked and grayed out)
.NET Passport Authentication (checked...NOT grayed out)
In addition, there have been no changes to the server any time recently.
One last thing, I did reboot the server just to ensure that something was not hung somewhere. This had no affect on the situation. Thanks again for the quick response and for your help!
Thanks for the quick response. I just checked the certificate, which is homegrown BTW, and the expiration date shows to be in 2010. In addition, it says that the certificate status is 'ok'. I checked the directory security tab for the RPC virtual directory in IIS and here is what it has:
Enable anonymous access (unchecked)
Integrated Windows Authentication (checked and grayed out)
Digest Authentication for Windows domain server (checked and grayed out)
Basic Authentication (password is sent in clear text) (checked and grayed out)
.NET Passport Authentication (checked...NOT grayed out)
In addition, there have been no changes to the server any time recently.
One last thing, I did reboot the server just to ensure that something was not hung somewhere. This had no affect on the situation. Thanks again for the quick response and for your help!
There is your problem.
Deselect the .net Passport Authentication and enable Integrated and Basic authentication.
Simon.
Deselect the .net Passport Authentication and enable Integrated and Basic authentication.
Simon.
ASKER
Simon,
I have not made any changes to this server since it was brought online. I definitely did not change this. Also, please note that Integrated and Basic authentication are both checked just grayed out. I would think that this means that they are enabled. I would be glad to send you a screen shot or post one here, if I knew how to do it. I will give this a try, but I dont know how this could have changed by itself. I am the only person with access to this server and I know for sure I have not made this change and there have been no system changes (updates, patches, or service packs) in the last 30 days. Do you think there is any other possibility that could be causing this. Again, to recap the directory security tab looks like this (note: basic and integrated authentication are both checked (enabled?) but grayed out):
Integrated Windows Authentication (**checked** and grayed out)
Digest Authentication for Windows domain server (checked and grayed out)
Basic Authentication (password is sent in clear text) (**checked** and grayed out)
.NET Passport Authentication (checked...NOT grayed out)
Please also keep in mind that this is an SBS 2003 server. I am not sure if that has any bearing on any of this, but thought I would mention it again. Thanks again for your help.
I have not made any changes to this server since it was brought online. I definitely did not change this. Also, please note that Integrated and Basic authentication are both checked just grayed out. I would think that this means that they are enabled. I would be glad to send you a screen shot or post one here, if I knew how to do it. I will give this a try, but I dont know how this could have changed by itself. I am the only person with access to this server and I know for sure I have not made this change and there have been no system changes (updates, patches, or service packs) in the last 30 days. Do you think there is any other possibility that could be causing this. Again, to recap the directory security tab looks like this (note: basic and integrated authentication are both checked (enabled?) but grayed out):
Integrated Windows Authentication (**checked** and grayed out)
Digest Authentication for Windows domain server (checked and grayed out)
Basic Authentication (password is sent in clear text) (**checked** and grayed out)
.NET Passport Authentication (checked...NOT grayed out)
Please also keep in mind that this is an SBS 2003 server. I am not sure if that has any bearing on any of this, but thought I would mention it again. Thanks again for your help.
ASKER
Simon,
I sent you a screen shot to your experts-exchange account. I hope you don't mind. I just thought it might be easier to see it. Thanks again!
Chris
I sent you a screen shot to your experts-exchange account. I hope you don't mind. I just thought it might be easier to see it. Thanks again!
Chris
I have seen the screenshot, and my response still stands.
Deselect the .net passport authentication as you can't use that. The other options are greyed out because you cannot use them. By deselecting the .net passport system the options will come available again and the system will work.
Simon.
Deselect the .net passport authentication as you can't use that. The other options are greyed out because you cannot use them. By deselecting the .net passport system the options will come available again and the system will work.
Simon.
ASKER
Okay, I have some additional information. This seems to be happening to only 1 account. All of the rest are working. What's happening for this one account is the password is being rejected. However, this account can log into OWA and can establish a VPN connection and can log into the domain. Also, when physically on the local network where the server is located, the account can connect to Outlook via RPC over HTTP as noted by looking at the connections tab in Outlook and seeing that all of the sessions are TCP/IP instead of RPC.
I still have not made the changes to the .NET passport authentication since no other accounts are having issues connecting.
I still have not made the changes to the .NET passport authentication since no other accounts are having issues connecting.
That doesn't make any sense.
Is it the same machine internally and externally?
If it is then you shouldn't see a single user with the problem, unless the problem is with the remote site.
If it was the firewall causing the problem - then it would affect everyone.
If it was the user account causing the problem - then I would expect the problem to be seen no matter where the account was being used.
Simon.
Is it the same machine internally and externally?
If it is then you shouldn't see a single user with the problem, unless the problem is with the remote site.
If it was the firewall causing the problem - then it would affect everyone.
If it was the user account causing the problem - then I would expect the problem to be seen no matter where the account was being used.
Simon.
ASKER
It is the same machine both internally and externally (laptop). My first thought was a corrupted profile in Outlook, so I deleted and started with a fresh profile. I am at a loss as well. Its almost like when the machine is remote the credentials are not being passed. It can't be the password because the password works when the machine in on the internal network and for logging into OWA, etc.
One thing I will add is this. I know for a fact that the login process is different when the machine is remote versus being on the local network because when the user is on the local network they are not prompted for credentials when they launch Outlook. However, when they are remote they are prompted. I know this must have something to do with it.
One thing I will add is this. I know for a fact that the login process is different when the machine is remote versus being on the local network because when the user is on the local network they are not prompted for credentials when they launch Outlook. However, when they are remote they are prompted. I know this must have something to do with it.
If the machine is a member of the domain, then they should not be prompted for credentials whether on the network or off the network. For a domain member the entire process should be transparent.
Simon.
Simon.
ASKER
The machine is indeed a member of the domain. I am not sure I agree with you on this point. :-) I have seen this many times where a machine is a member of the domain and the user is prompted for credentials for Outlook when not on the local network. I think this is a limitation of Outlook. Even if you check the box to remember the password Outlook will prompt you to re enter the password each time you launch it. I am not sure why this happens, but I know I have seen this across multiple domains.
ASKER
As an update...when the machine is connected via VPN the user is not prompted for credentials.
I have deployed lots of Exchange servers, and lots of clients with RPC over HTTPS on machines that are members of the domain - and not one has prompted for credentials. My clients wouldn't accept it, and my deployments of RPC over HTTPS are always totally transparent to the user.
Therefore you have to look at the authentication methods.
In Outlook, ensure that the RPC Proxy settings are set to NTLM Authentication, not basic.
Ensure that both basic and integrated authentication are set on the /rpc virtual directory in IIS Manager.
Simon.
Therefore you have to look at the authentication methods.
In Outlook, ensure that the RPC Proxy settings are set to NTLM Authentication, not basic.
Ensure that both basic and integrated authentication are set on the /rpc virtual directory in IIS Manager.
Simon.
ASKER
I have made all the changes to Outlook you suggested...the issue remains. I made the changes to IIS as you suggested and then re started IIS to make sure the settings took. I am sending you some screenshots as well.
Please keep the following in mind:
1) All other users are able to connect and have been able to connect without issue. Only one account seems to be affected.
2) All users were previously prompted for credentials when connecting via RPC over HTTPS and now they are prompted once, and if they choose 'save password' then they are no longer prompted.
I am sending you screenshots of the server's RPC virtual directory securty settings and the offending machine's Outlook configuration.
Please keep the following in mind:
1) All other users are able to connect and have been able to connect without issue. Only one account seems to be affected.
2) All users were previously prompted for credentials when connecting via RPC over HTTPS and now they are prompted once, and if they choose 'save password' then they are no longer prompted.
I am sending you screenshots of the server's RPC virtual directory securty settings and the offending machine's Outlook configuration.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Simon,
Thanks for all of your help! I think making the other changes as well has helped too. Again, thanks!
Thanks for all of your help! I think making the other changes as well has helped too. Again, thanks!
Lets check the first two easy things.
1. Authentication on the /rpc virtual directory in IIS. Make sure that it is set to integrated authentication.
2. The SSL certificate - make sure that it hasn't expired, especially if it is a home grown certificate.
Simon.