WorkSpaces の問題のトラブルシューティング - Amazon WorkSpaces
高度なログ記録の有効化 固有の問題のトラブルシューティング

WorkSpaces の問題のトラブルシューティング

以下の情報は、WorkSpaces の問題のトラブルシューティングに役立ちます。

高度なログ記録の有効化

任意の Amazon WorkSpaces クライアントに対して高度なログ記録を有効にして、ユーザーが直面する可能性のある問題のトラブルシューティングに役立てることができます。

高度なログ記録では、診断情報とデバッグレベルの詳細 (詳細なパフォーマンスデータなど) を含むログファイルが生成されます。1.0+ および 2.0+ クライアントの場合、これらの高度なログ記録ファイルは AWS のデータベースに自動的にアップロードされます。

注記

高度なログ記録によって生成されたログファイルの確認や WorkSpaces クライアントの問題に関する技術サポートを AWS に依頼するには、AWS サポートまでお問い合わせください。詳細については、「AWS サポートセンター」を参照してください。

Windows クライアント

    Windows クライアントのログは、次の場所に保存されています。

    %LOCALAPPDATA%\Amazon Web Services\Amazon WorkSpaces\logs

    Windows クライアントで高度なログ記録を有効にするには

    1. Amazon WorkSpaces クライアントを閉じます。

    2. コマンドプロンプトアプリを開きます。

    3. -l3 フラグを指定して WorkSpaces クライアントを起動します。

      c:

      cd "C:\Program Files\Amazon Web Services, Inc\Amazon WorkSpaces"

      workspaces.exe -l3

      注記

      WorkSpaces が、すべてのユーザーではなく 1 人のユーザーに対してインストールされている場合は、次のコマンドを使用します。

      c:

      cd "%LocalAppData%\Programs\Amazon Web Services, Inc\Amazon WorkSpaces"

      workspaces.exe -l3

    macOS クライアント

      macOS クライアントのログは次の場所に保存されます。

      ~/Library/"Application Support"/"Amazon Web Services"/"Amazon WorkSpaces"/logs

      macOS クライアントで高度なログ記録を有効にするには

      1. Amazon WorkSpaces クライアントを閉じます。

      2. ターミナルを開きます。

      3. 以下のコマンドを実行します。

        open -a workspaces --args -l3

      Android クライアント
        Android くらいで高度なログ記録を有効にするには

        1. Amazon WorkSpaces クライアントを閉じます。

        2. Android クライアントメニューを開きます。

        3. [Support] (サポート) を選択します。

        4. [Logging settings] (ログ記録設定) を選択します。

        5. [Enable advanced logging] (高度なログ記録の有効化) を選択します。

        高度なログを有効にした後に Android クライアントのログを取得するには

        • [Extract log] (ログの抽出) をクリックして、圧縮したログをローカルに保存します。

        Linux クライアント

          Linux クライアントのログは、次の場所に保存されます。

          ~/.local/share/Amazon Web Services/Amazon WorkSpaces/logs

          Linux クライアントで高度なログ記録を有効にするには

          1. Amazon WorkSpaces クライアントを閉じます。

          2. ターミナルを開きます。

          3. 以下のコマンドを実行します。

            /opt/workspacesclient/workspacesclient -l3

          Windows クライアント

            Windows クライアントのログは、次の場所に保存されています。

            %LOCALAPPDATA%\Amazon Web Services\Amazon WorkSpaces\logs

            Windows クライアントで高度なログ記録を有効にするには

            1. Amazon WorkSpaces クライアントを閉じます。

            2. コマンドプロンプトアプリを開きます。

            3. -l3 フラグを指定して WorkSpaces クライアントを起動します。

              c:

              cd "C:\Program Files (x86)\Amazon Web Services, Inc\Amazon WorkSpaces"

              workspaces.exe -l3

              注記

              WorkSpaces が、すべてのユーザーではなく 1 人のユーザーに対してインストールされている場合は、次のコマンドを使用します。

              c:

              cd "%LocalAppData%\Programs\Amazon Web Services, Inc\Amazon WorkSpaces"

              workspaces.exe -l3

            macOS クライアント

              macOS クライアントのログは次の場所に保存されます。

              ~/Library/"Application Support"/"Amazon Web Services"/"Amazon WorkSpaces"/logs

              macOS クライアントで高度なログ記録を有効にするには

              1. Amazon WorkSpaces クライアントを閉じます。

              2. ターミナルを開きます。

              3. 以下のコマンドを実行します。

                open -a workspaces --args -l3

              Android クライアント
                Android くらいで高度なログ記録を有効にするには

                1. Amazon WorkSpaces クライアントを閉じます。

                2. Android クライアントメニューを開きます。

                3. [Support] (サポート) を選択します。

                4. [Logging settings] (ログ記録設定) を選択します。

                5. [Enable advanced logging] (高度なログ記録の有効化) を選択します。

                高度なログを有効にした後に Android クライアントのログを取得するには

                • [Extract log] (ログの抽出) をクリックして、圧縮したログをローカルに保存します。

                Linux クライアント

                  Linux クライアントのログは、次の場所に保存されます。

                  ~/.local/share/Amazon Web Services/Amazon WorkSpaces/logs

                  Linux クライアントで高度なログ記録を有効にするには

                  1. Amazon WorkSpaces クライアントを閉じます。

                  2. ターミナルを開きます。

                  3. 次のコマンドを実行します。

                    /opt/workspacesclient/workspacesclient -l3

                  1. WorkSpaces クライアントを開きます。

                  2. クライアントアプリケーションの右上隅にある歯車アイコンを選択します。

                  3. [Advanced Settings (詳細設定)] を選択します。

                  4. [Enable Advanced Logging (高度なログ記録を有効にする)] チェックボックスをオンにします。

                  5. [Save] (保存) を選択します。

                  Windows クライアントのログは、次の場所に保存されています。

                  %LOCALAPPDATA%\Amazon Web Services\Amazon WorkSpaces\1.0\Logs

                  macOS クライアントのログは次の場所に保存されます。

                  ~/Library/Logs/Amazon Web Services/Amazon WorkSpaces/1.0

                  固有の問題のトラブルシューティング

                  以下の情報は、WorkSpaces に固有の問題のトラブルシューティングに役立ちます。

                  問題点

                  ユーザー名に無効な文字があるため Amazon Linux WorkSpace を作成できません

                  Amazon Linux WorkSpaces の場合、ユーザー名:

                  • 最大 20 文字を含めることができます。

                  • UTF-8 で表現可能な文字、スペース、および数字を含めることができます。

                  • 次の特殊文字を含めることができます: _.-#

                  • ダッシュ記号 (-) をユーザー名の 1 文字目として使用することはできません。

                  注記

                  これらの制限は、Windows WorkSpaces には適用されません。Windows WorkSpaces では、ユーザー名のすべての文字で @ および - 記号をサポートしています。

                  Amazon Linux WorkSpace のシェルを変更しましたが、PCoIP セッションをプロビジョニングできません

                  Linux WorkSpaces のデフォルトシェルを上書きするには、「Amazon Linux WorkSpaces のデフォルトシェルを上書きする」を参照してください。

                  Amazon Linux WorkSpaces が起動しない

                  2020 年 7 月 20 日以降、Amazon Linux WorkSpaces は新しいライセンス証明書を使用する予定です。これらの新しい証明書は、PCoIP エージェントの 2.14.1.1、2.14.7、2.14.9、および 20.10.6以降のバージョンでのみ互換性があります。

                  サポートされていないバージョンの PCoIP エージェントを使用している場合は、最新のバージョン (20.10.6) にアップグレードする必要があります。このバージョンでは、新しい証明書と互換性のある最新の修正とパフォーマンスが向上できます。7 月 20 日までにこれらのアップグレードを行わないと、Linux WorkSpaces のセッションプロビジョニングが失敗し、エンドユーザーは WorkSpaces に接続できなくなります。

                  PCoIP エージェントを最新バージョンにアップグレードするには

                  1. https://console.aws.amazon.com/workspaces/ で WorkSpaces コンソールを開きます。

                  2. ナビゲーションペインで [WorkSpaces] を選択します。

                  3. Linux WorkSpace を選択し、[アクション]、[WorkSpaces の再起動] の順に選択して再起動します。WorkSpace ステータスが STOPPED の場合は、[アクション]、[WorkSpaces を起動] の順に選択し、ステータスが AVAILABLE になるまで待ってから再起動する必要があります。

                  4. WorkSpace が再起動され、ステータスが AVAILABLE になったら、このアップグレードの実行中に WorkSpace のステータスを ADMIN_MAINTENANCE に変更することをお勧めします。完了したら、WorkSpace の状態を AVAILABLE に変更します。ADMIN_MAINTENANCE モードの詳細については、「手動メンテナンス」を参照してください。

                    WorkSpace のステータスを ADMIN_MAINTENANCE に変更するには、次の操作を行います。

                    1. WorkSpace を選択して、[Actions]、[Modify WorkSpace] の順に選択します。

                    2. [Modify State (状態の変更)] を選択します。

                    3. [想定される状態] で、[ADMIN_MAINTENANCE] を選択します。

                    4. [Modify] を選択します。

                  5. SSH 経由で Linux WorkSpace に接続します。詳細については、「Linux WorkSpaces の SSH 接続を有効にする」を参照してください。

                  6. PCoIP エージェントを更新するには、次のコマンドを実行します。

                    sudo yum --enablerepo=pcoip-stable install pcoip-agent-standard-20.10.6

                  7. エージェントのバージョンを確認し、更新が成功したことを確認するには、次のコマンドを実行します。

                    rpm -q pcoip-agent-standard

                    検証コマンドは、次の結果を生成する必要があります。

                    pcoip-agent-standard-20.10.6-1.el7.x86_64

                  8. WorkSpace から切断し、再度再起動します。

                  9. WorkSpace のステータスを ステップ 4 の ADMIN_MAINTENANCE に設定した場合は、ステップ 4 を繰り返し、意図した状態を AVAILABLE に設定します。

                  PCoIP エージェントをアップグレードしても Linux WorkSpace が起動しない場合は、AWS サポートにお問い合わせください。

                  接続したディレクトリの WorkSpaces の起動にたびたび失敗する

                  オンプレミスのディレクトリの 2 つの DNS サーバーまたはドメインコントローラーが、ディレクトリに接続したときに指定した各サブネットからアクセス可能であることを確認します。各サブネットでAmazon EC2 インスタンスを起動し、2 つの DNS サーバーの IP アドレスを使用してディレクトリにインスタンスを結合することで、この接続を確認できます。

                  内部エラーにより WorkSpaces の起動に失敗する

                  サブネットが、サブネット内で起動されたインスタンスに IPv6 アドレスを自動的に割り当てるように設定されているかどうかを確認します。この設定を確認するには、Amazon VPC コンソールを開き、サブネットを選択し、[Subnet Actions] を選択して、次に [Modify auto-assign IP settings] を選択します。この設定を有効にすると、Performance バンドルまたは Graphics バンドルを使用して WorkSpace を起動することはできません。代わりに、この設定を無効にし、インスタンスを起動するときに IPv6 アドレスを手動で指定します。

                  ディレクトリを登録しようとすると、登録が失敗し、ディレクトリが ERROR 状態のままになります

                  この問題は、マルチリージョンレプリケーション用に設定されている AWS Managed Microsoft AD ディレクトリを登録しようとする場合に発生することがあります。プライマリリージョンのディレクトリは Amazon WorkSpaces で使用するために正常に登録できますが、レプリケートされたリージョンにディレクトリを登録しようとすると失敗します。AWS Managed Microsoft AD を使用したマルチリージョンレプリケーションは、レプリケートされたリージョン内での Amazon WorkSpaces での使用についてサポートされていません。

                  ユーザーがインタラクティブなログオンバナーで Windows WorkSpace に接続できない

                  ログオンバナーを表示するためにインタラクティブなログオンメッセージが実装されると、これによりユーザーは自分の Windows WorkSpaces にアクセスできなくなります。現在、インタラクティブのログオンメッセージのグループポリシー設定は WorkSpaces でサポートされていません。Interactive logon: Message text for users attempting to log on グループポリシーが適用されていない組織単位 (OU) に WorkSpaces を移動します。

                  ユーザーが Windows WorkSpace に接続できない

                  ユーザーが Windows WorkSpace に接続しようとすると、次のエラーが表示されます。

                  "An error occurred while launching your WorkSpace. Please try again."

                  このエラーは、WorkSpace が PCoIP を使用して Windows デスクトップを読み込めない場合によく発生します。以下を確認してください。

                  • このメッセージは、Windows 向けの PCoIP Standard Agent サービスが実行されていない場合に表示されます。RDP を使用して接続し、サービスが実行されていること、サービスが自動的に開始されるように設定されていること、および管理インターフェイス (eth0) 経由で通信できることを確認します。

                  • PCoIP エージェントがアンインストールされた場合は、Amazon WorkSpaces コンソールから WorkSpace を再起動して、自動的に再インストールします。

                  • WorkSpaces セキュリティグループがアウトバウンドトラフィックを制限するように変更された場合も、長時間の遅延後にこのエラーが Amazon WorkSpaces クライアントで発生する可能性があります。送信トラフィックを制限すると、Windows はディレクトリコントローラーと通信してログインできなくなります。セキュリティグループで WorkSpaces がプライマリネットワークインターフェイスを介して必要なすべてのポートでディレクトリコントローラーと通信できることを確認します。

                  このエラーの別の原因として、ユーザー権利の割り当てグループポリシーに関連がある場合があります。次のグループポリシーが正しく設定されていない場合、ユーザーは自分の Windows WorkSpace にアクセスできなくなります。

                  コンピュータ構成\Windows Settings\Security Settings\Local Policies\User Rights Assignment

                  • 正しくないポリシー:

                    ポリシー: ネットワークからこのコンピュータにアクセスする

                    設定: ドメイン名\ドメインコンピュータ

                    優先される GPO: ファイルアクセスを許可する

                  • 正しいポリシー:

                    ポリシー: ネットワークからこのコンピュータにアクセスする

                    設定: ドメイン名\ドメインユーザー

                    優先される GPO: ファイルアクセスを許可する

                  注記

                  このポリシー設定は、ドメインコンピュータの代わりにドメインユーザーに適用する必要があります。

                  詳細については、Microsoft Windows のドキュメントの「ネットワークセキュリティポリシーの設定からこのコンピュータにアクセスする」および「セキュリティポリシー設定を構成する」を参照してください。

                  ユーザーが WorkSpaces Web Access から WorkSpaces にログオンしようとすると問題が発生する

                  Amazon WorkSpaces では、ユーザーが Web Access クライアントから正常にログオンできるように、専用のログオン画面設定を使用しています。

                  Web Access ユーザーが WorkSpaces にログオンできるようにするには、グループポリシー設定と 3 つのセキュリティポリシー設定を構成する必要があります。これらの設定が正しく設定されていないと、ログオン時間が長くなったり、WorkSpaces にログオンする際にブラックスクリーンがユーザーに表示されたりする場合があります。これらの設定を構成するには、「Amazon WorkSpaces Web Access を有効化および設定する」を参照してください。

                  重要

                  2020 年 10 月 1 日以降、お客様は Amazon WorkSpaces Web Access クライアントを使用して Windows 7 カスタム WorkSpaces または Windows 7 自分のライセンス使用 (BYOL) WorkSpaces に接続できなくなります。

                  Amazon WorkSpaces クライアントで、グレーの「ロード中...」画面がしばらく表示されてからログイン画面に戻る。他のエラーメッセージは表示されない。

                  通常、この動作が発生する場合、WorkSpaces クライアントはポート 443 経由で認証できますが、ポート 4172 (PCoIP) または 4195 (WSP) 経由でストリーミング接続を確立できないことを示しています。この状況は、ネットワークの前提条件が満たされていない場合に発生する可能性があります。クライアント側の問題により、クライアントでのネットワークチェックが失敗することがよくあります。どのヘルスチェックが失敗しているかを確認するには、ネットワークチェックアイコン (通常、2.0+ クライアントのログイン画面の右下隅に感嘆符が付いた赤い三角形、または 3.0+ クライアントの右上隅にあるネットワークアイコン Network icon ) を選択します。

                  注記

                  この問題の最も一般的な原因は、クライアント側のファイアウォールまたはプロキシがポート 4172 または 4195 (TCP および UDP) 経由のアクセスを防止していることです。このヘルスチェックが失敗した場合は、ローカルのファイアウォール設定を確認してください。

                  ネットワークチェックに合格した場合は、WorkSpace のネットワーク設定に問題がある可能性があります。たとえば、Windows ファイアウォールの規則により、管理インターフェイス上のポート UDP 4172 または 4195 がブロックされる場合があります。 リモートデスクトッププロトコル (RDP) クライアントを使用して WorkSpace に接続し、WorkSpace が必要なポート要件を満たしていることを確認します。

                  ユーザーに「WorkSpace Status: Unhealthy。We were unable to connect you to your WorkSpace。Please try again in a few minutes.」というメッセージが表示される。

                  このエラーは通常、SkyLightWorkSpacesConfigService サービスがヘルスチェックに応答していないことを示します。

                  WorkSpace を再起動または起動したばかりの場合は、数分待ってからもう一度お試しください。

                  WorkSpace がしばらくの間実行されていてもこのエラーが表示される場合は、RDP を使用して接続し、SkyLightWorkSpacesConfigService サービスについて次のことを確認します。

                  • 実行中である。

                  • 自動的に開始するように設定されている。

                  • 管理インターフェイス (eth0) を介して通信できる。

                  • サードパーティー製のウイルス対策ソフトウェアによってブロックされていない。

                  ユーザーに「This device is not authorized to access the WorkSpace。Please contact your administrator for assistance.」というメッセージが表示される。

                  このエラーは、IP アクセスコントロールグループが WorkSpace ディレクトリで設定されているが、クライアント IP アドレスがホワイトリストに登録されていないことを示します。

                  ディレクトリの設定を確認します。ユーザーが接続しているパブリック IP アドレスで WorkSpace へのアクセスが許可されていることを確認します。

                  ユーザーが WSP WorkSpace に接続しようとすると、「ネットワークがありません。ネットワーク接続が失われました ネットワーク接続を確認するか、管理者に問い合わせてください。」 WSP WorkSpace に接続しようとしたとき

                  このエラーが発生したが、ユーザーに接続の問題が発生していない場合は、ネットワークのファイアウォールでポート 4195 が開いていることを確認してください。WorkSpaces Streaming Protocol (WSP) を使用する WorkSpaces の場合、クライアントセッションのストリーミングに使用されるポートが 4172 から 4195 に変更されています。

                  WorkSpaces クライアントがネットワークエラーを返しますが、デバイス上の他のネットワーク対応アプリケーションは使用できます

                  WorkSpaces のクライアントアプリケーションは AWS クラウド内のリソースへのアクセスに依存しているため、最低 1 Mbps のダウンロード帯域幅を提供する接続が必要です。デバイスがネットワークに断続的に接続している場合、WorkSpaces クライアントアプリケーションがネットワークに関する問題を報告することがあります。

                  WorkSpaces は、2018 年 5 月の時点で Amazon Trust Services により発行されたデジタル証明書の使用を適用します。Amazon Trust Services は、WorkSpaces でサポートされているオペレーティングシステムですでに信頼されたルート CA になっています。オペレーティングシステムのルート CA リストが最新でない場合、デバイスは WorkSpaces に接続できず、クライアントからネットワークエラーが返されます。

                  証明書の失敗による接続の問題を認識するには

                  • PCoIP ゼロクライアント - 次のエラーメッセージが表示されます。

                    Failed to connect. The server provided a certificate that is invalid. See below for details:
