We have an exchange 2010 SP1 mail server with all roles installed. Our clients are mostly 2003 Outlook. Up until today, everyone was able to connect to exchange and all was good. Today, absolutely random people cannot open Outlook. When I try to delete and recreate the profiles I get the error message "The name could not be resolved. The operation failed." For these users, I have tried to log in on half a dozen machines and I get the error everytime. I can log in as myself or other users who aren't having problems and those users work on all the test machines. The users can log into webmail, and their smartphones work too - just outlook refuses to connect. I've read that typically the "work offline" mode has been enabled, but that is not the case here - the server will not connect. Upon making a new profile it simply refuses to connect to exchange and therefore the profile never gets created. Over the weekend some tweaks were done to the server. We've been using a different offline address book other than the default since exchange was installed - and I removed the standard "default offline address book" since it is not used. Is there something that I'm missing? Can anyone help solve this problem?

Over the weekend I disabled IPv6 as well. I re-enabled that and now I get a new error message: "The name could not be resolved. The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action."

On Mon, 15 Nov 2010 18:04:24 +0000, Erik Tank wrote: > > >We have an exchange 2010 SP1 mail server with all roles installed. Our clients are mostly 2003 Outlook. Up until today, everyone was able to connect to exchange and all was good. Today, absolutely random people cannot open Outlook. When I try to delete and recreate the profiles I get the error message "The name could not be resolved. The operation failed." For these users, I have tried to log in on half a dozen machines and I get the error everytime. I can log in as myself or other users who aren't having problems and those users work on all the test machines. > >The users can log into webmail, and their smartphones work too - just outlook refuses to connect. > >I've read that typically the "work offline" mode has been enabled, but that is not the case here - the server will not connect. Upon making a new profile it simply refuses to connect to exchange and therefore the profile never gets created. > >Over the weekend some tweaks were done to the server. We've been using a different offline address book other than the default since exchange was installed - and I removed the standard "default offline address book" since it is not used. Is there something that I'm missing? Can anyone help solve this problem? If you suspect a connectivity problem you can use RpcPing: http://support.microsoft.com/kb/831051 To use RPC directly (without HTTPS), these commands should work: Store Interface (TCP:6001) RPCPing -t ncacn_ip_tcp -s RpcServerFqdn -f a4f1db00-ca47-1067-b31f-00dd010662da,0 -u 10 -a connect -v 3 -I "Account,Domain,Password!" Directory Interface (TCP:6004) RPCPing -t ncacn_ip_tcp -s RpcServerFqdn -f f5cc5a18-4264-101a-8c59-08002b2f8426,56 -u 10 -a connect -v 3 -I "Account,Domain,Password!" If you use the name of a Global Catalog server instead of your Exchange server when you create a new profile do the symptoms change? Since you're using Outlook 2003 and Exchange 2010, have you tried using "Encryption" on the profile's "Security" tab? IIRC, the RPC connection to Exchange 2010 requires the use of encrypted RPC. What other "tweaks" did you make on the server? Did you do anything to hide these people from the Global Address Book, or prevent them from reading the GAL? If you try using their legacyExchangeDN as the user name when you "Check Names", does that work? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Update #2: Now the server is refusing new connections of any type. Existing user accounts are also randomly offline - unable to work online, but not everyone. Some accounts are still connected and working fine - though I have not touched their profiles either. I uninstalled all windows updates that happened over the weekend as well, but that made no difference.

Update #3: I have deleted a working user's profile, and upon re-adding it; it fails. So it appears exchange is rejecting any new connections. Anyone know of a solution to this?

