On Premise Exchange error preventing users from using Email

This morning during a computer installation I was receiving an error "An Attempt to Resolve the DNS name of a Domain Controller in the domain being joined has failed". Even though I had entered in the correct DNS to join the domain. After a search there was an article suggesting refreshing the DNS reverse lookup zone. After performing the refresh, the users on premise exchange server began giving the error of "The attempt to connect to http://exchange.contoso.com'/powershell using 'Kerberos' authentication failed: Connecting to the remote server failed with the following error message : WinRM cannot process the request. The following error occurred while using Kerberos  authentication: The network path was not found."
Currently the client has been down for 3 hours without email and there is nothing out there that I have found that resolves the issue.
Was the refresh of the DNS reverse lookup that caused this issue or is that just coincidence. Has anyone found a solution to this issue or encountered this before?
Jake ValineAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Wayne88Commented:
Try adding a PTR record manually to point to the Exchange server to get them back up and running.  

Here is how:  Adding a resource record to a reverse lookup zone
0
Justin StearCommented:
Have you tried the solutions from: http://blogs.technet.com/b/whats_on_scotts_mind_today/archive/2012/12/07/exchange-2010-unable-to-open-exchange-management-console-initialization-failed.aspx 

Resolutions:

Method 1:

Close all MMC/EMC instances before proceeding.
Open Registry Editor (regedit) as the user you run the EMC under.
Go to
HKEY_CURRENT_USER\SOFTWARE\Microsoft\ExchangeServer\v14\AdminTools
Look for value NodeStructureSetting.
If it is there, back it up and then remove it.
Method 2:

Close all MMC/EMC Instances before proceeding.
Open Powershell or Powershell IDE as the user you run the EMC under and execute the following command:.
Remove-ItemProperty -Path HKCU:\Software\Microsoft\ExchangeServer\v14\AdminTools\ -Name NodeStructureSettings
Close Powershell
After performing either of the methods above to remove the registry entry you should be able to open the Exchange Management Console and it will discover another Exchange server and connect.
0
Wayne88Commented:
The problem described is not an MMC issue.  This is a problem relating to the Outlook client finding and connecting to the server on the network.

Jake, try adding a PTR record as described here:

https://technet.microsoft.com/en-us/library/cc844045(v=ws.10).aspx
0
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.

Jake ValineAuthor Commented:
I appreciate the feedback. I did indeed try the second suggestion, but that resolved nothing unfortunately. I am currently rebooting the server, though it is taking a bit longer than desired. I will give the PTR a try and post my results. Thank you very much for the suggestions.
0
Wayne88Commented:
Let us know how it goes.  Good luck.
0
Jake ValineAuthor Commented:
Hey guys, so here is the update. The issue is now strictly the on premise Exchange 2010. It displays the error "Connecting to remote server failied with the following error message: The WinRM client received an HTTP server error status (500), but the remove service did not include any other informaition about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'."

I checked the Powershell in IIS and the path is correct, and I checked the EMC in Environmental properties and that path is correct as well. I installed WinRM in IIS because it wasn't there before. But still receiving the same error as above. I will literally send baked goods to who can help on this one.
0
Justin StearCommented:
I'm seeing that a lot of people are uninstalling and reinstalling WinRM, which fixes this issue.  I'm going to just post a link to the technet forum I was just reading, as a there are a bunch of different solutions people have come up with that worked.  You may have already seen this, but it may help.

https://social.technet.microsoft.com/Forums/exchange/en-US/5b82f131-b469-4661-9d6c-1c1c7939b73a/the-winrm-client-received-an-http-server-error-status-500?forum=exchange2010

For the sake of clarification, I'm assuming the properties and path you are reffering to are:
ExchangeInstallPath = C:\Program Files\Microsoft\Exchange Server\V14\
PowerShell virtual directory under Default Web Site = \Program Files\Microsoft\Exchange Server\v14\ClientAccess\PowerShell
0
Jake ValineAuthor Commented:
Hey Justin,

Yes I have found that forum. I did give it a try, but to no avail.
0
Justin StearCommented:
What other roles are install on this Server?  What OS is it?  Any events in the event viewer stick out?
0
Jake ValineAuthor Commented:
Using Server 2008 R2 with SBS 2011
It plays as AD, DHCP, DNS, IIS, and of course On premise Exchange
0
Justin StearCommented:
Looks like a fellow member of EE had this same issue, may not be bad to take a look through his troubleshooting as well if you haven't already.  
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Q_27944959.html
0
Wayne88Commented:
Hi Guys,

