Connection to AWS
Create and manage connections and resources describes the wizards that create a connection. The following information covers details specific to AWS cloud environments.
Note:
Before creating a connection to AWS, you need to first finish setting up your AWS as a resource location. See AWS virtualization environments.
Create a connection
When you create a connection using Studio:
- You must provide the API key and secret key values. You can export the key file containing those values from AWS and then import them. You must also provide the region, availability zone, VPC name, subnet addresses, domain name, security group names, and credentials.
- The credentials file for the root AWS account (retrieved from the AWS console) is not formatted the same as credentials files downloaded for standard AWS users. Therefore, Citrix DaaS cannot use the file to populate the API key and secret key fields. Ensure that you are using AWS Identity Access Management (IAM) credentials files.
Note:
After you create a connection, attempts to update the API key and secret key might fail. To resolve the issue, check your proxy server or firewall restrictions and ensure that the following address is contactable:
https://*.amazonaws.com
.
Limitation
If you change the name of an AWS Virtual Private Cloud (VPC) in the AWS console, then the existing hosting unit in Citrix Cloud breaks. When the hosting unit is broken, you cannot create catalogs or add machines to existing catalogs. To resolve the issue, change the name of the AWS VPC back to the original name.
Host connection default values
When you create host connections in Studio for the AWS cloud environment, the following default values display:
Option | Absolute | Percentage |
---|---|---|
Simultaneous actions (all types) | 125 | 100 |
Maximum new actions per minute | 150 | n/a |
Maximum concurrent provisioning operations | 100 | n/a |
MCS supports 100 maximum concurrent provisioning operations by default.
You can configure these values by accessing the Citrix Studio Advanced section on the Edit Connection screen:
Alternatively, you can use the Remote PowerShell SDK to set the maximum number of concurrent operations for optimal settings per your environment.
Use the PowerShell custom property, MaximumConcurrentProvisioningOperations
, to specify the maximum number of concurrent AWS provisioning operations.
Before configuration:
- Ensure you have installed the PowerShell SDK for Cloud.
- Understand that the default value for
MaximumConcurrentProvisioningOperations
is 100.
Perform the following steps to customize the MaximumConcurrentProvisioningOperations
value:
- Open a PowerShell window.
- Run
asnp citrix*
to load the Citrix-specific PowerShell modules. - Enter
cd xdhyp:\Connections\
. - Enter
dir
to list the connections. -
Change or Initialize the Custom Properties string:
-
If the Custom Properties string has a value, copy the Custom Properties into Notepad. Next, change the
MaximumConcurrentProvisioningOperations
property to your preferred value. You can enter a value ranging 1–1000. For example,<Property xsi:type="IntProperty" Name="MaximumConcurrentProvisioningOperations" Value="xyz"/>
. -
If the Custom Properties string is empty or null, you must initialize the string by entering the proper syntax for both the schema and the
MaximumConcurrentProvisioningOperations
property.
-
-
In the PowerShell window, paste the modified Custom Properties from Notepad and assign a variable to the modified Custom Properties. If you initialized the Custom Properties, add the following lines after the syntax:
$customProperties = '<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Property xsi:type="IntProperty" Name="MaximumConcurrentProvisioningOperations" Value="100"/></CustomProperties>'
.This string sets the
MaximumConcurrentProvisioningOperations
property to 100. In the Custom Properties string, you must set theMaximumConcurrentProvisioningOperations
property to a value that aligns with your needs. - Enter
Get-XDAuthentication
, which prompts you for your credentials. - Run
$cred = Get-Credential
, which might prompt you for solely a Password (or a Name and Password). You might also be prompted for the application ID and associated secret. For connections using role-based authentication, role_based_auth is both the Name and Password. Otherwise, enter the AWS API ID and secret. - Run
set-item -PSPath 'XDHyp:\Connections<connection-name>' -CustomProperties $customProperties -username $cred.username -Securepassword $cred.password
. You must set the <connection-name> to the name of the connection. - Enter
dir
to verify the updated CustomProperties string.
Configure security groups per network interface
When editing a host connection, you can now configure the maximum number of security groups allowed per elastic network interface (ENI) using a PowerShell command. For information on AWS security groups quota values, see Security groups.
To configure security groups per network interface:
- Open a PowerShell window.
- Run
asnp citrix*
to load the Citrix-specific PowerShell modules. - Run
cd xdhyp:\Connections\
. - Run
dir
to list the connections. -
Run the following PowerShell command to configure security groups per network interface:
Set-HypHypervisorConnectionMetadata -HypervisorConnectionName aws -Name "Citrix_MachineManagement_Options" -Value " AwsMaxENISecurityGroupLimit=<number>" <!--NeedCopy-->
Note:
If you do not set a value for
AwsMaxENISecurityGroupLimit
, then it takes the default value of 5.
Cross-account provisioning
There are use-cases where the Cloud Connectors would like to be placed in a separate AWS account (shared services account or site components account) with IAM roles that have cross-account access (cross-account IAM role) and MCS-provisioned machine catalogs in separate secondary AWS account (workloads accounts), without the need for additional Cloud Connectors in the separate accounts. To support such scenarios, this feature uses VPC peering and cross-account access using IAM roles to make provisioning across different AWS accounts possible for enterprises managing multiple AWS accounts.
With VPC peering, you can have your Cloud Connector, and provisioned VMs in different regions or accounts be able to communicate among each other.
With cross-account access using IAM roles, you allow the primary account (Cloud Connector account) to assume an IAM role to access AWS resources in the secondary account (machine catalog VMs).
To allow Cloud Connector to access the resources of the secondary account, create a host connection after assuming the IAM role from the secondary account.
To allow Cloud Connectors to access the resources of the secondary account, create a host connection after assuming the IAM role from the secondary account.
Prerequisites
Set up the following before creating a host connection for cross-account provisioning:
- Set up VPC peering and configure the security groups in both regions or accounts. See Set up VPC peering.
- Delegate cross-account access using IAM roles. See Delegate cross-account access using IAM role.
Set up VPC peering
Let’s assume that VPC A is in the primary account (Account A) and it has the Cloud Connectors and Active Directory. VPC B is in the secondary account (Account B) where you want to provision the VMs.
To set up a VPC peering connection between Account A and Account B, do the following:
-
Create a VPC peering connection. See:
- Go to your VPC A and to the route table that is associated with the public subnet.
- Click Edit Routes > Add route. Add VPC B’s CIDR block in the Destination column and add the VPC peering you created in the Target column.
- Repeat Steps 2 and 3, but with the private subnets for VPC A and VPC B (add VPC A’s CIDR block). See Update your route tables for a VPC peering connection.
- Go to the private security group associated with VPC A.
- Select Actions, then Edit inbound rules.
-
Select Add rule. For type, select All Traffic, then in the Source Column add:
- If it is a different region, add VPC B’s CIDR Block.
- If it is a different account but the same region, add the account ID and private security group ID of VPC B separated by a forward slash (Example, 123456789012/sg-1a2b3c4d)
- Repeat Steps 5 through 7, but with the private security group for VPC B (but add VPC A’s CIDR Block or VPC A’s account ID and private security group ID of the same region, but different account). See Update your security groups to reference peer security groups.
Note:
There is no charge to create a VPC peering connection. However, while VPC peering within an Availability Zone is free, charges apply when data transfer over a VPC peering connection occurs across multiple Availability Zones and regions. See Pricing for a VPC peering connection.
Delegate cross-account access using IAM roles
After setting up VPC peering across accounts, you delegate cross-account access using IAM roles.
With cross-account access using IAM roles, you allow the primary account (Cloud Connector account) to assume an IAM role to access AWS resources in the secondary account (machine catalog VMs).
To access cross-account resources, do the following:
Remember:
Assumed, VPC A is in the primary account (Account A) and it has the Cloud Connector and Active Directory. VPC B is in the secondary account (Account B) where you want to provision the VMs
- Set up VPC peering across accounts with the steps mentioned before.
- Create an IAM role and policy in Account B with minimal Citrix IAM Permissions. See IAM tutorial: Delegate access across AWS accounts using IAM roles. Let’s say the arn of this role is “arn:aws:iam::5678:role/citrix-role”.
- Add the Trust policy to the role “arn:aws:iam::5678:role/citrix-role” so that it’s allowed to be accessed by Account A role “arn:aws:iam::1234:role/primary-account-citrix-role” as per - Cross account resource access in IAM.
- Create the IAM role and policy in Account A with the name mentioned before “primary-account-citrix role”, which can assume the IAM role and pass the IAM role from the Account B (arn:aws:iam::5678:role/citrix-role).
- Assign the role “arn:aws:iam::1234:role/primary-account-citrix-role” to all the Cloud Connectors in Account A.
Cloud Connectors can now assume the role from Account B (“arn:aws:iam::5678:role/citrix-role”).
Create host connection for cross-account provisioning
Create a host connection in the secondary account (Account B) where you want to provision the VMs. This allows Cloud Connectors of Account A to access the resources in Account B after assuming the role from Account B.
Use PowerShell commands to create the host connection and add the following two custom properties:
-
CrossAccountRoleArn
: If you don’t provideCrossAccountRoleArn
property, then the regular Host Connection is created. In this case,MaximumAssumeRoleDurationInSeconds
is ignored even if it is provided. -
MaximumAssumeRoleDurationInSeconds
:DurationInSeconds
must be between 900 seconds to 3600 seconds. The default is 900 seconds. If you provide a value provided more than 3600, thenDurationInSeconds
is set to 3600.
Example:
$connectionName = "cross-account-conn"
$cloudRegion = "us-east-1"
$apiKey = "role_based_auth"
$secretKey = "role_based_auth"
$zoneUid = "xxxxxx"
$secureKey = (ConvertTo-SecureString -String $secretKey -AsPlainText -Force)
$connectionPath = "XDHyp:\Connections\" + $connectionName
$customProperties = '<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="CrossAccountRoleArn" Value="arn:aws:iam::5678:role/citrix-role" /><Property xsi:type="StringProperty" Name="MaximumAssumeRoleDurationInSeconds" Value="3600" />
"</CustomProperties>'
$connection = New-Item -Path $connectionPath -ConnectionType "AWS" -HypervisorAddress "https://ec2.$($cloudRegion).amazonaws.com" -Persist -Scope @() -UserName $apiKey -SecurePassword $secureKey -ZoneUid $zoneUid -CustomProperties $customProperties
New-BrokerHypervisorConnection -HypHypervisorConnectionUid $connection.HypervisorConnectionUid
<!--NeedCopy-->
After the host connection is created, create hosting units using Studio or PowerShell. However, select VPC and Networks.
Service endpoint URL
Standard zone service endpoint URL
When you use MCS, a new AWS connection is added with an API key and an API secret. With this information, along with the authenticated account, MCS queries AWS for the supported zones using the AWS DescribeRegions EC2 API call. The query is made using a generic EC2 Service Endpoint URL https://ec2.amazonaws.com/
. Use MCS to select the zone for the connection from the list of supported zones. The preferred AWS service endpoint URL is automatically selected for the zone. However, after you create the service endpoint URL, you can no longer set or modify the URL.
Non-standard service endpoint URL
There can be situations where you might not need the automatically chosen AWS Service Endpoint URL for the connection. For such cases, you can use Citrix Cloud SDK and PowerShell to create a connection with a non-standard service endpoint URL. For example, to create a connection using the service endpoint URL https://ec2.cn-north-1.amazonaws.com.cn
:
- Set up the AWS hosted Cloud Connector and ensure that it has connectivity.
-
Run the following PowerShell commands to see the list of Cloud Connectors.
PS C:\> asnp citrix.* PS C:\> Get-XDAuthentication PS C:\> Get-ConfigEdgeServer <!--NeedCopy-->
-
Find the ZoneUid from the newly created Cloud Connector and enter it into the following PowerShell commands. Replace the italicized items with the respective values.
PS C:\> $hyp= New-Item -Path xdhyp:\Connections -ZoneUid
ZoneUid-Name
“My New Connection”-ConnectionType "AWS" -HypervisorAddress @("https://ec2.cn-north-1.amazonaws.com.cn") -UserName
“APIkey”-Password
“API Secret”-Persist
PS C:\> New-BrokerHypervisorConnection -HypHypervisorConnectionUid $hyp. HypervisorConnectionUid
- Refresh the Hosting tab to verify that the EC2 connection has been created.
- Add a resource location using the new connection.
Define IAM permissions
Use the information in this section to define IAM permissions for Citrix DaaS on AWS. Amazon’s IAM service permits accounts having multiple users, which can be further organized into groups. These users can possess different permissions to control their ability to perform operations associated with the account. For more information about IAM permissions, see the IAM JSON policy reference.
To apply IAM permissions policy to a new group of users:
- Log in to the AWS management console and select the IAM service from the drop-down list.
- Select Create a New Group of Users.
- Type a name for the new user group and select Continue.
- On the Permissions page, choose Custom Policy then Select.
- Type a name for the Permissions policy.
- In the Policy Document section, enter the relevant permissions.
After entering the policy information, select Continue to complete the application of the IAM permissions policy to the group of users. Users in the group are granted permissions to do only those actions that are required for Citrix DaaS.
Important:
Use the policy text provided in the example provided in this article to list the actions that a Citrix DaaS uses to perform actions within an AWS account without restricting those actions to specific resources. Citrix recommends that you use the example for testing purposes. For production environments, you might choose to add further restrictions on resources.
Add IAM permissions
Add the permissions in the IAM section of the AWS Management Console:
- In the Summary panel, select the Permissions tab.
- Select Add permissions.
In the Add Permissions to screen, grant permissions:
Use the following as an example in the JSON tab:
Tip:
The noted JSON example might not include all the permissions for your environment. See About AWS permissions for more information.
Required AWS permissions
This section contains the complete list of AWS permissions. Use the complete set of permissions as given in the section for the functionality to work correctly.
Note:
The
iam:PassRole
permission is needed only for role_based_auth.
Creating a host connection
A new host connection is added using the information obtained from AWS.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeRegions"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
<!--NeedCopy-->
Power management of VMs
VMs are powered on or off.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstances",,
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
<!--NeedCopy-->
Creating, updating, or deleting VMs
A machine catalog is created, updated, or deleted with VMs provisioned as AWS instances.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:AttachVolume",
"ec2:AssociateIamInstanceProfile",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateImage",
"ec2:CreateLaunchTemplate",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteVolume",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeIamInstanceProfileAssociations",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeLaunchTemplateVersions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeRegions",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSnapshots",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeSpotInstanceRequests",
"ec2:DescribeInstanceCreditSpecifications",
"ec2:DescribeInstanceAttribute",
"ec2:GetLaunchTemplateData",
"ec2:DescribeVolumes",
"ec2:DescribeVpcs",
"ec2:DetachVolume",
"ec2:DisassociateIamInstanceProfile",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ec2:CreateSecurityGroup",
"ec2:DeleteSecurityGroup"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ebs:StartSnapshot",
"ebs:GetSnapshotBlock",
"ebs:PutSnapshotBlock",
"ebs:CompleteSnapshot",
"ebs:ListSnapshotBlocks",
"ebs:ListChangedBlocks",
"ec2:CreateSnapshot"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
<!--NeedCopy-->
Note:
- The EC2 section related to SecurityGroups is only needed if an Isolation Security Group must be created for the Preparation VM during catalog creation. Once this is done, these permissions are not required.
Importing VMs
A machine catalog is created by importing VMs.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:DescribeSpotInstanceRequests"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
<!--NeedCopy-->
Note:
The
ec2:DescribeSpotInstanceRequests
is needed only if there is a spot instance in the AWS region from where VMs are going to be imported.
Direct disk upload and download
Direct disk upload eliminates the volume worker requirement for machine catalog provisioning, and instead uses public APIs provided by AWS. This functionality reduces the cost associated with extra storage accounts and the complexity for maintaining volume worker operations.
Note:
The support for volume worker is removed. The direct disk upload and download permissions are required for machine catalog provisioning.
The following permissions must be added to the policy:
ebs:StartSnapshot
ebs:GetSnapshotBlock
ebs:PutSnapshotBlock
ebs:CompleteSnapshot
ebs:ListSnapshotBlocks
ebs:ListChangedBlocks
ec2:CreateSnapshot
ec2:DeleteSnapshot
ec2:DescribeLaunchTemplates
Important:
- You can add a new VM to existing machine catalogs without any volume worker resources such as volume worker AMI, and volume worker VM.
- If you delete an existing catalog that used any volume worker before, all artifacts that are volume worker related are deleted.
EBS encryption of created volumes
EBS can auto-encrypt newly created volumes if the AMI is encrypted, or EBS is configured to encrypt all new volumes. However, to implement the functionality, the following permissions must be included in the IAM policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:GenerateDataKey",
"kms:ReEncryptTo",
"kms:ReEncryptFrom"
],
"Resource": "*"
}
]
}
<!--NeedCopy-->
Note:
The permissions can be limited to specific keys by including a Resource and Condition block at the discretion of the user. For example, KMS Permissions with Condition:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:GenerateDataKey",
"kms:ReEncryptTo",
"kms:ReEncryptFrom"
],
"Resource": [
"arn:aws:kms:us-east-2:123456789012:key/abcd1234-a123-456d-a12b-a123b4cd56ef"
],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
]
}
<!--NeedCopy-->
The following key policy statement is the entire default key policy for KMS keys that is required to allow the account to use IAM policies to delegate permission for all actions (kms:*) on the KMS key.
{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:",
"Resource": ""
}
<!--NeedCopy-->
For more information, see the AWS Key Management Service official documentation.
IAM role-based authentication
The following permissions are added to support role-based authentication.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/*"
}
]
}
<!--NeedCopy-->
Minimal IAM permissions policy
The following JSON can be used for all currently supported features. You can create host connections, create, update, or delete VMs, and do power management using this policy. The policy can be applied to the users as explained in Defining IAM permissions sections or you can also use role-based authentication using role_based_auth security key and secret key.
Important:
To use role_based_auth, first configure the desired IAM role on the cloud connector ec2 instance when setting up the cloud connector. Using Citrix Studio, add the hosting connection and supply the role_based_auth for the authentication key and secret. A hosting connection with these settings then uses role-based authentication.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:AttachVolume",
"ec2:AssociateIamInstanceProfile",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateImage",
"ec2:CreateLaunchTemplate",
"ec2:CreateNetworkInterface",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteLaunchTemplate",
"ec2:DeleteNetworkInterface",
"ec2:DeleteSecurityGroup",
"ec2:DeleteSnapshot",
"ec2:DeleteTags",
"ec2:DeleteVolume",
"ec2:DeregisterImage",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeIamInstanceProfileAssociations",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeLaunchTemplateVersions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeRegions",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSnapshots",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeSpotInstanceRequests",
"ec2:DescribeInstanceCreditSpecifications",
"ec2:DescribeInstanceAttribute",
"ec2:GetLaunchTemplateData",
"ec2:DescribeVolumes",
"ec2:DescribeVpcs",
"ec2:DetachVolume",
"ec2:DisassociateIamInstanceProfile",
"ec2:RebootInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ec2:CreateSecurityGroup",
"ec2:DeleteSecurityGroup"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ebs:StartSnapshot",
"ebs:GetSnapshotBlock",
"ebs:PutSnapshotBlock",
"ebs:CompleteSnapshot",
"ebs:ListSnapshotBlocks",
"ebs:ListChangedBlocks",
"ec2:CreateSnapshot"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:GenerateDataKey",
"kms:ReEncryptTo",
"kms:ReEncryptFrom"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/*"
}
]
}
<!--NeedCopy-->
Note:
- The EC2 section related to SecurityGroups is only needed if an Isolation Security Group must be created for the Preparation VM during catalog creation. Once this is done, these permissions are not required.
- The KMS section is only required when using EBS volume encryption.
- The
iam:PassRole
permission section is needed only for role_based_auth.- Specific resource-level permissions can be added instead of full access based on your requirements and environment. Refer to AWS documents Demystifying EC2 Resource-Level Permissions and Access management for AWS resources for more details.
- Use
ec2:CreateNetworkInterface
andec2:DeleteNetworkInterface
permissions only if you are using the volume worker method.
Validate permissions on host connection
You can validate permissions on a host connection to do tasks related to creating and managing MCS machine catalogs. This implementation helps you to find out the missing permissions required for different scenarios such as creating, deleting, and updating VMs, power management of VMs, and EBS encryption, ahead of time so that you can avoid being blocked at critical times.
You can validate the permissions on a host connection using the PowerShell command Test-HypHypervisorConnection
. The result from the command is captured as a list where each item in the list is broken into three sections.
- Category: The action or task a user can do to create and manage an MCS machine catalog.
- Corrective Action: The step an admin must do to resolve a users’ missing permissions discrepancy.
- Missing permission: The list of missing permissions for a category.
To validate the permissions, do the following:
- Create a host connection to AWS.
- Open a PowerShell window from the Delivery Controller host.
- Run
asnp citrix*
to load the Citrix-specific PowerShell modules. -
Run the following command to verify if you have the required permissions to look up your permissions.
Test-HypHypervisorConnection -LiteralPath "XDHyp:\Connections\AWSCon" <!--NeedCopy-->
-
After you add the missing permissions required to look up your permissions, run the following command to verify if you have permissions in the following categories:
- Create Update delete
- Power Management
- EBS encryption
Test-HypHypervisorConnection -LiteralPath "XDHyp:\Connections\AWSCon" [-SecurePassword -Password] "password" -UserName "" -CustomProperties "" <!--NeedCopy-->
For more information on adding permissions, see Add IAM permissions.
Where to go next
- If you’re in the initial deployment process, see Create machine catalogs.
- For AWS specific information, see Create an AWS catalog.