On Mon, 15 Nov 2010 18:04:24 +0000, Erik Tank wrote: If you suspect a connectivity problem you can use RpcPing: http://support.microsoft.com/kb/831051 To use RPC directly (without HTTPS), these commands should work: Store Interface (TCP:6001) RPCPing -t ncacn_ip_tcp -s RpcServerFqdn -f a4f1db00-ca47-1067-b31f-00dd010662da,0 -u 10 -a connect -v 3 -I "Account,Domain,Password!" Directory Interface (TCP:6004) RPCPing -t ncacn_ip_tcp -s RpcServerFqdn -f f5cc5a18-4264-101a-8c59-08002b2f8426,56 -u 10 -a connect -v 3 -I "Account,Domain,Password!" If you use the name of a Global Catalog server instead of your Exchange server when you create a new profile do the symptoms change? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP Using our GC server actually worked!! It fills in the mail servers address and the check name button resolves properly. I ran the two statements for rpcping and for the store interface completes 1 call in 1ms. The Directory Interface however, fails. "RpcEpResolveBinding failed - 1753 (000006d9) What exactly does this mean?

Since you're using Outlook 2003 and Exchange 2010, have you tried using "Encryption" on the profile's "Security" tab? IIRC, the RPC connection to Exchange 2010 requires the use of encrypted RPC. What other "tweaks" did you make on the server? Did you do anything to hide these people from the Global Address Book, or prevent them from reading the GAL? If you try using their legacyExchangeDN as the user name when you "Check Names", does that work? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP RPC encryption is handed out via group policy and everything was fine up until this weekend. Other tweaks did not include anything with the GAL. Mostly changing size limits on messages, and other things that the ExBPA reported... nothing significant other than deleting the unused OAB. Thanks for the help so far - I'm not sure what to do next.

On Mon, 15 Nov 2010 20:34:41 +0000, Erik Tank wrote: >On Mon, 15 Nov 2010 18:04:24 +0000, Erik Tank wrote: If you suspect a connectivity problem you can use RpcPing: http://support.microsoft.com/kb/831051 To use RPC directly (without HTTPS), these commands should work: Store Interface (TCP:6001) RPCPing -t ncacn_ip_tcp -s RpcServerFqdn -f a4f1db00-ca47-1067-b31f-00dd010662da,0 -u 10 -a connect -v 3 -I "Account,Domain,Password!" Directory Interface (TCP:6004) RPCPing -t ncacn_ip_tcp -s RpcServerFqdn -f f5cc5a18-4264-101a-8c59-08002b2f8426,56 -u 10 -a connect -v 3 -I "Account,Domain,Password!" If you use the name of a Global Catalog server instead of your Exchange server when you create a new profile do the symptoms change? --- Rich Matheisen MCSE+I, Exchange MVP >--- Rich Matheisen MCSE+I, Exchange MVP > >Using our GC server actually worked!! It fills in the mail servers address and the check name button resolves properly. > >I ran the two statements for rpcping and for the store interface completes 1 call in 1ms. > >The Directory Interface however, fails. "RpcEpResolveBinding failed - 1753 (000006d9) > >What exactly does this mean? It means that the test was unable to connect to the RPC service for the GUID f5cc5a18-4264-101a-8c59-08002b2f8426. First thing to verify is that all the Exchange services are running. Assuming they are, you can use this KB article (http://support.microsoft.com/kb/325930) to verify that the server-side registry stuff is all correct (and that the DLL's are present). You can use the portqry tool (http://support.microsoft.com/kb/832919) to see what UUID's the server has registered: portqry -n <exchangeserver> -e 135 The NSPI (i.e. directory) service uses the UUID (GUID) f5cc5a18-4264-101a-8c59-08002b2f8426. The output from portqry would look like this (on two lines): UUID: f5cc5a18-4264-101a-8c59-08002b2f8426 MS Exchange Directory NSPI Proxy ncacn_ip_tcp:srvr005[1158] If everything looks like it SHOULD work, make sure you haven't changed any firewall rules. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

All services are started. using the portqry tool, the UUID f5cc5a18-4264-101a-8c59-08002b2f8426 is not listed at all. No changes to firewall rules have been made at all - but I have tried completely disabling it, with no luck either. Next steps?

