翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # RunBooks の問題 次のセクションには、発生する可能性のある問題、検出方法、問題の解決方法に関する提案が含まれています。 + [インストールの問題](#installation-issues) + [CloudFormationスタックはWaitCondition received failed message」というメッセージで を作成できません。Error:States.TaskFailed"](#cf-stack-fails) + [CloudFormationスタックが正常に作成された後に E メール通知が受信されない](#email-invitation-not-received) + [インスタンスのサイクルまたは vdc-controller が失敗状態](#instances-cycling) + [環境 CloudFormation スタックが依存オブジェクトエラーにより削除に失敗する](#object-error) + [環境の作成中に CIDR ブロックパラメータでエラーが発生しました](#cidr-block-error) + [環境作成中の CloudFormation スタック作成の失敗](#cf-stack-creation-fails) + [AdDomainAdminNode CREATE\_FAILED で外部リソース (デモ) スタックの作成が失敗する](#demo-environment-stack-fails) + [ID 管理の問題](#troubleshooting-identity-management) + [iam:PassRole を実行する権限がありません](#res-troubleshooting-issue-runbooks-unauth-passrole) + [自分の AWSアカウント以外のユーザーにAWSリソースの Research and Engineering Studio へのアクセスを許可したい](#res-troubleshooting-issue-runbooks-outside-acct) + [環境にログインすると、すぐにログインページに戻ります。](#return-to-login) + [ログイン試行時の「ユーザーが見つかりません」エラー](#user-not-found) + [Active Directory に追加されたが、RES にないユーザー](#user-missing) + [セッションの作成時に使用できないユーザー](#session-user-unavailable) + [CloudWatch クラスターマネージャーログのサイズ制限超過エラー](#sizelimit-exceeded-error) + [Storage](#res-troubleshooting-storage) + [RES を使用してファイルシステムを作成しましたが、VDI ホストにマウントされません](#res-troubleshooting-storage-created) + [RES を介してファイルシステムをオンボードしたが、VDI ホストにマウントされない](#res-troubleshooting-storage-onboarded) + [VDI ホストから読み書きできない](#res-troubleshooting-storage-rw) + [アクセス許可処理のユースケースの例](#res-troubleshooting-storage-rw-example) + [RES から Amazon FSx for NetApp ONTAP を作成しましたが、ドメインに参加していません](#res-troubleshooting-storage-join) + [スナップショット](#res-troubleshooting-snapshots) + [スナップショットのステータスが Failed である](#res-troubleshooting-snapshots-failed) + [スナップショットは、テーブルをインポートできなかったことを示すログとともに適用されません。](#res-troubleshooting-snapshots-not-imported) + [インフラストラクチャ](#res-troubleshooting-infrastructure) + [正常なインスタンスがないロードバランサーターゲットグループ](#res-troubleshooting-infrastructure-load-balancer) + [仮想デスクトップの起動](#res-troubleshooting-virtual-desktops) + [Windows Virtual Desktop のログインアカウントが管理者に設定されています](#res-troubleshooting-virtual-desktops-windows-admin) + [外部リソース CertificateRenewalNode を使用する場合、証明書の有効期限が切れます](#res-troubleshooting-virtual-desktops-certificate-expires) + [以前に機能していた仮想デスクトップが正常に接続できなくなった](#res-troubleshooting-virtual-desktops-was-working) + [5 つの仮想デスクトップしか起動できない](#res-troubleshooting-virtual-desktops-only-five) + [デスクトップ Windows の接続試行は「接続が閉じられました。トランスポートエラー"](#res-troubleshooting-virtual-desktops-transport-error) + [VDIsプロビジョニング状態でスタックする](#res-troubleshooting-virtual-desktops-stuck-prov) + [起動後に VDIsがエラー状態になる](#res-troubleshooting-virtual-desktops-error-after) + [ログインすると、VDI セッションが空白の画面になります](#res-troubleshooting-virtual-desktops-vdi-blank-screen) + [仮想デスクトップコンポーネント](#res-troubleshooting-vd-component) + [Amazon EC2 インスタンスがコンソールで終了を繰り返し表示](#res-troubleshooting-vd-component-ec2-terminated) + [AD への参加に失敗したために vdc-controller インスタンスがサイクルしています / eVDI モジュールが失敗した API ヘルスチェックを表示](#res-troubleshooting-vd-component-cycling) + [プロジェクトは、ソフトウェアスタックを編集して追加するときにプルダウンに表示されません](#res-troubleshooting-vd-component-not-in-pulldown) + [cluster-manager Amazon CloudWatch ログには、「 アカウントはまだ利用できません。ユーザーの同期を待っています」と表示されます (アカウントはユーザー名です）。](#res-troubleshooting-vd-component-acct-unavailable) + [ログイン試行時の Windows デスクトップに「アカウントが無効になっています。管理者にお問い合わせください」](#res-troubleshooting-vd-component-acct-disabled) + [外部/顧客の AD 設定に関する DHCP オプションの問題](#res-troubleshooting-vd-component-dhcp) + [Firefox エラー MOZILLA\_PKIX\_ERROR\_REQUIRED\_TLS\_FEATURE\_MISSING](#res-troubleshooting-vd-firefox) + [Env 削除](#res-troubleshooting-env-deletion) + [res-xxx-cluster スタックが「DELETE\_FAILED」状態で、「Role is invalid or cannot be assumed」エラーのため手動で削除できない](#res-troubleshooting-env-deletion-role-invalid) + [ログの収集](#res-troubleshooting-env-deletion-collect-logs) + [VDI ログのダウンロード](#res-troubleshooting-env-deletion-download-logs) + [Linux EC2 インスタンスからのログのダウンロード](#res-troubleshooting-env-deletion-linux-ec2-logs) + [Windows EC2 インスタンスからのログのダウンロード](#res-troubleshooting-env-deletion-windows-ec2-logs) + [WaitCondition エラーの ECS ログの収集](#res-troubleshooting-env-deletion-waitcondition) + [ネットワークインターフェイスの削除に失敗しました](#res-troubleshooting-env-deletion-eni-failure) + [デモ環境](#res-troubleshooting-demo-env) + [ID プロバイダーへの認証リクエストを処理する際のデモ環境ログインエラー](#demo-environment-login-error) + [デモスタックのキークロークが機能しない](#demo-environment-stack-keycloak) + [Active Directory の問題](#active-directory-issues) + [VDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない](#active-directory-issues-vdi-stuck) + [SSO の設定後に RES ウェブポータルにログインできない](#active-directory-issues-res-web-portal) + [AD ユーザーは、Linux VDIs を正常に起動した後でも、ファイルブラウザを使用してホームディレクトリにアクセスできません](#active-directory-issues-home-directory-access) + [SSH アクセスが有効になっていると、AD 管理者ユーザーは踏み台ホストにアクセスできません](#active-directory-issues-bastion-host-access) + [RES 外部リソーススタックによってデプロイされた Active Directory の表示と管理](#active-directory-issues-external-resource-stack) ## インストールの問題 **Topics** + [CloudFormationスタックはWaitCondition received failed message」というメッセージで を作成できません。Error:States.TaskFailed"](#cf-stack-fails) + [CloudFormationスタックが正常に作成された後に E メール通知が受信されない](#email-invitation-not-received) + [インスタンスのサイクルまたは vdc-controller が失敗状態](#instances-cycling) + [環境 CloudFormation スタックが依存オブジェクトエラーにより削除に失敗する](#object-error) + [環境の作成中に CIDR ブロックパラメータでエラーが発生しました](#cidr-block-error) + [環境作成中の CloudFormation スタック作成の失敗](#cf-stack-creation-fails) + [AdDomainAdminNode CREATE\_FAILED で外部リソース (デモ) スタックの作成が失敗する](#demo-environment-stack-fails) ........................ ### CloudFormationスタックはWaitCondition received failed message」というメッセージで を作成できません。Error:States.TaskFailed" 問題を特定するには、 という名前の Amazon CloudWatch ロググループを調べます`-InstallerTasksCreateTaskDefCreateContainerLogGroup-`。同じ名前のロググループが複数ある場合は、最初に使用できるロググループを調べます。ログ内のエラーメッセージには、問題に関する詳細情報が表示されます。 **注記** パラメータ値にスペースがないことを確認します。 ........................ ### CloudFormationスタックが正常に作成された後に E メール通知が受信されない CloudFormationスタックが正常に作成された後に E メールの招待を受信しなかった場合は、以下を確認します。 1. E メールアドレスパラメータが正しく入力されたことを確認します。 E メールアドレスが正しくないか、アクセスできない場合は、Research and Engineering Studio 環境を削除して再デプロイします。 1. インスタンスのサイクルの証拠については、Amazon EC2 コンソールを確認してください。 `` プレフィックス が付いた Amazon EC2 インスタンスが終了済みとして表示され、新しいインスタンスに置き換えられる場合、ネットワークまたは Active Directory の設定に問題がある可能性があります。 1. AWSHigh Performance Compute レシピをデプロイして外部リソースを作成した場合は、VPC、プライベートサブネットとパブリックサブネット、およびその他の選択したパラメータがスタックによって作成されたことを確認します。 パラメータのいずれかが正しくない場合は、RES 環境を削除して再デプロイする必要がある場合があります。詳細については、「[製品のアンインストール](uninstall-the-product.md)」を参照してください。 1. 独自の外部リソースを使用して製品をデプロイした場合は、ネットワークと Active Directory が予想される設定と一致していることを確認します。 インフラストラクチャインスタンスが Active Directory に正常に参加したことを確認することが重要です。のステップを試[インスタンスのサイクルまたは vdc-controller が失敗状態](#instances-cycling)して問題を解決します。 ........................ ### インスタンスのサイクルまたは vdc-controller が失敗状態 この問題の最も可能性の高い原因は、リソース (複数可) が Active Directory に接続または参加できないことです。 **問題を検証するには:** 1. コマンドラインから、vdc-controller の実行中のインスタンスで SSM とのセッションを開始します。 1. `sudo su -` を実行します。 1. `systemctl status sssd` を実行します。 ステータスが非アクティブ、失敗、またはログにエラーが表示される場合、インスタンスは Active Directory に参加できませんでした。 ![SSM エラーログ](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/instancecyclingssmerrors.png) **問題を解決するには:** + 同じコマンドラインインスタンスから、 `cat /root/bootstrap/logs/userdata.log` を実行してログを調査します。 この問題には、3 つの根本原因のいずれかが考えられます。 #### 根本原因 1: 入力された ldap 接続の詳細が正しくない ログを見直します。以下が複数回繰り返される場合、インスタンスは Active Directory に参加できませんでした。 ``` + local AD_AUTHORIZATION_ENTRY= + [[ -z '' ]] + [[ 0 -le 180 ]] + local SLEEP_TIME=34 + log_info '(0 of 180) waiting for AD authorization, retrying in 34 seconds ...' ++ date '+%Y-%m-%d %H:%M:%S,%3N' + echo '[2024-01-16 22:02:19,802] [INFO] (0 of 180) waiting for AD authorization, retrying in 34 seconds ...' [2024-01-16 22:02:19,802] [INFO] (0 of 180) waiting for AD authorization, retrying in 34 seconds ... + sleep 34 + (( ATTEMPT_COUNT++ )) ``` 1. RES スタックの作成中に以下のパラメータ値が正しく入力されたことを確認します。 + directoryservice.ldap\_connection\_uri + directoryservice.ldap\_base + directoryservice.users.ou + directoryservice.groups.ou + directoryservice.sudoers.ou + directoryservice.computers.ou + directoryservice.name 1. DynamoDB テーブルの誤った値を更新します。テーブルは、**テーブル**の下の DynamoDB コンソールにあります。テーブル名は である必要があります`{{}}.cluster-settings`。 1. テーブルを更新したら、現在環境インスタンスを実行している cluster-manager と vdc-controller を削除します。Auto Scaling は、DynamoDB テーブルの最新の値を使用して新しいインスタンスを開始します。 #### 根本原因 2: ServiceAccount ユーザー名が正しく入力されていない ログが を返す場合`Insufficient permissions to modify computer account`、スタックの作成時に入力した ServiceAccount 名が正しくない可能性があります。 1. AWSコンソールから Secrets Manager を開きます。 1. `directoryserviceServiceAccountUsername` を検索します。シークレットは である必要があります`{{}}-directoryservice-ServiceAccountUsername`。 1. シークレットを開いて詳細ページを表示します。**シークレット値** で、**シークレット値の取得** を選択し、**プレーンテキスト **を選択します。 1. 値が更新された場合は、環境の現在実行中の cluster-manager インスタンスと vdc-controller インスタンスを削除します。自動スケーリングは、Secrets Manager の最新値を使用して新しいインスタンスを起動します。 #### 根本原因 3: ServiceAccount パスワードが正しく入力されていない ログに と表示される場合`Invalid credentials`、スタックの作成時に入力した ServiceAccount パスワードが正しくない可能性があります。 1. AWSコンソールから Secrets Manager を開きます。 1. `directoryserviceServiceAccountPassword` を検索します。シークレットは である必要があります`{{}}-directoryservice-ServiceAccountPassword`。 1. シークレットを開いて詳細ページを表示します。**シークレット値** で、**シークレット値の取得** を選択し、**プレーンテキスト **を選択します。 1. パスワードを忘れた場合、または入力したパスワードが正しいかどうかわからない場合は、Active Directory と Secrets Manager でパスワードをリセットできます。 1. でパスワードをリセットするにはAWS Managed Microsoft AD: 1. AWSコンソールを開き、 に移動しますDirectory Service。 1. RES **ディレクトリのディレクトリ ID** を選択し、**アクション**を選択します。 1. **ユーザーパスワードのリセット**を選択します。 1. ServiceAccount ユーザー名を入力します。 1. 新しいパスワードを入力し、**パスワードのリセット**を選択します。 1. Secrets Manager でパスワードをリセットするには: 1. AWSコンソールを開き、Secrets Manager に移動します。 1. `directoryserviceServiceAccountPassword` を検索します。シークレットは である必要があります`{{}}-directoryservice-ServiceAccountPassword`。 1. シークレットを開いて詳細ページを表示します。**シークレット値** で、**シークレット値の取得** を選択し、**プレーンテキスト **を選択します。 1. **[編集]** を選択します。 1. ServiceAccount ユーザーの新しいパスワードを設定し、**保存**を選択します。 1. 値を更新した場合は、環境の現在実行中の cluster-manager インスタンスと vdc-controller インスタンスを削除します。Auto Scaling は、最新の値を使用して新しいインスタンスを開始します。 ........................ ### 環境 CloudFormation スタックが依存オブジェクトエラーにより削除に失敗する などの依存オブジェクトエラーが原因で `{{}}-vdc` CloudFormation スタックの削除が失敗した場合`vdcdcvhostsecuritygroup`、コンソールを使用してAWS RES が作成したサブネットまたはセキュリティグループに起動された Amazon EC2 インスタンスが原因である可能性があります。 この問題を解決するには、この方法で起動されたすべての Amazon EC2 インスタンスを検索して終了します。その後、環境の削除を再開できます。 ........................ ### 環境の作成中に CIDR ブロックパラメータでエラーが発生しました 環境を作成すると、レスポンスステータスが [FAILED] の CIDR ブロックパラメータにエラーが表示されます。 エラーの例: ``` Failed to update cluster prefix list: An error occurred (InvalidParameterValue) when calling the ModifyManagedPrefixList operation: The specified CIDR (52.94.133.132/24) is not valid. For example, specify a CIDR in the following form: 10.0.0.0/16. ``` この問題を解決するために想定される形式は x.x.x.0/24 または x.x.x.0/32 です。 ........................ ### 環境作成中の CloudFormation スタック作成の失敗 環境の作成には、一連のリソース作成オペレーションが含まれます。一部のリージョンでは、容量の問題が発生し、CloudFormation スタックの作成が失敗する可能性があります。 この場合、環境を削除し、作成を再試行します。または、別のリージョンで作成を再試行することもできます。 ........................ ### AdDomainAdminNode CREATE\_FAILED で外部リソース (デモ) スタックの作成が失敗する デモ環境スタックの作成が次のエラーで失敗した場合、インスタンスの起動後のプロビジョニング中に Amazon EC2 パッチ適用が予期せず発生した可能性があります。 ``` AdDomainAdminNode CREATE_FAILED Failed to receive 1 resource signal(s) within the specified duration ``` **失敗の原因を特定するには:** 1. SSM ステートマネージャーで、パッチ適用が設定されているかどうか、およびすべてのインスタンスに設定されているかどうかを確認します。 1. SSM RunCommand/Automation の実行履歴で、パッチ適用関連の SSM ドキュメントの実行がインスタンスの起動と一致するかどうかを確認します。 1. 環境の Amazon EC2 インスタンスのログファイルで、ローカルインスタンスのログ記録を確認して、プロビジョニング中にインスタンスが再起動したかどうかを確認します。 パッチ適用が原因で問題が発生した場合は、起動から少なくとも 15 分後に RES インスタンスのパッチ適用を遅らせます。 ........................ ## ID 管理の問題 シングルサインオン (SSO) と ID 管理のほとんどの問題は、設定ミスが原因で発生します。SSO 設定の設定については、以下を参照してください。 + [IAM Identity Center でのシングルサインオン (SSO) の設定](sso-idc.md) + [シングルサインオン (SSO) 用の ID プロバイダーの設定](configure-id-federation.md) ID 管理に関連するその他の問題をトラブルシューティングするには、以下のトラブルシューティングトピックを参照してください。 **Topics** + [iam:PassRole を実行する権限がありません](#res-troubleshooting-issue-runbooks-unauth-passrole) + [自分の AWSアカウント以外のユーザーにAWSリソースの Research and Engineering Studio へのアクセスを許可したい](#res-troubleshooting-issue-runbooks-outside-acct) + [環境にログインすると、すぐにログインページに戻ります。](#return-to-login) + [ログイン試行時の「ユーザーが見つかりません」エラー](#user-not-found) + [Active Directory に追加されたが、RES にないユーザー](#user-missing) + [セッションの作成時に使用できないユーザー](#session-user-unavailable) + [CloudWatch クラスターマネージャーログのサイズ制限超過エラー](#sizelimit-exceeded-error) ........................ ### iam:PassRole を実行する権限がありません iam:PassRole アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して RES にロールを渡すことができるようにする必要があります。 一部のAWSサービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。 次の例のエラーは、marymajor という名前の IAM ユーザーがコンソールを使用して RES でアクションを実行しようとすると発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。 ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` この場合、Mary のポリシーを更新してメアリーに iam:PassRole アクションの実行を許可する必要があります。サポートが必要な場合は、AWS管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。 ........................ ### 自分の AWSアカウント以外のユーザーにAWSリソースの Research and Engineering Studio へのアクセスを許可したい 他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。 詳細については、以下を参照してください: + 所有しているAWSアカウント間でリソースへのアクセスを提供する方法については、IAM *ユーザーガイド*の[「所有している別のAWSアカウントの IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 + サードパーティーAWSアカウントにリソースへのアクセスを提供する方法については、*IAM ユーザーガイド*の[「サードパーティーが所有するAWSアカウントへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。 + ID フェデレーションを通じてアクセスを提供する方法については、*IAM ユーザーガイド*の[「外部で認証されたユーザー (ID フェデレーション) へのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)を提供する」を参照してください。 + クロスアカウントアクセスにロールとリソースベースのポリシーを使用する方法の違いについては、[IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーの違い](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)」を参照してください。 ** ........................ ### 環境にログインすると、すぐにログインページに戻ります。 この問題は、SSO 統合の設定が間違っている場合に発生します。問題を特定するには、コントローラーインスタンスログをチェックし、エラーがないか設定を確認します。 **ログを確認するには:** 1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。 1. **ロググループ**から、 という名前のグループを見つけます`/{{}}/cluster-manager`。 1. ロググループを開いて、ログストリームのエラーを検索します。 **設定を確認するには:** 1. [DynamoDB コンソール](https://console.aws.amazon.com/dynamodb)を開く 1. **テーブルから**、 という名前のテーブルを見つけます`{{}}.cluster-settings`。 1. テーブルを開き、**Explore テーブル項目**を選択します。 1. フィルターセクションを展開し、次の変数を入力します。 + **属性名** – キー + **条件** – を含む + **値** – sso 1. **[Run]** (実行) を選択します。 1. 返された文字列で、SSO 設定値が正しいことを確認します。正しくない場合は、sso\_enabled キーの値を **False** に変更します。 ![sso_enabled キー値の項目の編集画面がある DynamoDB コンソール。](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-editssoenabledkeyvalue.png) 1. RES ユーザーインターフェイスに戻り、SSO を再設定します。 ........................ ### ログイン試行時の「ユーザーが見つかりません」エラー ユーザーが RES インターフェイスにログインしようとしたときに「ユーザーが見つかりません」というエラーが表示され、そのユーザーが Active Directory に存在する場合: + **ユーザーが RES に存在せず、最近 AD にユーザーを追加した場合** + ユーザーがまだ RES に同期されていない可能性があります。RES は 1 時間ごとに同期するため、次の同期後にユーザーが追加されたことを待機して確認する必要がある場合があります。すぐに同期するには、「」の手順に従います[Active Directory に追加されたが、RES にないユーザー](#user-missing)。 + **ユーザーが RES に存在する場合:** 1. 属性マッピングが正しく設定されていることを確認します。詳細については、「[シングルサインオン (SSO) 用の ID プロバイダーの設定](configure-id-federation.md)」を参照してください。 1. SAML 件名と SAML E メールの両方がユーザーの E メールアドレスにマッピングされていることを確認します。 ........................ ### Active Directory に追加されたが、RES にないユーザー **注記** このセクションは RES 2024.10 以前に適用されます。RES 2024.12 以降については、「」を参照してください[同期を手動で実行する方法 (リリース 2024.12 および 2024.12.01)](active-directory-sync.md#active-directory-sync-manually)。RES 2025.03 以降については、「」を参照してください[同期を手動で開始または停止する方法 (リリース 2025 年 3 月以降)](active-directory-sync.md#active-directory-sync-start-stop)。 ユーザーを Active Directory に追加しても RES にない場合は、AD 同期をトリガーする必要があります。AD 同期は、AD エントリを RES 環境にインポートする Lambda 関数によって 1 時間ごとに実行されます。場合によっては、新しいユーザーまたはグループを追加した後、次の同期プロセスが実行されるまで遅延することがあります。Amazon Simple Queue Service から手動で同期を開始できます。 **同期プロセスを手動で開始します。** 1. [Amazon SQS コンソール](https://console.aws.amazon.com/sqs)を開きます。 1. **キュー**から、 を選択します`-cluster-manager-tasks.fifo`。 1. **[メッセージの送信と受信]** を選択します。 1. **メッセージ本文**には、次のように入力します。 **{ "name": "adsync.sync-from-ad", "payload": {} }** 1. **メッセージグループ ID** には、次のように入力します。 **adsync.sync-from-ad** 1. **メッセージ重複排除 ID** には、ランダムな英数字の文字列を入力します。このエントリは、過去 5 分以内に行われたすべての呼び出しとは異なる必要があります。そうしないと、リクエストは無視されます。 ........................ ### セッションの作成時に使用できないユーザー セッションを作成する管理者が、セッションの作成時に Active Directory に属しているユーザーが利用できない場合、ユーザーは初めてログインする必要がある場合があります。セッションはアクティブなユーザーに対してのみ作成できます。アクティブなユーザーは、少なくとも 1 回環境にログインする必要があります。 ........................ ### CloudWatch クラスターマネージャーログのサイズ制限超過エラー ``` 2023-10-31T18:03:12.942-07:00 ldap.SIZELIMIT_EXCEEDED: {'msgtype': 100, 'msgid': 11, 'result': 4, 'desc': 'Size limit exceeded', 'ctrls': []} ``` CloudWatch クラスターマネージャーログにこのエラーが表示された場合、ldap 検索が返したユーザーレコードが多すぎる可能性があります。この問題を修正するには、IDP の ldap 検索結果の制限を引き上げます。 ........................ ## Storage **Topics** + [RES を使用してファイルシステムを作成しましたが、VDI ホストにマウントされません](#res-troubleshooting-storage-created) + [RES を介してファイルシステムをオンボードしたが、VDI ホストにマウントされない](#res-troubleshooting-storage-onboarded) + [VDI ホストから読み書きできない](#res-troubleshooting-storage-rw) + [RES から Amazon FSx for NetApp ONTAP を作成しましたが、ドメインに参加していません](#res-troubleshooting-storage-join) ........................ ### RES を使用してファイルシステムを作成しましたが、VDI ホストにマウントされません ファイルシステムは、VDI ホストでマウントする前に「使用可能」状態である必要があります。以下のステップに従って、ファイルシステムが必須状態であることを確認します。 Amazon EFS 1. [ Amazon EFS コンソール](https://console.aws.amazon.com/efs/home#/file-systems)に移動します。 1. ファイルシステムの状態が**使用可能**であることを確認します。 1. ファイルシステムの状態が**使用可能**でない場合は、VDI ホストを起動する前に待ちます。 Amazon FSx ONTAP 1. [ Amazon FSx コンソール](https://console.aws.amazon.com/fsx/home#file-systems)に移動します。 1. **ステータス**が**使用可能**であることを確認します。 1. **Status** が**使用可能**でない場合は、VDI ホストを起動するまで待ちます。 ........................ ### RES を介してファイルシステムをオンボードしたが、VDI ホストにマウントされない RES にオンボードされるファイルシステムには、VDI ホストがファイルシステムをマウントできるように、必要なセキュリティグループルールが設定されている必要があります。これらのファイルシステムは RES の外部で作成されるため、RES は関連するセキュリティグループルールを管理しません。 オンボードされたファイルシステムに関連付けられたセキュリティグループは、次のインバウンドトラフィックを許可する必要があります。 + Linux " ホストからの NFS トラフィック (ポート: 2049) + Windows " ホストからの SMB トラフィック (ポート: 445) ........................ ### VDI ホストから読み書きできない ONTAP は、ボリュームの UNIX、NTFS、MIXED セキュリティスタイルをサポートしています。セキュリティスタイルは、ONTAP がデータアクセスを制御するために使用するアクセス許可のタイプと、これらのアクセス許可を変更できるクライアントタイプを決定します。 たとえば、ボリュームが UNIX セキュリティスタイルを使用している場合でも、ONTAP のマルチプロトコル特性により、SMB クライアントは引き続きデータにアクセスできます (ただし、適切に認証および認可される場合に限ります）。ただし、ONTAP は UNIX クライアントのみがネイティブツールを使用して変更できる UNIX アクセス許可を使用します。 #### アクセス許可処理のユースケースの例 **Linux ワークロードでの UNIX スタイルのボリュームの使用** アクセス許可は、他のユーザーの sudoer で設定できます。たとえば、次の例では、 `/` ディレクトリに対する``完全な読み取り/書き込みアクセス許可のすべてのメンバーに付与します。 ``` sudo chown root:{{}} /{{}} sudo chmod 770 /{{}} ``` **Linux および Windows ワークロードでの NTFS スタイルのボリュームの使用** 共有アクセス許可は、特定のフォルダの共有プロパティを使用して設定できます。たとえば、ユーザー`user_01`とフォルダ がある場合`myfolder`、`Full Control`、、`Change`または のアクセス許可`Read`を `Allow`または に設定できます`Deny`。 ![共有アクセス許可は、フルコントロール、変更、または読み取りの許可または拒否に設定できます。](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-permissions-for-documents-dialog.png) ボリュームを Linux クライアントと Windows クライアントの両方で使用する場合は、Linux ユーザー名を同じユーザー名に domain\\username の NetBIOS ドメイン名形式に関連付ける名前マッピングを SVM に設定する必要があります。これは、Linux ユーザーと Windows ユーザーの間で変換するために必要です。リファレンスについては、[「Amazon FSx for NetApp ONTAP によるマルチプロトコルワークロードの有効化](https://aws.amazon.com/blogs/storage/enabling-multiprotocol-workloads-with-amazon-fsx-for-netapp-ontap/)」を参照してください。 ........................ ### RES から Amazon FSx for NetApp ONTAP を作成しましたが、ドメインに参加していません 現在、RES コンソールから Amazon FSx for NetApp ONTAP を作成すると、ファイルシステムはプロビジョニングされますが、ドメインに参加しません。作成した ONTAP ファイルシステム SVM をドメインに結合するには、[「Microsoft Active Directory SVMs の結合](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/self-managed-AD-join.html)」を参照して、[Amazon FSx コンソール](https://console.aws.amazon.com/fsx/home#file-systems)の手順に従ってください。必要な[アクセス許可が AD の Amazon FSx サービスアカウントに委任](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/self-managed-AD-best-practices.html#connect_delegate_privileges)されていることを確認します。SVM がドメインに正常に参加したら、SVM **概要 > エンドポイント > SMB DNS 名**に移動し、後で必要になるため DNS 名をコピーします。 ドメインに結合したら、クラスター設定 DynamoDB テーブルで SMB DNS 設定キーを編集します。 1. [ Amazon DynamoDB コンソール](https://console.aws.amazon.com/dynamodbv2/home)に移動します。 1. **Tables** を選択し、 を選択します`-cluster-settings`。 1. 「**Explore table items******」で、フィルタを展開し、次のフィルタを入力します。 + 属性名 - キー + 条件 - に等しい + 値 - `shared-storage..fsx_netapp_ontap.svm.smb_dns` 1. 返された項目を選択し、次に**アクション**、**編集項目**を選択します。 1. 以前にコピーした SMB DNS 名で**値**を更新します。 1. **[保存して閉じる]** を選択します。 さらに、ファイルシステムに関連付けられたセキュリティグループが、[Amazon VPC によるファイルシステムアクセスコントロール](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/limit-access-security-groups.html)で推奨されているトラフィックを許可していることを確認します。ファイルシステムを使用する新しい VDI ホストは、ドメインに参加している SVM とファイルシステムをマウントできるようになりました。 または、RES Onboard File System 機能を使用してドメインに既に参加している既存のファイルシステムをオンボードすることもできます。**環境管理**から**ファイルシステム**、**オンボードファイルシステム**を選択します。 ........................ ## スナップショット **Topics** + [スナップショットのステータスが Failed である](#res-troubleshooting-snapshots-failed) + [スナップショットは、テーブルをインポートできなかったことを示すログとともに適用されません。](#res-troubleshooting-snapshots-not-imported) ........................ ### スナップショットのステータスが Failed である RES スナップショットページで、スナップショットのステータスが Failed の場合、エラーが発生した時間、クラスターマネージャーの Amazon CloudWatch ロググループに移動することで原因を特定できます。 ``` [2023-11-19 03:39:20,208] [INFO] [snapshots-service] creating snapshot in S3 Bucket: asdf at path s31 [2023-11-19 03:39:20,381] [ERROR] [snapshots-service] An error occurred while creating the snapshot: An error occurred (TableNotFoundException) when calling the UpdateContinuousBackups operation: Table not found: res-demo.accounts.sequence-config ``` ........................ ### スナップショットは、テーブルをインポートできなかったことを示すログとともに適用されません。 以前の env から取得したスナップショットが新しい env に適用されない場合は、クラスターマネージャーの CloudWatch ログを調べて問題を特定します。必要なテーブルクラウドがインポートされないことが問題で言及されている場合は、スナップショットが有効な状態であることを確認します。 1. metadata.json ファイルをダウンロードし、さまざまなテーブルの ExportStatus のステータスが COMPLETED であることを確認します。さまざまなテーブルに `ExportManifest`フィールドが設定されていることを確認します。上記のフィールドが設定されていない場合、スナップショットは無効な状態であり、スナップショットの適用機能では使用できません。 1. スナップショットの作成を開始したら、RES でスナップショットのステータスが COMPLETED になっていることを確認します。スナップショットの作成プロセスには最大 5～10 分かかります。スナップショット管理ページを再ロードまたは再アクセスして、スナップショットが正常に作成されたことを確認します。これにより、作成されたスナップショットが有効な状態になります。 ........................ ## インフラストラクチャ **Topics** + [正常なインスタンスがないロードバランサーターゲットグループ](#res-troubleshooting-infrastructure-load-balancer) ........................ ### 正常なインスタンスがないロードバランサーターゲットグループ サーバーエラーメッセージなどの問題が UI に表示されるか、デスクトップセッションが接続できない場合、インフラストラクチャの Amazon EC2 インスタンスに問題がある可能性があります。 問題の原因を特定する方法は、まず Amazon EC2 コンソールで、繰り返し終了し、新しいインスタンスに置き換えられていると思われる Amazon EC2 インスタンスがないかを確認することです。その場合は、Amazon CloudWatch logsをチェックして原因を特定できます。 もう 1 つの方法は、システム内のロードバランサーを確認することです。システムに問題がある可能性があることを示すのは、Amazon EC2 コンソールで見つかったロードバランサーに、登録された正常なインスタンスが表示されない場合です。 通常の外観の例を以下に示します。 ![EC2 ロードバランサーダッシュボード](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-ec2-load-balancers.png) Healthy エントリが 0 の場合、リクエストを処理できる Amazon EC2 インスタンスがないことを示します。 Unhealthy エントリが 0 以外の場合は、Amazon EC2 インスタンスが循環している可能性があります。これは、インストールされているアプリケーションソフトウェアがヘルスチェックに合格していないことが原因である可能性があります。 Healthy エントリと Unhealthy エントリの両方が 0 の場合、ネットワークの設定ミスの可能性を示します。たとえば、パブリックサブネットとプライベートサブネットには、対応する AZs がない場合があります。この状態が発生すると、ネットワーク状態が存在することを示す追加のテキストがコンソールに表示される場合があります。 ........................ ## 仮想デスクトップの起動 **Topics** + [Windows Virtual Desktop のログインアカウントが管理者に設定されています](#res-troubleshooting-virtual-desktops-windows-admin) + [外部リソース CertificateRenewalNode を使用する場合、証明書の有効期限が切れます](#res-troubleshooting-virtual-desktops-certificate-expires) + [以前に機能していた仮想デスクトップが正常に接続できなくなった](#res-troubleshooting-virtual-desktops-was-working) + [5 つの仮想デスクトップしか起動できない](#res-troubleshooting-virtual-desktops-only-five) + [デスクトップ Windows の接続試行は「接続が閉じられました。トランスポートエラー"](#res-troubleshooting-virtual-desktops-transport-error) + [VDIsプロビジョニング状態でスタックする](#res-troubleshooting-virtual-desktops-stuck-prov) + [起動後に VDIsがエラー状態になる](#res-troubleshooting-virtual-desktops-error-after) + [ログインすると、VDI セッションが空白の画面になります](#res-troubleshooting-virtual-desktops-vdi-blank-screen) ........................ ### Windows Virtual Desktop のログインアカウントが管理者に設定されています RES ウェブポータルで Windows Virtual Desktop を起動できるが、接続時にログインアカウントが管理者に設定されている場合、Windows VDI が Active Directory に正常に参加していない可能性があります。 確認するには、Amazon EC2 コンソールから Windows インスタンスに接続し、 のブートストラップログを確認します`C:\Users\Administrator\RES\Bootstrap\virtual-desktop-host-windows\`。で始まるエラーメッセージ`[Join AD] authorization failed:`は、インスタンスが AD に参加できなかったことを示します。障害の詳細については、ロググループ名で CloudWatch の Cluster Manager ログ`/{{}}/cluster-manager`を確認してください。 + `Insufficient permissions to modify computer account` + このエラーは、サービスアカウントに AD にコンピュータを追加する適切なアクセス許可がないことを示します。[Microsoft Active Directory のサービスアカウントを設定する](prerequisites.md#service-account-ms-ad) 「」セクションで、サービスアカウントに必要なアクセス許可を確認してください。 + `Invalid Credentials` + AD のサービスアカウントの認証情報の有効期限が切れているか、誤った認証情報が指定されています。サービスアカウントの認証情報を確認または更新するには、[Secrets Manager コンソールにパスワードを保存するシー](https://console.aws.amazon.com/secretsmanager/listsecrets)クレットにアクセスします。RES 環境の **Identity Management** ページの **Active Directory Domain** **の Service Account Credentials Secret ARN フィールドで、このシークレットの ARN** が正しいことを確認します。 ........................ ### 外部リソース CertificateRenewalNode を使用する場合、証明書の有効期限が切れます [外部リソースレシピ](create-external-resources.md)をデプロイし、Linux VDIs への接続`"The connection has been closed. Transport error"`中に というエラーが発生した場合、最も可能性の高い原因は、Linux での pip インストールパスが正しくないために自動的に更新されない期限切れの証明書です。証明書の有効期限は 3 か月です。 Amazon CloudWatch ロググループは、次のようなメッセージで接続試行エラーをログに記録する`{{}}/vdc/dcv-connection-gateway`場合があります。 ``` | 2024-07-29T21:46:02.651Z | Jul 29 21:46:01.702 WARN HTTP:Splicer Connection{id=341 client_address="x.x.x.x:50682"}: Error in connection task: TLS handshake error: received fatal alert: CertificateUnknown | redacted:/res-demo/vdc/dcv-connection-gateway | dcv-connection-gateway_10.3.146.195 | | 2024-07-29T21:46:02.651Z | Jul 29 21:46:01.702 WARN HTTP:Splicer Connection{id=341 client_address="x.x.x.x:50682"}: Certificate error: AlertReceived(CertificateUnknown) | redacted:/res-demo/vdc/dcv-connection-gateway | dcv-connection-gateway_10.3.146.195 | ``` **問題を解決するには:** 1. AWSアカウントで、[EC2](https://console.aws.amazon.com/ec2) に移動します。という名前のインスタンスがある場合は`*-CertificateRenewalNode-*`、インスタンスを終了します。 1. [Lambda](https://console.aws.amazon.com/lambda) に移動します。という名前の Lambda 関数が表示され`*-CertificateRenewalLambda-*`、Lambda コードに次のようなものがないか確認してください。 ``` export HOME=/tmp/home mkdir -p $HOME cd /tmp wget https://bootstrap.pypa.io/pip/3.7/get-pip.py python3 ./get-pip.py pip3 install boto3 eval $(python3 -c "from botocore.credentials import InstanceMetadataProvider, InstanceMetadataFetcher; provider = InstanceMetadataProvider(iam_role_fetcher=InstanceMetadataFetcher(timeout=1000, num_attempts=2)); c = provider.load().get_frozen_credentials(); print(f'export AWS_ACCESS_KEY_ID={c.access_key}'); print(f'export AWS_SECRET_ACCESS_KEY={c.secret_key}'); print(f'export AWS_SESSION_TOKEN={c.token}')") mkdir certificates cd certificates git clone https://github.com/Neilpang/acme.sh.git cd acme.sh ``` 1. 最新の外部リソース Certs スタックテンプレートについては、[こちらを参照してください](https://github.com/aws-samples/aws-hpc-recipes/blob/main/recipes/security/public_certs/assets/main.yaml)。テンプレートで Lambda コードを見つけます: **リソース** → **CertificateRenewalLambda** → **プロパティ** → **コード**。次のようなものがあります。 ``` sudo yum install -y wget export HOME=/tmp/home mkdir -p $HOME cd /tmp wget https://bootstrap.pypa.io/pip/3.7/get-pip.py mkdir -p pip python3 ./get-pip.py --target $PWD/pip $PWD/pip/bin/pip3 install boto3 eval $(python3 -c "from botocore.credentials import InstanceMetadataProvider, InstanceMetadataFetcher; provider = InstanceMetadataProvider(iam_role_fetcher=InstanceMetadataFetcher(timeout=1000, num_attempts=2)); c = provider.load().get_frozen_credentials(); print(f'export AWS_ACCESS_KEY_ID={c.access_key}'); print(f'export AWS_SECRET_ACCESS_KEY={c.secret_key}'); print(f'export AWS_SESSION_TOKEN={c.token}')") mkdir certificates cd certificates VERSION=3.1.0 wget https://github.com/acmesh-official/acme.sh/archive/refs/tags/$VERSION.tar.gz -O acme-$VERSION.tar.gz tar -xvf acme-$VERSION.tar.gz cd acme.sh-$VERSION ``` 1. `*-CertificateRenewalLambda-* ` Lambda 関数のステップ 2 の セクションをステップ 3 のコードに置き換えます。**デプロイ**を選択し、コード変更が有効になるまで待ちます。 1. Lambda 関数を手動でトリガーするには、**テスト**タブに移動し、**テスト**を選択します。追加の入力は必要ありません。これにより、Secret Manager で Certificate シークレットと PrivateKey シークレットを更新する証明書 EC2 インスタンスが作成されます。 1. 既存の dcv-gateway インスタンスを終了`{{}}-vdc-gateway`し、自動スケーリンググループが新しいインスタンスを自動的にデプロイするのを待ちます。 ........................ ### 以前に機能していた仮想デスクトップが正常に接続できなくなった デスクトップ接続が閉じられたり、接続できなくなったりすると、基盤となる Amazon EC2 インスタンスが失敗するか、Amazon EC2 インスタンスが RES 環境外で終了または停止されたことが原因である可能性があります。管理者 UI のステータスは、準備完了状態を引き続き表示する場合がありますが、接続の試行は失敗します。 Amazon EC2 コンソールを使用して、インスタンスが終了または停止されたかどうかを判断する必要があります。停止した場合は、もう一度開始してみてください。状態が終了した場合は、別のデスクトップを作成する必要があります。ユーザーのホームディレクトリに保存されたデータは、新しいインスタンスの起動時に引き続き使用できます。 以前に失敗したインスタンスが管理者 UI にまだ表示されている場合は、管理者 UI を使用して終了する必要がある場合があります。 ........................ ### 5 つの仮想デスクトップしか起動できない ユーザーが起動できる仮想デスクトップの数のデフォルトの制限は 5 です。これは、管理者が管理者 UI を使用して次のように変更できます。 + **デスクトップ設定**に移動します。 + [**一般**] タブを選択します。 + **プロジェクトごとのユーザーあたりのデフォルトの許可されたセッション**の右側にある編集アイコンを選択し、値を目的の新しい値に変更します。 + [**Submit**] を選択してください。 + ページを更新して、新しい設定が設定されていることを確認します。 ........................ ### デスクトップ Windows の接続試行は「接続が閉じられました。トランスポートエラー" Windows デスクトップ接続が UI エラー「接続が閉じられました。トランスポートエラー」。Windows インスタンスでの証明書の作成に関連する DCV サーバーソフトウェアの問題が原因である可能性があります。 Amazon CloudWatch ロググループは、次のようなメッセージで接続試行エラーをログに記録する`/vdc/dcv-connection-gateway`場合があります。 ``` Nov 24 20:24:27.631 DEBUG HTTP:Splicer Connection{id=9}: Websocket{session_id="1291e75f-7816-48d9-bbb2-7371b3b911cd"}: Resolver lookup{client_ip=Some(52.94.36.19) session_id="1291e75f-7816-48d9-bbb2-7371b3b911cd" protocol_type=WebSocket extension_data=None}:NoStrictCertVerification: Additional stack certificate (0): [s/n: 0E9E9C4DE7194B37687DC4D2C0F5E94AF0DD57E] Nov 24 20:25:15.384 INFO HTTP:Splicer Connection{id=21}:Websocket{ session_id="d1d35954-f29d-4b3f-8c23-6a53303ebc3f"}: Connection initiated error: unreachable, server io error Custom { kind: InvalidData, error: General("Invalid certificate: certificate has expired (code: 10)") } Nov 24 20:25:15.384 WARN HTTP:Splicer Connection{id=21}: Websocket{session_id="d1d35954-f29d-4b3f-8c23-6a53303ebc3f"}: Error in websocket connection: Server unreachable: Server error: IO error: unexpected error: Invalid certificate: certificate has expired (code: 10) ``` この場合、SSM セッションマネージャーを使用して Windows インスタンスへの接続を開き、次の 2 つの証明書関連ファイルを削除することが解決される可能性があります。 ``` PS C:\Windows\system32\config\systemprofile\AppData\Local\NICE\dcv> dir Directory: C:\Windows\system32\config\systemprofile\AppData\Local\NICE\dcv Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 8/4/2022 12:59 PM 1704 dcv.key -a---- 8/4/2022 12:59 PM 1265 dcv.pem ``` ファイルは自動的に再作成され、それ以降の接続試行が成功する可能性があります。 この方法で問題を解決し、Windows デスクトップの新しい起動で同じエラーが発生した場合は、ソフトウェアスタックの作成 関数を使用して、再生成された証明書ファイルを含む固定インスタンスの新しい Windows ソフトウェアスタックを作成します。これにより、正常な起動と接続に使用できる Windows ソフトウェアスタックが生成されます。 ........................ ### VDIsプロビジョニング状態でスタックする デスクトップ起動が管理者 UI のプロビジョニング状態のままである場合は、いくつかの理由が考えられます。 原因を特定するには、デスクトップインスタンスのログファイルを調べ、問題の原因となっている可能性のあるエラーを探します。このドキュメントには、ログファイルと Amazon CloudWatch ロググループのリストが含まれており、有用な*ログおよびイベント情報ソース*というラベルが付いたセクションに関連情報が含まれています。 この問題の潜在的な原因は次のとおりです。 + *使用されている AMI ID は software-stack として登録されていますが、RES ではサポートされていません。* Amazon マシンイメージ (AMI) に必要な設定またはツールがないため、ブートストラッププロビジョニングスクリプトを完了できませんでした。Linux インスタンスなど、インスタンス`/root/bootstrap/logs/`のログファイルには、これに関する有用な情報が含まれている場合があります。AWSMarketplace から取得した AMIs ID は、RES デスクトップインスタンスでは機能しない場合があります。サポートされているかどうかを確認するには、テストが必要です。 + *ユーザーデータスクリプトは、Windows 仮想デスクトップインスタンスがカスタム AMI から起動されたときに実行されません。* デフォルトでは、ユーザーデータスクリプトは Amazon EC2 インスタンスの起動時に 1 回実行されます。既存の仮想デスクトップインスタンスから AMI を作成し、その AMI にソフトウェアスタックを登録して、このソフトウェアスタックで別の仮想デスクトップを起動しようとすると、ユーザーデータスクリプトは新しい仮想デスクトップインスタンスでは実行されません。 この問題を解決するには、AMI の作成に使用した**元の**仮想デスクトップインスタンスで管理者として PowerShell コマンドウィンドウを開き、次のコマンドを実行します。 ``` C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 –Schedule ``` 次に、インスタンスから新しい AMI を作成します。新しい AMI を使用してソフトウェアスタックを登録し、後で新しい仮想デスクトップを起動できます。プロビジョニング状態のままのインスタンスで同じコマンドを実行し、インスタンスを再起動して仮想デスクトップセッションを修正することもできますが、設定ミスのある AMI から別の仮想デスクトップを起動すると、同じ問題が再度発生することに注意してください。 ........................ ### 起動後に VDIsがエラー状態になる **考えられる問題 1: ホームファイルシステムに、異なる POSIX アクセス許可を持つユーザーのディレクトリがあります。** これは、次のシナリオが当てはまる場合に直面する問題である可能性があります。 1. デプロイされた RES バージョンは 2024.01 以降です。 1. RES スタックのデプロイ中に、 の 属性が に設定`EnableLdapIDMapping`されました`True`。 1. RES スタックのデプロイ中に指定されたホームファイルシステムは、RES 2024.01 より前のバージョンで使用されたか、 を `EnableLdapIDMapping`に設定して以前の環境で使用されました`False`。 **解決手順**: ファイルシステム内のユーザーディレクトリを削除します。 1. クラスターマネージャーホストへの SSM。 1. `cd /home`. 1. `ls` - は、、.. などのユーザー名に一致するディレクトリ名を持つディレクトリ`admin1`を一覧表示する必要があります`admin2`。 1. ディレクトリ を削除します`sudo rm -r 'dir_name'`。**ssm-user ディレクトリと ec2-user ディレクトリを削除しないでください**。 1. ユーザーが新しい env に既に同期されている場合は、ユーザーの DDB テーブルからユーザーの を削除します (**clusteradmin を除く**)。 1. AD 同期の開始 - クラスターマネージャー Amazon EC2 `sudo /opt/idea/python/3.9.16/bin/resctl ldap sync-from-ad`で実行します。 1. RES ウェブページから `Error`状態の VDI インスタンスを再起動します。VDI が約 20 分で `Ready`状態に移行することを検証します。 ........................ ### ログインすると、VDI セッションが空白の画面になります ログイン後にコンソールセッションタイプの VDI セッションが空白で応答しない場合、X サーバーが壊れていることを意味します。これは、DCV がデスクトップをストリーミングしようとしているが、ストリーミングする OS の問題が原因である可能性があります。この最も可能性の高い原因は、Xorg 設定の問題です。次のコマンドを実行して、デフォルトの Xorg 設定にあまり依存しないようにできます。 **Debian ベースの Linux:** ``` dpkg-divert --package nice-xdcv --divert /usr/bin/Xorg.orig --rename /usr/bin/Xorg ln -sf /usr/bin/Xdcv-console /usr/bin/Xorg ``` **Red Hat ベースの Linux:** ``` rpm -q --whatprovides /usr/bin/Xorg && \ cp /usr/bin/Xorg /usr/bin/Xorg.orig && \ ln -sf /usr/bin/Xdcv-console /usr/bin/Xorg ``` ........................ ## 仮想デスクトップコンポーネント **Topics** + [Amazon EC2 インスタンスがコンソールで終了を繰り返し表示](#res-troubleshooting-vd-component-ec2-terminated) + [AD への参加に失敗したために vdc-controller インスタンスがサイクルしています / eVDI モジュールが失敗した API ヘルスチェックを表示](#res-troubleshooting-vd-component-cycling) + [プロジェクトは、ソフトウェアスタックを編集して追加するときにプルダウンに表示されません](#res-troubleshooting-vd-component-not-in-pulldown) + [cluster-manager Amazon CloudWatch ログには、「 アカウントはまだ利用できません。ユーザーの同期を待っています」と表示されます (アカウントはユーザー名です）。](#res-troubleshooting-vd-component-acct-unavailable) + [ログイン試行時の Windows デスクトップに「アカウントが無効になっています。管理者にお問い合わせください」](#res-troubleshooting-vd-component-acct-disabled) + [外部/顧客の AD 設定に関する DHCP オプションの問題](#res-troubleshooting-vd-component-dhcp) + [Firefox エラー MOZILLA\_PKIX\_ERROR\_REQUIRED\_TLS\_FEATURE\_MISSING](#res-troubleshooting-vd-firefox) ........................ ### Amazon EC2 インスタンスがコンソールで終了を繰り返し表示 インフラストラクチャインスタンスが Amazon EC2 コンソールで終了と繰り返し表示される場合、原因はその設定に関連している可能性があり、インフラストラクチャインスタンスタイプによって異なります。以下に、原因を特定する方法を示します。 Amazon EC2 コンソールで vdc-controller インスタンスが終了状態が繰り返し表示される場合は、シークレットタグが正しくない可能性があります。RES によって維持されるシークレットには、インフラストラクチャの Amazon EC2 インスタンスにアタッチされた IAM アクセスコントロールポリシーの一部として使用されるタグがあります。vdc-controller がサイクルしていて、CloudWatch ロググループに次のエラーが表示された場合、シークレットが正しくタグ付けされていない可能性があります。シークレットには、次のタグを付ける必要があることに注意してください。 ``` { "res:EnvironmentName": "{{}}" # e.g. "res-demo" "res:ModuleName": "virtual-desktop-controller" } ``` このエラーの Amazon CloudWatch ログメッセージは、次のように表示されます。 ``` An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::160215750999:assumed-role/{{}}-vdc-gateway-role-us-east-1/i-043f76a2677f373d0 is not authorized to perform: secretsmanager:GetSecretValue on resource: arn:aws:secretsmanager:us-east-1:160215750999:secret:Certificate-res-bi-Certs-5W9SPUXF08IB-F1sNRv because no identity-based policy allows the secretsmanager:GetSecretValue action ``` Amazon EC2 インスタンスのタグをチェックし、上記のリストと一致することを確認します。 ........................ ### AD への参加に失敗したために vdc-controller インスタンスがサイクルしています / eVDI モジュールが失敗した API ヘルスチェックを表示 eVDI モジュールがヘルスチェックに失敗した場合、環境ステータスセクションに以下が表示されます。 ![環境モジュールとステータスダッシュボードの例](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-environment-modules-status.png) この場合、デバッグの一般的なパスは、**クラスターマネージャーの** [CloudWatch](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups) ログを調べることです。( という名前のロググループを探します`/cluster-manager`。) 考えられる問題: + ログにテキスト が含まれている場合は`Insufficient permissions`、res スタックの作成時に指定された ServiceAccount ユーザー名のスペルが正しいことを確認してください。 ログ行の例: ``` Insufficient permissions to modify computer account: CN=IDEA-586BD25043,OU=Computers,OU=RES,OU=CORP,DC=corp,DC=res,DC=com: 000020E7: AtrErr: DSID-03153943, #1: 0: 000020E7: DSID-03153943, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90008 (userAccountControl):len 4 >> 432 ms - request will be retried in 30 seconds ``` + [ SecretsManager コンソール](https://console.aws.amazon.com/secretsmanager/listsecrets)から、RES デプロイ中に提供される ServiceAccount ユーザー名にアクセスできます。Secrets Manager で対応するシークレットを検索し、**プレーンテキストの取得**を選択します。ユーザー名が正しくない場合は、**編集**を選択してシークレット値を更新します。現在の cluster-manager インスタンスと vdc-controller インスタンスを終了します。新しいインスタンスは安定した状態になります。 + 提供された[外部リソーススタック](create-external-resources.md)によって作成されたリソースを使用している場合、ユーザー名は「ServiceAccount」である必要があります。RES のデプロイ中に `DisableADJoin`パラメータが False に設定されている場合は、ServiceAccount」ユーザーに AD で**コンピュータ**オブジェクトを作成するアクセス許可があることを確認します。 + 使用したユーザー名が正しいが、ログにテキスト が含まれている場合`Invalid credentials`、入力したパスワードが**間違って**いるか、**有効期限が切れ**ている可能性があります。 ログ行の例: ``` {'msgtype': 97, 'msgid': 1, 'result': 49, 'desc': 'Invalid credentials', 'ctrls': [], 'info': '80090308: LdapErr: DSID-0C090569, comment: AcceptSecurityContext error, data 532, v4563'} ``` + 環境の作成時に入力したパスワードは、[Secrets Manager コンソールにパスワードを保存するシーク](https://console.aws.amazon.com/secretsmanager/listsecrets)レットにアクセスして読み取ることができます。シークレット ( など`directoryserviceServiceAccountPassword`) を選択し、**プレーンテキストの取得**を選択します。 + シークレットのパスワードが正しくない場合は、**編集**を選択してシークレットの値を更新します。現在の cluster-manager インスタンスと vdc-controller インスタンスを終了します。新しいインスタンスは更新されたパスワードを使用し、安定した状態になります。 + パスワードが正しい場合は、接続された Active Directory でパスワードの有効期限が切れている可能性があります。最初に Active Directory でパスワードをリセットしてから、シークレットを更新する必要があります。[Directory Service コンソール](https://console.aws.amazon.com/directoryservicev2/identity/home)から Active Directory でユーザーのパスワードをリセットできます。 1. 適切なディレクトリ ID を選択する 1. **アクション**、**ユーザーパスワードのリセット**を選択し、ユーザー名 (ServiceAccount」など) と新しいパスワードをフォームに入力します。 1. 新しく設定したパスワードが以前のパスワードと異なる場合は、対応する Secret Manager シークレットのパスワードを更新します (例: `directoryserviceServiceAccountPassword`。 1. 現在の cluster-manager インスタンスと vdc-controller インスタンスを終了します。新しいインスタンスは安定した状態になります。 ........................ ### プロジェクトは、ソフトウェアスタックを編集して追加するときにプルダウンに表示されません この問題は、ユーザーアカウントと AD の同期に関連する次の問題に関連している可能性があります。この問題が発生した場合は、クラスターマネージャーの Amazon CloudWatch ロググループでエラー` account not available yet. waiting for user to be synced`「」をチェックして、原因が同じか関連しているかを判断します。 ........................ ### cluster-manager Amazon CloudWatch ログには、「 アカウントはまだ利用できません。ユーザーの同期を待っています」と表示されます (アカウントはユーザー名です）。 SQS サブスクライバーは、ユーザーアカウントにアクセスできないため、ビジー状態で無限ループに陥っています。このコードは、ユーザーの同期中にユーザーのホームファイルシステムを作成しようとしたときにトリガーされます。 ユーザーアカウントにアクセスできないのは、使用中の AD に対して RES が正しく設定されていないためです。たとえば、BI/RES 環境の作成時に使用された `ServiceAccountCredentialsSecretArn`パラメータの値が正しくない可能性があります。 ........................ ### ログイン試行時の Windows デスクトップに「アカウントが無効になっています。管理者にお問い合わせください」 ![アカウント無効化エラー画面](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-disabled-account.png) ユーザーがロックされた画面に再度ログインできない場合は、SSO 経由で正常にサインオンした後、RES 用に設定された AD でユーザーが無効になっている可能性があります。 AD でユーザーアカウントが無効になっている場合、SSO ログインは失敗します。 ........................ ### 外部/顧客の AD 設定に関する DHCP オプションの問題 独自の Active Directory `"The connection has been closed. Transport error"`で RES を使用するときに Windows 仮想デスクトップで というエラーが発生した場合は、dcv-connection-gateway Amazon CloudWatch ログに次のようなものがないか確認してください。 ``` Oct 28 00:12:30.626 INFO HTTP:Splicer Connection{id=263}: Websocket{session_id="96cffa6e-cf2e-410f-9eea-6ae8478dc08a"}: Connection initiated error: unreachable, server io error Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" } Oct 28 00:12:30.626 WARN HTTP:Splicer Connection{id=263}: Websocket{session_id="96cffa6e-cf2e-410f-9eea-6ae8478dc08a"}: Error in websocket connection: Server unreachable: Server error: IO error: failed to lookup address information: Name or service not known Oct 28 00:12:30.627 DEBUG HTTP:Splicer Connection{id=263}: ConnectionGuard dropped ``` 独自の VPC の DHCP オプションに AD ドメインコントローラーを使用している場合は、以下を行う必要があります。 1. AmazonProvidedDNS を 2 つのドメインコントローラー IPs。 1. ドメイン名を ec2.internal に設定します。 以下に例を示します。この設定がない場合、RES/DCV は ip-10-0-x-xx.ec2.internal ホスト名を検索するため、Windows デスクトップは**トランスポートエラー** を返します。 ![ドメイン名とドメイン名サーバーの例](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-domain-name-and-servers.png) ........................ ### Firefox エラー MOZILLA\_PKIX\_ERROR\_REQUIRED\_TLS\_FEATURE\_MISSING Firefox ウェブブラウザを使用すると、仮想デスクトップに接続しようとすると、MOZILLA\_PKIX\_ERROR\_REQUIRED\_TLS\_FEATURE\_MISSING というエラーメッセージが表示されることがあります。 原因は、RES ウェブサーバーが TLS \+ ステープリングオンでセットアップされているが、ステープリング検証で応答していないことです ([https://support.mozilla.org/en-US/questions/1372483](https://support.mozilla.org/en-US/questions/1372483)。 これは、[https://really-simple-ssl.com/mozilla\_pkix\_error\_required\_tls\_feature\_missing ](https://really-simple-ssl.com/mozilla_pkix_error_required_tls_feature_missing)の指示に従って修正できます。 ........................ ## Env 削除 **Topics** + [res-xxx-cluster スタックが「DELETE\_FAILED」状態で、「Role is invalid or cannot be assumed」エラーのため手動で削除できない](#res-troubleshooting-env-deletion-role-invalid) + [ログの収集](#res-troubleshooting-env-deletion-collect-logs) + [VDI ログのダウンロード](#res-troubleshooting-env-deletion-download-logs) + [Linux EC2 インスタンスからのログのダウンロード](#res-troubleshooting-env-deletion-linux-ec2-logs) + [Windows EC2 インスタンスからのログのダウンロード](#res-troubleshooting-env-deletion-windows-ec2-logs) + [WaitCondition エラーの ECS ログの収集](#res-troubleshooting-env-deletion-waitcondition) + [ネットワークインターフェイスの削除に失敗しました](#res-troubleshooting-env-deletion-eni-failure) ........................ ### res-xxx-cluster スタックが「DELETE\_FAILED」状態で、「Role is invalid or cannot be assumed」エラーのため手動で削除できない 「res-xxx-cluster」スタックが「DELETE\_FAILED」状態で、手動で削除できない場合は、次の手順を実行して削除できます。 スタックが「DELETE\_FAILED」状態になっている場合は、まず手動で削除してみてください。スタックの削除を確認するダイアログが表示される場合があります。**[削除]** を選択します。 ![スタック確認ポップアップ画面の削除](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-delete-stack-popup.png) 必要なスタックリソースをすべて削除しても、保持するリソースを選択するメッセージが表示されることがあります。その場合は、「保持するリソース」としてすべてのリソースを選択し、**「削除**」を選択します。 次のようなエラーが表示される場合があります。 `Role: arn:aws:iam::... is Invalid or cannot be assumed` ![無効なロールのエラーを示す CloudFormation スタックウィンドウ](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-cloudformation-stacks-error.png) これは、スタックの削除に必要なロールが、スタックの前に最初に削除されたことを意味します。これを回避するには、ロールの名前をコピーします。IAM コンソールに移動し、次に示すパラメータを使用して、その名前のロールを作成します。 + **信頼されたエンティティタイプ**で**AWSサービス**を選択します。 + **ユースケース** で、 `Use cases for otherAWS services`を選択します`CloudFormation`。 ![IAM ロール ロールの作成ステップ 1 ウィンドウでは、信頼されたエンティティを選択できます。](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-select-trusted-entity.png) [**次へ**] を選択します。ロールに「」および`AWSCloudFormationFullAccess``AdministratorAccess`「」のアクセス許可を付与してください。レビューページは次のようになります。 ![この IAM 画面では、ロールに名前を付け、確認して作成できます。](http://docs.aws.amazon.com/ja_jp/res/latest/ug/images/res-iam-name-review-create-role.png) 次に、CloudFormation コンソールに戻り、スタックを削除します。これで、ロールを作成した後で削除できるようになります。最後に、IAM コンソールに移動し、作成したロールを削除します。 ........................ ### ログの収集 **EC2 コンソールから EC2 インスタンスにログインする** + Linux EC2 インスタンスにログインするには、[次の手順に従います](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-with-systems-manager-session-manager.html)。 + Windows EC2 インスタンスにログインするには、[次の手順に従います](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)。次に、Windows PowerShell を開いてコマンドを実行します。 **インフラストラクチャホストログの収集** 1. Cluster-manager: 次の場所からクラスターマネージャーのログを取得し、チケットにアタッチします。 1. CloudWatch ロググループ からのすべてのログ`/cluster-manager`。 1. `-cluster-manager` EC2 インスタンスの `/root/bootstrap/logs` ディレクトリにあるすべてのログ。このセクションの冒頭にあるEC2 コンソールから EC2 インスタンスにログインする」から にリンクされている手順に従って、インスタンスにログインします。 1. Vdc-controller: 次の場所から vdc-controller のログを取得し、チケットにアタッチします。 1. CloudWatch ロググループ からのすべてのログ`/vdc-controller`。 1. `-vdc-controller` EC2 インスタンスの `/root/bootstrap/logs` ディレクトリにあるすべてのログ。このセクションの冒頭にあるEC2 コンソールから EC2 インスタンスにログインする」から にリンクされている手順に従って、インスタンスにログインします。 ログを簡単に取得する方法の 1 つは、 [Linux EC2 インスタンスからのログのダウンロード](#res-troubleshooting-env-deletion-linux-ec2-logs)セクションの指示に従うことです。モジュール名はインスタンス名になります。 **VDI ログの収集** **対応する Amazon EC2 インスタンスを特定する ** ユーザーがセッション名 で VDI を起動した場合`VDI1`、Amazon EC2 コンソールのインスタンスの対応する名前は になります`-VDI1-`。 **Linux VDI ログの収集 ** このセクションの冒頭にあるAmazon EC2 コンソールから EC2 インスタンスにログインする」の「」にリンクされた手順に従って、Amazon EC2 コンソールから対応する Amazon EC2 インスタンスにログインします。VDI Amazon EC2 インスタンスの `/root/bootstrap/logs`および `/var/log/dcv/` ディレクトリにあるすべてのログを取得します。 ログを取得する方法の 1 つは、ログを s3 にアップロードし、そこからダウンロードすることです。そのためには、以下の手順に従って 1 つのディレクトリからすべてのログを取得し、アップロードします。 1. `/root/bootstrap/logs` ディレクトリの下に dcv ログをコピーするには、次の手順に従います。 ``` sudo su - cd /root/bootstrap mkdir -p logs/dcv_logs cp -r /var/log/dcv/* logs/dcv_logs/ ``` 1. 次に、次のセクション「」に記載されている手順に従って[VDI ログのダウンロード](#res-troubleshooting-env-deletion-download-logs)ログをダウンロードします。 **Windows VDI ログの収集** このセクションの冒頭にあるAmazon EC2 コンソールから EC2 インスタンスにログインする」の「」にリンクされた手順に従って、Amazon EC2 コンソールから対応する Amazon EC2 インスタンスにログインします。VDI EC2 インスタンスの `$env:SystemDrive\Users\Administrator\RES\Bootstrap\Log\` ディレクトリですべてのログを取得します。 ログを取得する方法の 1 つは、ログを S3 にアップロードし、そこからダウンロードすることです。これを行うには、次のセクション「」に記載されているステップに従います[VDI ログのダウンロード](#res-troubleshooting-env-deletion-download-logs)。 ........................ ### VDI ログのダウンロード 1. VDI EC2 インスタンスの IAM ロールを更新して、S3 アクセスを許可します。 1. EC2 コンソールに移動し、VDI インスタンスを選択します。 1. 使用している IAM ロールを選択します。 1. アクセス**許可の追加ドロップダウンメニューのアクセス許可ポリシー**セクションで、**ポリシーのアタッチ**を選択し、**AmazonS3FullAccess** ポリシーを選択します。 **** 1. アクセス**許可を追加** を選択して、そのポリシーをアタッチします。 1. その後、VDI タイプに基づいて以下の手順に従ってログをダウンロードします。モジュール名はインスタンス名になります。 1. [Linux EC2 インスタンスからのログのダウンロード](#res-troubleshooting-env-deletion-linux-ec2-logs) Linux 用。 1. [Windows EC2 インスタンスからのログのダウンロード](#res-troubleshooting-env-deletion-windows-ec2-logs) for Windows。 1. 最後に、ロールを編集して`AmazonS3FullAccess`ポリシーを削除します。 **注記** すべての VDIs、 と同じ IAM ロールを使用します。 `-vdc-host-role-` ........................ ### Linux EC2 インスタンスからのログのダウンロード ログをダウンロードする EC2 インスタンスにログインし、次のコマンドを実行してすべてのログを s3 バケットにアップロードします。 ``` sudo su - ENV_NAME={{}} REGION={{}} ACCOUNT={{}} MODULE={{}} cd /root/bootstrap tar -czvf ${MODULE}_logs.tar.gz logs/ --overwrite aws s3 cp ${MODULE}_logs.tar.gz s3://${ENV_NAME}-cluster-${REGION}-${ACCOUNT}/${MODULE}_logs.tar.gz ``` その後、S3 コンソールに移動`-cluster--`し、名前が のバケットを選択し、以前にアップロードした`_logs.tar.gz`ファイルをダウンロードします。 ........................ ### Windows EC2 インスタンスからのログのダウンロード ログをダウンロードする EC2 インスタンスにログインし、次のコマンドを実行してすべてのログを S3 バケットにアップロードします。 ``` $ENV_NAME="" $REGION="{{}}" $ACCOUNT="{{}}" $MODULE="{{}}" $logDirPath = Join-Path -Path $env:SystemDrive -ChildPath "Users\Administrator\RES\Bootstrap\Log" $zipFilePath = Join-Path -Path $env:TEMP -ChildPath "logs.zip" Remove-Item $zipFilePath Compress-Archive -Path $logDirPath -DestinationPath $zipFilePath $bucketName = "${ENV_NAME}-cluster-${REGION}-${ACCOUNT}" $keyName = "${MODULE}_logs.zip" Write-S3Object -BucketName $bucketName -Key $keyName -File $zipFilePath ``` その後、S3 コンソールに移動`-cluster--`し、名前が のバケットを選択し、以前にアップロードした`_logs.zip`ファイルをダウンロードします。 ........................ ### WaitCondition エラーの ECS ログの収集 1. デプロイされたスタックに移動し、**リソース**タブを選択します。 1. **Deploy** → **ResearchAndEngineeringStudio** → **Installer** → **Tasks** → **CreateTaskDef** → **CreateContainer** → **LogGroup** を展開し、ロググループを選択して CloudWatch ログを開きます。 1. このロググループから最新のログを取得します。 ........................ ### ネットワークインターフェイスの削除に失敗しました RES ファイナライザースタック`detachvpcfromlambdacustomresource`の削除の「イベント」セクションで削除に失敗した場合、これは Lambda サービスが削除に失敗したか、RES Lambdas にアタッチされたネットワークインターフェイスが時間内に削除されなかったことを意味します。 [ Amazon EC2 コンソール](https://console.aws.amazon.com/ec2)内のネットワークインターフェイスページに移動し、 を含む説明でフィルタリングすることで、これらの古い**ネットワークインターフェイス**を手動で削除できます`AWS Lambda VPC ENI-{{{RES-Environment-Name}}}`。最大 14 個のネットワークインターフェイスが必要ですが、正常に削除できた Lambda の数によっては少なくなる場合があります。これらのネットワークインターフェイスを手動で削除し、RES スタックの削除を再起動します。 ## デモ環境 **Topics** + [ID プロバイダーへの認証リクエストを処理する際のデモ環境ログインエラー](#demo-environment-login-error) + [デモスタックのキークロークが機能しない](#demo-environment-stack-keycloak) ........................ ### ID プロバイダーへの認証リクエストを処理する際のデモ環境ログインエラー **問題** ログインしようとして、ID プロバイダーへの認証リクエストを処理するときに「予期しないエラー」が発生した場合、パスワードの有効期限が切れている可能性があります。これは、ログインしようとしているユーザーのパスワードまたは Active Directory サービスアカウントのいずれかです。 緩和策 1. [Directory サービスコンソール](https://console.aws.amazon.com/directoryservicev2)でユーザーとサービスアカウントのパスワードをリセットします。 1. [ Secrets Manager](https://console.aws.amazon.com/secretsmanager) のサービスアカウントのパスワードを、上記で入力した新しいパスワードと一致するように更新します。 + Keycloak スタックの : **PasswordSecret**-...-**RESExternal**-...-**DirectoryService**-... with Description: Password for Microsoft Active Directory + for RES: **res-ServiceAccountPassword**-... with 説明: Active Directory サービスアカウントのパスワード 1. [EC2 コンソール](https://console.aws.amazon.com/ec2)に移動し、クラスターマネージャーインスタンスを終了します。Auto Scaling ルールは、新しいインスタンスのデプロイを自動的にトリガーします。 ........................ ### デモスタックのキークロークが機能しない **問題** キークロークサーバーがクラッシュし、サーバーを再起動したときにインスタンスの IP が変更された場合、キークロークが壊れた可能性があります。RES ポータルのログインページがロードに失敗するか、ロード状態でスタックし、解決されません。 緩和策 Keycloak を正常な状態に復元するには、既存のインフラストラクチャを削除し、Keycloak スタックを再デプロイする必要があります。以下の手順に従ってください。 1. Cloudformation に移動します。そこに 2 つのキークローク関連スタックが表示されます。 + `{{}}-RESSsoKeycloak-{{}}` (Stack1) `{{}}-RESSsoKeycloak-{{}}-RESSsoKeycloak-*` (スタック2) 1. Stack1 を削除します。ネストされたスタックを削除するように求められたら、は**い**を選択してネストされたスタックを削除します。 スタックが完全に削除されていることを確認します。 1. ここで RES SSO Keycloak スタックテンプレートをダウンロード[します](https://s3.amazonaws.com/aws-hpc-recipes/main/recipes/res/res_demo_env/assets/res-sso-keycloak.yaml)。 1. 削除されたスタックとまったく同じパラメータ値を使用して、このスタックを手動でデプロイします。CloudFormation コンソールからデプロイするには、**スタックの作成** → **新しいリソース (標準)** を使用 → **既存のテンプレートを選択する** → **テンプレートファイルをアップロード**します。削除されたスタックと同じ入力を使用して、必要なパラメータを入力します。これらの入力は、CloudFormation コンソールでフィルターを変更し、**パラメータ**タブに移動することで、削除されたスタックで確認できます。環境名、キーペア、およびその他のパラメータが元のスタックパラメータと一致していることを確認します。 1. スタックがデプロイされると、環境を再度使用する準備が整います。ApplicationUrl は、デプロイされたスタックの**出力**タブにあります。 ........................ ## Active Directory の問題 **Topics** + [VDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない](#active-directory-issues-vdi-stuck) + [SSO の設定後に RES ウェブポータルにログインできない](#active-directory-issues-res-web-portal) + [AD ユーザーは、Linux VDIs を正常に起動した後でも、ファイルブラウザを使用してホームディレクトリにアクセスできません](#active-directory-issues-home-directory-access) + [SSH アクセスが有効になっていると、AD 管理者ユーザーは踏み台ホストにアクセスできません](#active-directory-issues-bastion-host-access) + [RES 外部リソーススタックによってデプロイされた Active Directory の表示と管理](#active-directory-issues-external-resource-stack) ### VDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない 最初に VDI のインストールログと設定ログ (`/root/bootstrap/logs/`Linux の場合は および `/opt/idea/app/logs/` ディレクトリ、Windows の場合は `C:\Users\Administrator\RES\Bootstrap\Log\`および `C:\Program Files\RES\app\logs\` ディレクトリ) で、インストールエラーや設定エラーがないか確認してください。 インスタンスが Active Directory に参加できなかったというエラーメッセージが表示された場合は、通常、Cluster Manager が AD のインスタンスのコンピュータアカウントをプリセットできないためです。`/{{environment-name}}/cluster-manager` CloudWatch ロググループの Cluster Manager ログを確認し、 を含むエラーメッセージをフィルタリングします`[preset-computer]`。一般的な問題は次のとおりです。 + AD サービスアカウントの認証情報が無効です。 + RES に提供したサービスアカウントのシークレットを確認します。ユーザー名とパスワードがキーと値のペアとして提供され`{{{username}}: {{password}}}`、認証情報が有効であることを確認します。既存のインスタンスを終了し、サービスアカウントのシークレットを変更した後に自動スケーリンググループが新しいインスタンスを自動的に起動できるようにして、クラスターマネージャーインスタンスをサイクルする必要があります。次に、新しい VDIsを起動して変更を適用します。 + サービスアカウントには、AD でコンピュータアカウントを作成するアクセス許可がありません。 + サービスアカウントに、「」に記載されているすべての必要なアクセス許可があることを確認します[Microsoft Active Directory のサービスアカウントを設定する](prerequisites.md#service-account-ms-ad)。AD でサービスアカウントのアクセス許可を修正した後、新しい VDIsを起動する必要があります。 + LDAP サーバーに接続できません。 + AD 設定で VPC 内の LDAP/LDAPS 接続が許可され、AWSマネージド AD を使用している場合は [AWSManaged Microsoft AD の DHCP オプションセットを作成または変更した後、VPC の DHCP オプション](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html)が正しく設定されていることを確認します。 + LDAPS 接続では、 `DomainTLSCertificateSecretArn`パラメータが必要であり、接続を保護するために有効な CA 証明書を指定する必要があります。既存のインスタンスを終了し、TLS 証明書シークレットを変更した後に自動スケーリンググループが新しいインスタンスを自動的に起動できるようにして、Cluster Manager インスタンスをサイクルする必要があります。次に、新しい VDIsを起動して変更を適用します。 + RES と AD 間の接続をテストするには、Cluster Manager インスタンスで次の ldapsearch コマンドを実行します (ユーザー OU、LDAP 接続 URI、サービスアカウントのユーザー名とパスワードを置き換えます）。AD が接続を許可するように適切に設定されている場合、このコマンドは指定された OU のすべてのユーザーを返します。 ``` ldapsearch -x -b "OU=Users,OU=RES,OU=CORP,DC=corp,DC=res,DC=com" -D "ServiceAccount@corp.res.com" -H ldap://corp.res.com -w {{service-account-password}} "(objectClass=group)" ``` RES のインストール`true`時に DisableADJoin を に設定した場合、**Linux** VDIs SSSD サービスを介して接続するのではなく、Active Directory にのみ接続します。EC2 コンソールから VDI インスタンスに接続し、そのインスタンス`id {{username}}`で コマンドを実行します。コマンドが対応する AD ユーザーの UID / GID を返すことができない場合は、VDI インスタンス`sudo systemctl status sssd`の コマンドと `/var/log/sssd/` ディレクトリの SSSD サービスログを使用して SSSD サービスのステータスを確認します。 AD に接続するために SSSD 設定をカスタマイズする必要がある場合は、SSSD 設定ファイル (`/etc/sssd/sssd.conf`) を手動で編集し、infra / VDI host (2024.12.01 release 以前`sudo systemctl restart sssd`で コマンドを使用して SSSD サービスを再起動するか、RES ウェブポータルから追加の SSSD 設定を提供できます。[Active Directory の同期](active-directory-sync.md)これは、既存または新しい VDIs に自動的に適用されます (2025.03 release 以降）。 ........................ ### SSO の設定後に RES ウェブポータルにログインできない `{{environment-name}}.accounts.users` と `{{environment-name}}.accounts.groups` DynamoDB テーブルをチェックして、ユーザーとグループが Active Directory から同期されているかどうかを確認します。テーブルが空であるか、ログインしているユーザーが見つからない場合は、`/{{environment-name}}/cluster-manager`CloudWatch ロググループ (2024.12 リリース以前) または `/{{environment-name}}/ad-sync` CloudWatch ロググループ (2024.12 リリース以降) の AD 同期ログを確認します。 に記載されている一般的な AD 設定の問題に加えて[VDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない](#active-directory-issues-vdi-stuck)、他のエラーには次のようなものがあります。 + サービスアカウントには、AD のユーザーとグループをクエリするアクセス許可がありません。 + サービスアカウントに、「」に記載されているすべての必要なアクセス許可があることを確認します[Microsoft Active Directory のサービスアカウントを設定する](prerequisites.md#service-account-ms-ad)。 + Active Directory のユーザー/グループに E メールアドレスなどの必須属性がありません。 + ユーザー/グループの属性を更新して問題を解決します。 AD 同期の問題を修正したら、次にスケジュールされた AD 同期が 1 時間ごとに発生するのを待つか、 [同期を手動で実行する方法 (リリース 2024.12 および 2024.12.01)](active-directory-sync.md#active-directory-sync-manually) (2024.12 および 2024.12.01 リリース) または [同期を手動で開始または停止する方法 (リリース 2025 年 3 月以降)](active-directory-sync.md#active-directory-sync-start-stop) (リリース 2025.03 以降) の指示に従って手動でトリガーできます。 ........................ ### AD ユーザーは、Linux VDIs を正常に起動した後でも、ファイルブラウザを使用してホームディレクトリにアクセスできません Cluster Manager インスタンス`id {{username}}`で コマンドを実行して、AD ユーザーが Cluster Manager に表示されるかどうかを確認します。コマンドが対応する AD ユーザーの UID / GID を返すことができない場合は、`/{{environment-name}}/cluster-manager`CloudWatch ロググループの Cluster Manager ログを確認し、SSSD サービスの開始に関するエラーを検索します。Cluster Manager ログにエラーがない場合は、Cluster Manager インスタンス`sudo systemctl status sssd`の コマンドと `/var/log/sssd/` ディレクトリの SSSD サービスログを使用して、SSSD サービスのステータスを確認します。 AD ユーザーが Cluster Manager に表示されている場合は、コマンド を実行して、ユーザーのホームディレクトリ (`/home/{{username}}`) の UID / GID を確認します`ls -n /home`。ユーザーのホームディレクトリの UID/GID を、 `id {{username}}` コマンドによって返された UID/GID と比較します。UID / GID が一致しない場合、ユーザーのホームディレクトリが RES の外部または以前の RES デプロイから作成される可能性があります。**重要なユーザーデータをバックアップ**し、ホームディレクトリを削除して、ユーザーで新しい Linux VDI を起動します。新しい VDI が正常にプロビジョニングされると、ホームディレクトリは適切な UID/GID で再作成されます。 ........................ ### SSH アクセスが有効になっていると、AD 管理者ユーザーは踏み台ホストにアクセスできません 踏み台ホストインスタンス`id {{username}}`で コマンドを実行して、AD ユーザーが踏み台ホストに表示されるかどうかを確認します。コマンドが対応する AD ユーザーの UID / GID を返すことができない場合は、`/{{environment-name}}/bastion-host`CloudWatch ロググループの踏み台ホストログをチェックし、SSSD サービスの開始に関するエラーを検索します。踏み台ホストログにエラーがない場合は、踏み台ホストインスタンス`sudo systemctl status sssd`の コマンドと `/var/log/sssd/` ディレクトリの SSSD サービスログを使用して、SSSD サービスのステータスを確認します。 ........................ ### RES 外部リソーススタックによってデプロイされた Active Directory の表示と管理 AWSマネージド Active Directory が RES 外部リソーススタックによってデプロイされている場合、Active Directory へのアクセスと管理に使用できるAWS、アカウントの下に`AdDomainWindowsNode-{{external-resource-stack-name}}-WindowsManagementHost`デプロイされた で始まる名前のインスタンスが必要です。次の認証情報を使用して、EC2 コンソールの Fleet Manager を介してインスタンスにログインできます。 + username: 管理者 + password: 外部リソーススタックをデプロイするときに提供される AdminPassword パラメータ AWSマネージド Active Directory を管理するには、*AWS「 Directory Service* [管理ガイド」のAmazon EC2 インスタンスを使用してユーザーとグループ](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_ec2.html)を管理する」を確認してください。 ........................