Jump to content

PoC Guide: Deploying Citrix DaaS on Amazon WorkSpaces Core

  • Contributed By: Gerhard Krenn Special Thanks To: Camilo Marino

PoC Guide: Deploying Citrix DaaS on Amazon WorkSpaces Core
 

Overview

AWS WorkSpaces Core is a managed virtual desktop infrastructure designed to work with third-party VDI solutions such as Citrix DaaS. It is the compute layer of AWS workloads that the Citrix DaaS control plane can help orchestrate and manage to deliver HDX-optimized apps anywhere. AWS WorkSpaces Core and Citrix improve cost savings, simplify cloud management, and provide a superior user experience.

Citrix DaaS treats AWS WorkSpaces Core as another Resource Location option to leverage within your deployment. It helps your IT teams manage and provision WorkSpace Core desktops directly from the Citrix platform, reducing application delivery complexity and simplifying operations. With security features like Zero Trust Network Access (ZTNA), contextual access policies, and secure browser redirection, Citrix protects your business from cyber threats and data leaks.

Citrix improves the WorkSpaces Core experience with advanced HDX graphics, Unified Communication optimizations, USB redirection, and support for 3D workloads, ensuring smooth performance on any device or network. With centralized management, automated patching, and streamlined updates, Citrix optimizes your budget by reducing IT costs and complexity.

This Proof of Concept guide will help you start deploying Citrix DaaS on Amazon WorkSpaces Core.
 

The following is covered in this guide:

  1. Deploying all needed entities for Citrix DaaS:
    1. Deploying a Resource Location and its Cloud Connectors
  2. Deploying all needed entities for Amazon WorkSpaces Core:
    1. Deploying a VPC
    2. Deploying the Subnets and Gateways
    3. Setting the IAM permissions
    4. Deploying all needed instances like the Jumphost and a Domain Controller
  3. Creating the Deployment of Citrix DaaS on Amazon WorkSpaces Core
     

 Note: 

To automatically deploy Citrix DaaS and Amazon WorkSpaces Core using Terraform, please review our PoC Guide: Deploying Citrix DaaS and Amazon Workspaces Core using Terraform.

 

Deploying Citrix DaaS on Amazon WorkSpaces Core

Before deploying Citrix DaaS, we must create and configure all necessary prerequisites.
We assume you already have a Citrix Cloud tenant with an active trial or a paid subscription to the Citrix DaaS service and an active AWS account.
 

Deploy an Amazon VPC

An Amazon Virtual Private Cloud (VPC) enables you to launch AWS resources into a virtual network that you have defined.

Important: 

It is possible to have multiple VPCs in your AWS tenant.
Create a dedicated
VPC for your Citrix DaaS deployment.
Tag all resources for easier management.
The default
VPC holds these IP address ranges: 172.31.0.0/16

 

  1. Log on to your AWS console and open the VPC service dashboard (enter VPC in the Search bar at the top of the page):
  2. No VPCs are defined, so we need to create one.
    vpc1.png
  3. Choose the AWS region where you want to create your VPC (example screenshot):
    vpc2.png
  4. Fill out the VPC settings according to your needs (example screenshot):
    vpc4a.png
    vpc4b.png
    vpc4c.png
  5. After completing all settings, click Create VPC to start creation. It will take some moments before the VPC is ready.
    vpc-new.png

Note: 

For more information about VPCs, please visit Amazon´s Product Documentation pages.
 

 

Deploy Subnets, Internet Gateways, NAT Gateways, Route Tables and Security Groups

After creating the VPC, we deploy all needed network components, such as Subnets, Internet Gateways, NAT Gateways, and Routing Tables.
 

Deploying the Subnets

A Subnet is a range of IP addresses in your VPC.
You can create AWS resources
in specific subnets, such as EC2 instances.

The Subnet type is determined by how you configure routing for your Subnets:

  • Public Subnet: The Subnet has a direct route to an Internet Gateway. Resources in a Public Subnet can directly access the Internet.
  • Private Subnet: The Subnet does not have a direct route to an Internet Gateway. Resources in a Private Subnet require a NAT device to access the Internet.
     

