September 8, 2022 Author:  JP AlfaroSpecial thanks:  Darren Harding, Selma Wei, Armando Rodriguez, Daniel Lugo

Reference Architecture: Citrix DaaS implementation with Azure Active Directory Domain Services for CSPs

Architecture

Azure Active Directory Domain Services
is a fully managed Active Directory service on Microsoft Azure. Not to be confused with Azure AD, which is a cloud-based identity and authentication service for Microsoft services, Azure AD Domain Services (ADDS) provides managed domain controllers. Azure ADDS includes enterprise features like domain-join and group policy. While Azure AD leverages modern authentication and authorization protocols like OpenID Connect and OAuth 2.0, Azure ADDS utilizes traditional protocols that rely on Active Directory, like LDAP and Kerberos. Azure AD Domain Services automatically synchronizes identities from Azure AD to your managed AD environment.

Azure ADDS automatically deploys and manages highly available Active Directory domain controllers on your Azure subscription. Domain controller access is restricted, and you can only manage your domain by deploying management instances with Remote Server Administration tools. Additionally, Domain Admin and Enterprise Admin permissions are not available under the managed service. The Azure ADDS instance is deployed directly to a Virtual Network (VNet) within your subscription, resources can be deployed to the same VNet, or in different VNets. If resources are deployed to a different VNet, it must be connected to the Azure ADDS VNet via a VNet peering.

Azure ADDS can be deployed as a user forest
, or a resource forest. For this implementation, we are deploying Azure ADDS as a user forest, without configuring a trust to an external on-premises AD environment. Also, the Citrix DaaS resources are deployed based on our CSP reference architecture
.

Architecture Scenario 1

This deployment scenario implies the following considerations:

• Azure AD:
  • Shared Azure AD tenant for all customers
• Azure ADDS:
  • Shared Azure ADDS instance for all customers
• Subscriptions:
  • Shared Azure subscription for smaller customers
  • Dedicated Azure subscriptions for larger customers
• Network Connectivity:
  • VNET Peering from dedicated subscriptions to the shared subscription for Azure ADDS connectivity

Architecture Scenario 2

This deployment scenario implies the following considerations:

• Azure AD:
  • Shared Azure AD tenant for all customers
  • Dedicated Azure AD tenant for larger customers
• Azure ADDS:
  • Shared Azure ADDS instance for all customers
• Subscriptions:
  • Shared Azure subscription for smaller customers
  • Dedicated Azure subscriptions for larger customers
• Network Connectivity:
  • VNET Peering from dedicated subscriptions to the shared subscription for Azure ADDS connectivity

Architecture Scenario 3

This deployment scenario implies the following considerations:

• Azure AD:
  • Shared Azure AD tenant for all customers
  • Dedicated Azure AD tenant for larger customers
• Azure ADDS:
  • Shared Azure ADDS instance for small customers
  • Dedicated Azure ADDS instance for larger customers
• Subscriptions:
  • Shared Azure subscription for smaller customers
  • Dedicated Azure subscriptions for larger customers
• Network Connectivity:
  • No VNET peering from dedicated subscriptions to shared subscription

Azure Resource Hierarchy

When designing and organizing your Azure subscription resources, take the following resource hierarchy in consideration:

Initial Assumptions

Azure ADDS

• Azure AD tenant exists
• Azure subscription exists
• An Azure AD account with the following permissions is available:
  • Azure AD: Global Admin
  • Subscription: Contributor
• Azure ADDS will be deployed as a standalone user forest, no trust will be configured
• While it is a possibility, existing AD users will not be synchronized via Azure AD Connect
• Self-service password reset will be deployed to force password resets for password hash synchronization

Citrix Cloud

• A Citrix Cloud subscription is available
• Citrix Cloud Connector will be deployed
• VDA master image will be deployed
• Azure hosting connections will be configured
• Machine Catalog and Delivery Group will be configured

Terminology

The following are the most common Azure terms you need to understand, as described in the Azure documentation:

