企業でよくあるWindows/M365環境を構築してみる

Windowsクライアントをコードで全自動展開する — Windows/M365環境構築シリーズ Part9 この記事の内容 Hyper-V上でWindows 10およびWindows 11のゴールデンイメージを作成する手順を解説します Sysprepと応答ファイル（Unattend.xml）を組み合わせ、クライアントOSを全自動で構成する方法を紹介します WinRMをオフライン環境でセットアップするためのHyper-Vゲストサービス活用法を説明します サーバー版の応答ファイルとクライアント版の違いについてポイントを整理します AnsibleプレイブックからCopy-VMFileコマンドレットを利用してVMを自動展開するフローを示します はじめに 前回までのシリーズでは、Windows Serverのひな型（ゴールデンイメージ）をSysprepで作成し、コード1本で自動展開できる環境を構築してきました。しかし実際の検証環境ではクライアントOSも必要になります。そこで今回はWindows 10とWindows 11のひな型も作成し、サーバーと同じようにコードから自動展開できる仕組みを整えていきます。 Hyper-V仮想マシンの作成 まずHyper-V上に仮想マシンを2台作成します。 項目 Windows 10 Windows 11 世代 第2世代 第3世代 メモリ 8GB 8GB ネットワーク 接続しない 接続しない ポイント：ネットワークには接続しないこと ひな型作成時にネットワークへ接続すると、Windows Updateが走るなど想定外の動作が起きやすくなります。ネットワークを切断した状態でセットアップを進めるほうが格段に楽です。 Windows 11特有の設定 Windows 11ではセキュリティ要件が厳しいため、仮想マシンのセキュリティ設定でTPM（トラステッドプラットフォームモジュール）を必ず有効化してください。有効にしないとISOからのインストール自体が弾かれてしまいます。 初回セットアップとAdministratorアカウントの準備 仮想マシンが起動したら、初期セットアップウィザードをローカルアカウントで進めます。ネットワーク未接続の状態であれば、Microsoftアカウントを求められることなくローカルユーザーでのセットアップが可能です。 セットアップ完了後は以下の手順でAdministratorアカウントを有効化します。 セットアップ時に作成したローカルユーザーで一度ログオン 「コンピューターの管理」からセットアップ用ユーザーを削除 ビルトインAdministratorアカウントを有効化 Administratorでログオンし直す このシリーズでは、Ansibleから管理する際にビルトインAdministratorで統一することでシンプルな管理を実現しています。なお、通常Sysprep実行後にAdministratorは無効化されますが、応答ファイル内に無効化を防ぐ記述を入れることで有効状態を維持します。 WinRMのセットアップ（オフライン環境での対処） AnsibleからWindows VMをリモート管理するにはWinRMの構成が必要です。通常はインターネットからスクリプトをダウンロードして実行しますが、今回はネットワーク未接続のため別の方法を使います。 Hyper-Vゲストサービスを使ったファイル転送 Hyper-Vの「統合サービス」にあるゲストサービスを有効化すると、Copy-VMFileコマンドレットでホストからゲストへファイルをコピーできます。ネットワーク接続が不要なため、オフライン環境で非常に役立ちます。 まずゲストVM上で一時ディレクトリを作成しておきます。 New-Item -ItemType Directory -Path C:\temp 次にホスト側のHyper-V管理端末からスクリプトをゲストにコピーします。 Copy-VMFile "Windows10" ` -SourcePath "C:\temp\ConfigureRemotingForAnsible.ps1" ` -DestinationPath "C:\temp\ConfigureRemotingForAnsible.ps1" ` -CreateFullPath ` -FileSource Host WinRM構成スクリプトの実行 ゲストVM内でPowerShellを管理者として起動し、スクリプト実行ポリシーを変更してからスクリプトを実行します。 ...

