AWSへの接続

接続を作成するウィザードについては、接続とリソースの作成および管理で説明しています。以下の情報は、AWSクラウド環境に固有の詳細を扱っています。

注:

AWSへの接続を作成する前に、まずAWSアカウントをリソースの場所として設定を完了する必要があります。AWSクラウド環境を参照してください。

接続の作成

Web Studioから接続を作成する場合:

  • APIキーとシークレットキーの値を指定する必要があります。これらの値を含むキーファイルをAWSからエクスポートし、インポートできます。また、リージョン、アベイラビリティゾーン、VPC名、サブネットアドレス、ドメイン名、セキュリティグループ名、および資格情報も指定する必要があります。
  • ルートAWSアカウント(AWSコンソールから取得)の資格情報ファイルは、標準のAWSユーザー用にダウンロードされた資格情報ファイルと同じ形式ではありません。そのため、Citrix Virtual Apps and Desktops™管理では、このファイルを使用してAPIキーとシークレットキーのフィールドに入力することはできません。AWS Identity Access Management (IAM) の資格情報ファイルを使用していることを確認してください。

注:

接続を作成した後、APIキーとシークレットキーの更新が失敗する場合があります。この問題を解決するには、プロキシサーバーまたはファイアウォールの制限を確認し、次のアドレスにアクセスできることを確認してください:https://*.amazonaws.com

ホスト接続のデフォルト値

AWSクラウド環境でホスト接続を作成すると、次のデフォルト値が表示されます:

オプション 絶対値 パーセンテージ
同時アクション(全タイプ) 125 100
1分あたりの最大新規アクション数 125  

MCSは、デフォルトで最大100の同時プロビジョニング操作をサポートします。

クロスアカウントプロビジョニング

Delivery ControllerをプライマリAWSアカウント(共有サービスアカウントまたはサイトコンポーネントアカウント)に配置し、クロスアカウントアクセス(クロスアカウントIAMロール)を持つIAMロールを使用し、MCSでプロビジョニングされたマシンカタログを個別のセカンダリAWSアカウント(ワークロードアカウント)に配置するユースケースがあります。この場合、個別のAWSアカウントに追加のDelivery Controllerは必要ありません。このようなシナリオをサポートするために、この機能はVPCピアリングとIAMロールを使用したクロスアカウントアクセスを利用して、複数のAWSアカウントを管理する企業向けに異なるAWSアカウント間でのプロビジョニングを可能にします。

VPCピアリングを使用すると、Delivery Controllerと、異なるリージョンやアカウントにプロビジョニングされたVMが相互に通信できるようになります。

IAMロールを使用したクロスアカウントアクセスにより、プライマリアカウント(Delivery Controllerアカウント)はIAMロールを引き受けて、セカンダリアカウント(マシンカタログVM)内のAWSリソースにアクセスできるようになります。

Delivery Controllerがセカンダリアカウントのリソースにアクセスできるようにするには、セカンダリアカウントからIAMロールを引き受けた後にホスト接続を作成します。

前提条件