• Azure subscriptions: Azure subscriptions are an agreement with Microsoft to use Azure services. Billing is tied to a subscription based on the resources consumed, and resources cannot be deployed without a subscription. Subscriptions allow you to organize access to resources. Subscription types include trial, pay as you go, Enterprise Agreement, and MSDN, and each one can have a different payment setup. Azure subscriptions must be tied to an Azure AD tenant.
• Azure AD: Azure AD is Microsoft’s cloud-based identity management service for users, groups, and devices. Azure AD is not to be considered a replacement to traditional Active Directory Domain Services, as it does not support LDAP or Kerberos. Multiple Azure subscriptions can be tied to a single Azure AD tenant. Azure AD offers different types of licenses (Free, Premium 1, and Premium 2) which provide different functionality based on the license level.
• Management Groups: Azure Management Groups are containers that allow you to manage access, policy, and compliance across multiple subscriptions. Management groups can contain subscriptions, or other management groups.
• Azure RBAC: Azure RBAC is utilized to manage authorization for Azure resources. Azure RBAC contains over 70 built-in roles and allows you to create custom roles to manage authorization to resources based on your requirements. Permissions are cascaded from management groups to subscriptions, from subscriptions to resources groups, and from resource groups to resources. The Owner RBAC role provides the highest level of permissions over an Azure Resource and also allows you to manage resource permissions for other users.
• Azure AD Roles: Azure AD roles are used to manage Azure AD related actions, like creating users, groups, app registrations, interaction with APIs, and more. The Global Administrator role grants the highest level of authorization in Azure AD, including access to all Azure AD features, manage roles and licensing for other users, and more. The Global Administrator role is automatically assigned to the user who first creates the Azure AD tenant.
• Custom Azure AD Domain: All new Azure AD tenants are created under the onmicrosoft.com domain, custom domains can be configured by validating ownership with your domain registrar.
• Resource Groups: Resource groups are logical containers utilized to organize resources within Azure and manage their permissions via RBAC. Typically, resources within a resource group share a similar lifecycle. A resource group cannot contain other resource groups, and Azure resources cannot be created unless you specify a resource group. While a Resource Group is deployed to an Azure region, it can contain resources from different regions.
• VNET: An Azure VNET is a software defined network that allows you to manage and deploy resources under an isolated address space in Azure. VNETs allow resources to communicate with other resources on the same VNET, the internet, resources in other VNETs, or on-premises. Access to and from VNETs is secured via Network Security Groups and you can also configure routes by implementing User Defined Routes. Azure VNETs are a layer 3 overlays, so they do not understand any layer 2 semantics like VLANs or GARP. All VNETs contain a main address space and must contain at least one subnet with an address space within it. VM IPs in a VNET are not attached to the actual VM instance, they are assigned to the VM NIC, which is managed as an independent resource.
• VNET Peering: A peering allows for 2 VNETs to connect and communicate via the Azure backbone, as opposed to the traditional VNET-to-VNET connection, which routes traffic through the public internet. Peerings allow for low latency and can be configured across different regions, different subscriptions, and even different Azure AD tenants. Peering connections are non-transitive by default, advanced configuration is required to change this behavior. In a hub and spoke architecture, a spoke VNET can only communicate with the hub, but it is unable to communicate with resources in other spokes.
• Network Security Group: A Network Security Group (NSG) is a set of rules that enable you to control inbound and outbound access to resources inside a VNET, they can be attached to a subnet or a NIC. Inbound and outbound rules within a Network Security Group are managed independently, and all rules must have a priority from 100 and 4096. By default, Network Security Groups include a set of default rules that permit traffic between resources in the same VNET, outbound internet access, among others. Network Security Groups have no relationship whatsoever with OS level firewall configurations and as a rule of thumb, a zero-trust approach is recommended when designing your Network Security Groups.
• App Registration: An app registration is an Azure AD account that allows an external application to interact with Azure APIs. When an app registration is created, Azure AD generates an app ID and a secret, which act as a user name and password. In this implementation, an app registration is created to allow Citrix Cloud to interact with Azure and perform machine creation and power management tasks.

Azure ADDS Considerations

• Azure ADDS automatically synchronizes user identities from Azure AD
• Synchronization works from Azure AD to Azure ADDS, not the opposite way
• It can leverage users created in the Cloud, or users synced via Azure AD Connect
• Azure AD Connect cannot be installed on an Azure ADDS environment to sync objects back to Azure AD
• LDAP write functions only work for objects created directly on ADDS, not for users synced from Azure AD
• Azure ADDS can only be used as a standalone domain (one forest, one domain only), not as an extension of an on-premises domain
• The service is deployed on Azure Availability Zones where available
• Azure ADDS is deployed as a user forest by default, at the moment of this writing, the resource forest deployment model is on preview
• For users synced from Azure AD, the password hash is not synchronized until the users reset their password, Azure Self Service Password Reset is utilized to help users reset their passwords.
• The AAD DC Administrators group, which is created when the Azure ADDS instance is deployed, cannot be edited inside ADUC. AAD DC Administrators group can only be edited from within Azure AD groups in the Azure console
• For users synced from Azure AD:
  • The password cannot be reset from the ADUC console
  • Cannot be moved to a different OU
  • These users are typically used to manage the Azure ADDS instance as a CSP, end customer users can be created inside ADUC