仮想基盤上のActive Directory ドメインコントローラーの時刻同期を構成する — 企業でよくあるWindows/M365環境を構築してみるシリーズ Part8 この記事の内容 仮想環境（Hyper-V）上のActive Directory ドメインコントローラーで注意が必要な時刻同期の設定を解説します Hyper-Vの時刻同期統合サービスを無効化し、Windowsタイムサービス（w32tm）による正しい構成に切り替える手順を紹介します PDCエミュレーター（1台目のDC）を外部NTPサーバーと同期させる設定コマンドを紹介します 2台目以降のDCおよびメンバーサーバーはドメイン階層から自動的に時刻同期する構成の確認方法を説明します 設定を怠ると時刻ずれが発生し、Kerberos認証が失敗するなど深刻な障害につながるため、正しく構成されているか確認いただける内容です はじめに このシリーズでは、企業でよくあるWindows/M365環境を検証環境で再現しながら構築しています。前回まででActive Directoryを構築し、ユーザーを追加して同期を設定するところまで完了しました。 しかし、まだ1つ重要な設定が残っています。それが時刻同期の構成です。 Active Directoryにおいて時刻は非常に重要な要素です。特にKerberos認証では、ドメインコントローラーとクライアント間の時刻差が5分以内でなければ認証が失敗します。時刻がずれてしまうと認証エラーが発生し、ドメイン全体に影響が及ぶ深刻な障害となります。 仮想環境でのAD DCサポートについて かなり以前はドメインコントローラーを仮想環境で動作させることが推奨されない時代もありましたが、Windows Server 2012以降は仮想化環境での動作が正式にサポートされています。Server 2016以降はさらに改善が加えられています。 Microsoftの公式ドキュメント「Active Directory ドメイン サービス（AD DS）の安全な仮想化」でも、USNロールバックなどの問題が発生しないよう保護機能が導入されていることが説明されています。 仮想環境でのDCの時刻同期に関する重要な注意点 仮想環境でドメインコントローラーを運用する場合、多くの企業で時刻同期が推奨構成になっていないというケースが見受けられます。 Microsoftのドキュメントでは以下のように説明されています。 仮想環境で動作するドメインコントローラーに対してWindowsタイムサービスを正しく構成するには、ホストとゲスト（DC）間の時刻同期を無効化することが推奨されます Hyper-Vの場合、具体的にはHyper-V時刻同期プロバイダー（統合サービスの「時刻の同期」チェックボックス）をオフにします その上で、PDCエミュレーターが外部NTPサーバーと同期するよう構成します 2台目以降のDCやメンバーサーバーはドメインの階層構造に従って時刻を同期します 現在の時刻同期状態を確認する まず、現在の時刻同期がどのような状態になっているかを確認します。コマンドプロンプトを管理者として開き、以下のコマンドを実行します。 w32tm /query /status 設定変更前は、出力に VMICTimeProvider や VM IC Time Synchronization Provider と表示され、Hyper-Vの時刻同期機能と同期していることが確認できます。 Hyper-Vの時刻同期統合サービスを無効化する Hyper-Vマネージャーから、ドメインコントローラーの仮想マシンの設定を変更します。変更はVMをシャットダウンした状態で行います。 Hyper-Vマネージャーで対象VMを右クリックし、**「シャットダウン」**を選択します VMの**「設定」**を開きます 左メニューの**「統合サービス」**を選択します 「時刻の同期」チェックボックスをオフにします 「OK」をクリックして設定を保存します 複数のDCがある場合は、すべてのDCで同様の操作を行います。 起動・停止の順序について 複数のDCをシャットダウン・起動する場合、2台目以降のDCから停止し、1台目のDC（PDCエミュレーター）を最後にシャットダウンするとよいでしょう。起動時は逆に1台目のDCを最初に起動します。クラスターなどと同様に、マスターとなるサーバーを最後まで残し最初に起動することで、不要なトラブルを防ぐことができます。 PDCエミュレーターを外部NTPサーバーと同期させる DCを起動したら、フォレストルートのPDCエミュレーター（1台目のDC）に外部NTPサーバーとの同期を設定します。 以下のコマンドを実行します。ntp.nict.jp は国立研究開発法人情報通信研究機構（NICT）が提供する日本の標準時サーバーです。 w32tm /config /syncfromflags:manual /manualpeerlist:"ntp.nict.jp" /update 設定後、以下のコマンドで強制的に再同期します。 ...