Important: 

Each Subnet must be associated with a Route Table, specifying all allowed outbound traffic routes. Every Subnet is automatically associated with the main Route Table for the VPC.
Disable the
Auto-assign IP settings, as otherwise, a public IPv4 address is automatically requested for each new Network Interface in this Subnet.

 

 

Note: 

Security Groups enable you to increase security for the resources in your VPC as they act like virtual firewalls.
 

  1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar on top of the page), and choose the Subnets option:
  2. In this guide, we create four different Subnets:
    1. One Public Subnet containing the Jump Host VM
    2. One Private Subnet for the Cloud Connector VMs and other Infrastructure-related VMs
    3. Two Private Subnets for all Worker VMs/VDAs
      Example screenshots:

      sn1.png

      sn-pub1.png

      sn-all1.png
  3. Remember to disable the Auto-assign setting.
    sn-pub2.png
     

Note: 

For more information about Subnets, please visit Amazon´s Product Documentation pages.
 

After creating the Subnets, you must create an Internet Gateway to enable the Public Subnet and the Jump Host-VM to connect to the Internet.
 

Deploying an Internet Gateway

An Internet Gateway allows communication between your VPC and the Internet. It supports IPv4 and IPv6 traffic and provides a target in your VPC Route Tables.
Resources in your Public Subnets can connect to the Internet if they have a public IPv4 address or an IPv6 address. The communication flow is two-way—the resources can also be contacted from the Internet.

For communication using IPv4, the Internet Gateway also performs Network Address Translation (NAT).
 

Important: 

Make sure to secure the communication flow of your resources by using Network ACLs or Security Groups.
 

  1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar on top of the page), and choose the Internet Gateways option (example screenshot):
    inet-gw1.png
  2. After creating the Internet Gateway, you must attach it to the VPC by clicking the Attach to a VPC button. Choose the correct VPC.
    inet-gw3.png

To connect the Public Subnet to the Internet, you need to adjust the adjacent Route Table. A Route Table contains a set of routes directing network traffic from your Subnet or Gateway.

  1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar at the top of the page), and choose the Route Tables option.
  2. Choose Create Route Table and set the values according to your needs.
    rt1.png
  3. Create the Route Table by clicking the adjacent button.
  4. After creation, choose the just created Route Table and edit the routes:
    rt2.png
  5. Enter 0.0.0.0/0 into the Destination field and choose the Internet Gateway you created as the Target. Click Add route to save the route to the Route Table

The Public Subnet now has a connection to the Internet.
 

Deploying a NAT Gateway

After creating the Internet Gateway, you need to create a NAT Gateway in the Private Subnet(s) to enable the Private Subnet(s) to connect to the Internet.

A NAT Gateway is a Network Address Translation (NAT) device.
 

Important: 

You can use a NAT Gateway to enable instances in a Private Subnet to connect to services outside your VPC. External services cannot initiate a connection with those instances.
A NAT Gateway is for use with IPv4 traffic only.

 

When you create a NAT Gateway, you specify one of the following connectivity types:

  • Public – (Default) Instances in Private Subnets can connect to the Internet.
  • Private – Instances in Private Subnets can connect to other VPCs or your on-premises network but not to the Internet.
  1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar at the top of the page), and choose the NAT gateways option.
    nat-gw1.png
  2. Choose the settings according to your needs and click on Create NAT gateway to create it.
  3. After creation, you need to add a Route Table and change the Route Table for the NAT Gateway as you did before for the Internet Gateway.
    rt3.png
  4. Add the correct settings and click on Add route.
  5. After changing the Route Table, you must edit the Subnet settings by choosing Subnet associations. Select the Internal Subnet and click on Save associations.
    nat-gw2.png

All instances in the Internal Subnet should be able to connect to the Internet.

Note: 