OK now for the really creepy news. Its working. I changed absolutely nothing. The only thing I did was install port query v 2 and ran it... I have NO idea why this happened to start with... but it seems like all my users can connect (just in time to go home). I will post back if it happens again... now the UUID listed previously is listed under portqry as well. This makes me so mad!! How would it just start working on it's own after being disabled all day? I feel like such an amateur because of this. I hope it happens again so I can actually know what fixed it. If you have any theories as to why it happened - I'd still love to hear them. I don't think I've seen the last of this! Thanks again for all your help Rich!

On Mon, 15 Nov 2010 23:35:23 +0000, Erik Tank wrote: >OK now for the really creepy news. Its working. I changed absolutely nothing. The only thing I did was install port query v 2 and ran it... All that does is to report what's registered with RPC. You don't even have to install it on the machine to get it to report that information. >I have NO idea why this happened to start with... but it seems like all my users can connect (just in time to go home). > >I will post back if it happens again... now the UUID listed previously is listed under portqry as well. This makes me so mad!! How would it just start working on it's own after being disabled all day? I feel like such an amateur because of this. I hope it happens again so I can actually know what fixed it. > >If you have any theories as to why it happened - I'd still love to hear them. I don't think I've seen the last of this! Thanks again for all your help Rich! Well, you did say you disabled the firewall. That sounds like a good place to start. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I disabled the firewall only temporarily and turned it back on after a few minutes - it started working on it's own with the firewall turned back on. I rebooted the server last night for some maintenance (new backup exec agent installed required a restart) and after restarting, the same problem has reappeared where users cannot log into Outlook. I can put in the global catalog server and then outlook resolves the proper name and mail server - but why is this happening? I'm guessing it will probably resolve itself on it's own, but I'll poke it with a stick for a while to see what happens. Does the backup exec client have something to do with this? Erik

On Tue, 23 Nov 2010 15:49:34 +0000, Erik Tank wrote: >I disabled the firewall only temporarily and turned it back on after a few minutes - it started working on it's own with the firewall turned back on. > >I rebooted the server last night for some maintenance (new backup exec agent installed required a restart) and after restarting, the same problem has reappeared where users cannot log into Outlook. I can put in the global catalog server and then outlook resolves the proper name and mail server - but why is this happening? I'm guessing it will probably resolve itself on it's own, but I'll poke it with a stick for a while to see what happens. When it stops working, does portqry still show the UUID registered in RPC? >Does the backup exec client have something to do with this? I have no idea. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

The UUID for the directory store no longer shows up under the portqry tool. I guess my question is - why is the rpc port for the directory store not listening. And FYI - it hasn't corrected itself as it did last time. So now I'm really stumped.

On Wed, 24 Nov 2010 15:31:12 +0000, Erik Tank wrote: >The UUID for the directory store no longer shows up under the portqry tool. I guess my question is - why is the rpc port for the directory store not listening. And FYI - it hasn't corrected itself as it did last time. So now I'm really stumped. You can start here: http://support.microsoft.com/kb/839880 Beyond that, it may be best to contact MS PSS for help. The DS Referral and Proxy services may be at the bottom of this. You might try this on the Outlook clients, too: http://support.microsoft.com/kb/319206 Try the "closest" GC setting first. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi, This problem could be caused by the corrupt user profile. Please back up the user's personal files and then remove his local user profile from windows. Then log into windows to create a new profile. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks Gen Lin-MSFT