Active Directoryへ2台目のドメインコントローラーを追加する この記事の内容 既存のActive Directory環境に2台目のドメインコントローラーを追加する手順を解説します Active Directoryサイトの概念と役割について説明します ドメインコントローラー昇格直後に発生するエラーの見方と対処法を紹介します dcdiag コマンドを使った診断の方法と注意点を解説します ドメインコントローラー追加後に絶対にやってはいけないことを説明します 前提環境 本記事では、すでに1台目のドメインコントローラー（DC01）が稼働しているWindows Server Active Directory環境に、2台目のサーバー（DC02）をドメインコントローラーに昇格させる手順を解説します。DC02はあらかじめドメインへのメンバーサーバーとして参加済みの状態からスタートします。 役割と機能の追加 DC02に対して、Active Directoryドメインサービス（AD DS）の役割を追加します。手順はDC01を構築した際と同様です。サーバーマネージャーから「役割と機能の追加」ウィザードを起動し、Active Directoryドメインサービスを選択してインストールします。 ドメインコントローラーへの昇格 AD DSのインストールが完了したら、ドメインコントローラーへの昇格ウィザードを起動します。ここで重要な選択肢があります。 ウィザードには以下の3つの選択肢が表示されます。 新しいフォレストを追加する 既存のフォレストに新しいドメインを追加する 既存のドメインにドメインコントローラーを追加する ← 今回はこちら すでにActive Directoryが存在する環境に2台目のドメインコントローラーを追加したい場合は、必ず「既存のドメインにドメインコントローラーを追加する」を選択してください。 操作を実行するための資格情報には、Domain Adminsなど最強権限を持つアカウントを使用します。 ドメインコントローラーオプションの設定 次の画面では、以下の項目を設定します。 ドメインネームシステム（DNS）サーバー: チェックを入れる グローバルカタログ（GC）: チェックを入れる ディレクトリサービス復元モード（DSRM）パスワード: 1台ごとに個別に設定が必要なため、このタイミングで入力する Active Directoryサイトについて ウィザードの途中でサイトを選択する画面が表示されます。ここでActive Directoryの「サイト」という概念を説明します。 サイトとは サイトとは、物理的なネットワークの場所を表す論理的な区画です。たとえば「東京オフィス」「大阪オフィス」のように複数のサイトを作成し、どのサブネットがどのサイトに属するかを定義できます。 サイトを使うメリット クライアントは自分が属するサイトを認識でき、そのサイト内にいるドメインコントローラーに優先的にログイン要求を送ります。これにより、地理的に近いドメインコントローラーへの自動ルーティングが実現します。 また、サイトが複数ある場合は、同じサイト内では頻繁にレプリケーションを行い、別サイトへのレプリケーションはまとめて夜間に行うなど、レプリケーショントポロジのコントロールが可能になります。 今回の環境 今回はサイトが1つだけ（Default-First-Site-Name）存在する構成のため、サブネットの定義は行わず、デフォルトのサイトをそのまま使用します。 レプリケーション元の指定 続いて、初期データをどのドメインコントローラーからレプリケートするかを指定する画面があります。現時点では1台しかないためどちらを選んでも結果は同じですが、複数台構成や複数サイト構成になった場合には、この設定がレプリケーション効率に影響します。 パスの確認とディスク設定 ADのデータベース、ログファイル、SYSVOLのパスを確認します。専用のドライブを用意しておくことが推奨されます。今回はウィザード内で新しいシンプルボリュームを作成してから設定を進めます。 設定が完了したらウィザードを完了させます。処理が終わると自動的に再起動されます。 昇格の確認 再起動後、サーバーマネージャーやActive Directoryサイトとサービスを確認します。 Active Directoryサイトとサービスを開くと、Default-First-Site-Name の中にDC02が追加されていることが確認できます Active Directoryユーザーとコンピューターを開くと、DC02がコンピューターのOUからドメインコントローラーのOUへ移動していることが確認できます これでDC02がドメインコントローラーとして認識されたことが確認できました。 dcdiag による診断 昇格直後に診断コマンドを実行してみましょう。 ...

