Error: “The remote session was disconnected because there was no terminal server license server available to provide a license”

Windows 2003 Terminal Servers do not recognize the Windows 2000 Licensing server and the following error occurs:

“The remote session was disconnected because there was no terminal server license server available to provide a license.

User-added image

The following event ids are logged:

Event ID 1004: No Terminal Server licenses available.

Event ID 1011: There are no Terminal Server licenses available.

Users cannot log on to a session using either ICA or RDP.

Background

Microsoft stated that Windows 2003 Server serves the Windows 2003 Terminal Server licensing. In the old licensing scheme, the licensing was on an Active Directory controller but in Windows 2003 this is no longer a requirement.

Refer to Q279561 Microsoft technote to install a Windows 2003 Server and point all Terminal Server users to the installed license.

Note: Windows XP and pre-release client OS requires TS License of 2003. Vista, Windows 7 and later require license from 2008 Terminal Server.

Related:

  • No Related Posts

Joining Storefront to Server Group Error “Cannot Join Server Group”

  1. Check for any GPOs that might be blocking any local security policies on server. If this is the case, please block/disable that GPO.
  2. The policy “Access this computer from the network” with location “Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment”, needs to have at least following groups by default:

Everyone

Administrators

Users

Backup Operators

Add COMPUTERS (Storefront Servers)

NOTE: Depending on GPOs applied to environment,

The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.

Server type of GPO Default value
Default domain policy Not defined
Default domain controller policy Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access
Stand-alone server default settings Everyone, Administrators, Users, Backup Operators
Domain controller effective default settings Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access
Member server effective default settings Everyone, Administrators, Users, Backup Operators
Client computer effective default settings Everyone, Administrators, Users, Backup Operators

Related:

  • No Related Posts

The SQL Server service account does not have permission to access Active Directory Domain Services.

  1. DDC loses connection to Hypervisor.
  2. VDAs power state shows up as ‘Unknown’.
  3. Test hosting connection fails with error ‘Check that a connection to the hypervisor can be established’.
  4. On editingupdating hosting connection, we get below exception in Citrix Studio.

Error Id: XDDS:33A6280E

Inner Exception:

DesktopStudio_ErrorId : ConnectionValidationFailure

Exception : PluginUtilities.Exceptions.ManagedMachineGeneralException: Command did not execute: System.Management.Automation.CmdletInvocationException: The SQL Server service account does not have permission to access Active Directory Domain Services (AD DS). (Error ID: 2607)

—> Microsoft.VirtualManager.Utils.CarmineException: The SQL Server service account does not have permission to access Active Directory Domain Services (AD DS).