• GPOs can be created and linked to the pre-created AADDC Computers and AADC Users organizational units, not to other pre-created OUs
  • You can create your own OU structure and deploy GPOs
  • Domain and Site level GPOs cannot be created
• OU lockdown is possible by utilizing the Delegation of Control Wizard on new OUs
  • Does not work on pre-created OUs

Logon Process Considerations

Azure ADDS synchronizes user accounts from the Azure AD tenant under which is created. It includes accounts created with a custom domain, accounts created with the initial onmicrosoft.com domain, and B2B accounts (external accounts added to Azure AD as guests). Based on the type of user account, users will have a different logon experience:

• Custom domain accounts:
  • Login using UPN (user@domain.com): Login successful
  • Login using NetBIOS (domain\user): Login successful
• Onmicrosoft domain accounts:
  • Login using UPN (user@domain.onmicrosoft.com): Login unsuccessful (1)
  • Login using NetBIOS (domain\user): Login successful (2)
• B2B accounts (guests):
  • Login using UPN (user@domain.com): Login unsuccessful
  • Login using NetBIOS (domain\user): Login unsuccessful (3)

NOTE:
(1) Adding an alternate UPN name is not allowed on Azure ADDS, so these users cannot login via UPN.

(2) This works properly because the NetBIOS name is the same for all users.

(3) These users cannot authenticate against Azure ADDs, even though they are synchronized, Azure does not have access to their password hash.

Implementation

Azure Components

Step 1: Create a Resource Group for Azure ADDS

1- On the Azure portal menu, select Resource Groups, and click Add

Considerations:

• This step assumes an Azure subscription has been created and is ready to deploy the resources.

2- On the Basics tab, enter the following information, and click Review + Create

• Subscription
• Resource group name
• Resource group region

3- On the Review + create tab, click Create

Considerations:

• Repeat these steps to create resource groups for customer resources, networks, and more.
• Optionally, you can pre-create resource groups for Citrix Machine Creation Services to utilize. Machine Creation Services (MCS) can only utilize empty resource groups.

Step 2: Create the Azure ADDS VNet

1- On the Azure portal menu, select Virtual Networks, and click Add.

2- On the Basics tab, enter the following information, and click Next: IP Addresses:

• Subscription
• Resource group name
• VNET name
• VNET region

3- On the IP Addresses tab, enter the following information, and click Next: Security:

• IPv4 address space
• Add subnets

Considerations:

• Add subnets as determined by your network design decisions. In this case, we are adding a subnet for the ADDS service, and a subnet for shared infrastructure resources, including Citrix Cloud Connectors, master images, and so forth and so on.

4- On the Security tab, configure DDoS and Firewall as required, and click Review + create

5- On the Review + create tab, click Create.

Considerations:

• Repeat these steps to create customer networks, both in the same subscription, or any additional subscription.

Step 3: Configure VNet Peerings

1- On the Azure portal menu, select Virtual Networks, and select the VNET where ADDS will be deployed.

Considerations:

• For this implementation, networking is designed in a hub and spoke architecture. A VNET peering will be configured from the Azure ADDS network (hub) to the customer networks (spokes).
• By default, VNET peerings are not transitive, so spoke networks are not able to communicate with each other unless intentionally configured
  .
• If peering networks on different Azure subscriptions and Azure AD tenants:
  • Users must be added as guest users on the opposite subscription and be granted with RBAC permissions to peer networks.
  • Network Security Groups must be properly configured on both sides.

2- On the VNET blade, click Peerings and Add.

3- On the Add peering blade, enter the following information:

• Name of the peering from the source VNET to the destination VNET
• Subscription
• Destination virtual network
• Name of the peering from the destination VNET to the source VNET

4- Scroll down and click OK

Considerations:

• Repeat these steps to peer other customer (spoke) networks.