For more information about Gateways, please visit Amazon´s Product Documentation pages.
 

Set the IAM Permissions

After creating all needed Network components, we must set all required IAM permissions.

Identity and Access Management (IAM) allows control of access to AWS resources.
IAM controls who can be authenticated (signed in) and authorized (have permissions) to use Amazon VPC resources.

 

Deploying the initial IAM Policy

You can control access by attaching policies and attaching them to identities or resources.
A Policy defines the permissions associated with it. Policies are evaluated when a user or a root user wants to access a resource.
Permissions in the Policies determine whether the request is allowed or denied.
Most Policies are stored in AWS as JSON documents.

More information about IAM JSON-based policies can be found in the IAM JSON policy reference.
 

Deploying Security Groups on the Network Entities

A Security Group acts like a virtual firewall.
If you associate a Security Group with an EC2 instance, it controls the instance's inbound and outbound traffic.

When you create a VPC, it comes with a default Security Group.
You can create additional Security Groups for a VPC, each with their own inbound and outbound rules:

  • You can specify each inbound rule's source, port range, and protocol.
  • You can specify each outbound rule's destination, port range, and protocol.

The following diagram shows a VPC with a Subnet, an Internet Gateway, and a Security Group.
The Subnet contains an EC2 instance. The Security Group is assigned to the instance and acts as a virtual firewall. The only traffic that reaches the instance is the traffic allowed by the Security Group rules.

aws-security-group-overview.png

  1. Log on to your AWS console, enter VPC in the Search bar at the top of the page, and choose the Security option. Click on Security Groups on the Dashboard.
    sg1.png
  2. Create a new Security Group by clicking on Create security group.
    sg1a.png
  3. Fill out all relevant fields and add the Inbound Rules by clicking Add rule on the Inbound Rules part.
    sg3.png
    For the Security Group bound to the Instances in the Public Subnet, use the following rules:

Type: HTTP
Protocol: TCP
Port range: 80
Source: Custom 0.0.0.0/0

Type: HTTPS
Protocol: TCP
Port range: 443
Source: Custom 0.0.0.0/0

Type: RDP
Protocol: TCP
Port range: 3389
Source: MyIP – your current external IP should be entered automatically

Create more Inbound Rules according to your needs.
 

For the Security Group bound to the Instances in the Private Subnet, use the following rules:

Type: HTTP
Protocol: TCP
Port range: 80
Source: Custom 0.0.0.0/0

Type: HTTPS
Protocol: TCP
Port range: 443
Source: Custom 0.0.0.0/0

Type: RDP
Protocol: TCP
Port range: 3389
Source: Custom 0.0.0.0/0

Type: Custom TCP
Protocol: TCP
Port range: 1494
Source: Custom 0.0.0.0/0

Type: Custom UDP
Protocol: UDP
Port range: 1494
Source: Custom 0.0.0.0/0

Type: Custom TCP
Protocol: TCP
Port range: 2598
Source: Custom 0.0.0.0/0

Type: Custom UDP
Protocol: UDP
Port range: 2598
Source: Custom 0.0.0.0/0

Create more Inbound Rules according to your needs.

After creating all the needed rules, click on Create security group to create it.sg2.png

sg4.png

You have successfully created all needed Security Groups. All necessary Network-related prerequisites have been created.
 

Note: 

For more information about Security Groups, please visit Amazon´s Product Documentation pages.
 

 

Deploy all needed Instances in your VPC

An Amazon EC2 Instance is a Virtual Machine in the AWS Cloud environment. Amazon EC2 provides a wide range of Instance types. You can choose an Instance type that provides the compute resources, memory, storage, and network configurations that meet your needs.

In this section, we will initially deploy the following Instances:

  • (1) Jump Host for accessing the environment over the Internet using RDP
  • (1) Domain Controller for providing all needed Active Directory functionalities
  • (2) Cloud Connectors
  • Further Instances will be created automatically during the Machine Catalog creation.

Important: 

