none
Exchange Management Shell fails to connect to Exchange Server 2013

    Question

  • Hi,

    I have installed Exchange Server 2013 on the 2012 Server successfully. The Exchange server is joined to a domain and logged in as domain administrator. I can login to Exchange Admin Center configured and OWA with no problem. I have configured the Exchange Server with multiple mailboxes and everything works fine.

    When I launch Exchange Management Shell, it fails to connect to Exchange Server 2013 and following error message is given.

    VERBOSE: Connecting to EXCHANGE2013.testlab1.local.

    New-PSSession : [exchange2013.testlab1.local] Connecting to remote server exchange2013.testlab1.local failed with thefollowing error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos uthentication mechanism, but the destination computer (EXCHANGE2013.testlab1.local: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.

    At line:1 char:1

    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...

    I looked through many topics and follow many suggestions, but no luck so far.

      
    Tuesday, April 2, 2013 7:27 PM

All replies

  • Hi,

    I have installed Exchange Server 2013 on the 2012 Server successfully. The Exchange server is joined to a domain and logged in as domain administrator. I can login to Exchange Admin Center configured and OWA with no problem. I have configured the Exchange Server with multiple mailboxes and everything works fine.

    When I launch Exchange Management Shell, it fails to connect to Exchange Server 2013 and following error message is given.

    VERBOSE: Connecting to EXCHANGE2013.testlab1.local.

    New-PSSession : [exchange2013.testlab1.local] Connecting to remote server exchange2013.testlab1.local failed with thefollowing error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos uthentication mechanism, but the destination computer (EXCHANGE2013.testlab1.local: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.

    At line:1 char:1

    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...

    I looked through many topics and follow many suggestions, but no luck so far.

    • Merged by emma.yoyo Wednesday, April 3, 2013 7:52 AM duplicated
    Tuesday, April 2, 2013 7:45 PM
  • The Exchange server is joined to a domain and logged in as domain administrator.

      

    Hi Hamid,

    If you use another account which is assigned the Organization Management permission and log to to the server, what's the result?


    Frank Wang
    TechNet Community Support

    Wednesday, April 3, 2013 7:45 AM
  • Hi Frank,

    I created another account (exchange2013admin) assigned with Organization Management Permission and same issue with the same error message occurred. On the new account I assigned other permission like Administrators, Domain Admin, Enterprise Admin, Server Management, ...etc and same result is observed. 

    Regards,

    Hamid 

    Wednesday, April 3, 2013 2:08 PM
  • Hi,

    got the exact same issue in my test environment.

    After it fails to connect to the local machine it goes out and connects to one of the 2k10 servers.

    When i try to login to ecp it redirects to a 2010 interface, i have to manually edit the url to https://<fqdn>/ecp/?ExchClientVer=15

    same if I install another cas only machine

    Installed ex2k13 cu1 in an existing ex2k10 sp3 configuration.

    Been trying to fix this since cu1 was released yesterday non stop. no luck yet.

    I am a bit disappointed. Brand new server 2012 and exchange 2013 installation following technet how-to and first thing I have to do is troubleshoot :(

    ill keep trying


    edit:

    created a test user directly though 2013 ecp and tried to login to owa.

    this is was i get:

    A mailbox couldn't be found for NT AUTHORITY\SYSTEM. If the problem continues, contact your helpdesk

    edit2:

    maybe this is relevant.

    first I installed a mailbox only box, then a cas box. Then i added cas to the mailbox server.


    • Edited by intrepid656 Wednesday, April 3, 2013 5:41 PM
    Wednesday, April 3, 2013 5:29 PM
  • did you install the WINRM feature from server manager?

    Where Technology Meets Talent

    Wednesday, April 3, 2013 9:05 PM
  • Hi,

    yes it´s installed.

    WinRM-IIS-Ext



    • Edited by intrepid656 Thursday, April 4, 2013 6:59 AM
    Thursday, April 4, 2013 6:58 AM
  • Hi,

    the same happened to me when I remove defaults ssl certtificates.

    If you do so, go in IIS mmc and right click the "Exchange Back-End " site > Edit links > Https > Edit. Then select your certificate.

    Thursday, April 4, 2013 7:07 AM
  • Did not remove the default cert, its still there.
    Thursday, April 4, 2013 8:15 AM
  • You may want to remove and re-install the WinRM. I faced the same issue and was able to fix it.

    http://www.exchangeitpro.com/2013/02/24/exchange-2013-the-winrm-client-received-an-http-server-error-status-500-but-the-remote-service-did-not-include-any-other-information-about-the-cause-of-the-failure/


    Where Technology Meets Talent

    Thursday, April 4, 2013 7:43 PM
  • Hi,

    thx for the tip.

    No change though.

    edit:

    well after a lot of searching i noticed that wsman module was not enabled for powershell virtual directory in iis.

    I enabled it and now I get

    The WinRM client received an HTTP server error status (500)

    Removing and reinstallin winrm iis extension does not help.

    edit2:

    found an error in the logs that at least makes sense. but no luck fixing it so far.

    The WSMan IIS module failed to read configuration. The error received was -2144108477: %%-2144108477
     The configuration XML is not valid. The XML element: "Plugin" is expected but not found..

     User Action
     Make sure both the schema and validation files are present and valid.


    edit 3:

    modified my web.config file in iis root according to http://msdn.microsoft.com/en-us/library/windows/desktop/ee309364%28v=vs.85%29.aspx

    guess what.. now i get a new error :)

    The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid


    • Edited by intrepid656 Saturday, April 6, 2013 12:50 PM
    Saturday, April 6, 2013 8:20 AM
  • ..  I manually loaded the pssnapin, removed mailboxes, deleted the database and uninstalled exchange.

     Add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.E2010

    (Yes its called e2010 for exchange 2013)

    Im going to remove the server from ad, delete the vm and start from scratch.

    Sunday, April 7, 2013 12:26 PM
  • Thanks everyone for all your tips.

    I did try above tips and I still get the same error message as shown below. Any idea? Thanks again for everyone help.

    VERBOSE: Connecting to EXCHANGE2013.testlab1.local.

    New-PSSession : [exchange2013.testlab1.local] Connecting to remote server exchange2013.testlab1.local failed with thefollowing error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos uthentication mechanism, but the destination computer (EXCHANGE2013.testlab1.local: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.

    Monday, April 8, 2013 1:48 PM
  • I have performed 3 fresh installs now.

    2 on server 2012 and 1 on 2008r2 and still get the same error as you.

    Tried manually installing all prerequisites before and letting setup do it, I tried installing rtm first and then update to cu1, same error.

    This is driving me nuts.

    Monday, April 8, 2013 4:54 PM
  • I know how frustrating it is. I ran into the same issues couple  of time and adding the WInRM worked for me.

    Are you installing separate CAS and mailbox server and all in one?

    From the GUI make sure there are no issues with the cert or delete and create new self-signed certs.


    Where Technology Meets Talent

    Monday, April 8, 2013 5:26 PM
  • Hi Guys,

    Is anything else using port 80 on your server?

    Cheers

    Hardeep.

    Tuesday, April 9, 2013 2:48 PM
  • it should be using 443

    Where Technology Meets Talent

    Tuesday, April 9, 2013 3:18 PM
  • Hi all,

    I have same problems,

    No error when installation Exchange 2013 Coexist

    always had the same error when fresh install

    please help

    Thanks

    Ichwan

    Wednesday, April 10, 2013 1:17 PM
  • HI, 

    I am having the same problem and have done everything you guys said, but still nothing, just wanted to let you know that you aren't the only one who has these problems 

    Sunday, April 28, 2013 6:44 PM
  • Is it meant to connect to port 80 "(EXCHANGE2013.testlab1.local:80)" because when i try accessing the http://localhost:80 on my exchange server it comes back with 

    HTTP Error 403.4 - Forbidden

    The page you are trying to access is secured with Secure Sockets Layer (SSL).


    Sunday, April 28, 2013 6:53 PM
  • I'm having the same problem as well...
    Monday, April 29, 2013 10:46 PM
  • I have come across the same issue.  Still troubleshooting it. 
    Friday, May 3, 2013 8:53 AM
  • I'm currently working on this issue with Microsoft Support, will post the results once its resolved.
    Monday, May 6, 2013 4:32 PM
  • So we got the issue fixed last night, for me the issue was that the "Organization Management" group had some risdual AD objects and some users that weren't suppose to be in there, as well it was a member of other groups. So we removed all objects from "Members" and "Members Of" and added only the "Administrator" user to "Members" and added the Administrator group to "Members Of", forced an AD sync since we have multiple DC's, restarted the Exchange machine and bim bam boom it worked =D I can finally get some sleep....

    I really hope this helps someone.

    • Proposed as answer by intrepid656 Tuesday, June 11, 2013 5:42 PM
    Tuesday, May 7, 2013 3:02 PM
  • Please Try running this:


            PSH> winrm set winrm/config/client `@`{TrustedHosts=`"`*`"`}

    Sounds like you need to open up the client connection permissions.

    You may not want to open it up to anywhere though.
     this should also work:

          PSH> winrm set winrm/config/client
          `@`{TrustedHosts=`"server1_IP,server2_IP"`}

    • Proposed as answer by Lakhan S Wednesday, May 8, 2013 4:47 AM
    Wednesday, May 8, 2013 4:47 AM
  • Additionally i would like to share the results of everything we did during troubleshooting.

    Problem:

    =======

    “Unable to Access Exchange Management Shell on Server 'EX2013'”.

     

     

    Environment:

    ===========

    Windows Server 2012

    Exchange Server 2013 CU1

     

     

    Resolution:

    =========

    o   Issue was ““Unable to Access Exchange Management Shell on Server 'EX2013'”..”

    o   We were getting error “FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed” while accessing EMS, However OWA and EAC was working fine.

    o   We were also not able to see Exchange 2013 server when we run Get-ExchangeServer from Exchange 2010 Shell.

    o   Verified the firewall was disabled.

    o   Verified the Network configuration.

    o   All the exchange services were present and started.

    o   You were logged in with an account had Admin rights hence we logged off and logged back in with ‘Administrator’ account but still the same issue.

    o   Added host entry but still had same issue.

    o   We ran below command to check the Remote connectivity from the effected server.

     

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2010 server>/PowerShell/ -Authentication Kerberos -Credential $UserCredential

     

    o   We had the same issue.

    o   Then we removed and reinstalled the exchange server completely but still had the same issue.

    o   Later we formatted the box completely and installed everything again but still had the same issue.

    o   Ran ‘winrm quickconfig ‘ to check the WinRM configuration found it correct.

    o   Ran below commands to add exchange snapin for exchange.

     

    Add-pssnapin Microsoft.Exchange.Management.PowerShell.E2010

    Add-pssnapin Microsoft.Exchange.Management.PowerShell.SnapIn

     

    o   Ran Get-User icons-svc | fl Name, *rem* found RemotePowerShellEnabled : True

    o   did IISreset But still had the same issue.

    o   Ran netstat -a to check port 80, which was open.

    o   Verified the IIS, Default Web Site was started.

    o   Verified the WSmen Kerbauth was Native and Local under powershell Virtual Direcotry in Modules.

    o   Bindings were correct on Default Website.

    o   Ran below command to enable .Net framework 4.0

    %SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable

    o   Did IISreset and rebooted the server but still had the same issue.

    o   Downloaded and ran Procmon took the PowerShell traces verified found there were permission issues and getting Access Denied errors.

    o   Verified all the permission on below mentioned locations

     

    14:01:14.0601232 powershell.exe 13020 RegOpenKey HKLM\System\CurrentControlSet\Services\WinSock2\Parameters ACCESS DENIED Desired Access: All Access

    14:01:13.9446459 powershell.exe 13020 RegOpenKey HKLM\SOFTWARE\Microsoft\ExchangeServer\v15\Transport ACCESS DENIED Desired Access: Read

    14:01:13.9348908 powershell.exe 13020 RegOpenKey HKLM\SOFTWARE\Microsoft\ExchangeServer\v15\FIP-FS ACCESS DENIED Desired Access: Read

     

    o   found all of them correct.

    o   further went to verify the permission and Group Membership on trusted subsystem and members of organization management group.

    o   Found a security Group 'Exchange Installed Domain Servers' added as Member of ‘Organization management’ Group.

    o   Hence removed that Security Group and there were other accounts added in same group hence removed them also.

    o   Force the replication using repadmin /syncall /AdeP.

    o   Rebooted the server once.

    o   Now we were able to connect EMS successfully.

    o   Ran Get-ExchangeServer we could see both the servers now.

    o   Then we were testing mailbox migration but got an error as Migration mailbox missing.

    o   Ran setup.exe /preparead to create the same.

    o   Ran the below commands to enable arbitration on the same.

     

    Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136"

    Set-Mailbox "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" -Arbitration –Management:$true

     

    o   Now initiated the migration and completed successfully.



    • Edited by radray Wednesday, May 8, 2013 12:24 PM
    Wednesday, May 8, 2013 12:24 PM
  • Same issue here.

    I tried all steps mentioned here and nothing worked.

    If I add wsman module the error change to HTTP server error status (500) as intrepid656.

    Lab environment with Windows Server 2012 DC and 2 Mailbox/CAS members of a DAG. Both servers have this issue.


    Dario Woitasen | MCSE Lync Server 2013 | MCITP: Enterprise Messaging Administrator 2007/2010, Lync Server 2010 Administrator

    Wednesday, May 8, 2013 9:03 PM
  • So we got the issue fixed last night, for me the issue was that the "Organization Management" group had some risdual AD objects and some users that weren't suppose to be in there, as well it was a member of other groups. So we removed all objects from "Members" and "Members Of" and added only the "Administrator" user to "Members" and added the Administrator group to "Members Of", forced an AD sync since we have multiple DC's, restarted the Exchange machine and bim bam boom it worked =D I can finally get some sleep....

    I really hope this helps someone.

    Hi,

    I know its been a while but I want to confirm that this was the solution for me. THANK YOU !!!

    We have a big migration project coming up so I rebuild the customer network in a lab and everything was working fine. Installed first mailbox and cas server, all fine. Added second mailbox server and began to build out dag, got lazy and wanted to put the witness on the dc so I added the "Exchange Trusted Subsystem" Group to "BUILTIN\Administrators". DAG installation worked fine.

    Added second CAS Server and got the WinRM Error again.

    Removed the group membership, moved witness share to one of the cas servers and rebooted CAS-02.

    Everything is working fine now.

    Tuesday, June 11, 2013 5:48 PM
  • I had problems with EMS connecting to server too. Found this article and it worked immidiately:

    http://dbanda.blogspot.com/2013/05/problem-with-exchange-2013-management.html

    I have mixed 2007 and 2013 environment where 2013 server only has one native test user. i cant acces this user via owa, I get no mailbox found error with NT AUTHORITY\SYSTEM. another weird thing: I accidentaly entered that temporary user's credentials into ecp window and it opened Ehchange administration page without a problem. And it appears that this temporary user has full rights on the exchange management. I checked user in AD and found that it only belongs to domain\users group.

    Tuesday, July 9, 2013 11:15 AM
  • Same Error here:

    Problem everything installed on the same machine:

    Solution:

    IIS Manager | Default Website | PowerShell

    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

    After the change: IISRESET 

    Regards Lukacs

    • Proposed as answer by radray Wednesday, September 18, 2013 11:51 PM
    Wednesday, September 11, 2013 2:49 PM
  • Same Error here:

    Problem everything installed on the same machine:

    Solution:

    IIS Manager | Default Website | PowerShell

    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

    After the change: IISRESET 

    Regards Lukacs

    THANK YOU!!!! i thought i'd never get this fixed. you the man =D
    Wednesday, September 18, 2013 11:52 PM
  • Same Error here:

    Problem everything installed on the same machine:

    Solution:

    IIS Manager | Default Website | PowerShell

    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

    After the change: IISRESET 

    Regards Lukacs

    Thank YOU !!!!!!! this was nowhere near to what i was thinking !

    Worked like a CHARM!! saved me a lot of time :)

    Tuesday, October 1, 2013 7:36 AM
  • Solution:

    IIS Manager | Default Website | PowerShell

    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

    After the change: IISRESET


    Kirpal Singh

    Sunday, January 5, 2014 6:43 AM
  • This helped SO MUCH. I changed my certificate on the Exchange server to one created by our certificate authority so anything on the domain would trust it and it broke the server hard. Thanks a ton, this was very useful.
    Sunday, August 10, 2014 3:49 PM
  • Look, here's another solution.

    Open a Powershell session as Admin

    Run this command:

     POWERSHELL>$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://YOURSERVER/PowerShell/ -Authentication Kerberos -Credential $UserCredential

    POWERSHELL>Import-PSSession $Session

     POWERSHELL>Add-PSSnapin microsoft.exchange.management.powershell.snapin

    And Voila!

    Than will let you work as Exchange Management Shell, same commands.

    Good luck

    EDIT: If you are working logged in your exchange server, just type the last command on powershell:

    Add-PSSnapin microsoft.exchange.management.powershell.snapin

    Regards


    Monday, September 7, 2015 6:05 PM
  • 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!

    Saturday, September 19, 2015 7:23 AM
  • I had exact same problem and found that my Virtual directories for the front end and backend of powershell in IIS were different after a Powershell virtual Directory reset via EMC.  the reset changed front end but not back end regardless I'm not sure the proper directory by my powershell lies in the V15\ClientAccess directory but the reset put the frontend powershell in the V15\Frontend\HttpProxy\ causing the WinRm error and snapins not to work. I moved the front end directory to where it was before the powershell virtual directory did IISREset and BingBangBam every thing works. I'm sure this could've been fixed via config file somewhere but wasted enough time troubleshooting.
    Monday, June 6, 2016 1:17 PM
  • Appreciate you posting the solution. Thank You much!

    This solved my issue on an exchange 2016 box.

    Regards,

    Arnel

    Monday, August 21, 2017 12:26 PM
  • Hi All,

    I faced same issue in Exchange powershell and fixed also.

    i found certficate was not set in backend directory with bindings section..


    Kirpal Singh

    Tuesday, May 29, 2018 1:20 PM
  • Same issue:
    Try to you a program from CodeTwo to copy/sync a old Exchange2003 (SBS2003) to EX2012CU21.
    Program give every time the Msg: PowerShell Access forbitten (Code 401).

    Solution was simple:

    How to allow PowerShell to connect to Exchange Server over IP address:
    Problem:
    You need to be able to connect with PowerShell to your on-premises Exchange Server by using its IP address instead of its FQDN or hostname.

    Solution:
    In order to allow PowerShell to connect remotely over an IP address, PowerShell Virtual Directory in IIS must be configured for basic authentication. Follow the steps below to do that:

    1.Run  Exchange Management Shell on the Exchange machine to which you want to connect over the IP address.
    2.Execute the cmdlet below:

    Set-PowerShellVirtualDirectory -Identity "PowerShell (Default Web Site)" -BasicAuthentication $true

    After execute this command on the EX2012 Server ist work perfekt.

    Good luck.

    Tuesday, September 25, 2018 4:22 PM