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

Database Access and Permission Model for XenDesktop

This article describes the SQL Server database access and permission model used by XenDesktop 5 and later.

Background

All runtime access to the central XenDesktop site database is performed by the services running on each controller. These services gain access to the database through their Active Directory machine accounts. This database access is sufficient to allow full day-to-day operation of the site including use of Desktop Studio, Desktop Director, and the service-specific SDKs.

The controller machine accounts and users in the database are granted only the minimum access to the XenDesktop database required for the services to operate.

The use of machine accounts for database access removes the need to securely store SQL logon (SQL authentication) passwords on the controller. It also ensures that only machines that have been configured with appropriate database access at the database server can act as XenDesktop controllers for a particular site.

Use of machine accounts provides a simple and secure model for protecting the critical data in the XenDesktop database. However, the creation and manipulation of the machine account logons at the database server is an inherently privileged operation that falls outside the scope of the permissions granted within the XenDesktop database itself. For this reason, certain key actions on the site are considered privileged administrative operations that require additional database server level permissions not granted to the XenDesktop services themselves; these operations cannot be performed except by a database user with elevated privileges.

The database access performed is summarized in the following diagram:

User-added image

The normal runtime permissions and administrative permissions used by the XenDesktop site are described separately in the following sections.

Note: Use of SQL logons (SQL authentication) in place of machine account logons for the XenDesktop services is not a supported configuration. The SQL scripts used by Desktop Studio and the SDKs are based on the use of machine account logons. In addition, attempting to use SQL logons (SQL authentication) might lead to the account passwords being trivially exposed through the SDKs.

Database Permission Model

Runtime Permissions

Each XenDesktop service gains access to the database through the local controller’s machine account. All routine Desktop Studio, Desktop Director, and SDK operations go through one of the XenDesktop services and thus no additional machine account logons are required for use of any of those components irrespective of the machine on which they run.

For a controller machine that is not on the same machine as the database server, the detailed database permissions are granted as:

  • The services gain access to the database server through their machine account logon (names of the form ‘DOMAINMACHINE$’). These logons do not need to be members of any server-level roles.

  • Within the XenDesktop database, the machine logons are mapped one-to-one with a dedicated per-machine user. Each such user has the same name as the logon to which it relates (in other words: ‘DOMAINMACHINE$’).

  • Each per-machine user is a member of the following XenDesktop-specific database-level roles:

Database Role Corresponding XenDesktop Service

ADIdentitySchema_ROLE

AD Identity Service

chr_Broker

chr_Controller

Broker Service

ConfigurationSchema_ROLE

Central Configuration Service

DesktopUpdateManagerSchema_ROLE

Desktop Update Manager Service

HostingUnitServiceSchema_ROLE

Hosting Management Service

MachinePersonalitySchema_ROLE

(This is no longer present on 7.x DBs)
NA
ConfigLoggingSchema_ROLE

(added in XenDesktop 7.0 and later)
Configuration Logging Service
ConfigLoggingSiteSchema_ROLE

(added in XenDesktop 7.0 and later)
Configuration Logging Service
DAS_ROLE

(added in XenDesktop 7.0 and later)
Delegated Admin service
MonitorData_ROLE

(added in XenDesktop 7.0 and later)
Monitor Service
StorefrontSchema_ROLE

(added in XenDesktop 7.0 and later)
StoreFront Service

Note: This is not the real StoreFront service which are web services in IIS and some other Windows services such as Credential Wallet and Configuration Replication. This is a XenDesktop integration service with StoreFront.
Analytics_ROLE

(added in XenDesktop 7.0 and later)
Analytics Service
AppLibrarySchema_ROLE App library service
EnvTestServiceSchema_ROLE Env Test service
Monitor_ROLE Monitor service
OrchestrationSchema_ROLE Orchestration service
TrustSchema_ROLE FMA trust service


Each one of the preceding roles has the minimum permissions granted to it to allow the corresponding service on the controller to function. These permissions are restricted to execute on stored procedures and read on some tables.

For a controller that is on the same machine as the database server, the model is as in the preceding diagram except that the logon and user relate to the local NetworkService account. In this case, both the logon and user names are ‘NT AUTHORITYNETWORK SERVICE’.

Notes

  • All server logons, database users, roles and permissions are created as required either by Desktop Studio, or through the scripts obtained directly from the service-specific SDKs. No further configuration is required.

  • It should never be necessary to manual modify the users, roles, or permissions created within the XenDesktop database.

Administrative Permissions

The permissions required to perform various administrative operations on a XenDesktop database are shown in the following table. Because it is envisaged that these are typically performed by a database administrator, no operation-specific database roles are provided, thus db_owner rights are usually required as shown.

All of these operations can be performed using Desktop Studio, if required. In these cases, a direct connection is made from Desktop Studio to the database server; thus, the Desktop Studio user must either have a database server account that is explicitly a member of the appropriate server roles or be able to provide credentials of an account that is. Such direct database access is only used for the following operations; all other operations go through the underlying XenDesktop services.

Operation

Purpose

Server Roles

Database Roles

Database Creation

Create suitable empty database for use by XenDesktop.