To access a non-domain-joined Windows-based Instance, you need an EC2 Key Pair to decrypt the administrator password. A Key Pair, consisting of a public key and a private key, is a set of security credentials you use to prove your identity.

After joining the Instance to a Domain, you can log on using the Domain credentials.
The Key Pair is used only for local Admin access
.

 

 

Creating the EC2 Key Pair

Before deploying Windows Instances, you must create a Key Pair to gain access to the Instance after it is created.

  1. Log on to your AWS console, enter EC2 in the Search bar at the top of the page, and choose the Network & Security option. Click on Key Pairs on the Dashboard. If no Key Pair was already created, click Create key pair..
    kp1.png
  2. Choose the needed settings and click Create key pair.
    kp2.png

 

Important: 

After successful creation, download and store the Key Pair in a safe place.
You will need it each time you access the Windows Instance with local administrator credentials.

 

 

Deploying the Jump Host Instance

Our environment will be completely shielded and deployed in the already-created Private Subnet for security reasons.
Administrative access to the Instances is only possible using a dedicated Jump Host Instance in the Public Subnet.

Important: 

Choose the right Instance type that fits your needs.
Each type offers different compute, memory, and storage capabilities, which reflect
different costs. An overview of all available Instance types can be found here.

In this guide, we chose a t2.medium type for the Jump Host.

 

  1. Log on to your AWS console, enter EC2 in the Search bar at the top of the page, and choose the Instances option. Click on Launch instance on the Dashboard.
    jumphost1.png
  2. Choose all relevant settings for the new Instance, such as Name and Tags, AMI Type and AMI Image, Instance Type, Key Pair to log in, Security Group to which this Instance will be bound, and Storage configuration.
    Set advanced details according to your needs.
    jumphost2.pngjumphost3.pngjumphost4.png
  3. After choosing and setting all the needed information, click Launch instance to create the Instance.
  4. After successful creation, the Jump Host Instance is listed on the Instances tab.
    jumphost5.png

 

Connecting to the Jump Host Instance Instance

For security reasons, the Jump Host Instance is not Domain-joined. You need to log on to it using local administrator credentials.

As mentioned in the Key Pair section, you need an EC2 Key Pair to decrypt the administrator password.

  1. To log on to the Instance, open the AWS console, enter EC2 in the Search bar at the top of the page, and choose the Instances option.
  2. Mark the Instance you want to connect to and click on Connect.
    jumphost-connect1.png
  3. Choose RDP client as the connection method and click Get password.
    jumphost-connect2.png
  4. Now upload the mentioned Key Pair using Upload private key file. Click Decrypt password after uploading to get the administrator credentials.
    jumphost-connect3.png
  5. Now you have the decrypted login information and can log on to the Jump Host Instance using RDP.
    jumphost-connect4.png

 

Deploying the Domain Controller Instance

For this environment, we decided to follow our standard deployment type for Domain Controllers:

The AD deployment consists of a Hub-and-Spoke model. Each Resource Location running on a Hypervisor/Hyperscaler is connected to the primary Domain Controller using IPSec-based Site-to-Site VPNs. Each Resource Location can have its subdomain if needed.

Note: 

You can follow the steps mentioned above to deploy the Jump Host Instance.
 

 

After the successful creation of the Domain Controller Instance, you can access it by:

  1. Connect to the Jump Host Instance using RDP and log on using the Key Pair.
  2. Connect to the Domain Controller Instance using RDP from the Jump Host Instance.
  3. The Domain Controller and Replication configurations are out of this guide's scope.
     

Assuming the Domain Controller Instance is completely configured, you can proceed to the next step – deploying and configuring the Cloud Connector Instances. 
 

Deploying and Configuring the Resource Location and its Cloud Connector Instances

Connecting your resources to Citrix Cloud involves deploying Cloud Connectors in your environment and creating Resource Locations.

Resource Locations contain the resources required to deliver Cloud Services to your subscribers. Depending on which Citrix Cloud services you use and the services you want to provide your subscribers, they can contain different resources.

