Citrix Cloud Connector -101

This post has already been read 16963 times!

What is the Citrix Cloud Connector?

Citrix Cloud Connectors are components that effectively provide a communications link to your AD environments, back to Services provided by Citrix in the Cloud. The official Citrix statement is here:

The Citrix Cloud Connector is a Citrix component that serves as a channel for communication between Citrix Cloud and your resource locations, enabling cloud management without requiring any complex networking or infrastructure configuration. 

Networking

I will assume you know what the Cloud Plane is and what Resource locations are, however, if not please read here:

https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-resource-locations/resource-locations.html
Outbound Connection
The link between the Citrix Cloud (Services provided by Citrix for you to control and administer) and Resource Locations (Your AD environment, VDA’s, Group Policy, Applications) requires nothing more than TLS 1.2 with strong cipher suites. Outbound port 443 to be open with access to the internet. The Cloud Connector should have no inbound ports accessible from the Internet. The advised placement of Connectors is in the LAN, not DMZ and for the 2012/2016 O/S machine to be domain-joined. This is not an option! (No server Core!)

A Connector can be behind a web proxy that works with SSL/TLS encrypted communication.
Internal ‘Inbound/Outbound’ connections
49152 -65535/UDP 123/UDP W32Time
49152 -65535/TCP 135/TCP RPC Endpoint Mapper
49152 -65535/TCP 464/TCP/UDP Kerberos password change
49152 -65535/TCP 49152-65535/TCP RPC for LSA, SAM, Netlogon (*)
49152 -65535/TCP/UDP 389/TCP/UDP LDAP
49152 -65535/TCP 636/TCP LDAP SSL
49152 -65535/TCP 3268/TCP LDAP GC
49152 -65535/TCP 3269/TCP LDAP GC SSL
53, 49152 -65535/TCP/UDP 53/TCP/UDP DNS
49152 -65535/TCP 49152 -65535/TCP FRS RPC (*)
49152 -65535/TCP/UDP 88/TCP/UDP Kerberos
49152 -65535/TCP/UDP 445/TCP SMB

Updates

Cloud Connector updates are ‘managed’ by Citrix. The method by which updates are applied is known as ‘Canary’.  The method this encompasses is first controlled by two distinct environments maintained by Citrix – Release A and Release B. One of the environments is updated first and then customers are migrated over in batches within a 4-5-day process. Once all customers are migrated, work begins on the alternate environment. Every time there is a Cloud Plane update it is likely there will be a Connector update. It is, therefore, a recommendation that more than one connector is present in a Resource location (N + 1) as Connectors are upgraded in serial. Just a word of caution on this, always try to think of the recommendation as N+1. Even during an update (Always have 2 working Connectors).
Controlled Updates
Citrix Cloud now has the capability to allow you as the Administrator to leverage control of the update process.  You can now specify the time you wish the install to be carried out, at least giving you some notion of any update problems. Simply accessing the Resource Locations under the Hamburger menu in the Cloud Plane and choosing manage Resource Locations will provide this capability.



It is advised to keep your Connectors online, so you don't miss updates provided by Citrix. What I would like to see with the above feature is to   set your update schedule per Connector and switch off a % of your connectors in public clouds and save on consumption costs, then start them back up when you know the upgrade slot is approaching to cover the  connector that you have scheduled to update. Right now this appears to target all Connectors in the Resource Location.
Update Issues
If an issue is encountered during the update/migration phase, a hard stop is issued. Citrix Cloud can easily roll back to the previous code/environment within 5 minutes. Cloud Connectors are downgraded in serial.

The Cloud Connector will self-manage. Do not disable reboots or put other restrictions on the Cloud Connector. These actions prevent the Cloud Connector from updating itself when there is a critical update.

Connector Logs

When faced with problems, there are some steps that you can carry out to mitigate the situation.

Know where to look for the log files:
Install Logs Locations
%AppData%\Local\Temp\CitrixLogs\CloudServicesSetup %windir%\Temp\CitrixLogs\CloudServicesSetup

Codes to look out for:

1603 - An unexpected error occurred

2 - A prerequisite check failed

0 - Installation completed successfully

Connector to Cloud Logs
Location = %ProgramData%\Citrix\WorkspaceCloud\Logs

The logs here can be deleted and can be controlled by a Registry key. (HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CloudServices\AgentAdministration\MaximumLogSpaceMegabytes).

 There are also useful Event logs in the Application part of Event Viewer (Source will be from Citrix). By default, event logs are in the C:\ProgramData\Citrix\WorkspaceCloud\Logs directory of the machine hosting the Cloud Connector.

