when start EMC or EMS failed in exchange 2010 environment should check these steps

type 1

When you try to start Exchange Management Shell (EMS) or Exchange Management Console (EMC) on a computer that is running Microsoft Exchange Server 2010, you receive the following error message:

Connecting to remote server failed with the following error message: 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. For more information, see the about_Remote_Troubleshooting Help topic. 

This problem occurs because one or more of the following conditions are true:

• The Kerbauth module is configured incorrectly in Internet Information Services (IIS) in one of the following ways:
  • The Kerbauth module is displayed as a Managed module instead of as a Native module.
  • The Kerbauth module has been loaded on the Default website level (instead of, or in addition to, the PowerShell virtual directory).
• The user does not have Remote PowerShell Enabled status.
• The WSMan module entry is missing from the Global modules section of the ApplicationHost.config file that is in the following location:
  

  C:\Windows\System32\Inetsrv\config\ApplicationHost.config

  This causes the WSMan module to be displayed as a Managed module in the PowerShell virtual directory.

Note The WSMan Module entry may also be missing from the ApplicationHost.config file if the WinRM IIS Extension feature is installed on the server.

To resolve this problem, use one of the following methods:

• Make sure that the Kerbauth module is not enabled on the default website but is, instead, enabled only for the PowerShell virtual directory. Remote PowerShell uses Kerberos authentication for the user connection. Internet Information Services (IIS) implements this Kerberos authentication method by using a Native module.
  In IIS Manager, Kerbauth should be listed as a Native module in the PowerShell virtual directory. The DLL location for this module should point to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll. 
  Note The Local entry type for the Kerbauth module indicates that the module was enabled directly on this level and was not inherited from a parent level.

  

• Make sure that the user who is trying to connect has a Remote PowerShell Enabled status. To determine whether a user is enabled for Remote PowerShell, you have to start Exchange Management Shell by using an account that is enabled, and then run the following command:

  (Get-User <username>).RemotePowershellEnabled

This query returns a response of True or False. If the output is displayed as False, the user is not enabled for Remote PowerShell. To enable the user, run the following command:

Set-User <username> -RemotePowerShellEnabled $True

• Make sure that the WSMan module is registered but not enabled at the Server level. Also make sure that the WSMan module is enabled for the PowerShell virtual directory. Then, verify that the following WSMan module entry is included in the "Global modules" section of the C:\Windows\System32\Inetsrv\config\ApplicationHost.config file as follows:

<globalModules>
           <add name="WSMan" image="C:\Windows\system32\wsmsvc.dll" />

Note You must follow these steps even if the WinRM IIS Extension feature has been removed. This is because the uninstall procedure does not automatically fix the ApplicationHost.config file.

type 2

When you try to start Exchange Management Shell (EMS) or Exchange Management Console (EMC) on a computer that is running Microsoft Exchange Server 2010, you receive the following error message:

The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic.

This problem occurs because one or more of the following conditions are true:

• The MSExchangePowerShellAppPool application pool is experiencing problems or is not running.
• The user idoes not have Remote PowerShell Enabled status.
• Windows Remote Management (WinRM) is configured incorrectly on the server

To resolve this problem, use one of the following methods:

• Make sure that the MSExchangePowerShellAppPool application pool is running. If the pool is running, try to recycle it. Then, check for errors or warnings in the event logs.
• Make sure that the user who is trying to connect has Remote PowerShell Enabled status. To determine whether a user is enabled for Remote PowerShell, start Exchange Management Shell by using an account that has been enabled, and then run the following query:
  

  (Get-User <username>).RemotePowershellEnabled

  This query returns a response of True or False. If the response is False, the user is not enabled for Remote PowerShell. To enable the user, run the following command:

  Set-User <username> -RemotePowerShellEnabled $True

• Make sure that WinRM is configured correctly on the server. To do this, follow these steps:

1. Run WinRM Quick Config. To do this, click Start, type WinRM Quick Config in the Start Search box, and then press ENTER.
2. Make sure that both tests pass and that no actions are required. If any actions are required, click Yes in the prompt window to allow the WinRM configuration changes to be made.
3. Click Start, type cmd in the Start Search box, and then press ENTER. In the Command Prompt window, type WinRM enumerate winrm/config/listener at the command prompt, and then press ENTER.
4. Make sure that a listener exists for the HTTP protocol on port 5985, and that the listener is listening on all addresses.

type 3

When you try to start Exchange Management Shell (EMS) or Exchange Management Console (EMC) on a computer that is running Microsoft Exchange Server 2010, you receive the following error message: 

Connecting to remote server failed with the following error message: 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. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command ‘Discover-ExchangeServer -UseWIA $true -SuppressError $true’.

Additionally, you may see the following Warning event logged in the System log: 
Source: Microsoft-Windows-WinRM
EventID: 10113
Level: Warning
Description: Request processing failed because the WinRM service cannot load data or event source: DLL="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll"

This problem occurs because one of the following conditions is true:

• The ExchangeInstallPath variable is missing.
• The path of the PowerShell virtual directory was modified.

To resolve this problem, use one of the following methods:

• Make sure that the ExchangeInstallPath value is set correctly. To do this, open the System item in Control Panel, click Advanced system settings, and then click Environment variables on the Advanced tab. In the System variables box, locate the ExchangeInstallPath variable. The corresponding value for this variable should be C:\Program Files\Microsoft\Exchange Server\V14\.
• In IIS Manager, locate the entry for the PowerShell virtual directory under Default Web Site. Then, make sure that the entry points to the \Program Files\Microsoft\Exchange Server\v14\ClientAccess\PowerShell folder.

type 4

When you try to open Exchange Management Shell (EMS) on a Microsoft Exchange Server 2010 Client Access server, you receive the following error message in EMS: 

VERBOSE: Connecting to <server name>
[<server name>] Connecting to remote server failed with the following error message : The WinRM client received an HTTP status code of 403 from the remote WS-Management service. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionOpenFailed
Failed to connect to any Exchange Server in the current site.
Please enter the Server FQDN where you want to connect:

This problem occurs because the Require SSL option on the PowerShell virtual directory in Internet Information Services (IIS) Manager is enabled. However, this option setting is not needed because Exchange Server 2010 uses Kerberos authentication

To resolve this problem, follow these steps:

1. On the Exchange Server 2010 Client Access server, open IIS Manager.
2. Locate the PowerShell Virtual directory under Default Web Site, and then click SSL Settings in the details pane.
3. Double-click SSL Settings and then clear the Require SSL option.
4. In the details pane, click Apply to save the settings in IIS Manager.
5. Restart IIS.
6. Close EMS, and then reopen it.

 

MS KB links:

http://support.microsoft.com/kb/2028305/en-US

http://support.microsoft.com/kb/2027064/en-US

http://support.microsoft.com/kb/2027063/en-US

http://support.microsoft.com/kb/2276957/en-US