Event ID 71 — Terminal Services License Server Security Group Configuration

Event ID 71 — Terminal Services License Server Security Group Configuration

Updated: January 5, 2012

Applies To: Windows Server 2008

When the TS Licensing role service is installed on the server, the Terminal Server Computers local group is created. The license server will respond only to requests for TS CALs from terminal servers whose computer accounts are members of this group if the Computer Configuration\Administrative Templates\Windows Components\Terminal Services\TS Licensing\License server security group Group Policy setting has been enabled and applied to the license server. By default, the Terminal Server Computers local group is empty.

When the TS Licensing role service is removed from the server, the Terminal Server Computers local group is deleted.

Event Details

Product: Windows Operating System
ID: 71
Source: Microsoft-Windows-TerminalServices-Licensing
Version: 6.0
Symbolic Name: TLS_E_LS_CREATE_LOCALGROUP
Message: The Terminal Server Computers local group cannot be created.Win32 error code: %1!s!

Resolve
Create the Terminal Server Computers local group on the license server

To resolve this issue, create the Terminal Server Computers local group on the Terminal Services license server.

To perform this procedure, you must have membership in the local Administrators group, or you must have been delegated the appropriate authority.

To create the Terminal Server Computers group:

  1. On the license server, open the Local Users and Groups snap-in. To open Local Users and Groups, click Start, click Run, type lusrmgr.msc, and then click OK.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. In the left pane, right-click Groups, and then click New Group.
  4. In Group name, type Terminal Server Computers, click Create, and then click Close.

Note:  If the license server is installed on an Active Directory Domain Services (AD DS) domain controller, use the Active Directory Users and Computers snap-in to create the Terminal Server Computers group. To create the Terminal Server Computers group on a domain controller, you must have membership in the Domain Admins group in AD DS, or you must have been delegated the appropriate authority. To open Active Directory Users and Computers, click Start, click Run, type dsa.msc, and then click OK.

Verify

To verify that the Terminal Server Computers local group is correctly configured on the license server, use the Local Users and Groups snap-in.

Note:  If the license server is installed on an Active Directory Domain Services (AD DS) domain controller, use the Active Directory Users and Computers snap-in to verify that the Terminal Server Computers group is properly configured. To use Active Directory Users and Computers on a domain controller, you must have membership in the Domain Admins group in AD DS, or you must have been delegated the appropriate authority. To open Active Directory Users and Computers, click Start, click Run, type dsa.msc, and then click OK.

To perform this procedure, you must have membership in the local Administrators group, or you must have been delegated the appropriate authority.

To verify that the Terminal Server Computers group is properly configured:

  1. On the license server, open the Local Users and Groups snap-in. To open Local Users and Groups, click Start, click Run, type lusrmgr.msc, and then click OK.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. In the left pane, click Groups.
  4. In the right pane, the Terminal Server Computers group should be listed. If the License Server security group Group Policy setting is enabled for the license server, the group should contain a list of computer accounts for terminal servers.

Note:  If the TS Licensing role service has been removed from the server, the Terminal Server Computers local group should not be listed.

Related Management Information

Terminal Services License Server Security Group Configuration

Terminal Services

Related:

NLB Cluster %2 %1: Host %3 converged with %4 host(s) as part of the cluster. Note: The list of cluster members was too large to fit in this event log – see the first data dump entry for a binary map of the cluster membership or run ‘wlbs query’ to see a list of cluster members.

Details
Product: Windows Operating System
Event ID: 71
Source: WLBS
Version: 5.2
Symbolic Name: MSG_INFO_SLAVE_MAP
Message: NLB Cluster %2 %1: Host %3 converged with %4 host(s) as part of the cluster. Note: The list of cluster members was too large to fit in this event log – see the first data dump entry for a binary map of the cluster membership or run ‘wlbs query’ to see a list of cluster members.
   
Explanation

This event is logged to inform you that the specified host has joined the cluster.

   
User Action

No user action is required. If you do not want this host to be the default host, reconfigure the host priority settings. For more information about Network Load Balancing, see Help and Support.

Related:

Client Access server %1 attempted to proxy Outlook Web Access traffic to Client Access server %2. This failed because the authentication for the connection between the two Client Access servers failed. This may be due to one of these configuration problems: 1. The host name in %2 may not be registered as a Service Principal Name (SPN) with Kerberos on the target Client Access server. This usually happens because you used the IP address, instead of the host name, of the target Client Access server in the “internalURL” configuration for the Outlook Web Access virtual directory on the target Client Access server. You can change the “internalURL” configuration for the target Client Access server using the “set-owavirtualdirectory” Exchange admin task. If you don’t want to change the “internalURL” configuration for the Outlook Web Access virtual directory on the target Client Access server, you can also use the tool “setspn.exe” on the target Client Access server to register additional SPNs for which that Client Access server will accept Kerberos authentication. 2.The server hosting %2 may be configured not to allow Kerberos authentication. It might be set to use Windows Integrated authentication for the Outlook Web Access virtual directory, but be configured to only use NTLM (not Kerberos) authentication for Windows Integrated authentication. See the IIS documentation for additional troubleshooting steps if you suspect this may be the cause of the failure.

Details
Product: Exchange
Event ID: 71
Source: MSExchange OWA
Version: 8.0
Symbolic Name: ProxyErrorAuthenticationToCas2Failure
Message: Client Access server %1 attempted to proxy Outlook Web Access traffic to Client Access server %2. This failed because the authentication for the connection between the two Client Access servers failed. This may be due to one of these configuration problems: 1. The host name in %2 may not be registered as a Service Principal Name (SPN) with Kerberos on the target Client Access server. This usually happens because you used the IP address, instead of the host name, of the target Client Access server in the “internalURL” configuration for the Outlook Web Access virtual directory on the target Client Access server. You can change the “internalURL” configuration for the target Client Access server using the “set-owavirtualdirectory” Exchange admin task. If you don’t want to change the “internalURL” configuration for the Outlook Web Access virtual directory on the target Client Access server, you can also use the tool “setspn.exe” on the target Client Access server to register additional SPNs for which that Client Access server will accept Kerberos authentication. 2.The server hosting %2 may be configured not to allow Kerberos authentication. It might be set to use Windows Integrated authentication for the Outlook Web Access virtual directory, but be configured to only use NTLM (not Kerberos) authentication for Windows Integrated authentication. See the IIS documentation for additional troubleshooting steps if you suspect this may be the cause of the failure.
   
Explanation

This error indicates that either Kerberos authentication has been misconfigured on the target Client Access Server or that the target Client Access server has not been configured to allow Kerberos authentication.

   
User Action

To resolve this error, do one or more of the following:

  • See the error text for possible causes and resolutions.

  • If you have difficulty resolving the issue, contact Microsoft Customer Support. For information about how to contact support, visit Microsoft Help and Support.

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related: