

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# WorkSpaces Personal の管理
<a name="administer-workspaces"></a>

WorkSpaces コンソールを使用して WorkSpaces を管理できます。

ディレクトリ管理タスクを実行するには、「[WorkSpaces Personal で Active Directory 管理ツールを設定する](directory_administration.md)」を参照してください。

**注記**  
ENA、NVMe、PV ドライバーなど、WorkSpaces のネットワーク依存関係ドライバーを必ず更新してください。この作業は、少なくとも 6 か月に 1 回行う必要があります。詳細については、[Elastic Network Adapter (ENA) ドライバーのインストールまたはアップグレード](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking-ena.html#ena-adapter-driver-install-upgrade-win)、[AWS NVMe ドライバー (Windows インスタンス)](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html)、および [Windows インスタンスでの PV ドライバーのアップグレード](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Upgrading_PV_drivers.html)に関する説明を参照してください。
EC2Config、EC2Launch、および EC2Launch V2 エージェントを定期的に最新バージョンに更新してください。この作業は、少なくとも 6 か月に 1 回行う必要があります。詳細については、「[EC2Config および EC2Launch の更新](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/migrating-latest-types.html#upgdate-ec2config-ec2launch)」を参照してください。

**Topics**
+ [WorkSpaces Personal で Windows WorkSpaces を管理する](group_policy.md)
+ [WorkSpaces Personal で Amazon Linux 2 WorkSpaces を管理する](manage_linux_workspace.md)
+ [WorkSpaces Personal で Ubuntu WorkSpaces を管理する](manage_ubuntu_workspace.md)
+ [Rocky Linux WorkSpaces を管理する](manage_rockylinux_workspace.md)
+ [Red Hat Enterprise Linux WorkSpaces の管理](manage_rhel_workspace.md)
+ [WorkSpaces Personal でリアルタイム通信用に WorkSpaces を最適化する](communication-optimization.md)
+ [WorkSpaces Personal の実行モードを管理する](running-mode.md)
+ [WorkSpaces Personal でアプリケーションを管理する](manage-applications.md)
+ [WorkSpaces Personal で WorkSpace を変更する](modify-workspaces.md)
+ [WorkSpaces Personal でブランドをカスタマイズする](customize-branding.md)
+ [WorkSpaces Personal でリソースにタグを付ける](tag-workspaces-resources.md)
+ [WorkSpaces Personal のメンテナンス](workspace-maintenance.md)
+ [WorkSpaces Personal の暗号化された WorkSpaces](encrypt-workspaces.md)
+ [WorkSpaces Personal の WorkSpace を再起動する](reboot-workspaces.md)
+ [WorkSpaces Personal の WorkSpace を再構築する](rebuild-workspace.md)
+ [WorkSpaces Personal の WorkSpace を復元する](restore-workspace.md)
+ [WorkSpaces Personal での Microsoft 365 Bring Your Own License (BYOL)](byol-microsoft365-licenses.md)
+ [WorkSpaces Personal で Windows BYOL WorkSpaces をアップグレードする](upgrade-windows-10-byol-workspaces.md)
+ [WorkSpaces Personal で WorkSpace を移行する](migrate-workspaces.md)
+ [WorkSpaces Personal で WorkSpace を削除する](delete-workspaces.md)

# WorkSpaces Personal で Windows WorkSpaces を管理する
<a name="group_policy"></a>

グループポリシーオブジェクト (GPO) を使用して、Windows WorkSpaces または Windows WorkSpaces ディレクトリの一部であるユーザーを管理するための設定を適用できます。

**注記**  
Microsoft Entra ID またはカスタム WorkSpaces ディレクトリを使用する場合は、Microsoft Entra ID または ID プロバイダーを使用してユーザーとグループを管理できます。詳細については、「[WorkSpaces Personal で専用の Microsoft Entra ID ディレクトリを作成する](launch-entra-id.md)」を参照してください。
Linux インスタンスはグループポリシーに従いません。Amazon Linux WorkSpaces の管理については、[WorkSpaces Personal で Amazon Linux 2 WorkSpaces を管理する](manage_linux_workspace.md) を参照してください。

Amazon では、WorkSpaces コンピュータオブジェクトの組織単位と WorkSpaces ユーザーオブジェクトの組織単位を作成することをお勧めします。

Amazon WorkSpaces に固有のグループポリシー設定を使用するには、使用しているプロトコル (PCoIP または DCV) のグループポリシー管理用テンプレートをインストールする必要があります。

**警告**  
グループポリシー設定は、WorkSpaces のユーザーエクスペリエンスに次のように影響する場合があります。  
**ログオンバナーを表示するためにインタラクティブなログオンメッセージを実装すると、ユーザーは自分の WorkSpaces にアクセスできなくなります。**現在、インタラクティブなログオンメッセージのグループポリシー設定は PCoIP WorkSpaces でサポートされていません。ログオンメッセージは DCV WorkSpaces でサポートされており、ユーザーはログオンバナーを承諾した後に再度ログインする必要があります。証明書ベースのログオンが有効になっている場合、ログオンメッセージはサポートされていません。
**グループポリシー設定を使用してリムーバブルストレージを無効にすると、ログインに失敗します**。ユーザーはドライブ D にアクセスできず、一時ユーザープロファイルにログインされます。
**グループポリシー設定を使用してリモートデスクトップユーザーのローカルグループからユーザーを削除すると、そのユーザーは WorkSpaces クライアントアプリケーションを使用して認証できなくなります**。このグループポリシー設定の詳細については、Microsoft のドキュメントの[リモートデスクトップサービスによるログオンを許可する](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services)を参照してください。
**組み込みの Users グループを [**Allow log on locally**] (ローカルログオンを許可) セキュリティポリシーから削除すると、PCoIP WorkSpaces ユーザーは WorkSpaces クライアントアプリケーションを介して WorkSpaces に接続できなくなります。**PCoIP WorkSpaces も、PCoIP エージェントソフトウェアの更新を受信しなくなります。PCoIP エージェントの更新には、セキュリティやその他の修正が含まれていたり、WorkSpaces の新機能を有効にするものであったりする場合があります。このセキュリティポリシーの使用方法の詳細については、Microsoft ドキュメントの[ローカルでログオンを許可する](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-locally)を参照してください。
グループポリシー設定は、ドライブアクセスの制限に使用できます。**ドライブ C またはドライブ D へのアクセスを制限するようにグループポリシー設定を行うと、ユーザーは WorkSpaces にアクセスできません。**この問題を回避するために、ユーザーがドライブ C およびドライブ D にアクセスできることを確認します。
**WorkSpaces のオーディオ入力機能を使用するには、WorkSpaces 内のローカルログオンアクセスが必要です。**Windows WorkSpaces では、オーディオ入力機能はデフォルトで有効になっています。ただし、WorkSpaces でのユーザーのローカルログオンを制限するグループポリシー設定がある場合、オーディオ入力は WorkSpaces では機能しません。そのグループポリシー設定を削除すると、WorkSpaces の次回再起動後にオーディオ入力機能が有効になります。このグループポリシー設定の詳細については、Microsoft のドキュメントの[ローカルでのログオンを許可する](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-locally)をご参照ください。  
オーディオ入力リダイレクトの有効化または無効化の詳細については、[PCoIP のオーディオ入力リダイレクトを設定する](#gp_audio) または [DCV のオーディオ入力リダイレクトを設定する](#gp_audio_in_wsp) を参照してください。
グループポリシーを使用して Windows の電源プランを [**Balanced**] (バランス) または [**Power saver**] (省電力) に設定すると、WorkSpaces がアイドル状態になると、WorkSpaces がスリープ状態になる場合があります。グループポリシーを使用して、Windows の電源プランを [**High performance**] (高パフォーマンス) に設定することを強くお勧めします。詳細については、「[Windows WorkSpace をアイドル状態のままにすると、スリープ状態になる](amazon-workspaces-troubleshooting.md#windows_workspace_sleeps_when_idle)」を参照してください 
グループポリシー設定によっては、セッションから切断されているときに、ユーザーが強制的にログオフされます。ユーザーが WorkSpaces で開いているすべてのアプリケーションが閉じられます。
DCV WorkSpaces では、「アクティブだがアイドル状態のリモートデスクトップサービスセッションの時間制限を設定する」は現在サポートされていません。DCV セッション中は使用しないでください。アクティビティがあり、セッションがアイドル状態でない場合でも切断が発生します。

Active Directory 管理ツールを使用して GPO を操作する方法については、[WorkSpaces Personal で Active Directory 管理ツールを設定する](directory_administration.md) を参照してください。

**Contents**
+ [DCV のグループポリシー管理用テンプレートファイルをインストールする](#gp_install_template_wsp)
+ [DCV のグループポリシー設定を管理する](#gp_configurations_dcv)
+ [PCoIP のグループポリシー管理用テンプレートをインストールする](#gp_install_template)
+ [PCoIP のグループポリシー設定を管理する](#gp_configurations_pcoip)
+ [Kerberos チケットの最大ライフタイムを設定する](#gp_kerberos_ticket)
+ [インターネットアクセス用のデバイスプロキシサーバー設定を構成する](#gp_device_proxy)
  + [デスクトップトラフィックのプロキシ](#w2aac11c29c11c27c15)
  + [プロキシサーバーの使用に関する推奨事項](#w2aac11c29c11c27c17)
+ [Zoom Meeting Media プラグインのサポートを有効にする](#zoom-integration)
  + [DCV の Zoom Meeting Media プラグインを有効にする](#zoom-wsp)
    + [前提条件](#zoom-integ-prerequisites-wsp)
    + [[開始する前に]](#zoom-begin-wsp)
    + [Zoom コンポーネントのインストール](#installing-zoom-wsp)
  + [PCoIP の Zoom Meeting Media プラグインを有効にする](#zoom-pcoip)
    + [前提条件](#zoom-integ-prerequisites-pcoip)
    + [Windows WorkSpaces ホストにレジストリキーを作成する](#zoom-integ-create-registry-key)
    + [トラブルシューティング](#zoom-integ-troubleshoot)

## DCV のグループポリシー管理用テンプレートファイルをインストールする
<a name="gp_install_template_wsp"></a>

DCV を使用しているときに WorkSpaces に固有のグループポリシー設定を使用するには、DCV 用のグループポリシー管理用テンプレートの `wsp.admx` ファイルと `wsp.adml` ファイルを、WorkSpaces ディレクトリのドメインコントローラーのセントラルストアに追加する必要があります。`.admx` および `.adml` ファイルの詳細については、「[Windows でグループポリシー管理用テンプレートのセントラルストアを作成および管理する方法](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra)」を参照してください。

次の手順では、セントラルストアを作成し、管理用テンプレートファイルをそのストアに追加する方法について説明します。ディレクトリ管理用の WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、次の手順を実行します。

**DCV のグループポリシー管理用テンプレートファイルをインストールするには**

1. 実行中の Windows WorkSpace から、`wsp.admx` ディレクトリの `wsp.adml` および `C:\Program Files\Amazon\WSP` ファイルのコピーを作成します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、Windows エクスプローラーを開き、アドレスバーに `\\example.com` のような組織の完全修飾ドメイン名 (FQDN) を入力します。

1. `sysvol` フォルダを開きます。

1. `FQDN` という名前のフォルダを開きます。

1. `Policies` フォルダを開きます。今、`\\FQDN\sysvol\FQDN\Policies` に入っているはずです。

1. まだ存在しない場合は、`PolicyDefinitions` という名前のフォルダを作成します。

1. `PolicyDefinitions` フォルダを開きます。

1. `wsp.admx` ファイルを `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions` フォルダにコピーします。

1. `PolicyDefinitions` フォルダに `en-US` という名前のフォルダを作成します。

1. `en-US` フォルダを開きます。

1. `wsp.adml` ファイルを `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions\en-US` フォルダにコピーします。<a name="verify-admin-template"></a>

**管理用テンプレートファイルが正しくインストールされていることを確認するには**

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開きます。

1. フォレスト ([**フォレスト:*FQDN***]) を展開します。

1. [**ドメイン**] を展開します。

1. FQDN を展開します (`example.com` など)。

1. [**Group Policy Objects (グループポリシーオブジェクト)**] を展開します。

1. [**Default Domain Policy (デフォルトドメインポリシー)**] を選択し、コンテキスト (右クリック) メニューを開き、[**Edit (編集)**] を選択します。
**注記**  
WorkSpaces をバックアップするドメインが AWS Managed Microsoft AD ディレクトリの場合、デフォルトのドメインポリシーを使用して GPO を作成することはできません。代わりに、委任された権限を持つドメインコンテナの下に GPO を作成してリンクする必要があります。  
を使用してディレクトリを作成すると AWS Managed Microsoft AD、 は*ドメインルートの下にドメイン名*組織単位 (OU) Directory Service を作成します。この 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 管理ガイド*の[作成されるもの](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html)を参照してください。

1. グループポリシー管理エディタで、**[コンピューターの構成]**、**[ポリシー]**、**[管理用テンプレート]**、**[Amazon]**、**[DCV]** の順に選択します。

1. これで、この **DCV** グループポリシーオブジェクトを使用して、DCV を使用しているときに WorkSpaces 固有のグループポリシー設定を変更できます。

## DCV のグループポリシー設定を管理する
<a name="gp_configurations_dcv"></a>

**グループポリシー設定を使って、DCV を使用する Windows WorkSpaces を管理するには**

1. [DCV の最新の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_wsp)が、WorkSpaces ディレクトリのドメインコントローラーのセントラルストアにインストールされていることを確認します。

1. 管理用テンプレートファイルが正しくインストールされていることを確認します。詳細については、「[管理用テンプレートファイルが正しくインストールされていることを確認するには](#verify-admin-template)」を参照してください。

### DCV のプリンターサポートを設定する
<a name="gp_local_printers_wsp"></a>

デフォルトでは、WorkSpaces は基本的なリモート印刷を可能にします。印刷の互換性を確実にするため、ホスト側の汎用プリンタードライバーを使用するため、提供される印刷機能は限られています。

Windows WorkSpaces に接続する Windows クライアントの高度なリモート印刷では、両面印刷などのプリンターの特定の機能を使用できますが、ホスト側とクライアント側に一致するプリンタードライバーをインストールする必要があります。

グループポリシー設定を使用して、必要に応じてプリンターのサポートを設定できます。


**ベーシック印刷とアドバンスト印刷**  

| 側面 | 基本的な印刷 | 高度な印刷 | 
| --- | --- | --- | 
| 使用するドライバー | 汎用 XPS ドライバー | プリンター固有のドライバー | 
| ドライバーのインストール | 自動 | 手動 (ホストとクライアント) | 
| 特徴 | 標準印刷のみ | プリンターのフル機能 (二重、紙トレイの選択、フィニッシングなど) | 

**高度な印刷を使用する場合: **- 両面 (二重) 印刷 - 特定の紙トレイの選択 - フィニッシングオプション (ステープリング、ホールパンチ) - ラベル印刷 (例: ゼブラプリンター) - プリンターの色管理およびその他の高度な機能。

#### プリンタサポートの設定
<a name="w2aac11c29c11c19b5b1c13"></a>

**プリンターのサポートを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Configure remote printing**] 設定を開きます。

1. [**Configure remote printing (リモート印刷を設定)**] ダイアログボックスで、次のいずれかを実行します。
   + **基本的な印刷:** **Enabled** を選択します。クライアントコンピュータの現在のデフォルトプリンターを自動的に使用するには、**ローカルデフォルトプリンターをリモートホストにマッピングを選択します。 **
   + **詳細印刷:** **有効** を選択し、**詳細印刷を有効にする** を選択します。クライアントコンピュータの現在のデフォルトプリンターを自動的に使用するには、**ローカルデフォルトプリンターをリモートホストにマップを選択します**。ポリシーを有効にすると、一致するプリンタードライバーをホスト側とクライアント側にインストールする必要があります。
   + 印刷を無効にするには、**[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

#### 高度なプリンターリダイレクトを設定する
<a name="w2aac11c29c11c19b5b1c17"></a>

**前提条件**

1. **WorkSpaces ホストエージェント:** バージョン 2.2.0.2116 以降

1. **Windows クライアント:** バージョン 5.31.0 以降

1. **プリンタードライバー:** 一致するプリンタードライバーは WorkSpace とクライアントデバイスの両方にインストールする必要があります

**注記**  
高度な印刷は、Windows WorkSpaces に接続する Windows クライアントでのみサポートされています。MacOS、Linux、および Web クライアントは基本的な印刷を使用します。

#### ドライバーバージョンの一致
<a name="w2aac11c29c11c19b5b1c23"></a>

高度な印刷を選択すると、次の 3 つのドライバー検証モードがサポートされます。


**ドライバー検証モード**  

| モード | 行動 | 使用時 | 
| --- | --- | --- | 
| 名前のみ (デフォルト) | ドライバー名のみに一致し、バージョンは無視されます | 必要な最大互換性 | 
| 部分一致 | Major.Minor バージョン (10.6.x.x など) に一致 | 互換性と機能のバランス | 
| 完全一致 | バージョンが完全に一致する必要があります | 専用プリンター (例: ゼブララベルプリンター) | 

**検証モードを設定するには、GPO **のプリンタードライバー検証ドロップダウンで名前のみ、部分一致、または完全一致を設定します。

**注記**  
ドライバーの検証に失敗すると、WorkSpaces は自動的に基本的な印刷に戻ります。

**設定を確認する**

1. WorkSpace に接続します。

1. **設定** > **デバイス** > **プリンターとスキャナー**を開きます。

1. ローカルプリンターが「リダイレクト済み」プレフィックスで表示されることを確認します。

1. テストドキュメントを印刷し、プリンターのプロパティをクリックして、詳細オプションが利用可能であることを確認します。

#### トラブルシューティング
<a name="w2aac11c29c11c19b5b1c27"></a>

**高度な機能は利用できません**: - GPO で「高度な印刷を有効にする」が選択されていることを確認します - 検証モードに従ってドライバーのバージョンが一致していることを確認します - 完全ではなく部分的な検証モードを使用することを検討してください。GPO の変更を有効にするには、必ず再起動してください。

**プリンターが表示されない**: - **リモート印刷の設定****が有効になっている**ことを確認する - プリンターがクライアントデバイスに接続されていることを確認する - WorkSpace セッションを再起動する

**印刷ジョブが失敗**する: - クライアントと WorkSpace の両方でドライバーのバージョンを確認する - ログを確認する: **C:\$1ProgramData\$1Amazon\$1WSP\$1Logs\$1agentsession.log** - ログで「高度な印刷が有効になっている」を探します

詳細なログ記録を有効にする: グループポリシーで、**コンピュータ設定** > **ポリシー** > **管理テンプレート** > **Amazon** > **WSP** でログの詳細度を設定してデバッグします。

### DCV のクリップボードリダイレクト (コピー/貼り付け) を設定する
<a name="gp_clipboard_wsp"></a>

デフォルトでは、WorkSpaces は双方向 (コピー/貼り付け) のクリップボードリダイレクトをサポートしています。Windows WorkSpaces の場合、グループポリシー設定を使用して、この機能を無効にしたり、クリップボードリダイレクトを許可する方向を設定したりできます。

**Windows WorkSpaces のクリップボードリダイレクトを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Configure clipboard redirection**] 設定を開きます。

1. **[Configure clipboard redirection]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

   **[Configure clipboard redirection]** を **[Enabled]** にすると、以下の **[Clipboard redirection options]** が使用可能になります。
   + **[Copy and Paste]** (コピーして貼り付ける) では、クリップボードのコピーと貼り付けの双方向リダイレクトを許可します。
   + **[Copy Only]** (コピーのみ) では、サーバーのクリップボードからクライアントのクリップボードへのデータのコピーのみを許可します。
   + **[Paste Only]** (貼り付けのみ) では、クライアントのクリップボードからサーバーのクリップボードへのデータの貼り付けのみを許可します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

**既知の制限事項**  
WorkSpaces でクリップボードのリダイレクトが有効になっていると、Microsoft Office アプリケーションから 890 KB よりも大きいコンテンツをコピーした場合に、アプリケーションが遅くなったり最大 5 秒応答しなくなったりすることがあります。

### DCV のセッション再開タイムアウトを設定する
<a name="gp_auto_resume_wsp"></a>

ネットワーク接続が切断されると、アクティブな WorkSpaces クライアントセッションが切断されます。Windows と macOS 用の WorkSpaces クライアントアプリケーションは、ネットワーク接続が一定時間内に復元すればセッションを自動的に再接続するように試行します。デフォルト設定のセッション再起動タイムアウトは 20 分 (1,200 秒) ですが、ドメインのグループポリシー設定で制御される WorkSpaces では、この値の変更ができます。

**自動セッション再起動タイムアウト値を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Enable/disable automatic reconnect**] (自動再接続を有効/無効にする) 設定を開きます。

1. **[Enable/disable automatic reconnect]** ダイアログボックスで、**[Enabled]** を選択し、**[Reconnect timeout (seconds)]** を必要なタイムアウト (秒) に設定します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV のビデオ入力リダイレクトを設定する
<a name="gp_video_in_wsp"></a>

デフォルトでは、WorkSpaces はローカルカメラから取得されたデータのリダイレクトをサポートしています。Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**Windows WorkSpaces のビデオ入力リダイレクトを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Enable/disable video-in redirection (ビデオ入力リダイレクトを有効/無効にする)**] 設定を開きます。

1. **[Enable/disable video-in redirection]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV のオーディオ入力リダイレクトを設定する
<a name="gp_audio_in_wsp"></a>

デフォルトでは、WorkSpaces では、ローカルマイクから取得されたデータのリダイレクトをサポートしています。Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**Windows WorkSpaces のオーディオ入力リダイレクトを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Enable/disable audio-in redirection (オーディオ入力リダイレクトを有効/無効にする)**] 設定を開きます。

1. **[Enable/disable audio-in redirection]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV のオーディオ出力リダイレクトを設定する
<a name="gp_audio_out_wsp"></a>

デフォルトでは、WorkSpaces はデータをローカルスピーカーにリダイレクトします。Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**Windows WorkSpaces のオーディオ出力リダイレクトを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[オーディオ出力リダイレクトを有効/無効にする]** 設定を開きます。

1. **[オーディオ出力リダイレクトを有効/無効にする]** ダイアログボックスで、**[有効]** または **[無効]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します。Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** の順に選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV のタイムゾーンリダイレクトを無効化する
<a name="gp_time_zone_wsp"></a>

デフォルトでは、WorkSpaces 内の時間は、WorkSpaces への接続に使用されているクライアントのタイムゾーンを反映するように設定されます。この動作は、タイムゾーンのリダイレクトによって制御されます。次のようにさまざまな理由から、タイムゾーンのリダイレクトをオフにすることもできます。例えば、次のようになります。
+ 会社は、すべての従業員が特定のタイムゾーンで業務を行うことを希望している (一部の従業員が他のタイムゾーンにいる場合でも)。
+ WorkSpaces で、特定のタイムゾーン内の特定の時刻に実行するタスクをスケジュールした。
+ よく出張するユーザーが、一貫性と個人設定のため WorkSpaces を 1 つのタイムゾーンにまとめておきたいと考えている。

Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**Windows WorkSpaces のタイムゾーンのリダイレクトを無効にするには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Enable/disable time zone redirection (タイムゾーンリダイレクトを有効/無効にする)**] 設定を開きます。

1. **[Enable/disable time zone redirection]** ダイアログボックスで **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

1. WorkSpaces のタイムゾーンを目的のタイムゾーンに設定します。

WorkSpaces のタイムゾーンは静的になり、クライアントマシンのタイムゾーンは反映されなくなります。

### DCV のセキュリティ設定を構成する
<a name="wsp_security"></a>

DCV では、転送中のデータは TLS 1.2 暗号化を使用して暗号化されます。デフォルトでは、次の暗号はすべて暗号化に使用でき、クライアントとサーバーはどちらの暗号を使用するかをネゴシエートします。
+ ECDHE-RSA-AES128-GCM-SHA256
+ ECDHE-ECDSA-AES128-GCM-SHA256
+ ECDHE-RSA-AES256-GCM-SHA384
+ ECDHE-ECDSA-AES256-GCM-SHA384
+ ECDHE-RSA-AES128-SHA256
+ ECDHE-RSA-AES256-SHA384

Windows WorkSpaces では、グループポリシー設定を使用して TLS セキュリティモードを変更し、特定の暗号スイートを新規に追加またはブロックすることもできます。これらの設定とサポートされている暗号スイートの詳細については、**[PCoIP セキュリティ設定の構成]** グループポリシーダイアログボックスを参照してください。

**DCV のセキュリティ設定を構成するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[セキュリティ設定の構成]** を開きます。

1. **[セキュリティ設定の構成]** ダイアログボックスで、**[有効]** を選択します。許可する暗号スイートを追加し、ブロックする暗号スイートを削除します。これらの設定の詳細については、**[セキュリティ設定の構成]** ダイアログボックスに表示される説明を参照してください。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpaces を再起動するには、Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** を選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV の拡張機能を設定する
<a name="extensions"></a>

デフォルトでは、WorkSpaces 拡張機能のサポートは無効になっています。必要に応じて、以下の方法で拡張機能を使用するように WorkSpace を設定できます。
+ サーバーとクライアント – サーバーとクライアントの両方の拡張機能を有効にする
+ サーバーのみ – サーバーのみの拡張機能を有効にする
+ クライアントのみ – クライアントのみの拡張機能を有効にする

Windows WorkSpaces では、グループポリシー設定を使用して拡張機能の使用を設定できます。

**DCV の拡張機能を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[拡張機能の設定]** を開きます。

1. **[拡張機能の設定]** ダイアログボックスで、**[有効]** を選択し、必要なサポートオプションを設定します。**[クライアントのみ]**、**[サーバーとクライアント]**、または **[サーバーのみ]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します。Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** を選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV のスマートカードリダイレクトを設定する
<a name="gp_smart_cards_in_wsp"></a>

デフォルトでは、Amazon WorkSpaces は、*セッション前認証*または*セッション内認証*のいずれにもスマートカードの使用のサポートを有効化していません。セッション前認証とは、ユーザーが WorkSpaces にログインしている間に実行されるスマートカード認証をいいます。セッション内認証とは、ログイン後に実行される認証をいいます。

必要に応じグループポリシー設定を使用して、Windows WorkSpaces のセッション前認証およびセッション内認証を有効にします。セッション前認証は、**EnableClientAuthentication**API アクションまたは **enable-client-authentication** AWS CLI コマンドを使用して AD Connector ディレクトリ設定で有効にする必要があります。詳細については、*AWS Directory Service 管理ガイド*の [AD Connector のスマートカード認証を有効にする](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_clientauth.html)を参照してください。

**注記**  
Windows WorkSpaces でスマートカードを使用できるようにするには、追加の手順が必要です。詳細については、「[WorkSpaces Personal での認証にスマートカードを使用する](smart-cards.md)」を参照してください。

**Windows WorkSpaces のスマートカードリダイレクトを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Enable/disable smart card redirection**] (スマートカードリダイレクトを有効/無効にする) 設定を開きます。

1. **[Enable/disable smart card redirection]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。グループポリシー設定の変更を適用するには、WorkSpace を再起動します (Amazon WorkSpaces コンソールで WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します)。

### DCV の WebAuthn (FIDO2) リダイレクト
<a name="gp_webauthn_fido2_in_wsp"></a>

デフォルトでは、Amazon WorkSpaces は WebAuthn リダイレクトを有効にし、ユーザーは WorkSpace 内で実行されているアプリケーションでローカル FIDO2 互換のセキュリティキーと生体認証を使用できます。この機能は WorkSpace のアプリケーションからユーザーのローカルデバイスに認証リクエストを安全にリダイレクトし、YubiKey や Windows Hello などの認証方法へのシームレスなアクセスを提供します。

Amazon WorkSpaces は、WebAuthn リダイレクトの 2 つのバージョンをサポートしています。
+ **標準 WebAuthn** – ブラウザベースのアプリケーションには、Windows および Linux WorkSpaces でサポートされているブラウザ拡張機能が必要です
+ **Enhanced WebAuthn** – ブラウザ拡張機能は必要なく、追加のネイティブアプリケーションサポートもあり、Windows WorkSpaces でのみサポートされます

#### 標準 WebAuthn リダイレクト
<a name="w2aac11c29c11c19b5c21b9"></a>

標準 WebAuthn リダイレクトでは、WebAuthn プロンプトのクライアントデバイスへのリダイレクトを容易にするためにブラウザ拡張機能が必要です。

##### バージョン要件
<a name="w2aac11c29c11c19b5c21b9b5"></a>
+ **Windows WorkSpaces**: DCV ホストエージェントバージョン 2.0.0.1425 以降
+ **クライアントのバージョン:**
  + Windows クライアント: 5.19.0 以降
  + Mac クライアント: 5.19.0 以降
  + Linux クライアント: 2024.0 以降

##### WorkSpaces でサポートされているブラウザ
<a name="w2aac11c29c11c19b5c21b9b7"></a>
+ Google Chrome 116 以降
+ Microsoft Edge 116 以降

#### Enhanced WebAuthn リダイレクト
<a name="w2aac11c29c11c19b5c21c11"></a>

Enhanced WebAuthn リダイレクトにより、ブラウザ拡張機能が不要になり、WebAuthn 認証をサポートするネイティブ Windows アプリケーションで WebAuthn 認証がサポートされます。

##### バージョン要件
<a name="w2aac11c29c11c19b5c21c11b5"></a>
+ **Windows WorkSpaces**: DCV ホストエージェントバージョン 2.1.0.2000 以降
+ **クライアントのバージョン:**
  + Windows クライアント: 5.29.0 以降
  + Mac クライアント: 5.29.0 以降

##### 主な利点
<a name="w2aac11c29c11c19b5c21c11b7"></a>
+ ブラウザ拡張機能は不要
+ パフォーマンスの向上
+ ネイティブ Windows アプリケーションでの WebAuthn のサポート
+ ブラウザとデスクトップアプリケーション間のシームレスな認証操作

##### WorkSpaces でサポートされているブラウザ
<a name="w2aac11c29c11c19b5c21c11b9"></a>
+ Google Chrome 116 以降
+ Microsoft Edge 116 以降

#### WebAuthn リダイレクトを設定する
<a name="w2aac11c29c11c19b5c21c13"></a>

**Windows WorkSpaces の WebAuthn リダイレクトを設定するには**

1. グループポリシー管理エディタで、**[コンピューターの構成]**、**[ポリシー]**、**[管理用テンプレート]**、**[Amazon]**、**[DCV]** の順に選択します。

1. **[Configure WebAuthn redirection]** 設定を開きます。

1. **[Configure WebAuthn redirection]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。グループポリシーの変更を適用するには、Amazon WorkSpaces コンソールに移動し、WorkSpace を選択して WorkSpace を再起動します。次に、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します。

**注記**  
このグループポリシー設定により、WebAuthn リダイレクトが有効になります。使用するバージョン (Standard または Enhanced) は、ホストエージェントのバージョンとオペレーティングシステムのサポートによって異なります。

#### WebAuthn プロセスの互換性を設定する
<a name="w2aac11c29c11c19b5c21c15"></a>

WebAuthn リダイレクトを有効にすると、**[WebAuthn Process Compatibility List]** を通じて WebAuthn リダイレクトの使用を許可するアプリケーションとプロセスを設定できます。

##### デフォルトのプロセス互換性リスト
<a name="w2aac11c29c11c19b5c21c15b5"></a>

デフォルトでは、WebAuthn リダイレクトに対して次のプロセスが有効になっています。

```
['chrome.exe','msedge.exe','island.exe','firefox.exe','dcvwebauthnnativemsghost.exe','msedgewebview2.exe','Microsoft.AAD.BrokerPlugin.exe']
```

##### 標準 WebAuthn に必要なプロセス
<a name="w2aac11c29c11c19b5c21c15b7"></a>
+ `dcvwebauthnnativemsghost.exe` – このプロセスは標準 WebAuthn 機能に**必要**であり、標準 WebAuthn を使用するときは互換性リストに残っている必要があります。

**WebAuthn プロセスの互換性リストを設定するには**

1. グループポリシー管理エディタで、**[コンピューターの構成]**、**[ポリシー]**、**[管理用テンプレート]**、**[Amazon]**、**[DCV]** の順に選択します。

1. **[Configure WebAuthn Redirection]** 設定を開きます。

1. [**有効**] を選択します。

1. **[WebAuthn process compatibility list]** フィールドで、WebAuthn リダイレクトと互換性のあるプロセス名のリストを指定します。
   + デフォルトのリストを開始点として使用する
   + 必要に応じて環境に合わせてプロセス名を追加する

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。

##### プロセス互換性リストのガイドライン
<a name="w2aac11c29c11c19b5c21c15c11"></a>
+ **標準 WebAuthn の場合**: 常にリスト `dcvwebauthnnativemsghost.exe` に含める
+ **カスタムアプリケーション**: 環境で WebAuthn サポートが必要な `.exe` プロセス名を追加する
+ **形式**: カンマ区切りのプロセス名を角括弧で囲み、各プロセス名を一重引用符で囲む

##### カスタムプロセスリストの例
<a name="w2aac11c29c11c19b5c21c15c11b5"></a>

```
['chrome.exe','msedge.exe','firefox.exe','dcvwebauthnnativemsghost.exe','msedgewebview2.exe','Microsoft.AAD.BrokerPlugin.exe','myapp.exe','customapplication.exe']
```

#### Standard から Enhanced WebAuthn に移行する
<a name="w2aac11c29c11c19b5c21c17"></a>

標準 WebAuthn から Enhanced WebAuthn にアップグレードする場合、ユーザーは Enhanced WebAuthn を使用する前に、標準 WebAuthn 用に以前にインストールした **Amazon DCV WebAuthn リダイレクトブラウザ拡張機能をアンインストールまたは無効にする必要があります**。

##### このステップが重要である理由
<a name="w2aac11c29c11c19b5c21c17b5"></a>
+ Enhanced WebAuthn はブラウザ拡張機能なしでリダイレクトをネイティブに処理します
+ 拡張機能を有効にしたままにすると、デフォルトで標準 WebAuthn リダイレクトになります

#### Amazon DCV WebAuthn リダイレクト拡張機能をインストールする (標準 WebAuthn のみ)
<a name="installing_webauthn"></a>

**注記**  
このセクションは標準 WebAuthn にのみ適用されます。Enhanced WebAuthn では、ブラウザ拡張機能は必要ありません。

標準 WebAuthn を使用するには、機能が有効にされた後、ユーザーが Amazon DCV WebAuthn リダイレクト拡張機能をインストールする必要があります。次のいずれかの方法があります。
+ ブラウザでブラウザ拡張機能を有効にするように求めるプロンプトがユーザーに表示されます。
**注記**  
 これは 1 回限りのブラウザプロンプトです。DCV エージェントのバージョンを 2.0.0.1425 以降に更新すると、ユーザーに通知が送られます。エンドユーザーが WebAuthn リダイレクトを必要としない場合は、ブラウザから拡張機能を削除できます。GPO ポリシーを使用して、WebAuthn リダイレクト拡張機能のインストールプロンプトをブロックすることもできます。
+ GPO ポリシーを使用して、ユーザーのリダイレクト拡張機能を強制的にインストールできます。GPO ポリシーを有効にすると、ユーザーがサポートされているブラウザを起動したときに、インターネットアクセスを使って拡張機能が自動的にインストールされます。
+ ユーザーは、[Microsoft Edge アドオン](https://microsoftedge.microsoft.com/addons/detail/dcv-webauthn-redirection-/ihejeaahjpbegmaaegiikmlphghlfmeh)または [Chrome ウェブストア](https://chromewebstore.google.com/detail/dcv-webauthn-redirection/mmiioagbgnbojdbcjoddlefhmcocfpmn?pli=1)を使用して拡張機能を手動でインストールできます。

##### WebAuthn リダイレクト拡張機能のネイティブメッセージングについて
<a name="installing_webauthn-understand"></a>

Chrome および Edge ブラウザでの WebAuthn リダイレクトは、ブラウザ拡張機能とネイティブメッセージングホストを使用します。ネイティブメッセージングホストは、拡張機能とホストアプリケーション間の通信を許可するコンポーネントです。一般的な設定では、すべてのネイティブメッセージングホストはデフォルトでブラウザで許可されます。ただし、ネイティブメッセージングブロックリストを使用することを選択できます。\$1 の値は、明示的に許可されない限り、すべてのネイティブメッセージングホストが拒否されることを意味します。この場合、許可リスト `com.dcv.webauthnredirection.nativemessagehost` で値を明示的に指定して、Amazon DCV WebAuthn リダイレクトネイティブメッセージングホストを有効にする必要があります。

詳細については、ブラウザのガイダンスに従ってください。
+ Google Chrome については、「[許可されたネイティブ メッセージング ホスト](https://support.google.com/chrome/a/answer/2657289#zippy=%2Cnative-messaging-allowed-hosts)」を参照してください。
+ Microsoft Edge については、「[ネイティブ メッセージング](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies#native-messaging)」を参照してください。

##### グループポリシーを使用してブラウザ拡張機能を管理およびインストールする
<a name="w2aac11c29c11c19b5c21c19c11"></a>

Amazon DCV WebAuthn リダイレクト拡張機能は、Active Directory (AD) ドメインに参加しているセッションホストの場合はドメインから一元的に、またはセッションホストごとにローカルグループポリシーエディタを使用してインストールできます。このプロセスは、使用しているブラウザによって異なります。

**Microsoft Edge の場合**

1. [Microsoft Edge 管理用テンプレート](https://learn.microsoft.com/en-us/deployedge/configure-microsoft-edge#1-download-and-install-the-microsoft-edge-administrative-template)をダウンロードしてインストールします。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開きます。

1. フォレスト ([**フォレスト:*FQDN***]) を展開します。

1. [**ドメイン**] を展開します。

1. FQDN を展開します (`example.com` など)。

1. [**Group Policy Objects (グループポリシーオブジェクト)**] を展開します。

1. [**Default Domain Policy (デフォルトドメインポリシー)**] を選択し、コンテキスト (右クリック) メニューを開き、[**Edit (編集)**] を選択します。

1. **[コンピューターの構成]**、**[管理用テンプレート]**、**[Microsoft Edge]**、**[拡張機能]** の順に選択します。

1. **[拡張機能の管理設定を構成する]** を開いて、**[有効]** に設定します。

1. **[拡張機能の管理設定を構成する]** に以下を入力します。

   ```
   {"ihejeaahjpbegmaaegiikmlphghlfmeh":{"installation_mode":"force_installed","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
   ```

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。グループポリシーの変更を適用するには、Amazon WorkSpaces コンソールに移動し、WorkSpace を選択して WorkSpace を再起動します。次に、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します。

**注記**  
次の構成管理設定を適用することで、拡張機能のインストールをブロックできます。  

```
{"ihejeaahjpbegmaaegiikmlphghlfmeh":{"installation_mode":"blocked","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
```

**Google Chrome の場合**

1. Google Chrome 管理用テンプレートをダウンロードしてインストールします。詳細については、「[管理対象パソコンに Chrome ブラウザのポリシーを設定する](https://support.google.com/chrome/a/answer/187202#zippy=%2Cwindows)」を参照してください。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開きます。

1. フォレスト ([**フォレスト:*FQDN***]) を展開します。

1. [**ドメイン**] を展開します。

1. FQDN を展開します (`example.com` など)。

1. [**Group Policy Objects (グループポリシーオブジェクト)**] を展開します。

1. [**Default Domain Policy (デフォルトドメインポリシー)**] を選択し、コンテキスト (右クリック) メニューを開き、[**Edit (編集)**] を選択します。

1. **[コンピューターの構成]**、**[管理用テンプレート]**、**[Google Chrome]**、**[拡張機能]** の順に選択します。

1. **[拡張機能の管理設定を構成する]** を開いて、**[有効]** に設定します。

1. **[拡張機能の管理設定を構成する]** に以下を入力します。

   ```
   {"mmiioagbgnbojdbcjoddlefhmcocfpmn":{ "installation_mode":"force_installed","update_url":"https://clients2.google.com/service/update2/crx"}}
   ```

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。グループポリシーの変更を適用するには、Amazon WorkSpaces コンソールに移動し、WorkSpace を選択して WorkSpace を再起動します。次に、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します。

**注記**  
次の構成管理設定を適用することで、拡張機能のインストールをブロックできます。  

```
{"mmiioagbgnbojdbcjoddlefhmcocfpmn":{ "installation_mode":"blocked","update_url":"https://clients2.google.com/service/update2/crx"}}
```

### DCV の WebRTC リダイレクトを設定する
<a name="gp_webrtc_in_wsp"></a>

WebRTC リダイレクトでは、WorkSpaces からローカルクライアントにオーディオおよびビデオ処理をオフロードすることでリアルタイム通信が強化されるため、パフォーマンスが向上し、レイテンシーが低減します。ただし、WebRTC リダイレクトに汎用性はなく、サードパーティーのアプリケーションベンダーが WorkSpaces との固有の統合を開発する必要があります。デフォルトでは、WebRTC リダイレクトは WorkSpaces で有効になっていません。WebRTC リダイレクトを使用するには、以下を確認します。
+ サードパーティーアプリケーションベンダーによる統合
+ WorkSpaces 拡張機能が、グループポリシー設定を通じて有効になっていること
+ WebRTC リダイレクトが有効になっていること
+ WebRTC リダイレクトブラウザ拡張機能がインストールされ有効になっていること

**注記**  
このリダイレクトは拡張機能として実装されるため、グループポリシー設定を使用して WorkSpaces 拡張機能のサポートを有効にする必要があります。拡張機能が無効になっている場合、WebRTC リダイレクトは機能しません。

#### 要件
<a name="w2aac11c29c11c19b5c23b9"></a>

DCV の WebRTC リダイレクトには、以下が必要です。
+ DCV ホストエージェントバージョン 2.0.0.1622 以降
+ WorkSpaces クライアント
  + Windows 5.21.0 以降
  + ウェブクライアント
+ Amazon DCV WebRTC リダイレクト拡張機能を実行している WorkSpaces にインストールされているウェブブラウザ
  + Google Chrome 116 以降
  + Microsoft Edge 116 以降

#### Windows WorkSpaces の WebRTC リダイレクトを有効化/無効化する
<a name="w2aac11c29c11c19b5c23c11"></a>

必要に応じて、グループポリシー設定を使用して、Windows WorkSpaces の WebRTC リダイレクトのサポートを有効または無効にできます。この設定を無効にするか指定しない場合、WebRTC リダイレクトは無効になります。

この機能を有効にすると、Amazon WorkSpaces と統合されているウェブアプリケーションは、WebRTC API コールをローカルクライアントにリダイレクトできるようになります。

**Windows WorkSpaces の WebRTC リダイレクトを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[Configure WebRTC Redirection]** 設定を開きます。

1. **[Configure WebRTC Redirection]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。グループポリシーの変更を適用するには、Amazon WorkSpaces コンソールに移動し、WorkSpace を選択して WorkSpace を再起動します。次に、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します。

#### Amazon DCV WebRTC リダイレクト拡張機能をインストールする
<a name="installing_webrtc"></a>

WebRTC を使用するには、機能が有効にされた後、ユーザーが Amazon DCV WebRTC リダイレクト拡張機能をインストールする必要があります。次のいずれかの方法があります。
+ ブラウザでブラウザ拡張機能を有効にするように求めるプロンプトがユーザーに表示されます。
**注記**  
WebRTC リダイレクトを有効にすると、1 回限りのブラウザプロンプトとしてユーザーに通知が送られます。
+ 以下の GPO ポリシーを使用して、ユーザーのリダイレクト拡張機能を強制的にインストールできます。GPO ポリシーを有効にすると、ユーザーがサポートされているブラウザを起動したときに、インターネットアクセスを使って拡張機能が自動的にインストールされます。
+ ユーザーは、[Microsoft Edge アドオン](https://microsoftedge.microsoft.com/addons/detail/amazon-dcv-webrtc-redirec/kjbbkjjiecchbcdoollhgffghfjnbhef)または [Chrome ウェブストア](https://chromewebstore.google.com/detail/dcv-webrtc-redirection-ex/diilpfplcnhehakckkpmcmibmhbingnd?hl=en&authuser=0&pli=1)を使用して拡張機能を手動でインストールできます。

##### グループポリシーを使用してブラウザ拡張機能を管理およびインストールする
<a name="w2aac11c29c11c19b5c23c13b7"></a>

Amazon DCV WebRTC リダイレクト拡張機能は、Active Directory (AD) ドメインに参加しているセッションホストの場合はドメインから一元的に、またはセッションホストごとにローカルグループポリシーエディタを使用してインストールできます。このプロセスは、使用しているブラウザによって異なります。

**Microsoft Edge の場合**

1. [Microsoft Edge 管理用テンプレート](https://learn.microsoft.com/en-us/deployedge/configure-microsoft-edge#1-download-and-install-the-microsoft-edge-administrative-template)をダウンロードしてインストールします。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開きます。

1. フォレスト ([**フォレスト:*FQDN***]) を展開します。

1. [**ドメイン**] を展開します。

1. FQDN を展開します (`example.com` など)。

1. [**Group Policy Objects (グループポリシーオブジェクト)**] を展開します。

1. [**Default Domain Policy (デフォルトドメインポリシー)**] を選択し、コンテキスト (右クリック) メニューを開き、[**Edit (編集)**] を選択します。

1. **[コンピューターの構成]**、**[管理用テンプレート]**、**[Microsoft Edge]**、**[拡張機能]** の順に選択します。

1. **[拡張機能の管理設定を構成する]** を開いて、**[有効]** に設定します。

1. **[拡張機能の管理設定を構成する]** に以下を入力します。

   ```
   {"kjbbkjjiecchbcdoollhgffghfjnbhef":{"installation_mode":"force_installed","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
   ```

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。グループポリシーの変更を適用するには、Amazon WorkSpaces コンソールに移動し、WorkSpace を選択して WorkSpace を再起動します。次に、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します。

**注記**  
次の構成管理設定を適用することで、拡張機能のインストールをブロックできます。  

```
{"kjbbkjjiecchbcdoollhgffghfjnbhef":{"installation_mode":"blocked","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
```

**Google Chrome の場合**

1. Google Chrome 管理用テンプレートをダウンロードしてインストールします。詳細については、「[管理対象パソコンに Chrome ブラウザのポリシーを設定する](https://support.google.com/chrome/a/answer/187202#zippy=%2Cwindows)」を参照してください。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開きます。

1. フォレスト ([**フォレスト:*FQDN***]) を展開します。

1. [**ドメイン**] を展開します。

1. FQDN を展開します (`example.com` など)。

1. [**Group Policy Objects (グループポリシーオブジェクト)**] を展開します。

1. [**Default Domain Policy (デフォルトドメインポリシー)**] を選択し、コンテキスト (右クリック) メニューを開き、[**Edit (編集)**] を選択します。

1. **[コンピューターの構成]**、**[管理用テンプレート]**、**[Google Chrome]**、**[拡張機能]** の順に選択します。

1. **[拡張機能の管理設定を構成する]** を開いて、**[有効]** に設定します。

1. **[拡張機能の管理設定を構成する]** に以下を入力します。

   ```
   {"diilpfplcnhehakckkpmcmibmhbingnd":{ "installation_mode":"force_installed","update_url":"https://clients2.google.com/service/update2/crx"}}
   ```

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces セッションの再開後に有効になります。グループポリシーの変更を適用するには、Amazon WorkSpaces コンソールに移動し、WorkSpace を選択して WorkSpace を再起動します。次に、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します。

**注記**  
次の構成管理設定を適用することで、拡張機能のインストールをブロックできます。  

```
{"diilpfplcnhehakckkpmcmibmhbingnd":{ "installation_mode":"blocked","update_url":"https://clients2.google.com/service/update2/crx"}}
```

### DCV の画面ロックで切断セッションを設定する
<a name="gp_lock_screen_in_wsp"></a>

必要に応じて、Windows ロック画面が検出されたときに、ユーザーの WorkSpaces セッションを切断できます。WorkSpaces クライアントから再接続するには、WorkSpaces で有効になっている認証の種類に応じて、ユーザーはパスワードまたはスマートカードを使用して自分自身を認証できます。

このグループポリシー設定は、デフォルトでは無効になっています。必要に応じて、グループポリシー設定を使用して、Windows WorkSpaces の Windows ロック画面が検出された場合におけるセッションの切断を有効にできます。

**注記**  
このグループポリシー設定は、パスワード認証セッションとスマートカード認証セッションの両方に適用されます。
Windows WorkSpaces でスマートカードを使用できるようにするには、追加の手順が必要です。詳細については、「[WorkSpaces Personal での認証にスマートカードを使用する](smart-cards.md)」を参照してください。

**Windows WorkSpaces の画面ロックにおけるセッションの切断を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. [**Enable/disable disconnect session on screen lock**] (画面ロックの場合のセッションの切断を有効/無効にする) 設定を開きます。

1. **[Enable/disable disconnect session on screen lock]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV の画面キャプチャ保護を設定する
<a name="screen_capture_protection"></a>

Screen Capture Protection は、ローカルクライアントツールからの WorkSpaces セッションのスクリーンショット、画面録画、画面共有を防止します。有効にすると、クライアント側から画面コンテンツをキャプチャしようとすると、背景または黒い長方形が表示され、機密情報が流出するのを防ぐのに役立ちます。

#### 要件
<a name="w2aac11c29c11c19b5c27b5"></a>

DCV の画面キャプチャ保護には、以下が必要です。
+ DCV ホストエージェントバージョン 2.2.0.2116 以降
+ WorkSpaces クライアント
  + Windows 5.30.2 以降
  + MacOS 5.30.2 以降

**注記**  
 この機能は Linux クライアント、ウェブアクセス、または PCoIP プロトコルではサポートされていません。
保護は、クライアントデバイスから開始されたキャプチャに適用されます。ユーザーは WorkSpace 自体内からスクリーンショットを撮ることができます。
この機能は、MS Teams での画面共有と互換性がありません。

#### 既知の制限事項
<a name="w2aac11c29c11c19b5c27b9"></a>
+ この機能は、物理的なカメラによる画面のキャプチャを妨げることはできません。
+ この機能は、ホストサーバーへの直接 RDP 接続から保護しません。
+ この機能は、コラボレーションツールやチャットツールの画面共有機能など、WorkSpace 自体内から開始されたキャプチャ試行から保護しません。
+ 有効にすると、すべてのキャプチャメソッドがブロックされます (選択的ブロックは使用できません）。
+ この機能が有効になっていてビデオキャプチャが試行された場合 (クライアントウィンドウを画面共有しようとするなど）、MacOS クライアントウィンドウがグレー表示されることがあります。

**Windows WorkSpaces の画面キャプチャ保護を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **画面キャプチャ保護の設定**を開きます。

1. **画面キャプチャ保護の設定**ダイアログボックスで、**有効**または**無効**を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。

   1. WorkSpace を再起動します (WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。

   1. 管理コマンドプロンプトで、`gpupdate /force` と入力します。

### DCV の間接ディスプレイドライバー (IDD) を設定する
<a name="indirect_display_driver"></a>

デフォルトでは、WorkSpaces は間接ディスプレイドライバー (IDD) の使用をサポートしています。Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**Windows WorkSpaces の間接ディスプレイドライバー (IDD) を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. ** AWS 間接ディスプレイドライバーを有効にする** 設定を開きます。

1. Enable **the AWS Indirect Display Driver** ダイアログボックスで、**Enabled** または **Disabled** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。

   1. WorkSpace を再起動します (WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。

   1. 管理コマンドプロンプトで、`gpupdate /force` と入力します。

### DCV の表示設定を構成する
<a name="display_settings"></a>

WorkSpaces では、最大フレームレート、最小画質、最大画質、YUV エンコーディングなど、さまざまな表示設定を構成できます。これらの設定は、必要な画質、応答性、色精度に基づいて調整します。

デフォルトでは、最大フレームレートの値は 25 です。最大フレームレートの値は、1 秒あたりの最大許容フレーム数 (fps) を指定します。値を 0 にすると、無制限に設定されます。

デフォルトでは、最小画質の値は 30 です。最小画質は、最善の画像応答性、つまり最善の画質になるように最適化できます。最善の応答性を実現するには、最小品質を下げます。最善の品質を実現するには、最小品質を上げます。
+ 最善の応答性を実現する理想的な値は、30～90 です。
+ 最適な品質を実現する理想的な値は、60～90 です。

デフォルトでは、最低画質の値は 80 です。最大画質は画像の応答性や画質には影響しませんが、最大値を設定してネットワークの使用を制限します。

デフォルトでは、画像エンコーディングは YUV420 に設定されています。**[YUV444 エンコーディングを有効にする]** を選択すると、YUV444 エンコーディングが有効になり、高い色精度が得られます。

Windows WorkSpaces では、グループポリシー設定を使用して、最大フレームレート、最小画質、および最大画質の値を設定できます。

**Windows WorkSpaces の表示設定を構成するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[ディスプレイ設定の構成]** を開きます。

1. **[Configure display settings]** ダイアログボックスで **[Enabled]** を選択し、**[Maximum frame rate (fps)]**、**[minimum image quality]**、**[maximum image quality]** の各値を目的のレベルに設定します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpaces を再起動します。Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** を選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV の AWS 仮想ディスプレイ専用ドライバーの VSync を設定する
<a name="vsync"></a>

デフォルトでは、WorkSpaces は AWS 仮想ディスプレイ専用ドライバーの VSync 機能の使用をサポートしています。Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**Windows WorkSpaces に VSync を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. Virtual ** AWS Display Only Driver 設定の Enable VSync 機能**を開きます。

1. Virtual ** AWS Display Only Driver ダイアログボックスの Enable VSync 機能で**、**Enabled** または **Disabled** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、以下を実行します。

   1. 次のいずれかを実行して WorkSpace を再起動します。

      1. オプション 1 — WorkSpaces コンソールで、再起動する WorkSpace を選択します。次に、**[アクション]**、**[WorkSpaces を再起動]** の順に選択します。

      1. オプション 2 — 管理コマンドプロンプトで、`gpupdate /force` と入力します。

   1. 設定を適用するために WorkSpace に再接続します。

   1. WorkSpace をもう一度再起動します。

### DCV のログ詳細度を設定する
<a name="log_verbosity"></a>

デフォルトでは、DCV WorkSpaces のログ詳細度は **[情報]** に設定されています。ログレベルは、以下のように詳細度の低いものから最も詳細なものまで設定できます。
+ エラー – 最も低い詳細度
+ 警告
+ 情報 – デフォルト
+ デバッグ – 最も高い詳細度

Windows WorkSpaces では、グループポリシー設定を使用してログの詳細レベルを設定できます。

**Windows WorkSpaces のログ詳細度レベルを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[ログ詳細度の設定]** を開きます。

1. **[ログ詳細度の設定]** ダイアログボックスで、**[有効]** を選択し、ログの詳細度レベルを、**[デバッグ]**、**[エラー]**、**[情報]**、または **[警告]** に設定します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します。Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** を選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV のアイドル切断タイムアウトを設定する
<a name="idle-disconnect"></a>

WorkSpaces では、WorkSpace への接続中にユーザーの非アクティブ状態が所定の長さに達したら接続を解除するように設定できます。ユーザーアクティビティ入力の例は次のとおりです。
+ キーボードイベント
+ マウスイベント (カーソルの移動、スクロール、クリック)
+ スタイラスイベント
+ タッチイベント (タッチスクリーン、タブレットのタップ)
+ ゲームパッドイベント
+ ファイルストレージオペレーション (アップロード、ダウンロード、ディレクトリ作成、リスト項目)
+ ウェブカメラストリーミング

オーディオ入力、オーディオ出力、ピクセルの変更は、ユーザーアクティビティにはなりません。

アイドル切断タイムアウトを有効にする場合、オプションで、アクティビティが発生しない限り、設定された時間内にセッションが切断されることをユーザーに通知できます。

デフォルトでは、アイドル切断タイムアウトは無効になっており、タイムアウト値は 0 分に設定され、通知は無効になっています。このポリシー設定を有効にすると、アイドル切断タイムアウトの値はデフォルトで 60 分、アイドル切断タイムアウト警告の値はデフォルトで 60 秒になります。Windows WorkSpaces では、グループポリシー設定を使用してこの機能を設定できます。

**Windows WorkSpaces のアイドル切断タイムアウトを設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[Configure Idle Disconnect Timeout]** 設定を開きます。

1. **[Configure Idle Disconnect Timeout]** ダイアログボックスで **[Enabled]**を選択し、切断タイムアウトの値 (分単位) と、オプションの警告タイマーの値 (秒単位) を設定します。

1. [**適用**]、[**OK**] の順に選択します。

1. グループポリシー設定の変更は、変更を適用するとすぐに有効になります。

### DCV のファイル転送を設定する
<a name="gp-file-transfer"></a>

デフォルトでは、Amazon WorkSpaces のファイル転送機能は無効になっています。これを有効にすると、ユーザーはローカルコンピュータと WorkSpaces セッションの間でファイルをアップロードおよびダウンロードできます。ファイルは WorkSpaces セッションの **[ストレージ]** フォルダに保存されます。

**Windows WorkSpaces のファイル転送を有効にするには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[Configure session storage]** 設定を開きます。

1. **[Configure Session Storage]** ダイアログボックスで、**[Enabled]** を選択します。

1. (オプション) セッションストレージのフォルダを指定します (`c:/session-storage` など)。指定しない場合、セッションストレージのデフォルトフォルダはホームフォルダになります。

1. WorkSpace は、次のいずれかのファイル転送オプションを使用して設定できます。
   + 双方向ファイル転送を許可する場合は、`Download and Upload` を選択します。
   + ローカルコンピュータから WorkSpaces セッションへのファイルアップロードのみを許可する場合は、`Upload Only` を選択します。
   + WorkSpaces セッションからローカルコンピュータへのファイルダウンロードのみを許可する場合は、`Download Only` を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します。Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** を選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV の USB リダイレクトを設定する
<a name="gp_dcv_usbredirection"></a>

#### 概要:
<a name="gp_dcv_usbredirection_overview"></a>

バージョン 2.2.0.2047 以降、Amazon WorkSpaces は DCV ベースの Windows WorkSpaces の汎用 USB リダイレクトをサポートしているため、ユーザーは仮想デスクトップ環境内のローカル USB デバイスにアクセスできます。この機能は、特定のデバイスクラスの既存の最適化されたリダイレクトソリューションを補完します。

**注記**  
Amazon では、最適化されたリダイレクトソリューションが利用できないデバイスにのみ汎用リダイレクトを使用することをお勧めします。利用可能な場合、最適化されたリダイレクトソリューションはパフォーマンスを向上させます。

#### 前提条件
<a name="gp_dcv_usbredirection_prerequisites"></a>
+ DCV プロトコルバージョン 2.2.0.2047 以降を使用する Windows WorkSpaces 
+ WorkSpaces Windows クライアントの最新バージョン (バージョン 5.30.0 以降)
+ グループポリシー設定を構成するための管理アクセス

#### 設定
<a name="gp_dcv_usbredirection_config"></a>

USB リダイレクトはデフォルトで無効になっています。この機能を有効にするには、グループポリシーオブジェクト (GPO) を使用します。この機能を有効にすると、リダイレクトのために許可リストにデバイスを追加できます。デフォルトでは、許可リストにないデバイスはリダイレクトできません。

##### グループポリシーの設定
<a name="gp_dcv_usbredirection_gpo"></a>

**グループポリシーを使用して DCV の USB リダイレクトを設定するには**

1. Windows WorkSpaces に接続します。

1. ポリシーテンプレートファイル (`wsp.admx` および `wsp.adml`) を `C:\Program Files\Amazon\WSP`フォルダからコピーします。

1. `C:\Windows\PolicyDefinitions` フォルダ`wsp.admx`に貼り付けます。

1. `C:\Windows\PolicyDefinitions\en-US` フォルダ`wsp.adml`に貼り付けます。

1. ローカル GPO エディタを起動します (**gpedit.msc**)。

1. **ローカルコンピュータポリシー** > **コンピュータ設定** > **管理テンプレート** > **Amazon** > **WSP** に移動します。

1. WSP 設定で **USB の有効化/無効化**を設定します。

1. **有効化** を選択して USB リダイレクトを有効にします。

**注記**  
この設定の変更は、次の接続に適用されます。

#### デバイスの管理
<a name="gp_dcv_usbredirection_device_mgmt"></a>

USB リダイレクトを有効にすると、GPO のデバイス許可リストを設定して、リダイレクトをサポートするデバイスを追加できます。

##### デバイス許可リストの設定
<a name="gp_dcv_usbredirection_allowlist"></a>

USB リダイレクトは、デフォルトの拒否オールセキュリティスタンスに従います。管理者は、次の形式を使用して GPO の許可リストに追加することで、デバイスを明示的に許可する必要があります。

```
Name, Base class, Subclass, Protocol, Id Vendor, Id Product, Support Auto-share, Skip reset
// Use * to skip any values
```

**例:**

**ベンダー ID/製品 ID を持つデバイスの追加:**

```
Credit Card Reader, *, *, *, 0x0483, 0x2016, 1, 0
// Allows Credit Card Reader with VID 0x0483 and PID 0x2016 with auto-share support
```

**クラス/サブクラスを使用したデバイスの追加:**

```
3D Mouse Devices, 03, 01, *, *, *, 1, 0
// Allows all 3D mice using HID class (03), boot interface subclass (01), with auto-share support
```

**注記**  
許可リストに追加する前に、デバイスの互換性とパフォーマンスをテストします。

#### セキュリティに関する考慮事項
<a name="gp_dcv_usbredirection_security"></a>

##### ベストプラクティス
<a name="gp_dcv_usbredirection_best_practices"></a>
+ 最適なパフォーマンスと互換性を実現するために、サポートされているデバイスで利用可能な場合は、専用のリダイレクト方法を使用します。たとえば、YubiKey などのセキュリティキーの場合は、代わりに WebAuthn リダイレクトを使用します。
+ 厳格なデバイス許可リストを実装します。
+ 監査ログを使用してデバイスアクセスをモニタリングします。
+ 新しいデバイスを許可する前に、データセキュリティへの影響を評価します。

### DCV のウェブカメラの解像度を設定する
<a name="gp-webcam-resolution"></a>

この設定を使用して、ウェブカメラの解像度を指定します。このポリシー設定を有効にすると、以下を指定できます。
+ ウェブカメラの最大解像度: 提供される解像度の中から、選択可能なウェブカメラの最大解像度を指定します。この値が欠落している、または (0, 0) の場合は、デフォルト値が使用されます。
+ 好ましいウェブカメラの解像度: クライアントによって提供される解像度のうち、優先するウェブカメラの解像度を指定します。指定した解像度がサポートされていない場合は、一致する解像度のうち最も近いものが選択されます。この値が欠落している、または (0, 0) の場合は、デフォルト値が使用されます。

このポリシー設定を無効にするか設定しない場合、デフォルトの解像度が使用されます。

**Windows WorkSpaces のウェブカメラの解像度を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[Configure webcam resolution]** の設定を開きます。

1. **[Configure webcam resolution]** ダイアログボックスで、**[Enabled]** を選択し、**[Maximum webcam resolution]** (ピクセル単位) または **[Preferred webcam resolution]** (ピクセル単位) を設定します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します。Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** を選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### DCV のサーバーキーボードレイアウトの使用を設定する
<a name="gp-server-keyboard-layout"></a>

この設定は、デフォルトのクライアント側のキーボードレイアウトではなく、サーバー側のキーボードレイアウトをキー解釈に使用するかどうかを制御します。この設定の変更は、次の接続に適用されます。キーボード処理の詳細については、「*Amazon WorkSpaces User Guide*」を参照してください。

このポリシー設定を有効にすると、次のいずれかのオプションを選択できます。
+ **常にオフ** – 常にクライアントレイアウトを使用する
+ **常にオン** – 常にサーバーレイアウトを使用する

このポリシー設定を無効にするか設定しない場合、**常にオフ**オプションが使用されます。

**注記**  
この機能は、Amazon WorkSpaces Windows クライアントバージョン 5.29.2 以降、および Amazon WorkSpaces macOS クライアントバージョン 5.30.0 以降でサポートされています。

**Windows WorkSpaces のサーバーキーボードレイアウトの使用を設定するには**

1. グループポリシー管理エディタで、[**Computer Configuration (コンピュータの設定)**]、[**Policies (ポリシー)**]、[**Administrative Templates (管理用テンプレート)**]、[**Amazon**]、[**WSP**] の順に選択します。

1. **[Configure server keyboard layout usage]** 設定を開きます。

1. **[Configure server keyboard layout usage]** ダイアログボックスで、**[Enabled]** を選択し、**[Server keyboard layout option]** を設定します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します。Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces の再起動]** を選択します。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

## PCoIP のグループポリシー管理用テンプレートをインストールする
<a name="gp_install_template"></a>

PCoIP プロトコルを使用するときに Amazon WorkSpaces に固有のグループポリシー設定を使用するには、WorkSpaces で使用されている PCoIP エージェントのバージョン（32 ビットまたは 64 ビット）に適したグループポリシー管理用テンプレートを追加する必要があります。

**注記**  
32 ビットと 64 ビットのエージェントの WorkSpaces が混在している場合は、32 ビットエージェント用のグループポリシー管理用テンプレートを使用できます。グループポリシー設定は 32 ビットと 64 ビットの両方のエージェントに適用されます。すべての WorkSpaces が 64 ビットエージェントを使用している場合は、64 ビットエージェントの管理テンプレートを使用するように切り替えることができます。

**WorkSpaces に 32 ビットエージェントがあるかどうか、 64 ビットのエージェントがあるかどうかを調べるには**

1. WorkSpaces にログインし、**[表示]**、**[Ctrl \$1 Alt \$1 Delete で送信]** を選択するか、タスクバーを右クリックして **[タスクマネージャー]** を選択することで、タスクマネージャーを開きます。

1. タスクマネージャで、[**詳細**] タブに移動し、列見出しを右クリックし、[**列の選択**] を選択します。

1. [**列の選択**] ダイアログボックスで、[**プラットフォーム**] を選択し、[**OK**] をクリックします。

1. [**詳細**] タブで、`pcoip_agent.exe` を探し、[**プラットフォーム**] 列でその値を確認し、PCoIP エージェントが 32 ビットであるか 64 ビットであるか判別します。(32 ビットと 64 ビットの WorkSpaces コンポーネントが混在している場合がありますが、これは正常です)。

### PCoIP のグループポリシー管理用テンプレートをインストールする (32 ビット)
<a name="gp_install_template_pcoip_32_bit"></a>

PCoIP プロトコルを 32 ビット PCoIP エージェントで使用するとき、WorkSpaces に固有のグループポリシー設定を使用するには、PCoIP 用のグループポリシー管理用テンプレートをインストールする必要があります。ディレクトリの管理 WorkSpaces またはディレクトリに結合されている Amazon EC2 インスタンスで、次の手順を実行します。

.adm ファイルの操作の詳細については、マイクロソフトのドキュメントの「[グループポリシー管理用テンプレート (.adm) ファイルを管理するための推奨事項](https://docs.microsoft.com/troubleshoot/windows-server/group-policy/manage-group-policy-adm-file)」を参照してください。

**PCoIP のグループポリシー管理用テンプレートをインストールするには**

1. 実行中の Windows WorkSpaces から、`pcoip.adm` ディレクトリの `C:\Program Files (x86)\Teradici\PCoIP Agent\configuration` ファイルのコピーを作成します。

1. ディレクトリ管理用の WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、WorkSpaces マシンアカウントが含まれているドメイン内の組織単位に移動します。

1. コンピュータアカウントの組織単位のコンテキスト（右クリック）メニューを開き、[**Create a GPO in this domain, and link it here**] を選択します。

1. [**New GPO**] ダイアログボックスで、GPO のわかりやすい名前 (**「WorkSpaces Machine Policies」など**) を入力し、[**Source Starter GPO**] は [**(none)**] のままにします。[**OK**] を選択してください。

1. 新しい GPO のコンテキスト (右クリック) メニューを開き、[**Edit**] を選択します。

1. グループポリシー管理エディタで、[**Computer Configuration**]、[**Policies**]、[**Administrative Templates**] の順に選択します。メインメニューから **[Action]**、**[Add/Remove Templates]** の順に選択します。

1. **[Add/Remove Templates]** ダイアログボックスで、**[Add]** を選択し、先ほどコピーした `pcoip.adm` ファイルを選択したら、**[Open]**、**[Close]** の順に選択します。

1. [Group Policy Management Editor] を終了します。これで、この GPO を使用して、WorkSpaces に固有のグループポリシーの設定を変更できます。

**管理用テンプレートファイルが正しくインストールされていることを確認するには**

1. ディレクトリ管理用の WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、WorkSpaces マシンアカウントの WorkSpaces GPO に移動して選択します。メインメニューの **[Action]**、**[Edit]** を選択します。

1. グループポリシー管理エディタで、[**Computer Configuration**]、[**Policies**]、[**Administrative Templates**]、[**Classic Administrative Templates**]、[**PCoIP Session Variables**] の順に選択します。

1. これで、この **PCoIP セッション変数**グループポリシーオブジェクトを使用して、PCoIP を使用しているときに Amazon WorkSpaces に固有のグループポリシー設定を変更できるようになります。
**注記**  
ユーザーによる設定の上書きを許可するには、[**Overridable Administrator Settings**] (上書き可能な管理者設定) を選択します。許可しない場合は、[**Not Overridable Administrator Settings**] (上書き可能でない管理者設定) を選択します。

### PCoIP のグループポリシー管理用テンプレートをインストールする (64 ビット)
<a name="gp_install_template_pcoip_64_bit"></a>

PCoIP プロトコルを使用しているときに WorkSpaces に固有のグループポリシー設定を使用するには、グループポリシー管理用テンプレート `PCoIP.admx` および PCoIP 用 `PCoIP.adml` ファイルを WorkSpaces ディレクトリのドメインコントローラーのセントラルストアに追加する必要があります。`.admx` および `.adml` ファイルの詳細については、「[Windows でグループポリシー管理用テンプレートのセントラルストアを作成および管理する方法](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra)」を参照してください。

次の手順では、セントラルストアを作成し、管理用テンプレートファイルをそのストアに追加する方法について説明します。ディレクトリ管理用の WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、次の手順を実行します。

**PCoIP のグループポリシー管理用テンプレートファイルをインストールするには**

1. 実行中の Windows WorkSpace から、`PCoIP.admx` ディレクトリの `PCoIP.adml` および `C:\Program Files\Teradici\PCoIP Agent\configuration\policyDefinitions` ファイルのコピーを作成します。`PCoIP.adml`ファイルは、そのディレクトリの `en-US` サブフォルダにあります。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、Windows エクスプローラーを開き、アドレスバーに `\\example.com` のような組織の完全修飾ドメイン名 (FQDN) を入力します。

1. `sysvol` フォルダを開きます。

1. `FQDN` という名前のフォルダを開きます。

1. `Policies` フォルダを開きます。今、`\\FQDN\sysvol\FQDN\Policies` に入っているはずです。

1. まだ存在しない場合は、`PolicyDefinitions` という名前のフォルダを作成します。

1. `PolicyDefinitions` フォルダを開きます。

1. `PCoIP.admx` ファイルを `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions` フォルダにコピーします。

1. `PolicyDefinitions` フォルダに `en-US` という名前のフォルダを作成します。

1. `en-US` フォルダを開きます。

1. `PCoIP.adml` ファイルを `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions\en-US` フォルダにコピーします。

**管理用テンプレートファイルが正しくインストールされていることを確認するには**

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開きます。

1. フォレスト ([**フォレスト:*FQDN***]) を展開します。

1. [**ドメイン**] を展開します。

1. FQDN を展開します (`example.com` など)。

1. [**Group Policy Objects (グループポリシーオブジェクト)**] を展開します。

1. [**Default Domain Policy (デフォルトドメインポリシー)**] を選択し、コンテキスト (右クリック) メニューを開き、[**Edit (編集)**] を選択します。
**注記**  
WorkSpaces をバックアップするドメインが AWS Managed Microsoft AD ディレクトリの場合、デフォルトドメインポリシーを使用して GPO を作成することはできません。代わりに、委任された権限を持つドメインコンテナの下に GPO を作成してリンクする必要があります。  
を使用してディレクトリを作成すると AWS Managed Microsoft AD、 は*ドメインルートの下にドメイン名*組織単位 (OU) Directory Service を作成します。この 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 管理ガイド*の[作成されるもの](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html)を参照してください。

1. グループポリシー管理エディタで、[**コンピュータの設定**]、[**ポリシー**]、[**管理用テンプレート**]、[**PCoIP セッション変数**] の順に選択します。

1. これで、この **PCoIP セッション変数**グループポリシーオブジェクトを使用して、PCoIP を使用しているときに WorkSpaces に固有のグループポリシー設定を変更できるようになります。
**注記**  
ユーザーによる設定の上書きを許可するには、[**Overridable Administrator Settings**] (上書き可能な管理者設定) を選択します。許可しない場合は、[**Not Overridable Administrator Settings**] (上書き可能でない管理者設定) を選択します。

## PCoIP のグループポリシー設定を管理する
<a name="gp_configurations_pcoip"></a>

グループポリシー設定を使って、PCoIP を使用する Windows WorkSpaces を管理します。

### PCoIP のプリンタサポートを設定する
<a name="gp_local_printers"></a>

デフォルトでは、WorkSpaces は基本的なリモート印刷を可能にします。印刷の互換性を確実にするため、ホスト側の汎用プリンタードライバーを使用するため、提供される印刷機能は限られています。

Windows クライアントの高度なリモート印刷では、両面印刷など、プリンター固有の機能を使用できますが、ホスト側に一致するプリンタードライバーをインストールする必要があります。

リモート印刷は仮想チャネルとして実装されます。仮想チャネルが無効になっている場合、リモート印刷は機能しません。

Windows WorkSpaces の場合、グループポリシー設定を使用して、必要に応じてプリンターのサポートを設定できます。

**プリンターのサポートを設定するには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Configure remote printing**] 設定を開きます。

1. [**Configure remote printing (リモート印刷を設定)**] ダイアログボックスで、次のいずれかを実行します。
   + 高度なリモート印刷を有効にするには、**[Enabled]** を選択し、**[Options]** の **[Configure remote printing]** で **[Basic and Advanced printing for Windows clients]** を選択します。クライアントコンピュータの現在のデフォルトプリンターを自動的に使用するには、[ **Automatically set default printer (デフォルトプリンターを自動的に設定する)**] を選択します。
   + 印刷を無効にするには、**[Enabled]** を選択し、**[Options]** の **[Configure remote printing]** で **[Printing disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

デフォルトでは、ローカルプリンターへの自動リダイレクトは無効になっています。グループポリシーの設定を使用して、この機能を有効にすることができます。有効にすると、WorkSpaces に接続するたびに、ローカルプリンターがデフォルトプリンターとして設定されます。

**注記**  
ローカルプリンターのリダイレクトは Amazon Linux WorkSpaces ではご利用になれません。

**ローカルプリンターへの自動リダイレクトを有効にするには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Configure remote printing**] 設定を開きます。

1. **[Enabled]** を選択し、**[Options]** の **[Configure remote printing]** で、次のいずれかを選択します。
   + **Basic and Advanced printing for Windows clients** (Windows クライアント用の基本印刷と高度な印刷)
   + **Basic printing** (基本印刷)

1. [**Automatically set default printer**] (デフォルトのプリンターを自動的に設定) を選択し、[**OK**] を選択します。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### PCoIP のクリップボードリダイレクト (コピー/貼り付け) を設定する
<a name="gp_clipboard"></a>

デフォルトでは、WorkSpaces はクリップボードのリダイレクトをサポートしています。Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**クリップボードのリダイレクトを有効または無効にするには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Configure clipboard redirection**] 設定を開きます。

1. [**Configure clipboard redirection (クリップボードのリダイレクトの設定)**] ダイアログボックスで、[**有効**] を選択し、次のいずれかの設定を選択して、クリップボードのリダイレクトが許可される方向を決定します。終了したら、[**OK**] を選択します。
   + 双方向で無効
   + エージェントからクライアントのみ有効 (WorkSpaces からローカルコンピュータ)
   + クライアントからエージェントのみ有効 (ローカルコンピュータから WorkSpaces)
   + 双方向で有効 

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

**既知の制限事項**  
WorkSpaces でクリップボードのリダイレクトが有効になっていると、Microsoft Office アプリケーションから 890 KB よりも大きいコンテンツをコピーした場合に、アプリケーションが遅くなったり最大 5 秒応答しなくなったりすることがあります。

### PCoIP のセッション再開タイムアウトを設定する
<a name="gp_auto_resume"></a>

ネットワーク接続が切断されると、アクティブな WorkSpaces クライアントセッションが切断されます。Windows と macOS 用の WorkSpaces クライアントアプリケーションは、ネットワーク接続が一定時間内に回復すればセッションを自動的に再接続するように試行します。デフォルト設定のセッション再起動タイムアウトは 20 分ですが、ドメインのグループポリシー設定で制御される WorkSpaces では、この値の変更ができます。

**自動セッション再起動タイムアウト値を設定するには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Configure Session Automatic Reconnection Policy**] 設定を開きます。

1. **[Configure Session Automatic Reconnection Policy]** ダイアログボックスで **[Enabled]** を選択し、**[Configure Session Automatic Reconnection Policy]** オプションを必要なタイムアウト値 (分単位) に設定して、**[OK]** を選択します。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### PCoIP のオーディオ入力リダイレクトを設定する
<a name="gp_audio"></a>

デフォルトでは、Amazon WorkSpaces では、ローカルマイクから取得されたデータのリダイレクトをサポートしています。Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**注記**  
WorkSpaces でのユーザーのローカルログオンを制限するグループポリシー設定がある場合、オーディオ入力は WorkSpaces では機能しません。そのグループポリシー設定を削除すると、WorkSpaces の次回再起動後にオーディオ入力機能が有効になります。このグループポリシー設定の詳細については、Microsoft のドキュメントの「[ローカルでのログオンを許可する](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-locally)」をご参照ください。

**オーディオ入力リダイレクトを有効または無効にするには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Enable/disable audio in the PCoIP session**] (PCoIP セッションでのオーディオ入力を有効/無効にする) 設定を開きます。

1. **[Enable/disable audio in the PCoIP session]** ダイアログボックスで、**[Enabled]** または **[Disabled]** を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### PCoIP のタイムゾーンリダイレクトを無効化する
<a name="gp_time_zone"></a>

デフォルトでは、WorkSpaces 内の時間は、WorkSpaces への接続に使用されているクライアントのタイムゾーンを反映するように設定されます。この動作は、タイムゾーンのリダイレクトによって制御されます。次のようにさまざまな理由から、タイムゾーンのリダイレクトをオフにすることもできます。
+ 会社は、すべての従業員が特定のタイムゾーンで業務を行うことを希望している (一部の従業員が他のタイムゾーンにいる場合でも)。
+ WorkSpaces で、特定のタイムゾーン内の特定の時刻に実行するタスクをスケジュールした。
+ よく出張するユーザーが、一貫性と個人設定のため WorkSpaces を 1 つのタイムゾーンにまとめておきたいと考えている。

Windows WorkSpaces では必要に応じて、グループポリシーの設定を使用し、この機能を無効にすることができます。

**タイムゾーンのリダイレクトを無効にするには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Configure timezone redirection**] (タイムゾーンリダイレクトを構成) の設定を開きます。

1. [**Configure timezone redirection**] (タイムゾーンリダイレクトを設定) ダイアログボックスで [**Disabled**] (無効) を選択します。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

1. WorkSpaces のタイムゾーンを目的のタイムゾーンに設定します。

WorkSpaces のタイムゾーンは静的になり、クライアントマシンのタイムゾーンは反映されなくなります。

### PCoIP セキュリティ設定を構成する
<a name="gp_security"></a>

PCoIP については、転送中のデータは、TLS 1.2 暗号化と SigV4 リクエスト署名を使用して暗号化されます。PCoIP プロトコルは、AES で暗号化された UDP トラフィックをストリーミングピクセルに使用します。ポート 4172 (TCP および UDP) を使用するストリーミング接続は、AES-128 および AES-256 暗号を使用して暗号化されますが、暗号化はデフォルトで 128 ビットとなります。このデフォルトを 256 ビットに変更するには、[**Configure PCoIP Security Settings**] (PCoIP セキュリティ設定を構成) グループポリシー設定を使用します。

このグループポリシー設定を使用して、TLS セキュリティモードを変更し、特定の暗号スイートをブロックすることもできます。これらの設定とサポートされている暗号スイートの詳細については、[**Configure PCoIP Security Settings**] (PCoIP セキュリティ設定を構成) グループポリシーダイアログボックスを参照してください。

**PCoIP セキュリティ設定を構成するには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Configure PCoIP Security Settings**] (PCoIP セキュリティ設定を構成) の設定を開きます。

1. [**Configure PCoIP Security Settings**] (PCoIP セキュリティ設定を構成) ダイアログボックスで、[**Enabled**] (有効) を選択します。ストリーミングトラフィックのデフォルトの暗号化を 256 ビットに設定するには、[**PCoIP Data Encryption Ciphers**] (PCoIP データ暗号化暗号) オプションに移動し、[**AES-256-GCM only**] (AES-256-GCM のみ) を選択します。

1. (オプション) **TLS セキュリティモード**の設定を調整し、ブロックする暗号スイートをリストします。これらの設定の詳細については、[**Configure PCoIP Security Settings**] (PCoIP セキュリティ設定を構成) ダイアログボックスに表示される説明を参照してください。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

### PCoIP の USB リダイレクトを設定する
<a name="gp_usbredirection"></a>

**注記**  
Amazon WorkSpaces は現在、YubiKey U2F に対してのみ USB リダイレクトをサポートしています。他のタイプの USB デバイスもリダイレクトされる場合がありますが、それらはサポートされていないため、正常に動作しない可能性があります。

**PCoIP の USB リダイレクトを有効にするには**

1. インストールした[PCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_32_bit)、または [PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレート](#gp_install_template_pcoip_64_bit)が最新であることを確認します。

1. ディレクトリ管理 WorkSpaces または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (**gpmc.msc**) を開き、**PCoIP セッション変数**に移動します。

1. [**Enable/disable USB in the PCOIP session**] (PCoIP セッションでの USB を有効/無効にする) 設定を開きます。

1.  [**Enabled**] (有効)、[**OK**] の順に選択します。

1. [**Configure PCoIP USB allowed and unallowed device rules**] (PCoIP USB の許可および許可されないデバイスのルール設定) を開きます。

1. **[有効]**を選択し、**[USB 認可テーブルを入力 (最大 10 個のルール)]**で、USB デバイスの許可リストルールを設定します。

   1. 承認ルール - 110500407。この値は、ベンダー ID (VID) と製品 ID (PID) の組み合わせです。VID/PID の組み合わせの形式は 1xxxxyyyy です。xxxx は 16 進形式の VID で、yyyy は 16 進形式の PID です。この例では、1050 が VID で、0407 が PID です。YubiKey USB の値の詳細については、[YubiKey USB ID Values](https://support.yubico.com/hc/en-us/articles/360016614920-YubiKey-USB-ID-Values) を参照してください。

1. **[USB 認可テーブルを入力 (最大 10 個のルール)]**で、USB デバイスのブロックリストルールを設定します。

   1. [**Unauthorization Rule**] (非承認ルール) に、空の文字列を設定します。これは、承認リスト内の USB デバイスだけが許可されることを意味します。
**注記**  
USB 承認ルールと USB 非承認ルールをそれぞれ最大 10 個定義することができます。複数のルールを区切るには、縦棒 (\$1) 文字を使用します。承認ルールと非承認ルールの詳細については、[Teradici PCoIP Standard Agent for Windows](https://www.teradici.com/web-help/pcoip_agent/standard_agent/windows/20.10/admin-guide/configuring/configuring/#pcoip-usb-allowed-and-unallowed-device-rules) を参照してください。

1. [**OK**] を選択してください。

1. グループポリシー設定の変更は、WorkSpaces の次回のグループポリシーの更新後、および WorkSpaces セッションの再起動後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。
   + WorkSpace を再起動します (Amazon WorkSpaces コンソールで、WorkSpace を選択し、**[アクション]**、**[WorkSpaces を再起動]** を選択します)。
   + 管理コマンドプロンプトで、**gpupdate /force** と入力します。

この設定が有効になると、USB デバイスのルール設定で制限されていない限り、サポートされているすべての USB デバイスが WorkSpaces にリダイレクトできるようになります。

## Kerberos チケットの最大ライフタイムを設定する
<a name="gp_kerberos_ticket"></a>

Windows WorkSpaces の [**Remember Me**] (情報を記憶する) 機能を無効にしていない場合、WorkSpaces ユーザーは WorkSpaces クライアントアプリケーションの [**Remember Me**] (情報を記憶する) または [**Keep me logged in**] (ログイン状態を保つ) チェックボックスを使用して、認証情報を保存することができます。この機能により、ユーザーはクライアントアプリケーションが実行中であれば簡単に WorkSpaces に接続できます。認証情報は、ユーザーの Kerberos チケットの最大有効期間が終了するまで安全にキャッシュに保存されます。

WorkSpaces で AD Connector ディレクトリを使用している場合は、Microsoft Windows ドキュメントの「[チケットの最長有効期間](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket)」の手順に従って、グループポリシーを使用して WorkSpaces ユーザーの Kerberos チケットの最大有効期間を変更できます。

[**Remember Me**] (このアカウントを記憶する) 機能を有効または無効にする方法については、[WorkSpaces Personal でユーザーを対象とした WorkSpaces の自己管理機能を有効にする](enable-user-self-service-workspace-management.md) を参照してください。

## インターネットアクセス用のデバイスプロキシサーバー設定を構成する
<a name="gp_device_proxy"></a>

デフォルトでは、WorkSpaces クライアントアプリケーションは、デバイスオペレーティングシステム設定で HTTPS (ポート 443) トラフィック用に指定したプロキシサーバーを使用します。Amazon WorkSpaces クライアントアプリケーションは、更新、登録、認証に HTTPS ポートを使用します。

**注記**  
サインイン認証情報を使用した認証を必要とするプロキシサーバーはサポートされていません。

Microsoft ドキュメントの「[デバイスプロキシとインターネット接続の設定の構成](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet)」の手順に従って、グループポリシーを通じて Windows WorkSpaces のデバイスプロキシサーバー設定を構成できます。

WorkSpaces Windows クライアントアプリケーションでのプロキシ設定の構成の詳細については、「Amazon WorkSpaces ユーザーガイド」の「[プロキシサーバー](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-windows-client.html#windows_proxy_server)」を参照してください。

WorkSpaces macOS クライアントアプリケーションでのプロキシ設定の構成の詳細については、「*Amazon WorkSpaces User Guide*」の「[Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-osx-client.html#osx_proxy_server)」を参照してください。

WorkSpaces Web Access クライアントアプリケーションでのプロキシ設定の構成の詳細については、「*Amazon WorkSpaces User Guide*」の「[Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-web-access.html#web-access-proxy)」を参照してください。

### デスクトップトラフィックのプロキシ
<a name="w2aac11c29c11c27c15"></a>

PCoIP WorkSpaces の場合、デスクトップクライアントアプリケーションは、UDP のポート 4172 トラフィック (デスクトップトラフィック) に対するプロキシサーバーの使用も、TLS の復号と検査もサポートしていません。ポート 4172 に直接接続する必要があります。

DCV WorkSpaces の場合、WorkSpaces Windows クライアントアプリケーション (バージョン 5.1 以降) と macOS クライアントアプリケーション (バージョン 5.4 以降) は、ポート 4195 TCP トラフィックに対する HTTP プロキシサーバーの使用をサポートしています。TLS の復号および検査はサポートしていません。

DCV は、UDP 経由のデスクトップトラフィックに対するプロキシの使用をサポートしていません。TCP トラフィックに対するプロキシの使用をサポートしているのは、WorkSpaces Windows および macOS デスクトップクライアントアプリケーションと Web Access のみです。

**注記**  
プロキシサーバーを使用する場合、クライアントアプリケーションが WorkSpaces サービスに対して行う API コールもプロキシされます。API コールとデスクトップトラフィックの両方が同じプロキシサーバーを通過する必要があります。

### プロキシサーバーの使用に関する推奨事項
<a name="w2aac11c29c11c27c17"></a>

WorkSpaces デスクトップトラフィックでのプロキシサーバーの使用はお勧めしません。

Amazon WorkSpaces デスクトップトラフィックは既に暗号化されているため、プロキシを使用してもセキュリティは向上しません。プロキシを使用すると、ネットワークパスに余分なホップが発生してレイテンシーをもたらし、ストリーミング品質に影響する可能性があります。プロキシのサイズがデスクトップストリーミングトラフィックの処理に適切でない場合、プロキシによってスループットが低下する可能性もあります。さらに、ほとんどのプロキシは長時間実行される WebSocket (TCP) 接続をサポートするようには設計されていないため、ストリーミングの品質と安定性に影響する可能性があります。

プロキシを使用する必要がある場合は、ストリーミングの品質と応答性に悪影響を及ぼす可能性のあるネットワークレイテンシーの増大を避けるため、プロキシサーバーを WorkSpace クライアントのできるだけ近く、できれば同じネットワーク内に配置してください。

## Amazon WorkSpaces で Zoom Meeting Media プラグインのサポートを有効にする
<a name="zoom-integration"></a>

Zoom は、Zoom VDI プラグインを使用して、Windows ベースの DCV および PCoIP WorkSpaces での最適化されたリアルタイム通信をサポートしています。クライアントとの直接通信によってビデオ通話はクラウドベースの仮想デスクトップを迂回できるため、ユーザーの WorkSpace 内で会議が行われていてもローカルのような Zoom エクスペリエンスを提供できます。

### DCV の Zoom Meeting Media プラグインを有効にする
<a name="zoom-wsp"></a>

Zoom VDI コンポーネントをインストールする前に、Zoom 最適化をサポートするように WorkSpaces 設定を更新します。

#### 前提条件
<a name="zoom-integ-prerequisites-wsp"></a>

プラグインを使用する前に、以下の要件を満たしていることを確認してください。
+ Windows WorkSpaces クライアントバージョン 5.10.0 以降と [Zoom VDI プラグイン](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE29K2S6NPYCC3SWB667AT:~:text=Zoom%20Meeting%20client.-,Install%20the%20Zoom%20VDI%20plugin,-To%20complete%20your)バージョン 5.17.10 以降
+ WorkSpaces 内 — [VDI 版 Zoom Meeting](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0063810) クライアントバージョン 5.17.10 以降

#### [開始する前に]
<a name="zoom-begin-wsp"></a>

1. **[拡張機能]** グループポリシー設定を有効にします。詳細については、「[DCV の拡張機能を設定する](#extensions)」を参照してください。

1. **[自動再接続]** グループポリシー設定を無効にします。詳細については、「[DCV のセッション再開タイムアウトを設定する](#gp_auto_resume_wsp)」を参照してください。

#### Zoom コンポーネントのインストール
<a name="installing-zoom-wsp"></a>

Zoom 最適化を有効にするには、Zoom が提供する 2 つのコンポーネントを Windows WorkSpaces にインストールします。詳細については、「[Using Zoom for Amazon WorkSpaces](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE29K2S6NPYCC3SWB667AT)」を参照してください。

1. WorkSpace に VDI 版 Zoom Meeting クライアントバージョン 5.12.6 以降をインストールします。

1. WorkSpace がインストールされているクライアントに Zoom VDI プラグイン (Windows ユニバーサルインストーラ) バージョン 5.12.6 以降をインストールします。

1. VDI 版 Zoom クライアントで VDI プラグインのステータスが **[接続済み]** として表示されることを確認して、プラグインが Zoom トラフィックを最適化していることを確認します。詳細については、「[How to confirm Amazon WorkSpaces optimization](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE1MA5YMYFX5B5XM873V1Y)」を参照してください。

### PCoIP の Zoom Meeting Media プラグインを有効にする
<a name="zoom-pcoip"></a>

Active Directory への管理者アクセス許可を持つユーザーは、グループポリシーオブジェクト (GPO) を使用してレジストリキーを生成できます。これにより、ユーザーは強制更新を使用してドメイン内のすべての Windows WorkSpaces にレジストリキーを送信できます。または、管理者権限を持つユーザーは、WorkSpaces ホストにレジストリキーを個別にインストールすることもできます。

#### 前提条件
<a name="zoom-integ-prerequisites-pcoip"></a>

プラグインを使用する前に、以下の要件を満たしていることを確認してください。
+ Windows WorkSpaces クライアントバージョン 5.4.0 以降と [Zoom VDI プラグイン](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE29K2S6NPYCC3SWB667AT:~:text=Zoom%20Meeting%20client.-,Install%20the%20Zoom%20VDI%20plugin,-To%20complete%20your)バージョン 5.12.6 以降
+ WorkSpaces 内 — [VDI 版 Zoom Meeting](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0063810) クライアントバージョン 5.12.6 以降

#### Windows WorkSpaces ホストにレジストリキーを作成する
<a name="zoom-integ-create-registry-key"></a>

次の手順に従って、Windows WorkSpaces ホストにレジストリキーを作成します。Windows WorkSpaces で Zoom を使用するには、レジストリキーが必要です。

1. 管理者として Windows レジストリエディタを開きます。

1. `\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Amazon` に移動します。

1. **Extension** キーが存在しない場合は、右クリックして **[New]** (新規) > **[Key]** (キー) を選択し、「**Extension**」という名前を付けます。

1. 新しい **Extension** キーで右クリックし、**[New]** (新規) > **[DWORD]** を選択し、「**enable**」という名前を付けます。この名前は小文字にする必要があります。

1. 新しい **DWORD** をクリックし、**[値]** を **[1]** に変更します。

1. コンピュータを再起動してプロセスを完了します。

1. WorkSpaces ホストで、最新の Zoom VDI クライアントをダウンロードしてインストールします。WorkSpaces クライアント (5.4 以降) で、Amazon WorkSpaces 用の最新の Zoom VDI クライアントプラグインをダウンロードしてインストールします。詳細については、*Zoom サポートウェブサイト*の「[VDI releases and downloads](https://support.zoom.us/hc/en-us/articles/4415057249549-VDI-releases-and-downloads)」を参照してください。

Zoom を起動してビデオ通話を開始します。

#### トラブルシューティング
<a name="zoom-integ-troubleshoot"></a>

Windows WorkSpaces での Zoom のトラブルシューティングを行うには、以下のアクションを実行してください。
+ レジストリキーがアクティブ化され、正しく適用されていることを確認します。
+ `C:\ProgramData\Amazon\Amazon WorkSpaces Extension` に移動します。`wse_core_dll` と表示されていることを確認します。
+ ホストとクライアントの間でバージョンが正しいこと、また一致していることを確認します。

問題が解決しない場合は、 [サポート センター](https://console.aws.amazon.com/support/home#/) サポート を使用して にお問い合わせください。

次の例を使用し、ディレクトリの管理者として GPO を適用できます。
+ **WSE.adml**

  ```
  <?xml version="1.0" encoding="utf-8"?>
  <policyDefinitionResources xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
      <!-- 'displayName' and 'description' don't appear anywhere. All Windows native GPO template files have them set like this. -->
      <displayName>enter display name here</displayName>
      <description>enter description here</description>
  
      <resources>
      <stringTable>
          <string id="SUPPORTED_ProductOnly">N/A</string>
          <string id="Amazon">Amazon</string>
          <string id="Amazon_Help">Amazon Group Policies</string>
          <string id="WorkspacesExtension">Workspaces Extension</string>
          <string id="WorkspacesExtension_Help">Workspace Extension Group Policies</string>
  
          <!-- Extension Itself -->
          <string id="ToggleExtension">Enable/disable Extension Virtual Channel</string>
          <string id="ToggleExtension_Help">
  Allows two-way Virtual Channel data communication for multiple purposes
  
  By default, Extension is disabled.</string>
  
      </stringTable>
      </resources>
  </policyDefinitionResources>
  ```
+ **WSE.admx**

  ```
  <?xml version="1.0" encoding="utf-8"?>
  <policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
      <policyNamespaces>
          <target prefix="WorkspacesExtension" namespace="Microsoft.Policies.Amazon.WorkspacesExtension" />
      </policyNamespaces>
      <supersededAdm fileName="wse.adm" />
      <resources minRequiredRevision="1.0" />
      <supportedOn>
          <definitions>
              <definition name="SUPPORTED_ProductOnly" displayName="$(string.SUPPORTED_ProductOnly)"/>
          </definitions>
      </supportedOn>
      <categories>
          <category name="Amazon" displayName="$(string.Amazon)" explainText="$(string.Amazon_Help)" />
          <category name="WorkspacesExtension" displayName="$(string.WorkspacesExtension)" explainText="$(string.WorkspacesExtension_Help)">
              <parentCategory ref="Amazon" />
          </category>
      </categories>
  
      <policies>
          <policy name="ToggleExtension" class="Machine" displayName="$(string.ToggleExtension)" explainText="$(string.ToggleExtension_Help)" key="Software\Policies\Amazon\Extension" valueName="enable">
              <parentCategory ref="WorkspacesExtension" />
              <supportedOn ref="SUPPORTED_ProductOnly" />
              <enabledValue>
                  <decimal value="1" />
              </enabledValue>
              <disabledValue>
                  <decimal value="0" />
              </disabledValue>
          </policy>
      </policies>
  </policyDefinitions>
  ```

# WorkSpaces Personal で Amazon Linux 2 WorkSpaces を管理する
<a name="manage_linux_workspace"></a>

RPM Package Manager (RPM) を必要とするワークロードの場合は、[Red Hat Enterprise Linux](https://docs.aws.amazon.com/workspaces/latest/adminguide/manage_rhel_workspace.html) または [Rocky Linux](https://docs.aws.amazon.com/workspaces/latest/adminguide/manage_rockylinux_workspace.html) を使用することをお勧めします。Amazon Linux 2 では、Firefox や glibc など、必要な一部のアプリケーションやライブラリの最新バージョンが提供されない場合があります。

Linux インスタンスはグループポリシーに従っていないため、設定管理ソリューションを使用してポリシーの配信と適用を行うことをお勧めします。例えば、[Ansible](https://www.ansible.com/) を使用できます。

**注記**  
ローカルプリンターのリダイレクトは Amazon Linux WorkSpaces ではご利用になれません。

## Amazon Linux WorkSpaces で DCV の動作を制御する
<a name="wsp_agent_linux"></a>

DCV の動作は、`/etc/wsp/` ディレクトリにある `wsp.conf` ファイルの構成設定によって制御されます。ポリシーの変更をデプロイして適用するには、Amazon Linux をサポートする設定管理ソリューションを使用します。変更はすべて、エージェントの起動時に有効になります。

**注記**  
誤った変更またはサポートされていない変更を `wsp.conf` ファイルに加えた場合、ポリシー変更は WorkSpaces に新たに確立された接続に適用されない場合があります。
現在、Amazon Linux WorkSpaces DCV バンドルには、次の制限があります。  
現在、 AWS GovCloud (米国西部) および AWS GovCloud (米国東部) でのみ利用可能です。
動画入力はサポートされていません。
画面ロック時のセッション切断はサポートされていません。

以降のセクションでは、特定の機能を有効または無効にする方法について説明します。

## DCV Amazon Linux WorkSpaces のクリップボードリダイレクトを設定する
<a name="wsp_linux_clipboard"></a>

デフォルトでは、WorkSpaces はクリップボードのリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を設定します。この設定は、WorkSpace を切断して再接続したときに有効になります。

**DCV Amazon Linux WorkSpaces のクリップボードリダイレクトを設定するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. 

   ```
   clipboard = X
   ```

   *X* に指定できる値は以下のとおりです。

   `enabled` – クリップボードリダイレクトは両方向ともに有効です (デフォルト)

   `disabled` – クリップボードリダイレクトは両方向ともに無効です

   `paste-only` – クリップボードリダイレクトは有効ですが、ローカルクライアントデバイスからコンテンツをコピーし、リモートホストデスクトップに貼り付けることのみが可能です。

   `copy-only` – クリップボードリダイレクトは有効ですが、リモートホストデスクトップからコンテンツをコピーし、ローカルクライアントデバイスに貼り付けることのみが可能です。

## DCV Amazon Linux WorkSpaces のオーディオ入力リダイレクトを有効または無効にする
<a name="wsp_linux_audio"></a>

デフォルトでは、WorkSpaces はオーディオインリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。この設定は、WorkSpace を切断して再接続したときに有効になります。

**DCV Amazon Linux WorkSpaces のオーディオ入力リダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. ファイルの末尾に次の行を追加します。

   ```
   audio-in = X
   ```

   *X* に指定できる値は以下のとおりです。

   `enabled` – オーディオ入力リダイレクトは有効です (デフォルト)

   `disabled` – オーディオ入力リダイレクトは無効です

## DCV Amazon Linux WorkSpaces のタイムゾーンのリダイレクトを有効または無効にする
<a name="linux_time_zone_wsp"></a>

デフォルトでは、WorkSpaces 内の時間は、WorkSpaces への接続に使用されているクライアントのタイムゾーンを反映するように設定されます。この動作は、タイムゾーンのリダイレクトによって制御されます。次のような理由から、タイムゾーンのリダイレクトをオフにすることもできます。
+ 会社は、すべての従業員が特定のタイムゾーンで業務を行うことを希望している (一部の従業員が他のタイムゾーンにいる場合でも)。
+ WorkSpaces で、特定のタイムゾーン内の特定の時刻に実行するタスクをスケジュールした。
+ よく出張するユーザーが、一貫性と個人設定のため WorkSpaces を 1 つのタイムゾーンにまとめておきたいと考えている。

必要に応じて、DCV 設定ファイルを使用してこの機能を設定します。この設定は、WorkSpace を切断して再接続した後に有効になります。

**DCV Amazon Linux WorkSpaces のタイムゾーンのリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp-agent/wsp.conf
   ```

1. ファイルの末尾に次の行を追加します。

   ```
   timezone_redirect= X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – タイムゾーンのリダイレクトは有効です (デフォルト)

   **disabled** – タイムゾーンのリダイレクトは無効です

## Amazon Linux WorkSpaces で PCoIP エージェントの動作を制御する
<a name="pcoip_agent_linux"></a>

PCoIP Agent の動作は、`pcoip-agent.conf` ディレクトリにある `/etc/pcoip-agent/` ファイルの構成設定によって制御されます。ポリシーの変更をデプロイして適用するには、Amazon Linux をサポートする設定管理ソリューションを使用します。変更はすべて、エージェントの起動時に有効になります。エージェントを再起動すると、開いている接続がすべて終了されウィンドウマネージャーが再起動されます。変更を適用するには、WorkSpace を再起動することをお勧めします。

**注記**  
`pcoip-agent.conf` ファイルに正しくない変更またはサポートされていない変更を加えた場合、WorkSpace が動作しなくなる可能性があります。WorkSpace が動作しなくなった場合は、[SSH を使用して WorkSpace に接続](connect-to-linux-workspaces-with-ssh.md)して変更をロールバックするか、[WorkSpace を再構築](rebuild-workspace.md)する必要がある場合があります。

以降のセクションでは、特定の機能を有効または無効にする方法について説明します。利用可能な設定の一覧については、Amazon Linux WorkSpace のターミナルから `man pcoip-agent.conf` を実行します。

## PCoIP Amazon Linux WorkSpaces のクリップボードリダイレクトを設定する
<a name="linux_clipboard"></a>

デフォルトでは、WorkSpaces はクリップボードのリダイレクトをサポートしています。PCoIP エージェント設定を使用して、必要に応じてこの機能を無効にします。この設定は、WorkSpace を再起動したときに有効になります。

**PCoIP Amazon Linux WorkSpaces のクリップボードリダイレクトを設定するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `pcoip-agent.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/pcoip-agent/pcoip-agent.conf
   ```

1. ファイルの末尾に次の行を追加します。

   ```
   pcoip.server_clipboard_state = X
   ```

   *X* に指定できる値は以下のとおりです。

   0 – クリップボードリダイレクトは両方向ともに無効です

   1 – クリップボードリダイレクトは両方向ともに有効です

   2 – クリップボードリダイレクトはクライアントからエージェントへのみ有効です (ローカルクライアントデバイスからリモートホストデスクトップへのコピーと貼り付けのみを許可)

   3 – クリップボードリダイレクトはエージェントからクライアントへのみ有効です (リモートホストデスクトップからローカルクライアントデバイスへのコピーと貼り付けのみを許可)

**注記**  
クリップボードのリダイレクトは仮想チャネルとして実装されます。仮想チャンネルが無効になっている場合、クリップボードのリダイレクトは機能しません。仮想チャネルを有効にするには、Teradici のドキュメントの「[PCoIP Virtual Channels](https://www.teradici.com/web-help/pcoip_agent/standard_agent/linux/20.07/admin-guide/configuring/configuring/#pcoip-virtual-channels)」をご参照ください。

## PCoIP Amazon Linux WorkSpaces のオーディオ入力リダイレクトを有効化/無効化する
<a name="linux_audio"></a>

デフォルトでは、WorkSpaces はオーディオインリダイレクトをサポートしています。PCoIP エージェント設定を使用して、必要に応じてこの機能を無効にします。この設定は、WorkSpace を再起動したときに有効になります。

**PCoIP Amazon Linux WorkSpaces のオーディオ入力リダイレクトを有効化/無効化するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `pcoip-agent.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/pcoip-agent/pcoip-agent.conf
   ```

1. ファイルの末尾に次の行を追加します。

   ```
   pcoip.enable_audio = X
   ```

   *X* に指定できる値は以下のとおりです。

   0 – オーディオ入力リダイレクトは無効です

   1 – オーディオ入力リダイレクトは有効です

## PCoIP Amazon Linux WorkSpaces のタイムゾーンのリダイレクトを有効化/無効化する
<a name="linux_time_zone"></a>

デフォルトでは、WorkSpaces 内の時間は、WorkSpaces への接続に使用されているクライアントのタイムゾーンを反映するように設定されます。この動作は、タイムゾーンのリダイレクトによって制御されます。次のような理由から、タイムゾーンのリダイレクトをオフにすることもできます。
+ 会社は、すべての従業員が特定のタイムゾーンで業務を行うことを希望している (一部の従業員が他のタイムゾーンにいる場合でも)。
+ WorkSpaces で、特定のタイムゾーン内の特定の時刻に実行するタスクをスケジュールした。
+ よく出張するユーザーが、一貫性と個人設定のため WorkSpaces を 1 つのタイムゾーンにまとめておきたいと考えている。

Linux WorkSpaces のために必要な場合は、PCoIP エージェントの設定を使用してこの機能を無効にすることができます。この設定は、WorkSpace を再起動したときに有効になります。

**PCoIP Amazon Linux WorkSpaces のタイムゾーンのリダイレクトを有効化/無効化するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `pcoip-agent.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/pcoip-agent/pcoip-agent.conf
   ```

1. ファイルの末尾に次の行を追加します。

   ```
   pcoip.enable_timezone_redirect= X
   ```

   *X* に指定できる値は以下のとおりです。

   0 – タイムゾーンのリダイレクトは無効です

   1 – タイムゾーンのリダイレクトは有効です

## Amazon Linux WorkSpaces 管理者に SSH アクセスを付与する
<a name="linux_ssh"></a>

デフォルトでは、割り当て済みユーザーおよびドメイン管理者グループのアカウントのみが SSH を使用して Amazon Linux WorkSpaces に接続できます。

Active Directory で Amazon Linux WorkSpaces 管理者専用の管理者グループを作成することをお勧めします。

**Linux\$1Workspaces\$1Admins Active Directory グループのメンバーの sudo アクセスを有効にするには**

1. 次の例に示すように、`sudoers` を使用して `visudo` ファイルを編集します。

   ```
   [example\username@workspace-id ~]$ sudo visudo
   ```

1. 次の行を追加します。

   ```
   %example.com\\Linux_WorkSpaces_Admins ALL=(ALL) ALL 
   ```

専用の管理者グループを作成したら、次のステップに従ってグループのメンバーのログインを有効にします。

**Linux\$1WorkSpaces\$1Admins Active Directory グループのメンバーのログインを有効にするには**

1. 昇格された権限で `/etc/security/access.conf` を編集します。

   ```
   [example\username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. 次の行を追加します。

   ```
   +:(example\Linux_WorkSpaces_Admins):ALL 
   ```

SSH 接続の有効化の詳細については、[WorkSpaces Personal で Linux WorkSpaces の SSH 接続を有効にする](connect-to-linux-workspaces-with-ssh.md) を参照してください。

## Amazon Linux WorkSpaces のデフォルトシェルを上書きする
<a name="linux_shell"></a>

Linux WorkSpaces のデフォルトシェルを上書きするには、ユーザーの `~/.bashrc` ファイルを編集することをお勧めします。たとえば、`Z shell` シェルの代わりに `Bash` を使用するには、`/home/username/.bashrc` に次の行を追加します。

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**注記**  
この変更を行った後、WorkSpace を再起動するか (切断だけでなく) WorkSpace からログアウトし、再度ログインして変更を有効にする必要があります。

## 不正なアクセスからカスタムリポジトリを保護する
<a name="password_protect_repos"></a>

カスタムリポジトリへのアクセスを制御するには、パスワードではなく、Amazon Virtual Private Cloud (Amazon VPC) に組み込まれているセキュリティ機能を使用することをお勧めします。たとえば、ネットワークアクセスコントロールリスト (ACL) とセキュリティグループを使用します。これらの機能の詳細については、*Amazon VPC ユーザーガイド*の[セキュリティ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html)を参照してください。

リポジトリを保護するためにパスワードを使用する必要がある場合は、Fedora ドキュメントの「[リポジトリ定義ファイル](https://docs.fedoraproject.org/en-US/Fedora_Core/3/html/Software_Management_Guide/sn-writing-repodefs.html)」に示されているように、`yum` リポジトリ定義ファイルを作成してください。

## Amazon Linux Extras Library リポジトリを使用する
<a name="linux_extras"></a>

Amazon Linux では、Extras Library を使用してアプリケーションおよびソフトウェア更新をインスタンスにインストールできます。Extras Library の使用については、*Linux インスタンス用 Amazon EC2 ユーザーガイド*の [Extras Library (Amazon Linux)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html#extras-library) を参照してください。

**注記**  
Amazon Linux リポジトリを使用している場合は、Amazon Linux WorkSpaces がインターネットにアクセスできるか、このリポジトリおよびメイン Amazon Linux リポジトリへの仮想プライベートクラウド (VPC) エンドポイントを設定する必要があります。詳細については、「[WorkSpaces Personal でのインターネットアクセス](amazon-workspaces-internet-access.md)」を参照してください。

## Linux WorkSpaces での認証にスマートカードを使用する
<a name="linux_smart_cards"></a>

Linux WorkSpaces DCV バンドルでは、認証に [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) および [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) スマートカードを使用できます。詳細については、「[WorkSpaces Personal での認証にスマートカードを使用する](smart-cards.md)」を参照してください。

## インターネットアクセス用のデバイスプロキシサーバー設定を構成する
<a name="gp_device_proxy_linux"></a>

デフォルトでは、WorkSpaces クライアントアプリケーションは、デバイスオペレーティングシステム設定で HTTPS (ポート 443) トラフィック用に指定したプロキシサーバーを使用します。Amazon WorkSpaces クライアントアプリケーションは、更新、登録、認証に HTTPS ポートを使用します。

**注記**  
サインイン認証情報を使用した認証を必要とするプロキシサーバーはサポートされていません。

Microsoft ドキュメントの「[デバイスプロキシとインターネット接続の設定の構成](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet)」の手順に従って、グループポリシーを通じて Linux WorkSpaces のデバイスプロキシサーバー設定を構成できます。

WorkSpaces Windows クライアントアプリケーションでのプロキシ設定の構成の詳細については、「Amazon WorkSpaces ユーザーガイド」の[プロキシサーバー](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-windows-client.html#windows_proxy_server)を参照してください。

WorkSpaces macOS クライアントアプリケーションでのプロキシ設定の構成の詳細については、「*Amazon WorkSpaces User Guide*」の「[Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-osx-client.html#osx_proxy_server)」を参照してください。

WorkSpaces Web Access クライアントアプリケーションでのプロキシ設定の構成の詳細については、「*Amazon WorkSpaces User Guide*」の「[Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-web-access.html#web-access-proxy)」を参照してください。

### デスクトップトラフィックのプロキシ
<a name="w2aac11c29c13c35c15"></a>

PCoIP WorkSpaces の場合、デスクトップクライアントアプリケーションは、UDP のポート 4172 トラフィック (デスクトップトラフィック) に対するプロキシサーバーの使用も、TLS の復号と検査もサポートしていません。ポート 4172 に直接接続する必要があります。

DCV WorkSpaces の場合、WorkSpaces Windows クライアントアプリケーション (バージョン 5.1 以降) と macOS クライアントアプリケーション (バージョン 5.4 以降) は、ポート 4195 TCP トラフィックに対する HTTP プロキシサーバーの使用をサポートしています。TLS の復号および検査はサポートしていません。

DCV は、UDP 経由のデスクトップトラフィックに対するプロキシの使用をサポートしていません。TCP トラフィックに対するプロキシの使用をサポートしているのは、WorkSpaces Windows および macOS デスクトップクライアントアプリケーションと Web Access のみです。

**注記**  
プロキシサーバーを使用する場合、クライアントアプリケーションが WorkSpaces サービスに対して行う API コールもプロキシされます。API コールとデスクトップトラフィックの両方が同じプロキシサーバーを通過する必要があります。

### プロキシサーバーの使用に関する推奨事項
<a name="w2aac11c29c13c35c17"></a>

WorkSpaces デスクトップトラフィックでのプロキシサーバーの使用はお勧めしません。

Amazon WorkSpaces デスクトップトラフィックは既に暗号化されているため、プロキシを使用してもセキュリティは向上しません。プロキシを使用すると、ネットワークパスに余分なホップが発生してレイテンシーをもたらし、ストリーミング品質に影響する可能性があります。プロキシのサイズがデスクトップストリーミングトラフィックの処理に適切でない場合、プロキシによってスループットが低下する可能性もあります。さらに、ほとんどのプロキシは長時間実行される WebSocket (TCP) 接続をサポートするようには設計されていないため、ストリーミングの品質と安定性に影響する可能性があります。

プロキシを使用する必要がある場合は、ストリーミングの品質と応答性に悪影響を及ぼす可能性のあるネットワークレイテンシーの増大を避けるため、プロキシサーバーを WorkSpace クライアントのできるだけ近く、できれば同じネットワーク内に配置してください。

# WorkSpaces Personal で Ubuntu WorkSpaces を管理する
<a name="manage_ubuntu_workspace"></a>

Ubuntu WorkSpaces バンドルには、Canonical からの Ubuntu Pro のサブスクリプションが含まれています。Windows や Amazon Linux WorkSpaces と同様に、Ubuntu WorkSpaces はドメイン結合されているため、Active Directory ユーザーとグループを使用して以下を実行できます。
+ Ubuntu WorkSpaces を管理する
+ ユーザーにこれらの WorkSpaces へのアクセスを許可する

AdSys を使用することで、グループポリシーで Ubuntu WorkSpaces を管理できます。Active Directory 統合の詳細については、「[Ubuntu Active Directory の統合に関するよくある質問](https://ubuntu.com/blog/new-active-directory-integration-features-in-ubuntu-22-04-faq)」を参照してください。[Landscape](https://ubuntu.com/landscape) や [Ansible](https://www.ansible.com/) など、他の構成および管理ソリューションを使用することもできます。

## Ubuntu WorkSpaces で DCV の動作を制御する
<a name="wsp_ubuntu"></a>

DCV の動作は、`/etc/wsp/` ディレクトリにある `wsp.conf` ファイルの構成設定によって制御されます。ポリシーの変更をデプロイして適用するには、Ubuntu をサポートする設定管理ソリューションを使用します。変更はすべて、エージェントの起動時に有効になります。

**注記**  
誤った変更またはサポートされていない変更を加えた場合、WorkSpace に新たに確立された接続に `wsp.conf` ポリシーが適用されない場合があります。

以降のセクションでは、特定の機能を有効または無効にする方法について説明します。

## Ubuntu WorkSpaces のクリップボードのリダイレクトの有効化または無効化
<a name="ubuntu_clipboard"></a>

デフォルトでは、WorkSpaces はクリップボードのリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Ubuntu WorkSpaces のクリップボードのリダイレクトを有効化または無効化するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   clipboard = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – クリップボードリダイレクトは両方向ともに有効です (デフォルト)

   **disabled** – クリップボードリダイレクトは両方向ともに無効です

   **[paste-only]** (ペーストのみ) — クリップボードのリダイレクトが有効で、ローカルクライアントデバイスからコンテンツをコピーし、リモートホストデスクトップにペーストするのみが可能です。

   **[copy-only]** (コピーのみ) — クリップボードのリダイレクトが有効で、リモートホストのデスクトップからコンテンツをコピーし、ローカルのクライアントデバイスにペーストするのみが可能です。

## Ubuntu WorkSpaces のオーディオインリダイレクトの有効化または無効化
<a name="ubuntu_audio"></a>

デフォルトでは、WorkSpaces はオーディオインリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Ubuntu WorkSpaces のオーディオインリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   audio-in = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – オーディオ入力リダイレクトは有効です (デフォルト)

   **disabled** – オーディオ入力リダイレクトは無効です

## Ubuntu WorkSpaces のビデオインリダイレクトの有効化または無効化
<a name="ubuntu_video"></a>

デフォルトでは、WorkSpaces はビデオインリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Ubuntu WorkSpaces のビデオインリダイレクトを有効化または無効化するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   video-in = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – ビデオ入力リダイレクトは有効です (デフォルト)

   **disabled** – ビデオ入力リダイレクトは無効です

## Ubuntu WorkSpaces のタイムゾーンのリダイレクトの有効化または無効化
<a name="ubuntu-time-zone"></a>

デフォルトでは、WorkSpaces 内の時間は、WorkSpaces への接続に使用されているクライアントのタイムゾーンを反映するように設定されます。この動作は、タイムゾーンのリダイレクトによって制御されます。次のような理由から、タイムゾーンのリダイレクトをオフにすることもできます。
+ 会社は、すべての従業員が特定のタイムゾーンで業務を行うことを希望している (一部の従業員が他のタイムゾーンにいる場合でも)。
+ WorkSpaces で、特定のタイムゾーン内の特定の時刻に実行するタスクをスケジュールした。
+ よく出張するユーザーが、一貫性と個人設定のため WorkSpaces を 1 つのタイムゾーンにまとめておきたいと考えている。

必要に応じて、DCV 設定ファイルを使用してこの機能を設定します。

**Ubuntu WorkSpaces のタイムゾーンのリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   timezone-redirection = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – タイムゾーンのリダイレクトは有効です (デフォルト)

   **disabled** – タイムゾーンのリダイレクトは無効です

## Ubuntu WorkSpaces のプリンターリダイレクトの有効化または無効化
<a name="ubuntu_printer"></a>

デフォルトでは、WorkSpaces はプリンターリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Ubuntu WorkSpaces のプリンターリダイレクトを有効化または無効化するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   remote-printing = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – プリンターリダイレクトは有効です (デフォルト)

   **disabled** – プリンターリダイレクトは無効です

## DCV の画面ロック時におけるセッションの切断を有効または無効にする
<a name="ubuntu_screenlock"></a>

画面ロック時におけるセッションの切断を有効にすると、ロック画面が検出されたときにユーザーが WorkSpaces セッションを終了できます。WorkSpaces クライアントから再接続するには、WorkSpaces で有効になっている認証の種類に応じて、ユーザーはパスワードまたはスマートカードを使用して自分自身を認証できます。

デフォルトでは、WorkSpaces は画面ロックによるセッションの切断をサポートしていません。必要に応じて、DCV 設定ファイルを使用してこの機能を有効にします。

**Ubuntu WorkSpaces の画面ロック時におけるセッションの切断を有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   disconnect-on-lock = X
   ```

   *X* に指定できる値は以下のとおりです。

   **有効** — 画面ロック時の接続解除が有効です

   **disabled** – 画面ロック時の接続解除は無効です (デフォルト)

## Ubuntu WorkSpaces 管理者に SSH アクセスを付与する
<a name="grant_ssh_access_ubuntu"></a>

デフォルトでは、割り当て済みユーザーおよびドメイン管理者グループのアカウントのみが SSH を使用して Ubuntu WorkSpaces に接続できます。SSH を使用して他のユーザーやアカウントが Ubuntu WorkSpaces に接続できるようにするには、Active Directory で Ubuntu WorkSpaces 管理者専用の管理者グループを作成することをお勧めします。

**`Linux_WorkSpaces_Admins` Active Directory グループのメンバーの sudo アクセスを有効にするには**

1. 次の例に示すように、`sudoers` を使用して `visudo` ファイルを編集します。

   ```
   [username@workspace-id ~]$ sudo visudo
   ```

1. 次の行を追加します。

   ```
   %Linux_WorkSpaces_Admins ALL=(ALL) ALL
   ```

専用の管理者グループを作成したら、次のステップに従ってグループのメンバーのログインを有効にします。

**`Linux_WorkSpaces_Admins` Active Directory グループのメンバーのログインを有効にするには**

1. 昇格された権限で `etc/security/access.conf` を編集します。

   ```
   [username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. 次の行を追加します。

   ```
   +:(Linux_WorkSpaces_Admins):ALL
   ```

 Ubuntu WorkSpaces では、SSH 接続のユーザー名を指定する際にドメイン名を追加する必要はなく、パスワード認証はデフォルトで無効になっています。SSH 経由で接続するには、Ubuntu WorkSpace の `$HOME/.ssh/authorized_keys` に SSH パブリックキーを追加するか、`/etc/ssh/sshd_config` を編集して `yes` に PasswordAuthentication を設定する必要があります。SSH 接続の有効化の詳細については、「[Linux WorkSpace で SSH 接続を有効化する](https://docs.aws.amazon.com/workspaces/latest/adminguide/connect-to-linux-workspaces-with-ssh.html)」を参照してください。

## Ubuntu WorkSpace のデフォルトシェルを無効にする
<a name="override_default_shell_ubuntu"></a>

Ubuntu WorkSpace のデフォルトシェルを無効にするには、ユーザーの `~/.bashrc` ファイルを編集することをお勧めします。たとえば、`Z shell` シェルの代わりに `Bash` を使用するには、`/home/username/.bashrc` に次の行を追加します。

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**注記**  
この変更を行った後、WorkSpace を再起動するか (切断だけでなく) WorkSpace からログアウトし、再度ログインして変更を有効にする必要があります。

## Ubuntu WorkSpaces での認証にスマートカードを使用する
<a name="linux_smart_cards"></a>

Ubuntu WorkSpaces バンドルでは、認証に [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) および [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) スマートカードを使用できます。詳細については、「[WorkSpaces Personal での認証にスマートカードを使用する](smart-cards.md)」を参照してください。

## インターネットアクセス用のデバイスプロキシサーバー設定を構成する
<a name="gp_device_proxy_ubuntu"></a>

デフォルトでは、WorkSpaces クライアントアプリケーションは、デバイスオペレーティングシステム設定で HTTPS (ポート 443) トラフィック用に指定したプロキシサーバーを使用します。Amazon WorkSpaces クライアントアプリケーションは、更新、登録、認証に HTTPS ポートを使用します。

**注記**  
サインイン認証情報を使用した認証を必要とするプロキシサーバーはサポートされていません。

Microsoft ドキュメントの「[デバイスプロキシとインターネット接続の設定の構成](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet)」の手順に従って、グループポリシーを通じて Ubuntu WorkSpaces のデバイスプロキシサーバー設定を構成できます。

WorkSpaces Windows クライアントアプリケーションでのプロキシ設定の構成の詳細については、「Amazon WorkSpaces ユーザーガイド」の「[プロキシサーバー](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-windows-client.html#windows_proxy_server)」を参照してください。

WorkSpaces macOS クライアントアプリケーションでのプロキシ設定の構成の詳細については、「*Amazon WorkSpaces User Guide*」の「[Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-osx-client.html#osx_proxy_server)」を参照してください。

WorkSpaces Web Access クライアントアプリケーションでのプロキシ設定の構成の詳細については、「*Amazon WorkSpaces User Guide*」の「[Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-web-access.html#web-access-proxy)」を参照してください。

### デスクトップトラフィックのプロキシ
<a name="w2aac11c29c15c29c15"></a>

PCoIP WorkSpaces の場合、デスクトップクライアントアプリケーションは、UDP のポート 4172 トラフィック (デスクトップトラフィック) に対するプロキシサーバーの使用も、TLS の復号と検査もサポートしていません。ポート 4172 に直接接続する必要があります。

DCV WorkSpaces の場合、WorkSpaces Windows クライアントアプリケーション (バージョン 5.1 以降) と macOS クライアントアプリケーション (バージョン 5.4 以降) は、ポート 4195 TCP トラフィックに対する HTTP プロキシサーバーの使用をサポートしています。TLS の復号および検査はサポートしていません。

DCV は、UDP 経由のデスクトップトラフィックに対するプロキシの使用をサポートしていません。TCP トラフィックに対するプロキシの使用をサポートしているのは、WorkSpaces Windows および macOS デスクトップクライアントアプリケーションと Web Access のみです。

**注記**  
プロキシサーバーを使用する場合、クライアントアプリケーションが WorkSpaces サービスに対して行う API コールもプロキシされます。API コールとデスクトップトラフィックの両方が同じプロキシサーバーを通過する必要があります。

### プロキシサーバーの使用に関する推奨事項
<a name="w2aac11c29c15c29c17"></a>

WorkSpaces デスクトップトラフィックでのプロキシサーバーの使用はお勧めしません。

Amazon WorkSpaces デスクトップトラフィックは既に暗号化されているため、プロキシを使用してもセキュリティは向上しません。プロキシを使用すると、ネットワークパスに余分なホップが発生してレイテンシーをもたらし、ストリーミング品質に影響する可能性があります。プロキシのサイズがデスクトップストリーミングトラフィックの処理に適切でない場合、プロキシによってスループットが低下する可能性もあります。さらに、ほとんどのプロキシは長時間実行される WebSocket (TCP) 接続をサポートするようには設計されていないため、ストリーミングの品質と安定性に影響する可能性があります。

プロキシを使用する必要がある場合は、ストリーミングの品質と応答性に悪影響を及ぼす可能性のあるネットワークレイテンシーの増大を避けるため、プロキシサーバーを WorkSpace クライアントのできるだけ近く、できれば同じネットワーク内に配置してください。

# Rocky Linux WorkSpaces を管理する
<a name="manage_rockylinux_workspace"></a>

Rocky Linux WorkSpaces は、[Ansible](https://www.ansible.com/) などの設定および管理ソリューションを使用して管理できます。

**注記**  
Rocky Linux ソフトウェアに含まれる著作権、商標、またはその他の所有権もしくは機密性に関する通知を削除、変更、または隠蔽することはできません。

## Rocky Linux WorkSpaces で DCV の動作を制御する
<a name="wsp_rockylinux"></a>

DCV の動作は、`/etc/wsp/` ディレクトリにある `wsp.conf` ファイルの構成設定によって制御されます。ポリシーの変更をデプロイして適用するには、Rocky Linux をサポートする設定管理ソリューションを使用します。変更はすべて、エージェントの起動時に有効になります。

**注記**  
誤った変更またはサポートされていない変更を加えた場合、WorkSpace に新たに確立された接続に `wsp.conf` ポリシーが適用されない場合があります。

以降のセクションでは、特定の機能を有効または無効にする方法について説明します。

## Rocky Linux WorkSpaces のクリップボードリダイレクトを有効化/無効化する
<a name="rockylinux_clipboard"></a>

デフォルトでは、WorkSpaces はクリップボードのリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Rocky Linux WorkSpaces のクリップボードリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   clipboard = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – クリップボードリダイレクトは両方向ともに有効です (デフォルト)

   **disabled** – クリップボードリダイレクトは両方向ともに無効です

   **[paste-only]** (ペーストのみ) — クリップボードのリダイレクトが有効で、ローカルクライアントデバイスからコンテンツをコピーし、リモートホストデスクトップにペーストするのみが可能です。

   **[copy-only]** (コピーのみ) — クリップボードのリダイレクトが有効で、リモートホストのデスクトップからコンテンツをコピーし、ローカルのクライアントデバイスにペーストするのみが可能です。

## Rocky Linux WorkSpaces のオーディオ入力リダイレクトを有効化/無効化する
<a name="rockylinux_audio"></a>

デフォルトでは、WorkSpaces はオーディオインリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Rocky Linux WorkSpaces のオーディオ入力リダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   audio-in = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – オーディオ入力リダイレクトは有効です (デフォルト)

   **disabled** – オーディオ入力リダイレクトは無効です

## Rocky Linux WorkSpaces のビデオ入力リダイレクトを有効化または無効化する
<a name="rockylinux_video"></a>

デフォルトでは、WorkSpaces はビデオインリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Rocky Linux WorkSpaces のビデオ入力リダイレクトを有効化または無効化するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   video-in = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – ビデオ入力リダイレクトは有効です (デフォルト)

   **disabled** – ビデオ入力リダイレクトは無効です

## Rocky Linux WorkSpaces のタイムゾーンのリダイレクトを有効化/無効化する
<a name="rockylinux-time-zone"></a>

デフォルトでは、WorkSpaces 内の時間は、WorkSpaces への接続に使用されているクライアントのタイムゾーンを反映するように設定されます。この動作は、タイムゾーンのリダイレクトによって制御されます。次のような理由から、タイムゾーンのリダイレクトをオフにすることもできます。
+ 会社は、すべての従業員が特定のタイムゾーンで業務を行うことを希望している (一部の従業員が他のタイムゾーンにいる場合でも)。
+ WorkSpaces で、特定のタイムゾーン内の特定の時刻に実行するタスクをスケジュールした。
+ よく出張するユーザーが、一貫性と個人設定のため WorkSpaces を 1 つのタイムゾーンにまとめておきたいと考えている。

必要に応じて、DCV 設定ファイルを使用してこの機能を設定します。

**Rocky Linux WorkSpaces のタイムゾーンのリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   timezone-redirection = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – タイムゾーンのリダイレクトは有効です (デフォルト)

   **disabled** – タイムゾーンのリダイレクトは無効です

## Rocky Linux WorkSpaces のプリンターリダイレクトを有効化または無効化する
<a name="rockylinux_printer"></a>

デフォルトでは、WorkSpaces はプリンターリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Rocky Linux WorkSpaces のプリンターリダイレクトを有効化または無効化するには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   remote-printing = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – プリンターリダイレクトは有効です (デフォルト)

   **disabled** – プリンターリダイレクトは無効です

## DCV の画面ロック時におけるセッションの切断を有効または無効にする
<a name="rockylinux_screenlock"></a>

画面ロック時におけるセッションの切断を有効にすると、ロック画面が検出されたときにユーザーが WorkSpaces セッションを終了できます。WorkSpaces クライアントから再接続するには、WorkSpaces で有効になっている認証の種類に応じて、ユーザーはパスワードまたはスマートカードを使用して自分自身を認証できます。

デフォルトでは、WorkSpaces は画面ロックによるセッションの切断をサポートしていません。必要に応じて、DCV 設定ファイルを使用してこの機能を有効にします。

**Rocky Linux WorkSpaces の画面ロック時におけるセッションの切断を有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   disconnect-on-lock = X
   ```

   *X* に指定できる値は以下のとおりです。

   **有効** — 画面ロック時の接続解除が有効です

   **disabled** – 画面ロック時の接続解除は無効です (デフォルト)

## Rocky Linux WorkSpaces 管理者に SSH アクセスを付与する
<a name="grant_ssh_access_rockylinux"></a>

デフォルトでは、割り当て済みユーザーおよびドメイン管理者グループのアカウントのみが SSH を使用して Rocky Linux WorkSpaces に接続できます。SSH を使用して他のユーザーやアカウントが Rocky Linux WorkSpaces に接続できるようにするには、Active Directory で Rocky Linux WorkSpaces 管理者専用の管理者グループを作成することをお勧めします。

**`Linux_WorkSpaces_Admins` Active Directory グループのメンバーの sudo アクセスを有効にするには**

1. 次の例に示すように、`sudoers` を使用して `visudo` ファイルを編集します。

   ```
   [username@workspace-id ~]$ sudo visudo
   ```

1. 次の行を追加します。

   ```
   %Linux_WorkSpaces_Admins ALL=(ALL) ALL
   ```

専用の管理者グループを作成したら、次のステップに従ってグループのメンバーのログインを有効にします。

**`Linux_WorkSpaces_Admins` Active Directory グループのメンバーのログインを有効にするには**

1. 昇格された権限で `etc/security/access.conf` を編集します。

   ```
   [username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. 次の行を追加します。

   ```
   +:(Linux_WorkSpaces_Admins):ALL
   ```

 Rocky Linux WorkSpaces では、SSH 接続のユーザー名を指定する際にドメイン名を追加する必要はなく、パスワード認証はデフォルトで無効になっています。SSH 経由で接続するには、Rocky Linux WorkSpace の `$HOME/.ssh/authorized_keys` に SSH パブリックキーを追加するか、`/etc/ssh/sshd_config` を編集して PasswordAuthentication を `yes` に設定する必要があります。SSH 接続の有効化の詳細については、「[Linux WorkSpace で SSH 接続を有効化する](https://docs.aws.amazon.com/workspaces/latest/adminguide/connect-to-linux-workspaces-with-ssh.html)」を参照してください。

## Rocky Linux WorkSpaces のデフォルトシェルを上書きする
<a name="override_default_shell_rockylinux"></a>

Rocky Linux WorkSpaces のデフォルトシェルを上書きするには、ユーザーの `~/.bashrc` ファイルを編集することをお勧めします。たとえば、`Z shell` シェルの代わりに `Bash` を使用するには、`/home/username/.bashrc` に次の行を追加します。

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**注記**  
この変更を行った後、WorkSpace を再起動するか (切断だけでなく) WorkSpace からログアウトし、再度ログインして変更を有効にする必要があります。

## Rocky Linux WorkSpaces での認証にスマートカードを使用する
<a name="linux_smart_cards"></a>

Rocky Linux WorkSpaces バンドルでは、認証に [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) と [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) スマートカードを使用できます。詳細については、「[WorkSpaces Personal での認証にスマートカードを使用する](smart-cards.md)」を参照してください。

# Red Hat Enterprise Linux WorkSpaces の管理
<a name="manage_rhel_workspace"></a>

Ansible などの設定および管理ソリューションを使用して、Red Hat Enterprise Linux WorkSpaces を管理できます。 [https://www.ansible.com/](https://www.ansible.com/)

## Red Hat Enterprise Linux WorkSpaces で DCV の動作を制御する
<a name="wsp_rhel"></a>

DCV の動作は、`/etc/wsp/` ディレクトリにある `wsp.conf` ファイルの構成設定によって制御されます。ポリシーの変更をデプロイして適用するには、Red Hat Enterprise Linux をサポートする設定管理ソリューションを使用します。変更はすべて、エージェントの起動時に有効になります。

**注記**  
誤った変更またはサポートされていない変更を加えた場合、WorkSpace に新たに確立された接続に `wsp.conf` ポリシーが適用されない場合があります。

以降のセクションでは、特定の機能を有効または無効にする方法について説明します。

## Red Hat Enterprise Linux WorkSpaces のクリップボードのリダイレクトを有効または無効にする
<a name="rhel_clipboard"></a>

デフォルトでは、WorkSpaces はクリップボードのリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Red Hat Enterprise Linux WorkSpaces のクリップボードのリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   clipboard = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – クリップボードリダイレクトは両方向ともに有効です (デフォルト)

   **disabled** – クリップボードリダイレクトは両方向ともに無効です

   **[paste-only]** (ペーストのみ) — クリップボードのリダイレクトが有効で、ローカルクライアントデバイスからコンテンツをコピーし、リモートホストデスクトップにペーストするのみが可能です。

   **[copy-only]** (コピーのみ) — クリップボードのリダイレクトが有効で、リモートホストのデスクトップからコンテンツをコピーし、ローカルのクライアントデバイスにペーストするのみが可能です。

## Red Hat Enterprise Linux WorkSpaces のオーディオ入力リダイレクトを有効または無効にする
<a name="rhel_audio"></a>

デフォルトでは、WorkSpaces はオーディオインリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Red Hat Enterprise Linux WorkSpaces のオーディオ入力リダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   audio-in = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – オーディオ入力リダイレクトは有効です (デフォルト)

   **disabled** – オーディオ入力リダイレクトは無効です

## Red Hat Enterprise Linux WorkSpaces のビデオ入力リダイレクトを有効または無効にする
<a name="rhel_video"></a>

デフォルトでは、WorkSpaces はビデオインリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Red Hat Enterprise Linux WorkSpaces のビデオ入力リダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   video-in = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – ビデオ入力リダイレクトは有効です (デフォルト)

   **disabled** – ビデオ入力リダイレクトは無効です

## Red Hat Enterprise Linux WorkSpaces のタイムゾーンのリダイレクトを有効または無効にする
<a name="rhel-time-zone"></a>

デフォルトでは、WorkSpaces 内の時間は、WorkSpaces への接続に使用されているクライアントのタイムゾーンを反映するように設定されます。この動作は、タイムゾーンのリダイレクトによって制御されます。次のような理由から、タイムゾーンのリダイレクトをオフにすることもできます。
+ 会社は、すべての従業員が特定のタイムゾーンで業務を行うことを希望している (一部の従業員が他のタイムゾーンにいる場合でも)。
+ WorkSpaces で、特定のタイムゾーン内の特定の時刻に実行するタスクをスケジュールした。
+ よく出張するユーザーが、一貫性と個人設定のため WorkSpaces を 1 つのタイムゾーンにまとめておきたいと考えている。

必要に応じて、DCV 設定ファイルを使用してこの機能を設定します。

**Red Hat Enterprise Linux WorkSpaces のタイムゾーンのリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   timezone-redirection = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – タイムゾーンのリダイレクトは有効です (デフォルト)

   **disabled** – タイムゾーンのリダイレクトは無効です

## Red Hat Enterprise Linux WorkSpaces のプリンターリダイレクトを有効または無効にする
<a name="rhel_printer"></a>

デフォルトでは、WorkSpaces はプリンターリダイレクトをサポートしています。必要に応じて、DCV 設定ファイルを使用してこの機能を無効にします。

**Red Hat Enterprise Linux WorkSpaces のプリンターリダイレクトを有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   remote-printing = X
   ```

   *X* に指定できる値は以下のとおりです。

   **enabled** – プリンターリダイレクトは有効です (デフォルト)

   **disabled** – プリンターリダイレクトは無効です

## DCV の画面ロック時におけるセッションの切断を有効または無効にする
<a name="rhel_screenlock"></a>

画面ロック時におけるセッションの切断を有効にすると、ロック画面が検出されたときにユーザーが WorkSpaces セッションを終了できます。WorkSpaces クライアントから再接続するには、WorkSpaces で有効になっている認証の種類に応じて、ユーザーはパスワードまたはスマートカードを使用して自分自身を認証できます。

デフォルトでは、WorkSpaces は画面ロックによるセッションの切断をサポートしていません。必要に応じて、DCV 設定ファイルを使用してこの機能を有効にします。

**Red Hat Enterprise Linux WorkSpaces の画面ロック時におけるセッションの切断を有効または無効にするには**

1. 次のコマンドを使用して、昇格された権限を持つエディタで `wsp.conf` ファイルを開きます。

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. `[policies]` グループの末尾に次の行を追加します。

   ```
   disconnect-on-lock = X
   ```

   *X* に指定できる値は以下のとおりです。

   **有効** — 画面ロック時の接続解除が有効です

   **disabled** – 画面ロック時の接続解除は無効です (デフォルト)

## Red Hat Enterprise Linux WorkSpaces 管理者に SSH アクセスを付与する
<a name="grant_ssh_access_rhel"></a>

デフォルトでは、割り当て済みユーザーおよびドメイン管理者グループのアカウントのみが SSH を使用して Red Hat Enterprise Linux WorkSpaces に接続できます。SSH を使用して他のユーザーやアカウントが Red Hat Enterprise Linux WorkSpaces に接続できるようにするには、Active Directory で Red Hat Enterprise Linux WorkSpaces 管理者専用の管理者グループを作成することをお勧めします。

**`Linux_WorkSpaces_Admins` Active Directory グループのメンバーの sudo アクセスを有効にするには**

1. 次の例に示すように、`sudoers` を使用して `visudo` ファイルを編集します。

   ```
   [username@workspace-id ~]$ sudo visudo
   ```

1. 次の行を追加します。

   ```
   %Linux_WorkSpaces_Admins ALL=(ALL) ALL
   ```

専用の管理者グループを作成したら、次のステップに従ってグループのメンバーのログインを有効にします。

**`Linux_WorkSpaces_Admins` Active Directory グループのメンバーのログインを有効にするには**

1. 昇格された権限で `etc/security/access.conf` を編集します。

   ```
   [username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. 次の行を追加します。

   ```
   +:(Linux_WorkSpaces_Admins):ALL
   ```

 Red Hat Enterprise Linux WorkSpaces では、SSH 接続のユーザー名を指定する際にドメイン名を追加する必要はなく、パスワード認証はデフォルトで無効になっています。SSH 経由で接続するには、Red Hat Enterprise Linux WorkSpace の `$HOME/.ssh/authorized_keys` に SSH パブリックキーを追加するか、`/etc/ssh/sshd_config` を編集して PasswordAuthentication を `yes` に設定する必要があります。SSH 接続の有効化の詳細については、「[Linux WorkSpace で SSH 接続を有効化する](https://docs.aws.amazon.com/workspaces/latest/adminguide/connect-to-linux-workspaces-with-ssh.html)」を参照してください。

## Red Hat Enterprise Linux WorkSpaces のデフォルトシェルを上書きする
<a name="override_default_shell_rhel"></a>

Red Hat Enterprise Linux WorkSpaces のデフォルトシェルを上書きするには、ユーザーの `~/.bashrc` ファイルを編集することをお勧めします。たとえば、`Z shell` シェルの代わりに `Bash` を使用するには、`/home/username/.bashrc` に次の行を追加します。

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**注記**  
この変更を行った後、WorkSpace を再起動するか (切断だけでなく) WorkSpace からログアウトし、再度ログインして変更を有効にする必要があります。

## Red Hat Enterprise Linux WorkSpaces での認証にスマートカードを使用する
<a name="linux_smart_cards"></a>

Red Hat Enterprise Linux WorkSpaces バンドルでは、認証に [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) および [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) スマートカードを使用できます。詳細については、「[WorkSpaces Personal での認証にスマートカードを使用する](smart-cards.md)」を参照してください。

# WorkSpaces Personal でリアルタイム通信用に WorkSpaces を最適化する
<a name="communication-optimization"></a>

Amazon WorkSpaces には、Microsoft Teams、Zoom、Webex などのユニファイドコミュニケーション (UC) アプリケーションのデプロイを円滑化するさまざまな手法が用意されています。現代のアプリケーション環境では、ほとんどの UC アプリケーションに、1:1 チャットルーム、共同グループチャットチャネル、シームレスなファイルストレージと交換、ライブイベント、ウェビナー、ブロードキャスト、インタラクティブな画面共有と制御、ホワイトボード、オフラインのオーディオ/ビデオメッセージング機能などのさまざまな機能が備わっています。この機能のほとんどは、追加の微調整や機能強化が不要で、WorkSpaces で標準機能としてシームレスに使用できます。ただし、リアルタイムのコミュニケーション要素、特に 1 対 1 の通話と集合的なグループ会議は、この規則の例外となるため注意してください。このような機能を適切に組み込むには、しばしば、WorkSpaces のデプロイプロセス中に目的達成に特化した重点的な取り組みと計画が求められます。

Amazon WorkSpaces での UC アプリケーションのリアルタイム通信機能の実装を計画する場合、3 つの異なるリアルタイム通信 (RTC) 設定モードを選択できます。選択するモードは、ユーザーに提供される 1 つまたは複数の特定のアプリケーションと、使用する予定のクライアントデバイスによって異なります。

このドキュメントでは、Amazon WorkSpaces で最も一般的な UC アプリケーションのユーザーエクスペリエンスの最適化に焦点を当てています。WorkSpaces Core 固有の最適化については、パートナー固有のドキュメントを参照してください。

**Topics**
+ [メディア最適化モードの概要](#media-optimization-modes-overview)
+ [使用する RTC 最適化モードについて](#choosing-optimization-mode)
+ [RTC 最適化ガイダンス](#rtc-optimization-guidance)

## メディア最適化モードの概要
<a name="media-optimization-modes-overview"></a>

使用可能なメディア最適化オプションは次のとおりです。

### オプション 1: メディア最適化リアルタイム通信 (メディア最適化 RTC)
<a name="media-optimized-rtc"></a>

このモードでは、サードパーティの UC および VoIP アプリケーションがリモート WorkSpace で実行され、直接通信のためにメディアフレームワークはサポートされるクライアントにオフロードされます。以下の UC アプリケーションは、Amazon WorkSpaces でこのアプローチを使用しています。
+ [Zoom Meetings](https://support.zoom.us/hc/en-us/articles/10372235268749-Using-Zoom-for-Amazon-WorkSpaces)
+ [Cisco Webex Meetings](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/vdi/wbx-vdi-deployment-guide.html)
+ [Microsoft Teams 2.0 (パブリックプレビュー)](https://learn.microsoft.com/en-us/microsoftteams/vdi-2)

メディア最適化 RTC モードが機能するには、UC アプリケーションベンダーは、[DCV 拡張機能 SDK](https://docs.aws.amazon.com/dcv/latest/extsdkguide/what-is.html) などの入手可能な Software Development Kits (SDK) のいずれかを使用して、WorkSpaces との統合を開発する必要があります。このモードでは、UC コンポーネントをクライアントデバイスにインストールする必要があります。

このモードの設定の詳細については、「[メディア最適化 RTC の設定](#configure-media-optimized-rtc)」を参照してください。

### オプション 2: セッション中最適化リアルタイム通信 (セッション中最適化 RTC)
<a name="in-session-optimized-rtc"></a>

このモードでは、未変更の UC アプリケーションが WorkSpace 上で実行され、オーディオとビデオのトラフィックが DCV を経由してクライアントデバイスに送られます。マイクからのローカルオーディオとウェブカメラからのビデオストリームは、WorkSpace にリダイレクトされ、UC アプリケーションで使用されます。このモードは幅広いアプリケーション互換性を備えており、UC アプリケーションをリモート WorkSpace からさまざまなクライアントプラットフォームに効率的に配信します。UC アプリケーションコンポーネントをクライアントデバイスにデプロイする必要はありません。

このモードの設定の詳細については、「[セッション中最適化 RTC の設定](#configure-in-session-optimized-rtc)」を参照してください。

### オプション 3: 直接リアルタイム通信 (直接 RTC)
<a name="direct-rtc"></a>

このモードでは、WorkSpace 内で動作するアプリケーションが、ユーザーのデスクまたはクライアント OS にある物理電話セットまたは仮想電話セットを制御します。これにより、音声トラフィックは、ユーザーのワークステーションの物理電話またはクライアントデバイス上で動作する仮想電話からリモートコールピアに直接トラバースします。このモードで機能するアプリケーションの注目すべき例には以下が含まれます。
+ [Amazon WorkSpaces 向けの Amazon Connect の最適化](https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/connect-optimization.html)
+ [Genesys Cloud WebRTC Media Helper](https://help.mypurecloud.com/articles/about-webrtc-media-helper/)
+ [Microsoft Teams SIP ゲートウェイ](https://learn.microsoft.com/en-us/microsoftteams/sip-gateway-plan)
+ [Microsoft Teams 卓上電話機と Teams ディスプレイ](https://www.microsoft.com/en-us/microsoft-teams/across-devices/devices/category/desk-phones-teams-displays/34)
+ UC アプリケーションのダイヤルインまたは「dial my phone」機能による音声会議への参加。

このモードの設定の詳細については、「[直接 RTC の設定](#configure-direct-rtc)」を参照してください。

## 使用する RTC 最適化モードについて
<a name="choosing-optimization-mode"></a>

異なる RTC 最適化モードを同時に使用することも、フォールバックとして互いに補完するように設定することもできます。たとえば、Cisco Webex Meetings 向けにディア最適化 RTC を有効にするとします。この構成により、ユーザーがデスクトップクライアントから WorkSpace にアクセスするときの通信が最適化されます。ただし、UC 最適化コンポーネントが組み込まれていない共有インターネットキオスクから Webex にアクセスするシナリオでは、Webex はセッション中最適化 RTC モードにシームレスに移行して機能を維持します。ユーザーが複数の UC アプリケーションを使用する場合は、RTC 設定モードがユーザー固有の要件に基づいて異なる場合があります。

以下の表に UC アプリケーションの一般的な機能を示します。ここでは、どの RTC 設定モードが最良の結果をもたらすかが定義されています。


| 機能 | 直接 RTC | メディア最適化 RTC | セッション中最適化 RTC | 
| --- | --- | --- | --- | 
| **1:1 チャット** | RTC 設定は不要 | 
| **グループチャットルーム** | RTC 設定は不要 | 
| **グループオーディオ会議** | Best |  = ベスト | 良好 | 
| **グループビデオ会議** | 良好 |  = ベスト | 良好 | 
| **1 対 1 のオーディオ通話** | Best |  = ベスト | 良好 | 
| **1 対 1 のビデオ通話** | 良好 |  = ベスト | 良好 | 
| **ホワイトボード** | RTC 設定は不要 | 
| **オーディオ/ビデオクリップ/メッセージング** | 該当しない | 良好 | Best | 
| **ファイル共有** | 該当しない | UC アプリケーションによって異なる | Best | 
| **画面の共有と制御** | 該当しない | UC アプリケーションによって異なる | Best | 
| **ウェビナー/イベントのブロードキャスト** | 該当しない | 良好 | Best | 

## RTC 最適化ガイダンス
<a name="rtc-optimization-guidance"></a>

### メディア最適化 RTC の設定
<a name="configure-media-optimized-rtc"></a>

メディア最適化 RTC モードは、Amazon によって提供される SDK を使用する UC アプリケーションベンダーによって設定されます。このアーキテクチャでは、UC ベンダーが UC 固有のプラグインまたは拡張機能を開発し、それをクライアントにデプロイする必要があります。

SDK には、DCV Extension SDK やカスタマイズされたプライベートバージョンなどの公開オプションが含まれています。SDK によって、WorkSpace 内で動作する UC アプリケーションモジュールとクライアント側のプラグイン間で制御チャネルが確立されます。通常、この制御チャネルはクライアント拡張機能に通話の開始または通話への参加を指示します。クライアント側拡張機能を通じて通話が確立されると、UC プラグインはマイクからの音声とウェブカメラからのビデオをキャプチャし、それらを UC クラウドまたはコールピアに直接送信します。受信した音声はローカルで再生され、ビデオはリモートクライアント UI にオーバーレイされます。制御チャネルは通話のステータスを伝達します。

![\[メディア最適化 RTC の設定を示す図。\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/images/media-optimized-rtc.png)


Amazon WorkSpaces は現在、メディア最適化 RTC モードでは以下のアプリケーションをサポートしています。
+ [Zoom Meetings](https://support.zoom.us/hc/en-us/articles/10372235268749-Using-Zoom-for-Amazon-WorkSpaces) (PCoIP および DCV WorkSpaces)
+ [Cisco Webex Meetings](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/vdi/wbx-vdi-deployment-guide.html) (DCV WorkSpaces のみ)
+ [Microsoft Teams 2.0 (パブリックプレビュー)](https://learn.microsoft.com/en-us/microsoftteams/vdi-2) (DCV WorkSpaces のみ)

リストに含まれていないアプリケーションを使用する場合は、アプリケーションベンダーに連絡し、WorkSpaces メディア最適化 RTC のサポートをリクエストすることをお勧めします。このプロセスをより迅速に行うには、[aws-av-offloading@amazon.com](mailto:aws-av-offloading@amazon.com) にお問い合わせください。

メディア最適化 RTC モードにすると通話パフォーマンスが向上し、WorkSpace リソースの使用率が最小限に抑えられますが、一定の制限があります。
+ UC クライアント拡張機能をクライアントデバイスにインストールする必要があります。
+ UC クライアント拡張機能は、独立した管理と更新が必要です。
+ UC クライアント拡張機能は、モバイルプラットフォームやウェブクライアントなど、特定のクライアントプラットフォームでは使用できない場合があります。
+ このモードでは、画面共有の動作が異なる場合があるなど、UC アプリケーションの機能の一部が制限されることがあります。
+ クライアント側拡張機能の使用は、Bring-Your-Own-Device (BYOD) や共有キオスクなどのシナリオには適さない場合があります。

メディア最適化 RTC モードがユーザーの環境に適さない場合や、特定のユーザーがクライアント拡張機能をインストールできない場合は、フォールバックオプションとしてセッション中最適化 RTC モードを設定することをお勧めします。

### セッション中最適化 RTC の設定
<a name="configure-in-session-optimized-rtc"></a>

セッション中最適化 RTC モードでは、何も変更を行わなくとも UC アプリケーションが WorkSpace 上で動作し、ローカルのようなエクスペリエンスを提供します。アプリケーションによって生成されたオーディオストリームとビデオストリームは、DCV によってキャプチャされ、クライアント側に送信されます。クライアントでは、マイク (DCV と PCoIP WorkSpaces の両方) とウェブカメラ (DCV WorkSpaces のみ) の信号がキャプチャされ、WorkSpace にリダイレクトされて、シームレスに UC アプリケーションに渡されます。

特に、このオプションはレガシーアプリケーションとの互換性が非常に高く、アプリケーションのオリジンに関係なく一貫したユーザーエクスペリエンスを提供できます。セッション中最適化はウェブクライアントでも機能します。

![\[セッション中最適化 RTC の設定を示す図。\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/images/in-session-optimized-rtc.png)


DCV は、リモート RTC モードのパフォーマンスを高めるために細心の注意を払って最適化されています。最適化手段には以下が含まれます。
+ アダプティブ UDP ベース QUIC トランスポートを利用し、効率的なデータ転送を保証します。
+ 低遅延オーディオパスを確立し、高速なオーディオ入出力を容易にします。
+ 音声用に最適化されたオーディオコーデックを実装することで、CPU とネットワークの使用量を抑えながらオーディオ品質を維持します。
+ ウェブカメラのリダイレクト。ウェブカメラ機能を統合できるようになります。
+ パフォーマンスを最適化するためのウェブカメラの解像度の設定。
+ 速度と画質のバランスをとる適応型ディスプレイコーデックの統合。
+ オーディオジッター補正。スムーズなオーディオ伝送を保証します。

これらの最適化により、リモート RTC モードでの堅牢でスムーズなエクスペリエンスが実現します。

#### 推奨サイズ
<a name="sizing-recommendations"></a>

リモート RTC モードを効果的にサポートするには、Amazon WorkSpaces のサイズを適切に設定することが重要です。リモート WorkSpace は、それぞれのユニファイドコミュニケーション (UC) アプリケーションのシステム要件を満たすか、それを上回る必要があります。次の表は、一般的な UC アプリケーションをビデオ通話や音声通話に使用する場合の WorkSpaces の最小サポート設定と推奨設定の概要を示しています。


|   | ビデオ通話 | 音声通話 |   | アプリケーション | RTC アプリの CPU 要件 | RTC アプリの RAM 要件 | 最低限のサポート対象 WorkSpace | 推奨 WorkSpace | 最低限のサポート対象 WorkSpace | 推奨 WorkSpace | リファレンス | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| Microsoft Teams | 2 コア (必須)、4 コア (推奨) | 4.0 GB RAM | Power (4 vCPU、16 GB メモリ) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/communication-optimization.html)  | Performance (2 vCPU、8 GB メモリ) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/communication-optimization.html)  | [Microsoft Teams のハードウェア要件](https://learn.microsoft.com/en-us/microsoftteams/hardware-requirements-for-the-teams-app) | 
| Zoom | 2 コア (必須)、4 コア (推奨) | 4.0 GB RAM | Power (4 vCPU、16 GB メモリ) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/communication-optimization.html)  | Performance (2 vCPU、8 GB メモリ) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/communication-optimization.html)  | [Zoom システム要件: Windows、macOS、Linux](https://support.zoom.us/hc/en-us/articles/201362023-Zoom-system-requirements-Windows-macOS-Linux) | 
| Webex | 2 コア (必須) | 4.0 GB RAM | Power (4 vCPU、16 GB メモリ) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/communication-optimization.html)  | Performance (2 vCPU、8 GB メモリ) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/communication-optimization.html)  | [Webex サービスのシステム要件](https://help.webex.com/en-us/article/fz1e4b/System-requirements-for-Webex-services) | 

ビデオ会議では、ビデオのエンコードとデコードに大量のリソースが使用されることに注意してください。物理マシンのシナリオでは、これらのタスクは GPU にオフロードされます。GPU 以外の WorkSpaces では、これらのタスクはリモートプロトコルエンコーディングと同時に CPU 上で実行されます。したがって、動画ストリーミングやビデオ通話を定期的に行うユーザーには、PowerPro 以上の構成を選択することを強くお勧めします。

また、画面共有はリソースを大量に消費します。解像度が高くなると、リソースの消費量も増加します。その結果、GPU 以外の WorkSpaces で、画面共有はより低いフレームレートに制限されることがよくあります。

#### UDP ベースの QUIC トランスポートを DCV に活用する
<a name="leaverage-udp-based-quic-transport"></a>

UDP トランスポートは、特に RTC アプリケーションの送信に適しています。効率を最大化するには、QUIC トランスポートを DCV に活用するようにネットワークを設定してください。UDP ベースのトランスポートはネイティブクライアントでしか使用できないことに注意してください。

#### WorkSpaces 用の UC アプリケーションの設定
<a name="configure-uc-application"></a>

背景ぼかし、仮想背景、リアクション、ライブイベントのホスティングなど、強化されたビデオ処理機能を使用する場合は、最適なパフォーマンスを実現するために GPU 対応の WorkSpace を選択することが不可欠です。

ほとんどの UC アプリケーションには、GPU 以外の WorkSpaces の CPU 使用率を低減させるために、高度なビデオ処理を無効にするガイダンスが用意されています。

詳細については、以下のリソースを参照してください。
+ Microsoft Teams: [仮想デスクトップ インフラストラクチャ用の Teams](https://https://learn.microsoft.com/en-us/microsoftteams/vdi-2)
+ Zoom Meetings: [Managing the user experience for incompatible VDI plugins](https://support.zoom.us/hc/en-us/articles/4411856902285-Managing-the-user-experience-for-incompatible-VDI-plugins-)
+ Webex: [Deployment guide for Webex App for Virtual Desktop Infrastructure (VDI) - Manage and troubleshoot Webex App for VDI [Webex App]](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/vdi/wbx-vdi-deployment-guide/manage-teams-vdi.html#id_138538)
+ Google Meet: [Using VDI](https://support.google.com/a/answer/1279090?hl=en#VDI)

#### オーディオとウェブカメラの双方向リダイレクトを有効にする
<a name="enable-bi-directional-audio-webcam-redirection"></a>

Amazon WorkSpaces は本質的に、オーディオ入力、オーディオ出力、ビデオインによるカメラリダイレクトをデフォルトでサポートしています。ただし、特定の理由でこれらの機能が無効になっている場合、提供されているガイダンスに従ってリダイレクトを再度有効にできます。詳細については、「*Amazon WorkSpaces 管理ガイド*」の「[DCV のビデオ入力リダイレクトを有効または無効にする](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_video_in_wsp)」を参照してください。ユーザーは接続後にセッションで使用したいカメラを選択する必要があります。詳細については、Amazon WorkSpaces ユーザーガイドの「[ウェブカメラおよびその他のビデオデバイス](https://docs.aws.amazon.com/workspaces/latest/userguide/peripheral_devices.html#devices-webcams)」を参照してください**。

#### ウェブカメラの最大解像度を制限する
<a name="limit-maximum-webcam-resolution"></a>

ビデオ会議に Power、PowerPro、GeneralPurpose.4xlarge、または GeneralPurpose.8xlarge WorkSpaces を使用する場合、リダイレクトされるウェブカメラの最大解像度を制限することを強くお勧めします。PowerPro、GeneralPurpose.4xlarge または GeneralPurpose.8xlarge の場合、推奨される最大解像度は幅 640 ピクセル、高さ 480 ピクセルです。Power の場合は、推奨最大解像度は幅 320 ピクセル、高さ 240 ピクセルです。

次の手順を実行して、ウェブカメラの最大解像度を設定します。

1. Windows レジストリエディタを開きます。

1. 以下のレジストリパスに移動します。

   ```
   HKEY_USERS/S-1-5-18/Software/GSettings/com/nicesoftware/dcv/webcam
   ```

1. `max-resolution` という名前の文字列値を作成し、`(X,Y)` フォーマットで希望する解像度に設定します。このとき、`X` は水平方向のピクセル数 (幅) を表し、`Y` は垂直方向のピクセル数 (高さ) を表します。たとえば、次のように指定します。幅 640 ピクセル、高さ 480 ピクセルの解像度を表すには、`(640,480)` と指定します。

#### 音声用に最適化されたオーディオ設定の有効化
<a name="enable-voice-optimized-audio-configuration"></a>

WorkSpaces は 7.1 の高音質オーディオを WorkSpaces からクライアントに配信するようにデフォルトで設定されており、優れた音楽再生品質が保証されています。ただし、主な用途に音声会議またはビデオ会議が含まれている場合は、オーディオコーデックプロファイルを音声用に最適化された設定に変更することで、CPU とネットワークリソースを節約できます。

次の手順を実行して、オーディオプロファイルを最適化された音声に設定します。

1. Windows レジストリエディタを開きます。

1. 以下のレジストリパスに移動します。

   ```
   HKEY_USERS/S-1-5-18/Software/GSettings/com/nicesoftware/dcv/audio
   ```

1. `default-profile` と言う名前の文字列値の名前を作成し、`voice` に設定します。

#### 音声通話やビデオ通話には高品質のヘッドセットを使用してください。
<a name="use-good-quality-headsets"></a>

オーディオ体験を向上させ、エコーを防ぐには、高品質のヘッドセットを使用することが重要です。デスクトップスピーカーを使用すると、通話のリモートエンドでエコーの問題が発生する可能性があります。

### 直接 RTC の設定
<a name="configure-direct-rtc"></a>

直接 RTC モードの設定は、特定のユニファイドコミュニケーション (UC) アプリケーションによって異なり、WorkSpaces の設定を変更する必要はありません。以下のリストは、さまざまな UC アプリケーションの最適化を完全に網羅したものではありません。

![\[メディア最適化 RTC の設定を示す図。\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/images/direct-rtc.png)

+ Microsoft Teams：
  + [SIP ゲートウェイの計画](https://learn.microsoft.com/en-us/microsoftteams/sip-gateway-plan)
  + [Microsoft 365 での音声会議](https://learn.microsoft.com/en-us/microsoftteams/audio-conferencing-in-office-365)
  + [Microsoft Teams での音声ソリューションの計画](https://learn.microsoft.com/en-us/microsoftteams/cloud-voice-landing-page)
+ Zoom Meetings:
  + [Enabling or disabling toll call dial-in numbers](https://support.zoom.us/hc/en-us/articles/360060920371-Enabling-or-disabling-toll-call-dial-in-numbers)
  + [Using desk phone call control](https://support.zoom.us/hc/en-us/articles/4912628206477-Using-desk-phone-call-control)
  + [Desk phone companion mode](https://support.zoom.us/hc/en-us/articles/360049007912-Desk-phone-companion-mode)
+ Webex:
  + [Webex App \$1 Make calls with your desk phone](https://help.webex.com/en-us/article/5mgmmb/Webex-App-%7C-Make-calls-with-your-desk-phone)
  + [Webex App \$1 Supported calling options](https://help.webex.com/en-us/article/xga73p/Webex-App-%7C-Supported-calling-options)
+ BlueJeans
  + [Dialing into a Meeting from a Desk Telephone](https://support.bluejeans.com/s/article/Dialing-into-a-meeting-from-a-Desk-Telephone)
+ Genesys:
  + [Genesys Cloud WebRTC Media Helper](https://help.mypurecloud.com/articles/about-webrtc-media-helper/)
+ Amazon Connect:
  + [Amazon WorkSpaces 向けの Amazon Connect の最適化](https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/connect-optimization.html)
+ Google Meet:
  + [Use a phone for audio in a video meeting](https://support.google.com/meet/answer/9518557?hl=en)

# WorkSpaces Personal の実行モードを管理する
<a name="running-mode"></a>

WorkSpace は、*実行モード*によって、すぐに使用できるかどうかとお支払い方法 (月単位または時間単位) が異なります。WorkSpace の作成時に、以下のいずれかの実行モードを選択できます。
+ **AlwaysOn** — 固定月額料金で WorkSpaces を無制限にご利用いただけます。このモードは、WorkSpace をプライマリデスクトップとしてフルタイム使用するユーザー用に最適です。
+ **AutoStop** — WorkSpaces のご利用に対し、時間単位で料金が発生します。このモードでは、アプリおよびデータを保存した状態と指定の長さの切断が発生した後、WorkSpaces が停止します。

詳細については、[WorkSpaces の料金](https://aws.amazon.com/workspaces/pricing/)を参照してください。

## AutoStop WorkSpaces
<a name="autostop-workspaces"></a>

自動停止時間を設定するには、Amazon WorkSpaces コンソールで WorkSpace を選択し、[**Actions**] (アクション)、[**Modify Running Mode Properties**] (実行モードプロパティの変更) の順に選択し、[**AutoStop Time (hours)**] (自動停止時間 (時間)) を設定します。デフォルトでは、**[AutoStop Time (hours)]** (自動停止時間 (時間)) は 1 時間に設定されています。つまり、WorkSpace は、切断されてから 1 時間後に自動的に停止することになります。

WorkSpace が切断され、自動停止時間が経過すると、WorkSpace が自動的に停止するまでさらに数分かかる場合があります。ただし、自動停止期間が経過するとすぐに請求が停止し、その追加時間に対しては課金されません。

WorkSpaces が休止をサポートしている場合、デスクトップの状態は WorkSpace のルートボリュームに保存されます。WorkSpace は、ユーザーがログインすると再開されます。開いているすべてのドキュメントと実行中のプログラムは、休止をサポートするすべての WorkSpaces オペレーティングシステムで保存状態に戻ります。

AutoStop GPU 対応 WorkSpaces および GeneralPurpose.4xlarge または GeneralPurpose.8xlarge は、休止をサポートしていません。アプリケーション/データの状態は保持されません。データ損失を避けるため、WorkSpaces の使用が終了したら毎回作業を保存することをお勧めします。

Bring-Your-Own-License (BYOL) AutoStop WorkSpaces では、多数の同時ログインによって、WorkSpaces が使用可能になるまでの時間が長引く可能性があります。BYOL AutoStop WorkSpaces に多くのユーザーが同時にログインすることが想定される場合は、アカウントマネージャーにご相談ください。

**重要**  
AutoStop WorkSpaces は、WorkSpaces が切断されている場合にのみ自動的に停止します。

WorkSpace は、次の場合にのみ切断されます。
+ ユーザーが WorkSpace から手動で切断するか、Amazon WorkSpaces クライアントアプリケーションを終了する場合。
+ クライアントデバイスがシャットダウンされる場合。
+ 20 分を超える時間にわたって、クライアントデバイスと WorkSpace の間に接続がない場合。

ベストプラクティスとして、AutoStop WorkSpace ユーザーは、日々、使用が終了したら、WorkSpaces から手動で切断すべきです。手動で切断するには、Linux、macOS、または Windows 用の WorkSpaces クライアントアプリケーションの **Amazon WorkSpaces** メニューから、[**Disconnect WorkSpace**] (WorkSpace を切断) または [**Quit Amazon WorkSpaces**] (Amazon WorkSpaces を終了) を選択します。Android または iPad の場合は、サイドバーメニューから [**Disconnect**] (切断) を選択します。

**次のような場合、AutoStop WorkSpaces が自動的に停止しないことがあります。**
+ クライアントデバイスがシャットダウンされるのではなく、ロック状態、スリープ状態、またはその他の非アクティブ状態 (ノートパソコンのカバーが閉じられている、など) にある場合は、WorkSpaces アプリケーションがバックグラウンドで引き続き実行されている可能性があります。WorkSpaces アプリケーションが引き続き実行中である限り、WorkSpace は切断されない可能性があるため、自動的に停止しない場合があります。
+ WorkSpaces は、ユーザーが WorkSpaces クライアントを使用している場合にのみ切断を検出できます。ユーザーがサードパーティーのクライアントを使用している場合は、WorkSpaces が切断状態を検出できない可能性があり、WorkSpaces が自動的に停止せず、請求が中断しない場合があります。

## 実行モードを変更する
<a name="modify-running-mode"></a>

実行モードは、いつでも切り替えることができます。

**WorkSpace の実行モードを変更するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. 変更する WorkSpace を選択し、**[Actions]** (アクション)、**[Modify Running Mode]** (実行モードの変更) の順に選択します。

1. 新しい実行モード **[AlwaysOn]** (常にオン) または **[AutoStop]** (自動停止) を選択し、次に **[Save]** (保存) をクリックします。

**を使用して WorkSpace の実行モードを変更するには AWS CLI**  
[modify-workspace-properties](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-properties.html) コマンドを使用します。

## AutoStop WorkSpace を停止/開始する
<a name="stop-start-workspace"></a>

AutoStop WorkSpaces が切断されている場合、切断されてから指定された時間が経過した後に自動的に停止し、時間単位の請求は一時停止します。コストをさらに最適化するには、AutoStop の WorkSpace に関連付けられている時間あたりの使用料金を手動で中断することができます。WorkSpace が停止し、ユーザーが次に WorkSpace にログオンする場合に備えて、すべてのアプリケーションやデータが保存されます。

停止中の WorkSpace にユーザーが再接続すると、通常は 90 秒未満で、前回の状態から再開されます。

AutoStop の WorkSpaces は、使用可能状態であってもエラー状態であっても再起動できます。

**自動停止 WorkSpace を停止するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. 停止する WorkSpace を選択したら、**[Actions]** (アクション)、**[Stop WorkSpaces]** (WorkSpaces の停止) の順に選択します。

1. 確認を求めるメッセージが表示されたら、**[Stop]** (停止) を選択します。

**AutoStop WorkSpace を開始するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. 開始する WorkSpace を選択したら、**[Actions]** (アクション)、**[Start WorkSpaces]** (WorkSpaces の起動) の順に選択します。

1. 確認を求めるメッセージが表示されたら、**[Start WorkSpace]** (WorkSpace の起動) を選択します。

AutoStop WorkSpaces に関連付けられた固定インフラストラクチャコストを削除するには、アカウントから WorkSpace を削除します。詳細については、「[WorkSpaces Personal で WorkSpace を削除する](delete-workspaces.md)」を参照してください。

**を使用して AutoStop WorkSpace を停止および開始するには AWS CLI**  
[stop-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/stop-workspaces.html) コマンドと [start-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/start-workspaces.html) コマンドを使用します。

# WorkSpaces Personal でアプリケーションを管理する
<a name="manage-applications"></a>

WorkSpace を起動すると、WorkSpace に関連付けられているすべてのアプリケーションバンドルのリストが、WorkSpaces コンソールに表示されます。

**WorkSpace に関連付けられているすべてのアプリケーションバンドルのリストを表示するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

1. 左のナビゲーションペインの **[WorkSpaces]** を選択します。

1. WorkSpace を選択したら、**[詳細の表示]** を選択します。

1. **[アプリケーション]** の下に、この WorkSpace に関連付られているアプリケーションの一覧が、インストールのステータスと共に表示されます。

**WorkSpace のアプリケーションバンドルは、次の方法で更新できます。**
+ WorkSpace にアプリケーションバンドルをインストールする
+ WorkSpace からアプリケーションバンドルをアンインストールする
+ WorkSpace にアプリケーションバンドルをインストールし、別のアプリケーションバンドルセットをアンインストールする

**注記**  
アプリケーションバンドルを更新するには、WorkSpace のステータスが `AVAILABLE` または `STOPPED` である必要があります。
[アプリケーションの管理] は Windows WorkSpaces でのみ使用できます。
[アプリケーションの管理] は、 AWSを通じてサブスクライブされたアプリケーションバンドルでのみ使用できます。

## [アプリケーションの管理] でサポートされているバンドル
<a name="w2aac11c29c25c11"></a>

[アプリケーションの管理] では、WorkSpaces で次のアプリケーションをインストールおよびアンインストールできます。Microsoft Office 2016 バンドルとMicrosoft Office 2019 の場合は、アンインストールのみが可能です。
+ Microsoft Office LTSC Professional Plus 2024
+ Microsoft Visio LTSC Professional 2024
+ Microsoft Project Professional 2024
+ Microsoft Office LTSC Standard 2024
+ Microsoft Visio LTSC Standard 2024
+ Microsoft プロジェクトスタンダード 2024
+ Microsoft Office LTSC Professional Plus 2021
+ Microsoft Visio LTSC Professional 2021
+ Microsoft Project Professional 2021
+ Microsoft Office LTSC Standard 2021
+ Microsoft Visio LTSC Standard 2021
+ Microsoft Project Standard 2021
+ Microsoft Visual Studio Professional 2022
+ Microsoft Visual Studio Enterprise 2022

次の表は、サポートされているアプリケーションとオペレーティングシステムの組み合わせと、サポートされていない組み合わせの一覧です。


|  | Microsoft Office Professional Plus 2016 (32 ビット) | Microsoft Office Professional Plus 2019 (64 ビット) | Microsoft LTSC Office Professional Plus / Standard 2024 (64 ビット) | Microsoft Project Professional/Standard 2024 (64 ビット) | Microsoft Visio Professional/Standard 2024 (64 ビット) | Microsoft LTSC Office Professional Plus / Standard 2021 (64 ビット) | Microsoft Project Professional / Standard 2021 (64 ビット) | Microsoft LTSC Visio Professional / Standard 2021 (64 ビット) | Microsoft Visual Studio Professional / Enterprise 2022 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| Windows Server 2016 | アンインストール | サポートされません | サポートされません | サポートされません | サポートされません | サポートされません | サポートされません | サポートされません | サポートされません | 
| Windows Server 2019 | サポートされていません | アンインストール | サポートされません | サポートされません | サポートされません | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | サポートされていません | 
| Windows Server 2022 | サポートされていません | アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | 
| Windows Server 2025 | サポートされていません | アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | サポートされません | サポートされません | サポートされません | インストール/アンインストール | 
| Windows 10 | アンインストール | アンインストール | サポートされません | サポートされません | サポートされません | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | 
| Windows 11 | アンインストール | アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | インストール/アンインストール | 

**重要**  
Microsoft Office/Visio/Project は、同じエディションとする必要があります。例えば、Standard アプリケーションと Professional アプリケーションを混在させることはできません。
Microsoft Office/Visio/Project は同じバージョンとする必要があります。例えば、2019 アプリケーションと 2021 アプリケーションを混在させることはできません。
Microsoft Office/Visio/Project 2021 および 2024 Standard/Professional は、Value、Graphics、GraphicsPro WorkSpaces バンドルではサポートされていません。
Microsoft Office/Visio/Project バージョン 2010 および 2013 (Standard または Professional エディション) はサポートされなくなりました。
Office 2016 または Office 2019 の Plus アプリケーションバンドルは、2025 年 10 月 14 日以降はサポートされなくなります。Office 2021 または Office 2024 を使用するには、それらの Office バージョンで WorkSpaces バンドルを移行することをお勧めします。詳細については、[WorkSpaces Personal でアプリケーションを管理する](manage-applications)」を参照してください。
Microsoft Office、Project、Visio では、2024 バージョンでは最大 25 GB、2021 バージョンでは最大 20 GB の空き容量が必要です。
Value、Standard、Graphics、および GraphicsPro WorkSpaces バンドルは、Visual Studio 2022 Enterprise/Professional ではサポートされていません。Performance バンドルは、リソースの消費量が少ない Visual Studio ワークロードに使用できます。ただし、最善の結果を得るには、クアッドコア以上のバンドルタイプで Visual Studio を使用することをお勧めします。バンドルタイプ Power、PowerPro、汎用.4xlarge、汎用.8xlarge、Graphics.g6、Graphics.g4dn、GraphicsPro.g4dn はこの要件を満たしています。詳細については、「[Visual Studio 2022 製品ファミリのシステム要件](https://learn.microsoft.com/en-us/visualstudio/releases/2022/system-requirements)」を参照してください。
WorkSpaces から **Microsoft Office 2016 用の Plus アプリケーションバンドル**をアンインストールすると、その Amazon WorkSpaces バンドルの一部として含まれていた Trend Micro のソリューションを利用できなくなります。Amazon WorkSpaces で Trend Micro のソリューションを引き続き使用したい場合は、[AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-u2in6sa3igl7c) で個別に購入できます。
Microsoft 365 アプリケーションをインストール/アンインストールするには、独自のツールとインストーラーを用意する必要があります。[アプリケーションの管理] ワークフローでは、Microsoft 365 アプリケーションをインストール/アンインストールすることはできません。
アプリケーションの管理を通じてインストール/アンインストールされたアプリケーションを含む、WorkSpaces のカスタムイメージを作成できます。
アフリカ (ケープタウン) などのオプトインリージョンでは、WorkSpaces インターネット接続をディレクトリレベルで有効にする必要があります。

## WorkSpace のアプリケーションバンドルを更新する
<a name="w2aac11c29c25c13"></a>

1. 

   [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. WorkSpace を選択し、**[アクション]**、**[アプリケーションの管理]** の順に選択します。

1. **[現在のアプリケーション]** には、この WorkSpace に既にインストールされているアプリケーションバンドルのリストが表示され、**[アプリケーションの選択]** には、この WorkSpace にインストールできるアプリケーションバンドルのリストが表示されます。

1. この WorkSpace でアプリケーションバンドルをインストールするには:

   1. この WorkSpace にインストールするアプリケーションバンドルを選択し、**[関連付け]** を選択します。

   1. 前のステップを繰り返して、他のアプリケーションバンドルをインストールします。

   1. アプリケーションバンドルのインストール中は、**[現在のアプリケーション]** の下に `Pending install deployment` ステータスが表示されます。

1. この WorkSpace からアプリケーションバンドルをアンインストールするには:

   1. **[アプリケーションの選択]** で、アンインストールするアプリケーションバンドルを選択し、**[関連付け解除]** を選択します。

   1. 前のステップを繰り返して、他のアプリケーションバンドルをアンインストールします。

   1. アプリケーションバンドルのアンインストール中は、**[現在のアプリケーション]** の下で、`Pending uninstall deployment` 状態でバンドルが表示されます。

1. バンドルのインストールまたはインストール状態を元に戻すには、次のいずれかを実行します。
   + バンドルを `Pending uninstall deployment` 状態から戻す場合は、元に戻すアプリケーションを選択し、**[関連付け]** を選択します。
   + バンドルを `Pending install deployment` 状態から戻す場合は、元に戻すアプリケーションを選択し、**[関連付け解除]** を選択します。

1. インストールまたはアンインストールを選択したアプリケーションバンドルが保留状態になったら、**[アプリケーションのデプロイ]** を選択します。
**重要**  
**[アプリケーションのデプロイ]** を選択すると、エンドユーザーセッションは終了し、アプリケーションのインストールまたはアンインストール中は WorkSpaces にアクセスできなくなります。

1. アクションを確認するには、「**確認**」と入力します。**[強制]** を選択して、**[エラー]** 状態のアプリケーションバンドルをインストールまたはアンインストールします。

1. アプリケーションバンドルの進行状況をモニターリングするには:

   1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

   1. ナビゲーションペインで [**WorkSpaces**] を選択します。**[ステータス]** には、次のようなステータスが表示されます。
      + **更新中** – アプリケーションバンドルの更新はまだ進行中です。
      + **使用可能/停止中** – アプリケーションバンドルの更新が完了し、WorkSpace は元の状態に戻っています。

   1. アプリケーションバンドルのインストールまたはアンインストールのステータスをモニタリングするには、WorkSpace を選択し、**[詳細を表示]** を選択します。**[アプリケーション]** の **[ステータス]** には、`Pending install`、`Pending uninstall`、`Installed` などのステータスが表示されます。
**注記**  
[アプリケーションの管理] を通じて新しくインストールしたアプリケーションバンドルがライセンス認証されていないことにユーザーが気付いた場合は、WorkSpace を手動で再起動できます。ユーザーは、再起動後にこれらのアプリケーションの使用を開始できます。その他のサポートについては、[AWS サポート](https://console.aws.amazon.com/support/home#/)にお問い合わせください。

## WorkSpace で Microsoft Visual Studio 2022 ワークロードを更新する
<a name="w2aac11c29c25c15"></a>

デフォルトでは、Microsoft Visual Studio 2022 は次のワークロードとともにインストールされ、18 GB のハードディスク容量が必要となります。
+ Visual Studio コアエディタ
+ Azure 開発
+ データストレージと処理
+ .NET デスクトップ開発
+ NET マルチプラットフォームアプリケーション UI 開発
+ ASP.NET およびウェブ開発
+ Node.js 開発

ユーザーはワークロードや個々のコンポーネントを柔軟に追加または削除できるため、特定の要件に合わせてアプリケーションを調整できます。追加のワークロードをインストールするには、より多くのディスク領域が必要になることに注意してください。ワークロード設定の詳細については、「[Visual Studio のワークロード、コンポーネント、および言語パックを変更する](https://learn.microsoft.com/en-us/visualstudio/install/modify-visual-studio?view=vs-2022)」を参照してください。

## [アプリケーションの管理] を使用して変更された WorkSpaces の管理
<a name="w2aac11c29c25c17"></a>

WorkSpaces にアプリケーションバンドルをインストールまたはアンインストールした後、次のアクションは既存の設定に影響を与える可能性があります。
+ **WorkSpace の復元** – WorkSpace を復元すると、WorkSpace が正常であったときに作成したこれらのボリュームの最新スナップショットに基づいて、ルートボリュームとユーザーボリュームの両方が再作成されます。WorkSpace の完全なスナップショットは、12 時間ごとに作成されます。詳細については、「[WorkSpaces の復元](https://docs.aws.amazon.com/workspaces/latest/adminguide/restore-workspace.html)」を参照してください。[アプリケーションの管理] を使用して変更した WorkSpaces を復元する前に、少なくとも 12 時間待機してください。[アプリケーションの管理] を使用して変更された WorkSpaces を、次の完全なスナップショットの前に復元すると、次の結果になります。
  +  [アプリケーションの管理] ワークフローを使用して WorkSpaces にインストールされたアプリケーションバンドルは WorkSpaces から削除されますが、ライセンスは引き続きアクティブ化され、それらのアプリケーションに対して WorkSpaces の料金が発生します。これらのアプリケーションバンドルを WorkSpaces に戻すには、[アプリケーションの管理] ワークフローを再度実行し、アプリケーションをアンインストールして最初からやり直した後で、もう一度インストールする必要があります。
  +  [アプリケーションの管理] ワークフローを使用して WorkSpaces から削除されたアプリケーションバンドルは、WorkSpaces に戻ります。ただし、ライセンスのアクティブ化が行われないため、これらのアプリケーションバンドルは正しく動作しません。これらのアプリケーションバンドルを削除するには、それらのアプリケーションバンドルを WorkSpaces から手動でアンインストールします。
+ **WorkSpace の再構築** – WorkSpace を再構築すると、ルートボリュームが再作成されます。詳細については、「[WorkSpaces の再構築](https://docs.aws.amazon.com/workspaces/latest/adminguide/rebuild-workspace.html)」を参照してください。[アプリケーションの管理] を使用して変更した WorkSpaces を再構築すると、次の結果になります。
  +  [アプリケーションの管理] ワークフローを使用して WorkSpaces にインストールされたアプリケーションバンドルは WorkSpaces から削除され、非アクティブになります。これらのアプリケーションを WorkSpaces に戻すには、[アプリケーションの管理] ワークフローを再度実行する必要があります。
  +  [アプリケーションの管理] ワークフローを使用して WorkSpaces から削除されたアプリケーションバンドルは WorkSpaces にインストールされ、アクティブになります。これらのアプリケーションバンドルを WorkSpaces から削除するには、[アプリケーションの管理] ワークフローを再度実行する必要があります。
+ **WorkSpace の移行** – 移行プロセスでは、ターゲットバンドルイメージからの新しいルートボリュームと、元の WorkSpace の最後に利用可能なスナップショットからのユーザーボリュームを使用して WorkSpace を再作成します。新しい WorkSpace ID を持つ新しい WorkSpace が作成されます。詳細については、「[WorkSpace の移行](https://docs.aws.amazon.com/workspaces/latest/adminguide/migrate-workspaces.html)」を参照してください。[アプリケーションの管理] を使用して変更した WorkSpaces を移行すると、次の結果になります。
  +  移行元 WorkSpaces のすべてのアプリケーションバンドルが削除され、非アクティブになります。新しい移行先 WorkSpaces は、移行先の WorkSpaces バンドルからアプリケーションを継承します。移行元の WorkSpaces アプリケーションバンドルは 1 か月分の請求になりますが、移行先バンドルのアプリケーションバンドルには日割り計算が適用されます。

# WorkSpaces Personal で WorkSpace を変更する
<a name="modify-workspaces"></a>

WorkSpace の起動後に、以下の 3 つの方法で設定を変更できます。
+ ルートボリューム (Windows の場合はドライブ C、Linux の場合は /)、およびユーザーボリューム (Windows の場合はドライブ D、Linux の場合は /home) のサイズを変更できます。
+ コンピューティングタイプを変更して、新しいバンドルを選択できます。
+ WorkSpace が PCoIP AWS バンドルで作成された場合は、CLI または Amazon WorkSpace API を使用してストリーミングプロトコルを変更できます。 Amazon WorkSpaces 

WorkSpace の現在の変更状態を表示するには、矢印を選択して WorkSpace の詳細を表示します。[**状態**] に表示される値は、[**コンピューティングの変更**]、[**ストレージの変更**]、および [**なし**] です。

WorkSpace を修正する場合は、ステータスが `AVAILABLE` または `STOPPED` である必要があります。ボリュームサイズとコンピューティングタイプを同時に変更することはできません。

WorkSpace のボリュームサイズまたはコンピューティングタイプを変更すると、WorkSpace の請求レートが変更されます。

ユーザーがボリュームとコンピューティングタイプを変更できるようにするには、[WorkSpaces Personal でユーザーを対象とした WorkSpaces の自己管理機能を有効にする](enable-user-self-service-workspace-management.md) を参照してください。

## ボリュームサイズの変更
<a name="modify_volume_sizes"></a>

WorkSpace のルートボリュームとユーザーボリュームのサイズを、それぞれ 2000 GB まで増やすことができます。セットグループに付属の WorkSpace ルートボリュームおよびユーザーボリュームは変更できません。使用可能なグループは以下のとおりです。


| [ルート (GB)、ユーザー (GB)] | 
| --- | 
| [80, 10] | 
| [80, 50] | 
| [80, 100] | 
| [175 〜 2,000、100 〜 2,000] | 

ルートボリュームとユーザーボリュームは、暗号化されているかどうかにかかわらず拡張できます。両方のボリュームとも、6 時間に 1 回拡張できます。ただし、ルートボリュームとユーザーボリュームのサイズを同時に増やすことはできません。詳細については、「[Limitations for Increasing Volumes](#limitations_increasing_volumes)」を参照してください。

**注記**  
WorkSpace のボリュームを拡張すると、WorkSpaces により Windows または Linux 内でボリュームのパーティションが自動的に拡張されます。プロセスが終了したら、変更を有効にするために WorkSpace を再起動する必要があります。

データを確実に保持するために、WorkSpace の起動後はルートやユーザーボリュームのサイズを縮小できなくなります。代わりに、WorkSpace を起動するときに、これらのボリュームの最小サイズを指定してください。
+ Value、Standard、Performance、Power、PowerPro のいずれかの WorkSpace は、最小 80 GB のルートボリュームおよび 10 GB のユーザーボリュームで起動できます。
+ GeneralPurpose.4xlarge または GeneralPurpose.8xlarge WorkSpace は、最低 175 GB のルートボリュームおよび最低 100 GB のユーザーボリュームで起動できます。
+ Graphics.g6、Graphics.g4dn、GraphicsPro.g4dn,または GraphicsPro WorkSpace は、ルートボリュームの場合は最低 100 GB、ユーザーボリュームの場合は最低 100 GB で起動できます。ボリュームのサイズ設定要件は、より大きなグラフィックスインスタンスタイプによって異なります。

WorkSpace のディスクサイズを拡大中の場合でも、ユーザーは自分の WorkSpace でほとんどのタスクを実行できます。ただし、WorkSpace コンピューティングタイプの変更、WorkSpace 実行モードの切り替え、WorkSpace の再構築、WorkSpace の再起動を行うことはできません。

**注記**  
ディスクサイズの拡大中にユーザーが自身の WorkSpaces を使用できるようにするには、WorkSpaces のボリュームのサイズを変更する前に、WorkSpaces のステータスが `AVAILABLE` ではなく `STOPPED` であることを確認します。WorkSpaces が `STOPPED` となっている場合、ディスクサイズの拡大中にその WorkSpaces を起動することはできません。

多くの場合、ディスクサイズの拡大プロセスには最長で 2 時間かかります。ただし、多数の WorkSpaces でボリュームサイズを変更している場合には、このプロセスが顕著に長くなることもあります。変更する WorkSpaces が多数ある場合は、 に連絡してサポート AWS サポート を受けることをお勧めします。

**ボリューム増加の制限**
+ サイズ変更できるのは SSD ボリュームのみです。
+ WorkSpace を起動するときは、6 時間待ってからボリュームのサイズを変更する必要があります。
+ ルートボリュームとユーザーボリュームのサイズを同時に増やすことはできません。ルートボリュームを増やすには、まずユーザーボリュームを 100 GB に変更する必要があります。この変更を行った後、ルートボリュームを 175～2000 GB の任意の値に更新できます。ルートボリュームを 175～2000 GB の任意の値に変更した後、ユーザーボリュームを 100～2000 GB の任意の値にさらに更新できます。
**注記**  
両方のボリュームを増やす場合は、最初の操作が終了するまで 20～30 分待ってから 2 番目の操作を開始する必要があります。
+ ユーザーボリュームが 100 GB の場合、Non-GPU-enabled WorkSpaces のルートボリュームを 175 GB 未満にすることはできません。GPU 対応 WorkSpaces のストレージ要件は、インスタンスのサイズ設定に比例してスケーリングされます。より大きな GPU 対応 WorkSpaces 設定を選択するときは、最適なパフォーマンスを維持し、ワークロードの需要の増加に対応するために、対応するより大きなストレージボリュームを割り当てる必要があります。最小インスタンスサイズの場合は、次のストレージ割り当てから始めます。ルート: 100 GB、ユーザー: 100 GB。GPU 対応 WorkSpaces は、ルートボリュームでは最低 100 GB、ユーザーボリュームでは最低 100 GB をサポートします。
+ ユーザーボリュームが 50 GB の場合、ルートボリュームを 80 GB 以外に更新することはできません。ルートボリュームが 80 GB の場合、ユーザーボリュームは 10、50、または 100 GB のみに設定できます。

**WorkSpace のルートボリュームを変更するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. WorkSpace を選択して、**[アクション]**、**[ルートボリュームを変更]** の順に選択します。

1. **[Root volume sizes]** (ルートボリュームサイズ) でボリュームサイズを選択するか、**[Custom]** (カスタム) を選択してカスタムボリュームサイズを入力します。

1. **[変更の保存]** をクリックします。

1. ディスクサイズの増加が完了したら、[WorkSpace を再起動](reboot-workspaces.md)して変更を反映する必要があります。データの損失を避けるために、WorkSpace を再起動する前に、開いているファイルを必ず保存してください。

**WorkSpace のユーザーボリュームを変更するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. WorkSpace を選択して、**[アクション]**、**[ユーザーボリュームを変更]** の順に選択します。

1. **[User volume sizes]** (ユーザーボリュームサイズ) でボリュームサイズを選択するか、**[Custom]** (カスタム) を選択してカスタムボリュームサイズを入力します。

1. **[Save changes]** (変更の保存) をクリックします。

1. ディスクサイズの増加が完了したら、[WorkSpace を再起動](reboot-workspaces.md)して変更を反映する必要があります。データの損失を避けるために、WorkSpace を再起動する前に、開いているファイルを必ず保存してください。

**WorkSpace のボリュームサイズを変更するには**  
`RootVolumeSizeGib` または `UserVolumeSizeGib` プロパティを使用して [modify-workspace-properties](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-properties.html) コマンドを使用します。

## コンピューティングタイプの変更
<a name="modify_compute"></a>

WorkSpace では、Standard、Power、Performance、PowerPro、GeneralPurpose.4xlarge、と GeneralPurpose.8xlarge のコンピューティングタイプに切り替えできます。これらのコンピューティングタイプの詳細については、「[Amazon WorkSpaces バンドル](https://aws.amazon.com/workspaces/features/#Amazon_WorkSpaces_Bundles)」を参照してください。

**注記**  
ソースオペレーティングシステムが Windows Server 2022 または Windows 11 以外の場合は、コンピューティングタイプを PowerPro から GeneralPurpose に変更することはできません。
非 GPU 対応バンドルから GeneralPurpose.4xlarge または GeneralPurpose.8xlarge にコンピューティングタイプを変更する場合、WorkSpaces は最小ルートボリュームサイズ 175 GB、ユーザーボリュームサイズ 100 GB を満たす必要があります。WorkSpaces のボリュームサイズを増やすには、「[ボリュームサイズの変更](#modify_volume_sizes)」を参照してください。
GPU 対応 WorkSpaces は、同じインスタンスファミリー内のコンピューティングタイプの変更をサポートしていますが、ファミリー間の変更をサポートしていません。たとえば、G4dn インスタンス間または G6 インスタンス間でコンピューティングタイプを変更できますが、G4dn インスタンスから G6 インスタンスファミリーに変更することはできません。異なるインスタンスファミリーを搭載した GPU 対応 WorkSpace バンドル間を移動するには、WorkSpace の移行機能を使用します。詳細については、[WorkSpaces Personal で WorkSpace を移行する](migrate-workspaces.md)を参照してください。
GraphicsPro バンドルは 2025 年 10 月 31 日にサポート終了となります。GraphicsPro WorkSpaces をお使いの場合、2025 年 10 月 31 日までに、サポートされているバンドルに移行することをお勧めします。詳細については、「[WorkSpaces Personal で WorkSpace を移行する](migrate-workspaces.md)」を参照してください。
Graphics および GraphicsPro のコンピューティングタイプは他の値に変更できません。

コンピューティングの変更をリクエストすると、WorkSpaces は新しいコンピューティングタイプを使用して WorkSpace を再起動します。WorkSpaces は、WorkSpace のオペレーティングシステム、アプリケーション、データ、およびストレージの設定を保持します。

より大きなコンピューティングタイプは 6 時間に 1 回、より小さなコンピューティングタイプは 30 日に 1 回リクエストできます。新規の WorkSpace については、より大きなバンドルをリクエストするには 6 時間待機する必要があります。

WorkSpace コンピューティングタイプが変更中の場合、ユーザーは WorkSpace から切断されるため、WorkSpace を使用または変更することはできません。WorkSpace は、コンピューティングタイプの変更プロセス中に自動的に再起動されます。

**重要**  
データの損失を避けるため、WorkSpace のコンピューティングタイプを変更する前に、開いているドキュメントやその他のアプリケーションファイルを必ず保存してください。

コンピューティングタイプの変更プロセスには、最大 1 時間かかる場合があります。

**WorkSpace のコンピューティングタイプを変更するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. WorkSpace を選択して、**[アクション]**、**[コンピューティングタイプを変更]** の順に選択します。

1. **[Compute type]** (コンピューティングタイプ) で、コンピューティングタイプを選択します。

1. **[Save changes]** (変更の保存) をクリックします。

**WorkSpace のコンピューティングタイプを変更するには**  
`ComputeTypeName` プロパティを使用して [modify-workspace-properties](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-properties.html) コマンドを使用します。

## プロトコルの変更
<a name="modify_protocols"></a>

 WorkSpace が PCoIP バンドルで作成されている場合は、CLI または Amazon WorkSpaces API AWS を使用してストリーミングプロトコルを変更できます。これにより、WorkSpace 移行機能を使用せずに、既存の WorkSpace を使用してプロトコルを移行できます。また、これにより、移行プロセス中に既存の PCoIP WorkSpaces を再作成しなくても、DCV を使用してルートボリュームを維持できます。
+ プロトコルを変更できるのは、WorkSpace が PCoIP バンドルで作成されていて、GPU 対応の WorkSpace でない場合のみです。
+ プロトコルを DCV に変更する前に、WorkSpace が DCV WorkSpace の以下の要件を満たしていることを確認してください。
  + WorkSpaces クライアントが DCV をサポートしている。
  + WorkSpace のデプロイ先のリージョンが DCV をサポートしている。
  + DCV の IP アドレスとポートの要件が公開されている。詳細については、「[WorkSpaces の IP アドレスとポートの要件](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)」を参照してください。
  + 現在のバンドルが DCV で確実に利用できる。
  + ビデオ会議を最大限に活用するには、Power、PowerPro、GeneralPurpose.4xlarge、または GeneralPurpose.8xlarge のみを使用することをお勧めします。

**注記**  
プロトコルの変更を開始する前に、本番環境以外の WorkSpaces でテストすることを強くお勧めします。
プロトコルを PCoIP から DCV に変更した後で PCoIP に戻すと、Web Access 経由で WorkSpaces に接続できなくなります。

**WorkSpace のプロトコルを変更するには**

1. (オプション) WorkSpace を再起動し、`AVAILABLE` 状態になるまで待ってからプロトコルを変更します。

1. (オプション) `describe-workspaces` コマンドを使用して WorkSpace のプロパティを一覧表示します。それが `AVAILABLE` 状態にあり、現在の `Protocol` が正しいことを確認します。

1. `modify-workspace-properties` コマンドを使用して、`Protocols` プロパティを `PCOIP` から`DCV` に、またはその逆に変更します。

   ```
   aws workspaces modify-workspace-properties
   --workspace-id <value>
   --workspace-properties "Protocols=[WSP]"
   ```
**重要**  
`Protocols` プロパティは、大文字と小文字が区別されます。`PCOIP` または `DCV` を必ず使用してください。

1. コマンドを実行した後で、WorkSpace が再起動して必要な設定を完了するまでには最大 20 分かかります。

1. `describe-workspaces` コマンドをもう一度使用して WorkSpace のプロパティを一覧表示し、それが `AVAILABLE` 状態にあり、現在の `Protocols` プロパティが正しいプロトコルに変更されていることを確認します。
**注記**  
WorkSpace のプロトコルを変更しても、コンソールのバンドルの表示は更新されません。**[Launch Bundle]** (バンドルの起動) という表示は変わりません。
20 分経っても WorkSpace が `UNHEALTHY` 状態のままである場合は、コンソールで WorkSpace を再起動します。

1. これで WorkSpace に接続できるようになりました。

# WorkSpaces Personal でブランドをカスタマイズする
<a name="customize-branding"></a>

Amazon WorkSpaces では、API を使用して独自のブランドロゴ、IT サポート情報、パスワードを忘れた場合のリンク、ログインメッセージなど、WorkSpace のログインページをカスタマイズすることで、ユーザーに親しみやすい WorkSpaces エクスペリエンスを作成できます。WorkSpace ログインページには、デフォルトの WorkSpaces ブランドに代わり、お客様のブランドがユーザーに表示されます。

以下のクライアントをサポートしています。
+ Server 
+ Linux
+ Android
+ macOS
+ iOS
+ Web Access

## カスタムブランドのインポート
<a name="import-custom-branding"></a>

クライアントのカスタムブランドをインポートするには、`ImportClientBranding` のアクションを使用します。アクションには以下の要素が含まれます。詳細については、「[ API リファレンスの ImportClientBranding](https://docs.aws.amazon.com/workspaces/latest/api/API_ImportClientBranding.html)」を参照してください。

**重要**  
クライアントのブランド属性は公開されています。機密情報が含まれないようにしてください。

ディレクトリがレガシーユーザーログインフローを使用しているか新しいユーザーログインフローを使用しているかに応じて、以下のスクリーンショットに示すように、ユーザーにはカスタムクライアントブランド属性が表示されます。


|  |  | 
| --- |--- |
|  ![\[WorkSpaces クライアントサインイン画面 - レガシーログインフロー\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/images/client-cobranding-legacy.png)  |  ![\[WorkSpaces クライアントサインイン画面 - 新しいログインフロー\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/images/client-cobranding-new.png)  | 

1. サポートリンク

1. Logo

1. パスワードを忘れた場合のリンク

1. ログインメッセージ


**カスタムブランドの要素**  

| ブランド要素 | 説明 | 要件と推奨事項 | 
| --- | --- | --- | 
| サポートリンク | ユーザーが WorkSpaces に関するヘルプを問い合わせるためのサポート E メールリンクを指定できます。SupportEmail 属性を使用するか、SupportLink 属性を使用してサポートページへのリンクを提供することで指定できます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/customize-branding.html) | 
| Logo | Logo 属性を使用して、組織のロゴをカスタマイズできます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/customize-branding.html) | 
| パスワードを忘れた場合のリンク | ForgotPasswordLink 属性を使用してウェブアドレスを追加し、これによりユーザーが WorkSpace のパスワードを忘れた場合に移動できます。 | 長さの制限：最小長 1、最大長は 200 です。 | 
| ログインメッセージ | LoginMessage 属性を使用して、サインイン画面のメッセージをカスタマイズできます。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/customize-branding.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/customize-branding.html)  | 

以下は、ImportClientBranding を使用するためのサンプルコードスニペットです。

### AWS CLI バージョン 2
<a name="import-client-branding-cli"></a>

**警告**  
カスタムブランディングをインポートすると、カスタムデータで指定したプラットフォーム内の属性が上書きされます。また、デフォルトのカスタムブランディング属性値で指定していない属性も上書きされます。上書きしたくない属性のデータを含める必要があります。

```
aws workspaces import-client-branding \
--cli-input-json file://~/Downloads/import-input.json \
--region us-west-2
```

インポート JSON ファイルは、以下のようなサンプルコードになります。

```
{
    "ResourceId": "<directory-id>",
    "DeviceTypeOsx": {
        "Logo": "iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAYAAABytg0kAAAAC0lEQVR42mNgQAcAABIAAeRVjecAAAAASUVORK5CYII=",
        "ForgotPasswordLink": "https://amazon.com/",
        "SupportLink": "https://amazon.com/",
        "LoginMessage": {
            "en_US": "Hello!!"
        }
    }
}
```

次のサンプル Java コードスニペットは、ロゴイメージを base64 でエンコードされた文字列に変換します。

```
// Read image as BufferImage
BufferedImage bi = ImageIO.read(new File("~/Downloads/logo.png"));
   
// convert BufferedImage to byte[]
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write(bi, "png", baos);
byte[] bytes = baos.toByteArray();
       
//convert byte[] to base64 format and print it
String bytesBase64 = Base64.encodeBase64String(bytes);
System.out.println(bytesBase64);
```

次のサンプル Python コードスニペットは、ロゴイメージを base64 でエンコードされた文字列に変換します。

```
# Read logo into base64-encoded string
with open("~/Downloads/logo.png", "rb") as image_file:
    f = image_file.read()
    base64_string = base64.b64encode(f)
    print(base64_string)
```

### Java
<a name="import-client-branding-java"></a>

**警告**  
カスタムブランディングをインポートすると、カスタムデータで指定したプラットフォーム内の属性が上書きされます。また、デフォルトのカスタムブランディング属性値で指定していない属性も上書きされます。上書きしたくない属性のデータを含める必要があります。

```
// Create WS Client
WorkSpacesClient client = WorkSpacesClient.builder().build();

// Read image as BufferImage
BufferedImage bi = ImageIO.read(new File("~/Downloads/logo.png"));

// convert BufferedImage to byte[]
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write(bi, "png", baos);
byte[] bytes = baos.toByteArray();
    
// Create import attributes for the plateform 
DefaultImportClientBrandingAttributes attributes =
        DefaultImportClientBrandingAttributes.builder()
                .logo(SdkBytes.fromByteArray(bytes))
                .forgotPasswordLink("https://aws.amazon.com/")
                .supportLink("https://aws.amazon.com/")
                .build();
                    
// Create import request
ImportClientBrandingRequest request = 
        ImportClientBrandingRequest.builder()
                .resourceId("<directory-id>")
                .deviceTypeOsx(attributes)
                .build();
                    
// Call ImportClientBranding API
ImportClientBrandingResponse response = client.importClientBranding(request);
```

### Python
<a name="import-client-branding-python"></a>

**警告**  
カスタムブランディングをインポートすると、カスタムデータで指定したプラットフォーム内の属性が上書きされます。また、デフォルトのカスタムブランディング属性値で指定していない属性も上書きされます。上書きしたくない属性のデータを含める必要があります。

```
import boto3

# Read logo into bytearray
with open("~/Downloads/logo.png", "rb") as image_file:
    f = image_file.read()
    bytes = bytearray(f)

# Create WorkSpaces client
client = boto3.client('workspaces')

# Call import API
response = client.import_client_branding(
    ResourceId='<directory-id>',
    DeviceTypeOsx={
        'Logo': bytes,
        'SupportLink': 'https://aws.amazon.com/',
        'ForgotPasswordLink': 'https://aws.amazon.com/',
        'LoginMessage': {
            'en_US': 'Hello!!'
        }
    }
)
```

### PowerShell
<a name="import-client-branding-powershell"></a>

```
#Requires -Modules @{ ModuleName="AWS.Tools.WorkSpaces"; ModuleVersion="4.1.56"}

# Specify Image Path
$imagePath = "~/Downloads/logo.png"

# Create Byte Array from image file
$imageByte = ([System.IO.File]::ReadAllBytes($imagePath))

# Call import API
Import-WKSClientBranding -ResourceId <directory-id> `
    -DeviceTypeLinux_LoginMessage @{en_US="Hello!!"} `
    -DeviceTypeLinux_Logo $imageByte `
    -DeviceTypeLinux_ForgotPasswordLink "https://aws.amazon.com/" `
    -DeviceTypeLinux_SupportLink "https://aws.amazon.com/"
```

ログインページをプレビューするには、WorkSpaces アプリケーションまたはウェブログインページを起動します。

**注記**  
変更が表示されるまでに最大 1 分程度かかる場合があります。

## カスタムブランドの説明
<a name="describe-custom-branding"></a>

現在使用しているクライアントブランドのカスタマイズの詳細を表示するには、`DescribeCustomBranding` のアクションを使用します。以下は、DescribeClientBranding を使用するためのサンプルスクリプトです。詳細については、「[ API リファレンスの DescribeClientBranding](https://docs.aws.amazon.com/workspaces/latest/api/API_DescribeClientBranding.html)」を参照してください。

```
aws workspaces describe-client-branding \
--resource-id <directory-id> \
--region us-west-2
```

## カスタムブランドの削除
<a name="delete-custom-branding"></a>

クライアントブランドのカスタマイズを削除するには、`DeleteCustomBranding` のアクションを使用します。以下は、DeleteClientBranding を使用するためのサンプルスクリプトです。詳細については、「[ API リファレンスの DeleteClientBranding](https://docs.aws.amazon.com/workspaces/latest/api/API_DeleteClientBranding.html)」を参照してください。

```
aws workspaces delete-client-branding \ 
--resource-id <directory-id> \
--platforms DeviceTypeAndroid DeviceTypeIos \  
--region us-west-2
```

**注記**  
変更が表示されるまでに最大 1 分程度かかる場合があります。

# WorkSpaces Personal でリソースにタグを付ける
<a name="tag-workspaces-resources"></a>

WorkSpaces のリソースは、*タグ*形式で各リソースに独自のメタデータを割り当てることによって整理および管理できます。タグごとに*キー*と*値*を指定します。キーは、特定の関連値を持つ「プロジェクト」、「所有者」、「環境」などの一般的なカテゴリにすることができます。タグを使用することは、 AWS リソースを管理し、請求データを含むデータを整理するためのシンプルで強力な方法です。

既存のリソースにタグを追加すると、これらのタグは翌月の初日までコスト配分レポートに表示されません。例えば、7 月 15 日に既存の WorkSpace にタグを追加した場合、8 月 1 日までタグはコスト配分レポートに表示されません。詳細については、*AWS Billing * の「[コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)」を参照してください。

**注記**  
Cost Explorer で WorkSpaces リソースタグを表示するには、*AWS Billing ユーザーガイド*の「[ユーザー定義コスト配分タグのアクティブ化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)」の手順に従って、WorkSpaces リソースに適用したタグをアクティブにする必要があります。  
タグはアクティベーション後 24 時間後に表示されますが、これらのタグに関連付けられた値が Cost Explorer に表示されるまでに 4～5 日かかる場合があります。さらに、Cost Explorer でコストデータを表示して提供するには、タグ付けされた WorkSpaces リソースにその期間中に料金が発生する必要があります。[Cost Explorer] には、タグが有効化されてからそれまでのコストデータのみが表示されます。現時点では、履歴データはありません。

**タグ付けできるリソース**
+ WorkSpaces、インポートされたイメージ、および IP アクセスコントロールグループの各リソースは、作成時にタグを追加できます。
+ 既存のリソースタイプ (WorkSpaces、登録されたディレクトリ、カスタムバンドル、イメージ、および IP アクセスコントロールグループ) にタグを追加できます。

**タグの制限**
+ リソースあたりのタグの最大数 – 50
+ キーの最大長 – 127 文字 (Unicode)
+ 値の最大長 – 255 文字 (Unicode)
+ タグのキーと値は大文字と小文字が区別されます。使用できる文字は、UTF-8 で表現できる文字、スペース、および数字と、特殊文字 (\$1、-、=、.、\$1、:、/、@) です。ただし、先頭または末尾にはスペースを使用しないでください。
+ タグ名`aws:`または値に または `aws:workspaces:`プレフィックスを使用しないでください。これらは AWS 使用のために予約されています。これらのプレフィックスが含まれるタグの名前または値は編集または削除できません。

**コンソール (ディレクトリ、WorkSpaces、または IP アクセスコントロールグループ) を使用して既存のリソースのタグを更新するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

1. ナビゲーションペインで、**ディレクトリ**、**WorkSpaces**、または **IP アクセスコントロール** のいずれかのリソースタイプを選択します。

1. リソースを選択して、詳細ページを開きます。

1. 次の 1 つ以上の操作を行います。
   + タグを更新するには、**[キー]** と **[値]** の値を編集します。
   + 新しいタグを追加するには、[**Add Tag**] を選択し、[**Key**] と [**Value**] の値を編集します。
   + タグを削除するには、タグの横にある削除アイコン (X) を選択します。

1. タグの更新を完了したら、**[Save]** (保存) を選択します。

**コンソールを使用して既存のリソースのタグを更新するには (イメージまたはバンドル)**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

1. ナビゲーションペインで、[**Bundles**] (バンドル) または [**Images**] (イメージ) のうち、いずれかのリソースタイプを選択します。

1. リソースを選択して、詳細ページを開きます。

1. [**タグ**] で、[**タグの管理**] を選択します。

1. 次の 1 つ以上の操作を行います。
   + タグを更新するには、**[キー]** と **[値]** の値を編集します。
   + 新しいタグを追加するには、[**Add new tag**] (新しいタグの追加) を選択し、**[キー]** と **[値]** の値を編集します。
   + タグを削除するには、タグの横にある [**削除**] を選択します。

1. タグの更新を完了したら、[**Save changes**] (変更の保存) を選択します。

**を使用して既存のリソースのタグを更新するには AWS CLI**  
[create-tags](https://docs.aws.amazon.com/cli/latest/reference/workspaces/create-tags.html) および [delete-tags](https://docs.aws.amazon.com/cli/latest/reference/workspaces/delete-tags.html) コマンドを使用します。

# WorkSpaces Personal のメンテナンス
<a name="workspace-maintenance"></a>

WorkSpaces を定期的にメンテナンスすることをお勧めします。WorkSpaces は、WorkSpaces のデフォルトのメンテナンスウィンドウをスケジュールします。メンテナンスウィンドウ中に、WorkSpace は必要に応じて重要な更新を Amazon WorkSpaces からインストールして再起動します。オペレーティングシステムの更新プログラム (利用可能な場合) は、WorkSpace が使用するように設定されている OS アップデートサーバーからもインストールされます。メンテナンス中は、WorkSpaces が使用できないことがあります。

デフォルトでは、Windows WorkSpaces は Windows Update から更新プログラムを受信するように設定されています。ユーザー独自の Windows 自動更新メカニズムを設定する方法については、[Windows Server Update Services (WSUS)](https://docs.microsoft.com/windows-server/administration/windows-server-update-services/deploy/deploy-windows-server-update-services) および [Configuration Manager](https://docs.microsoft.com/configmgr/sum/deploy-use/deploy-software-updates) のドキュメントを参照してください。

**要件**  
オペレーティングシステムの更新をインストールしてアプリケーションをデプロイできるように、WorkSpaces はインターネットにアクセスできる必要があります。詳細については、「[WorkSpaces Personal でのインターネットアクセス](amazon-workspaces-internet-access.md)」を参照してください。

## AlwaysOn WorkSpaces のメンテナンスウィンドウ
<a name="alwayson-maintenance"></a>

AlwaysOn WorkSpaces では、メンテナンスウィンドウはオペレーティングシステムの設定によって決まります。デフォルトは、WorkSpace のタイムゾーンの、毎週日曜日午前 0:00～4:00 の 4 時間です。デフォルトでは、AlwaysOn WorkSpace のタイムゾーンは、WorkSpace の AWS リージョンのタイムゾーンです。ただし、別のリージョンから接続し、タイムゾーンリダイレクトが有効にされた後に切断した場合は、WorkSpace のタイムゾーンは、接続元リージョンのタイムゾーンに更新されます。

グループポリシーを使用して、[Windows WorkSpaces のタイムゾーンリダイレクトを無効](group_policy.md#gp_time_zone)にすることができます。[Linux WorkSpaces のタイムゾーンのリダイレクトを無効にする](manage_linux_workspace.md#linux_time_zone)には、PCoIP エージェントの設定を使用します。

Windows WorkSpaces には、グループポリシーを使用してメンテナンスウィンドウを設定できます。「[自動更新のためのグループポリシーの設定](https://docs.microsoft.com/windows-server/administration/windows-server-update-services/deploy/4-configure-group-policy-settings-for-automatic-updates)」を参照してください。Linux WorkSpaces のメンテナンスウィンドウを設定することはできません。

## AutoStop WorkSpaces のメンテナンスウィンドウ
<a name="autostop-maintenance"></a>

AutoStop WorkSpaces は重要な更新をインストールするために月に 1 度自動的に開始されます。その月の第 3 月曜日から開始して、2 週間、WorkSpace の AWS リージョンのタイムゾーンの毎日 0:00～5:00 に、メンテナンスウィンドウが開かれます。WorkSpace はメンテナンスウィンドウのいずれかの日に保守されます。このウィンドウでは、7 日間を超えて経過した WorkSpaces のみが保守されます。

WorkSpace のメンテナンス期間中、WorkSpace の状態は `MAINTENANCE` に設定されます。

AutoStop WorkSpaces のメンテナンスに使用するタイムゾーンを変更することはできませんが、以下のようにして AutoStop WorkSpaces のメンテナンスウィンドウを無効にすることはできます。メンテナンスモードを無効にすると、WorkSpaces は再起動されず、`MAINTENANCE` 状態になりません。

**メンテナンスモードを無効にするには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

1. ナビゲーションペインで **[ディレクトリ]** を選択します。

1. ディレクトリを選択し、[**Actions**]、[**Update Details**] の順に選択します。

1. [**メンテナンスモード**] を展開します。

1. 自動更新を有効にするには、[**Enabled**] を選択します。更新を手動で管理する場合は、[**無効**] を選択します。

1. [**Update and Exit**] を選択します。

## 手動メンテナンス
<a name="admin-maintenance"></a>

必要に応じて、独自のスケジュールで WorkSpaces を管理できます。メンテナンスタスクを実行する場合は、WorkSpace の状態を **[Maintenance]** (メンテナンス) に変更することをお勧めします。完了したら、WorkSpace の状態を **[Available]** (使用可能) に変更します。

WorkSpace が **[Maintenance]** (メンテナンス) 状態の場合、以下の動作が発生します。
+ WorkSpace は、再起動、停止、起動、再構築には対応しません。
+ ユーザーは WorkSpace にログインできません。
+ AutoStop WorkSpace は、休止状態ではありません。

**コンソールを使用して WorkSpace の状態を変更するには**
**注記**  
WorkSpace の状態を変更するには、WorkSpace のステータスが **[Available]** (使用可能) である必要があります。WorkSpace が **[Available]** (使用可能) 状態ではない場合、**[Modify state]** (変更状態) の設定は使用できません。

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. WorkSpace を選択して、**[Actions]** (アクション)、**[Modify state]** (状態の変更) の順に選択します。

1. **[Modify state]** (状態の変更) で、**[Available]** (使用可能) または **[Maintenance]** (メンテナンス) を選択します。

1. **[保存]** を選択します。

**AWS CLI を使用して WorkSpace の状態を変更するには**  
[modify-workspace-state](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-state.html) コマンドを使用します。

# WorkSpaces Personal の暗号化された WorkSpaces
<a name="encrypt-workspaces"></a>

WorkSpaces は AWS Key Management Service () と統合されていますAWS KMS。これにより、 AWS KMS キーを使用して WorkSpaces のストレージボリュームを暗号化できます。WorkSpace を起動する際に、ルートボリューム (Microsoft Windows の場合は C ドライブ、Linux の場合は /) およびユーザーボリューム (Windows の場合は D ドライブ、Linux の場合は /home) を暗号化できます。これにより、保管時のデータ、ボリュームへのディスク I/O、ボリュームから作成されたスナップショットを暗号化することができます。

**注記**  
WorkSpaces の暗号化に加えて、特定の AWS 米国リージョンで FIPS エンドポイント暗号化を使用することもできます。詳細については、「[WorkSpaces Personal で FedRAMP 認証または DoD SRG コンプライアンスを設定する](fips-encryption.md)」を参照してください。
Windows BitLocker 暗号化は Amazon WorkSpaces ではサポートされていません。  Amazon WorkSpaces は、該当する場合、すべての Windows オペレーティングシステムで起動中に検出されたボリュームの復号を試みます。  WorkSpace 上の任意のボリュームでパスワード、ピン、または起動キーの組み合わせが有効になっていると、起動プロセス中にボリュームが応答しなくなり、異常が発生して正しく起動できなくなる可能性があります。

**Topics**
+ [前提条件](#encryption_prerequisites)
+ [制限](#encryption_limits)
+ [を使用した WorkSpaces 暗号化の概要 AWS KMS](#kms-workspaces-overview)
+ [WorkSpaces 暗号化コンテキスト](#kms-workspaces-encryption-context)
+ [ユーザーに代わって KMS キーを使用する許可を WorkSpaces に付与する](#kms-workspaces-permissions)
+ [WorkSpace を暗号化します。](#encrypt_workspace)
+ [暗号化された WorkSpaces を表示する](#maintain_encryption)

## 前提条件
<a name="encryption_prerequisites"></a>

暗号化プロセスを開始する前に、 AWS KMS キーが必要です。この KMS キーは、AmazonWorkSpaces の [AWS 管理 KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)（**aws/workspaces**）または対称[カスタマー管理の KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)のいずれかになります。
+ **AWS マネージド KMS キー** – リージョンの WorkSpace sコンソールから暗号化されていない WorkSpaces を初めて起動すると、Amazon WorkSpaces はアカウントに AWS マネージド KMS キー (**aws/workspaces**) を自動的に作成します。この AWS マネージド KMS キーを選択して、WorkSpace のユーザーボリュームとルートボリュームを暗号化できます。詳細については、「[を使用した WorkSpaces 暗号化の概要 AWS KMS](#kms-workspaces-overview)」を参照してください。

  この AWS マネージド KMS キーは、ポリシーと許可を含めて表示でき、 AWS CloudTrail ログでの使用を追跡できますが、この KMS キーを使用または管理することはできません。Amazon WorkSpaces は、この KMS キーを作成および管理します。Amazon WorkSpaces だけがこの KMS を使用でき、WorkSpaces はアカウント内の WorkSpaces リソースの暗号化だけに使用できます。

  AWS Amazon WorkSpaces がサポートする マネージド KMS キーは、毎年ローテーションされます。詳細については、「 *AWS Key Management Service デベロッパーガイド*」の[「ローテーション AWS KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)」を参照してください。
+ **カスタマーマネージド KMS キー** – または、 を使用して作成した対称カスタマーマネージド KMS キーを選択できます AWS KMS。ポリシーの設定を含め、この KMS キーを表示、使用、管理できます。KMS キーの作成の詳細については、 *AWS Key Management Service デベロッパーガイド*の [キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) を参照してください。 AWS KMS API を使用して KMS キーを作成する方法の詳細については、「 *AWS Key Management Service デベロッパーガイド*」の[「キーの使用](https://docs.aws.amazon.com/kms/latest/developerguide/programming-keys.html)」を参照してください。

  自動キー更新を有効にしない限り、カスタマー管理の KMS キー は自動的に更新されません。詳細については、「 *AWS Key Management Service デベロッパーガイド*」の[AWS KMS 「キーのローテーション](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)」を参照してください。

**重要**  
KMS キーを手動でローテーションする場合は、元の KMS キーと新しい KMS キーの両方を有効にして、 AWS KMS が元の KMS キーが暗号化した WorkSpaces を復号できるようにする必要があります。元の KMS キーを有効にしたくない場合は、WorkSpaces を再作成し、新しい KMS キーを使用して暗号化する必要があります。

 AWS KMS キーを使用して WorkSpaces を暗号化するには、次の要件を満たす必要があります。
+ **KMS キーは対称である必要があります。**Amazon WorkSpaces では、非対称 KMS キーがサポートされていません。対称 KMS キーと非対称 KMS キーの区別については、「*AWS Key Management Service デベロッパーガイド*」の「[対称および非対称 KMS キーを識別する](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html)」を参照してください。
+ **KMS キーを有効にする必要があります。**KMS キーが有効になっているかどうかを確認する方法については、「*AWS Key Management Service デベロッパーガイド*」の 「[コンソールで KMS キーを表示する](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details)」を参照してください。
+ **KMS キーに正しいアクセス権限とポリシーを関連付ける必要があります。**詳細については、「[パート 2: IAM ポリシーを使用して WorkSpaces 管理者に追加の許可を付与する](#kms-permissions-iam-policy)」を参照してください。

## 制限
<a name="encryption_limits"></a>
+ 既存の WorkSpace は暗号化できません。WorkSpace を起動するときは、暗号化する必要があります。
+ 暗号化された WorkSpace からのカスタムイメージの作成は、サポートされていません。
+ 暗号化された WorkSpace の暗号化を無効にすることは、現在サポートされていません。
+ ルートボリュームの暗号化を有効にした状態で起動された WorkSpaces では、プロビジョニングに最大 1 時間かかる場合があります。
+ 暗号化された WorkSpace を再起動または再構築するには、 AWS KMS キーが有効であることを最初に確認します。有効ではない場合、WorkSpace は使用できません。KMS キーが有効になっているかどうかを確認する方法については、「*AWS Key Management Service デベロッパーガイド*」の 「[コンソールで KMS キーを表示する](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details)」を参照してください。

## を使用した WorkSpaces 暗号化の概要 AWS KMS
<a name="kms-workspaces-overview"></a>

暗号化されたボリュームで WorkSpaces を作成すると、WorkSpaces は Amazon Elastic Block Store (Amazon EBS) を使用してこれらのボリュームを作成および管理します。Amazon EBS は､業界標準の AES-256 アルゴリズムを使用してデータキーでボリュームを暗号化します。Amazon EBS と Amazon WorkSpaces の両方が KMS キーを使用して暗号化されたボリュームを操作します。EBS ボリューム暗号化の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)」を参照してください。

暗号化されたボリュームを使用するWorkSpaces を起動すると、エンドツーエンドの処理が次のように行われます。

1. 暗号化に使用する KMS キーと、WorkSpace のユーザーとディレクトリを指定します。このアクションにより、この WorkSpaces (指定されたユーザーとディレクトリに関連付けられた WorkSpace )にのみ KMS キーの使用を許可する[権限](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)が作成されます。

1. WorkSpaces は、WorkSpace の暗号化された EBS ボリュームを作成し、使用する KMS キーとボリュームのユーザーおよびディレクトリを指定します。このアクションにより、Amazon EBS が WorkSpace とボリューム (指定されたユーザーとディレクトリに関連付けられた WorkSpace および指定されたボリューム) にのみ KMS キーを使用できるようにする権限が作成されます。

1. <a name="WSP-EBS-requests-encrypted-volume-data-key"></a>Amazon EBS は、KMS キーによって暗号化されたボリュームデータキーをリクエストし、WorkSpace ユーザーの Active Directory セキュリティ識別子 (SID) および AWS Directory Service ディレクトリ ID、ならびに[暗号化コンテキスト](#kms-workspaces-encryption-context)としての Amazon EBS ボリューム ID を指定します。

1. <a name="WSP-KMS-creates-data-key"></a>AWS KMS は新しいデータキーを作成し、KMS キーで暗号化してから、暗号化されたデータキーを Amazon EBS に送信します。

1. <a name="WSP-uses-EBS-to-attach-encrypted-volume"></a>WorkSpaces は、Amazon EBS を使用して、暗号化されたボリュームを WorkSpace にアタッチします。Amazon EBS は、暗号化されたデータキーを [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) リクエスト AWS KMS とともに に送信し、暗号化コンテキストとして使用される WorkSpace ユーザーの SID、ディレクトリ ID、ボリューム ID を指定します。

1. AWS KMS は KMS キーを使用してデータキーを復号し、プレーンテキストのデータキーを Amazon EBS に送信します。

1. Amazon EBS は、プレーンテキストデータキーを使用して、暗号化されたボリュームを出入りするすべてのデータを暗号化します。Amazon EBS は、ボリュームが WorkSpace にアタッチされている限り、プレーンテキストデータキーをメモリ内に保持します。

1. Amazon EBS は、暗号化されたデータキー ([Step 4](#WSP-KMS-creates-data-key) で受け取ったデータキー) とボリュームメタデータを保存し、後で WorkSpace を再起動または再構築した場合に使用できるようにします。

1. を使用して WorkSpace AWS マネジメントコンソール を削除する (または WorkSpaces API で [https://docs.aws.amazon.com/workspaces/latest/devguide/API_TerminateWorkspaces.html](https://docs.aws.amazon.com/workspaces/latest/devguide/API_TerminateWorkspaces.html)アクションを使用する) と、WorkSpaces と Amazon EBS は、その WorkSpace の KMS キーの使用を許可した許可を廃止します。

## WorkSpaces 暗号化コンテキスト
<a name="kms-workspaces-encryption-context"></a>

WorkSpaces は暗号化オペレーション ([https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html)、、 など) [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)に KMS キーを直接使用しません。つまり[https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)、WorkSpaces は[暗号化コンテキスト](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) AWS KMS を含む にリクエストを送信しません。ただし、Amazon EBS が、WorkSpaces の暗号化されたボリュームに対して暗号化されたデータキーをリクエストする場合 ([Step 3](#WSP-EBS-requests-encrypted-volume-data-key) の [を使用した WorkSpaces 暗号化の概要 AWS KMS](#kms-workspaces-overview)) と、そのデータキーのプレーンテキストコピーをリクエストする場合 ([Step 5](#WSP-uses-EBS-to-attach-encrypted-volume)) には、リクエストに暗号化コンテキストが含まれます。

 暗号化コンテキストは、データの整合性を確保するために が AWS KMS 使用する[追加の認証済みデータ](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (AAD) を提供します。暗号化コンテキストは AWS CloudTrail ログファイルにも書き込まれるため、特定の KMS キーが使用された理由を理解するのに役立ちます。Amazon EBS では、暗号化コンテキストとして次のものが使用されます。
+ WorkSpace に関連付けられている Active Directory ユーザーのセキュリティ識別子 (SID)
+ WorkSpace に関連付けられているディレクトリの AWS Directory Service ディレクトリ ID
+ 暗号化されたボリュームの Amazon EBS ボリューム ID

次の例は、Amazon EBS が使用する暗号化コンテキストの JSON 表現を示しています。

```
{
  "aws:workspaces:sid-directoryid": "[S-1-5-21-277731876-1789304096-451871588-1107]@[d-1234abcd01]",
  "aws:ebs:id": "vol-1234abcd"
}
```

## ユーザーに代わって KMS キーを使用する許可を WorkSpaces に付与する
<a name="kms-workspaces-permissions"></a>

WorkSpace sの AWS マネージド KMS キー (**aws/workspaces**) またはカスタマーマネージド KMS キーで WorkSpaces データを保護できます。カスタマー管理 KMS キーを使用する場合は、アカウントの WorkSpaces 管理者に代わって KMS キーを使用する WorkSpaces 許可を与える必要があります。WorkSpaces の AWS マネージド KMS キーには、デフォルトで必要なアクセス許可があります。

WorkSpaces で使用する KNS キーを準備するには、次の手順を実行します。

1. [KMS キーのキーポリシーでキーユーザーのリストに WorkSpaces 管理者を追加する](#kms-permissions-key-users)

1. [IAM ポリシーによって WorkSpaces 管理者に追加のアクセス許可を付与する](#kms-permissions-iam-policy)

WorkSpaces 管理者には、WorkSpaces を使用する許可も必要です。これらのアクセス許可の詳細については、[WorkSpaces の Identity and Access Management](workspaces-access-control.md) にアクセスしてください。

### パート 1: WorkSpaces の管理者をキーユーザーとして追加する
<a name="kms-permissions-key-users"></a>

WorkSpaces 管理者に必要なアクセス許可を付与するには、 AWS マネジメントコンソール または AWS KMS API を使用できます。

#### KMS キーのキーユーザーとして WorkSpaces 管理者を追加するには (コンソール)
<a name="kms-permissions-users-consoleAPI"></a>

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) で AWS Key Management Service (AWS KMS) コンソールを開きます。

1. を変更するには AWS リージョン、ページの右上隅にあるリージョンセレクターを使用します。

1. ナビゲーションペインで、[**Customer managed keys**] (カスタマー管理型のキー) を選択します。

1. 任意のカスタマーマネージドキーの KMS キーのキー ID またはエイリアスを選択する

1. [**キーポリシー**] タブを選択します。[**Key users**] (キーユーザー) で [**Add**] (追加) を選択します。

1. IAM ユーザーとロールのリストで、WorkSpaces 管理者に対応するユーザーとロールを選択し、[**Add**] (追加) を選択します。

#### KMS キーのキーユーザーとして WorkSpaces 管理者を追加するには ( API)
<a name="kms-permissions-users-api"></a>

1. [GetKeyPolicy](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html) オペレーションを使用して既存のキーポリシードキュメントを取得し、キーポリシードキュメントをファイルに保存します。

1. 任意のテキストエディタでポリシードキュメントを開きます。WorkSpaces 管理者に対応する IAM ユーザーとロールを、[キーユーザーにアクセス許可を付与する](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users)ポリシーステートメントに追加します。その後、ファイルを保存します。

1. [PutKeyPolicy](https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html) オペレーションを使用して、KMS キーにキーポリシーを適用します。

### パート 2: IAM ポリシーを使用して WorkSpaces 管理者に追加の許可を付与する
<a name="kms-permissions-iam-policy"></a>

カスタマー管理の KMS キーを選択して暗号化に使用する場合は、アカウントで暗号化された WorkSpaces を起動する IAM ユーザーの代わりに、Amazon WorkSpaces で KMS キーの使用を許可する IAM ポリシーを確立する必要があります。また、そのユーザーにも、Amazon WorkSpaces を使用するための許可が必要です。IAM ユーザーポリシーの作成と編集の詳細については、*IAM ユーザーガイド*の [IAM ポリシーを管理する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)および [WorkSpaces の Identity and Access Management](workspaces-access-control.md) を参照してください。

WorkSpaces の暗号化では、KMS キーへのアクセスを制限する必要があります。以下は、使用できるサンプルキーのポリシーです。このポリシーにより、 AWS KMS キーを管理できるプリンシパルと、このキーを使用できるプリンシパルが分離されます。このサンプルキーポリシーを使用する前に、サンプルアカウント ID と IAM ユーザー名を、アカウントの実際の値に置き換えてください。

最初のステートメントは、デフォルトの AWS KMS キーポリシーと一致します。これにより、IAM ポリシーを使用して KMS キーへのアクセスを制御するためのアクセス許可がアカウントに付与されます。2 番目と 3 番目のステートメントは、キーを管理および使用できる AWS プリンシパルをそれぞれ定義します。4 番目のステートメントでは、 と統合された AWS サービスが AWS KMS 、指定されたプリンシパルに代わって キーを使用できます。このステートメントは、 AWS のサービスが許可を作成、管理できるようにします。ステートメントは、KMS キーに対する許可を、アカウントのユーザーに代わって AWS のサービスによって行われた許可に制限する条件要素を使用します。

**注記**  
WorkSpaces 管理者が を使用して暗号化されたボリュームを持つ WorkSpaces AWS マネジメントコンソール を作成する場合、管理者はエイリアスとリストキー ( `"kms:ListAliases"` および のアクセス許可) を一覧表示するアクセス`"kms:ListKeys"`許可が必要です。WorkSpaces 管理者が (コンソールではなく) Amazon WorkSpaces API のみを使用する場合は、`"kms:ListAliases"` および `"kms:ListKeys"` のアクセス許可を省略できます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:user/Alice"},
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*"
       ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:user/Alice"},
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncryptFrom",
        "kms:ReEncryptTo",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:user/Alice"},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": "true"}}
    }
  ]
}
```

------

WorkSpace を暗号化しているロールまたはユーザーに適用する IAM ポリシーには、カスタマー管理の KMS キーを使用するためのアクセス許可と WorkSpaces へのアクセス権が必要です。IAM ユーザーまたはロールに WorkSpaces のアクセス許可を付与するには、以下のサンプルポリシーを IAM ユーザーまたはロールにアタッチします。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ds:*",
                "ds:DescribeDirectories",
                "workspaces:*",
                "workspaces:DescribeWorkspaceBundles",
                "workspaces:CreateWorkspaces",
                "workspaces:DescribeWorkspaceBundles",
                "workspaces:DescribeWorkspaceDirectories",
                "workspaces:DescribeWorkspaces",
                "workspaces:RebootWorkspaces",
                "workspaces:RebuildWorkspaces"
            ],
            "Resource": "*"
        }
    ]
}
```

------

ユーザーが を使用するには、次の IAM ポリシーが必要です AWS KMSこれにより、KMS キーへの読み取り専用アクセスと、許可を作成する能力がユーザーに付与されます。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:CreateGrant",
                "kms:Describe*",
                "kms:List*"
            ],
            "Resource": "*"
        }
    ]
}
```

------

ポリシーで KMS キーを指定する場合は、次のような IAM ポリシーを使用します。サンプルKMS キー ARN を有効なものに置き換えます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:ListAliases",
        "kms:ListKeys"
      ],
      "Resource": "*"
    }
  ]
}
```

------

## WorkSpace を暗号化します。
<a name="encrypt_workspace"></a>

**WorkSpace を暗号化するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

1. [**Launch WorkSpaces**] を選択し､最初の 3 つの手順を完了します。

1. [**WorkSpaces Configuration**] のステップで､以下を行います｡

   1. 暗号化するボリュームを選択します。[**Root Volume**]、[**User Volume**]、または両方のボリュームとなります。

   1. **暗号化キー**で、Amazon WorkSpaces によって作成された AWS マネージド KMS キーまたは作成した KMS キー AWS KMS のいずれかのキーを選択します。選択する KMS キーは対称である必要があります。Amazon WorkSpaces では、非対称 KMS キーがサポートされていません。

   1. [**Next Step**] を選択します。

1. [**Launch WorkSpaces**] を選択します。

## 暗号化された WorkSpaces を表示する
<a name="maintain_encryption"></a>

どの WorkSpaces とボリュームが WorkSpaces コンソールから暗号化されたのかを表示するには、左のナビゲーションバーから [**WorkSpaces**] を選択します。[**Volume Encryption**] 列に、各 WorkSpace で暗号化が有効になっているか無効になっているかが表示されます。特定のボリュームが暗号化されているかどうかを表示するには、WorkSpace エントリを展開して [**Encrypted Volumes**] フィールドを確認します。

# WorkSpaces Personal の WorkSpace を再起動する
<a name="reboot-workspaces"></a>

場合によっては、WorkSpace を手動で再起動する必要があります。WorkSpace を再起動すると、ユーザーが切断され、WorkSpace のシャットダウンと再起動が実行されます。データの損失を避けるため、WorkSpace を再起動する前に、開いているドキュメントやその他のアプリケーションファイルを必ず保存してください。ユーザーデータ、オペレーティングシステム、およびシステム設定には影響しません。

**警告**  
暗号化された WorkSpace を再起動するには、AWS KMS キーが有効であることを最初に確認します。有効でない場合、WorkSpace は使用できません。KMS キーが有効になっているかどうかを確認する方法については、「*AWS Key Management Service デベロッパーガイド*」の 「[コンソールで KMS キーを表示する](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details)」を参照してください。

**WorkSpace を再起動するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. 再起動する WorkSpaces を選択したら、**[Actions] ** (アクション)、**[Reboot WorkSpaces]** (WorkSpaces の再起動) の順に選択します。

1. 確認を求めるメッセージが表示されたら、[**Reboot WorkSpaces**] を選択します。

**を使用して WorkSpace を再起動するにはAWS CLI**  
[reboot-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/reboot-workspaces.html) コマンドを使用します。

**WorkSpaces を一括再起動するには**  
[amazon-workspaces-admin-module](https://github.com/aws-samples/amazon-workspaces-admin-module/tree/main) を使用します。

# WorkSpaces Personal の WorkSpace を再構築する
<a name="rebuild-workspace"></a>

WorkSpace を再構築すると、WorkSpace の起動元のバンドルの最新イメージのルートボリューム、ユーザーボリューム、およびプライマリ Elastic Network Interface が再作成されます。WorkSpace を再構築すると、WorkSpace を復元するよりも多くのデータが削除されますが、必要なのはユーザーボリュームのスナップショットだけです。WorkSpace を復元するには、「[WorkSpaces Personal の WorkSpace を復元する](restore-workspace.md)」を参照してください。

WorkSpace を再構築すると、次の状況が発生します。
+ ルートボリューム (Microsoft Windows の場合はドライブ C、Linux の場合は /) は、WorkSpace の作成元のバンドルの最新のイメージで更新されます。WorkSpace の作成後にインストールされたアプリケーション、または変更されたシステム設定は失われます。
+ ユーザーボリューム (Microsoft Windows の場合は D: ドライブ、Linux の場合は /home) が、最新のスナップショットから再作成されます。ユーザーボリュームの現在の内容は上書きされます。

  WorkSpace を再構築するときに使用する自動スナップショットは、12 時間ごとにスケジュールされます。ユーザーボリュームのこれらのスナップショットは、WorkSpace の正常性に関係なく取得されます。[**Actions**] (アクション)、[**Rebuild / Restore WorkSpace**] (WorkSpace のリビルドとリストア) を選択すると、最新のスナップショットの日付と時刻が表示されます。

  WorkSpace を再構築すると、再構築が完了した直後に (多くの場合 30 分以内に) 新しいスナップショットも作成されます。
+ プライマリ Elastic Network Interface が再作成されます。WorkSpace は新しいプライベート IP アドレスを受け取ります。

**重要**  
2020 年 1 月 14 日以降、パブリック Windows 7 バンドルから作成された WorkSpaces を再構築することはできません。Windows 7 の WorkSpaces については、Windows 10 への移行を検討することをお勧めします。詳細については、「[WorkSpaces Personal で WorkSpace を移行する](migrate-workspaces.md)」を参照してください。

WorkSpace を再構築できるのは、次の条件が満たされている場合のみです。
+ WorkSpace の状態は、`AVAILABLE`、`ERROR`、`UNHEALTHY`、`STOPPED`、または `REBOOTING` である必要があります。`REBOOTING` 状態の WorkSpace を再構築するには、[RebuildWorkspaces](https://docs.aws.amazon.com/workspaces/latest/api/API_RebuildWorkspaces.html) API オペレーションまたは [rebuild-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/rebuild-workspaces.html) AWS CLI コマンドを使用する必要があります。
+ ユーザーボリュームのスナップショットが存在する必要があります。

**WorkSpace を再構築するには**
**警告**  
暗号化された WorkSpace を再構築するには、AWS KMS キーが有効であることを最初に確認します。有効でない場合、WorkSpace は使用できません。KMS キーが有効になっているかどうかを確認する方法については、「*AWS Key Management Service デベロッパーガイド*」の 「[コンソールで KMS キーを表示する](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details)」を参照してください。

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. 再ビルドする WorkSpace を選択したら、**[Actions]** (アクション)、**[Rebuild / Restore WorkSpace]** (WorkSpace の再ビルド / 復元) の順に選択します。

1. **[Snapshot]** (スナップショット) で、スナップショットのタイムスタンプを選択します。

1. [**Rebuild**] を選択します。

**AWS CLI を使用して WorkSpace を再構築するには**  
[rebuild-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/rebuild-workspaces.html) コマンドを使用します。

**トラブルシューティング**  
Active Directory でユーザーの **sAMAccountName** ユーザー命名属性を変更した後に WorkSpace を再構築すると、次のエラーメッセージが表示されることがあります。

```
"ErrorCode": "InvalidUserConfiguration.Workspace"
"ErrorMessage": "The user was either not found or is misconfigured."
```

この問題を回避するには、ユーザー命名属性を元に戻してから再ビルドをするか、そのユーザー用に新しい WorkSpace を作成します。

**Microsoft Entra ID に参加済みの WorkSpaces を再構築する**  
ユーザーが再構築後に初めて WorkSpace にログインするときは、新しい WorkSpace が割り当てられたときと同様に、Out of Box Experience (OOBE) を再度実行する必要があります。その結果、WorkSpace に新しいユーザープロファイルフォルダが作成され、元のユーザープロファイルフォルダが上書きされます。したがって、Entra に参加している WorkSpace の再構築中、元のユーザープロファイルフォルダのコンテンツは再構築された WorkSpace の `D:\Users\<USERNAME%MMddyyTHHmmss%.NotMigrated>` に保存されます。デスクトップアイコン、ショートカット、データファイルを含むすべてのユーザープロファイルデータを復元するには、ユーザーが元のプロファイルコンテンツを `D:\Users\<USERNAME%MMddyyTHHmmss%.NotMigrated>` からユーザーのプロファイルフォルダ D:\$1Users\$1<USERNAME> にコピーする必要があります。

**注記**  
Microsoft Entra ID に参加している WorkSpaces では、可能な場合は常に、WorkSpaces の再構築ではなく WorkSpaces の復元を使用することをお勧めします。

# WorkSpaces Personal の WorkSpace を復元する
<a name="restore-workspace"></a>

WorkSpace を復元すると、WorkSpace が正常であったときに取得された各ボリュームのスナップショットを使用して、ルートボリュームとユーザーボリュームの両方が再作成されます。WorkSpace を復元すると、ルートボリュームとユーザーボリュームの両方のデータが、スナップショットが作成された時点までロールバックされます。WorkSpace を再構築すると、ユーザーボリュームのデータのみがロールバックされます。つまり、WorkSpace の再構築にはユーザーボリュームのスナップショットのみが必要であるのに対して、復元にはルートボリュームとユーザーボリュームの両方のスナップショットが必要になります。WorkSpace を再構築するには、「[WorkSpaces Personal の WorkSpace を再構築する](rebuild-workspace.md)」を参照してください。

WorkSpace を復元すると、次の状況が発生します。
+ ルートボリューム (Microsoft Windows の場合はドライブ C、Linux の場合は /) は、スナップショットを使用して、指定された日時で復元されます。スナップショットが作成された後にインストールされたアプリケーション、または変更されたシステム設定は失われます。
+ ユーザーボリューム (Microsoft Windows の場合は D ドライブ、Linux の場合は /home) は、スナップショットを使用して、指定された日時で再作成されます。ユーザーボリュームの現在の内容は上書きされます。

**復元ポイント**  
**[アクション]**、**[WorkSpace のリビルドとリストア]** の順に選択すると、操作に使用されるスナップショットの日付と時刻が表示されます。操作に使用されるスナップショットの日付と時刻を AWS CLI で確認するには、[describe-workspace-snapshots](https://docs.aws.amazon.com/cli/latest/reference/workspaces/describe-workspace-snapshots.html) コマンドを使用します。

**スナップショットが作成される場合**  
ルートボリュームとユーザーボリュームのスナップショットは、次の基準で取得されます。
+ **WorkSpace が最初に作成された後** — 通常、ルートボリュームとユーザーボリュームの最初のスナップショットは、WorkSpace の作成後すぐに (多くの場合 30 分以内に) 作成されます。AWS リージョンによっては、WorkSpace の作成後に最初のスナップショットが作成されるまで数時間かかる場合があります。

  最初のスナップショットが作成される前に WorkSpace が異常になった場合、WorkSpace を復元することはできません。その場合は、[WorkSpace の再構築](rebuild-workspace.md)を試みるか、AWS Support にお問い合わせください。
+ **通常使用中** — WorkSpace の復元時に使用する自動スナップショットは、12 時間ごとにスケジュールされます。WorkSpace が正常であれば、ルートボリュームとユーザーボリュームの両方のスナップショットがほぼ同時に作成されます。WorkSpace に不具合がある場合、スナップショットはユーザーボリュームに対してのみ作成されます。
+ **WorkSpace が復元された後** — WorkSpace を復元すると、復元が完了した直後に (多くの場合 30 分以内に) 新しいスナップショットが作成されます。AWS リージョンによっては、WorkSpace の復元後にこれらのスナップショットが作成されるまで数時間かかる場合があります。

  WorkSpace を復元した後、新しいスナップショットを作成する前に WorkSpace が異常になった場合、WorkSpace を再び復元することはできません。その場合は、[WorkSpace の再構築](rebuild-workspace.md)を試みるか、AWS Support にお問い合わせください。

WorkSpace を復元できるのは、次の条件が満たされている場合のみです。
+ WorkSpace の状態は、`AVAILABLE`、`ERROR`、`UNHEALTHY`、または `STOPPED` である必要があります。
+ ルートボリュームとユーザーボリュームのスナップショットが存在する必要があります。

**WorkSpace を復元するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. 復元する WorkSpace を選択したら、**[Actions]** (アクション)、**[Rebuild / Restore WorkSpace]** (WorkSpace の再ビルド / 復元) の順に選択します。

1. **[Snapshot]** (スナップショット) で、スナップショットのタイムスタンプを選択します。

1. **[復元]** を選択します。

**AWS CLI を使用して WorkSpace を復元するには**  
[restore-workspace](https://docs.aws.amazon.com/cli/latest/reference/workspaces/restore-workspace.html) コマンドを使用します。

# WorkSpaces Personal での Microsoft 365 Bring Your Own License (BYOL)
<a name="byol-microsoft365-licenses"></a>

Amazon WorkSpaces では、Microsoft のライセンス要件を満たしていれば、独自の Microsoft 365 ライセンスを持ち込むことができます。これらのライセンスにより、以下のオペレーティングシステムを搭載した WorkSpaces に Microsoft 365 Apps for enterprise ソフトウェアをインストールしてアクティブ化することができます。
+ Windows 10 (Bring Your Own License)
+ Windows 11 (Bring Your Own License)
+ Windows Server 2016
+ Windows Server 2019
+ Windows Server 2022
+ Windows Server 2025

WorkSpaces で Microsoft 365 Apps for enterprise を使用するには、Microsoft 365 E3/E5、Microsoft 365 A3/A5、Microsoft 365 G3/G5、または Microsoft 365 Business Premium のサブスクリプションが必要です。

Amazon WorkSpaces では、Microsoft 365 ライセンスを使用して、以下を含む Microsoft 365 Apps for enterprise をインストールおよびアクティブ化できます。
+ Microsoft Word
+ Microsoft Excel
+ Microsoft PowerPoint
+ Microsoft Outlook
+ Microsoft OneDrive

詳細については、[Microsoft 365 Apps for enterprise の詳細なリスト](https://www.microsoft.com/en/microsoft-365/enterprise/microsoft-365-apps-for-enterprise-product?activetab=pivot%3Aoverviewtab&market=af&ranMID=24542&ranEAID=QKfOgZNb5HA&ranSiteID=QKfOgZNb5HA-uvIr8evP5gLQf8n3Z0NLJA&epi=QKfOgZNb5HA-uvIr8evP5gLQf8n3Z0NLJA&irgwc=1&OCID=AIDcmm549zy227_aff_7593_1243925&tduid=%28ir__caugvllhggkfbgesuvvv2g21je2xb3afmz3ilkpl00%29%287593%29%281243925%29%28QKfOgZNb5HA-uvIr8evP5gLQf8n3Z0NLJA%29%28%29&irclickid=_caugvllhggkfbgesuvvv2g21je2xb3afmz3ilkpl00)を参照してください。

Microsoft 365 に含まれていない Microsoft アプリケーション (Microsoft Project、Microsoft Visio、Microsoft Power Automate など) を WorkSpaces にインストールすることもできますが、自分の追加ライセンスを用意する必要があります。

プライマリ WorkSpaces とフェイルオーバー WorkSpaces には[マルチリージョンレジリエンス](https://docs.aws.amazon.com/workspaces/latest/adminguide/multi-region-resilience.html)を使用して、Microsoft 365 やその他の Microsoft アプリケーションをインストールして使用できます。

**Topics**
+ [Microsoft 365 Apps for enterprise でワークスペースを作成](#create-workspaces-microsoft365)
+ [既存の WorkSpaces を移行して、Microsoft 365 Apps for enterprise を使用する](#migrate-workspaces-microsoft365)
+ [WorkSpaces で Microsoft 365 Apps for enterprise を更新する](#microsoft365-update)

## Microsoft 365 Apps for enterprise でワークスペースを作成
<a name="create-workspaces-microsoft365"></a>

Microsoft 365 Apps for enterprise で WorkSpaces を作成するには、アプリケーションをインストールしたカスタムイメージを作成し、それを使用してカスタムバンドルを作成する必要があります。このバンドルを使用して、アプリケーションがインストールされた新しい WorkSpaces を起動できます。WorkSpaces では、Microsoft 365 Apps for enterprise のパブリックバンドルは提供していません。

**Microsoft 365 Apps for enterprise で WorkSpace を作成するには:**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

1. 他の Microsoft アプリケーション WorkSpaces のイメージとして使用する WorkSpace を起動します。ここに Microsoft アプリケーションをインストールします。WorkSpaces の起動の詳細については、「[WorkSpaces を使用して仮想デスクトップを起動する](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html)」を参照してください。

1. [https://clients.amazonworkspaces.com/](https://clients.amazonworkspaces.com/) でクライアントアプリケーションを起動し、招待メールに記載されている登録コードを入力して、**[登録]** を選択します。

1. サインインするように求められたら、ユーザーのサインイン認証情報を入力し、**[Sign In]** (サインイン) を選択します。

1. Microsoft 365 Apps for enterprise をインストールして設定します。

1. WorkSpace からカスタムイメージを作成し、それを使用してカスタムバンドルを作成します。カスタムイメージとバンドルの作成の詳細については、「[カスタムの WorkSpaces イメージとバンドルの作成](https://docs.aws.amazon.com/workspaces/latest/adminguide/create-custom-bundle.html)」を参照してください。

1. 作成したカスタムバンドルを使用して WorkSpaces を起動します。これらの WorkSpaces には、Microsoft 365 Apps for enterprise がインストールされています。

## 既存の WorkSpaces を移行して、Microsoft 365 Apps for enterprise を使用する
<a name="migrate-workspaces-microsoft365"></a>

WorkSpaces に による Microsoft Office ライセンスがない場合は AWS、WorkSpaces に Microsoft 365 Apps for enterprise をインストールして設定できます。

 WorkSpaces に を通じて Microsoft Office ライセンスがある場合は AWS、エンタープライズ用 Microsoft 365 Apps をインストールする前に、まず Microsoft Office ライセンスの登録を解除する必要があります。

**重要**  
WorkSpaces から Microsoft Office アプリケーションをアンインストールしても、ライセンスは登録解除されません。Microsoft Office ライセンスの料金が発生しないようにするには、次のいずれか AWS を実行して、 を使用して Microsoft Office アプリケーションから WorkSpaces を登録解除します。  
 **アプリケーションの管理** (推奨) – Microsoft Office バージョンのライセンスを WorkSpaces からアンインストールできます。詳細については、「[アプリケーションの管理](manage-applications)」を参照してください。アンインストール後は、WorkSpaces に Microsoft 365 Apps for enterprise をインストールできます。
 **WorkSpace の移行** – ユーザーボリューム上のデータを保持しながら、1 つのバンドルから別のバンドルに WorkSpace を移行できます。  
WorkSpaces を Microsoft Office サブスクリプションのないイメージを含むバンドルに移行します。移行が完了すると、WorkSpaces に Microsoft 365 Apps for enterprise をインストールできます。
または、イメージに既に Microsoft 365 Apps for enterprise がインストールされているカスタム WorkSpaces イメージとバンドルを作成してから、WorkSpaces をこの新しいカスタムバンドルに移行します。移行が完了すると、WorkSpaces ユーザーは Microsoft 365 Apps for enterprise の使用を開始できます。
WorkSpaces の移行方法の詳細については、「[WorkSpace の移行](migrate-workspaces)」を参照してください。

## WorkSpaces で Microsoft 365 Apps for enterprise を更新する
<a name="microsoft365-update"></a>

デフォルトでは、Microsoft Windows オペレーティングシステムで実行されている WorkSpaces は Windows Update から更新プログラムを受信するように設定されています。ただし、Microsoft 365 Apps for enterprise の更新プログラムは Windows Update ではご利用いただけません。更新を Office CDN から自動的に実行するように設定するか、Windows Server Update Services (WSUS) を Microsoft Configuration Manager と組み合わせて使用して Microsoft 365 Apps for enterprise を更新します。詳細については、「[Microsoft Configuration Manager を使用して Microsoft 365 Apps の更新プログラムを管理する](https://learn.microsoft.com/en-us/deployoffice/updates/manage-microsoft-365-apps-updates-configuration-manager)」を参照してください。Microsoft 365 アプリケーションの更新頻度を設定するには、更新チャネルを指定し、Microsoft 365 on WorkSpaces のライセンスポリシーに準拠するように、[現在のチャネル] または [月次エンタープライズチャネル] に設定します。

# WorkSpaces Personal で Windows BYOL WorkSpaces をアップグレードする
<a name="upgrade-windows-10-byol-workspaces"></a>

Windows Bring-Your-Own-License (BYOL) WorkSpaces では、インプレースアップグレードプロセスを使用して新しいバージョンの Windows にアップグレードできます。アップグレードするには、このトピックの手順に従います。

インプレースアップグレードプロセスは、Windows 10 および 11 の BYOL WorkSpaces にのみ適用されます。

**重要**  
アップグレード済みの WorkSpace で Sysprep を実行しないでください。その場合、Sysprep が終了できないエラーが発生することがあります。Sysprep を実行する予定の場合は、アップグレードされていない WorkSpace のみで使用してください。

**注記**  
このプロセスを使用して Windows 10 および 11 の WorkSpaces を新しいバージョンにアップグレードできます。ただし、このプロセスを使用して Windows 10 WorkSpaces を Windows 11 にアップグレードすることはできません。

**Topics**
+ [前提条件](#upgrade_byol_prerequisites)
+ [考慮事項](#upgrade_byol_important_considerations)
+ [既知の制限事項](#byol-known-limitations)
+ [レジストリキー設定の概要](#upgrade_byol_registry_summary)
+ [インプレースアップグレードの実行](#upgrade_byol_procedure)
+ [トラブルシューティング](#byol-troubleshooting)
+ [PowerShell スクリプトを使用して WorkSpace レジストリを更新する](#update-windows-10-byol-script)

## 前提条件
<a name="upgrade_byol_prerequisites"></a>
+ グループポリシーや System Center Configuration Manager (SCCM) を使用して Windows 10 および 11 のアップグレードを延期または一時停止した場合は、Windows 10 および 11 の WorkSpaces に対してオペレーティングシステムのアップグレードを有効にします。
+ WorkSpace が自動停止 WorkSpace である場合は、AlwaysOn WorkSpace に変更してからインプレースアップグレードプロセスを開始し、更新の適用中に自動停止しないようにします。詳細については、「[実行モードを変更する](running-mode.md#modify-running-mode)」を参照してください。WorkSpace を AutoStop に設定したままにする場合は、アップグレードの実行中に自動停止時間を 3 時間以上に変更します。
+ インプレースアップグレードプロセスでは、Default User (`C:\Users\Default`) という名前の特別なプロファイルのコピーを作成することで、ユーザープロファイルを再作成します。このデフォルトのユーザープロファイルを使用してカスタマイズを行わないでください。代わりに、グループポリシーオブジェクト (GPO) を使用してユーザープロファイルをカスタマイズすることをお勧めします。GPO を使用して行ったカスタマイズは変更やロールバックが容易なため、エラーが発生しにくくなります。
+ インプレースアップグレードプロセスでは、1 つのユーザープロファイルだけをバックアップおよび再作成できます。ドライブ D に複数のユーザープロファイルがある場合は、必要なプロファイルを除くすべてのプロファイルを削除します。

## 考慮事項
<a name="upgrade_byol_important_considerations"></a>

インプレースアップグレードプロセスでは、2 つのレジストリスクリプト (`enable-inplace-upgrade.ps1` および `update-pvdrivers.ps1`) を使用して、Windows Update プロセスの実行に必要な変更を WorkSpaces に加えます。これらの変更には、ドライブ D ではなくドライブ C に (一時的な) ユーザープロファイルを作成することが含まれます。ユーザープロファイルがドライブ D にすでに存在する場合、その元のユーザープロファイルのデータはドライブ D に残ります。

デフォルトでは、WorkSpaces は `D:\Users\%USERNAME%` にユーザープロファイルを作成します。`enable-inplace-upgrade.ps1` スクリプトは、`C:\Users\%USERNAME%` に新しいユーザープロファイルを作成するように Windows を設定し、ユーザーシェルフォルダを `D:\Users\%USERNAME%` にリダイレクトします。この新しいユーザープロファイルは、ユーザーが初めてログオンしたときに作成されます。

インプレースアップグレード後、ユーザープロファイルをドライブ C に残して、ユーザーが今後に Windows Update プロセスを使用してマシンをアップグレードできるようにすることが可能です。ただし、ドライブ C にプロファイルが保存されている WorkSpaces は、再構築または移行すると、自分でデータをバックアップして復元しない限り、ユーザープロファイルのすべてのデータは失われます。ドライブ C にプロファイルを残す場合は、このトピックで後述するように、**UserShellFoldersRedirection** レジストリキーを使用して、ユーザーシェルフォルダをドライブ D にリダイレクトできます。

WorkSpaces を確実に再構築または移行できるようにしたり、ユーザーシェルフォルダのリダイレクトに関する起こり得る問題を回避したりするには、インプレースアップグレード後にユーザープロファイルをドライブ D に復元することをお勧めします。そのためには、このトピックで後述するように、**PostUpgradeRestoreProfileOnD** レジストリキーを使用します。

## 既知の制限事項
<a name="byol-known-limitations"></a>
+ ドライブ D からドライブ C へのユーザープロファイルの場所の変更は、WorkSpace の再構築または移行中には行われません。Windows 10 および 11 の BYOL WorkSpace でインプレースアップグレードを実行してから、その WorkSpace を再構築または移行すると、新しい WorkSpace のドライブ D にユーザープロファイルが作成されます。
**警告**  
インプレースアップグレード後にユーザープロファイルをドライブ C に残しておくと、ドライブ C に保存されているユーザープロファイルデータは、再構築または移行前にユーザープロファイルデータを手動でバックアップし、再構築または移行後に手動で復元しない限り、再構築または移行中に失われます。
+ また、デフォルトの BYOL バンドル内のイメージが旧リリースの Windows 10 および 11 に基づいている場合は、WorkSpace の再構築または移行後に再度インプレースアップグレードを実行する必要があります。

## レジストリキー設定の概要
<a name="upgrade_byol_registry_summary"></a>

インプレースアップグレードプロセスを有効にして、アップグレード後にユーザープロファイルを配置する場所を指定するには、複数のレジストリキーを設定する必要があります。


**レジストリパス: **HKLM:\$1Software\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1****  

| レジストリキー | タイプ | 値 | 
| --- | --- | --- | 
| 有効 | DWORD |  **0** – (デフォルト) インプレースアップグレードを無効にする **1** – インプレースアップグレードを有効にする  | 
| PostUpgradeRestoreProfileOnD | DWORD |  **0** – (デフォルト) インプレースアップグレード後にユーザープロファイルパスの復元を試みない **1** – インプレースアップグレード後にユーザープロファイルパス (**ProfileImagePath**) を復元する  | 
| UserShellFoldersRedirection | DWORD |  **0** – ユーザーシェルフォルダのリダイレクトを有効にしない **1** – (デフォルト) ユーザープロファイルが `D:\Users\%USERNAME%` で再生成された後、`C:\Users\%USERNAME%` へのユーザーシェルフォルダのリダイレクトを有効にする  | 
| NoReboot | DWORD |  **0** – (デフォルト) ユーザープロファイルのレジストリを変更した後、再起動するタイミングを制御することを許可する **1** – ユーザープロファイルのレジストリを変更した後、スクリプトが WorkSpace を再起動することを許可しない  | 


**レジストリパス: **HKLM:\$1Software\$1Amazon\$1WorkSpacesConfig\$1update-pvdrivers.ps1****  

| レジストリキー | タイプ | 値 | 
| --- | --- | --- | 
| 有効 | DWORD |  **0** – (デフォルト) AWS PV ドライバーの更新を無効にします **1** – PV AWS ドライバーの更新を有効にする  | 

## インプレースアップグレードの実行
<a name="upgrade_byol_procedure"></a>

BYOL WorkSpaces でインプレース Windows アップグレードを有効にするには、以下の手順で説明するように、特定のレジストリキーを設定する必要があります。また、特定のレジストリキーを設定して、インプレースアップグレードの完了後にユーザープロファイルを配置するドライブ (C または D) を指定する必要があります。

これらのレジストリの変更は手動で行うことができます。複数の WorkSpaces を更新する場合は、グループポリシーまたは SCCM を使用して PowerShell スクリプトをプッシュできます。サンプルの PowerShell スクリプトについては、[PowerShell スクリプトを使用して WorkSpace レジストリを更新する](#update-windows-10-byol-script) を参照してください。

**Windows 10 および 11 のインプレースアップグレードを実行するには**

1. 更新する Windows 10 および 11 の BYOL WorkSpaces で現在実行されている Windows のバージョンを確認し、システムを再起動します。

1. 以下の Windows システムレジストリキーを更新し、[**有効**] の値データを **0** から **1** に変更します。これらのレジストリ変更により、WorkSpace のインプレースアップグレードが有効になります。
   + **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1**
   + **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1update-pvdrivers.ps1**
**注記**  
これらのキーが存在しない場合は、WorkSpace を再起動します。システムを再起動すると、キーが追加されます。

   (オプション) SCCM Task Sequences などのマネージド型ワークフローを使用してアップグレードを実行する場合は、次のキー値を **1** に設定してコンピュータが再起動しないようにします。

   **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1\$1NoReboot**

1. インプレースアップグレードプロセス後にユーザープロファイルを配置するドライブを決定し (詳細については「[考慮事項](#upgrade_byol_important_considerations)」を参照)、以下のようにレジストリキーを設定します。
   + アップグレード後にドライブ C にユーザープロファイルが必要な場合の設定:

     **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1**

     キー名: **PostUpgradeRestoreProfileOnD**

     キー値: **0**

     キー名: **UserShellFoldersRedirection**

     キー値: **1**
   + アップグレード後にドライブ D にユーザープロファイルが必要な場合の設定:

     **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1**

     キー名: **PostUpgradeRestoreProfileOnD**

     キー値: **1**

     キー名: **UserShellFoldersRedirection**

     キー値: **0**

1. レジストリに変更を保存したら、再び WorkSpace を再起動して変更を適用します。
**注記**  
再起動後に WorkSpace にログインすると、新しいユーザープロファイルが作成されます。[**スタート**] メニューにプレースホルダーアイコンが表示される場合があります。この動作は、インプレースアップグレードが完了すると自動的に解決されます。
WorkSpace のブロックが解除されるまで約 10 分かかります。

   (オプション) 次のキー値が **1** に設定されていることを確認します。この設定で、WorkSpace がブロック解除され、更新可能になります。

   **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1\$1profileImagePathDeleted**

1. インプレースアップグレードを実行します。必要に応じて、SCCM、ISO、Windows Update (WU) のいずれの方法も使用できます。元の Windows 10 および 11 バージョンとインストール済みのアプリ数に応じて、このプロセスの所要時間は 40 〜 120 分です。
**注記**  
インプレースアップグレードプロセスには、最低 1 時間かかる可能性があります。WorkSpace インスタンスの状態は、アップグレード中に `UNHEALTHY` として表示されることがあります。

1. 更新プロセスが完了したら、Windows のバージョンが更新されていることを確認します。
**注記**  
インプレースアップグレードが失敗すると、Windows は自動的にロールバックし、アップグレードを開始する前に存在していた Windows 10 および 11 バージョンを使用します。トラブルシューティングの詳細については、[Microsoft の関連ドキュメント](https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolve-windows-10-upgrade-errors)を参照してください。

   (オプション) 更新スクリプトが正常に実行されたことを確認するには、次のキー値が **1** に設定されていることを確認します。

   **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1\$1scriptExecutionComplete**

1. AlwaysOn に設定するか、自動停止時間を変更することで WorkSpace の実行モードを変更し、インプレースアップグレードプロセスを中断することなく実行できるようにした場合は、実行モードを元の設定に戻します。詳細については、「[実行モードを変更する](running-mode.md#modify-running-mode)」を参照してください。

**PostUpgradeRestoreProfileOnD** レジストリキーを **1** に設定していない場合、ユーザープロファイルは Windows によって再生成され、インプレースアップグレード後に `C:\Users\%USERNAME%` に配置されるため、今後の Windows 10 および 11 のインプレースアップグレードで上記の手順を再度実行する必要はありません。デフォルトでは、`enable-inplace-upgrade.ps1` スクリプトは以下のシェルフォルダをドライブ D にリダイレクトします。
+ `D:\Users\%USERNAME%\Downloads`
+ `D:\Users\%USERNAME%\Desktop`
+ `D:\Users\%USERNAME%\Favorites`
+ `D:\Users\%USERNAME%\Music`
+ `D:\Users\%USERNAME%\Pictures`
+ `D:\Users\%USERNAME%\Videos`
+ `D:\Users\%USERNAME%\Documents`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Network Shortcuts`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Printer Shortcuts`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Recent`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\SendTo`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Templates`

シェルフォルダを WorkSpaces の他の場所にリダイレクトする場合は、インプレースアップグレード後に WorkSpaces で必要な操作を実行してください。

## トラブルシューティング
<a name="byol-troubleshooting"></a>

更新中に問題が発生した場合は、以下の項目をチェックしてトラブルシューティングに役立てます。
+ Windows ログ。デフォルトでは、以下の場所にあります。

  `C:\Program Files\Amazon\WorkSpacesConfig\Logs\`

  `C:\Program Files\Amazon\WorkSpacesConfig\Logs\TRANSMITTED`
+ Windows イベントビューア。

  Windows ログ > Application > Source: Amazon WorkSpaces

**ヒント**  
インプレースアップグレード中にデスクトップの一部のアイコンのショートカットが正常に動作しなくなった場合、アップグレードの準備のために WorkSpaces によってドライブ D のユーザープロファイルがドライブ C に移動されたことが原因です。アップグレードが完了すると、ショートカットは正常に動作します。

### ISO エラー解決を使用した Windows 11 24H2 のアップグレード
<a name="upgrade-iso-resolution"></a>

Windows 11 24H2 のアップグレードプロセスでは、2 番目の起動フェーズ中に重大な起動エラーが発生する可能性があります (具体的には、エラーコード 0xC1900101 - 0x40017 が表示されます)。通常このエラーは、ブートオペレーションフェーズ中に、システムドライバーファイルが存在しないか破損していることが原因でインストールを正常に完了できないために発生します。

*エラーコード:* 0xC1900101 - 0x40017

*エラーの説明:* SECOND\$1BOOT フェーズ中の BOOT オペレーションエラーによるインストール失敗

1. Windows 11 24H2 の ISO ファイルがあることを確認します。

1. 管理者としてコマンドプロンプトを開きます。

1. 次のコマンドを使用して、必要なシステムファイルをコピーします。

   ```
   copy "ISO-Drive:\Sources\WinSetupMon.sys" "C:\Windows\System32\Drivers\"
   ```

   **ISO-Drive** を ISO ドライブ情報に置き換えます。

1. 次を使用してファイルのコピーを検証します。

   ```
   C:\Windows\System32\Drivers\
   ```

1. ISO ファイルを使用して Windows 11 24H2 アップグレードを開始します。

## PowerShell スクリプトを使用して WorkSpace レジストリを更新する
<a name="update-windows-10-byol-script"></a>

次のサンプルの PowerShell スクリプトを使用して WorkSpaces のレジストリを更新し、インプレースアップグレードを有効にすることができます。[インプレースアップグレードの実行](#upgrade_byol_procedure) に従いますが、このスクリプトを使用して各 WorkSpace のレジストリを更新します。

```
# AWS WorkSpaces 1.28.20
# Enable In-Place Update Sample Scripts
# These registry keys and values will enable scripts to run on the next reboot of the WorkSpace.
 
$scriptlist = ("update-pvdrivers.ps1","enable-inplace-upgrade.ps1")
$wsConfigRegistryRoot="HKLM:\Software\Amazon\WorkSpacesConfig"
$Enabled = 1
$script:ErrorActionPreference = "Stop"
 
foreach ($scriptName in $scriptlist)
{
    $scriptRegKey = "$wsConfigRegistryRoot\$scriptName"
    
    try
    {
        if (-not(Test-Path $scriptRegKey))
        {        
            Write-Host "Registry key not found. Creating registry key '$scriptRegKey' with 'Update' enabled."
            New-Item -Path $wsConfigRegistryRoot -Name $scriptName | Out-Null
            New-ItemProperty -Path $scriptRegKey -Name Enabled -PropertyType DWord -Value $Enabled | Out-Null
            Write-Host "Value created. '$scriptRegKey' Enabled='$((Get-ItemProperty -Path $scriptRegKey).Enabled)'"
        }
        else
        {
            Write-Host "Registry key is already present with value '$scriptRegKey' Enabled='$((Get-ItemProperty -Path $scriptRegKey).Enabled)'"
            if((Get-ItemProperty -Path $scriptRegKey).Enabled -ne $Enabled)
            {
                Set-ItemProperty -Path $scriptRegKey -Name Enabled -Value $Enabled
                Write-Host "Value updated. '$scriptRegKey' Enabled='$((Get-ItemProperty -Path $scriptRegKey).Enabled)'"
            }
        }
    }
    catch
    {
        write-host "Stopping script, the following error was encountered:" `r`n$_ -ForegroundColor Red
        break
    }
}
```

# WorkSpaces Personal で WorkSpace を移行する
<a name="migrate-workspaces"></a>

**注記**  
 AWS を通じてWorkSpace から Microsoft Office バージョンのライセンスをサブスクリプション解除またはアンインストールする場合は、[[アプリケーションの管理](manage-applications)] を使用することをお勧めします。

ユーザーボリューム上のデータを保持しながら、1 つのバンドルから別のバンドルに WorkSpace を移行できます。サンプルシナリオを以下に示します。
+ Windows 7 デスクトップエクスペリエンスから Windows 10 デスクトップエクスペリエンスに WorkSpaces を移行できます。
+ WorkSpaces を PCoIP プロトコルから DCV に移行できます。
+ Windows Server 2016 搭載の WorkSpaces に 32 ビットの Microsoft Office が付属したバンドルから、Windows Server 2019 および Windows Server 2022 搭載の WorkSpaces に 64 ビットの Microsoft Office が付属したバンドルに、WorkSpaces を移行できます。
+ また、あるパブリックバンドルまたはカスタムバンドルから別のバンドルに WorkSpaces を移行することもできます。たとえば、GPU 対応 (Graphics.g6、Graphics.g4dn。 GraphicsPro.g4dn,Graphics、GraphicsPro) バンドルを non-GPU-enabledバンドルにバンドルします。
+ WorkSpaces を Windows 10 BYOL から Windows 11 BYOL に移行することはできますが、Windows 11 から Windows 10 への移行はサポートされていません。
+ バリューバンドルは Windows 11 ではサポートされていません。Windows 7 または 10 のバリューバンドル WorkSpaces を Windows 11 に移行するには、まずバリュー WorkSpaces をより大きなバンドルサービスに切り替える必要があります。
+ WorkSpaces を Windows 7 から Windows 11 に移行する前に、Windows 10 に移行する必要があります。Windows 11 に移行する前に、Windows 10 WorkSpace に少なくとも 1 回ログインしてください。Windows 7 WorkSpaces から Windows 11 への直接の移行はサポートされていません。
+ を通じて Microsoft Office を使用する Windows WorkSpaces AWS を、Microsoft 365 アプリケーションを使用するカスタム WorkSpaces バンドルに移行できます。移行後、WorkSpaces は Microsoft Office からサブスクリプション解除されます。
+ Microsoft Office を使用する Windows WorkSpaces AWS を、Office 2016/2019 サブスクリプションなしで WorkSpaces バンドルに移行できます。移行後、WorkSpaces は Microsoft Office からサブスクリプション解除されます。
+ BYOL BYOP WorkSpaces を Windows 10 から Windows 11 に移行し、ライセンス込みの BYOP WorkSpaces を Windows Server 2019 から Windows Server 2022 に移行できます。
+ Windows Server を搭載した WorkSpace バンドルは、Windows Server 2025 に移行できます。移行後、DCV ストリーミングプロトコルを使用して、グラフィックを多用するアプリケーションでも、さまざまなネットワーク条件でも、より強力なクライアントデバイスでも、高性能のリモートデスクトップストリーミングを有効にします。
+ Windows Server ライセンスに含まれている BYOP WorkSpace バンドルを BYOP Windows Server 2025 に移行できます。

Amazon WorkSpaces バンドルの詳細については、[WorkSpaces Personal のバンドルとイメージ](amazon-workspaces-bundles.md) を参照してください。

移行プロセスでは、ターゲットバンドルイメージからの新しいルートボリュームと、元の WorkSpace の最後に利用可能なスナップショットからのユーザーボリュームを使用して WorkSpace を再作成します。移行中に新しいユーザープロファイルが生成され、互換性が向上します。古いユーザープロファイルの名前が変更され、古いユーザープロファイル内の特定のファイルが新しいユーザープロファイルに移動されます (移動対象の詳細については、[移行中の動作](#during-migration) を参照してください。)

移行プロセスには、WorkSpace ごとに最大 1 時間かかります。移行プロセスを開始すると、新しい WorkSpace が作成されます。移行の成功を妨げるエラーが発生した場合、元の WorkSpace が復旧されて元の状態に戻り、新しい WorkSpace が終了します。

**Contents**
+ [移行の制限](#migration-limits)
+ [移行シナリオ](#migration-scenarios)
+ [移行中の動作](#during-migration)
+ [ベストプラクティス](#migration-best-practices)
+ [トラブルシューティング](#migration_troubleshooting)
+ [請求への影響](#migration-billing)
+ [WorkSpace の移行](#migration-workspaces)

## 移行の制限
<a name="migration-limits"></a>
+ パブリックまたはカスタムの Windows 7 デスクトップエクスペリエンスバンドルに移行することはできません。また、Bring-Your-Own-License (BYOL) Windows 7 バンドルに移行することもできません。
+ BYOL WorkSpaces は、他の BYOL バンドルにのみ移行できます。BYOL WorkSpace を PCoIP から DCV に移行するには、最初に DCV プロトコルを使用して BYOL バンドルを作成する必要があります。その後、PCoIP BYOL WorkSpaces をその DCV BYOL バンドルに移行できます。
+ パブリックバンドルまたはカスタムバンドルから作成された WorkSpace を BYOL バンドルに移行することはできません。
+ DCV プロトコルは、Windows で Graphics G6 バンドル、Graphics.g4dn、GraphicsPro.g4dn をサポートしています。Ubuntu では、Graphics.g4dn と GraphicsPro.g4dn のみを使用できます。
+ PCoIP プロトコルは、Windows でのみ Graphics.g4dn および GraphicsPro.g4dn バンドルをサポートしています。
+ Linux WorkSpaces の移行は現在サポートされていません。
+ 複数の言語をサポートする AWS リージョンでは、言語バンドル間で WorkSpaces を移行できます。
+ ソースバンドルとターゲットバンドルは異なっている必要があります (ただし、複数の言語をサポートするリージョンでは、言語が異なる限り、同じ Windows 10 バンドルに移行できます)。同じバンドルを使用して WorkSpace を更新する場合は、代わりに [WorkSpace を再構築します](rebuild-workspace.md)。
+ リージョン間で WorkSpaces を移行することはできません。
+ 場合によっては、移行が正常に完了しない場合、エラーメッセージが表示されず、移行プロセスが開始されなかったように見えることがあります。移行の試行後 1 時間経過しても WorkSpace バンドルが同じである場合、移行は失敗します。[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にアクセスしてサポートをお求めください。
+ BYOP WorkSpaces を PCoIP または DCV WorkSpaces に移行することはできません。
+ Active Directory ドメインに参加している WorkSpaces を Microsoft Entra に参加している WorkSpaces に移行することはできません。

## 移行シナリオ
<a name="migration-scenarios"></a>

次の表に、可能な移行シナリオを示します。


| 移行元 OS | 移行先 OS | 使用可能 | 
| --- | --- | --- | 
|  パブリックまたはカスタムバンドル Windows 7  |  パブリックまたはカスタムバンドル Windows 10  |  はい  | 
|  カスタムバンドル Windows 7  |  パブリックバンドル Windows 7  |  いいえ  | 
|  カスタムバンドル Windows 7  |  カスタムバンドル Windows 7  |  いいえ  | 
|  パブリックバンドル Windows 7  |  カスタムバンドル Windows 7  |  いいえ  | 
|  パブリックまたはカスタムバンドル Windows 10  |  パブリックまたはカスタムバンドル Windows 7  |  いいえ  | 
|  パブリックまたはカスタムバンドル Windows 10  |  カスタムバンドル Windows 10  |  はい  | 
|  Windows 7 の BYOL バンドル  |  Windows 7 の BYOL バンドル  | いいえ | 
| Windows 7 の BYOL バンドル |  Windows 10 の BYOL バンドル  |  はい  | 
|  Windows 10 の BYOL バンドル  |  Windows 7 の BYOL バンドル  |  いいえ  | 
|  Windows 10 の BYOL バンドル  |  Windows 10 の BYOL バンドル  |  はい  | 
|  Windows Server 2016 搭載のパブリック Windows 10 バンドル  |  Windows Server 2019 搭載のパブリック Windows 10 バンドル  |  はい  | 
|  Windows Server 2019 搭載のパブリック Windows 10 バンドル  |  Windows Server 2016 搭載のパブリック Windows 10 バンドル  |  はい  | 
|  Windows 10 の BYOL バンドル  |  Windows 11 の BYOL バンドル  |  はい  | 
|  Windows 11 の BYOL バンドル  |  Windows 10 の BYOL バンドル  |  いいえ  | 
|  Windows Server 2016 搭載のカスタム Windows 10 バンドル  |  Windows Server 2019 搭載のパブリック Windows 10 バンドル  |  はい  | 
|  Windows Server 2016 搭載のカスタム Windows 10 バンドル  |  Windows Server 2022 搭載のパブリック Windows 10 バンドル  |  はい  | 
|  Windows Server 2019 搭載のカスタム Windows 10 バンドル  |  Windows Server 2022 搭載のパブリック Windows 10 バンドル  |  はい  | 
| Windows 10 BYOP BYOL | Windows 11 BYOP BYOL | はい | 
| Windows 11 BYOP BYOL | Windows 10 BYOP BYOL | いいえ | 
| Windows Server 2019 搭載のパブリック BYOP  | Windows Server 2022 搭載のパブリック BYOP  | はい | 
| Windows Server 2022 搭載のパブリック BYOP  | Windows Server 2019 搭載のパブリック BYOP  | いいえ | 
| Windows Server 2019 搭載のパブリック BYOP  | Windows Server 2025 搭載のパブリック BYOP  | はい | 
| Windows Server 2025 搭載のパブリック BYOP  | Windows Server 2019 搭載のパブリック BYOP  | いいえ | 
| Windows Server 2022 搭載のパブリック BYOP  | Windows Server 2025 搭載のパブリック BYOP  | はい | 
| Windows Server 2025 搭載のパブリック BYOP  | Windows Server 2022 搭載のパブリック BYOP  | いいえ | 
| Windows Server 2019 搭載のパブリック Windows 10 バンドル  | Windows Server 2025 搭載のパブリック BYOP  | はい | 
| Windows Server 2019 搭載のカスタム Windows 10 バンドル  | Windows Server 2025 搭載のパブリック BYOP  | はい | 
| Windows Server 2022 搭載のパブリック Windows 10 バンドル  | Windows Server 2025 搭載のパブリック BYOP  | はい | 
| Windows Server 2022 搭載のカスタム Windows 10 バンドル  | Windows Server 2025 搭載のパブリック BYOP  | はい | 

**注記**  
Windows Server 2019 搭載のパブリック Windows 10 バンドル PCoIP ブランチでは、Web Access は使用できません。

## 移行中の動作
<a name="during-migration"></a>

移行中は、ユーザーボリューム (ドライブ D) 上のデータは保持されますが、ルートボリューム (ドライブ C) 上のすべてのデータは失われます。つまり、インストールされているアプリケーション、設定、およびレジストリの変更は、いずれも保持されません。古いユーザープロファイルフォルダの名前が `.NotMigrated` サフィックスで変更され、新しいユーザープロファイルが作成されます。

移行プロセスでは、元のユーザーボリュームの最後のスナップショットに基づいてドライブ D が再作成されます。新しい WorkSpace の初回起動時に、移行プロセスで元の `D:\Users\%USERNAME%` フォルダが `D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated` という名前のフォルダに移動されます。新しい OS によって新しい `D:\Users\%USERNAME%\` フォルダが生成されます。

新しいユーザープロファイルが作成されると、次のユーザーシェルフォルダ内のファイルが古い `.NotMigrated` プロファイルから新しいプロファイルに移動します。
+ `D:\Users\%USERNAME%\Desktop`
+ `D:\Users\%USERNAME%\Documents`
+ `D:\Users\%USERNAME%\Downloads`
+ `D:\Users\%USERNAME%\Favorites`
+ `D:\Users\%USERNAME%\Music`
+ `D:\Users\%USERNAME%\Pictures`
+ `D:\Users\%USERNAME%\Videos`

**重要**  
移行プロセスでは、古いユーザープロファイルから新しいプロファイルへのファイルの移動が試みられます。移行中に移動されなかったファイルは、`D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated` フォルダ内に残ります。移行が成功すると、どのファイルが移動されたかを `C:\Program Files\Amazon\WorkspacesConfig\Logs\MigrationLogs` で確認できます。自動的に移動されなかったファイルは、手動で移動できます。  
デフォルトでは、パブリックバンドルではローカル検索インデックス作成が無効になっています。有効にすると、デフォルトでは `C:\Users` ではなく `D:\Users` を検索する設定となるため、それも調整する必要があります。ローカル検索インデックス作成を `D:\Users\username` に設定し、`D:\Users` に設定していない場合、`D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated` フォルダ内のユーザーファイルの移行後にローカル検索インデックス作成が機能しないことがあります。

元の WorkSpace に割り当てられたタグは移行中に引き継がれ、WorkSpace の実行モードは保持されます。ただし、新しい WorkSpace は、新しい WorkSpace ID、コンピュータ名、および IP アドレスを取得します。

## ベストプラクティス
<a name="migration-best-practices"></a>

WorkSpace を移行する前に、次の操作を行います。
+ ドライブ C の重要なデータを別の場所にバックアップします。ドライブ C 上のすべてのデータは、移行中に消去されます。
+ ユーザーボリュームのスナップショットが作成されたことを確認するために、移行中の WorkSpace の経過時間が 12 時間以上であることを確認します。Amazon WorkSpaces コンソールの [**Migrate WorkSpaces**] (WorkSpace の移行) ページで、最後のスナップショットの時刻を確認できます。最後のスナップショット以降に作成されたデータは、移行中に失われます。
+ データの損失を避けるために、ユーザーがWorkSpaces からログアウトし、移行プロセスが完了するまでログインし直さないようにしてください。WorkSpaces が `ADMIN_MAINTENANCE` モードになっている場合は移行できないことに注意してください。
+ 移行する WorkSpaces のステータスが、`AVAILABLE`、`STOPPED`、または `ERROR` であることを確認します。
+ 移行する WorkSpaces に十分な IP アドレスがあることを確認します。移行中に、新しい IP アドレスが WorkSpaces に割り当てられます。
+ スクリプトを使用して WorkSpaces を移行する場合、一度に移行できる WorkSpace のバッチの最大数は 25 です。

## トラブルシューティング
<a name="migration_troubleshooting"></a>
+ 移行後にファイルが見つからないことについてユーザーから報告があった場合は、移行プロセス中にユーザープロファイルファイルが移動されなかったかどうかを確認します。どのファイルが移動されたかは、`C:\Program Files\Amazon\WorkspacesConfig\Logs\MigrationLogs` で確認できます。移動されなかったファイルは、`D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated` フォルダに配置されます。自動的に移動されなかったファイルは、手動で移動できます。
+ API を使用して WorkSpaces を移行し、移行が成功しなかった場合、API によって返されたターゲット WorkSpace ID は使用されず、WorkSpace で元の WorkSpace ID が保持されます。
+ 移行が正常に完了しない場合は、Active Directory で、適切にクリーンアップされたかどうかを確認します。不要になった WorkSpaces は、手動による削除が必要になる場合があります。

## 請求への影響
<a name="migration-billing"></a>

移行が発生する月に、新しい WorkSpaces と元の WorkSpaces の両方に比例配分された金額が請求されます。たとえば、5 月 10 日に WorkSpace A を WorkSpace B に移行すると、5 月 1 日から 5 月 10 日まで WorkSpace A の料金が請求され、5 月 11 日から 5 月 30 日まで WorkSpace B の料金が請求されます。

**注記**  
WorkSpace を別のバンドルタイプに移行する場合 (例えば、Performance から Power へ、または Value から Standard へ)、移行プロセス中にルートボリューム (ドライブ C) とユーザーボリューム (ドライブ D) のサイズが増加する可能性があります。必要に応じて、ルートボリュームは、新しいバンドルのデフォルトのルートボリュームサイズに合わせて増加します。ただし、ユーザーボリュームに対して、元のバンドルのデフォルトとは異なるサイズ (高いサイズまたは低いサイズ) をすでに指定していた場合、移行プロセス中も同じユーザーボリュームサイズが保持されます。それ以外の場合、移行元の WorkSpace ユーザーボリュームサイズとデフォルトのユーザーボリュームサイズのうち、大きい方が使用されます。

## WorkSpace の移行
<a name="migration-workspaces"></a>

WorkSpaces は、Amazon WorkSpaces コンソール、、 AWS CLI または Amazon WorkSpaces API を使用して移行できます。

**WorkSpace を移行するには**

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. WorkSpace を選択したら、[**アクション**]、[**Migrate WorkSpaces (WorkSpace の移行)**] の順に選択します。

1. **[Bundle]** (バンドル) で、WorkSpace の移行先のバンドルを選択します。
**注記**  
BYOL WorkSpace を PCoIP から DCV に移行するには、最初に DCV プロトコルを使用して BYOL バンドルを作成する必要があります。その後、PCoIP BYOL WorkSpaces をその DCV BYOL バンドルに移行できます。

1. [**Migrate WorkSpaces (WorkSpace の移行)**] を選択します。

   Amazon WorkSpaces コンソールに、ステータスが `PENDING` の新しい WorkSpace が表示されます。移行が完了すると、元の WorkSpace が終了し、新しい WorkSpace のステータスが `AVAILABLE` に設定されます。

1. (オプション) 不要になったカスタムバンドルとイメージを削除する方法については、[WorkSpaces Personal でカスタムバンドルまたはイメージを削除する](delete_bundle.md) を参照してください。

を通じて WorkSpaces を移行するには AWS CLI、[migrate-workspace](https://docs.aws.amazon.com/cli/latest/reference/workspaces/migrate-workspace.html) コマンドを使用します。Amazon WorkSpaces API を使用して WorkSpaces を移行するには、*Amazon WorkSpaces API リファレンス*の [MigrateWorkSpace](https://docs.aws.amazon.com/workspaces/latest/api/API_MigrateWorkspace.html) を参照してください。

# WorkSpaces Personal で WorkSpace を削除する
<a name="delete-workspaces"></a>

不要になった WorkSpace は、削除することができます。関連リソースも削除できます。

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

**注記**  
Simple AD および AD Connector は、WorkSpaces で無料で利用できます。Simple AD または AD Connector ディレクトリで 30 日間連続使用されている WorkSpaces がない場合、そのディレクトリは Amazon WorkSpaces での使用から自動的に登録解除され、 [AWS Directory Service 料金の条件](https://aws.amazon.com/directoryservice/pricing/)に従って課金されるようになります。  
空のディレクトリを削除するには、[WorkSpaces Personal でディレクトリを削除する](delete-workspaces-directory.md) を参照してください。Simple AD または AD Connector ディレクトリを削除した場合、WorkSpaces を再度ご使用になる際は、いつでも Simple AD または AD Connector を新たに作成できます。

**WorkSpace を削除するには**

状態が **[Suspended]** (一時停止) 以外の WorkSpace は削除できます。

1. [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home) で WorkSpaces コンソールを開きます。

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

1. WorkSpace を選択し、**[Delete]** (削除) を選択します。

1. 確認を求めるメッセージが表示されたら、**[Delete WorkSpace]** (WorkSpace の削除) を選択します。WorkSpace が削除されるまで約 5 分かかります。削除中、WorkSpace の状態は **[Terminating]** (終了中) に設定されます。削除が完了すると、コンソールから WorkSpace が消えます。

1. （オプション）不要になったカスタムバンドルとイメージを削除するには、「[WorkSpaces Personal でカスタムバンドルまたはイメージを削除する](delete_bundle.md)」を参照してください。

1. （オプション）ディレクトリのすべての WorkSpaces を削除した後で、ディレクトリを削除することができます。詳細については、「[WorkSpaces Personal でディレクトリを削除する](delete-workspaces-directory.md)」を参照してください。

1. (オプション) ディレクトリの Virtual Private Cloud (VPC) のすべてのリソースを削除した後で、VPC を削除し、NAT ゲートウェイで使用されている Elastic IP アドレスを解放できます。詳細については、*Amazon VPC ユーザーガイド*の [VPC の削除](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting)および [Elastic IP アドレスの使用](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html#WorkWithEIPs)を参照してください。

**を使用して WorkSpace を削除するにはAWS CLI**  
[terminate-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/terminate-workspaces.html) コマンドを使用します。