Active Directoryへのドメイン参加 — 企業でよくあるWindows/M365環境を構築してみるシリーズ Part6 この記事の内容 既存のドメインコントローラー（DC01）の正常性確認方法（dcdiag / repadmin） 2台目のWindows Serverを追加してActive Directoryドメインへ参加させる手順 ドメイン参加時のDNS設定の重要性 Active Directoryユーザーとコンピューター（ADUC）でのオブジェクト確認 ドメインユーザーとローカルユーザーの違いと、ドメイン参加後のサインイン方法 はじめに 前回はドメインコントローラー（DC01）を1台構築しました。今回はそのDC01が正常に動作しているかを確認した上で、2台目のドメインコントローラー候補となるWindows Server（DC02）を追加し、Active Directoryドメインへ参加させるまでの手順を解説します。 次回はこのDC02をドメインコントローラーへ昇格させる手順を紹介予定です。 ドメインコントローラーの正常性確認 何か問題が発生したとき、「もともと壊れていたのか、追加したら壊れたのか」を切り分けることは非常に重要です。そのため、新しいサーバーを追加する前には必ず現状の正常性を確認しておきましょう。 dcdiag /v による確認 dcdiagコマンドを使うと、ドメインコントローラーに関する多数のテストを自動実行し、結果を一覧で表示してくれます。 dcdiag /v 実行するとたくさんの出力が流れますが、各テスト項目に対して「合格（passed）」や「失敗（failed）」が表示されます。以下のようなテストが実行されます。 接続性テスト（Connectivity） 広告テスト（Advertising） FRS/KCCイベントのテスト システムログの確認 DNS参照の確認 など多数 すべて合格であれば、ドメインコントローラーは正常に動作していると判断できます。暇があれば定期的に実行しておくことをおすすめします。 repadmin による複製状況の確認 2台以上のドメインコントローラーがある環境では、repadminコマンドで複製（レプリケーション）の状態も確認します。 repadmin /replsummary 1台構成の今は特に意味はありませんが、エラーが出ないことの確認として実行しておくと安心です。 2台目のWindows Serverの追加 DC01の正常性が確認できたので、次にDC02となる新しいWindows Serverを追加します。 仮想マシンの作成 手動でやる場合は「新規仮想マシン」として作成します。IaC（Infrastructure as Code）を使っている場合は、Ansibleなどのプレイブックを実行するだけで展開できます。 ansible-playbook create_vm.yml コードによる展開はサーバー追加が非常に手軽になるため、ぜひ活用してみてください。 DNSの設定（重要） DC02を作成する際、DNSサーバーのアドレスとして既存のDC01を指定することが非常に重要です。 D N S サ ー バ ー : < D C 0 1 の I P ア ド レ ス > ドメインに参加する際、WindowsはDNSを使ってドメイン名からドメインコントローラーを探します。既存のドメインコントローラー（DC01）がDNSサーバーを兼ねているため、DC02のDNS設定にDC01を指定しておかないと、後のドメイン参加処理が失敗します。 ...

