Exchange 2010 SP1 RPC problems

I have a (possibly reoccurring) problem with our Exchange 2010 SP1 box.  The server hosts all roles (hub transport).  The problem started last week where after I restarted the server for maintenance, random Outlook clients could not connect.  When trying to setup a new Outlook account (even deleting all old profiles) the username could not be verified with the exchange server.  We have RPC encryption turned on via group policy for the legacy 2003 clients, and even some of the 2007 and 2010 users have problems.  But only certain people are affected by this - while others continue to connect and work without problems.  Some are marked as offline, and have no way of changing it to "online" as there normally is.

I've narrowed it down to it being an RPC error due to running portqry and finding no connection to the UUID: f5cc5a18-4264-101a-8c59-08002b2f8426 MS Exchange Directory NSPI Proxy ncacn_ip_tcp:srvr005[1158]

The command I ran was "portqry -n (exchange server) -e 135"

I say this is a reoccurring problem because it happened one other time, last week.  The last time this happened, the problem resolved itself after about 8 hours.  Today, we are still having the problems this time well after 8 hours.  I'm losing faith that it will resolve itself this time.  

Strange thing is - we can setup an Outlook client successfully if we put the global catalog server in as the exchange server in a new outlook profile and then the username resolves and the correct exchange server name maps properly.  Email works happily after this is done.

Can anyone provide any insight as to why this is happening and how to resolve the problem correctly?  I've already gone through a MS article which describes registry entries and proper DLLs in place.  Since this resolved itself last time - I still feel as though it may resolve itself this time, but want to be able to restart my exchange server without this problem (and on the off-chance it doesn't start working, to help fix it)

Thanks in advance,
Who is Participating?
lastlostlastConnect With a Mentor Commented:

As per the above article, create the following key:
HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider

On the Edit menu, click Add Value, and then add the following registry value:
Value name: DS Server
Data type: REG_SZ (string)
Value data: FQDN of the global catalog server

P.S: this needs to be done on the OL client that is having issue.

Let us know how it goes.
Schnell SolutionsSystems Infrastructure EngineerCommented:
Do you use NLB?

You have some clients working and other ones not, do all of them belong to the same AD Domain, network segment and has the same TCP/IP configuration?

etank52Author Commented:
we do not use Network Load Balancing and all users are on the same domain, same subnet.  We have five buildings, each with their own AD servers, and the network subnet is 10.x.0.0/16.  The x differentiates the different buildings.  
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

etank52Author Commented:
Lastlostlast, This seems to have fixed the outlook client to connect and verify the mapping of the useraccount/servername when setting up an outlook profile.  But why is the rpcping not working still, and why doesn't it happen consistently?  Once the rpcping works, this registry value is not needed... I'm more concerned as to why rpc is not responding (tcp: 6004)... as I stated, I can get the outlook client to connect by putting in a domain server in the servername field of an outlook profile setup, but my main concern is why or how rpc is not working and no UUID of f5cc5a18-4264-101a-8c59-08002b2f8426 is being displayed as a connection via a portqry.  

I don't have a lot of experience with most of this so perhaps it's all in an explanation, but up until a week or so ago, we never had this rpc problem.  I rebooted the server due to a backup exec agent update, which I have already removed for testing purposes (which didn't fix anything).

My understanding of rpcping is that TCP:6004 is the directory store, where TCP:6001 is the information store... the 6001 pings fine, but the 6004 fails.  Why would everything start working again last week a day after it started having errors without any registry changes?
etank52Author Commented:
For some further background info - we had RODC's at our outlying buildings, but now we have a 50MB fiber connection between buildings and have demoted the RODC and promoted it to a standard DC.  They are all handling global catalogs as well.  

Replication appears to be just fine, no errors about replication at all.  It seems to me that now that there are multiple options for domain writ-ability, that this problem has surfaced.  I hope this information helps solve the problem.

1. Have you restarted the Exchange Servers after the promotion/demotion of the DC's?

You are correct, 6004 is for Directory Services. I would suggest you perform a dcdiag from the Exchange server and check if there are any errors that are logged in...
You can also perform a 'netstat -ano' and check which process is using port 6004. We should only have mad.exe (MS Exchange SA) listening on that port.

Let us know how it goes.
etank52Author Commented:
There are three failures when doing a DCDiag /S:ADServer

      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

For the netstat -ano there are no open ports on 6004 at all.  6001, 6005, 6006, and 6007 are open, but not 6004.

etank52Author Commented:
When I run DCDiag from any of my domain controllers and use the /s:servername method to check the other servers, I get the same three failures - FRSEvent, KCCEvent, SystemLog.  But on all of the domain controllers there is no hint or error at all as to there being a problem... everything is replicating properly as far as I can tell.  

Any pointers?
Hmm.. To be honest.. I am not good with AD.. so will not be able to comment on the DCDIAG errors. I suggested running DCDIAG hoping it would give you a clue. :-)

In regards to Exchange, Can you disable all 3rd party services using MSCONFIG and restart the server once and check if we still face the same issue?

Let us know how it goes..
etank52Author Commented:
Well, situations have popped up that have confused me to no end.  I decided to turn on IPv6 on all the DC's and the exchange server.  I restarted the server, rpcping still failed, UUID didn't show up in port query.  I enabled our second NIC, turned it to DHCP, disabled it again (it's not even plugged into the network)... restarted - same problems persisted.  Backup Exec fails to run if I have dhcp on the second nic, so I changed it back to static, restarted and now everything is perfect.  RPCPing works on 6004, UUID shows up under port query, all the outlook clients are connecting again without fail.  

I changed it back to break it again intentionally - still works.  I swap it back again - still works.  Now I cannot seem to make it fail any longer.

The same three errors are listed above when I run a DCDiag /s:ADserver from any of the AD servers, or the exchange server.  But I've tested replication, dns, etc - there are no issues with replication at all.  It looks like the original problem with the rpcping has cleared itself up, or the changing of the NIC adapter triggered something.  

The only thing left that does not work is adding a second mail database.  It fails to do that still, so something isn't kosher yet.  Should I open a new case for the other problems?
etank52Connect With a Mentor Author Commented:
I called MS PSS and the problem resolved itself before they called me back.  They were unable to duplicate the problem, therefore we do not have a resolve for this item.  If it comes back again, I was instructed to call them back and open a new case to resolve the issue.

As far as the errors with AD, the AD team at MS did not find any fault with the current setup.  The exchange team did not find any faults either.  Things seem to be rolling smoothly.

Since this problem doesn't appear to be coming back, I will close this case.

Thank you,
Points for comment # 34200707.

I believe the points should be shared.
etank52Author Commented:
The outlook clients connecting wasn't the reason for the post - the post was for RPCPing failing on port 6004.  The registry workaround in post # 34200707 was not used to fix this RPCPing issue.  In the original post, I noted that I already had a method for clients to connect (by using the DC name in place of the exchange server).  The real problem was to get the directory service open and able to connect, and show up via a port query.  No solution for this was given, and I cannot find a way to reproduce the error.

On the other hand you did provide an alternate solution to the *effect* of the problem, so I will award partial points.
etank52Author Commented:
Partial points awarded for alternate method of solving the effect of the problem, not full points since the cause of the problem was not solved.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.