Step 4: Create the Azure AD Domain Services instance

1- On the Azure search bar, type Domain Services, and click Azure AD Domain Services

2- On the Azure AD Domain Services page, click + Add.

3- On the Basics tab, enter the following information, and click Next:

• Subscription
• Resource group name
• DNS domain name
• Region
• SKU
• Forest type

Considerations:

• The AAD DS instance region must match that of the network you pre-created on the previous steps.
• A User Forest is the default type of forest on Azure ADDS, they synchronize all Azure AD user accounts to Azure ADDS so that they authenticate against the Azure ADDS instance. This model assumes user password hashes can be synced.
• A Resource forest: is a recently supported type of forest, which is on preview. Under this deployment model, Azure ADDS is used to manage machine accounts. A one-way trust is configured from Azure ADDS (trusting domain) to an on-premises AD environment (the trusted domain). With this configuration, user accounts from the on-premises environment can log in to resources hosted in Azure which are joined to the Azure ADDS domain. This type of forest assumes network connectivity to the on-premises domain is configured.

4- On the Networking tab, enter the following information, and click Next:

• Virtual Network
• Subnet

5- On the Administration tab, click Manage group membership

6- On the Members blade, click + Add members

7- On the Add members blade, search for the accounts that you want to add as members of the AAD DC Administrators group.

8- Once the users have been added, click Select

9- Back on the Administration tab, click Next

Considerations:

• The AAD DC Administrators group membership can only be managed from Azure AD, it cannot be managed from the ADUC console in the Azure ADDS instance.

10- On the Synchronization tab, click Next

Considerations:

• This page can be optionally utilized to select which Azure AD objects to synchronize to Azure ADDS by selecting the Scoped sync type.

11- On the Review tab, click Create

12- On the confirmation pop-up, click OK

Considerations:

• The process to create the Azure ADDS instance can take up to 1 hour.

Step 5: Configure DNS for the Azure ADDS VNET

1- Once the Azure ADDS instance has been created, under Update DNS server settings for your virtual network, click Configure

Considerations:

• This step automatically configures the DNS settings of the VNET where the Azure ADDS instance was created (Hub network). Once configured, all DNS queries are forwarded to the managed domain controllers.
• Customer networks (spokes) must have their DNS settings updated manually.

Step 6: Configure DNS for the customer networks

1- On the Azure portal menu, select Virtual Networks, and select your customer (spoke) VNET.

2- On the VNET blade, click DNS Servers, select Custom, enter the IP address of the managed domain controllers and click Save

Considerations:

• Repeat these steps for every customer (spoke) VNET, and any other external VNET that is peered to the VNET hosting the Azure ADDS instance.

Step 7: Configure Self Service Password Reset (SSPR)

1- On the Azure portal menu, select Azure Active Directory, and click Password reset

Considerations:

• When Azure AD users are initially synced to Azure ADDS, their password hash is not synced, therefore, users must reset their password for this to occur. SSPR is utilized to allow for users to reset their passwords in a simple and secure manner.
• User authentication against Azure ADDS does not work until this step is performed.
• The step to enable SSPR is only required if it has not been previously configured.
• This step is only required if Azure AD users are being managed from the Azure portal (not users synced from on-prem AD via Azure AD Connect). For users synced from on-prem AD via Azure AD connect, follow these steps.

2- On the Properties blade, select All, and click Save.

Considerations:

• You can optionally choose Selected to enable SSPR only to a subset of users.
• Next time the users login, they will be forced to register to SSPR.

Step 8: SSPR User Registration Process

1- When a user logs in, they are redirected to the SSPR registration screen and configure their authentication methods.

Considerations:

• SSPR authentication methods can be selected on the SSPR configuration blade in the Azure portal.
• For this example, SSPR has been enabled with the basic settings, which requires for a Phone an Email to be configured.

2- Once the users enter their authentication information, the SSPR enrollment process is complete.

3- Users can now navigate to Self-Service Password Reset
to reset their password.

Considerations:

• Once this step is complete and the users reset their password, the password hash is synced from Azure AD to Azure ADDS.
• For synced users, the ADUC cannot be utilized to reset their password.

Step 9: Create the AD management VM

1- On the Azure portal menu, select Virtual Machines, and click Add

2- On the Basics tab, enter the following information, and click Next: Disks:

• Subscription
• Resource group
• VM Name
• Region
• Availability options
• Image
• Size
• Admin account details