Time is also important. Make sure your time is synched.

Internet Explorer Enhanced Security Configuration (IE ESC) is turned off.

You also have https://status.cloud.com  to check any Cloud Plane issues. 

Drastic Action

Sometimes, you may not get the obvious answer. In this instance it is advised to carry out the following:

- Have operational cloud connectors – n+1 if possible

- Go to Citrix Cloud and remove the connector from inside the Resource  Location

- Then, log in to cloud connector server and uninstall software

- Add new Connector and run installation

- Reboot

Install new cloud connector software manually by logging in to the Citrix Cloud from the Cloud Connector Server and going to your Resource tab in the Citrix Cloud management portal.



Remember when it is downloaded to install using ‘Run as Administrator’.

Security

By default, the XML and broker traffic is not secure to the Cloud Connectors. There is certainly some confusion I have seen on blogs about whether this is supported. It is. The procedure to add a certificate is as follows:
Adding Certificate
Install PFX certificate in local machine context on the Connector Server

Obtain thumbprint of certificate in properties of the certificate and go to the details tab



Add to a notepad and then get rid of spaces (if any between characters). This is the Certificate Hash.

Then identify app identifier for certificate HKCR\Installer\Products and do a search for Citrix broker service.



This will take you to a product name key. Copy the key Guid into the same notepad and get rid of the path.

(You must format this, so it has a – after the first 8 characters, then – after next 4, 4, 4 with remaining characters left)

Example GUID:

Add the details to the following command in the same notepad and save in UTF-8 format to a location. Then copy your command into an administrative cmd prompt.

Command:

Netsh http add sslcert ipport=0.0.0.0:443 certhash=PASTE_CERT_HASH appid={PASTE_XD_GUID_HERE}

Once the certificate is added, you will need to change the storefront XML brokers to 443 and the STA’s used on the Gateway to 443 (https).
Trusted CA
The (CA) used by Citrix Cloud SSL/TLS certificates and by Microsoft Azure Service Bus SSL/TLS certificates is trusted by the Cloud Connector.
Outbound Communication
As stated, all outbound communication is encrypted.

Secure Data
All company data remains in resource location. The control plane does not store sensitive customer information.  Administrator passwords are asked for on-demand (by prompting only those who can administer). There is no data-at-rest that is sensitive or encrypted.

Proxy

If the Connectors are behind a Proxy, the following URL’s must be reachable:

Cloud Connector 

https://*.citrixworkspacesapi.net

https://*.cloud.com 

https://*.servicebus.windows.net 

https://*.apps.cloud.com 

https://*.blob.core.windows.net 

https://*.nssvc.net (Gateway Service) 

https://*.xendesktop.net

Administration Console

https://*.cloud.com

https://*.citrixworkspacesapi.net

https://*.blob.core.windows.net

https://browser-release-b.azureedge.net

https://*.xendesktop.net
The Connector will use the proxy settings in the context of the installing user. All Connector services will also run as Local Service. To configure support for the services to use a proxy, run the following command:

Netsh winhttp import proxy source=ie

Then restart the connector. (No support for auto-detect, authenticating or PAC scripts)

https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-resource-locations/citrix-cloud-connector/proxy-firewall-configuration.html

Rendezvous

This setting enables an HDX session between the client (Workspace App/Receiver) and server (VDA) to be established through the Citrix Gateway Service. When enabled, HDX traffic no longer flows through the Cloud Connector. VDA establishes an outbound connection directly to the Citrix Gateway Service in the Citrix Cloud, therefore minimizing resource constraints of your Citrix Cloud Connectors.

This policy is enabled by default and applies only to HDX sessions established through Citrix Cloud.

Rendezvous conditions:

- VDA 1811 or later

- The functional level at machine catalog 1811 minimum

- CVADS 1811 or later

Note:

If the VDA requires a proxy server to access the internet, the proper proxy configuration is required, however, Proxy connections are not supported when using the Rendezvous protocol. In this instance, you would need to use traffic via the Connector. If the Rendezvous protocol policy is enabled and the ICA traffic can’t reach the Gateway Service directly in the Cloud, the traffic will fall back to the Cloud Connector.

Resiliency

The Citrix Cloud is resilient by design. You do need to factor this resiliency into your Connectors taking in to account the Connector upgrade process. Remember, N+1 always!

The diagram below highlights the resilient nature of the Citrix Cloud.



If using a public Cloud, place your connectors into availability sets.

Local Host Cache