See note [4] below.

dbcreator

NA

Schema Creation

Create all service-specific database schemas and add first controller to site.

securityadmin

db_owner

Add Controller

Add controller (other than the first) to site.

securityadmin

db_owner

Add Controller (mirror server)

Add controller login to the database server currently in the mirror role of a mirrored XenDesktop database.

securityadmin

NA

Remove Controller

Remove controller from site.

See note [5] below.

db_owner

Schema Update

Apply schema updates/hotfixes.

NA

db_owner

Notes

  1. While technically more restrictive, in practice, the securityadmin server role should be treated as equivalent to the sysadmin server role.

  2. Where the preceding operations are performed using Desktop Studio, the user account must currently explicitly be a member of the sysadmin server role.

  3. The accounts used to perform the preceding administrative operations are never recorded by the XenDesktop site. An account that was previously used for an operation can subsequently be removed without impacting the site in any way.

  4. When an empty database is created using Desktop Studio, it is created with all default attributes except for the following:

    • The collation sequence is set to Latin1_General_CI_AS_KS. Where a database is created manually, any collation sequence can be used provided that it is case-insensitive, ascent-sensitive, and kanatype-sensitive (typically the collation sequence name ends with _CI_AS_KS).
    • The recovery model is set to Simple. For use as a mirrored database, this must be changed to Full.
  5. When a controller is removed from a site, either directly through Desktop Studio, or using the scripts generated by Desktop Studio or SDK, the controller logon to the database server is not removed. This is to avoid potentially removing a logon being used by non-XenDesktop services on the same machine. The logon must be removed manually if it is no longer required; this requires securityadmin server role membership.

Additional Resources

Citrix Documentation – System requirements for XenDesktop

Refer to the following for more information on Microsoft SQL Server roles:

Related:

VDA Registration: 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.

SeeManaging a Forward Lookup Zonefor information on managing Lookup Zones.

On theDesktop 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 theVirtual 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.

Related:

Error: The trust relationship between this workstation and the primary domain failed

Option 4) CMD line using NETDOM tool:

1. Logon to the machine with a local administrator account.

2. Obtain the tool netdom.exe from Windows Server 2008 or Windows Server 2008 R2 CD to enable the Active Directory Domain Services role.

3. Note: For Windows Vista and Windows 7, utilize the Remote Server Administration Tools (RSAT) to enable the Active Directory Domain Services role.

4. Run netdom.exe to change the password.

5. Open command prompt with administrator rights.

6. Execute the command: netdom.exe resetpwd /s:<server> /ud:<user> /pd:*

7. Restart the machine



Provisioning Services Target Device

Make sure that you have configured the PVS environment properly.

Reference the following article: https://support.citrix.com/article/CTX132289


Once that is confirmed. Shut the target device down and reset the machine account password for the affected target device in the PVS console.

User-added image

Related:

  • No Related Posts

Azure Active Directory and Citrix XenApp and XenDesktop

Introduction

Citrix XenApp and XenDesktop have traditionally used Windows Server Active Directory domains to manage end user access and administrator roles. With the move to the cloud, the use of an Active Directory domain continues to remain a requirement.

When using Azure as a Resource Location, Azure Active Directory also has a role to play:

  1. Azure Active Directory must always be configured as the holder of an application service account for the Citrix service. This account is used by Citrix Cloud or Studio to perform machine lifecycle events within the Azure Tenant.

  2. Azure Active Directory can be used as a more general repository of accounts for administrators and users. Depending on the configuration and type of service, using Azure Active Directory for this role may be optional.

The remainder of this document is focused on the various Azure Active Directory configurations that customers are likely to have, how each of those configurations can be used as repositories of accounts, and the recommended way to associate a Windows Server Active Directory domain controller to manage your Citrix XenApp and XenDesktop environment.

Note: Customers using Windows 10 CBB under a Hybrid Use Benefit license are required to associate an Azure Active Directory instance with their deployment. For other service scenarios, use of Azure Active Directory as a repository is optional and will depend on the customer’s choice of architecture.

Identity management – “hybrid” or “born in the cloud”

Companies that were “born in the cloud” most likely began with an Azure Active Directory linked to some service. This is often the Azure Active Directory associated with an Office 365 Tenant.

Companies that were born in a datacenter typically adopt a hybrid model with some assets in Azure and others remaining in the datacenter. These customers often add Azure Active Directory to an existing Windows Server Active Directory to support authentication with some external service.

The key difference between the two origins is whether there was an existing Windows Server Active Directory that needs to be synchronized with Azure Active Directory (aka ‘Synced with Active Directory’), or if the user accounts are only in Azure Active Directory (aka ‘In cloud’).

Citrix machines (XenApp and XenDesktop workers and supporting infrastructure machines) have a requirement to be joined to an Active Directory domain. This is required for domain computer accounts, new machine provisioning (creation of machine accounts), user association, and pass-through / Kerberos authentication to resources. It is because of these requirements that Azure Active Directory cannot be used alone.

