Outlook client starts getting message "Your logon information is incorrect. Check your username..." Or "Exchange Server Unavailable"

Please refer to question Q_20913274.html. for more background on this situation.

Some of our Outlook clients started receiving this message(s) when starting up Outlook.  We went through all the usual troubleshooting steps involving network connectivity, name resolution, rpc ping, nslookups, checked the DNS entries as well as WINs entries.  No trouble was found in any of those tests, with the exception of pinging the host name of the Exchange server.  That failed.  Pinging the qualified name worked.  I added the Exchange server and a couple of Global Catalog servers to the Host file and the issue was "resolved". Further, we discovered that a better solution was to remove "ncacn_np" from the string on the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider] "Rpc_Binding_Order.  

The question is:  What happened?  Why was it working the day before and not now?  and if it is a DNS problem why isn't everyone having the same problem?  We only have 2 DNS servers.  The first is a primary which does a zone transfer to the second. It doesn't make sense that an event happened that effected random clients.  It would be logical that something changed at a single point of failure, like maybe the DNS server, or the Exchange server(s) but if that were the case it would affect the entire domain. BTW, the mailboxes are distributed across 11 Exchange servers and the problem happened with clients on all 11.   Any ideas?

P.S. The client versions range from Outlook 98 to Outlook 2003.  The OS's from NT4 to XP Pro service pack 2 with all up to date patches.  The Exchange servers are 2003.  We have not had any problems to date with the 2003 clients.
Who is Participating?
marc_nivensConnect With a Mentor Commented:
I was reading your other thread, and 2 things really stood out to me.  1)  The fact that all of the sudden some of your clients that were using named pipes just stopped working, and 2) That there are others that have admin access to the Domain.  I'd be willing to bet that this is policy related.  There are multiple policy settings in 2003 that are potentially incompatible with your setup.  Could have been that the admins just made this domain native, just applied a more secure policy, or just decomissioned the last NT 4 BDC.  This one sounds like either RestrictAnonymous/RestrictAnonymousSam, SMB signing, or the NTLM compatibility level.

I know you had some questions about how this makes sense so here are my theories on a few of them:

Why do none of the OL98 clients work?
Perhaps because all of their traffic is being proxied to the DC via dsproxy and in that case
we would be passing through a named pipes logon.  If we are, then we're never going to get in if there are certain policies in place.  Also if you want non-domain members to authenticate with the 2003 DC using the ncacn_ip_tcp transport you will have to add a reg key to publish this endpoint on all DC's that authenticate users.  This article explains the key: http://support.microsoft.com/?id=236111

Why do all OL2003 clients work?
Because they always use either Kerberos or NTLMv2 over TCP/IP sockets.  These would not be affected by the normal policies.

Why are the rest of the outlook clients inconsistent?
It probably has to do with the client OS.  For example an Outlook 2000 client on NT 4.0 would not be able to logon with the secure 2003 policy settings in place, but an Outlook 2000 client on Windows XP would.  Also, with your NT 4 machines that are part of a different domain, even if you logged on you would probably not be able to change your password through outlook (at least until you add the reg key mentioned above).

Why did hosts file fix some clients?
You said the clients could ping by FQDN but not by short name.  Unless you had Outlook XP or later and had the FQDN of the server listed in the profile properties it wasn't going to work just simply because of name resolution.

Why did removing ncacn_np fix some clients?
It forced a bind to Exchange on ncacn_ip_tcp.  So in turn the clients actually started passing the right credentials, and perhaps others worked because they bypassed the named pipes restriction.

Either way, you should verify you have these settins on the 2003 domain controllers policy:

Microsoft network client: Digitally sign communications (always):  NOT DEFINED
Microsoft network client: Digitally sign communications (if server agrees):  ENABLED
Microsoft network server: Digitally sign communications (always):  NOT DEFINED
Microsoft network server: Digitally sign communications (if server agrees):  ENABLED
Network access: Allow anonymous SID/Name translation:  ENABLED
Network access: Do not allow anonymous enumeration of SAM accounts:  DISABLED
Network access: Do not allow anonymous enumeration of SAM accounts and shares:  DISABLED
Network access: Restrict anonymous access to named pipes and shares:   NOT DEFINED
Network security: Lan Manager authentication level:  Send LM & NTLM - use NTLMv2 session security if negotiated

Once you make these changes you will need to ensure the policy gets applied, then reboot the PDC emulator.

There may be more but thats all I can think of right now.  I know lowering security settings isn't something to be done
lightly, but the only way to really take advantage of the security in Windows 2003 is to get rid of all legacy clients.
Oh, and here is a good article on the policy settings:  http://support.microsoft.com/?id=823659

All Courses

From novice to tech pro — start learning today.