Active Directory 構築解説 — 企業でよくあるWindows / M365環境を構築してみる Part5 この記事の内容 Active Directory ドメインサービス（AD DS）とは何か、なぜオンプレミス環境で必要なのかを解説します Windows Server へのAD DSロール追加から、ドメインコントローラーへの昇格までの手順を紹介します フォレスト・ドメイン・機能レベルなどの重要概念についても触れます ドライブ設計やDNSとの関係など、実運用で重要なポイントを解説します 冗長化（ドメインコントローラーを2台以上構成すること）の必要性についても説明します シリーズの概要と前提環境 このシリーズは、企業で一般的に使われているWindowsサーバーおよびMicrosoft 365環境を実際に構築しながら解説していくものです。冗長化なども考慮した「現場でそのまま使えるレベル」を目指しています。 Part4までで、物理サーバー（Lenovo ThinkSystem SE350）上にNested Hyper-Vを有効化した仮想マシンを作成し、Ansibleを使って仮想マシンの展開やネットワーク設定を自動化できる下準備が整いました。Part5からはいよいよ本題に入ります。 Active Directoryとは Active Directory（AD）は、主にWindowsサーバーやクライアントをまとめて管理するためのディレクトリサービスです。ユーザー、グループ、コンピューターなど、組織内のさまざまなリソースをディレクトリに登録し、一元管理することができます。 オンプレミスのWindows環境においては、Active Directoryはほぼ必須の存在です。ただし、その概念を完全に理解するには相応の学習が必要です。主要な学習項目だけでも相当な量があり、実際の現場管理者でなければ聞き慣れない用語が多く並びます。本シリーズでは「まず作って、動かしながら理解する」というアプローチで進めていきます。 また、Active Directoryにはいくつかの種類がありますが、今回はその基本となる**Active Directory ドメインサービス（AD DS）**を構築します。 Active Directoryの各サービスについて Windows Serverのロール一覧には、AD関連として以下のものが並んでいます。 サービス名 現在の推奨状況 Active Directory ドメインサービス（AD DS） 現在でも主力。オンプレミスでは必須 Active Directory フェデレーションサービス（AD FS） 非推奨。クラウド化が進み今から入れるべきではない Active Directory Rights Management Services（AD RMS） 非推奨。クラウド版への移行が進んでいる Active Directory ライトウェイトディレクトリサービス（AD LDS） 場合によっては使用する Active Directory 証明書サービス（AD CS） 現在でも利用する組織が多い AD FSとAD RMSは今から新規に構成することは推奨されません。今回はAD DSに集中します。 ...

AnsibleとHyper-VでInfrastructure as Codeを実現する この記事の内容 Hyper-V上でAnsibleを使ったInfrastructure as Code（IaC）の実現方法を解説します WindowsホストでAnsibleを動かすためにWSL（Windows Subsystem for Linux）を活用します YAMLファイルに仮想マシンの設定を記述するだけで、コマンド一発で自動展開できる仕組みを構築します Ansibleのべき等性により、同じプレイブックを複数回実行しても安全に運用できます 本シリーズのPart1〜3で作成したゴールデンイメージと組み合わせることで、完全自動のVM展開環境が完成します はじめに 本記事は「企業でよくあるWindows・M365環境を構築してみるシリーズ」のPart4です。前回までのPart1〜3では、ネステッドHyper-Vの基盤構築、Windows Server 2022のSysprep済みゴールデンイメージ作成、そして自動応答ファイルによるゼロタッチ展開の仕組みを整えました。 今回はその仕組みをさらに発展させ、Infrastructure as Code（IaC） を実現します。テキストファイルにVMの名前やIPアドレスなどの設定を書いておくだけで、コマンド一発で全自動的に環境が出来上がるという仕組みです。 自動化ツールには Ansible を使用します。Hyper-VでIaCを実現するための情報はインターネット上に非常に少なく、本記事の情報は希少性が高いものとなっています。 前提条件 本記事の手順を実施するにあたって、以下が完了していることを前提とします。 ネステッドHyper-Vの基盤構築済み Windows Server 2022のSysprep実行済みゴールデンイメージ作成済み 自動応答ファイルによるゼロタッチ展開の設定済み WSLのインストール AnsibleはWindows上では直接実行できないため、WSL（Windows Subsystem for Linux） を使用します。WSLを使うことで、Windows上でLinuxのコマンドが使えるようになります。 管理者権限でPowerShellを起動し、まずインストール可能なディストリビューション一覧を確認します。 wsl --list --online Ubuntuをインストールします。 wsl --install -d Ubuntu インストール後、再起動を求められますので再起動します。再起動後にログインすると、インストールが自動的に再開されます。UNIXユーザー名とパスワードを設定すれば完了です。 WSL（Ubuntu）環境のセットアップ WSLのUbuntu環境を最新の状態にします。 sudo apt update sudo apt upgrade -y 続いてAnsibleをインストールします。 sudo apt install ansible -y 次に、AnsibleからWindowsホストを管理するために必要な pywinrm もインストールします。 pip install pywinrm 最後にAnsible本体をインストールします。インストールが完了するとバージョン（例：2.9.6）が表示されます。 ...

以下が記事本文です。 ADK と SIM を使って応答ファイルを作成し、Sysprep 実行後の構成を自動化する この記事の内容 Windows ADK（Assessment and Deployment Kit）の「Deployment Tools」をインストールして Windows システムイメージマネージャー（SIM）を起動する手順を解説します SIM を使い、日本語ロケール・タイムゾーン・プロダクトキー・EULA 承諾・Administrator パスワードなどを盛り込んだ応答ファイル（Unattend.xml）を作成します 作成した応答ファイルを Sysprep 実行時に指定することで、仮想マシンの初回起動（OOBE）を完全に自動化する方法を紹介します 応答ファイルの配置先や Sysprep コマンドの引数についても具体的に説明します 複数の仮想マシンを展開する際に毎回手動設定が不要になり、ゴールデンイメージ運用が大幅に効率化されます 応答ファイルとは 前回は Sysprep の基本的な使い方を解説しました。今回はさらに一歩進めて、応答ファイル（Unattend.xml） を作成します。 応答ファイルとは、Sysprep 済みのイメージを初回起動（OOBE: Out-of-Box Experience）した際に自動的に読み込まれる設定ファイルです。これを使うことで次のような項目を無人で構成できます。 PC 名の設定 Administrator パスワードの設定 ライセンス（EULA）の自動承諾 言語・ロケール・タイムゾーンの設定 プロダクトキーの入力 応答ファイルを活用することで、Sysprep 済みイメージから何も入力せずに使える状態まで自動的に持っていくことが可能になります。 Windows ADK のインストール 応答ファイルを作成するには Windows ADK（Windows Assessment and Deployment Kit） が必要です。 ADK は、Windows イメージの大規模展開向けカスタマイズや、アプリケーションのパフォーマンステストなど多岐にわたる機能を持つツールキットです。Windows Server 2022 にも対応しています。 Microsoft の公式サイトから ADK のインストーラーをダウンロードし、実行します。機能の選択画面では、応答ファイルの作成に必要な以下のコンポーネントのみを選択します。 ...

Sysprepで Windows Server の雛形（ゴールドイメージ）を作成する この記事の内容 Windows Server を複数台展開する際に、毎回同じ設定をする手間を省く「雛形（ゴールドイメージ）」の作り方を解説します 仮想ディスク（VHDXファイル）を単純コピーしてはいけない理由と、その解決策としての Sysprep を紹介します Sysprep 実行前に雛形へ仕込んでおくと便利な設定項目を紹介します Sysprep を実行してシャットダウンされた状態の VHDX をコピーし、新しい仮想マシンを作成する手順を解説します 次回予告として、自動応答ファイルを使った展開後のセットアップ完全自動化について触れます はじめに 本記事は「企業でよくある Windows / M365 環境を構築してみるシリーズ」のパート2です。前回はネストされた Hyper-V 基盤を作成しました。今回はその基盤の上に Windows Server を効率よく複数台展開するために、Sysprep（システム準備ツール） を使って雛形を作成する方法を解説します。 なぜ単純なVHDXコピーではいけないのか 仮想マシンを複数台用意する方法のひとつとして、仮想ハードディスク（VHDXファイル）をそのままコピーするというアプローチが考えられます。しかし Windows の場合、OS 内部には固有の ID（SID など）が埋め込まれており、単純にコピーするとその ID が重複してしまいます。 特に Active Directory 環境では、この ID の重複が原因でさまざまな問題が発生します。そのため、コピーしても問題が起きないよう「一般化（Generalize）」した状態にしてからコピーする必要があります。 この一般化を行うツールが Sysprep（System Preparation Tool） です。 Sysprep とは Sysprep は Windows に標準搭載されているシステム準備ツールで、以下のパスに格納されています。 C : \ W i n d o w s \ S y s t e m 3 2 \ S y s p r e p \ s y s p r e p . e x e Sysprep を実行して「一般化」を選択すると、OS に埋め込まれた固有の ID がクリアされ、次回起動時に再生成される状態になります。また、シャットダウンオプションを選ぶことで、一般化処理が完了した後に OS が自動的にシャットダウンされます。 ...