クロスアカウントプロビジョニング用のホスト接続を作成する前に、以下を設定します。

  • VPCピアリングを設定し、両方のリージョンまたはアカウントでセキュリティグループを構成します。(#set-up-vpc-peering)VPCピアリングの設定を参照してください。
  • IAMロールを使用してクロスアカウントアクセスを委任します。(以下のトピックへのリンク)を参照してください。

VPCピアリングを設定する

VPC Aがプライマリアカウント(アカウントA)にあり、Delivery ControllerとActive Directoryがあるとします。VPC Bはセカンダリアカウント(アカウントB)にあり、そこにVMをプロビジョニングします。

アカウントAとアカウントBの間にVPCピアリング接続を設定するには、次の手順を実行します。

  1. VPCピアリング接続を作成します。参照:

  2. VPC Aに移動し、パブリックサブネットに関連付けられているルートテーブルに移動します。
  3. Edit Routes > Add routeをクリックします。Destination列にVPC BのCIDRブロックを追加し、Target列に作成したVPCピアリングを追加します。
  4. 手順2と3を繰り返しますが、VPC AとVPC Bのプライベートサブネットを使用します(VPC AのCIDRブロックを追加します)。VPCピアリング接続のルートテーブルを更新するを参照してください。
  5. VPC Aに関連付けられているプライベートセキュリティグループに移動します。
  6. アクション」を選択し、次に「インバウンドルールを編集」を選択します。
  7. Add ruleを選択します。タイプにはAll Trafficを選択し、Source Columnに以下を追加します。

    • 異なるリージョンの場合は、VPC BのCIDRブロック。
    • 異なるアカウントだが同じリージョンの場合は、アカウントIDとVPC BのプライベートセキュリティグループIDをスラッシュで区切って追加します(例:123456789012/sg-1a2b3c4d)。
  8. 手順5から7を繰り返しますが、VPC Bのプライベートセキュリティグループを使用します(ただし、VPC AのCIDRブロック、または同じリージョンだが異なるアカウントのVPC AのアカウントIDとプライベートセキュリティグループIDを追加します)。ピアセキュリティグループを参照するようにセキュリティグループを更新するを参照してください。

注:

VPCピアリング接続の作成には料金はかかりません。ただし、アベイラビリティーゾーン内でのVPCピアリングは無料ですが、VPCピアリング接続を介したデータ転送が複数のアベイラビリティーゾーンやリージョンをまたがる場合は料金が発生します。VPCピアリング接続の料金を参照してください。

IAMロールを使用してクロスアカウントアクセスを委任する

アカウント間でVPCピアリングを設定した後、IAMロールを使用してクロスアカウントアクセスを委任します。

IAMロールを使用したクロスアカウントアクセスにより、プライマリアカウント(Delivery Controller™アカウント)がIAMロールを引き受けて、セカンダリアカウント(マシンカタログVM)内のAWSリソースにアクセスできるようになります。

クロスアカウントリソースにアクセスするには、次の手順を実行します。

注意:

VPC Aはプライマリアカウント(アカウントA)にあり、Delivery ControllerとActive Directoryを持っています。VPC Bはセカンダリアカウント(アカウントB)にあり、VMをプロビジョニングしたい場所です。

  1. 上記の手順でアカウント間のVPCピアリングを設定します。
  2. アカウントBで、最小限のCitrix IAM権限を持つIAMロールとポリシーを作成します。IAMチュートリアル:IAMロールを使用してAWSアカウント間でアクセスを委任するを参照してください。このロールのARNは「arn:aws:iam::5678:role/citrix-role」であるとします。
  3. 「arn:aws:iam::5678:role/citrix-role」ロールに信頼ポリシーを追加し、アカウントAのロール「arn:aws:iam::1234:role/primary-account-citrix-role」からアクセスできるようにします。詳細については、IAMでのクロスアカウントリソースアクセスを参照してください。
  4. アカウントAで、上記の名前「primary-account-citrix role」を持つIAMロールとポリシーを作成します。このロールは、IAMロールを引き受け、アカウントBからのIAMロール(arn:aws:iam::5678:role/citrix-role)を渡すことができます。
  5. アカウントAのすべてのデリバリーコントローラーに、「arn:aws:iam::1234:role/primary-account-citrix-role」というロールを割り当てます。

Delivery Controllerは、アカウントBからのロール(「arn:aws:iam::5678:role/citrix-role」)を引き受けることができるようになりました。

クロスアカウントプロビジョニング用のホスト接続を作成する

VMをプロビジョニングするセカンダリアカウント(アカウントB)にホスト接続を作成します。これにより、アカウントAのDelivery Controllerは、アカウントBからロールを引き受けた後、アカウントBのリソースにアクセスできるようになります。

PowerShellコマンドを使用してホスト接続を作成し、次の2つのカスタムプロパティを追加します。

  • CrossAccountRoleArn: CrossAccountRoleArnプロパティを指定しない場合、通常のホスト接続が作成されます。この場合、MaximumAssumeRoleDurationInSecondsが指定されていても無視されます。
  • MaximumAssumeRoleDurationInSeconds: DurationInSecondsは900秒から3600秒の間である必要があります。デフォルトは900秒です。3600を超える値を指定した場合、DurationInSecondsは3600に設定されます。

例:

$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-->

ホスト接続が作成されたら、StudioまたはPowerShellを使用してホスティングユニットを作成します。ただし、VPCとネットワークを選択してください。

サービスエンドポイントURL

標準ゾーンサービスエンドポイントURL

MCSを使用すると、APIキーとAPIシークレットを持つ新しいAWS接続が追加されます。この情報と認証済みアカウントを使用して、MCSはAWS DescribeRegions EC2 API呼び出しを使用して、サポートされているゾーンについてAWSにクエリを実行します。クエリは汎用EC2サービスエンドポイントURL https://ec2.amazonaws.com/を使用して行われます。MCSを使用して、サポートされているゾーンのリストから接続するゾーンを選択します。優先されるAWSサービスエンドポイントURLは、そのゾーンに対して自動的に選択されます。ただし、サービスエンドポイントURLを作成した後、そのURLを設定または変更することはできません。

IAM権限の定義

このセクションの情報を使用して、AWS上のCitrix Virtual Apps and DesktopsのIAM権限を定義します。AmazonのIAMサービスでは、複数のユーザーを持つアカウントが許可されており、それらのユーザーはさらにグループに編成できます。これらのユーザーは、アカウントに関連する操作を実行する能力を制御するために、異なる権限を持つことができます。IAM権限の詳細については、IAM JSONポリシーリファレンスを参照してください。

新しいユーザーグループにIAM権限ポリシーを適用するには:

  1. AWSマネジメントコンソールにログインし、ドロップダウンリストからIAMサービスを選択します。
  2. 新しいユーザーグループの作成を選択します。
  3. 新しいユーザーグループの名前を入力し、続行を選択します。
  4. 権限」ページで、「カスタムポリシー」を選択します。「選択」を選択します。
  5. 権限ポリシー」の名前を入力します。
  6. Policy Document」セクションで、関連する権限を入力します。

ポリシー情報を入力したら、「Continue」を選択してユーザーグループを完了します。グループ内のユーザーには、Citrix Virtual Apps and Desktops に必要なアクションのみを実行する権限が付与されます。

重要:

前述の例で提供されているポリシーテキストを使用して、Citrix Virtual Apps and Desktops が AWS アカウント内でアクションを実行するために使用するアクションを、特定のリソースに制限することなくリストします。Citrix は、テスト目的でこの例を使用することをお勧めします。本番環境では、リソースにさらなる制限を追加することを選択できます。

IAM権限を設定する

AWS 管理コンソール の IAM セクションで権限を設定します。

  1. Summary」パネルで、「Permissions」タブを選択します。
  2. Add permissions オプションを選択します。

識別情報およびアクセス管理 (IAM)

Add Permissions to」画面で、権限を付与します。

IAMポリシーの権限を付与

JSON」タブで、以下を例として使用します。

ジェイソンの例

ヒント:

記載されているJSONの例には、お使いの環境に必要なすべての権限が含まれていない場合があります。詳細については、AWSでCitrix Virtual Apps and Desktopsを実行する際のIDおよびアクセス管理権限を定義する方法を参照してください。

必要なAWS権限

このセクションには、AWS権限の完全なリストが含まれています。

注:

iam:PassRoleという権限は、role_based_authの場合にのみ必要となります。

ホスト接続の作成

AWSからの情報を使用して、新しいホスト接続が追加されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "ec2:DescribeRegions"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
<!--NeedCopy-->

VMの電源管理

VMの電源がオンまたはオフになります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:DescribeInstances",
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:RebootInstances",
                "ec2:DescribeInstanceStatus"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
<!--NeedCopy-->

VMの作成、更新、または削除

AWSインスタンスとしてプロビジョニングされたVMを使用して、マシンカタログが作成、更新、または削除されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:AttachVolume",
                "ec2:AssociateIamInstanceProfile",
                "ec2:AuthorizeSecurityGroupEgress",
                "ec2:RevokeSecurityGroupEgress",
                "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:DescribeInstanceStatus",
                "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-->

注:

セキュリティグループに関連するEC2セクションは、カタログ作成中に準備VM用に分離セキュリティグループを作成する必要がある場合にのみ必要です。これが完了すると、これらの権限は不要になります。

ディスクの直接アップロードとダウンロード

直接ディスクアップロードは、マシンカタログプロビジョニングにおけるボリュームワーカーの要件を排除し、代わりにAWSが提供するパブリックAPIを使用します。この機能により、追加のストレージアカウントに関連するコストと、ボリュームワーカー操作を維持するための複雑さが軽減されます。

注:

ボリュームワーカーのサポートは削除されました。マシンカタログのプロビジョニングには、直接ディスクのアップロードおよびダウンロードの権限が必要です。

以下の権限をポリシーに追加する必要があります。

  • ebs:StartSnapshot
  • ebs:GetSnapshotBlock
  • ebs:PutSnapshotBlock
  • ebs:CompleteSnapshot
  • ebs:ListSnapshotBlocks
  • ebs:ListChangedBlocks
  • ec2:CreateSnapshot
  • ec2:DeleteSnapshot
  • ec2:DescribeLaunchTemplates

重要:

  • ボリュームワーカーAMIやボリュームワーカーVMなどのボリュームワーカー操作なしで、既存のマシンカタログにVMを追加できます。
  • 以前にボリュームワーカーを使用していた既存のカタログを削除すると、ボリュームワーカー関連を含むすべてのアーティファクトが削除されます。

作成されたボリュームのEBS暗号化

AMIが暗号化されている場合、またはEBSがすべての新しいボリュームを暗号化するように構成されている場合、EBSは新しく作成されたボリュームを自動的に暗号化できます。ただし、この機能を実装するには、IAMポリシーに以下の権限を含める必要があります。

{
     "Version": "2012-10-17",
     "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                 "kms:CreateGrant",
                 "kms:Decrypt",
                 "kms:DescribeKey",
                 "kms:GenerateDataKeyWithoutPlainText",
                 "kms:GenerateDataKey",
                 "kms:ReEncryptTo",
                 "kms:ReEncryptFrom"
            ],
            "Resource": "*"
        }
    ]
}
<!--NeedCopy-->