Ensure that the SQL Server service is running under a domain account or a computer account that has permission to access AD DS. For more information, see “Some applications and APIs require access to authorization information on account objects” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=121054. —> System.ServiceModel.FaultException`1[Microsoft.VirtualManager.Utils.ErrorInfo]: The SQL Server service account does not have permission to access Active Directory Domain Services (AD DS).

5. Similar error is thrown on connecting to SCVMM console,

Related:

  • No Related Posts

Desktop Director User Account Search Process is Slow or Fails

In Information Server (IIS) Management and under the Desktop Director site, select Application Settings and add a new value to search the Active Directory called Connector.ActiveDirectory.ForestSearch.

By default, the value is hidden and configured as True. If you configure the value as False, Desktop Director will only search the current domain.

If the Director Server or the Administrator on the Director Server is not a member of the searchable domain, add the searchable domain or domains in the Connector.ActiveDirectory.Domains field, as displayed in the following screen shot:

User-added image

Example :-

(user),(server),abc.local,xyz.local

Related:

Getting incorrect username or password error when using FAS to single sign on with VDA with event ID 102 and event ID 25 on DC

Some applications have features that read the token-groups-global-and-universal (TGGAU) attribute on user account objects or on computer account objects in the Microsoft Active Directory directory service. Some Win32 functions make it easier to read the TGGAU attribute. Applications that read this attribute or that call an API (referred to as a function in the rest of this article) that reads this attribute do not succeed if the calling security context does not have access to the attribute.

By default, access to the TGGAU attribute is determined by the

Permission Compatibility decision (made when the domain was created during the DCPromo.exe process). The default permission compatibility for new Windows Server 2003 domains does not grant broad access to the TGGAU attribute. Access to read the TGGAU attribute can be granted as required to the new Windows Authorization Access (WAA) group in Windows Server 2003.

Related:

Incident with local user.

I need a solution

Hi,

DLP in version 14.6 linked to the active directory, when entering as a domain user if it generates an incident and performs the assigned blocking action, however, when entering as a local user to the endpoint, it does not generate an incident and much less the response action.

Is there a problem with this version ?, or is it necessary to perform some extra configuration?

Greetings.

0

Related:

Successfully Deploying XenDesktop in a Complex Active Directory Environment

The following environments assume that XenDesktop 5.x is installed on all DDCs and VDAs. This article is based on the registry based Controller Discovery – this is the recommended method for multiple forest registration.

The NetBIOS and Fully Quality Domain Name (FQDN) can be different. For example, the NetBIOS name could be BOB but the FQDN could be parent1.local or the NetBIOS name and FQDN can be the same:

Example: NetBIOS name is parent and the FQDN would be parent.local.

Note: Dots in NetBIOS names are not recommend.

Appropriate user access permissions are given for successful machine creation. In a cross-forest setup, use Delegation Control Wizard to keep permissions to minimum use. Permission must be given for the DDC Administrator to create machines in a different forest in a specific Organizational Unit (OU). The following minimum permission can be given for successful machine creation:

  1. Open Active Directory Users and Computers Microsoft Management Console (MMC).

  2. Right-click your OU and select Delegate Control.

  3. On the first screen, click Next.

  4. In the Users & Groups screen, click Add and pick a user or group you want to delegate rights to and click Next.

    The best practice is to assign a group rather than a single user, as it is easier to manage and audit.

  5. In the Tasks to Delegate screen, select Create a custom task to delegate and click Next.

  6. In the Active Directory Object Type screen, select Only the following objects in folder and select Computer objects.

    User-added image

  7. Select Create selected objects in this folder and click Next.
  8. In the Permissions screen, select General and then select Read and Write.

  9. Click Next.

    User-added image

  10. Click Finish to complete the delegation control.

Different types of Active Directory Setups

Simple Single Domain Deployment

The following diagram illustrates a XenDesktop deployment in a single Active Directory domain, where the DDCs, VDAs, and the users are all in the same domain.

User-added image

In this Single domain setup, all relevant components and objects are based on one single domain. Registration of VDAs with the DDC should be successful and no additional configuration, that is, the registry key changes is required.

Following is a list to check if VDA is unable to register with the DDC:

  1. Check Event Viewer for errors on both the DDC and the VDA.

  2. Ensure that the firewall is open for port 80 between the VDA and the DDC.

  3. Check that the FQDN of the DDC is correct in the registry setting of the VDA machine. On the VDA, check the following Reg Key:

    Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

    HKEY_LOCAL_MACHINESOFTWARECitrixVirtualDesktopAgent and confirm the parameter ListOfDDCs had the correct FQDN.

    If using 64-bit Virtual Machine, the VDA Reg Key is HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixVirtualDesktopAgentListOfDDCs

  4. Ensure that the DNS settings are correct on VDA and DDC, and both the computers can resolve each other by DNS name and reverse lookups. Use the XDPing tool, downloadable from the Knowledge Center article CTX123278 – XDPing Tool to further troubleshoot.

  5. Check that the Time is in sync between the VDA and DDC are correct.

    For further troubleshooting, see Troubleshooting Virtual Desktop AgentRegistration with Controllers in XenDesktop.

Single Forest with Multiple Domains or Single Forest with Multiple Domains with shortcut trusts

The following two diagrams illustrate a XenDesktop deployment in a single forest with multiple domains and a Single Forest with multiple domains with shortcut trusts – where the DDC, VDA, and Users are all based in different domains.

The following is the illustration for Multiple Domains:

User-added image

The following is an illustration for Multiple Domains with short cut trusts:

User-added image

Multiple Domains: DDC, Users, and VDA are based in various domains, by default, a bidirectional transitive trust relationship exists between all domains in a forest.

Multiple Domains with short cut trusts: DDC, Users, and VDA are based in various domains but at two-way shortcut, trust has been manually created between the DDC domain and the VDA domain. Typically, shortcut trusts are used in a complex forest where it can take time to traverse between all domains for authentication. By adding a shortcut trusts, it shortens the trust path to improve the speed of user authentication.

For successful registration of the VDA with the DDC, the following should be configured correctly. DNS Forward/Reverse Lookup Zones are in place and configured on the relevant DNS servers. For further troubleshooting of VDAs not registering, see Following is a list to check if VDA is unable to register with the DDC: mentioned in the Simple Single Deployment section.

Multiple Forests with 2 way or 1 way trusts (external trusts or forest trusts)

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment. This is where the DDC is in a different Active Directory forest and the end users and desktops can be either in the same forest or in a separate Active Directory forest.

Note: For Forest trusts, both Forests must be in Win2003 Forest Functional Level.

User-added image

The preceding illustration shows two separate Active Directory forest with a two-way forest trust. DDC and Users are in the same forest (parent.local) but the VDAs are located in different forest (parent2.local).

For successful VDA registration with the DDC, the following must be configured correctly:

DNS, for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional Forwarders, Forward /Reverse lookup zones and Stub zones are all acceptable for name lookup/resolution. As an example, in the preceding illustration, on the DNS server for Parent.local, a Secondary Forward Lookup Zone and a Reverse Lookup zone for Parent2.local has been added and similarly the opposite has been done on the Parent2.local. This means that the DDC should now be able to resolve the VDA by name and IP and the VDA resolves the DDC by name and IP address.

See Managing a Forward Lookup Zone for information on managing Lookup Zones.

On the Desktop Delivery Controller, enable the following registry value on the DDC. This enables support for VDAs, which are located in separate forests: HKEY_LOCAL_MACHINESoftwareCitrixDesktopServerSupportMultipleForest (REG_DWORD)

User-added image

To enable VDAs located in separate forests; this value must be present and set to 1.

After changing the SupportMultipleForest value, you must restart the Citrix Broker Service for the changes to have an effect.

On the Virtual Desktop Agent, enable the following registry value on the VDA to enable support for DDCs located in a separate forest.

  • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

  • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

To enable support for DDCs located in a separate forest; this value must be present and set to 1.

Note: The next step is only required if External Trusts are only being used.

  1. If the Active Directory FQDN does not match the DNS FQDN or if the domain where the DDC resides has a different NetBIOS name to that of the Active Directory FQDN, you must add the following registry key on the Virtual Desktop Agent machine.
    • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentListOfSIDs
    • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentListOfSIDs
    • User-added image

The ListOfSIDs registry key contains the DOMAIN SID of the DDC. By using this key, DNS lookups are using the true DNS name of the DDC.

To obtain the correct domain SID of the DDC, the domain SID can be found in the results of the PowerShell cmdlet Get-BrokerController from an elevated PowerShell prompt on the delivery controller.

Note: You must restart the Citrix Desktop Service for the changes to have an effect.

Multiple Forests with One-Way Selective trusts

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment using One-way Selective Trusts. The DDC is in a different Active Directory forest and the end users and existing VDAs (created either manually or through an alternative method) are in a separate Active Directory forest. In a one-way selective trust, automatic creation of Virtual Machines through DDC will fail, because of authentication issues.

For this example, the NetBIOS and FQDN are different in each Forest and domain.

Note: For One-Way Selective trusts, both Forests must be in Win2003 Forest Functional Level or above.

User-added image

Selective authentication is used in environments where users are explicitly granted/ allowed to authenticate to servers and resources on the trusting domain. This method gives domain administrators control on what rights users can be given to access services on the trusting domain. See Enable Selective Authentication over a Forest Trust for more information on Selective trusts.

Configure the following for successful registration of the VDA with the DDC:

  1. DNS for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional forwarders, Forward/Reverse lookup zones, and Stub zones are all acceptable for name lookup/resolution.

  2. Create the Selective trust on the relevant Domain Controllers.

  3. Follow steps provided in the Multiple Forests with trusts (External trusts – NTLM or Forest trusts Kerberos) section.

  4. The VDAs must be granted authentication access to the DDC. This is done through Active Directory Computer and Users snap-in.

    Note: VDAs can be added to a group to make management easier (granting rights). This is recommended.

    a) In Active Directory Computers and Users, browse to the location of the DDCs.

    b) Right-click DDC and click Properties.

    c) Click the Security tab.

    d) Click Add and click Locations to change the domain to where the VDAs reside.

    e) Click on Advanced, and click on Object Types. Choose ‘Computers’

    f) Select all the relevant VDA or Group (recommended) and click OK.

    g) Select the VDA’s or Group and give the rights – Read and Allowed to authenticate, as displayed in the following screen shot:

      1. User-added image

  5. On the DDC, select an Existing Catalog and create a relevant Assignment. When done, the Virtual Machines should show in a Ready State, as displayed in the following screen shot:

    User-added image

For further troubleshooting of VDA not registering, see Following is a list to check if VDA is unable to register with the DDC section.

Related:

Moving clients from SEPM Domain to another

I need a solution

Following a side by side Active Directory migration, on our SEPM we ended up with 2 domains. I will call them Olddomain and Newdomain. When i go to Admin-Domains, each domain has clients. I need to move clients from Olddomain to Newdomain so that i can delete Olddomain.

– When i delete Olddomain, it takes the clients with it

– I open Olddomain and try Move clients, but i cant see Newdomain for a target

What would be the best approach?

0

Related:

Workspace Environment Management (WEM): Active Directory search improvements in WEM 4.6

Introduction

The Active Directory (AD) system built into the WEM Administration Console and WEM Infrastructure Server has been refactored in WEM 4.6 to improve performance and stability.

Although AD searches performed by the WEM Console and WEM Infrastructure server in previous WEM versions have typically returned results quickly, many customer environments consist of multiple AD forests or AD domains. The Active Directory improvements introduced in WEM 4.6 are designed to improve performance and stability; particularly for multi-forest/domain environments.

Active Directory improvements in WEM 4.6

Global Catalog (GC) mechanism: AD searches are initiated against the AD forest’s Global Catalogue Server (GC) instead of searching against each of the forest’s Domain Controllers in turn.

Asynchronous search mechanism: AD searches are performed on all forests (GC servers or domains) at the same time, instead of searching one by one.

AD search timeout mechanism: If the AD User or Machine object lookup points to a forest or domain that is currently unavailable, a configurable timeout been introduced to prevent prolonged searching. The timeout value is set through the WEM Administration Console (Active Directory Objects => Advanced => Active Directory search timeout (msec)), as shown below:

User-added image

The default value is 1 second (1000 msec). The value set here affects AD searches for both the WEM Administration Console and the WEM Infrastructure Server. If an AD search time exceeds the value specified in this field, AD searching will stop.

This can be configured with a preferred value based on real environment conditions. In large environments or in cases where there are dead forest entries, having a higher value, could also cause issues such as an unresponsive/black screen when logging in, since the AD search will continue to run depending on the timeout value set. It is recommended to remove the dead forest’s trust relationship with current forest to avoid the time consuming queries. If this cannot be done, there will be an enhancement coming soon which will greatly decrease the query frequency and made blacklist for dead forests in codes automatically.

NOTE: Citrix recommends using a timeout value of at least 1000 msec to avoid a timeout before the AD search completes.


Troubleshooting Active Directory searches in WEM

If AD searches are failing:

  • Check that the Active Directory search timeout (msec) is appropriate for the environment. This means that there is no specific value to recommend. Consideration needs to be given if the environment includes multiple AD forests or AD domains.
  • Generate WEM Administration Console and WEM Infrastructure Server debug logs that capture the failed AD search occurrences. In the logs, Active Directory-related entries are marked as AD: in the header of the body, right after the function name:

User-added image

Related:

PureMessage for Microsoft Exchange: Error 0x80070005 displayed when opening a PureMessage remote console

A user who is not a member of the Active Directory group Sophos PureMessage Administrators will encounter an error when opening a remote console of the PureMessage.

Error retrieving data from the server. Ensure server / database is started and try again

System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Applies to the following Sophos products and versions

PureMessage for Microsoft Exchange 3.1.4

PureMessage for Microsoft Exchange 4.0.4

What to do

In Active Directory, go to the Users folder and add the user in the group Sophos PureMessage Administrators.

Note: For customers using an Exchange Environment with a Single AD (Active Directory) server, this is fine. For customers following the Microsoft Best Practice of deploying at least 2 Peer Domain Controllers or have more than two DCs, use Replication to Force Update. See the following Microsoft articles below:

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.

Related: