Windows Server 2019

Windows Server 2012/R2のサポート終了が迫っています！今すぐ移行計画を立てましょう この記事の内容 Windows Server 2012/2012 R2のサポートは2023年10月10日に終了します サポート終了後も延長セキュリティ更新プログラム（ESU）で最大3年の猶予が得られますが、コストがかかります Azureまたはオンプレミスの Azure Stack HCI へ移行することで、ESUを3年間無償で受けられます Azure Stack HCI へ移行することで、Windowsサーバーのメジャーバージョンアップ問題から解放されます クラスター対応更新（CAU）により、OS・ファームウェア・ドライバーのアップデートがボタン操作で完了します サポート終了まであと少し Windows Server 2012および2012 R2は、Microsoftの製品ライフサイクル情報によると、2023年10月10日にサポートが終了します。 まだまだ現役で使われている組織が多いかと思いますが、残り期間を考えると、今から計画を立ててもギリギリか、すでに間に合わない状況になりつつあります。組織内にWindows Server 2012が存在している場合、アップグレードするのか、移行するのか、作り変えるのかといった検討から実作業まで、相当な期間が必要です。2年という猶予はあっという間に過ぎてしまいます。 中には、まだWindows Server 2008を使い続けているというお客様もいらっしゃいます。メジャーバージョンのサポート切れに多くの組織が追いつけず、延長サポートを受けるために高額な費用を支払い続けているケースも少なくありません。 延長セキュリティ更新プログラム（ESU）という選択肢 Microsoftからはサポート終了に伴うサーバー移行支援オファーも提供されており、その中に**Extended Security Updates（ESU）**があります。ESUを利用することで、サポート終了後も最大3年間、セキュリティ更新プログラムを受け取ることができます。 ただし、ESUをファーストオプションとして最初から選択してしまうのは避けてください。あくまでも移行準備のための猶予として位置づけるべきものです。 ESUを無償で受けられる2つの移行先 移行先によっては、3年間のESUを無償で受けることができます。これが非常に重要なポイントです。 1. パブリッククラウド（Azure）への移行 Windows Server 2012をそのままAzureに移行することで、3年間無償でESUを受けることができます。Windows Server 2008でも実績がある方法です。 移行を支援するサービスとして、以下のものが活用できます。 Azure Migrate：移行のアセスメントと計画を支援 Azure Site Recovery：スムーズなレプリケーションと移行 以前は「クラウドに持ってこられない」と思われていたシステムも、今では対応できるケースが増えています。たとえば、共有ディスクを使ったクラスターも、現在はAzure上で利用できるようになっています。一度検討したことがある方も、改めて確認してみる価値があります。 2. オンプレミスのAzure Stack HCIへの移行 パブリッククラウドへの移行がハードルとして高い組織には、オンプレミスのままAzure Stack HCIへ移行することで、無償でESUを受けられるという選択肢があります。 Azure Stack HCIが対象となるサービスには以下が含まれます。 Azure VMware Solution（AVS） Azure Stack HCI たとえばAVSを使えば、IPアドレスやMACアドレスを変更せずにライブマイグレーションでAzureに移行し、延長サポートを受け続けることも可能です。 オンプレミスの仮想基盤をAzure Stack HCIにリプレースして、オンプレミス環境のまま無償ESUを受け取ることができます。Azure Stack HCIのOSは「Azure Stack HCI OS」としてWindows Serverから独立しており、Azureの延長サポートを受けられる構成になっています。 ...