3- On the Disks tab, enter the OS Disk Type, and click Next: Networking

4- On the Networking tab, configure the following information, and click Next: Management:

• Virtual network
• Subnet
• Public IP (if applicable)
• Network security group

5- On the Management tab, configure the following information, and click Next: Advanced:

• Monitoring
• Auto-shutdown
• Backup

6- On the Advanced tab, leave the default settings, and click Next: Tags

7- On the Tags tab, create any required tags for the VM instance, and click Next: Review + create

8- On the Review + create tab, make sure all information is correct, and click Create

Considerations:

• Repeat the previous steps to create all additional VMs: Cloud Connectors, Master Images, and so forth and so forth and so on.

Step 10: Join the Management VM to the domain

1- Connect to the instance via RDP and open Server Manager, and click Add Roles and Features

2- On the Add Roles and Features Wizard, add the following features:

• Role Administration Tools
• ADDS and AD LDS Tools
• Active Directory module for Windows PowerShell
• AD DS Tools
• AD DS Snap-ins and Command-Line Tools
• Group Policy Management Console (GPMC)
• DNS Manager

3- When the installation finishes, join the VM to the Azure ADDS domain.

Considerations:

• Repeat the previous steps to join all other VMs to the Azure ADDS domain.
• RSAT tools installation is only required for the VMs used to manage the Azure ADDS instance.
• Make sure the password of the user account utilized to join the VMs to the Azure ADDS domain has been reset before attempting these steps.

Step 11: Create an Azure AD App Registration

1- On the Azure portal menu, select Azure Active Directory > App registrations > + New registration

2- On the Register an application blade, enter the following information, and click Register:

• App name
• Supported account types
• Redirect URL
  • Web
  • “https://citrix.cloud.com”

3- On the Overview blade, copy the following values to a notepad:

• Application (client) ID
• Directory (tenant) ID

Considerations:

• The application ID and Directory ID values will be utilized later on when creating a hosting connection for Citrix MCS to manage Azure resources.

4- Click on Certificates & secrets and then +New client secret

5- On the Add a client secret pop-up, enter a Description and Expiration, and click Add

6- Back on the Certificates & secrets screen, copy the value of the client secret

Considerations:

• While the Client ID acts as a user name for the app registration, the Client Secret acts as the password.

7- Click on API permissions and then Add a permission

8- On the Request API permissions blade, under APIs my organization uses search for Windows Azure, and select Windows Azure Active Directory

9- On the Azure Active Directory Graph API blade, select Delegated Permissions, assign the Read all users’ basic profiles permission, and click Add permissions

10- Back on the Request API permissions blade, under APIs my organization uses search for Windows Azure again, and select Windows Azure Service Management API

11- On the Azure Service Management API blade, select Delegated Permissions, assign the Access Azure Service Management as organization users permission and click Add permissions

12- On the Azure portal menu, click Subscriptions and copy the value of your Subscription ID

Considerations:

• Copy the value of all subscriptions utilized to manage resources via Citrix MCS. The hosting connection for each Azure subscription must be configured independently.

13- Select your subscription, and select Access Control (IAM) > +Add > Add role assignment

14- On the Add role assignment blade, assign the Contributor role to the new app registration, and click Save

Considerations:

• Repeat this step to add Contributor permissions to the registration on any additional subscription.
• If utilizing a secondary subscription belonging to a separate Azure AD tenant, a new app registration must be configured.

Citrix Components

Step 1: Install the Cloud Connector

1- Connect to the Cloud Connector VM via RDP and use a web browser to navigate to Citrix Cloud
. Enter your Citrix Cloud credentials and click Sign in

2- Under Domains, click Add New

3- On the Domains tab under Identity and Access Management, click +Domain

4- In the Add a Cloud Connector window click Download

5- Save the cwcconnector.exe file to the instance.

6- Right-click the cwcconnector.exe file, and select Run as administrator

7- On the Citrix Cloud Connector window, click Sign in

8- On the sign-in window, enter your Citrix Cloud credentials, and click Sign in

9- When the installation finishes, click Close

Considerations:

• Cloud Connector installation can take up to 5 minutes.
• At a minimum, 2 Cloud Connectors must be configured per resource location.

Step 2: Configure the VDA Master Image

1- Connect to the Citrix VDA master image VM via RDP and use a web browser to navigate to Citrix Downloads
and download the latest Citrix VDA version