On Fri, 26 Nov 2010 02:03:04 +0000, Gen Lin wrote: >This problem could be caused by the corrupt user profile. Please back up the user's personal files and then remove his local user profile from windows. Then log into windows to create a new profile. How would that cause the directory service UUID to disappear from the Exchange server? Running portqry to get a list of UUIDs shows the normaly present UUID to be absent from the port mapper. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi, This problem could be caused by the corrupt user profile. Please back up the user's personal files and then remove his local user profile from windows. Then log into windows to create a new profile. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks Gen Lin-MSFT I'm guessing you are referring to the outlook client's profile. I have tried that and no luck, even logging in with a totally seperate user on the machine still has the problem. The real problem is why the UUID isn't showing up for the directory service (TCP port 6004) during a port query. When the UUID was displaying, and the rpcping tool could ping the tcp:6004 port, then all the client profiles worked fine. It is because this RPC port is closed (if its closed) or if the end mapper is out of ports (not sure I fully understand the end mapper stuff), that the clients cannot connect. I created a group policy to hand out the "DS Server" value to a test machine, and sure enough, all clients will work fine with this work around, but it's not the workaround I'm looking for - it's a solution to the RPC port being closed that I'm looking for. I don't do band-aids when I know there's something underneath that's causing damage. I'd rather do surgery to fix it right... All metaphors aside, I know what the problem is, I just don't know how to fix it. Suggestions?

I did some more digging on the internet and found a few things to try which surprised me. When running a dcdiag on any server by themselves, to themselves, there are no errors, but running DCDiag /S:ADServer I get the three errors on all our DC's to each other. Starting test: FrsEvent The event log File Replication Service on server ADServer could not be queried, error 0x6ba "The RPC server is unavailable." ......................... ADServer failed test FrsEvent Starting test: KccEvent The event log Directory Service on server ADServer could not be queried, error 0x6ba "The RPC server is unavailable." ......................... ADServer failed test KccEvent Starting test: SystemLog The event log System on server ADServer could not be queried, error 0x6ba "The RPC server is unavailable." ......................... ADServer failed test SystemLog Also, I ran "netstat -ano" on our exchange server and there are no open ports on 6004 at all. 6001, 6005, 6006, and 6007 are open, but not 6004. Can anyone shed some light on this please? - There are NO errors in the event logs about replication or DNS errors at all. I'm at a loss...

On Mon, 29 Nov 2010 20:07:29 +0000, Erik Tank wrote: > > >I did some more digging on the internet and found a few things to try which surprised me. When running a dcdiag on any server by themselves, to themselves, there are no errors, but running DCDiag /S:ADServer I get the three errors on all our DC's to each other. Starting test: FrsEvent The event log File Replication Service on server ADServer could not be queried, error 0x6ba "The RPC server is unavailable." ......................... ADServer failed test FrsEvent Starting test: KccEvent The event log Directory Service on server ADServer could not be queried, error 0x6ba "The RPC server is unavailable." ......................... ADServer failed test KccEvent Starting test: SystemLog The event log System on server ADServer could not be queried, error 0x6ba "The RPC server is unavailable." ......................... ADServer failed test SystemLog Also, I ran "netstat -ano" on our exchange >server and there are no open ports on 6004 at all. 6001, 6005, 6006, and 6007 are open, but not 6004. > > > >Can anyone shed some light on this please? - There are NO errors in the event logs about replication or DNS errors at all. I'm at a loss... Just curious -- are the times on the DC and Exchange server more than 5 minutes apart? The error codes are all 0x66ba, or 1722 decimal. That says "The RPC server is unavailable." --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

The clocks are all spot on accurate.

On Tue, 30 Nov 2010 16:09:45 +0000, Erik Tank wrote: >The clocks are all spot on accurate. I suggested calling MS PSS before. I'll suggest it again. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich, for all your help. I did call PSS but the problem magically resolved itself again before they contacted me. We were unable to reproduce the problem sadly, so I still do not have a solution to the problem when it happens again. But for now, things are working just peachy. Erik

FWIW, we had exactly the same symptoms as are described here two days ago. In the end, it was caused by following instructions from RIM for migrating a BES Administrator account from 2003 to 2010. Step 5 in this document: http://www.blackberry.com/btsc/dynamickc.do?externalId=KB22601&sliceID=1&command=show&forward=nonthreadedKC&kcId=KB22601#Task5 Contains invalid syntax for the Exchange 2010 SP1 microsoft.exchange.addressbook.service.exe.config file . This caused the Address Book service to fail at startup. Changing the syntax of the change to allowable format allowed the address book service to start, resolving the issue.