Nested Hyper-Vで検証基盤を準備する — 企業でよくあるWindows・M365環境を構築してみるシリーズ Part1 この記事の内容 Nested Hyper-V（ネスト仮想化）とは何か、有効化の手順を解説します Windows Server 2022 をインストールした仮想マシンを検証基盤として構築します 内部仮想スイッチと PowerShell の New-NetNat コマンドレットを使い、NAT ネットワークを構成します ゲスト VM からインターネットへの疎通確認まで行います 次回以降、この基盤の上に Active Directory など企業向け環境を展開していきます シリーズの概要 このシリーズでは、Windows Server と Microsoft 365 を使った典型的な企業向け環境を構築し、ポイントを解説していきます。冗長化も考慮しながら進めていく予定です。 本記事は第1回として、後続の環境構築すべての土台となる Nested Hyper-V の検証基盤 を整えます。検証機材として Lenovo ThinkSystem SE350 を使用しています。 Nested Hyper-V とは Nested Hyper-V（ネスト仮想化）とは、仮想マシン上で Hyper-V を動作させることです。つまり、すでに仮想化されている環境の中に、さらに仮想マシンを作成できるようになります。 有効化するには Set-VMProcessor コマンドレットに -ExposeVirtualizationExtensions $true を指定して実行します。これにより、仮想マシンに仮想化支援機能が公開され、その中で Hyper-V が利用できるようになります。 ネットワーク構成の全体像 構築するネットワーク構成は以下のとおりです。 既存の構成（SE350 上）: 物理ネットワーク → SE350（物理マシン）→ インターネット SE350 上に Hyper-V が有効化済み NatSwitch という名前の NAT スイッチが作成済み（192.168.x.x/16 のネットワーク） Hyper-V ホストは NatSwitch 上に仮想 NIC を持ち、192.168.x.254 を割り当て済み 今回新たに構築する構成: ...

企業でよくある Windows / M365 環境を構築してみる — シリーズ紹介 この記事の内容 Windows Server と Active Directory を中心としたオンプレミス環境を、ゼロから構築する手順を解説するシリーズの紹介記事です Active Directory とAzure Active Directory（Microsoft Entra ID）を Microsoft Entra Connect で同期する構成まで扱います クライアント端末（Windows 10/11）のドメイン参加や、ファイルサーバー・Webサーバー・プリントサーバーなども対象とします 可用性・冗長構成を意識した、実際の企業環境に近い設計を目指します 各動画はこのインデックス動画を起点にリンクがまとめられます シリーズの概要 このシリーズは、「Active Directory と Azure Active Directory を Microsoft Entra Connect で同期したい」というリクエストをきっかけに始まりました。せっかくなら企業でよくある環境をゼロから構築しながら、一つひとつ丁寧に解説していこうというコンセプトで企画されています。 ネストされたHyper-V環境を活用し、ゼロから環境を作るところを見せられる構成を前提としています。 構築予定の内容 シリーズ全体を通して、以下の構成要素を順番に構築していく予定です。 オンプレミス環境の構築 まずはオンプレミス側の基盤を整えます。 Windows Server の展開 Active Directory の構築 メンバーサーバーの展開とドメイン参加 クライアント（Windows 10 / Windows 11）の展開とドメイン参加 グループポリシーの適用 Active Directory ユーザーの作成 クライアントからドメインユーザーでログインし、ドメイン上のリソースにアクセスする流れの確認 また、以下のサーバーロールも追加する予定です。 ファイルサーバー Webサーバー（Windows統合認証） プリントサーバー クラウド連携の構築 オンプレミス環境が完成したら、次はクラウド側との統合に進みます。 Azure Active Directory（Microsoft Entra ID）の作成 Microsoft Entra Connect による同期の設定 Microsoft 365 の展開 オンプレミス認証基盤とクラウド認証基盤のシングルサインオン構成 冗長構成への意識 このシリーズでは、テスト環境とはいえ「1台で済ませる」という構成は極力避け、冗長性・可用性を意識した構成を目指します。実際の企業環境でも通用するような設計を念頭に置きながら進めていきます。 ...