Windows Server 2019 から 2022 へのインプレースアップグレード この記事の内容 Windows Server 2019 が稼働中の Hyper-V サーバーに対して、インプレースアップグレードで Windows Server 2022 を導入した検証結果を紹介します アップグレード作業は Lenovo XClarity Controller（リモート管理ボード）経由でリモート実施しました Hyper-V 上で仮想マシンが起動中だとアップグレードが失敗するという注意点があります アップグレード後も Hyper-V ロールおよびゲスト VM が問題なく動作することを確認しました 検証環境では特に大きなトラブルなくアップグレードに成功しました 検証環境について 今回の検証は、Lenovo ThinkSystem SE350 をメインの検証環境として使用しています。この機材はお借りしたものであり、普段から Hyper-V サーバーとして多数の仮想マシンを稼働させています。 今回の目的は、その実際に使用中のサーバーに対して、インプレースアップグレードで Windows Server 2022 を導入し、問題なく動作するかどうかを検証することです。 リモート管理ボードを使ったアップグレード作業 サーバー機器は通常の PC とは異なり、ディスプレイを直接接続することが少ない環境です。今回は Lenovo XClarity Controller（リモート管理ボード）にアクセスし、リモートコントロール機能を使って画面を開いた状態でアップグレード作業を実施しました。 これにより、BIOS 画面も含めて作業中に画面が消えることなく、安定してセットアップを進めることができます。 アップグレードの手順 1. Windows Server メディアのマウントとセットアップの起動 Windows Server 2022 のインストールメディアをサーバーにマウントし、セットアップを起動します。セットアップ開始直後に更新プログラムのダウンロードが始まりますが、これは最新の ISO を入手済みであっても追加の更新が適用されることがあるため正常な動作です。 2. 失敗事例：仮想マシンの停止を忘れずに 最初の試行では、以下のエラーが発生しセットアップが中断されました。 実 行 中 の 仮 想 マ シ ン が 1 つ 以 上 検 出 さ れ ま し た Hyper-V サーバーに対してインプレースアップグレードを実施する場合、Hyper-V 上で稼働中の仮想マシンをすべて電源オフにする必要があります。 ...

以下が記事本文です。 Nested Hyper-V on Azure — Azure上でHyper-Vをネストして動かす方法 この記事の内容 Nested Hyper-V（ネストされた仮想化）とは何か、その仕組みを解説します Azure上でNested Hyper-Vを利用するための前提条件と注意事項を説明します Nested Hyper-Vに対応したAzure VMサイズの選び方を紹介します Hyper-VをAzure VM上で有効化する具体的な手順をデモで確認します ネスト環境におけるネットワーク構成の課題とNATを使った解決策を解説します Nested Hyper-Vとは Nested Hyper-V（ネストされたHyper-V）とは、Hyper-VのホストOS上に作成した仮想マシン（ゲストOS）の中で、さらにHyper-Vを動かして仮想マシンを作成する技術です。つまり「仮想マシンの中でさらに仮想マシンを動かす」ということになります。 通常のHyper-V環境では、CPUが持つ仮想化支援機能（Virtualization Extensions）はホストOSにのみ提供されます。ゲストOSにはこの機能が見えないため、ゲストOS上でHyper-Vを有効化することができません。 Nested Hyper-Vではこの制限を取り除き、仮想化支援機能をゲストOSにも提供します。これにより、ゲストOS上でもHyper-Vを有効化して、さらにその中にゲストOSを作成することが可能になります。 Nested Hyper-V on Azureとは 「Nested Hyper-V on Azure」とは、AzureのVM上でNested Hyper-Vを実行することを指します。 オンプレミス環境でNested Hyper-Vを利用する場合は、ホストOSのPowerShellから以下のコマンドを実行し、仮想化支援機能をゲストのvCPUに公開します。 Set-VMProcessor -VMName <VM名> -ExposeVirtualizationExtensions $true しかしAzure上では、このような根本的な設定を利用者が直接実行することはできません。そのため、あらかじめNested Hyper-Vが有効化されたVMサイズを選択するというアプローチになります。 利用条件と注意事項 Nested Hyper-Vを利用するには、以下の条件を満たす必要があります。 ホストOSとゲストOSの両方が、Windows Server 2016以降、またはWindows 10 Anniversary Update以降であること IntelのCPU（VT-xおよびEPTテクノロジーをサポートするもの）であること AMDのCPUは現時点では非対応（Windows 11でサポートされる可能性があるとの情報もありますが、公式発表の確認が必要です） また、Nested Hyper-VはゲストOSを多段階で動かすため、CPU・メモリのリソースを大量に消費します。それなりのスペックのVMを選択するよう注意してください。 Azure VMサイズの選択 AzureでNested Hyper-Vを利用するには、対応しているVMサイズを選ぶ必要があります。対応VMサイズはMicrosoftの公式ドキュメントに記載されています。 本デモでは以下のサイズを使用しました。 項目 設定値 VMサイズ D16s v4 OS Windows Server 2019 リージョン 東日本 フィルターで「Nested Virtualization対応」を絞り込む機能はポータル上に存在しないため、ドキュメントを参照しながらサイズを選定する必要があります。 ...