Ok, I was busy all morning.  First off, I think we are deviating from the real problem.  Jake mentioned that the problem started because the server cannot resolve the dns name of the DC and I still think that's the root cause here.

The WinRM is: "Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems, from different vendors, to interoperate."

I don't see it being related to the root cause to the problem and uninstalling something we're not sure if it's broken or not was how the whole came about.  So let's get back to the main issue.

However, note taken that WinRM is problematic now but let's fix the first issue.

Jake, can you ping the domain controller using computer name?  That's as basic as you can get so if you can't even ping the DC using its hostname then it can cause a lot of problems in your network aside from Exchange including Exchange Auto Discover.

Wayne
0
Jake ValineAuthor Commented:
Hey Wayne,

Yes. I believe I was able to resolve the DNS manager issue with your PTR suggestion, but the exchange portion of it is now playing as the only factor left. It's driving me bananas. Spent all night and now most of this morning trying to figure this out.
0
Wayne88Commented:
Hi Jake,

Ok great, let's takle the second problem.

First thing I normally do when troubleshooting anything at all is to turn off any antivirus, endpoint security and firewall on the machine.  Can you give that a try?

Can you run from elevated CMD prompt:

"winrm e winrm/config/listener" this will show which port and IP addresses WinRM is listening to.  Can you verify the port is not blocked?

"winmgmt  /salvagerepository" this will check WinRM for any problem.  What's the result?

"winrm get winrm/config" this will show the WinRM configuration.

Also check out WinRM (Windows Remote Management) Troubleshooting: http://blogs.technet.com/b/jonjor/archive/2009/01/09/winrm-windows-remote-management-troubleshooting.aspx

Wayne
0
Jake ValineAuthor Commented:
Hey Wayne and everyone,

So we ran the commands and they came back clean and seemed okay. However after extra digging in the services we saw that 3 services are stuck at "starting" and won't actually start. Throttle, Address Book, and Transport. I have tried stopping them, changing it to manual, restarting the service, but nothing seems to take. I think this might be apart of the problem.

Any suggestions?

- Jake
0
Wayne88Commented:
Hi Jake,

Is it possible to restart the server?  Are the 3 services dependent on each other?

Wayne
0
Jake ValineAuthor Commented:
Hey Wayne,

Yes it is possible to restart the server, though we have already done that multiple times and unfortunately the issue remains. Tried stopping/starting from the command line as well, but unfortunately still unable to.
0
Wayne88Commented:
Hi Jake,

Ok, I didn't know the server was restarted.  I just checked an Exchange 2007 and I don't see those services.  Are those services set to automatically start and never started?

Yours is Exchange 2010 correct?  I will try checking that.

Wayne
0
Jake ValineAuthor Commented:
Correct, they are set to start automatically. However they are stuck at "starting" so they never finish. Not sure why or what caused this issue to occur.
0
Wayne88Commented:
Jake, I still think the issues with those services are still related to the DNS problem.  Can you go to the Event viewer and look for Event ID:2121 or any messages along the line "The Microsoft Exchange Active Directory Topology service on server localhost did not return any suitable domain controllers"?  If so then it confirm my suspicion that it cannot find or resolve the DC name.

I can also be an IPV6 issue that's causing the DNS and all these problems because it take precendence over IPV4.  You can disable IPV6 for testing to confirm that this may be the problem but I've heard it can create issues to let's just disable it for testing if this fix the problem then just configure IPv4 as default over IPv6.  

Another thing to check too is to ensure the time sync of your Exchange server with all your DC or DCs are the same, time issues can prevent a service to start if the Exchange server is off by minutes while all the other servers are sync to a different server.  Best to point all server to a common NTP server (the Exchange or a DC).

Let's give that a try.
0
Jake ValineAuthor Commented:
Hey everyone,

To quickly resolve this issue as it had kept clients down for two days we used a backup point from an imaging software to restore to the day prior to the issue occurring. As that was the last time it worked properly. The restore worked and the clients are back up and running smoothly. Thank you for you suggestions and help. This has been a very educational process.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.

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.