Troubleshooting Access Problems in Windows PowerShell Web Access

  • Article

 

Applies To: Windows Server 2012, Windows Server 2012 R2

Troubleshooting access problems

The following table identifies some common problems that users might experience when they are attempting to connect to a remote computer by using Windows PowerShell Web Access, and includes suggestions for resolving the problems.

Problem

Possible cause and solution

Sign-in failure

Failure could occur because of any of the following.

  • An authorization rule that allows the user access to the computer, or a specific session configuration on the remote computer, does not exist. Windows PowerShell Web Access security is restrictive; users must be granted explicit access to remote computers by using authorization rules. For more information about creating authorization rules, see Authorization Rules and Security Features of Windows PowerShell Web Access in this guide.

  • The user does not have authorized access to the destination computer. This is determined by access control lists (ACLs). For more information, see “Signing in to Windows PowerShell Web Access” in Use the Web-based Windows PowerShell Console, or the Windows PowerShell Team Blog.

    • Windows PowerShell remote management might not be enabled on the destination computer. Verify that it is enabled on the computer to which the user is trying to connect. For more information, see “How to Configure Your Computer for Remoting” in about_Remote_Requirements in the Windows PowerShell About Help Topics.

When users try to sign in to Windows PowerShell Web Access in an Internet Explorer window, they are shown an Internal Server Error page, or Internet Explorer stops responding. This issue is specific to Internet Explorer.

This can occur for users who have signed in with a domain name that contains Chinese characters, or if one or more Chinese characters are part of the gateway server name. To work around this issue, the user should install and run Internet Explorer 10, and then perform the following steps.

  1. Change the Internet Explorer Document Mode setting to IE10 standards.

    1. Press F12 to open the Developer Tools console.

    2. In Internet Explorer 10, click Browser Mode, and then select Internet Explorer 10.

    3. Click Document Mode, and then click IE10 standards.

    4. Press F12 again to close the Developer Tools console.

  2. Disable automatic proxy configuration.

    1. In Internet Explorer 10, click Tools, and then click Internet Options.

    2. In the Internet Options dialog box, on the Connections tab, click LAN settings.

    3. Clear the Automatically detect settings check box. Click OK, and then click OK again to close the Internet Options dialog box.

Cannot connect to a remote workgroup computer

If the destination computer is a member of a workgroup, use the following syntax to provide your user name and sign in to the computer: <workgroup_name>\<user_name>

Cannot find Web Server (IIS) management tools, even though the role was installed

If you installed Windows PowerShell Web Access by using the Install-WindowsFeature cmdlet, management tools are not installed unless the IncludeManagementTools parameter is added to the cmdlet. For an example, see “To install Windows PowerShell Web Access by using Windows PowerShell cmdlets” in Install and Use Windows PowerShell Web Access. You can add the IIS Manager console and other IIS management tools that you need by selecting the tools in an Add Roles and Features Wizard session that is targeted at the gateway server. The Add Roles and Features Wizard is opened from within Server Manager.

The Windows PowerShell Web Access website is not accessible

If Enhanced Security Configuration is enabled in Internet Explorer (IE ESC), you can add the Windows PowerShell Web Access website to the list of trusted sites, or disable IE ESC. You can disable IE ESC in the Properties tile on the Local Server page in Server Manager.

The following error message is displayed while trying to connect when the gateway server is the destination computer, and is also in a workgroup: An authorization failure occurred. Verify that you are authorized to connect to the destination computer.

When the gateway server is also the destination server, and it is in a workgroup, specify the user name, computer name, and user group name as shown in the following lists. Do not use a dot (.) by itself to represent the computer name.

Scenario: Gateway server is in a domain

  • UserName Parameter: Server_name\user_name, Localhost\user_name, or .\user_name

  • UserGroup Parameter: Server_name\user_group, Localhost\user_group, or .\user_group

  • ComputerName Parameter: Fully qualified name of gateway server, or Localhost

  • ComputerGroup Parameter: Server_name\computer_group, Localhost\computer_group, or .\computer_group

Scenario: Gateway server is in a workgroup

  • UserName Parameter: Server_name\user_name, Localhost\user_name, or .\user_name

  • UserGroup Parameter: Server_name\user_group, Localhost\user_group or .\user_group

  • ComputerName Parameter: Server name

  • ComputerGroup Parameter: Server_name\computer_group, Localhost\computer_group or .\computer_group

Sign in to a gateway server as target computer by using credentials formatted as one of the following.

  • Server_name\user_name

  • Localhost\user_name

  • .\user_name

A security identifier (SID) is displayed in an authorization rule instead of the syntax user_name/computer_name 

Either the rule is no longer valid, or the Active Directory Domain Services query failed. An authorization rule is usually not valid in scenarios where the gateway server was at one time in a workgroup, but was later joined to a domain.

Cannot sign in to a target computer that has been specified in authorization rules as an IPv6 address with a domain.

Authorization rules do not support an IPv6 address in form of a domain name. To specify a destination computer by using an IPv6 address, use the original IPv6 address (that contains colons) in the authorization rule. Both domain and numerical (with colons) IPv6 addresses are supported as the target computer name on the Windows PowerShell Web Access sign-in page, but not in authorization rules. For more information about IPv6 addresses, see How IPv6 Works.

See Also

Authorization Rules and Security Features of Windows PowerShell Web Access Use the Web-based Windows PowerShell Console about_Remote_Requirements