Considerations:

• Citrix credentials are required to download the VDA software.
• Either the LTSR or CR version can be installed.
• A separate VDA installer must be downloaded for Server and Desktop OS machines.

2- Right-click the VDA installer file, and select Run as administrator

3- On the Environment page, select Create a master MCS image

4- On the Core Components page, click Next

5- On the Additional Components page, select the components that best apply to your requirements, and click Next

6- On the Delivery Controller page, enter the following information, and click Next:

• Select “Do it manually”
• Enter the FQDN of each Cloud Connector
• Click Test Connection and then Add

7- On the Features page, check the boxes of the features you want to enable based on your deployment needs, then click Next

8- On the Firewall page, select Automatically, and click Next

9- On the Summary page, ensure all the details are correct, and click Install

10- The VM will be restarted during installation

11- After the installation finishes, on the Diagnostics page, select the option that best fits your deployment needs, and click Next

12- On the Finish page, make sure Restart machine is checked, and click Finish

Step 3: Create an Azure Hosting Connection

1- On the Citrix Cloud hamburger menu, navigate to My Services > DaaS

2- In Web Studio, navigate to Hosting, and select Add Connection and Resources

4- On the Connection page, click the radio button next to Create a new connection, enter the following information, and click Next:

• Zone
• Connection type
• Azure environment

5- On the Connection Details page, enter the following information, and click Use Existing:

• Subscription ID
• Connection name

6- On the Existing Service Principal page, enter the following information, and click OK:

• Active Directory ID
• Application ID
• Application Secret

7- Back on the Connection Details page, click Next

8- On the Region page, select the region where your Cloud Connector and VDA were deployed, and click Next

9- On the Network page, enter a name for the resources, select the appropriate Virtual Network and Subnet, and click Next

10- On the Summary page, ensure all the information is correct, and click Finish

Step 4: Create a Machine Catalog

1- In Web Studio, navigate to Machine Catalogs, and select Create Machine Catalog

2- On the Introduction page, click Next

3- On the Operating System page, select the appropriate OS, and click Next

Considerations:

• Subsequent screens will slightly vary depending on the OS type selected in this page.

4- On the Machine Management page, select the following information, and click Next:

• The machine catalog will use: machines that are powered managed
• Deploy machines using: Citrix Machine Creation Services (MCS)
• Resources: select your Azure hosting connection

5- On the Desktop Experience page, select the options that best adjust to your requirements, and click Next

6- On the Master Image page, select the master image, the functional level (VDA version), and click Next

7- On the Storage and License Types, select the options that best adjust to your requirements, and click Next

8- On the Virtual Machines page, configure the number of virtual machines to deploy, the machine size, and click Next

9- On the Network Interface Cards page, add NICs as required, and click Next

10- On the Write Back Cache page, select your write cache options, and click Next

11- On the Resource Groups page, select between creating new resource groups for the Citrix MCS resources or using pre-created resource groups.

Considerations:

• Only empty resource groups appear on the list of existing resource groups.

12- On the Active Directory Computer Accounts page, configure the following options, and click Next:

• Account option: Create new AD accounts
• Domain: select your domain
• OU: the OU where the computer accounts will be stored
• Naming scheme: naming convention to be utilized

Considerations:

• Numbers will replace the pound signs on the naming scheme
• Be mindful of the NetBIOS 15-character limit when creating a naming scheme

13- On the Domain Credentials page, click Enter credentials

14- On the Windows Security pop-up, enter your domain credentials, and click Done

15- On the Summary page, enter a name and description, and click Finish

Step 5: Create a Delivery Group

1- In Web Studio, navigate to Delivery Groups, and select Create Delivery Group

2- On the Machines page, select your machine catalog, the number of machines, and click Next

3- On the Users page select an authentication option, and click Next

4- On the Applications page, click Add

5- On the Add Applications page, select which applications you want to publish, and click OK

Considerations:

• While most applications will show through the start menu, you can also optionally add applications manually.
• This step can be skipped if you do not need to publish seamless applications.

7- Back on the Applications page, click Next

8- On the Desktops page, click Add

9- On the Add Desktop page, configure the Desktop, and click OK

Considerations:

• This step can be skipped if you do not need to publish full desktops.

10- Back on the Desktops page, click Next

11- On the Summary page, enter a name, a description, and click Finish