注:

ユーザーの裁量により、リソースと条件ブロックを含めることで、権限を特定のキーに限定できます。例:条件付きKMS権限

{
     "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-->

以下のキーポリシーステートメントは、KMSキーに対するすべてのアクション (kms:*) の権限をIAMポリシーを使用して委任することをアカウントに許可するために必要な、KMSキーのデフォルトキーポリシー全体です。

{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:",
"Resource": ""
}
<!--NeedCopy-->

詳細については、AWS Key Management Serviceの公式ドキュメントを参照してください。

IAMロールベース認証

ロールベース認証をサポートするために、以下の権限が追加されます。

{
     "Version": "2012-10-17",
     "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::*:role/*"
        }
    ]
}
<!--NeedCopy-->

最小限のIAM権限ポリシー

以下のJSONは、現在サポートされているすべての機能に使用できます。このポリシーを使用して、ホスト接続の作成、VMの作成、更新、削除、および電源管理を行うことができます。 このポリシーは、IAM権限の定義セクションで説明されているようにユーザーに適用することも、role_based_authセキュリティキーとシークレットキーを使用してロールベース認証を使用することもできます。

重要:

role_based_authを使用するには、まずサイト内のすべてのDelivery Controllerで目的のIAMロールを構成します。Web Studioを使用してホスティング接続を追加し、認証キーとシークレットにrole_based_authを指定します。これらの設定を持つホスティング接続は、ロールベース認証を使用します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:AttachVolume",
                "ec2:AssociateIamInstanceProfile",
                "ec2:AuthorizeSecurityGroupEgress",
                "ec2:RevokeSecurityGroupEgress",
                "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:DescribeInstanceStatus",
                "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-->