Windows Server 2019 に Microsoft Edge をインストールする方法 この記事の内容 Windows Server 2019 では通常の手順では Microsoft Edge がインストールできない場合がある 「ビジネス向け Microsoft Edge」のダウンロードページを使うことで解決できる Azure 上の Windows Server 2019 Datacenter 環境で検証した手順を紹介 IE（Internet Explorer）しか入っていない環境でも適用可能 通常の Edge ダウンロードページでは起動できない・インストールできないという注意点がある 背景 Azure 上に展開した Windows Server 2019 Datacenter（2021年4月のアップデート適用済み）の環境では、デフォルトブラウザーとして IE（Internet Explorer）が入っているものの、Microsoft Edge はインストールされていません。 Edge をインストールしようと通常の方法でブラウザーのダウンロードページにアクセスすると、うまく起動できなかったり、インストールが完了しないという問題が発生します。 問題の症状 Windows Server 2019 の環境で Edge を入れようと、IE から Edge のダウンロードページにアクセスすると、以下のような状況になります。 ページは表示されるものの、インストーラーが正常に起動できない Edge がすでに入っている前提で動作しているように見える 「インストール済み」と判定されて先に進めない 通常のダウンロード導線をそのまま辿っても、Windows Server 環境ではうまくいきません。 解決方法：ビジネス向け Microsoft Edge をダウンロードする Twitter（現 X）で教えてもらった方法として、「ビジネス向け Microsoft Edge」のダウンロードページを使うことで解決できます。 手順 IE を開き、以下のキーワードで検索します。 ビ ジ ネ ス 向 け マ イ ク ロ ソ フ ト エ ッ ジ ダ ウ ン ロ ー ド 検索結果から「ビジネス向け Microsoft Edge をダウンロードする」というページを開きます。 ...

Azure Stack HCI と Storage Spaces Direct を見て理解する この記事の内容 Windows Admin Center（WAC）を使ったAzure Stack HCIクラスターの追加・管理方法 Storage Spaces Direct（S2D）のコマンド一発での有効化手順 スケールアウト（ノード追加）の簡単さ クラウド監視（Cloud Witness）の構成方法 ボリューム種別（3方向ミラー・Mirror Accelerated Parity）と耐障害性の実証 環境の概要 今回のデモ環境では、Windows Admin Center（WAC）をWebベースの管理ツールとして使用しています。ホストマシンはメモリ128GB・プロセッサ1基・32コアの構成で、Hyper-V上にさらにHyper-Vをネストして動作させています。 クラスターはStorage Spaces Directを実行していることが前提です。WACはAAD（Azure AD）と接続することで認証を行い、シングルサインオンにも対応しています。 Windows Admin CenterへのクラスターI追加 まず既存クラスターをWACに追加します。「接続の追加」からサーバー名を指定してクラスターを登録すると、WACがStorage Spaces Directを実行しているクラスターであることを自動で検出します。 追加後はダッシュボードで各サーバーの稼働状況、CPU・メモリ・IOPSレイテンシーなどをリアルタイムに確認できます。 Storage Spaces Direct の有効化 S2Dの有効化は驚くほどシンプルです。PowerShellで以下のコマンドを実行するだけです。 Enable-ClusterS2D New-Volume -StoragePoolFriendlyName "S2D on <クラスター名>" -FriendlyName "S2DVolume" -FileSystem CSVFS_ReFS このコマンドを実行すると、接続されているすべてのディスクを自動的に検出し、構成を最適化してストレージプールを作成します。複雑に見えるHyper-Converged Infrastructureの構成が、たった数行のコマンドで完了します。 スケールアウト（ノード追加） Azure Stack HCIの大きな特長の一つがスケールアウトの容易さです。 WACの「クラスターにサーバーを追加」からサーバー名を指定するだけで、3台目のノードをクラスターに参加させられます。追加中も仮想マシンは稼働を継続し、ストレージも自動的にリバランスされます。 1クラスターあたり最大16ノードまで拡張可能 最大ディスク容量は4ペタバイト ダウンタイムなしで仮想マシンの再配置とストレージのリバランスが実施されます クラウド監視（Cloud Witness）の構成 クラスターノードが偶数台の場合、クォーラムの観点から奇数台構成を推奨します。たとえば4ノード構成では、ノード同士が「2対2」で分断された際にどちらの側も過半数に達せず、両方が停止してしまう危険があります。 この解決策として**クラウド監視（Cloud Witness）**を追加します。Azureのストレージアカウントを使うことで、物理的な拠点を用意することなくクォーラムの票を1票追加できます。 Cloud Witnessの設定手順 1. Azureポータルでストレージアカウントを作成する ...

Storage Spaces Direct（記憶域スペースダイレクト）での2ノードから4ノードへのスケールアウト この記事の内容 Storage Spaces Direct（S2D）クラスターを2ノードから4ノードへスケールアウトする手順を紹介します ノード追加後のストレージプール拡張は、S2Dが自動的に実行します 仮想ディスク（Virtual Disk）の拡張は管理者が手動で行う必要があります Windows Admin CenterのUIへの反映はPowerShellより遅延があるため、リアルタイム確認にはPowerShellを推奨します ノード追加後のストレージ最適化（リバランス）の実行方法についても解説します 前提環境 この動画では、2ノード構成のStorage Spaces Directクラスターを出発点としています。クラスターはすでに稼働しており、仮想マシンも動作しているという状態です。 初期状態の確認として、以下のコマンドでストレージプールや仮想ディスクの状態を把握しておきます。 Get-StoragePool Get-VirtualDisk Get-PhysicalDisk 初期状態では、例えばストレージプールのサイズが 43.7 TB 程度であることを確認しておきます。この数値がノード追加後にどう変わるかを比較するための基準値となります。 ノードの追加手順 クラスターへのノード追加 ノードの追加は Add-ClusterNode コマンドを使って行います。追加するサーバーを指定するだけで、クラスターへの参加が完了します。 Add-ClusterNode -Name <追加するサーバー名> このコマンド一発でクラスターにノードが追加されます。操作自体は非常にシンプルです。 S2Dによる自動処理 ノードがクラスターに追加されると、Storage Spaces Directは以下の処理を全自動で実行します。 新しく追加されたサーバーのディスクを検出する 検出したディスクをストレージプールに追加する ストレージプールのサイズを拡張する この動作は、Get-PhysicalDisk コマンドで確認できる CanPool プロパティに注目することで追跡できます。ノード追加直後は True（プールへの追加が可能）となっており、S2Dが自動処理を完了すると False（すでにプールに追加済み）に変わります。 Get-PhysicalDisk | Select-Object FriendlyName, CanPool, Usage すべてのディスクの CanPool が False になれば、自動追加が完了した状態です。 ストレージプール拡張の確認 ノード追加後に再度 Get-StoragePool を実行すると、プールサイズが拡張されていることを確認できます。 Get-StoragePool 例として、2ノード時に 43.7 TB だったプールサイズが、4ノード追加後には 615.67 TB に拡張されていることが確認できます。この拡張も人手を介さず全自動で行われます。 ...