To create a Resource Location, install at least two Cloud Connectors in your domain. 

Note: 

You can follow the steps mentioned above for deploying the Jump Host Instance, but we recommend choosing another Instance type, such as a t3.large.
 

After the successful creation of the Cloud Connector Instances, you can access them by:

  1. Connect to the Jump Host Instance using RDP and log on using the Key Pair
  2. Connect to the Cloud Connector Instances using RDP from the Jump Host Instance

Before deploying the Cloud Connector software, you must add the Cloud Connector Instances to the Domain. This step is outside the scope of this guide.

For more detailed step-by-step instructions, please look at the corresponding part in this guide.

As all Cloud Connector Instances were successfully registered, you can proceed to the next step – deploying and configuring Amazon WorkSpaces Core.

 

Deploying Amazon WorkSpaces Core

This is a multi-step process: Create the Image, a Directory Connector, and the AWC Deployment.

If your licensing agreement with Microsoft allows it, you can bring and deploy your Windows 10 or 11 VDI machines into your WorkSpaces Core environment. Before enabling your account for Bring your Own Licenses (BYOL), you must go through a verification process to confirm your eligibility for BYOL. You can find more information here. You then need to enable BYOL for your account by following the instructions in Enable BYOL for your eligible WorkSpaces account using the Amazon WorkSpaces console.

  1. Log on to your AWS console and enter WorkSpaces in the Search bar on top of the page.
    awc-console-workspaces.png
  2. Choose Account Settings from the WorkSpaces Console.
    prereq-acc1.png
  3. If you don't see the Enable BYOL option, your account is not eligible for BYOL. You must create a Technical Support Case to enable your account to use BYOL.
    prereq-acc1a.png
    prereq-acc1b.png
  4. After your account is enabled for BYOL, you can set it up by clicking on Set up BYOL.
    Under Bring Your Own License (BYOL), in the Management network interface IP 
    address range area, choose an IP address range, then choose Display available CIDR blocks.
  5. Select the CIDR block you want to use and then choose Enable BYOL.
  6. After successful enrollment (enabling BYOL can last several hours), the WorkSpaces Console shows the successful BYOL enablement.
    prereq-acc2.png

 

Deploying and Configuring the Image

After you confirm that your VM meets the Microsoft BYOL requirements by following the instructions in Confirm that the Windows VM in Amazon WorkSpaces meets the requirements for Microsoft BYOL, you must export the VM from your virtualization environment. You will need this to create an image for BYOL that you can use in WorkSpaces.

The VM you export must be on a single volume with a maximum size of 70 GB and at least 10 GB of free space.

Note: 

Describing the whole process of creating a BYOL Image is out-of-scope of this guide.

For more information, see the documentation for
Exporting your VM from its virtualization environment, Bring Your Own Windows desktop licenses in WorkSpaces - Amazon WorkSpaces, and Bringing your Windows 11 image to AWS with VM Import/Export.

 

 

Important: 

To stay compliant with Microsoft licensing terms, AWS runs your BYOL WorkSpaces on hardware dedicated to you in the AWS Cloud.
 

 

Your Image must run one of the following Windows versions:

  • Windows 10 Version 22H2 (November 2022 Update)
  • Windows 10 Enterprise LTSC 2019 (1809)
  • Windows 10 Enterprise LTSC 2021 (21H2)
  • Windows 11 Enterprise 23H2 (October 2023 release)
  • Windows 11 Enterprise 22H2 (October 2022 release)

 

Important: 

While AWC creates the VDI VMs, the VDAs are not configured to get the list of Cloud Connectors.
You must manually configure the VDAs by setting the adjacent Registry key or deploying a GPO containing the addresses of the Cloud Connectors. For more information, see VDA registration.

 

  1. In this example, we set the Registry key HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ) and fill in the DNS name of the Cloud Connector.
    awc-unregistered1.png
  2. Make sure to check the successful registration to the Cloud Connectors:
    Restart the
    Citrix Desktop Service and open the Event Viewer.
  3. Look for the adjacent events in the Application log:
    awc-unregistered2.png

 

