We recently hosted our very first ACE (Ask the Cloud Experts) meetup. This monthly series is designed to provide a channel to connect with Citrix experts to help answer your Citrix Cloud questions. In our first-ever session, we covered Cloud Connectors.
There were a lot of questions, so we’ve broken the transcript of our Q&A into two blog posts (check out Part 1).
Our next ACE meetup will cover Profile Management and is scheduled for Tuesday, May 14. Sign up today!
What if there are two companies merging and they have both their own Citrix Cloud portals already? What’s the best practice to integrate the two environments so they can be managed from a single point?
The best way to approach this would be to contact your Customer Success Manager to find out if there are ways to combine these two environments licenses/subscriptions.
I have only an Azure AD domain with Office 365, and I don’t have an AD on-premises environment. How should I proceed to configure my Cloud Connector with my Azure AD?
The Cloud Connector itself only functions using a Microsoft Active Directory environment. So you’ll need to deploy an AD Domain Services in Azure and then join those connector machines to your domain to be able to establish that connectivity.
Does your on-premises infrastructure change with site aggregation? Can I take down my delivery controllers? How does Cloud Connector fit in here?
Site aggregation is the functionality that StoreFront has today to be able to aggregate multiple sites. What you are doing is taking your site as is and pointing it to the Cloud Connector so that it can be aggregated into your cloud workspace. The site itself continues to function exactly as it did before, except that the cloud workspace can reach out to it to aggregate it into the experience in the cloud.
When using the Gateway service and configuring Workspace, you choose either Gateway Service, Internal only, or NetScaler Gateway. When you want internal/external users to access Workspace, they go through the internet to the Gateway service even if they have local connectivity to the VDA with DNS resolution. Is there going to be any way to have beacons like you do in StoreFront so that all internal users access their VDAs through the high-speed LAN and external users only use Gateway service?
This is not configurable just yet. However, a similar functionality to give the ability to make an intelligent decision in terms of where or how the connections happen (like we do in traditional StoreFront environments) is definitely on the roadmap.
The Cloud Connector seems to have AD identity issues when dealing with an empty AD forest root top-level domain. Customers are not wanting to place the Cloud Connector into the AD forest root. Do we have plans to add support around this or change our ADidentity calls so that we don’t have to place the Cloud Connector into an empty AD forest root?
You don’t need to place the Cloud Connector into the forest root, it just has to have access to talk to the forest root. Basically, network access to the Domain Components (DC) and Global Catalog (GC). On the GC side, it’ll need access to users, computers and others that they want to be visible on Citrix Cloud. On the DC side, it mainly just needs to access root information about the domain itself and its child domains. If you’re leaving ACLs default and removing the Cloud Connector computer accounts from ACLs for any sensitive OUs, it should work just fine.
We did a proof of concept and installed Cloud Connectors with a development name connecting to a Dev Virtual Apps and Desktops. We will now go live with a production name. Can we install new Cloud Connectors and still use the original Dev Virtual Apps and Desktop server in dev?
If your connectors have ‘Dev’ attached to their name and you want to change that name, you’ll have to reinstall the Cloud Connector software for them to show up under a new name. If what you want to use is the same VDA servers you tested during your POC and point them to these new Cloud Connectors, you will have to modify the installation parameters of the VDA software on these servers and point them to these new Cloud Connectors. If you need to rename your customer name environment in the portal itself, please reach out to your Customer Success Manager to get help on this.
Will Citrix Receiver/Workspace single sign-on for published desktops be supported by Cloud Connector in the near future, or will StoreFront always be required?
When Workspace is used instead of the traditional StoreFront, as long as Citrix Cloud is the one collecting the username and password (if you’re using anything with AD), single sign on works. If there’s federation involved and we’re federating out to Azure AD, currently there’s no SSO. This is on our roadmap, and we’re working to support it.
Is multi-factor authentication with third-party tools such as Duo supported with Citrix Cloud?
Right now we do support mutli-factor authentication in Citrix Cloud for administrators and end-users with our integration with Azure AD. So if you’re using Azure AD as your identity provider, all forms of authentication that come with Azure AD are currently supported. We are currently in tech-preview to support Active Directory + TOTP (a protocol used by some popular authenticator apps like the Microsoft Authenticator and Google Authenticator). We will continue to add more authentication methods in the future.
What happens when a customer brings in the added complexity of using the connectors with Azure, AWS, or GCP? Are there any trust-related issues involved between the Citrix Cloud and VDA registration Especially scaling upwards of 30,000 or more VDAs and multiple domains. Do you have any documentation on trust relationships?
Two part question. Regarding trust relationships, we have documentation we can provide. As far as bringing in the added complexity of using these cloud provider platforms, there’s really not a whole lot of complexity added there even when using multiple cloud providers simultaneously. Citrix has made it very easy to incorporate these platforms, fitting into the greater motion of moving to the cloud. And these platforms can be easily separated using different resource locations and integrated with Citrix Cloud by means of Cloud Connectors.
Can the Cloud Connectors be load balanced? What load-balancing capabilities do they have?
Cloud Connectors in Citrix Cloud are naturally load balanced. Any connectors that are in the same resource location are seen as equal and the cloud will use them and distribute the load among them. This means that you can have as many as you need to be able to handle the load that’s necessary, so they are already load balanced.
Cloud Connector upgrades are evergreen. What are some best practices to make sure changes doesn’t interrupt service?
The first failsafe you want to have in place is making sure you have high availability for these machines. We recommend N+1, where N is the minimum number of Cloud Connectors to support your environment and +1 gives you an additional machine to help alleviate concerns, since these connectors normally don’t get updated at the same time. Make sure that the Cloud Connector software is not installed on any virtual machines that can get updates from other services that may require auto-updates. And also make sure that the Cloud Connector software is NOT installed on a machine that has other roles/functions or cannot be rebooted. Cloud Connector machines are to be dedicated for the Cloud Connector software only.
Another item to consider from a design perspective is that the local host cache (LHC) is a great way to minimize any potential impact of changes. If there are any updates or situations that can affect connectivity between your resource-location environment and Citrix Cloud, leveraging the LHC on the Cloud Connectors will minimize the risk and impact to end users.
When we provide the Cloud Connector name to the VDAs, can we provide a load-balanced VIP (or DNS Name) instead of individual Cloud Connector machine names?
You’ll provide the individual machine names, just the same as you would specify delivery controllers individually as well.
What is the best way to see current connections or from which connector sessions originated from (either Gateway or ICA direct). Basically, to see that multiple connectors in a resource location are load balancing?
There are plans for capabilities to be added in order to see which connector a session is being proxied through, but we currently don’t have a tool to display this information.
We put in Workspace recently and have a small number of users. We have discovered recently that the WEM cloud agent on the VDAs needs direct outbound connectivity itself to the WEM cloud plane where we thought that only the Cloud Connector component needed 443 egress. We have been appraised by support that the Cloud Connector WEM service communicates outbound with the WEM cloud plane and passes a token back to the VDA (WEM agent), which then needs to communicate outbound itself. Are there any plans for the connector SW to be changed so that it deals with the full end-to-end connectivity for the cloud service components?
As we’re evolving Citrix Cloud, there are various components that are on-premises that need to speak up to the Cloud. After feedback from customers, the Citrix Cloud Connector being used as a proxy for all communication starts to become a bottleneck. So we’re looking at various components and giving them the ability to communicate directly out to Citrix Cloud, not via the Connector or the proxy. We’re currently working very diligently to make sure that all of those connections are documented, as well as being able to support all of the same proxies so that customers don’t have to figure out how to do it individually with each service.
Don’t forget, as part of your Cloud subscription, you will be assigned a dedicated Customer Success Manager. Make sure you leverage them if you need any additional information, want to join a tech preview or have specific or follow-up questions. And make sure you join our ACE meetups the second Tuesday of each month at 9 a.m. ET for a new cloud topic.
Thanks for reading!
