

# EC2 Windows インスタンスのより新しいバージョンの Windows Server へのアップグレード
<a name="serverupgrade"></a>

EC2 Windows インスタンスの Windows Server オペレーティングシステムを旧バージョンからアップグレードする場合は次のいずれかの方法を使用できます。

**インプレースアップグレード**  
インプレースアップグレードは既存インスタンスで動作します。このプロセス中にオペレーティングシステムファイルのみが影響を受ける一方、設定、サーバーロール、データはそのまま残ります。

**移行 (並行アップグレードとも呼ばれます)**  
移行では設定、構成、データを取り込み、この情報を新しい EC2 Windows インスタンス上のより新しいバージョンのオペレーティングシステムに移行します。インスタンスはAWS Marketplace からサブスクライブしているパブリックまたはプライベートの Windows AMI、または共有されている AMI から起動できます。EC2 Image Builder を使用してカスタム AMI を作成することもできます。詳細については「[Image Builder ユーザーガイド](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)」を参照してください。  
AWS はEC2 インスタンスで実行される Windows Server バージョンに対して一連の一般利用可能な Amazon マシンイメージ (AMI) を提供します。これらの AMI は毎月更新されています。最新の Windows AMI の詳細については「[AWS Windows AMI リファレンス](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/windows-amis.html)」を参照してください。

Microsoft では従来、インプレースアップグレードする代わりに、より新しいバージョンの Windows Server に移行することを推奨しています。移行はアップグレードのエラーや問題がより少ない反面、新しいインスタンスのプロビジョニング、アプリケーションの計画と実施、新しいインスタンスでの環境設定の調整が必要であるため、インプレースアップグレードより時間がかかる場合があります。インプレースアップグレードはより高速である反面、ソフトウェアの非互換性に伴うエラーが生じる場合があります。

**Topics**
+ [EC2 Windows インスタンスでのインプレースアップグレードの実行](os-inplaceupgrade.md)
+ [Automation ランブックを使用した EC2 Windows インスタンスのアップグレード](automated-upgrades.md)
+ [EC2 Windows インスタンスを Nitro ベースのインスタンスタイプに移行する](migrating-latest-types.md)
+ [EC2 Windows インスタンスのオペレーティングシステムアップグレードに関するトラブルシューティング](os-upgrade-trbl.md)

# EC2 Windows インスタンスでのインプレースアップグレードの実行
<a name="os-inplaceupgrade"></a>

インプレースアップグレードを実行する前に、どのネットワークドライバをインスタンスで実行しているかを確認する必要があります。PV ネットワークドライバを使用すると、リモートデスクトップを使用してインスタンスにアクセスできます。インスタンスは AWS PV、Intel Network Adapter、あるいは拡張ネットワーキングドライバーのいずれかを使用します。詳細については「[Windows インスタンス用 Paravirtual ドライバー](xen-drivers-overview.md)」を参照してください。

## インプレースアップグレードを開始する前に
<a name="os-upgrade-before"></a>