Deploying and Configuring the Directory

WorkSpaces uses a directory to store and manage information for your WorkSpaces and users. The most used options are:

  • AD Connector — Use your existing on-premises Microsoft Active Directory.
    Users can sign into their WorkSpaces using their on-premises credentials and access on-premises resources from their WorkSpaces.

     
  • AWS Managed Microsoft AD — Create a Microsoft Active Directory hosted on AWS.

In this example, we use our own Domain Controller – an Instance running on Amazon EC2, which runs all relevant AD roles.

  1. Log on to your AWS console and enter Directory Service in the Search bar at the top of the page.
    awc-console-directory.png
  2. Click on Set up directory.
    directory1.png
  3. Select AD Connector from the list of Directory types according to your needs.
    directory2.png
  4. Select the Directory Size according to your needs.
    directory3.png
  5. Choose the VPC and Subnet settings according to your needs.
    directory4.png
  6. Enter all Connect to AD-related settings according to your needs.
    directory5.png
  7. Review all settings and click Create directory to start the process.
    directory6.png
  8. The Directory will now be created. This can be a lengthy process. Please check the Directory dashboard to see if the Directory was successfully created and is available before proceeding.
    directory7.pngdirectory9.png

 

Deploying and Configuring the Amazon Web Services Account

This procedure enables all needed permissions for Citrix DaaS to connect to AWS.

  1. Log into your Citrix Cloud Console, open the DaaS service, and choose Quick Deploy.
    cc-console-quickdeploy1.png
  2. Choose Amazon WorkSpaces Core.
    cc-console-quickdeploy2.png
  3. Under Step 2, Click on Start.
    cc-quickdeploy3a.png
  4. On the shown page, click on Download AWS CloudFormation Template.
    cc-quickdeploy3b.pngcc-quickdeploy3c.png
  5. Log on to your AWS console and enter CloudFormation in the Search bar on top of the page.
    cf1.png
  6. Under Create Stack, click on With new resources (standard).
  7. Select Choose an existing template and Upload a template file on the following page. Click Choose file and upload the Cloud Formation template you downloaded from Citrix Quick Deploy. Click Next.
    cf2.png
  8. Provide a stack name and a Role name for the role that will be created. Click Next.
    cf3.png
  9. Leave all the default parameters on the next screen, Acknowledge the warning message, and click Next.
    cf4.png
  10. Click Submit.
  11. Once the Cloud Formation deployment is done, go to IAM in AWS and search for the created role. Copy the ARN. It will be used later in the configuration.
    cf5.png

 

Creating the Deployment using the Quick Deploy wizard of Citrix DaaS

A Deployment is a group of VDI Desktops users can access from their Citrix Workspace.
This procedure specifies the characteristics of the Virtual Machines to be deployed as desktops and which AD users can use them.

Note: 

Amazon Workspaces Core sets the computer names when the Workspace is created. They are used as an identifier to ensure accurate Workspace data. You cannot modify the computer name using Citrix DaaS for Amazon Workspaces Core.
 