Local Host Cache also provides a level of resiliency should you lose access to the Cloud Control Plane. This is enabled by default. All connection data is copied into a local database (SQL Express) that resides on the Cloud Connector. You can still broker internal connections within your Resource Location without access to the Citrix Cloud. This obviously means you require Storefront on-premises. 
Other areas to note are this works with Xenapp and Pooled VDI. LHC v2 had improvement that allow the use of Pooled VDI. 

By default, power-managed desktop VDAs in pooled Delivery Groups that have the “ShutdownDesktopsAfterUse” property enabled are placed into maintenance mode when an outage occurs. You can change this default, to allow those desktops to be used during an outage. However, you cannot rely on the power management during the outage. (Power management resumes after normal operations resume.) Also, those desktops might contain data from the previous user, because they have not been restarted.To override the default behavior, you must enable it site-wide and for each affected Delivery Group. Run the following PowerShell cmdlets.

Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true Set-BrokerDesktopGroup -Name “<name>” -ReuseMachinesWithoutShutdownInOutage $true

Enabling this feature in the Site and the Delivery Groups does not affect how the configured “ShutdownDesktopsAfterUse” property works during normal operations.

There are sizing recommendations to be noted when using LHC which leads us nicely into the next topic.

Sizing

When updates are deployed to Citrix Cloud, Connector machines get updated.  You do not want to affect your user service. So, if you always want a fully operational environment, you are looking at a minimum of 3 connectors. This is where I disagree with the minimum of 2. Cloud connectors are also stateless. Connections are automatically load balanced but not at equal measure.

- 5000 VDA’s and 20,000 sessions can be used obtained with 2 Cloud        connectors. They would have 4 CPU and 4gb Ram.

- Cpu tends to be the resource constraint with Connectors.

- You do not need premium SSD storage for Connector Workloads.

- Two Cloud Connectors hosted on Azure Standard_A2_v2 VMs are recommended for 1,000 Windows 10 VMs

- The use of 2-vCPU Cloud Connectors is recommended for sites that host 2,500 VDAs

- For faster registrations and stability, go for 4 CPU’s

https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service/install-configure/install-cloud-connector/cc-scale-and-size.html

Connectors Love CPU

Based on the above, 3 connectors might be way too much for your workloads. The 3, in my opinion, is required due to the way Citrix manages the updates rather than specific sizing estimates.

You will have to be careful about VDA registration storms which get initiated about every two weeks by SQL and Delivery Controller updates in the Cloud.

The Authentication that traverses via the Cloud Connectors also has a direct impact on CPU.

The Local Host Cache (Require On-premises Storefront) will also eat into your CPU count. This is caused by the Citrix High Availability Service.

It is for this reason I suggest 4 CPU minimum (1 socket, 4 cores) and you get quicker registration and session launches.

Domain Trusts 

Cloud Connectors cannot traverse domain-Level trusts. For each separate domain, install Cloud Connectors. The same is true for Resource and User Domains. Trusts are required for launching resources in this scenario.

Trust relationships are only required if launching resources in a different domain or forest. (VDA’s in separate resource domain than your users).

Following Domain Trust configurations have been tested by Citrix:
Scenario = Single Domain, Single Forest

Deployed Connectors = One Domain

Trust = None

Domains Listed = Single

Workspace = Yes, all users

Storefront = Yes, all users

Scenario = Parent/Child Domain, Single Forest

Deployed Connectors = Resource(Parent) Domain

Trust = Parent-Child

Domains Listed = Both

Workspace = Yes, all users

Storefront = Yes, all users

 


Scenario = User/Resource Domain, Seperate Forests

Deployed Connectors = Resource Domain

Trust = Forest 2-Way

Domains Listed = Resource Domain

Workspace = Yes, only Resource Forest **

Storefront = Yes all users, both Forests

Scenario = User/Resource Domain, Seperate Forests

Deployed Connectors = Each Forest

Trust = Forest 2-Way

Domains Listed = Both

Workspace = Yes, all users

Storefront = Yes, all users
** Users in user domain may be nested into Resource domain security groups to mitigate this issue.

https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-resource-locations/citrix-cloud-connector/technical-details.html

Domain Functional Levels

Now, I know this has caught a few people out, so it is worth mentioning.

The Citrix Cloud Connector supports the following forest and domain functional levels in Active Directory.
Forest Domain Supported Domain Controllers
Windows Server 2008 R2 Windows Server 2008 R2 Windows Server 2008 R2,

Windows Server 2012,

Windows Server 2012 R2,

Windows Server 2016

