Export (0) Print
Expand All
Expand Minimize

PowerShell Virtual Directory issues cause problems with Exchange Management tools

[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at http://go.microsoft.com/fwlink/?linkid=34707.]  

Topic Last Modified: 2010-05-24

The Microsoft Exchange Server Best Practices Analyzer examines the system to verify that the PowerShell Virtual Directory is configured correctly and will not cause problems when you try to run the Exchange Management Tools in Exchange Server 2010.

To do this, the Analyzer tool verifies the following conditions:

  • The kerbauth.dll file can be located at the path indicated in the applicationHost.config file.
  • The PowerShell Virtual Directory is bound to 'Default Web Site' and to port 80.
  • The “Require SSL” option is not configured for the PowerShell Virtual Directory in IIS.
  • The path of the PowerShell Virtual Directory is the default path.
  • Kerbauth is listed as a Native Module, and the DLL location points to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll.

If these conditions are not configured correctly, issues may occur when you try to use the Exchange Management Tools.

PowerShell uses Kerberos to authenticate a remote computer connection. Internet Information Services (IIS) implements the Kerberos authentication method by using a native module. The Kerberos authentication module must be loaded on the PowerShell virtual directory level. If the Kerberos authentication module is configured as a Managed module instead of as a native module, or if the Kerberos authentication module has been loaded on the default Web site level, you may receive the following error message when you try to use the Exchange Management Tools:

 

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.

To resolve this issue, follow these steps.

Configure Kerberos Authentication
  1. Start Internet Information Services (IIS) Manager.

  2. In the Connections pane, expand Default Web Site, and then click PowerShell.

  3. In the /PowerShell Home pane, double-click Modules.

  4. Confirm that Kerbauth is a native module.

  5. Confirm that the path of the Kerbauth.dll file is C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll.

  6. Verify that the Kerbauth module is registered but not enabled on the default Web site. To do this, follow these steps:

    1. Click the default Web site in the Connections pane, and then double-click Modules in the results pane.
    2. In the Actions pane, click Configure Native Modules.
    3. If Kerbauth is not listed in the Configure Native Modules dialog box, click Register. In the Register Native Module dialog box, type the name and path of the Kerbauth module, and then click OK.
    4. If Kerbauth is enabled, click to clear the Kerbauth check box.
    5. Click OK.

If the ExchangeInstallPath variable is missing from the Environment variables in System Properties, you may receive the following error message when you try to use Exchange Management Tools:

 

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'.

To resolve this issue, follow these steps.

Add the ExchangeInstallPath variable to the Environment variables in System Properties, and check the path of the PowerShell Virtual Directory in IIS
  1. Open System Properties, and then click Environment variables.

  2. In the System variables area, verify that the ExchangeInstallPath variable exists and that the value for the variable is C:\Program Files\Microsoft\Exchange Server\V14\. Add the variable if it does not exist.

  3. Start IIS.

  4. Expand Default Web Site, and then click PowerShell.

  5. In the Actions pane, click Basic Settings.

  6. In the Edit Application dialog box, verify that the path in the Physical path box is as follows: C:\Program Files\Microsoft\Exchange Server\v14\ClientAccess\Powershell.

  7. Click OK.

Exchange Management Tools connects over port 80. If the Require SSL option is set for the PowerShell Virtual Directory, Exchange Management Tools tries to connect on port 443 instead of on port 80. If this occurs, IIS returns the following error message:

 

The WinRM client received an HTTP status code of 403 from the remote WS-Management service.

To resolve this issue, follow these steps.

The procedure title
  1. Start Internet Information Services (IIS) Manager.

  2. In the Connections pane, expand Default Web Site, and then click PowerShell.

  3. In the Results pane, double-click SSL Settings.

  4. On the SSL Settings property page, click to clear the Require SSL check box.

  5. In the Actions pane, click Apply.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft