Problem with WinRM on Exchange 2013 Management Shell and Exchange Toolbox on a new exchange 2013 with CAFE and BE on single server installation
2014-08-20 11:45
936 查看
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.
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.
相关文章推荐
- Error applying site theme: A theme with the name "Jet 1011" and version already exists on the server.
- Java code for authenticating into SMTP server with Auth and TLS turned on..
- install and configure Microsoft SharePoint Server 2013 on Windows Server 2008 R2
- building and installing openCV3 with extra modules on VS2013 win8
- Step by Step Setup Git Server on Windows with CopSSH + msysGit and Integrate Git with Visual Studio
- Download and run CSQL on Linux -Only two commands will be used to start the server
- IIS Error:404.2 The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server
- 提交时提示错误This Bundle is invalid.New apps and app updates submitted to the App Store must be built with
- 奇葩问题:This file could not be checked in because the original version of the file on the server was moved or deleted. A new version of this file has been saved to the server, but your check-in comments were not saved
- Problem to create "New Database Diagram" in Microsoft SQL Server Management Studio for SQL Server 2012
- pro and con thought on creating regular to deal with special problem!
- TF80012: The document cannot be opened because there is a problem with the installation of the Microsoft Visual Studio v
- Step by Step Setup Git Server on Windows with CopSSH + msysGit and Integrate Git with Visual Studio
- Step by Step Setup Git Server on Windows with CopSSH + msysGit and Integrate Git with Visual Studio
- Resolve can't copy and remove files on Exchange server
- Virtual Hosting With PureFTPd And MySQL (Incl. Quota And Bandwidth Management) On Fedora 13
- createDataSource, and add new rows on the datagrid to be filled out.
- Issue 71 - pymssql - Undefined symbols on Mac, CentOS, Redhat with pre-compiled build - A fast MS SQL Server client library for Python directly using C API instead of ODBC. It is Python DB-API 2.0 compliant. Works on Linux, *BSD, Solaris, Mac OS X and Win
- Migrating Mantis to a new server (And avoid the email sent failure problem)
- his bundle is invalid . new apps and app updates submitted to the app store must be built with publi