Citrix DaaS WebStudio enables the creation of the AWC Deployment using the QuickDeploy wizard.

  1. Log into your Citrix Cloud Console, open the DaaS service, and choose Quick Deploy.
    cc-console-quickdeploy1.png
  2. Choose Amazon WorkSpaces Core.
    awc-deploy2.png
  3. The Quick Deploy wizard shows all the needed steps. As the Resource Location was already created, the wizard marks this first step as Completed.
    awc-deploy3.png


    awc-deploy3a.png
  4. You can review each completed step by clicking Review.
    awc-deploy3aa.png
  5. Next, connect the Amazon Web Services account. Click Start to begin.
  6. Review the prerequisites and create the needed roles. The process was described earlier in this guide. Click Next
  7. Enter the arn: noticed above into the Role ID field and enter an appropriate name according to your needs. Click Next.
    awc-deploy7.png
  8. Choose the AWS region according to your needs. Click Next.
    awc-deploy8.png
  9. The Quick Deploy wizard will show that BYOL support has been successfully enabled. If not, you must stop and follow the instructions above to enable BYOL. If BYOL is already enabled, click Next.
    awc-deploy9.png
  10. Review the Summary and click Finish.
    awc-deploy10.png
  11. Assigning the Amazon Web Services account is complete.
    awc-deploy11.png
  12. The next step is to create the Directory Connection. Click Start to begin.
    awc-deploy12.png
  13. Review the prerequisites and click Next.
    awc-deploy13.png
  14. Choose the AWC-adjacent Citrix Cloud Resource Location. Click Next.
    awc-deploy14.png
  15. Choose the correct Account representing the needed arn:. Click Next.
    awc-deploy15.png
  16. The wizard chooses the Directory and the Subnets assigned to the chosen Account. Click Next.
  17. Enter the Organizational unit, select the Security Group and the administrator privileges according to your needs. Click Next.
    awc-deploy27.png
  18. Review the Summary and enter an appropriate Name. Click Add directory connection to assign the Directory.
    awc-deploy28.png
  19. Assigning the Directory Connection is complete.
    awc-deploy29.png
  20. The next step is to assign the Image. Click Start to begin.
    awc-deploy29.png
  21. Look at the prerequisites corresponding to your Image type and needs. Click Next: Choose image to proceed.
    awc-deploy30.png
  22. Choose the Image. Enter an appropriate Name and select the correct Account. After selecting the Account, the wizard lists all the images assigned. Select the Image according to your needs.
    awc-deploy31.png
  23. Choose the Ingestion of dedicated Graphic processors. Select Applications according to your needs, which will be included in the Image during the Image Creation process. Click Next: Summary.
    awc-deploy32.png
  24. Review the Summary and click on Import Image. This process might take several hours.
    awc-deploy33.png
    awc-deploy34.png
  25. Assigning the Image is complete.
    awc-deploy35.png
  26. The next step is Deliver the Deployment to the Users. Click Start to begin.
    awc-deploy35.png
  27. Review the Create deployment settings. The Directory Connection and Image chosen earlier should be set. Choose the Performance settings according to your needs. Click Next: Encryption.
    awc-deploy36.png
  28. Choose the Encryption settings according to your needs.
    awc-deploy37.png
  29. Select the Desktops settings according to your needs. Beware of choosing the Number of VDAs and the Volume sizes within your needs to limit costs.
    awc-deploy38.png
  30. If you want to assign the AD-User(s) to the VDIs during the creation, choose the AD-User(s) here.
    awc-deploy39.png
  31. Review the Summary and assign an appropriate name to the Deployment.
    awc-deploy40.png
  32. The Quick Deploy wizard should show all steps as complete.
    awc-deploy41.png
  33. Review the settings.
    awc-deploy42.png
    awc-deploy43.png
    awc-deploy44.png
    awc-deploy45.png
    awc-deploy46.png
  34. The creation of the AWC Deployment is completed. This could take some time to complete.

 

Test User Access to this Environment

Log on to your environment using Citrix WorkSpace App using User credentials assigned to this environment.
Check if all assigned Applications and Desktops are available:
awc-deploy47.png

The assigned AWC Desktop is available. The environment is ready to use:
awc-connect.gif

 

Summary

Deploying Citrix DaaS on Amazon WorkSpaces Core is straightforward.
However, all prerequisites must be fulfilled on the Amazon and Citrix DaaS sides.
Bringing your own Windows licenses (BYOL) into WorkSpaces Core enables you to use Windows Desktop-based VDI deployments on Amazon´s EC2.

We have shown examples of creating all the needed entities and configurations to deploy a working Citrix DaaS environment running on Amazon WorkSpaces Core.

 

 

 

 

 

 


User Feedback


There are no comments to display.



Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...