注:

  • SecurityGroupsに関連するEC2セクションは、カタログ作成時に準備VM用に分離セキュリティグループを作成する必要がある場合にのみ必要です。これが完了すると、これらの権限は不要になります。
  • KMSセクションは、EBSボリューム暗号化を使用する場合にのみ必要です。
  • iam:PassRole権限セクションは、role_based_authの場合にのみ必要です。
  • 要件と環境に基づいて、フルアクセスではなく特定のリソースレベルの権限を追加できます。詳細については、AWSドキュメントのDemystifying EC2 Resource-Level PermissionsAccess management for AWS resourcesを参照してください。

ホスト接続での権限の検証

ホスト接続で権限を検証し、MCSマシンカタログの作成と管理に関連するタスクを実行できます。この実装により、VMの作成、削除、更新、VMの電源管理、EBS暗号化など、さまざまなシナリオで必要な不足している権限を事前に特定できるため、重要な時期にブロックされるのを回避できます。

PowerShellコマンドTest-HypHypervisorConnectionを使用して、ホスト接続の権限を検証できます。このコマンドの結果はリストとして取得され、リスト内の各項目は3つのセクションに分かれています。

  • カテゴリ: ユーザーがMCSマシンカタログを作成および管理するために実行できるアクションまたはタスク。
  • 修正措置: 管理者がユーザーの不足している権限の不一致を解決するために実行する必要がある手順。
  • 不足している権限: カテゴリの不足している権限のリスト。

権限を検証するには、次の手順を実行します。

  1. AWSへのホスト接続を作成します。
  2. デリバリーコントローラー ホストから PowerShell ウィンドウを開きます。
  3. Citrix固有のPowerShellモジュールをロードするためにasnp citrix*を実行します。
  4. 自分の権限を検索するために必要な権限があるかどうかを確認するには、次のコマンドを実行します。

    Test-HypHypervisorConnection -LiteralPath "XDHyp:\Connections\AWSCon"
    <!--NeedCopy-->
    
  5. 自分の権限を検索するために必要な不足している権限を追加した後、次のカテゴリの権限があるかどうかを確認するには、次のコマンドを実行します。

    • 作成、更新、削除
    • 電源管理
    • EBS暗号化
    Test-HypHypervisorConnection -LiteralPath "XDHyp:\Connections\AWSCon" [-SecurePassword -Password] "password" -UserName "" -CustomProperties ""
    <!--NeedCopy-->
    

権限の追加について詳しくは、「IAM権限の設定」を参照してください。

次のステップ

詳細情報

AWSへの接続