- The supplied certificate is invalid due to timestamp
- The supplied certificate is not rooted in the devices local certificate store

                  • その他のクライアント – ヘルスチェックは、インターネットの赤い三角形の警告が表示されて失敗します。

                  Windows クライアントアプリケーション

                  証明書が失敗した場合は、次のいずれかの解決策を使用します。

                  解決策 1: クライアントアプリケーションを更新する

                  https://clients.amazonworkspaces.com/ から、最新の Windows クライアントアプリケーションをダウンロードしてインストールします。クライアントアプリケーションは、インストール中に、Amazon Trust Services によって発行された証明書をオペレーティングシステムが信頼するようにします。

                  解決策 2: Amazon Trust Services をローカルのルート CA リストに追加する

                  1. https://www.amazontrust.com/repository/ を開きます。

                  2. DER 形式の Starfield 証明書 (2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92) をダウンロードします。

                  3. Microsoft マネジメントコンソールを開きます。 (コマンドプロンプトから、mmc を実行します。)

                  4. [ファイル]、[スナップインの追加と削除]、[証明書]、[追加] の順に選択します。

                  5. [証明書スナップイン] ページで、[コンピュータ アカウント] を選択し、[次へ] を選択します。デフォルトの [ ローカル コンピュータ] のままにします。[Finish] (終了) を選択します。[OK] をクリックします。

                  6. [証明書 (ローカル コンピュータ)] を展開し、[信頼されたルート証明機関] を選択します。[アクション]、[すべてのタスク]、[インポート] の順に選択します。

                  7. ウィザードに従って、ダウンロードした証明書をインポートします。

                  8. WorkSpaces クライアントアプリケーションを終了し、再起動します。

                  解決策 3: グループポリシーを使用して Amazon Trust Services を信頼された CA としてデプロイする

                  グループポリシーを使用して、ドメインの信頼されたルート CA に Starfield 証明書を追加します。詳細については、「Use Policy to Distribute Certificates」を参照してください。

                  PCoIP ゼロクライアント

                  ファームウェアバージョン 6.0 以降を使用して WorkSpace に直接接続するには、Amazon Trust Services が発行した証明書をダウンロードしてインストールします。

                  Amazon Trust Services を信頼されたルート CA として追加するには

                  1. https://certs.secureserver.net/repository/ を開きます。

                  2. [Starfield Certificate Chain] で、サムプリント 14 65 FA 20 53 97 B8 76 FA A6 F0 A9 95 8E 55 90 E4 0F CC 7F AA 4F B7 C2 C8 67 75 21 FB 5F B6 58 の証明書をダウンロードします。

                  3. 証明書をゼロクライアントにアップロードします。詳細については、Teradici ドキュメントの「Uploading Certificates」を参照してください。

                  その他のクライアントアプリケーション

                  Amazon Trust Services から、Starfield 証明書 (2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92) を追加します。ルート CA の追加方法の詳細については、以下のドキュメントを参照してください。

                  WorkSpace ユーザーに、「デバイスは登録サービスに接続できません。ネットワーク設定を確認してください」というエラーが表示されます。

                  登録サービスでエラーが発生すると、[Connection Health Check] ページに次のメッセージが WorkSpace ユーザーに表示されます: 「ご使用のデバイスは WorkSpaces 登録サービスに接続できません。このデバイスを WorkSpaces に登録することはできません。ネットワーク設定を確認してください」というエラーメッセージが表示されることがあります。

                  このエラーは、WorkSpaces クライアントアプリケーションが登録サービスにアクセスできない場合に発生します。通常、これは、WorkSpaces ディレクトリが削除された場合に発生します。このエラーを解決するには、登録コードが有効であり、AWS クラウドで実行中のディレクトリに対応していることを確認します。

                  PCoIP ゼロクライアントユーザーに、「指定された証明書はタイムスタンプのために無効です」というエラーが表示される

                  Teradici でネットワークタイムプロトコル (NTP) が有効になっていない場合、PCoIP ゼロクライアントユーザーに証明書の失敗エラーが表示されることがあります。NTP を設定するには、「WorkSpaces の PCoIP ゼロクライアントをセットアップする」を参照してください。

                  PCoIP ゼロクライアントで USB プリンタと他の USB 周辺機器が動作しない

                  PCoIP エージェントのバージョン 20.10.4 以降、Amazon WorkSpaces は、Windows レジストリを介して USB リダイレクトをデフォルトで無効にします。このレジストリ設定は、ユーザーが PCoIP ゼロクライアントデバイスを使用して WorkSpaces に接続する場合の USB 周辺機器の動作に影響します。

                  WorkSpaces でバージョン 20.10.4 以降の PCoIP エージェントを使用している場合は、USB リダイレクトを有効にしない限り、USB 周辺デバイスは PCoIP ゼロクライアントデバイスで動作しません。

                  注記

                  32 ビット仮想プリンタードライバーを使用している場合は、それらのドライバーを 64 ビット版に更新する必要があります。

                  PCoIP ゼロクライアントデバイスの USB リダイレクトを有効にするには

                  グループポリシーを介してこれらのレジストリの変更をWorkSpacesにプッシュすることをお勧めします。詳細については、「Teradiciのマニュアル」からエージェントの設定および環境の設定を参照してください。

                  1. 次のレジストリキーの値を 1 (有効) に設定します。

                    KeyPath =HKEY_LOCAL_MACHINE\ SOFTWARE\ ソフトウェア\ ポリシー\ Teradici\ PCoIP\ pcoip_admin

                    KeyName = pcoip.enable_usb

                    KeyType = DWORD

                    KeyValue = 1

                  2. 次のレジストリキーの値を 1 (有効) に設定します。

                    KeyPath =HKEY_LOCAL_MACHINE\ SOWARE\ ソフトウェア\ ポリシー\ Teradici\ PCoIP\ pcoIP\ pcoip_admin

                    KeyName = pcoip.enable_usb

                    KeyType = DWORD

                    KeyValue = 1

                  3. まだ行っていない場合は、WorkSpace からログアウトしてから、再度ログインします。これで USB デバイスが動作するはずです。

                  ユーザーが Windows または macOS クライアントアプリケーションの更新をスキップしても、最新バージョンをインストールするように求められない

                  ユーザーが Amazon WorkSpaces Windows クライアントアプリケーションの更新をスキップすると、SkipThisVersion レジストリキーが設定されます。そのため、新しいバージョンのクライアントがリリースされたときに、クライアントを更新するように求められなくなります。最新バージョンに更新するにはAmazon WorkSpacesユーザーガイド の「WorkSpaces Windows クライアントアプリケーションを新しいバージョンに更新する」の説明に従って、レジストリを編集できます。以下の PowerShell コマンドを実行することもできます。

                  Remove-ItemProperty -Path "HKCU:\Software\Amazon Web Services. LLC\Amazon WorkSpaces\WinSparkle" -Name "SkipThisVersion"

                  ユーザーが Amazon WorkSpaces MacOS クライアントアプリケーションの更新をスキップすると、SUSkippedVersion 設定が定義されます。そのため、クライアントの新しいバージョンがリリースされたときに、クライアントを更新するように求められなくなります。最新バージョンに更新するには、Amazon WorkSpaces ユーザーガイド の「WorkSpaces macOS クライアントアプリケーションを新しいバージョンに更新する」の説明に従って、この設定をリセットできます。

                  ユーザーが Chromebook に Android クライアントアプリケーションをインストールできない

                  バージョン 2.4.13 は、Amazon WorkSpaces Chromebook クライアントアプリケーションの最終リリースです。Google は Chrome アプリのサポートを段階的に廃止するため、WorkSpaces Chromebook クライアントアプリケーションはこれ以上更新されず、その使用はサポートされません。

                  Android アプリケーションのインストールに対応している Chromebook では、代わりに WorkSpaces Android クライアントアプリケーションを使用することをお勧めします。

                  場合によっては、ユーザーの Chromebook で Android アプリケーションのインストールを有効にする必要があります。詳細については、「Chromebook 用の Android のセットアップ」を参照してください。

                  ユーザーに招待 E メールまたはパスワードリセット E メールが届かない

                  AD Connector または信頼できるドメインを使用して作成された WorkSpaces のウェルカム E メールまたはパスワードリセット E メールは、ユーザーに自動的には届きません。また、ユーザーが既に Active Directory に存在する場合も、招待メールは自動的に送信されません。

                  これらのユーザーに招待 E メールを手動で送信するには、「招待 E メールの送信」を参照してください 。

                  ユーザーパスワードをリセットするには、「WorkSpaces の Active Directory 管理ツールを設定する」を参照してください。

                  クライアントのログイン画面でユーザーに [パスワードを忘れた場合] が表示されません。

                  AD Connector または信頼できるドメインを使用している場合、ユーザーは自分のパスワードをリセットできません。([パスワードを忘れた場合] オプションは、WorkSpaces クライアントアプリケーションのログイン画面では使用できません。) ユーザーパスワードをリセットする方法については、WorkSpaces の Active Directory 管理ツールを設定する を参照してください。

                  Windows WorkSpace にアプリケーションをインストールしようとすると、「システム管理者がポリシーを設定してこのインストールを禁止しています」というメッセージが表示される

                  この問題に対処するには、Windows インストーラのグループポリシー設定を変更します。ディレクトリ内の複数の WorkSpaces にこのポリシーをデプロイするには、ドメイン結合された EC2 インスタンスから WorkSpaces 組織単位 (OU) にリンクされたグループポリシーオブジェクトに、この設定を適用します。AD Connector を使用している場合は、ドメインコントローラーからこれらの変更を行うことができます。Active Directory 管理ツールを使用してグループポリシーオブジェクトを操作する方法の詳細については、AWS Directory Service 管理ガイドの「Active Directory 管理ツールのインストール」を参照してください。

                  次の手順は、WorkSpaces グループポリシーオブジェクトの Windows インストーラ設定を構成する方法を示しています。

                  1. ドメインに WorkSpaces グループポリシー管理用テンプレート がインストールされていることを確認します。

                  2. Windows WorkSpace クライアントでグループポリシーの管理ツールを開き、WorkSpaces コンピュータアカウントの WorkSpaces グループポリシーオブジェクトに移動して選択します。メインメニューの [Action]、[Edit] を選択します。

                  3. グループポリシー管理エディタで、[Computer Configuration (コンピュータの構成)]、[Policies (ポリシー)]、[Administrative Templates (管理用テンプレート)]、[Classic Administrative Templates (従来の管理用テンプレート)]、[Windows Components (Windows コンポーネント)]、[Windows Installer (Windows インストーラ)] の順に選択します。

                  4. [Turn Off Windows Installer (Windows インストーラをオフ)] 設定を開きます。

                  5. [Turn Off Windows Installer (Windows インストーラをオフ)] ダイアログボックスで、[Not Configured (未構成)] を [Enabled (有効)] に変更し、[Disable Windows Installer (Windows インストーラを無効にする] を [Never (しない)] に設定します。

                  6. [OK] をクリックします。

                  7. グループポリシーの変更を適用するには、次のいずれかを実行します。

                    • WorkSpace を再起動します (WorkSpaces コンソールで、WorkSpace を選択し、[Actions] (アクション)、[Reboot WorkSpaces] (WorkSpaces の再起動) を選択します)。

                    • 管理コマンドプロンプトから、gpupdate /force と入力します。

                  ディレクトリのいずれの WorkSpaces もインターネットに接続できない

                  WorkSpaces はデフォルトではインターネットと通信することができません。明示的にインターネットアクセスを許可する必要があります。詳細については、「WorkSpace からのインターネットアクセスを提供する」を参照してください。

                  WorkSpace がインターネットにアクセスできなくなった

                  WorkSpace がインターネットにアクセスできなくなり、RDP を使用して WorkSpace に接続できない場合は、おそらく WorkSpace のパブリック IP アドレスが失われたことが原因と考えられます。ディレクトリレベルで Elastic IP アドレスの自動割り当てを有効にしている場合、(Amazon が提供するプールからの) Elastic IP アドレスは、起動時に WorkSpace に割り当てられます。ただし、所有している Elastic IP アドレスを WorkSpace に関連付けた後、その Elastic IP アドレスと WorkSpace との関連付けを解除すると、WorkSpace はパブリック IP アドレスを失い、Amazon が提供するプールから新しいアドレスを自動的に取得しません。

                  Amazon が提供するプールからの新しいパブリック IP アドレスを WorkSpace に関連付けるには、WorkSpace を再構築する必要があります。WorkSpace を再構築しない場合は、所有する別の Elastic IP アドレスを WorkSpace に関連付ける必要があります。

                  WorkSpace の起動後は、WorkSpace の Elastic Network Interface を変更しないことをお勧めします。Elastic IP アドレスが WorkSpace に割り当てられると、WorkSpace は同じパブリック IP アドレスを保持します (WorkSpace が再構築された場合を除く。その場合は新しいパブリック IP アドレスを取得します)。

                  オンプレミスディレクトリに接続しようとすると、「DNS unavailable」というエラーが表示される

                  オンプレミスディレクトリに接続するときに、次のようなエラーメッセージが表示されます。

                  DNS unavailable (TCP port 53) for IP: dns-ip-address

                  AD Connectorは、ポート 53 上で TCP および UDP によってオンプレミス DNS サーバーと通信できる必要があります。セキュリティグループおよびオンプレミスのファイアウォールが、このポート上の TCP および UDP 通信を許可していることを確認します。

                  オンプレミスディレクトリに接続しようとすると、「Connectivity issues detected」というエラーが表示される

                  オンプレミスディレクトリに接続するときに、次のようなエラーメッセージが表示されます。

                  Connectivity issues detected: LDAP unavailable (TCP port 389) for IP: ip-address
Kerberos/authentication unavailable (TCP port 88) for IP: ip-address
Please ensure that the listed ports are available and retry the operation.

                  AD Connectorは、以下のポート上で TCP および UDP によってオンプレミスドメインコントローラーと通信できる必要があります。セキュリティグループおよびオンプレミスのファイアウォールが、これらのポート上の TCP および UDP 通信を許可していることを確認します。

                  • 88 (Kerberos)

                  • 389 (LDAP)

                  オンプレミスディレクトリに接続しようとすると、「SRV record」というエラーが表示される

                  オンプレミスディレクトリに接続するときに、次のいずれかまたは複数のエラーメッセージが表示されます。

                  SRV record for LDAP does not exist for IP: dns-ip-address

SRV record for Kerberos does not exist for IP: dns-ip-address

                  AD Connector は、ディレクトリに接続するときに、_ldap._tcp.dns-domain-name および _kerberos._tcp.dns-domain-name SRV レコードを取得する必要があります。ディレクトリに接続するときに、サービスが指定された DNS サーバーからこれらのレコードを取得できない場合、このエラーが表示されます。DNS サーバーにこれらの SRV レコードが含まれていることを確認します。詳細については、Microsoft TechNet の「SRV リソースレコード」を参照してください。

                  Windows WorkSpace をアイドル状態のままにすると、スリープ状態になる

                  この問題を解決するには、WorkSpace に接続し、次の手順を使用して電源プランを [High performance (高パフォーマンス)] に変更します。

                  1. WorkSpace から [コントロールパネル] を開き、[ハードウェア] もしくは [ハードウェアとサウンド] を選択します (Windows のバージョンによっては、名前が異なる場合があります)。

                  2. [Power Options (電源オプション)] で [Choose a power plan (電源プランを選択)] を選択します。

                  3. [Choose or customize a power plan] (電力プランの選択あるいはカスタマイズ) ペインで [High performance] (高パフォーマンス) 電力プランを選択し、[Change plan settings] (プラン設定の変更)を選択します。

                    • オプションで、[High performance](高パフォーマンス) 電力プランの選択が無効になっている場合は、[現在利用できない設定を変更する] を選択してから、[高パフォーマンス] 電力プランを選択します。

                    • そのファイルに[高パフォーマンス]プランが非表示になっている場合は、[追加プランを表示]の右側にある矢印を選択して表示するか、もしくは左のナビゲーションで[電源プランを作成する]から[高パフォーマンス]を選択し、電源プランに名前を付けたうえで、[次へ] を選択します。

                  4. [プランの設定を変更する:高パフォーマンス]ページでは、[ディスプレイをオフにする]および（利用可能な場合）[コンピュータをスリープ状態にする]などについて[Never](決してしない）を選択してあることを確認してください。

                  5. 高パフォーマンスプランに変更した場合は、[変更の保存] を選択します。(または新しいプランを作成するのであれば[作成]を選択します)。

                  上記の手順で問題を解決できない場合は、次の操作を行います。

                  1. WorkSpace から [コントロールパネル] を開き、[ハードウェア] もしくは [ハードウェアとサウンド] を選択します (Windows のバージョンによっては、名前が異なる場合があります)。

                  2. [Power Options (電源オプション)] で [Choose a power plan (電源プランを選択)] を選択します。

                  3. [Choose or customize a power plan] (電力プランの選択あるいはカスタマイズ) ペインで、[High performance] (高パフォーマンス) 電源プランの右側にある [Change plan settings] (プラン設定の変更) リンクを選択して、[Change advanced power settings] (高度な電源設定の変更) リンクを選択します。

                  4. 設定リストの [Power Options (電源オプション)] ダイアログボックスで、[Hard disk (ハードディスク)] の左側にあるプラス記号を選択して関連する設定を表示します。

                  5. [Plugged in (プラグイン)] の [Turn off hard disk after (経過後にハードディスクを切断する)] 値が、[On battery (バッテリー使用時)] よりも大きいことを確認します (デフォルト値は 20 分)。

                  6. [PCI Express] の左側にあるプラス記号を選択し、[Link State Power Management (ステート電力管理リンク)] でも同様の選択を行います。

                  7. [Link State Power Management (ステート電力管理リンク)] 設定が [オフ] であることを確認します。

                  8. [OK] (あるいは、設定を変更した場合には [適用]) を選択して、ダイアログボックスを閉じます。

                  9. 設定を変更した場合には、[Change settings for the plan (プランの設定変更)] ペインで [変更の保存] を選択します。

                  WorkSpace の一部のステータスに UNHEALTHY と表示されます

                  WorkSpaces サービスは定期的にステータスリクエストを WorkSpace に送信します。このリクエストに応答しない WorkSpace は、"UNHEALTHY" と表示されます。この問題に対する一般的な原因は次のとおりです。

                  • WorkSpace のアプリケーションがネットワークポートをブロックして、WorkSpace によるステータスリクエストへの応答を妨げています。

                  • 高 CPU 使用率は、WorkSpace によるステータスリクエストへの応答を一時的に防ぐことがあります。

                  • WorkSpace のコンピュータ名が変更された場合。これにより、 WorkSpaces と WorkSpace の間に確立されるべき安全な交信が妨げられます。

                  次の方法を使用して、この状況を修正するよう試みることができます。

                  • WorkSpaces コンソールから WorkSpace を再起動します。

                  • トラブルシューティングの目的でのみ使用する必要がある次の手順を使用して、不具合のある WorkSpace に接続します。

                    1. 不具合のある WorkSpace と同じディレクトリ内の動作している WorkSpace に接続します。

                    2. 動作している WorkSpace から、Remote Desktop Protocol（RDP）を使って、不具合のある WorkSpace の IP アドレスから不具合のある WorkSpace に接続します。問題の規模により、不具合のある WorkSpace に接続できない場合もあります。

                    3. 不具合のある WorkSpace で最低限のポート要件が満たされていることを確認します。

                  • SkylightWorkspacesConfigService サービスがヘルスチェックに応答できることを確認します。この問題のトラブルシューティングについては、「ユーザーに「WorkSpace Status: Unhealthy。We were unable to connect you to your WorkSpace。Please try again in a few minutes.」というメッセージが表示される。」を参照してください。

                  • WorkSpaces コンソールから WorkSpace を再構築します。WorkSpace の再構築ではデータ損失が発生する可能性があるため、その他のすべての問題対処方法が失敗した場合にのみ、このオプションを実行してください。

                  WorkSpace が予期せずクラッシュまたは再起動する

                  PCoIP に対応した WorkSpace が繰り返しクラッシュまたは再起動し、エラーログやクラッシュダンプで spacedeskHookKmode.sys または spacedeskHookUmode.dll の問題が示されている場合、あるいは次のエラーメッセージが表示される場合は、WorkSpace へのウェブアクセスの無効化が必要になる場合があります。

                  The kernel power manager has initiated a shutdown transition.
Shutdown reason: Kernel API
                  The computer has rebooted from a bugcheck.
                  注記

                  • これらのトラブルシューティングステップは、WorkSpaces Streaming Protocol (WSP) に対応した WorkSpaces には適用されません。これらは、PCoIP に対応した WorkSpaces にのみ適用されます。

                  • Web Access を無効にするのは、ユーザーに Web Access の使用を許可しない場合だけです。

                  WorkSpace へのウェブアクセスを無効にするには、グループポリシーを設定し、2 つのレジストリ設定を変更する必要があります。Active Directory 管理ツールを使用して グループポリシーオブジェクトを操作する方法の詳細については、AWS Directory Service 管理ガイドの 「Active Directory 管理ツールのインストール」を参照してください。

                  ステップ 1: ディレクトリレベルでウェブアクセスを無効にするグループポリシーを設定する

                  STXHD Hosted Application Service が存在する必要があるため、ドメインコントローラーではなく PCoIP WorkSpace からこれらの変更を行う必要があります。

                  1. WorkSpaces が使用するセキュリティグループを編集して RDP 接続を許可します。詳細については、「RDP を使用して WorkSpace に接続するにはどうすればよいですか?」をご参照ください。

                  2. RDP を使用して WorkSpace に接続します。ドメインで GPO を作成および変更するアクセス許可を持つ AWS アカウントを使用していることを確認します。WorkSpace ディレクトリに Simple AD を使用している場合、ユーザー名は Administrator です。Microsoft AD を使用している場合、管理者のユーザー名は Admin です。

                  3. Active Directory Administration Tools (RSAT) をインストールして、グループポリシー管理エディタツールを取得します。これらのツールをインストールするには、AWS Directory Service 管理ガイド の「Active Directory 管理ツールのインストール」をご参照ください。

                    管理者として次の Windows PowerShell コマンドを実行することによって、これらのツールをインストールすることもできます。

                    Install-WindowsFeature -Name GPMC,RSAT-AD-PowerShell,RSAT-AD-AdminCenter,RSAT-ADDS-Tools,RSAT-DNS-Server

                  4. グループポリシー管理エディタ (gpmc.msc) を開き、ディレクトリのドメインコントローラーレベルでグループポリシーオブジェクト (GPO) ポリシーを見つけます。

                    注記

                    WorkSpaces をバックアップするドメインが AWS Managed Microsoft AD ディレクトリの場合、デフォルトのドメインポリシーを使用して GPO を作成することはできません。代わりに、委任された権限を持つドメインコンテナの下に GPO を作成してリンクする必要があります。

                    AWS Managed Microsoft AD を使用してディレクトリを作成すると、AWS Directory Service は、ドメインルートの下に yourdomainname 組織単位 (OU) を作成します。この OU の名前は、ディレクトリの作成時に入力した NetBIOS 名に基づく名前です。NetBIOS 名を指定しなかった場合、デフォルトでは、Directory DNS 名の最初の部分が使用されます (例えば、corp.example.com の場合、NetBIOS 名は corp となります)。

                    GPO を作成するには、デフォルトのドメインポリシーを選択する代わりに、yourdomainname OU (またはその下にある任意の OU) を選択し、コンテキスト (右クリック) メニューを開き、[Create a GPO in this domain, and Link it here] (このドメインに GPO を作成し、ここにリンクする) を選択します。

                    yourdomainname OU の詳細については、AWS Directory Service 管理ガイドの作成されるものを参照してください。

                  5. [Action]、[Edit] の順に選択します。

                  6. 次の設定に移動します。

                    コンピュータの設定\ポリシー\Windows の設定\セキュリティの設定\システムサービス\STXHD ホストアプリケーションサービス

                  7. [STXHD Hosted Application Service Properties] ダイアログボックスの [Security Policy Setting] タブで、[Define this policy setting] チェックボックスをオンにします。

                  8. [Select Service Startup Mode (サービススタートアップモードの選択)] で、[Disabled] を選択します。

                  9. [OK] をクリックします。

                  10. レジストリの編集が終了するまで (ステップ 2)、マシンが再起動しないようにします。

                  ステップ 2: レジストリを編集してウェブアクセスを無効にする

                  GPO を介してこれらのレジストリの変更をプッシュすることをお勧めします。

                  1. 次のレジストリキーの値を 1 (有効) に設定します。

                    KeyPath = HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\WorkSpacesConfig\update-webaccess.ps1

                    KeyName = RebootCount

                    KeyType = DWORD

                    KeyValue = 1

                  2. 次のレジストリキーの値を 4 (無効) に設定します。

                    KeyPath = HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\spacedeskHookKmode

                    KeyName = Start

                    KeyType = DWORD

                    KeyValue = 4

                  3. マシンを再起動します。

                  同じユーザー名に対応する複数の WorkSpace があるが、そのユーザーはいずれかの WorkSpaces にしかログインできない

                  最初に WorkSpace を削除せずに Active Directory (AD) でユーザーを削除してから、そのユーザーを Active Directory に再度追加し、そのユーザーの新しい WorkSpace を作成すると、同じユーザー名に対応する 2 つの WorkSpaces が同じディレクトリに作成されます。ただし、そのユーザーが元の WorkSpace に接続しようとすると、以下のエラーが表示されます。

                  "Unrecognized user. No WorkSpace found under your username. Contact your administrator to request one."

                  さらに、Amazon WorkSpaces コンソールでそのユーザー名を検索すると、両方の WorkSpaces がまだ存在していても、新しい WorkSpace のみが返されます (ユーザー名の代わりに WorkSpace ID を検索すると、元の WorkSpace を見つけることができます)。

                  この動作は、最初に WorkSpace を削除せずに Active Directory でユーザーの名前を変更した場合にも見られることがあります。その場合、ユーザー名を元のユーザー名に戻し、そのユーザーの新しい WorkSpace を作成すると、同じユーザー名に対応する 2 つの WorkSpaces が同じディレクトリに作成されます。

                  この問題は、Active Directory がユーザー名ではなくユーザーのセキュリティ識別子 (SID) を使用してユーザーを一意に識別するために発生します。ユーザーを削除して Active Directory で再作成すると、ユーザー名が同じであっても、そのユーザーに新しい SID が割り当てられます。ユーザー名の検索中に、Amazon WorkSpaces コンソールは SID を使用して Active Directory で一致する名前を見つけます。Amazon WorkSpaces クライアントも SID を使用して、WorkSpaces に接続しようとするユーザーを識別します。

                  この問題を解決するには、以下のいずれかの操作を行います。

                  • ユーザーが削除されて Active Directory で再作成されたためにこの問題が発生した場合は、Active Directory のごみ箱機能を有効にすると、削除された元のユーザーオブジェクトを復元できる可能性があります。元のユーザーオブジェクトを復元できる場合は、そのユーザーが元の WorkSpace に接続できることを確認してください。確認できれば、ユーザーデータを手動でバックアップして新しい WorkSpace から元の WorkSpace に転送した後、新しい WorkSpace を削除できます (必要に応じて)。

                  • 元のユーザーオブジェクトを復元できない場合は、そのユーザーの元の WorkSpace を削除します。そのユーザーは、代わりに新しい WorkSpace に接続し、その WorkSpace を使用できるようになります。必ずユーザーデータを手動でバックアップし、元の WorkSpace から新しい WorkSpace に転送してください。

                    警告

                    WorkSpace の削除は永続的なアクションであり、元に戻すことはできません。WorkSpace ユーザーのデータは保持されず、破棄されます。ユーザーデータのバックアップに関するヘルプについては、AWS Support にお問い合わせください。

                  Amazon WorkSpaces で Docker の使用がうまくいかない

                  Windows WorkSpaces

                  ネストされた仮想化 (Docker の使用を含む) は、Windows WorkSpaces ではサポートされていません。詳細については、「Docker ドキュメント」を参照してください。

                  Linux WorkSpaces

                  Linux WorkSpaces で Docker を使用するには、Docker によって使用される CIDR ブロックが、WorkSpace に関連付けられている 2 つの Elastic Network Interface (ENI) で使用される CIDR ブロックと重複しないようにしてください。Linux WorkSpaces で Docker を使用する際に問題が発生した場合、Docker にお問い合わせください。

                  一部の API コールで ThrottlingException エラーが表示される

                  WorkSpaces API コールのデフォルトの許容レートは、1 秒あたり 2 回の API コールの一定のレートで、許可される最大「バースト」レートは 1 秒あたり 5 回の API コールです。次の表は、API リクエストのバーストレート制限がどのように機能するかを示しています。

                  秒 送信されたリクエストの数 許可されたネットリクエスト 詳細

                  1

                  0

                  5

                  最初の 1 秒（1 秒目）の間は、1 秒あたり最大 5 回の呼び出しのバーストレートまで、5 つのリクエストが許可されます。

                  2

                  2

                  5

                  1 秒目で発行されたコール数が 2 つ以下であるため、5 つのコールのフルバーストキャパシティーを引き続き利用できます。

                  3

                  5

                  5

                  2 秒目で発行された呼び出しは 2 つだけであるため、5 つの呼び出しのフルバーストキャパシティーを引き続き利用できます。

                  4

                  2

                  2

                  バーストキャパシティーが 3 秒目にいっぱいまで使用されたため、1 秒あたり 2 回の呼び出しの一定のレートのみが使用できます。

                  5

                  3

                  2

                  バースト容量が残っていないため、現時点では許可される呼び出しは 2 つだけです。これは、3 つの API コールの 1 つが調整されることを意味します。1 つの調整された呼び出しは、短い遅延後に応答します。

                  6

                  0

                  1

                  5 秒目からの呼び出しの 1 つが 6 秒目で再試行されるため、6 秒目の追加の呼び出しは 1 つだけです。これは、1 秒あたり 2 回の呼び出しが一定のレート制限であるためです。

                  7

                  0

                  3

                  キューに調整された API コールがないため、レート制限はバーストレート制限が 5 回まで引き上げられます。

                  8

                  0

                  5

                  7 秒目には呼び出しが発行されなかったため、リクエストの最大数が許可されます。

                  9

                  0

                  5

                  8 秒目には呼び出しが発行されませんが、レート制限は 5 つを超えることはありません。

                  WorkSpace をバックグラウンドで実行させておくと、接続が何度も切断される

                  Mac ユーザーの場合は、Power Nap 機能がオンになっていないかどうかをチェックしてください。オンになっている場合は、オフにします。Power Nap をオフにするには、ターミナルを開いて、以下のコマンドを実行します。

                  defaults write com.amazon.workspaces NSAppSleepDisabled -bool YES

                  SAML 2.0 フェデレーションが動作していません。ユーザーには、WorkSpaces デスクトップをストリーミングする権限がありません。

                  このエラーは、SAML 2.0 フェデレーションの IAM ロール用に埋め込まれているインラインポリシーに、ディレクトリの Amazon リソースネーム (ARN) からストリーミングするためのアクセス許可が含まれていないことが原因で発生する可能性があります。この IAM ロールは、WorkSpaces ディレクトリにアクセスしているフェデレーションユーザーによって引き受けられます。ロールのアクセス許可を編集してディレクトリ ARN を含め、ユーザーがディレクトリに WorkSpace を持っていることを確認します。詳細については、「SAML 2.0 認証」および「AWS での SAML 2.0 フェデレーションのトラブルシューティング」を参照してください。

                  ユーザーが 60 分ごとに WorkSpaces セッションから切断されます。

                  WorkSpaces に SAML 2.0 認証を設定している場合、ID プロバイダー (IdP) によっては、認証レスポンスの一部として IdP が SAML 属性として AWS に渡す情報を設定する必要が生じる場合があります。これには、[Attribute] 要素の設定として、SessionDuration 属性を https://aws.amazon.com/SAML/Attributes/SessionDuration に設定することが含まれます。

                  SessionDuration は、再認証が必要となるまでに、ユーザーのフェデレーティッドストリーミングセッションをアクティブにしておくことができる最大時間を指定します。SessionDuration はオプションの属性ですが、これを SAML 認証レスポンスに含めることをお勧めします。この属性を指定しない場合、セッション時間はデフォルトで 60 分に設定されます。

                  この問題を解決するには、SAML 認証レスポンスに SessionDuration 値を含めるように IdP を設定し、必要に応じた値を設定します。詳細については、「ステップ 5: SAML 認証レスポンスのアサーションを作成する」を参照してください。

                  ユーザーが SAML 2.0 ID プロバイダー (IdP) 主導のフローを使用してフェデレートすると、ユーザーにリダイレクト URI エラーが発生します。または、IdP にフェデレートした後、クライアントからサインインを試みるたびに、WorkSpaces クライアントアプリケーションの追加インスタンスが開始されます。

                  このエラーが発生するのは、リレーステートの URL が正しい形式でないためです。IdP フェデレーションのセットアップでリレーステートが正しいこと、および WorkSpaces ディレクトリプロパティで、ユーザーアクセス URL とリレーステートパラメータ名が IdP フェデレーションに対して正しく設定されていることを確認します。それらが有効で、問題が解決しない場合は、AWS サポートにお問い合わせください。詳細については、「SAML のセットアップ」を参照してください。

                  ユーザーが IdP にフェデレートした後に WorkSpace Spaces クライアントアプリケーションにサインインしようとすると、「Something went wrong: An error occurred while launching your WorkSpace」(問題が発生しました: WorkSpace の起動中にエラーが発生しました) というメッセージが表示されます。

                  フェデレーションの SAML 2.0 アサーションを確認します。[SAML Subject NameID] (SAML サブジェクト名 ID) 値は WorkSpaces ユーザー名と一致する必要があります。通常は、Active Directory ユーザーの sAMAccountName 属性と同じです。さらに、PrincipalTag:Email 属性が https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email に設定された [Attribute] (属性) 要素は、WorkSpaces ディレクトリで定義されている WorkSpaces ユーザーの E メールアドレスと一致する必要があります。詳細については、「SAML のセットアップ」を参照してください。

                  ユーザーが IdP にフェデレートした後に WorkSpaces クライアントアプリケーションにサインインしようとすると、「Unable to validate tags」(タグを検証できません) というメッセージが表示されます。

                  https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email など、フェデレーションの SAML 2.0 アサーションの PrincipalTag 属性値を確認します。タグ値には、_ . : / = + - @ の各文字、英数字、およびスペースの組み合わせを含めることができます。詳細については、「IAM および AWS STS でのタグ付けの規則」を参照してください。

                  「The client and the server cannot communicate, because they do not possess a common algorithm」(クライアントとサーバーは共通のアルゴリズムを所有していないため、通信できません) というメッセージがユーザーに表示されます。

                  この問題は、TLS 1.2 を有効にしていない場合に発生する可能性があります。

                  マイクまたはウェブカメラが Windows WorkSpaces で動作しません。

                  [Start] (スタート) メニューを開いてプライバシー設定を確認してください

                  • [Start] (スタート) > [Settings] (設定) > [Privacy] (プライバシー) > [Camera] (カメラ)

                  • [Start] (スタート) > [Settings] (設定)> [Privacy] (プライバシー) > [Microphone] (マイク)

                  オフになっている場合は、オンにします。

                  または、WorkSpaces 管理者は、必要に応じてグループポリシーオブジェクト (GPO) を作成して、マイクやウェブカメラを有効にできます。

                  私のユーザーは証明書ベースの認証を使用してログインできず、デスクトップセッションに接続するときに WorkSpaces クライアントまたは Windows ログオン画面でパスワードの入力を求められます。

                  このセッションでは、証明書ベースの認証が失敗しました。問題が続く場合、証明書ベースの認証が失敗するのは、次のいずれかの問題が原因である可能性があります。

                  • WorkSpaces またはクライアントがサポートされていません。証明書ベースの認証は、最新の WorkSpaces Windows クライアントアプリケーションを使用している WorkSpaces Streaming Protocol (WSP) バンドルの Windows WorkSpaces でサポートされます。

                  • WorkSpaces ディレクトリで証明書ベースの認証を有効にしたら、WorkSpaces を再起動する必要があります。

                  • WorkSpaces が AWS Private CA と通信できなかったか、AWS Private CA が証明書を発行しませんでした。AWS CloudTrail で証明書が発行されたかどうかを確認してください。詳細については、「証明書ベースの認証の管理」を参照してください。

                  • ドメインコントローラーには、スマートカードログオン用のドメインコントローラー証明書がないか、有効期限が切れています。詳細については、「前提条件」のステップ 7「Configure domain controllers with a domain controller certificate to authenticate smart card users」(ドメインコントローラー証明書を使用して、スマートカードユーザーを認証するようにドメインコントローラーを設定する) を参照してください。

                  • 証明書が信頼されていません。詳細については、「前提条件」のステップ 7「Publish the CA to Active Directory」(CA を Active Directory に公開する) を参照してください。

                  • キャッシュに証明書はありますが、証明書を無効にしたユーザーの属性が変更されています。証明書の有効期限 (24 時間) 前に AWS Supportに連絡してキャッシュをクリアしてください。詳細については、AWS Supportセンターを参照してください。

                  • SAML 属性 UserPrincipalName の userPrincipalName 形式が正しくフォーマットされていないか、ユーザーの実際のドメインに解決されていません。詳細については、「前提条件」のステップ 1 を参照してください。

                  • SAML アサーションの ObjectSid 属性 (オプション) が、SAML_Subject NameID で指定したユーザーの Active Directory セキュリティ識別子 (SID) と一致しません。SAML フェデレーションの属性マッピングが正しいこと、および SAML ID プロバイダーが Active Directory ユーザーの SID 属性を同期していることを確認してください。

                  • スマートカードログオンのデフォルトの Active Directory 設定を変更したり、スマートカードがスマートカードリーダーから取り外された場合にアクションを実行したりするグループポリシー設定があります。これらの設定により、上記のエラー以外にも予期しない動作が発生する可能性があります。証明書ベースの認証では、仮想スマートカードがインスタンスのオペレーティングシステムに提示され、ログオンの完了後にそれが削除されます。「Primary Group Policy settings for smart cards」(スマートカードのプライマリグループポリシー設定) と「Additional smart card Group Policy settings and registry keys」(その他のスマートカードのグループポリシー設定とレジストリキー) (スマートカード取り出し時の動作を含む) を参照してください。

                  • プライベート CA の CRL ディストリビューションポイントがオンラインになっていないか、WorkSpaces からもドメインコントローラーからもアクセスできません。詳細については、「前提条件」のステップ 5 を参照してください。

                  トラブルシューティングのその他のステップには、WorkSpaces インスタンスの Windows イベントログを確認することが含まれます。ログオンの失敗を確認する一般的なイベントは、Windows セキュリティログの「イベント 4625: アカウントがログオンに失敗しました」です。

                  問題が解決しない場合は、AWS Support までお問い合わせください。詳細については、AWS Supportセンターを参照してください。

                  Windows インストールメディアを必要とする処理を実行しようとしていますが、WorkSpaces ではメディアが提供していません。

                  AWS が提供するパブリックバンドルを使用している場合は、必要に応じて Amazon EC2 が提供する Windows Server OS インストールメディアの EBS スナップショットを使用できます。

                  これらのスナップショットから EBS ボリュームを作成して Amazon EC2 にアタッチし、ファイルを必要とする WorkSpace にファイルを転送します。WorkSpaces の BYOL で Windows 10 を使用していて、インストールメディアが必要な場合は、独自のインストールメディアを用意する必要があります。詳細については、「インストールメディアを使用した Windows コンポーネントの追加」を参照してください。EBS ボリュームは WorkSpace に直接アタッチできないため、Amazon EC2 インスタンスにアタッチしてからファイルをコピーする必要があります。

                  WorkSpaces でサポートされていないリージョンで作成した既存の AWS マネージドディレクトリを使用して WorkSpaces を起動したいと考えています。

                  WorkSpaces で現在サポートされていないリージョンのディレクトリを使用して Amazon WorkSpaces を起動するには、以下の手順に従ってください。

                  注記

                  AWS Command Line Interface コマンドの実行中にエラーが発生した場合は、最新の AWS CLI バージョンを使用していることを確認してください。詳細については、「最新バージョンの AWS CLI を実行していることを確認する」を参照してください。

                  ステップ 1: アカウント内の別の仮想プライベートクラウド (VPC) との VPC ピアリングを作成します。

                  1. 異なるリージョンの VPC との VPC ピアリング接続を作成するには 詳細については、「同じアカウントの異なるリージョンにある VPC を使用して作成する」を参照してください。

                  2. VPC ピアリング接続を承認します。詳細については、「VPC ピアリング接続を承認する」を参照してください。

                  3. VPC ピアリング接続を有効にすると、Amazon VPC コンソール、AWS CLI、または API を使用して VPC ピアリング接続を表示できます。

                  ステップ 2: 両方のリージョンで VPC ピアリングのルートテーブルを更新する

                  ルートテーブルを更新して、IPv4 または IPv6 を介したピア VPC との通信を有効にします。詳細については、「VPC ピアリング接続のルートテーブルを更新する」を参照してください

                  ステップ 3: AD Connector を作成し、Amazon WorkSpaces を登録する

                  1. AD Connector の前提条件を確認するには、「AD Connector の前提条件」を参照してください。

                  2. 既存のディレクトリを AD Connector と接続します。詳細については、「AD Connector を作成する」を参照してください。

                  3. AD Connectorのステータスが [アクティブ] に変わったら、AWS Directory Service コンソールを開き、ディレクトリ ID のハイパーリンクを選択します。

                  4. AWS のアプリやサービスの場合は、Amazon WorkSpaces を選択し、このディレクトリの WorkSpaces へのアクセスを有効にします。

                  5. WorkSpaces でディレクトリを登録する 詳細については、「WorkSpaces でディレクトリを登録する」を参照してください。