インプレースアップグレードを始める前に、以下のタスクを完了し、以下の重要な詳細情報を確認してください。
+ Microsoft のドキュメントを参照し、アップグレードの要件、既知の問題、制限事項を把握します。また、アップグレードに関する公式の手順も確認します。
  + [Windows Server 2012 のアップグレードオプション](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj574204(v=ws.11))
  + [Windows Server 2012 R2 のアップグレードオプション](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn303416(v=ws.11))
  + [Windows Server 2016 以降のアップグレードおよび変換のオプション](https://learn.microsoft.com/en-us/windows-server/get-started/install-upgrade-migrate)
  + [Windows Server をアップグレードする](https://learn.microsoft.com/en-us/windows-server/get-started/upgrade-overview)
+ 少なくとも 2 つの vCPU と 4GB の RAM を持つインスタンスでオペレーティングシステムのアップグレードを実行することをお勧めします。必要に応じて、インスタンスを同じタイプのより大きなサイズ (例えば t2.small から t2.large) に変更し、アップグレードを実行してから元のサイズにサイズ変更することができます。インスタンスサイズを保持する必要がある場合は[インスタンスコンソールのスクリーンショット](troubleshoot-unreachable-instance.md#instance-console-screenshot)を使用して進行状況を監視できます。詳細については[Amazon EC2 インスタンスタイプの変更](ec2-instance-resize.md)を参照してください。
+ Windows インスタンス上のルートボリュームに十分な空きディスク容量があることを確認します。Windows セットアッププロセスによってディスク容量の不足が警告されないことがあります。特定のオペレーティングシステムのアップグレードに必要なディスク容量の詳細についてはMicrosoft のマニュアルを参照してください。ボリュームに十分な空きディスク容量がない場合はその容量を拡張できます。詳細については[ Amazon EBS ユーザーガイド](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html)」の「*Amazon EBS Elastic Volumes*」を参照してください。
+ アップグレードパスを決定します。オペレーティングシステムは同じアーキテクチャにアップグレードする必要があります。例えば、32 ビットシステムは 32 ビットシステムにアップグレードする必要があります。Windows Server 2008 R2 以降は 64 ビットシステムのみです。
+ アンチウイルスとアンチスパイウェアのソフトウェアとファイアウォールを無効にします。このようなタイプのソフトウェアはアップグレードプロセスと競合する場合があります。アップグレードが完了したら、アンチウイルスとアンチスパイウェアのソフトウェア、およびファイアウォールを再度有効にします。
+ [EC2 Windows インスタンスを Nitro ベースのインスタンスタイプに移行する](migrating-latest-types.md)トピックで説明した最新のドライバーに更新します。
+ Upgrade Helper Service ではCitrix PV ドライバーを実行しているインスタンスのみがサポートされています。インスタンスが Red Hat ドライバーを実行している場合は最初に手動で[これらのドライバーをアップグレード](Upgrading_PV_drivers.md)する必要があります。

## AWSPV、Intel Network Adapter、または拡張ネットワーキングドライバーを使用したインスタンスをインプレースアップグレードする
<a name="os-upgrade-pv"></a>

次の手順に従って、AWS PV、Intel Network Adapter、または拡張ネットワーキングドライバーを使用して Windows Server インスタンスをアップグレードします。

**インプレースアップグレードを実行するには**

1. アップグレード予定のシステムの AMI をバックアップまたはテスト用に作成します。その後、テスト環境として用意したこのコピーでアップグレードを実行できます。アップグレードが完了した場合はこのインスタンスにトラフィックをほとんどダウンタイムなしで切り替えることができます。アップグレードが失敗した場合はバックアップに戻すことができます。詳細については「[Amazon EBS-backed AMI を作成する](creating-an-ami-ebs.md)」を参照してください。

1. Windows Server インスタンスが最新のネットワークドライバを使用していることを確認します。

   1. AWS PV ドライバーを更新するには「[EC2 Windows インスタンスでの PV ドライバーのアップグレード](Upgrading_PV_drivers.md)」を参照してください。

   1. ENA ドライバーを更新するには「[EC2 Windows インスタンスに ENA ドライバーをインストールする](ena-adapter-driver-install-upgrade-win.md)」を参照してください。

   1. Intel ドライバーを更新するには「[Intel 82599 VF インターフェイスを使用する拡張ネットワーキング](sriov-networking.md)」を参照してください。

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションペインで、[**インスタンス**] を選択してください。インスタンスを見つけます。そのインスタンスの [インスタンス ID] および [アベイラビリティーゾーン] をメモしておきます。この情報はこの手順で後ほど使用します。

1. Windows Server 2012 または 2012 R2 から Windows Server 2016 以降にアップグレードする場合、手順を進める前にインスタンスで次の操作を実行します。

   1. EC2Config サービスをアンインストールします。詳細については「[EC2Launch v2 および EC2Config エージェントの Windows サービス管理](launch-agents-service-admin.md)」を参照してください。

   1. EC2Launch v1 または EC2Launch v2 エージェントをインストールします。詳細については「[EC2 Windows インスタンスの起動時に EC2Launch v1 エージェントを使用してタスクを実行する](ec2launch.md)」および「[EC2 Windows インスタンスの起動時に EC2Launch v2 エージェントを使用してタスクを実行する](ec2launch-v2.md)」を参照してください。

   1. AWS Systems Manager SSM Agent をインストールします。詳細については、「*AWS Systems Manager ユーザーガイド*」の「[Manually install SSM Agent on Amazon EC2 for Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)」を参照してください。

1. Windows Server インストールメディアスナップショットから新しいボリュームを作成します。

   1. 左サイドバーのナビゲーションペインで [**Elastic Block Store**] の [**スナップショット**] を選択してください。

   1. フィルターバーで、**[パブリックスナップショット]** を選択してください。

   1. 検索バーで、次のフィルターを指定します。
      + **[所有者のエイリアス]**、**[=]**、**[amazon]** の順に選択してください。
      + **[説明]** を選択し、**Windows** の入力を開始します。アップグレード先のシステムアーキテクチャと言語設定に一致する Windows フィルターを選択してください。例えば、Windows Server 2019 にアップグレードする場合には**[Windows 2019 English Installation Media]** を選びます。

   1. アップグレード先のシステムアーキテクチャおよび言語設定と一致するスナップショットの横にあるチェックボックスをオンにし、**[アクション]** および **[スナップショットからボリュームを作成]** を選択してください。

   1. **[ボリュームの作成]** ダイアログボックスで、Windows インスタンスと同一のアベイラビリティーゾーンを選択し、**[ボリュームの作成]** を選択してください。

1. ページ上部の **[ボリューム vol-*1234567890example* が正常に作成されました]** バナーで、作成したボリュームの ID を選択してください。

1. **[Actions]** (アクション)、**[Attach volume]** (ボリュームのアタッチ) の順に選択してください。

1. **[ボリュームのアタッチ]** ページの**[インスタンス]**で、Windows インスタンスのインスタンス ID を選択し、**[ボリュームのアタッチ]** を選択してください。

1. 「[Amazon EBS ボリュームを使用できるようにする](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html)」のステップに従い、新しいボリュームを使用可能にします。
**重要**  
ディスクを初期化すると既存のデータが削除されるため、初期化は実行しないでください。

1. Windows PowerShell で、新しいボリュームドライブに切り替えます。インスタンスにアタッチしたインストールメディアボリュームを開き、アップグレードを開始します。

   1. Windows Server 2016 以降にアップグレードする場合は以下を実行します。

      ```
      .\setup.exe /auto upgrade /dynamicupdate disable
      ```
**注記**  
setup.exe を `/dynamicupdate` オプションを無効に設定して実行すると、Windows は Windows Server のアップグレードプロセス中に更新プログラムをインストールできなくなります。これはアップグレード中に更新プログラムをインストールするとエラーが発生する可能性があるためです。アップグレードの完了後に、Windows Update で更新プログラムをインストールできます。

      Windows Server の旧バージョンにアップグレードする場合は以下を実行します。

      ```
      Sources\setup.exe
      ```

   1. **[インストールするオペレーティングシステムを選択]** ページで、Windows Server インスタンスの完全インストール版を選択し、**[次へ]** を選択します。

   1. [**Which type of installation do you want?** (どのタイプのインストールが必要ですか。)] で、[**アップグレード**] を選択してください。

   1. ウィザードを終了します。

Windows Server セットアップはファイルをコピーして処理します。数分後、リモートデスクトップセッションが終了します。アップグレードにかかる時間はアプリケーションの数と Windows Server インスタンスで実行されているサーバーロールによって異なります。短くて 40 分、長くて数時間かかることがあります。インスタンスはアップグレードプロセス中に 1 つ以上のステータスチェックに失敗する可能性があります。アップグレードが完了すると、すべてのステータスチェックが成功します。コンソール出力のシステムログを確認するか、Amazon CloudWatch メトリクスでディスクと CPU の動作を確認して、アップグレードが進行しているかどうかを確認できます。

**注記**  
Windows Server 2019 にアップグレードする場合、アップグレードが完了した後で、必要に応じて、デスクトップの背景を手動で変更して、以前のオペレーティングシステム名を削除できます。

インスタンスが数時間後にすべてのステータスチェックに成功しなかった場合、「[EC2 Windows インスタンスのオペレーティングシステムアップグレードに関するトラブルシューティング](os-upgrade-trbl.md)」を参照してください。

## アップグレード後のタスク
<a name="os-post"></a>

1. インスタンスにログインし、.NET Framework のアップグレードを開始します。システムを再起動するように求められたら、その指示に従います。

1. 前のステップで実行しなかった場合はEC2Launch v1 または EC2Launch v2 エージェントをインストールします。詳細については[EC2 Windows インスタンスの起動時に EC2Launch v1 エージェントを使用してタスクを実行する](ec2launch.md) および [EC2 Windows インスタンスの起動時に EC2Launch v2 エージェントを使用してタスクを実行する](ec2launch-v2.md) を参照してください。

1. Windows Server 2012 R2 にアップグレードした場合、PV ドライバーを AWS PV ドライバーにアップグレードすることをお勧めします。Nitro ベースのインスタンスでアップグレードした場合、NVME および ENA ドライバーをインストールまたはアップグレードすることをお勧めします。詳細については「[AWS NVMe ドライバー](aws-nvme-drivers.md)」または「[Windows の拡張ネットワーキングの有効化](enabling_enhanced_networking.md#enable-enhanced-networking-ena-windows)」を参照してください。

1. アンチウイルスとアンチスパイウェアのソフトウェアとファイアウォールを再度有効にします。

# Automation ランブックを使用した EC2 Windows インスタンスのアップグレード
<a name="automated-upgrades"></a>

AWS Systems Manager オートメーションランブックを使用して、AWS で Windows および SQL Server インスタンスの自動アップグレードを実行することができます。

**Topics**
+ [関連サービス](#automated-related)
+ [実行オプション](#automated-execution-option)
+ [Windows Server をアップグレードする](#automated-upgrades-windows)
+ [SQL Server のアップグレード](#automated-upgrades-sql)

## 関連サービス
<a name="automated-related"></a>

自動アップグレードプロセスでは次の AWS サービスを使用します。
+ **AWS Systems Manager**。AWS Systems Manager はAWS リソースを集中管理する強力な統合インターフェイスです。詳細については*[AWS Systems Manager ユーザーガイド](https://docs.aws.amazon.com/systems-manager/latest/userguide/)*を参照してください。
+ AWS Systems Manager エージェント (SSM Agent) はAmazon EC2 インスタンス、オンプレミスのサーバー、または仮想マシン (VM) にインストールして設定できる Amazon のソフトウェアです。SSM Agent により、Systems Manager がこれらのリソースを更新、管理、および設定できるようにします。このエージェントは AWS クラウド上の Systems Manager サービスからのリクエストを処理し、リクエストに指定されたとおりにそれらを実行します。詳細については*AWS Systems Manager ユーザーガイド*の[SSM Agent を使用する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)を参照してください。
+ **AWS Systems Manager SSM ランブック**。SSM ランブックはマネージドインスタンスで Systems Manager が実行するアクションを定義します。SSM ランブックは JavaScript Object Notation (JSON) や YAML を使用し、これにはユーザーが指定するステップおよびパラメータが含まれます。このトピックでは2 つのオートメーション用 Systems Manager SSM ランブックを使用します。詳細については「AWS Systems Manager ユーザーガイド」の「[AWS Systems Manager オートメーションランブックリファレンス](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html)」を参照してください。**

## 実行オプション
<a name="automated-execution-option"></a>

Systems Manager コンソールで [**Automation**] を選択する際、[**実行**] を選択してください。Automation ドキュメントを選択すると、自動化の実行オプションを選択するよう求められます。以下のオプションから選択してください。このトピックで後ほど示すパスのステップでは[**シンプルな実行**] オプションを使用します。

**シンプルな実行**  
1 つのインスタンスを更新するが、自動化の各ステップを実行して結果を監査しない場合はこのオプションを選択してください。このオプションについては以降のアップグレード手順で詳しく説明します。

**レート制御**

アップグレードを複数のインスタンスに適用する場合はこのオプションを選択してください。以下の設定を定義します。
+ **パラメータ**

  [マルチアカウント] および [リージョン] でも設定されているこの設定では自動化の分岐方法を定義します。
+ **[Targets]** (ターゲット)

  自動化を適用するターゲットを選択してください。この設定は[マルチアカウント] および [リージョン] でも設定されます。
+ **パラメータ値**

  オートメーションドキュメントのパラメータで定義されている値を使用します。
+ **Resource Group** (リソースグループ)

  AWS ではリソースはユーザーが操作できるエンティティです。例えば、Amazon EC2 インスタンス、AWS CloudFormation スタック、または Amazon S3 バケットなどがあります。複数のリソースを使用する場合はタスクごとに 1 つの AWS サービスから別のサービスに移動するのではなく、グループとしてそれらを管理する方が有益な場合があります。場合によってはアプリケーション層を構成する EC2 インスタンスなど、多数の関連リソースを管理する場合があります。この場合はこれらのリソースに対して一括してアクションを実行する必要があります。
+ **タグ**

  タグはAWS リソースを目的、所有者、環境などさまざまな方法で分類するのに役立ちます。この分類は同じ種類のリソースが多い場合に便利です。割り当てたタグを使用して、特定のリソースをすばやく識別することができます。
+ **レート制御**

  レート制御は[マルチアカウント] および [リージョン] でも設定されます。レート制御のパラメータを設定する際、ターゲットカウントまたはターゲットの割合 (%) によって、自動化を適用するフリートの数を定義します。

 **マルチアカウントおよびマルチリージョン**

マルチアカウントとマルチリージョンの設定でも使用されるレート制御で指定されたパラメータに加えて、2 つの設定があります。
+ **アカウントと組織単位 (OU)**

  自動化を実行する複数のアカウントを指定します。
+ **AWS リージョン**

  自動化を実行する複数の AWS リージョン を指定します。

**手動による実行**  
このオプションは[**シンプルな実行**] に似ていますが、このオプションでは自動化の各ステップを進め、結果を監査することができます。

## Windows Server をアップグレードする
<a name="automated-upgrades-windows"></a>

`[AWSEC2-CloneInstanceAndUpgradeWindows](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeWindows.html)` ランブックではアカウントの Windows Server インスタンスから Amazon マシンイメージ (AMI) を作成し、この AMI を、サポートされている希望のバージョンにアップグレードします。このマルチステッププロセスは完了するまで 2 時間かかる場合があります。

自動アップグレードプロセスには 2 つの AMI が含まれています。
+ **現在実行中のインスタンス**。最初の AMI は現在実行中のインスタンスです。このインスタンスはアップグレードされません。この AMI は別のインスタンスを起動してインプレースアップグレードを実行するために使用されます。プロセスが完了したら、この AMI はアカウントから削除されます。ただし、元のインスタンスを保持するように特別にリクエストした場合を除きます。この設定を行うには`KeepPreUpgradeImageBackUp` パラメータを使用します (デフォルト値は `false` です。つまり、AMI はデフォルトで削除されます)。
+ **更新された AMI**。この AMI は自動化プロセスの結果です。

最終結果は1 つの AMI です。つまり、AMI の更新されたインスタンスです。

アップグレードが完了したら、Amazon VPC で新しい AMI を起動して、アプリケーション機能をテストできます。テストが終了したら、別のアップグレードを実行する前に、アプリケーションのダウンタイムをスケジュールしてから、アップグレードされたインスタンスに完全に切り替えます。

### 前提条件
<a name="automated-prereq-windows"></a>

AWS Systems Manager オートメーションドキュメントを使用して Windows Server のアップグレードを自動化するには以下のタスクを実行する必要があります。
+ 指定された IAM ポリシーを使用して IAM ロールを作成することで、Systems Manager が Amazon EC2 インスタンスに対して自動化タスクを実行できるようにし、Systems Manager を使用するための前提条件を満たしていることを確認します。詳細については「AWS Identity and Access Management ユーザーガイド」の「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。**
+ [自動化の実行方法に関するオプションを選択してください。](#automated-execution-option)実行のオプションには[**シンプルな実行**]、[**レートの制御**]、[**複数のアカウントとリージョン**]、[**手動の実行**] があります。これらのパラメータの詳細については「[実行オプション](#automated-execution-option)」を参照してください。
+ インスタンスに SSM Agent がインストールされていることを確認します。詳細については「[Installing and configuring SSM Agent on Amazon EC2 instances for Windows Server (Windows Server の Amazon EC2 インスタンスで SSM Agent をインストールして設定する)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)」を参照してください。
+ Windows PowerShell 3.0 以降をインスタンスにインストールする必要があります。
+ Microsoft Active Directory ドメインに参加しているインスタンスの場合はホスト名の競合を避けるために、ドメインコントローラーに接続できない `SubnetId` を指定することをお勧めします。
+ インスタンスサブネットにはインターネットへのアウトバウンド接続が必要です。これにより、Amazon S3 などの AWS のサービス へのアクセスと、Microsoft からのパッチのダウンロードが可能になります。この要件はサブネットがパブリックサブネットでインスタンスにパブリック IP アドレスがある場合、またはサブネットがインターネットトラフィックをパブリック NAT デバイスに送信するルートを持つプライベートサブネットの場合に満たされます。
+ このオートメーションはWindows Server 2008 R2、Windows Server 2012 R2、Windows Server 2016、および Windows Server 2019 を実行しているインスタンスで機能します。
+ インスタンスでブートディスクに 20 GB の空きディスク領域があることを確認します。
+ インスタンスが AWS の提供する Windows ライセンスを使用しない場合はWindows Server 2012 R2 インストールメディアを含む Amazon EBS スナップショット ID を指定します。これを実行するには:

  1. Amazon EC2 インスタンスで Windows Server 2012 以降が実行されていることを確認します。

  1. インスタンスが実行されているのと同じアベイラビリティーゾーンに 6 GB の Amazon EBS ボリュームを作成します。ボリュームをインスタンスにアタッチします。それをマウントします (例えばドライブ D として)。

  1. ISO を右クリックし、インスタンスにマウントします (例えばドライブ E として)。

  1. ISO の内容をドライブ E:\$1 からドライブ D:\$1 にコピーします。

  1. 上記のステップ 2 で作成した 6 GB ボリュームの Amazon EBS スナップショットを作成します。

### Windows Server のアップグレードの制限事項
<a name="automated-windows-limits"></a>

このオートメーションではWindows のドメインコントローラー、クラスター、または Windows デスクトップオペレーティングシステムのアップグレードはサポートされていません。さらに、このオートメーションでは以下のロールがインストールされた Windows Server の Amazon EC2 インスタンスもサポートされていません。
+ リモートデスクトップセッションホスト (RDSH)
+ リモートデスクトップ接続ブローカー (RDCB) 
+ リモートデスクトップ仮想化ホスト (RDVH) 
+ リモートデスクトップウェブアクセス (RDWA)

### Windows Server の自動アップグレードの実行のステップ
<a name="2008R2-2012R2"></a>

以下のステップに従い、[AWSEC2-CloneInstanceAndUpgradeWindows](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeWindows.html) オートメーションランブックを使用して Windows Server インスタンスをアップグレードします。

1. **AWS マネジメントコンソール**から Systems Manager を開きます。

1. 左のナビゲーションペインの **[Change Management]** (変更管理) で、**[Automation]** (オートメーション) を選択してください。

1. [**Execute automation (自動化の実行)**] を選択してください。

1. `AWSEC2-CloneInstanceAndUpgradeWindows` と呼ばれるオートメーションドキュメントを検索します。

1. ドキュメント名が表示されたら、選択してください。選択すると、ドキュメントの詳細が表示されます。

1. **[Execute automation]** (オートメーションの実行) を選択して、このドキュメントのパラメータを入力してください。ページの上部にある [**シンプルな実行**] は選択したままにします。

1. 次のガイダンスに従って、リクエストされたパラメータを入力してください。
   + `InstanceID`

     **タイプ:** 文字列

     (必須) SSM エージェントがインストールされている Windows Server 2008 R2、2012 R2、2016、2019 を実行しているインスタンス。
   + `InstanceProfile`. 

     **タイプ:** 文字列

     (必須) IAM インスタンスプロファイル。この IAM ロールはAmazon EC2 インスタンスと AWS AMI に対して Systems Manager のオートメーションを実行するために使用されます。詳細については、*AWS Systems Managerユーザーガイド*の「[EC2 インスタンスの権限の設定](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-permissions.html#instance-profile-add-permissions)」を参照してください。
   + `TargetWindowsVersion`

     **タイプ:** 文字列

     (必須) ターゲットの Windows バージョンを選択してください。
   + `SubnetId`

     **タイプ:** 文字列

     (必須) このサブネットはアップグレードプロセス用であり、ソース EC2 インスタンスの場所を指します。サブネットに Amazon S3 などの AWS サービス や Microsoft (パッチのダウンロード用) へのアウトバウンド接続があることを確認します。
   + `KeepPreUpgradedBackUp`

     **タイプ:** 文字列

     (オプション) このパラメータが `true` に設定されている場合は自動化によって、インスタンスから作成されたイメージが保持されます。デフォルトの設定は`false` です。
   + `RebootInstanceBeforeTakingImage`

     **タイプ:** 文字列

     (オプション) デフォルトは `false` です (再起動なし)。このパラメータが `true` に設定されている場合はSystems Managerによって、アップグレード用の AMI を作成する前にインスタンスが再起動されます。

1. パラメータを入力したら、[**実行**] を選択してください。自動化が開始したら、実行の進行状況をモニタリングすることができます。

1. 自動化が完了すると、AMI ID が表示されます。Windows OS がアップグレードされたことを確認するにはAMI を起動します。
**注記**  
自動化のすべてのステップを実行する必要はありません。それぞれのステップには自動化とインスタンスの動作に基づいた条件が付けられています。Systems Manager は必須でない一部のステップをスキップする場合があります。  
さらに、いくつかの手順がタイムアウトすることもあります。Systems Manager ではすべての最新パッチについて、インストールとアップグレードが試みられます。ただし、場合によっては特定のステップの定義可能なタイムアウト設定に基づいてパッチがタイムアウトします。この場合、Systems Manager の自動化は次のステップに進み、内部 OS ターゲットの Windows Server バージョンにアップグレードされるようにします。

1. 自動化が完了したら、AMI ID を使用して Amazon EC2 インスタンスを起動して、アップグレードを確認することができます。AWS AMI から Amazon EC2 インスタンスを作成する方法の詳細については「[カスタム AMI から EC2 インスタンスを起動する方法](https://repost.aws/knowledge-center/launch-instance-custom-ami)」を参照してください。

## SQL Server のアップグレード
<a name="automated-upgrades-sql"></a>

[AWSEC2-CloneInstanceAndUpgradeSQLServer](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeSQLServer.html) スクリプトではアカウントで SQL Server を実行している Amazon EC2 インスタンスから AMI を作成し、その AMI を SQL Server の新しいバージョンにアップグレードします。このマルチステッププロセスは完了するまで 2 時間かかる場合があります。

自動化はインスタンスから AMI を作成し、指定したサブネットで新しい AMI を起動します。その後、オートメーションはSQL Server のインプレースアップグレードを実行します。アップグレードが完了したら、自動化によって、アップグレードされたインスタンスを終了する前に新しい AMI が作成されます。

自動アップグレードプロセスには 2 つの AMI が含まれています。
+ **現在実行中のインスタンス**。最初の AMI は現在実行中のインスタンスです。このインスタンスはアップグレードされません。この AMI は別のインスタンスを起動してインプレースアップグレードを実行するために使用されます。プロセスが完了したら、この AMI はアカウントから削除されます。ただし、元のインスタンスを保持するように特別にリクエストした場合を除きます。この設定を行うには`KeepPreUpgradeImageBackUp` パラメータを使用します (デフォルト値は `false` です。つまり、AMI はデフォルトで削除されます)。
+ **更新された AMI**。この AMI は自動化プロセスの結果です。

最終結果は1 つの AMI です。つまり、AMI の更新されたインスタンスです。

アップグレードが完了したら、Amazon VPC で新しい AMI を起動して、アプリケーション機能をテストできます。テストが終了したら、別のアップグレードを実行する前に、アプリケーションのダウンタイムをスケジュールしてから、アップグレードされたインスタンスに完全に切り替えます。

### 前提条件
<a name="automated-prereq-sql"></a>

AWS Systems Manager オートメーションドキュメントを使用して SQL Server のアップグレードを自動化するには以下のタスクを実行する必要があります。
+ 指定された IAM ポリシーを使用して IAM ロールを作成することで、Systems Manager が Amazon EC2 インスタンスに対して自動化タスクを実行できるようにし、Systems Manager を使用するための前提条件を満たしていることを確認します。詳細については「AWS Identity and Access Management ユーザーガイド」の「[AWS のサービス に許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
+ [自動化の実行方法に関するオプションを選択してください。](#automated-execution-option)実行のオプションには[**シンプルな実行**]、[**レートの制御**]、[**複数のアカウントとリージョン**]、[**手動の実行**] があります。これらのパラメータの詳細については「[実行オプション](#automated-execution-option)」を参照してください。
+ Amazon EC2 インスタンスではWindows Server 2008 R2 以降および SQL Server 2008 以降を使用する必要があります。
+ インスタンスに SSM Agent がインストールされていることを確認します。詳細については「[Windows Server の Amazon EC2 インスタンスで SSM Agent を使用する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)」を参照してください。
+ インスタンスに十分な空きディスク容量があることを確認します。
  + Windows Server 2008 R2 から 2012 R2 にアップグレードする場合、または Windows Server 2012 R2 からそれ以降のオペレーティングシステムにアップグレードする場合はインスタンスのブートディスクに 20 GB の空きディスク容量があることを確認してください。
  + Windows Server 2008 R2 から 2016 以降にアップグレードする場合はインスタンスのブートディスクに 40 GB の空きディスク領域があるか、インスタンスを確認します。
+ Bring Your Own License (BYOL) SQL Server バージョンを使用するインスタンスの場合、次の前提条件が追加で適用されます。
  + ターゲットの SQL Server インストールメディアを含む Amazon EBS スナップショット ID を提供します。これを実行するには: 

    1. Amazon EC2 インスタンスで Windows Server 2008 R2 以降が実行されていることを確認します。

    1. インスタンスが実行されているのと同じアベイラビリティーゾーンに 6 GB の Amazon EBS ボリュームを作成します。ボリュームをインスタンスにアタッチします。それをマウントします (例えばドライブ D として)。

    1. ISO を右クリックし、インスタンスにマウントします (例えばドライブ E として)。

    1. ISO の内容をドライブ E:\$1 からドライブ D:\$1 にコピーします。

    1. ステップ 2 で作成した 6 GB ボリュームの Amazon EBS スナップショットを作成します。

### SQL Server 自動アップグレードの制限事項
<a name="automated-sql-limits"></a>

[AWSEC2-CloneInstanceAndUpgradeSQLServer](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeSQLServer.html) ランブックを使用して自動アップグレードを実行する場合は以下の制限が適用されます。
+ アップグレードはWindows 認証を使用して SQL Server 上でのみ実行できます。
+ インスタンスに保留中のセキュリティパッチの更新がないことを確認します。[**Control Panel (コントロール パネル)**] を開き、[**Check for updates (更新の確認)**] を選択してください。
+ HA およびミラーリングモードでの SQL Server のデプロイはサポートされていません。

### SQL Server の自動アップグレードの実行のステップ
<a name="SQL2008R2-SQL2016"></a>

以下のステップに従い、[AWSEC2-CloneInstanceAndUpgradeSQLServer](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeSQLServer.html) オートメーションランブックを使用して SQL Server をアップグレードします。

1. まだダウンロードしていない場合はSQL Server 2016 の .iso ファイルをダウンロードして、ソースサーバーにマウントします。

1. .iso ファイルがマウントされたら、コンポーネントファイルをすべてコピーし、任意のボリューム上に置きます。

1. そのボリュームの Amazon EBS スナップショットを取得し、後で使用できるようにそのスナップショット ID をクリップボードにコピーします。6\$16詳細については「**[Amazon EBS ユーザーガイド]**」の「[Amazon EBS スナップショットの作成](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html)」を参照してください。

1. インスタンスプロファイルを Amazon EC2 ソースインスタンスにアタッチします。これにより、Systems Manager はEC2 インスタンスと通信し、AWS Systems Manager サービスに追加されているコマンドを実行できるようになります。例えば、ロールに `SSM-EC2-Profile-Role` という名前を付け、そのロールに `AmazonSSMManagedInstanceCore ` ポリシーをアタッチします。

1. AWS Systems Manager コンソールの左のナビゲーションペインで、[**マネージドインスタンス**] を選択してください。EC2 インスタンスがマネージドインスタンスのリストに含まれていることを確認します。数分後にインスタンスが表示されない場合は*AWS Systems Manager ユーザーガイド*の[インスタンスがある場所](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-remote-commands.html#where-are-instances)を参照してください。

1. 左のナビゲーションペインの **[Change Management]** (変更管理) で、**[Automation]** (オートメーション) を選択してください。

1. [**Execute automation (自動化の実行)**] を選択してください。

1. `AWSEC2-CloneInstanceAndUpgradeSQLServer` と呼ばれるオートメーションドキュメントを検索します。

1. `AWSEC2-CloneInstanceAndUpgradeSQLServer` SSM ドキュメントを選択し、**[Next]** (次へ) を選択してください。

1. [**シンプルな実行**] オプションが選択されていることを確認します。

1. 次のガイダンスに従って、リクエストされたパラメータを入力してください。
   + `InstanceId` 

     **タイプ:** 文字列

     (必須) SQL Server 2008 R2 (またはそれ以降) を実行しているインスタンス。
   + `IamInstanceProfile`

     **タイプ:** 文字列

     (必須) IAM インスタンスプロファイル。
   + `SQLServerSnapshotId`

     **タイプ:** 文字列

     (必須) ターゲット SQL Server インストールメディア用のスナップショット ID。このパラメータはSQL Server ライセンス込みインスタンスには必要ありません。
   + `SubnetId`

     **タイプ:** 文字列

     (必須) このサブネットはアップグレードプロセス用であり、ソース EC2 インスタンスの場所を指します。サブネットに Amazon S3 などの AWS サービス や Microsoft (パッチのダウンロード用) へのアウトバウンド接続があることを確認します。
   + `KeepPreUpgradedBackUp`

     **タイプ:** 文字列

     (オプション) このパラメータが `true` に設定されている場合は自動化によって、インスタンスから作成されたイメージが保持されます。デフォルトの設定は`false` です。
   + `RebootInstanceBeforeTakingImage`

     **タイプ:** 文字列

     (オプション) デフォルトは `false` です (再起動なし)。このパラメータが `true` に設定されている場合はSystems Managerによって、アップグレード用の AMI を作成する前にインスタンスが再起動されます。
   + `TargetSQLVersion`

     **タイプ:** 文字列

     (オプション) ターゲット SQL Server のバージョン。デフォルトは `2016` です。

1. パラメータを入力したら、[**実行**] を選択してください。自動化が開始したら、実行の進行状況をモニタリングすることができます。

1. [**実行ステータス**] に [**成功**] と表示されている場合は[**出力**] を展開して AMI 情報を確認します。AMI ID を使用して、任意の VPC で SQL Server インスタンスを起動します。

1. Amazon EC2 コンソールを開きます。左のナビゲーションペインで [**AMI**] を選択してください。新しい AMI が表示されます。

1. SQL Server の新しいバージョンが正常にインストールされていることを確認するには新しい AMI を選択して、**[Launch]** (起動) を選択してください。

1. AMI で使用するインスタンスのタイプ、デプロイする VPC とサブネット、使用するストレージを選択してください。AMI から新しいインスタンスを起動しているため、起動している新しい EC2 インスタンスに含めるボリュームがオプションとして提示されます。これらのボリュームは必要に応じて削除または追加できます。

1. インスタンスを識別しやすいようにタグを追加します。

1. 1 つ以上のセキュリティグループをインスタンスに追加します。

1. [**インスタンスの作成**] を選択してください。

1. インスタンスのタグ名を選択し、[**アクション**] ドロップダウンの [**接続**] を選択してください。

1. SQL Server の新しいバージョンが新しいインスタンスのデータベースエンジンとして表示されていることを確認します。

# EC2 Windows インスタンスを Nitro ベースのインスタンスタイプに移行する
<a name="migrating-latest-types"></a>

AWS Windows AMI はMicrosoft のインストールメディアで使用されるデフォルト設定で設定されており、いくつかのカスタマイズがあります。M5 や C5 といった [Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)をサポートするドライバーや設定などをカスタマイズできます。

以下のようなケースで Xen ベースのインスタンスから Nitro ベースのインスタンス (ベアメタルインスタンスなど) に移行する場合はこのトピックの手順に従うことをお勧めします。
+ カスタム Windows AMI からインスタンスを作成する場合
+ 2018 年 8 月より前に作成された Amazon が提供する Windows AMI からインスタンスを作成する場合

また、`AWSSupport-UpgradeWindowsAWSDrivers` オートメーションドキュメントを使用して、パート 1、パート 2、パート 3 で説明した手順を自動化することもできます。自動化された手順を使用する場合は[(代替案) AWS Systems Manager を使用した AWS PV、ENA、NVMe ドライバーのアップグレード](#auto-upgrade) を参照して、パート 4 とパート 5 に進みます。

詳細については[Amazon EC2 の更新 - 追加インスタンスタイプ、Nitro システム、および CPU オプション](https://aws.amazon.com/blogs/aws/amazon-ec2-update-additional-instance-types-nitro-system-and-cpu-options/)を参照してください。

**注記**  
Windows Server バージョン 2016 以降では以下の移行手順を実行できます。オペレーティングシステムのサポート期限が切れた古いバージョンではテストされておらず、最新のインスタンスタイプと互換性がない可能性があります。  
Linux インスタンスを移行するには「[Amazon EC2 インスタンスタイプの変更](ec2-instance-resize.md)」を参照してください。

**Contents**
+ [パート 1: AWS PV ドライバーのインストールとアップグレード](#upgrade-pv)
+ [パート 2: ENA のインストールとアップグレード](#upgrade-ena)
+ [パート 3: AWS NVMe ドライバーをアップグレード](#upgrade-nvme)
+ [パート 4: EC2Config および EC2Launch の更新](#upgdate-ec2config-ec2launch)
+ [パート 5: ベアメタルインスタンスのシリアルポートドライバーのインストール](#install-serial-port-bare-metal)
+ [パート 6: 電源管理設定の更新](#power-management)
+ [パート 7: 新しいインスタンスタイプ用の Intel チップセットドライバーの更新](#power-management-intel-drivers)
+ [(代替案) AWS Systems Manager を使用した AWS PV、ENA、NVMe ドライバーのアップグレード](#auto-upgrade)

**[開始する前に]** 

この手順では[Xen ベースのインスタンス](instance-types.md#instance-hypervisor-type) (M4 や C4 など) を使用中で、それを [Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)に移行しようとしていることが前提となります。

アップグレードを正常に実行するにはPowerShell バージョン 3.0 以降を使用する必要があります。

**注記**  
移行する場合、インスタンスが新しい Enhanced Networking Adapter デバイスにデフォルトで設定されるため、既存のネットワークインターフェイスカードの静的 IP またはカスタム DNS ネットワーク設定は失われる場合があります。

この手順のステップを実行する前に、インスタンスのバックアップを作成することをお勧めします。[EC2 コンソール](https://console.aws.amazon.com/ec2/)で、移行が必要なインスタンスを選択し、コンテキストメニュー (右クリック) を開いたら、[**インスタンスの状態**]、[**停止**] の順に選択してください。

**警告**  
インスタンスを停止すると、インスタンスストアボリューム上のデータは消去されます。インスタンスストアボリューム上のデータを保持するには永続的ストレージにデータをバックアップするようにしてください。

[EC2 コンソール](https://console.aws.amazon.com/ec2/)でインスタンスの右クリックコンテキストメニューを開き、[**イメージ**]、[**イメージの作成**] の順に選択してください。

**注記**  
この手順のパート 4 およびパート 5 はインスタンスタイプを移行または変更した後で完了できます。ただし、特にベアメタルインスタンスタイプに移行する場合は移行前に完了することをお勧めします。

## パート 1: AWS PV ドライバーのインストールとアップグレード
<a name="upgrade-pv"></a>

AWS PV ドライバーが Nitro システムで使用されていなくても、Citrix PV または AWS PV の以前のバージョンを使用している場合はアップグレードする必要があります。最新の AWS PV ドライバーはNitro システムがある場合、または Xen ベースインスタンスに戻す必要がある場合に表面化するかもしれない以前のバージョンのドライバーのバグを解決します。ベストプラクティスとして、AWS の Windows インスタンスの最新ドライバーに常に更新することをお勧めします。

次の手順に従って、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2、Windows Server 2016、または Windows Server 2019 で、 AWS PV ドライバーのインプレースアップグレードを実行するか、Citrix PV ドライバーから AWS PV ドライバーにアップグレードします。詳細については[EC2 Windows インスタンスでの PV ドライバーのアップグレード](Upgrading_PV_drivers.md)を参照してください。

ドメインコントローラーをアップグレードするには[ドメインコントローラーのアップグレード (AWS PV アップグレード)](Upgrading_PV_drivers.md#aws-pv-upgrade-dc)を参照してください。

**AWS PV ドライバーのアップグレードを実行するには**

1. リモートデスクトップを使用してインスタンスに接続し、アップグレードのためにインスタンスを準備します。アップグレードを実行する前に、システムディスク以外をすべてオフラインにします。AWS PV ドライバーのインプレースアップグレードを実行する場合はこのステップは必要ありません。また、サービスコンソールで、不可欠でないサービスを [**手動**] 起動に設定します。

1. インスタンスに最新のドライバーパッケージを[ダウンロード](https://s3.amazonaws.com/ec2-windows-drivers-downloads/AWSPV/Latest/AWSPVDriver.zip)します。

1. フォルダの内容を抽出し、`AWSPVDriverSetup.msi` を実行します。

MSI の実行後、インスタンスは自動的に再起動され、ドライバーがアップグレードされます。インスタンスは最大 15 分間、使用できなる場合があります。

アップグレードが完了し、インスタンスが Amazon EC2 コンソールの両方のヘルスチェックに合格した後、リモートデスクトップを使用してインスタンスに接続して、新しいドライバーがインストールされたことを確認します。デバイスマネージャーの [**Storage Controllers**] で、[**AWS PV Storage Host Adapter**] を見つけます。ドライバーバージョンがドライバーのバージョン履歴の表に掲載されている最新バージョンと同じであることを確認します。詳細については[AWS PV ドライバーパッケージの履歴](xen-drivers-overview.md#pv-driver-history)を参照してください。

## パート 2: ENA のインストールとアップグレード
<a name="upgrade-ena"></a>

すべてのネットワーク機能がサポートされるように、最新の Elastic Network Adapter ドライバーにアップグレードします。インスタンスを起動し、すでに拡張ネットワーキングが有効になっていない場合、必要なネットワークアダプタドライバーをダウンロードしてインスタンスにインストールします。次に、**拡張ネットワークを有効にする**ように enaSupport インスタンス属性を設定します。この属性はサポートされるインスタンスタイプにおいて、ENA ドライバーがインストールされている場合のみ有効にできます。詳細については[EC2 インスタンスで ENA による拡張ネットワーキングを有効にする](enhanced-networking-ena.md)を参照してください。

1. インスタンスに最新のドライバーを[ダウンロード](https://s3.amazonaws.com/ec2-windows-drivers-downloads/ENA/Latest/AwsEnaNetworkDriver.zip)します。以前のバージョンのドライバーが必要な場合は「[ENA Windows ドライバーのバージョン履歴](ena-driver-releases-windows.md#ena-win-driver-release-history)」を参照してください。

1. zip アーカイブを展開します。

1. 展開したフォルダから `install.ps1` PowerShell スクリプトを実行してドライバーをインストールします。
**注記**  
インストールエラーを回避するには`install.ps1` スクリプトを管理者として実行します。

1.  ご使用の AMI が enaSupport を有効にしているかどうか確認します。有効でない場合は[EC2 インスタンスで ENA による拡張ネットワーキングを有効にする](enhanced-networking-ena.md) のマニュアルに従ってください。

## パート 3: AWS NVMe ドライバーをアップグレード
<a name="upgrade-nvme"></a>

AWS NVMe ドライバーはNitro システム内では NVMe ブロックデバイスとして表示される Amazon EBS および SSD インスタンスストアボリュームとやり取りを行い、パフォーマンスを向上させるために使用されます。

**重要**  
Xen ベースのインスタンスで AWS NVMe をインストールまたはアップグレードできるように、次の手順が変更されています。これはインスタンスを Nitro ベースのインスタンスに移行することが目的です。

1. インスタンスに最新のドライバーパッケージを[ダウンロード](https://s3.amazonaws.com/ec2-windows-drivers-downloads/NVMe/Latest/AWSNVMe.zip)します。

   以前のバージョンのドライバーが必要な場合は「[NVMe Windows ドライバーのリリース](nvme-driver-version-history.md)」でサポートされるバージョンを確認してください。

1. zip アーカイブを展開します。

1.  `Readme.txt` の説明に従ってドライバーをインストールします。

1. **PowerShell** セッションを開き、次のコマンドを実行します。

   ```
   PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
   ```
**注記**  
コマンドを適用するには管理者として PowerShell セッションを実行している必要があります。PowerShell (x86) のバージョンではエラーが発生します。  
このコマンドはデバイスドライバーでのみ sysprep を実行します。完全な sysprep 準備は実行しません。

1. Windows Server 2008 R2 および Windows Server 2012 の場合、インスタンスをシャットダウンし、インスタンスタイプを変更し起動してからパート 4 に進みます。Nitro ベースのインスタンスタイプに移行する前に、インスタンスを再度 Xen ベースのインスタンスタイプで起動しようとしても動作しません。他のサポートされた Windows AMI の場合はデバイスの sysprep の後いつでもインスタンスタイプを変更できます。

## パート 4: EC2Config および EC2Launch の更新
<a name="upgdate-ec2config-ec2launch"></a>

Windows インスタンスの場合、最新の EC2Config および EC2Launch ユーティリティが EC2 ベアメタルの場合を含む Nitro Systemで実行されると追加の機能および情報が提供されます。EC2Config サービスはWindows Server 2016 より前の AMI にデフォルトで含まれています。EC2Launch はWindows Server 2016 以降の AMI の EC2Config を置き換えます。

EC2Config サービスおよび EC2Launch サービスが更新されると、AWS からの新しい Windows AMI には最新バージョンのサービスが含まれます。ただし、EC2Config および EC2Launch の最新バージョンを使用して、独自の Windows AMI とインスタンスを更新する必要があります。

**EC2Config のインストールまたは更新**

1. [EC2Config インストーラ](https://s3.amazonaws.com/ec2-downloads-windows/EC2Config/EC2Install.zip)をダウンロードして解凍します。

1. `EC2Install.exe` を実行します。オプションの完全なリストについては`EC2Install` オプションを指定して `/?` を実行してください。デフォルトではセットアップによってプロンプトが表示されます。プロンプトを表示せずにコマンドを実行するには`/quiet` オプションを使用します。

詳細については[EC2Config の最新バージョンのインストール](UsingConfig_Install.md)を参照してください。

**EC2Launch のインストールまたは更新**

1. インスタンスで EC2Launch をすでにインストールして設定している場合はEC2Launch 設定ファイルのバックアップを作成します。インストールプロセスではこのファイルに変更内容が保存されません。デフォルトではこのファイルは `C:\ProgramData\Amazon\EC2-Windows\Launch\Config` ディレクトリにあります。

1. [EC2-Windows-Launch.zip](https://s3.amazonaws.com/ec2-downloads-windows/EC2Launch/latest/EC2-Windows-Launch.zip) をインスタンス上のディレクトリにダウンロードします。

1. [install.ps1](https://s3.amazonaws.com/ec2-downloads-windows/EC2Launch/latest/install.ps1) を `EC2-Windows-Launch.zip` のダウンロード先と同じディレクトリにダウンロードします。

1. `install.ps1` を実行します。
**注記**  
インストールエラーを回避するには`install.ps1` スクリプトを管理者として実行します。

1. EC2Launch 設定ファイルのバックアップを作成する場合は同ファイルを `C:\ProgramData\Amazon\EC2-Windows\Launch\Config` ディレクトリにコピーします。

詳細については[EC2 Windows インスタンスの起動時に EC2Launch v1 エージェントを使用してタスクを実行する](ec2launch.md)を参照してください。

## パート 5: ベアメタルインスタンスのシリアルポートドライバーのインストール
<a name="install-serial-port-bare-metal"></a>

`i3.metal` インスタンスタイプではI/O ポートベースのシリアルデバイスではなく、PCI ベースのシリアルデバイスを使用しています。最新の Windows AMI は自動的に PCI ベースのシリアル・デバイスを使用し、シリアル・ポート・ドライバーがインストール済みです。日付が 2018.04.11 以降の Amazon が提供する Windows AMI から作成したインスタンスを使用していない場合、シリアル・ポート・ドライバーをインストールしてパスワード生成やコンソール出力などの EC2 機能用のシリアル・デバイスを有効にする必要があります。最新の EC2Config および EC2Launch はi3.metal もサポートし、追加機能を提供します。まだ実行していない場合はパート 4 のステップに従います。

**シリアルポートドライバーをインストールするには**

1. インスタンスにシリアルドライバーパッケージを[ダウンロード](https://s3.amazonaws.com/ec2-windows-drivers-downloads/AWSPCISerialDriver/Latest/AWSPCISerialDriver.zip)します。

1. フォルダの内容を展開し、`aws_ser.INF` のコンテキストメニューを開き (右クリック)、[**インストール**] を選択してください。

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

## パート 6: 電源管理設定の更新
<a name="power-management"></a>

次のように電源管理設定を更新すると、ディスプレイが消灯しないように設定されます。これにより、Nitro Systemで正常な OS のシャットダウンが可能になります。2018 年 11 月 28 日時点で Amazon が提供しているすべての Windows AMI は既にこのデフォルトの設定になっています。

1. コマンドプロンプトまたは PowerShell セッションを開きます。

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

   ```
   powercfg /setacvalueindex 381b4222-f694-41f0-9685-ff5bb260df2e 7516b95f-f776-4464-8c53-06167f40cc99 3c0bc021-c8a8-4e07-a973-6b14cbcb2b7e 0
   powercfg /setacvalueindex 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c 7516b95f-f776-4464-8c53-06167f40cc99 3c0bc021-c8a8-4e07-a973-6b14cbcb2b7e 0
   powercfg /setacvalueindex a1841308-3541-4fab-bc81-f71556f20b4a 7516b95f-f776-4464-8c53-06167f40cc99 3c0bc021-c8a8-4e07-a973-6b14cbcb2b7e 0
   ```

## パート 7: 新しいインスタンスタイプ用の Intel チップセットドライバーの更新
<a name="power-management-intel-drivers"></a>

`u-6tb1.metal`、`u-9tb1.metal`、および `u-12tb1.metal` インスタンスタイプは以前は Windows AMI にインストールされていなかったチップセットドライバーを必要とするハードウェアを使用します。日付が 2018 年 11 月 19 日以降の Amazon が提供する Windows AMI から起動したインスタンスを使用していない場合、Intel チップセット INF ユーティリティを使用して、そのドライバーをインストールする必要があります。

**チップセットドライバーをインストールするには**

1. インスタンスへの[チップセット INF ユーティリティ](https://www.intel.com/content/www/us/en/download/19347/chipset-inf-utility.html)。

1. ファイルを展開します。

1. `SetupChipset.exe` を実行します。

1. Intel ソフトウェアライセンス契約に同意し、チップセットドライバーをインストールします。

1. インスタンスを再起動します。

## (代替案) AWS Systems Manager を使用した AWS PV、ENA、NVMe ドライバーのアップグレード
<a name="auto-upgrade"></a>

`AWSSupport-UpgradeWindowsAWSDrivers` オートメーションドキュメントはパート 1、パート 2、パート 3 で説明した手順を自動化することもできます。この方法はドライバーのアップグレードに失敗したインスタンスを修復することもできます。

`AWSSupport-UpgradeWindowsAWSDrivers` オートメーションドキュメントは指定された EC2 インスタンスでストレージおよびネットワーク AWS ドライバーをアップグレードまたは修復します。このドキュメントではAWS Systems Manager エージェント (SSM Agent) を呼び出すことによって、最新バージョンの AWS ドライバーをオンラインでインストールしようとしています。SSM Agent が接続可能でない場合、明示的に要求された場合、ドキュメントは AWS ドライバーのオフラインインストールを実行できます。

**注記**  
ドメインコントローラーではこの手順は失敗します。ドメインコントローラーでドライバを更新するには[ドメインコントローラーのアップグレード (AWS PV アップグレード)](Upgrading_PV_drivers.md#aws-pv-upgrade-dc)を参照してください。

**AWS Systems Manager を使用して AWS PV、ENA および NVMe ドライバーを自動的にアップグレードするには**

1. [https://console.aws.amazon.com/ Systems Manager](https://console.aws.amazon.com/systems-manager) で Systems Manager コンソールを開きます。

1. [**オートメーション**]、[**オートメーションの実行**] の順に選択してください。

1. **AWSSupport-UpgradeWindowsAWSDrivers** オートメーションドキュメントを検索して選択し、**[オートメーションの実行]** を選択してください。

1. **[入力パラメータ]** セクションで、次のオプションを設定します。  
[インスタンス ID]  
アップグレードするインスタンスの一意の ID を入力してください。  
AllowOffline  
(オプション) 次のオプションのいずれかを選択してください。  
   + `True` —オフラインインストールを実行するにはこのオプションを選択してください。インスタンスはアップグレード処理中に停止され、再開されます。
**警告**  
インスタンスを停止すると、インスタンスストアボリューム上のデータは消去されます。インスタンスストアボリューム上のデータを保持するには永続的ストレージにデータをバックアップするようにしてください。
   + `False` — (デフォルト) オンラインインストールを実行するにはこのオプションを選択したままにします。インスタンスはアップグレード処理中に再起動されます。
オンラインおよびオフラインのアップグレードではアップグレード操作を試みる前に AMI が作成されます。AMI は自動化が完了した後も維持されます。AMI へのアクセスを保護するか、不要になった場合は削除してください。  
SubnetId  
(オプション) 以下のいずれかの値にエラーがあります。  
   + `SelectedInstanceSubnet` — (デフォルト) アップグレードプロセスではアップグレードするインスタンスと同じサブネットに*ヘルパー*インスタンスを起動します。サブネットはSystems Manager エンドポイント (`ssm.*`) との通信を可能にする必要があります。
   + `CreateNewVPC` — アップグレードプロセスでは*ヘルパー*インスタンスが新しい VPC で起動されます。ターゲットインスタンスのサブネットが `ssm.*` エンドポイントと通信できるかどうかが不明な場合はこのオプションを使用します。ユーザーはVPC を作成するアクセス許可が必要です。
   + 特定のサブネット ID — *ヘルパー*インスタンスを起動する特定のサブネットの ID を指定します。サブネットはアップグレードするインスタンスと同じアベイラビリティーゾーンに存在し、`ssm.*` エンドポイントとの通信を許可する必要があります。

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

1. アップグレードの完了を許可します。オンラインアップグレードの完了には最大 10 分、オフラインアップグレードの完了までには最大 25 分かかります。

# EC2 Windows インスタンスのオペレーティングシステムアップグレードに関するトラブルシューティング
<a name="os-upgrade-trbl"></a>

AWS は Upgrade Helper Service に関する問題についてアップグレードサポートを提供しています。Upgrade Helper Service はCitrix PV ドライバーを伴うインプレースアップグレードの実行を支援する AWS ユーティリティです。

アップグレードの後で、.NET Runtime Optimization サービスが .NET フレームワークを最適化する間、インスタンスの平均 CPU 使用率が一時的に高くなる場合があります。これは想定される動作です。

インスタンスが数時間後にすべてのステータスチェックに成功しなかった場合、次の項目を確認してください。
+ Windows Server 2008 にアップグレードして数時間後にすべてのステータスチェックに失敗した場合、アップグレードが失敗した可能性があり、ロールバックを確定する **[OK をクリック]** のプロンプトが表示されます。この状態ではコンソールにアクセスできないため、[OK] ボタンをクリックすることはできません。この状態を回避するにはAmazon EC2 コンソールまたは API を使用して再起動を行います。再起動が始まるまで 10 分以上かかります。インスタンスが使用可能になるまで 25 分ほどかかることがあります。
+ サーバーからアプリケーションまたはサーバーロールを削除した後、もう一度試します。

サーバーからアプリケーションまたはサーバーロールを削除した後、インスタンスがすべてのステータスチェックに失敗した場合、次の操作を行います。
+ インスタンスを停止し、ルートボリュームを別のインスタンスにアタッチします。詳細については["メタデータサービスを待っています"](common-messages.md#metadata-unavailable)でルートボリュームを停止して別のインスタンスにアタッチする方法の説明を参照してください。
+ [Windows セットアップのログファイルとイベントログ](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-log-files-and-event-logs?view=windows-11)で失敗の原因を調べます。

オペレーティングシステムのアップグレードまたは移行に関するその他の問題についてには[インプレースアップグレードを開始する前に](os-inplaceupgrade.md#os-upgrade-before)に一覧表示されている記事を確認することをお勧めします。