Windows Server 2008 R2 Windows Server 2012 Windows Server 2012,

Windows Server 2012 R2,

Windows Server 2016

Windows Server 2008 R2 Windows Server 2012 R2 Windows Server 2012 R2,

Windows Server 2016

Windows Server 2008 R2 Windows Server 2016 Windows Server 2016
Windows Server 2012 Windows Server 2012 Windows Server 2012,

Windows Server 2012 R2,

Windows Server 2016

Windows Server 2012 Windows Server 2012 R2 Windows Server 2012 R2,

Windows Server 2016

Windows Server 2012 Windows Server 2016 Windows Server 2016
Windows Server 2012 R2 Windows Server 2012 R2 Windows Server 2012 R2,

Windows Server 2016

Windows Server 2012 R2 Windows Server 2016 Windows Server 2016
Windows Server 2016 Windows Server 2016 Windows Server 2016

Services

Communication Outbound from Connectors

AD Provider allows Citrix Cloud to manage resources associated with AD accounts


Cloud Agent Logger transmits logs from on premises agents to logger Worker Cloud Service

Cloud Agent Watchdog handles auto updates of connector

Cloud Credential Provider is a local endpoint that interfaces with credential wallet in Citrix Cloud

Web Relay Provider is used by Xenmobile/App-layering to forward http requests received from web relay cloud service to on premises web servers

Config Synch Service copies brokering configuration from CVADS to the local system for LHC high availability

NetScaler Cloud Gateway Provides internet connectivity to on premises desktops/apps without need to open inbound firewall rules or deploy components in DMZ

Remote Broker Provider facilitates comms from local vda’s and storefront servers to the Remote Broker Service in Citrix Cloud

Remote HCL Server proxies’ communications between Delivery Controllers in Citrix Cloud and the hypervisors hosting your virtual resources.

Session Manager Service uses session manager proxy to manage anonymous pre-launch sessions and upload session count information to the Citrix Cloud

There are two services that do not communicate to the Cloud Plane.
 
Cloud Agent System is the provider of privileged services and is only Cloud service running with local system permissions.

High Availability Service listens and processes connection requests during an outage, gathered by configuration sync service which gathers broker information.

Internal Communication

AD Provider communicates with Active Directory over various ports

Web Relay Provider is used by Xenmobile so users can add CVADS resources   through secure hub via the pnagent services site

Remote Broker Provider is the Citrix Cloud version of the Broker Service running on delivery controller in traditional deployments. Works in the same way.

Config Synch/HA service and Remote Broker services work together for local host cache feature.

Config Synchroniser service sends Broker configuration data sent to HA Service. HA writes received data in local database. Remote Broker Provider transfers brokering responsibility to HA service.

NetScaler Gateway Service will send HDX traffic through connectors
Remote HCL service is used to provision Virtual Machines via the CVADS service using MCS

Session Manager service uses session manger proxy to interact with the delivery controller in a traditional deployment. If not using it, the proxy remains dormant

Command-line Installation

CWCConnector.exe /q /Customer:*Customer*  /ClientId:*ClientId*  /ClientSecret:*ClientSecret*  /ResourceLocationId:*ResourceLocationId*  /AcceptTermsOfService:*true*

You can retrieve a list of supported parameters by running CWCConnector /?.

/Customer: Required. The customer ID is shown on the API Access page in the Citrix Cloud console (within Identity and Access Management).

/ClientId: Required. The secure client ID an administrator can create, located on the API Access page.

/ClientSecret: Required. The secure client secret that can be downloaded after the secure client is created. Located on the API Access page.

/ResourceLocationId: Required. The unique identifier for an existing resource location. To retrieve the ID, click the ID button for the Resource Location on the Resource Locations page in the Citrix Cloud console. If no value is specified, Citrix Cloud uses the ID of the first resource location in the account.

/AcceptTermsOfService: Required. The default value is Yes.
I hope this serves as a nice one-stop-shop of Citrix Connector facts.

A final word before the article concludes. If you are looking at Citrix Cloud as a solution to get rid of ‘managed servers’, then great. If you are looking at the Cloud solution to rid yourself of tin, operational costs and have some hard and soft cost savings, even better. If you say, it will reduce the number of servers we require, think again.Certainly, this might be the case with 'Enterprise' customers. Remember, you are adding Connectors and there are limitations when it comes to domain traversing. One thing I will say is that Connectors are less high maintenance than Delivery Controllers, SQL and James Kindon, and there are many advantages to the Citrix Cloud approach.

Carpe Diem

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *