Friday, May 31, 2013

Problem with WinRM on Exchange 2013 Management Shell and Exchange Toolbox on a new exchange 2013 with CAFE and BE on single server installation

While deploying MS Exchange 2013 I experienced issues with accessing the Exchange Management Shell and Exchange Toolbox. Whenever I tried to open the Exchange Management Shell I kept get the following error:


VERBOSE: Connecting to Exchange2013.DOMAIN.LOCAL
New-PSSession : [exchange2013.domain.local] Connecting to remote server exchange2013.domain.local failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (exchange2013.domain.local) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.


VERBOSE: Connecting to EXCHANGE2013.LOCAL.COM.
New-PSSession : [exchange2013.domain.local:80] Connecting to remote server exchange-bt.tmal.com failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (exchange2013.local.COM:80) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.


Workaround and Resolution:

Searching the error on Google and all over the web resulted in various and numerous solutions most that worked for there environment but failed to address my issue, but made me realize that this was a Powershell website issue.
Exchange 2013 installs a Default Website (Client Access front End) on port 80 and 443 and also a Backend Website on port 81 and 444.

Here is how i managed to sort out my issue, I had to Change the physical path from: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell to: C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell and then issued an IISRESET.

This is how I went about diagnosing this, with the first Exchange Server 2013 installed and running, I installed a second Exchange 2013 Server with only the Mailbox server role.
On the second Exchange Mailbox server I was able to access the EMS and the Exchange Toolbox successfully.
Now from here on it's simple I only have to do a comparison of the Powershell settings in IIS Manager on these two Exchange servers.

Internet Information Services (IIS) Manager, Sites, Default Web Site, PowerShell and in the Actions Pane, choose Basic setting, physical Paths - on exchSvr1 has C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell while exchSvr2 has C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell on exchSvr1 changed the physical path to C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell

After changing all these i did an iisrest on the exchSvr1 (the affected server) and tried the EMS and Exchange Toolbox, they all worked.

31 comments:

Anonymous said...

Thanks this saved my day!

In my case it was a perfectly working Exchange 2013 CAS/MBX server on Windows 2012 that for some unknown reason went flat.

In this case too, the Powershell directory was pointing to the rontEnd\HttpProxy folder and the WSman module wasn't enabled.

Maybe some windows update forced this to the defaults.

Unknown said...

am happy this did help

Anonymous said...

Great stuff. This one has been annoying me for a long time now. Finally working after your steps.

Anonymous said...

You are incredible, thes best solution in all web.


Tks,

Cjanuzi said...

Damien thanks for your help
I followed your tutorial and everything is working perfectly
obvious and efficient solution
congratulations and thanks

Anonymous said...

Lifesaver, thank you! Changing the physical path was the secret.

Morten Nielsen said...

Thanks, had a similar issue. Had to reinstall the WinRM IIS Extension feature after upgrading from 2012 to 2012 R2.
Path was wrong as well in my case, but will change it back to check.

Btw, a difficult capta thingie

Anonymous said...

Absolute genius! We've been looking for a fix for this for a week!
Now we can access this, we can sort out the corrupted access to OWA and ECP front end.
Thanks!

Unknown said...

Thanks all, you are far too kind

Anonymous said...

Just fix my EMS with this solution. Thank you.

Anonymous said...

You Star ! Step 3 saved the Day for me - Thanks

J said...

This was right on time...Thanks so much for this post....I'd been searching for awhile for a solutions...now I can continue on with building out my Exchange 2013 Lab...

Tyler said...

This guy.... You deserve several gold stars! This fixed my issue after updating my EWS randomly decided to faceplant.

<3

wedge said...

Hi Guys. Found my fix to this. I set a proxy in the default winhttp of netsh and this causes 404 and the above error. reset it with "netsh winhttp reset proxy". Fixed the issue!

Anonymous said...

This is a lifesaver. Thank you so much for sharing this.

Anonymous said...

Been locked out of my exchange management shell for around a month (everything else worked perfectly but all other help on the web pointed to WinRM IIS extensions)
This fixed my issue in 2 minutes flat

Thank You for posting your solution.

Anonymous said...

Thanks so much. Worked for me too!

Bella73 said...

After spending about 30 hours trying to fix this I came upon your post. It worked like a charm. Thank you, thank you, thank you!

Unknown said...

You go for president? I vote you! Thank you.

Anonymous said...

my issue was resolved.

Unknown said...

[Solved]

Stop SharePoint on the Exchange server!

Open IIS Manager, stop SharePoint-80, start Default Web Site, and the error is gone!

Dave said...

Works as well on my Exchange server.
Funny though it is working on another Exchange server with the first path
There might be something else...

Anonymous said...

The issue was resolved. Thank you very much!

Anonymous said...

Thanks. Life saver.

Anonymous said...

New-PSSession [RODC-mridf] The connection to the remote server RODC-mridf failed with the error message
Hi ! Soory but I have this issue after have done your fix :

Any idea ?

Web services and got a response that the HTTP URL was not available. This response is ha
WS-Management. For more information, see about_Remote_Troubleshooting help.
The character line: 1: 1
+ New-PSSession -cn RODC-mridf
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo: OpenError (System.Manageme .... RemoteRunspace: RemoteRunspace) [New-PSSession
     + FullyQualifiedErrorId: URLNotAvailable, PSSessionOpenFailed
Microsoft.PowerShell.Core \ FileSystem :: \\ web-mridf \ powershell ---------------------------------- -----------

Joel said...

Cheers matey this one worked great, it could have been a combination of netsh winhttp reset proxy and the wrong URL set in IIS for powershell for me.

MJackmond@MyFireRules.NET said...

I JUST got off the phone with Microsoft, and this problem (for ME) was all
because the PDC and the Exchange Server were NOT "TIME synchronized"!!!
IF the Exchange Server is OFF by 6+ minutes THEN you will have this problem
as well as EMAIL to the Outside WILL STOP!

This article
(https://technet.microsoft.com/en-us/library/cc816884(v=ws.10).aspx)
provided my answer. (My PDC had ALREADY been configured to use an
"authoritative Time", but apparently all my other Servers were NOT being
told to "Look to the PDC for your TIME".
ON ALL your DCs and ALL your Servers, open a "Command Prompt (Admin)
and type the , type the following 3 lines (hitting enter after each
command): (each one will take a second or 2 to complete)

w32tm /config /syncfromflags:domhier /update (Enter)
net stop time (Enter)
net start time (Enter)

Do ALL the DCs FIRST, then do the Exchange Server.

Then you MUST reboot the Exchange Server for this to have an effect
for Exchange. After Rebooting and waiting until ALL the services
have come back up, I was again able to open "Exchange Management Shell"
and "Exchange Toolbox"!

Hope this helps someone!

Miloslav said...

Thank you for you help. It was the same problem for me. Apperently there is something wrong during installation. I did try twice to install server and exchange and always ended up with the same issue. Thanks to you I was able to solve it!
thx

Unknown said...

I can confirm this worked for me!!!

All the other fixes on the Internet did not help like re-installing WinRM, re-installing exchange, Kerberos enable/disable.

This worked 100%.


Thank you
Mike

kayal said...

Nice Article
aws course in Bangalore

aws training center in Bangalore

cloud computing courses in Bangalore

amazon web services training institutes in Bangalore

best cloud computing institute in Bangalore

cloud computing training in Bangalore

aws training in Bangalore

aws certification in Bangalore

best aws training in Bangalore

aws certification training in Bangalore

baresfuertoner said...




Nice post. Thanks for content creator.
aws training london