When Azure Active Directory is used with the Windows 10 CBB under a Hybrid Use Benefit license computer accounts and user accounts must be in the same Azure Active Directory. Documentation related to this requirement and its configuration would be available soon.

Implementing Active Directory with Azure Active Directory

As mentioned earlier there are two Azure Active Directory origins for customers; they are born in the cloud or they are hybrid. And there are two Azure Active Directory to Azure Tenant associations; the Azure Active Directory is native to the Azure Tenant or it is not. These combinations impact the Active Directory options that a customer must consider.

  • Customers that only have ‘In cloud’ users can take advantage of Azure Active Directory Domain Services.

  • Hybrid customers with a VPN (such as ExpressRoute) should deploy replica Domain Controllers in Azure.

It was previously described that many customers will have multiple Azure Active Directories. The key take away that affects any implementation is that the Azure Active Directory used for the application service account, can be different from the Azure Active Directory where user accounts reside.

The important design point is that the Domain Services are linked to the Azure Active Directory where user accounts reside. This is important all the time, but critical using Windows 10 CBB under a Hybrid Use Benefit license.

The following sections describe the primary scenarios through the use of diagrams to give an understanding of the topology and the relationship of the accounts and Active Directory components.

In cloud user accounts

In this scenario, the user accounts are ‘In cloud’. Therefore, Azure Active Directory Domain Services can be used to provide the necessary Domain Controller services required.

Useful links:

Some possible models with Azure Active Directory are:

In Cloud with one Azure Active Directory

The customer has one Azure Active Directory domain, which is also the same Azure Active Directory associated with the customer Azure Tenant.

User-added image

Figure 1- In Cloud customer with a single Azure AD

In Cloud with more than one Azure Active Directory

The customer could also have two (or more) Azure Active Directories. In the example below, the customer’s user accounts are being synchronized with an Azure Active Directory associated with an Office365 subscription. And the Azure Tenant account has its default Azure Active Directory which is separate.

Azure Role Based Access Control is used to grant access to user accounts from the Office365 Azure AD to the Azure Tenant, however the application service account used by Citrix must be an account native to the Azure Tenant.

User-added image

Figure 2- in cloud customer with a separate user Azure AD

Synced with Active Directory user accounts

In this scenario, the user accounts are ‘Synced with Active Directory’. Therefore Domain Controller IaaS VMs need to be deployed into the Azure subscription. These can be a replica domain controller if this is a hybrid deployment.

Useful links:

As with the ‘In cloud’ options above, similar topologies exist for customers that have a hybrid networking scenario. In the hybrid scenarios, there is some resource or application that must be accessed from a remote datacenter through a VPN, and Windows pass-through / Kerberos authentication is used by that resource or application.

Hybrid with one Azure Active Directory

User-added image

Figure 3- Hybrid network with a single Azure AD

Hybrid with more than one Azure Active Directory

User-added image

Figure 4- Hybrid network with a separate user Azure AD

Tips for success:

The application service account must be created in the Azure Active Directory instance associated with the Azure Tenant where Citrix resources will be deployed.

When creating the application service account from the Citrix Cloud portal or Studio using the “Create New” option, the Azure user account used to create the application service account must be a member of the Azure Tenant Azure Active Directory.

User-added image

Guest identities such as a Microsoft ID or invited from another Azure Active Directory cannot be used. Enable the “user type” column to discover this in the Azure Active Directory portal.

See Citrix documentation; Microsoft Azure Resource Manager for additional details.

When using the “Use existing” option in the Citrix Cloud portal or Studio delegated users can manually create the application service account through the Azure Portal.Refer to Manually Granting Citrix Cloud Access to Your Azure Subscription for more information.

Additional learning:

Related:

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

VDA Fails to Register: Cannot Communicate With Delivery Controllers

To resolve this issue:

1. If the communication between VDA and Delivery Controllers were set using

a) Policy or Manually/Registry-based:

  • Verify the ListOfDDCs is not empty, and that the hostnames are correctly entered and can be resolved. To do this, you can ping each host name or use nslookup from the command prompt.
  • Value will be stored in:
HKLMSoftwarePoliciesCitrixVirtualDesktopAgent (ListOfDDCs)

or

HKLMSoftwareWow6432NodeCitrixVirtualDesktopAgent (ListOfDDCs)

*For more information, see CTX133384 – Best Practices for XenDesktop Registry-based DDC Registration

b) Active Directory OU-based discovery:

  • Value will be stored in:
32 Bit: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentFarmGUID

64 Bit HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentFarmGUID

*For more information, see Active Directory OU-based Controller Discovery

c) Provisioned by MCS

  • The MCS process creates C:Personality.ini, containing a list of contactable DDCs in following format:

[VdaData] ListOfDDCs=<FQDN of the Controller>

2. Verify the VDA’s DNS settings are correctly configured so the Delivery Controller’s FQDN can be resolved from the VDA.

3. Verify the network communication by pinging VDA from the Controller and vice versa.

4. Verify the VDA and the Delivery Controller can communicate on the same port.

5. Verify that any Delivery Controller host names in the Windows Hosts file are correctly entered and can be resolved. To do this, you can ping each host name or use nslookup from the command prompt.

Related: