ラベル Windows の投稿を表示しています。 すべての投稿を表示
ラベル Windows の投稿を表示しています。 すべての投稿を表示
2026年1月17日土曜日

Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順

Entra Joinで管理しているWindows 11のデバイスは、ローカルアカウントを使えば今まで通りリモートデスクトップ接続することが可能だが、Entra IDでログインする場合は、少し工夫が必要となる。

本記事では、Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順を記載する。なお、接続手順は2パターンある。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築している。

  • デバイス : Windows 11 24H2 ※仮想マシン

手順①:「Webアカウントを使用して、リモートコンピューターにサインインする」のオプションを使う

1. Entra IDのユーザーを「Remote Desktop Users」または「Administrators」グループに所属させる

Entra IDのユーザーはGUIからはローカルのグループに所属させることはできない。したがって、以下のようにnet localgroupコマンドで追加を行う。コマンド実行には管理者権限が必要となる。

PS C:\Users\test> net localgroup "Remote Desktop Users" /add "AzureAD\tuser001@test.com"
コマンドは正常に終了しました。

追加後、念のためGUIでも確認しておこう。「コンピューターの管理 > ローカルユーザーとグループ」を開いてみると、「Entraのドメイン名\ユーザー名」でグループにEntra IDのユーザーが追加されているはずだ。

2. リモートデスクトップ接続の設定を変更

「リモートデスクトップ接続」の「詳細設定」タブにある「Webアカウントを使用して、リモートコンピューターにサインインする」を有効にする。

3. リモートデスクトップ接続実施

Webアカウントによるリモートデスクトップ接続を行い場合は、IPアドレスの接続は許可されずホスト名によるログインが必要となる。

なお、IPアドレスで接続しようとすると、以下のようなエラーで接続に失敗する。

4. ユーザー・パスワード入力

通常のリモートデスクトップ接続とは異なり、よくあるEntra IDでログインする際のユーザー・パスワードの入力画面が表示される。


入力内容に問題なければ、リモートデスクトップ接続に成功し、接続先デバイスのOS画面が表示される。

手順②:CredSSPを無効化する

1. Entra IDのユーザーを「Remote Desktop Users」または「Administrators」グループに所属させる

これは手順①と同じなので割愛する。

2. 接続先デバイスでネットワークレベル認証 (NLA) を無効化

接続先となるWindows 11のデバイスで、「設定 > システム > リモートデスクトップ」より、「デバイスが接続にネットワークレベル認証を使用することを要求する (推奨)」のチェックを外す。これによりネットワークレベル認証 (NLA) を無効化する。

3. リモートデスクトップ接続設定

リモートデスクトップ接続を開き、接続先のコンピューター名 (IPアドレスでも可) とEntra IDのアカウントを入力する。Entra IDのアカウントは「ユーザー名@ドメイン名」の形で入力すること。入力後、「名前を付けて保存」にて*.rdpファイルを保存する。

保存したファイル (*.rdp) のファイルをメモ帳などで開き、enablecredsspsupport:i:0の行を最下行に追記する。

この設定は、「クライアントが認証に資格情報セキュリティ サポート プロバイダー (CredSSP) を使用するかどうかを指定する」設定となり、0を指定することで無効化する。

screen mode id:i:1
use multimon:i:0

~(中略)~

username:s:AzureAD\tuser001@test.com
enablecredsspsupport:i:0 ←★追記

4. リモートデスクトップ接続実施

保存したファイル (*.rdp) をダブルクリックし、リモートデスクトップ接続をすると、通常はリモートデスクトップ接続クライアントで聞かれる認証画面ではなく、通常のWindows 11のログイン画面が表示され、ユーザー・パスワード入力ができるようになる。

5. ユーザー・パスワード入力

ユーザー名にはEntra IDのユーザー名を入力するが、「azuread\ユーザー名@ドメイン名」の名前で入力する。「azuread」と入力することでサインイン先がEntra IDとなる。

なお、*.rdpのファイル内で事前に「azuread\ユーザー名@ドメイン名」を入れたユーザー名で設定したとしても、必ず手入力で「azuread」の入力が必要となるので注意すること。

以上で、Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順は完了となる。

参考

2026年1月5日月曜日

Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせる

Entra Kerberosを設定すると、Entra Joinしている端末からもオンプレADのドメイン上のファイルサーバーにSSOし、ファイルアクセスができるようになる。

本記事では、Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせる手順を記載する。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築している。

  • デバイス : Windows 11 24H2 ※仮想マシン

1. Entra Kerberosを構成する

SSOさせるための前提条件として、「①Entra ConnectによるオンプレユーザーをEntra IDへ同期」させ、「②Entra Kerberosを構成」する必要がある。Entra IDで認証した際に、オンプレADの認証に必要な「部分的なTGT」を受け取ることで、オンプレADの認証を処理させるためだ。

Entra Connectの設定手順は、以下URLを参照すること。

Entra Kerberosの設定手順は、以下URLの「クラウド信頼とEntra Kerberosについて」を参照すること。

Entra Join手順

1. 設定画面へ遷移

[設定] > [アカウント] > [職場または学校にアクセスする]を選択する。

[職場または学校のアカウントを追加」を選択する。

2. Entra Joinに必要な認証情報の入力

「職場または学校アカウントのセットアップ」では、中央の「電子メールアドレス」のテキストボックスに入力して進めたくなるが、画面下部の[このデバイスをMicrosoft Entra IDに参加させる]のリンクを選んで登録する点に注意しよう。

Microsoftアカウントの認証画面に遷移するので、Entra IDのユーザー・パスワードを入力する。

「これがあなたのネットワークであることを確認してください」では「参加する」を選択する。

完了すると、「<テナント名>のEntra IDに接続しました」と表示される。

Entra管理センターでも、デバイスが「Microsoft Entra joined」と表示される。

以上で、Entra Joinは完了となる。

ファイルサーバーへのSSOでのアクセス確認

オンプレADにドメイン参加したWindows 11に共有フォルダを作成し、これをファイルサーバー相当としてSSOによる接続確認を行う。使用するユーザーと共有フォルダの設定は以下の通り。なお、使用するユーザーは、オンプレAD上に存在するユーザーをEntra Connectで同期しておく必要がある。

  • 使用するユーザー : tuser002
  • 共有タブ : tuser002のみフルコントロール
  • セキュリティタブ : tuser002のみフルコントロール

まず、ローカルアカウントでデバイスにログインしたのち、共有フォルダにアクセスする。当然「アクセスできません」のエラーとなる。

次に、フルコントロールを許可している「tuser002」のアカウントにてログインし、共有フォルダにアクセスする。今度は、エラーとならず共有フォルダにアクセスに成功できた。

以上で、Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせることの設定手順と確認は完了となる。

2025年12月24日水曜日

Windows Timeサービスの時刻同期を正しく設定する手順【Windows 10・Windows Server 2016以降対応】

数年前の記事となるが、Windows Server 2008 R2環境における時刻同期方法について記事にした。

あれからWindows Serverも2012、2012 R2、2016、2019、2022とバージョンアップを重ねてきているので、再度Windows 10及びWindows Server 2016以降における正しい時刻同期の設定方法を調べてみた。

以前の手順では、トリガーサービスの停止や「SpecialPollInterval」のレジストリ値の変更などが必要となっており煩雑となっていた。今回いろいろ調べてみたところ、Windows Server 2016以降ではw32tmのコマンドで設定するだけでよく、前回に比べてシンプルな手順となった。

Windowsの時刻設定

1. Windows Timeサービスが起動していることを確認

まずは、時刻同期をするための前提条件となるWindows Timeサービスの起動設定と状態を確認する。

私の環境で確認したところ、Windows 10では「スタートアップの種類」が「手動」になっておりサービスが起動していなかった。逆に、Windows Server 2016以降では、「自動起動」となっておりサービスも起動しており対処は不要だった。

サービスが起動していない場合は、以下コマンドにて「スタートアップの種類」を「自動起動」への変更と、サービスの起動を行う。

PS C:\> Set-Service -Name W32Time -StartupType Automatic
PS C:\> Start-Service -Name W32Time

Windows Timeサービスの起動状態を確認するには、PowerShellで以下コマンドを実行する。以下状態となっていれば問題なくWindows Timeサービスが起動している。

  • Status : Running
  • StartType : Automatic
PS C:\> Get-Service -Name W32Time | select Name, DisplayName, Status, StartType

Name    DisplayName   Status StartType
----    -----------   ------ ---------
W32Time Windows Time Running Automatic

2. 時刻同期先を「0x8」のフラグを付けて指定する

PowerShell (またはコマンドプロンプト) を管理者として開き、以下のようにコマンドを実行する。コマンドのオプションの意味は以下の通り。

オプション 説明
/config 設定を変更する際に指定。
/update 設定変更を即時に反映。
/manualpeerlist:"<同期先NTPサーバ>,<フラグ>" 同期先のNTPサーバを指定する (フラグについては後述する)。ダブルクォート ("") で囲まないとうまく設定が反映されないので注意。複数の同期先を指定する場合は、空白区切りにて記載する。
/syncfromflags:<同期方式> 手動で同期先を指定する場合は、「MANUAL」を指定する。なお、ドメイン環境においてドメインコントローラと同期する場合は「DOMHIER」を指定する。

以下コマンド実行例となる。「コマンドは正しく完了しました。」と表示されればOK。

PS C:\> w32tm /config /update /manualpeerlist:"ntp.nict.jp,0x8 ntp.jst.mfeed.ad.jp,0x8" /syncfromflags:MANUAL
コマンドは正しく完了しました。

フラグは以下の設定を選択することができる。

設定値 説明
0x1 「SpecialPollInterval」のレジストリ値で設定した秒数にて、一定間隔で同期する方式。
0x8 NTPクライアントモードで同期。RFC1305に準拠した同期。最初の同期は短いタイミングで同期を行い、以降は徐々に同期間隔を長くするという方式。同期間隔は「MinPollInterval」と「MaxPollInterval」のレジストリ値にて設定される。
0x9 NTPクライアントモードで同期。0x1と同様に一定間隔で同期。

Windows Server 2008時代は0x9のフラグを設定することが多かったが、現在は0x8で設定するのが推奨となる。
※理由は後述する「【補足】Windows Timeサービスのフラグに0x9を指定してはいけない理由」を参照いただきたい。

3. 設定確認

一度w32tm /resyncにて手動で同期しておく。その後、問題なく同期されていることをw32tm /query /statusで確認する。最終正常同期時刻が更新されていれば、問題なく時刻同期されている。

PS C:\> w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

PS C:\> w32tm /query /status
閏インジケーター: 0 (警告なし)
階層: 3 (二次参照 - (S)NTP で同期)
精度: -6 (ティックごとに 15.625ms)
ルート遅延: 0.0044629s
ルート分散: 8.2163946s
参照 ID: 0xC0A82117 (ソース IP:  192.168.33.23)
最終正常同期時刻: 2020/08/19 10:43:57 ←★
ソース: 192.168.33.23,0x8
ポーリング間隔: 7 (128s)

【補足】Windows Timeサービスのフラグに0x9を指定してはいけない理由

Windows Timeサービスでは「LargePhaseOffset」というレジストリ値の設定があり、この値で設定した時間よりも時刻のずれが生じた場合、「Spike」というステータスに遷移し時刻同期が停止する。「LargePhaseOffset」はデフォルトで 50000000 (単位は100ナノ秒なので5秒) で設定されている。
※本題ではないが「LargePhaseOffset」の単位が「ミリ秒」という情報もあるが、実機で確認した限りでは「100ナノ秒」が単位としては正しいようだ。

通常は「Spike」の後「Unset」と呼ばれるSTEPモードで時刻同期を行うステータスに遷移するが、フラグに0x9が指定されている場合 (SpecialPollIntervalで設定された一定の間隔による時刻同期が実行されている場合) は「Unset」に遷移せず、二度と時刻同期に成功しなくなるという問題が存在する。詳細は以下のMicrosoftのKBに記載がある。

なお、Windows TimeサービスのSpikeへ遷移する動作については、以下のMicrosoftのブログの記事にて非常に詳細に説明されている。

この問題はフラグに0x8を設定した場合は発生しないため、時刻同期のフラグは0x9ではなく0x8で設定することが推奨となる。

参考

変更履歴

  • 2020/9/5 新規作成
  • 2025/12/24 手動での同期手順を追加
2025年12月19日金曜日

Windows Hello for Business (WHfB) をクラウド信頼で認証するよう構成する手順

前回はEntra Connectを使って、Windowsデバイスをハイブリッド参加させる手順を記載した。

今回は、Windows Hello for Business (WHfB) をクラウド信頼で認証するよう構成する手順を記載する。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築しているため、Windows Helloは顔認証は使えない。したがって、PINの認証ができることまでを確認する。

  • Entra Connect : 2.5.190.0
  • オンプレAD : Windows Server 2022
  • デバイス : Windows 11 24H2 ※仮想マシン

前提として、Entraハイブリッド参加の構成が完了している必要がある。設定できていない場合は、以下手順を参考に設定を行うこと。

クラウド信頼とEntra Kerberosについて

WHfBは認証方式に「キー信頼」、「証明書信頼」、「クラウド信頼」(「クラウドトラスト」だったり「クラウドKerberos信頼」と表現されることもある)の3つの方式が存在する。

今回は後者の「クラウド信頼」で設定する。クラウド信頼には、Entra Kerberosの仕組みを使用する。そもそも、クラウド信頼認証とは何か、については、Microsoftの以下サイトに記載の図が比較的わかりやすい。

ざっくりな説明とはなるが、Windows HelloにてEntra IDに認証を求め、その認証結果をオンプレ側のADに連携することで、クラウドとオンプレ環境のどちらに対してもSSOができるようになる仕組みとなる。以下に図示する。

Entra Kerberosの設定は、基本的には以下のMicrosoftの手順に従って実行する。いろんなサイトにコマンドは乗っているが、以下のサイトの情報が事前事後の情報確認手順が含まれており確実な手順だと思ったので採用した。

Entra Kerberosの設定手順

インターネットからPowerShellのモジュールのインストールをするため、インターネットに接続できる環境で実行すること。コマンド実行は、ドメインに参加している端末でもサーバーでもどちらでも構わない。私は、Entra Connectを導入しているWindows Server 2022にて実行した。

1. PowerShellの実行ポリシーをBypassに変更

PowerShellの実行ポリシーをBypassに変更して、コマンド実行ができるようにする。

Set-ExecutionPolicy Bypass -Scope Process -Force

2. モジュールをインストール

AzureADHybridAuthenticationManagementのモジュールをインストールする。途中「信頼されていないリポジトリ」の確認がされる場合があるが、「y」を入力してインストールする。

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-PackageProvider -Name NuGet -Force
if (@(Get-PSRepository | ? {$_.Name -eq "PSGallery"}).Count -eq 0){
    Register-PSRepository -DefaultSet-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
}
Install-Module -Name PowerShellGet -Force
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

3. 設定前確認

設定変更前に、現在の設定を確認する。コマンド実行時に認証画面が表示されるので、以下に記載の権限を持つアカウントを指定すること。

$domain = "<ドメイン名>"

$domainCred = Get-Credential
※認証画面が表示されるのでオンプレの管理者(Domain Admins)を指定する。

$cloudUserName = "<Entraのグローバル管理者>"

Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName
※認証画面が表示されるのでEntraのグローバル管理者を指定する。

実際の実行結果は以下の通り。すべて空白で実行結果が表示されることを確認する。

PS C:\Windows\system32> Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName

Id                 :
UserAccount        :
ComputerAccount    :
DisplayName        :
DomainDnsName      :
KeyVersion         :
KeyUpdatedOn       :
KeyUpdatedFrom     :
CloudDisplayName   :
CloudDomainDnsName :
CloudId            :
CloudKeyVersion    :
CloudKeyUpdatedOn  :
CloudTrustDisplay  :

4. Entra Kerberos信頼を設定

事前確認でコマンドを問題なく実行できたら、いよいよEntra Kerberos信頼を設定する。特にエラーがなければ、数秒でコマンドが正常終了する(特に実行結果は表示されない)。

このコマンドを実行すると、AzureADKerberosのコンピューターアカウントがDomain ControllersのCNに作成される。

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName -DomainCredential $domainCred -SetupCloudTrust

5. 設定後確認

設定後の確認のため、再度設定値を確認する。

Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName

実行結果は以下の通り。事前確認の際は空白だったが、Entra Kerberosの設定後は値が表示されることが確認できる。

PS C:\Windows\system32> Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName

Id                 : 18631
UserAccount        : CN=krbtgt_AzureAD,OU=MyUsers,DC=test,DC=com
ComputerAccount    : CN=AzureADKerberos,OU=Domain Controllers,DC=test,DC=com
DisplayName        : krbtgt_18631
DomainDnsName      : test.com
KeyVersion         : 17153
KeyUpdatedOn       : 2025/12/15 10:41:30
KeyUpdatedFrom     : ad001.test.com
CloudDisplayName   : krbtgt_18631
CloudDomainDnsName : test.com
CloudId            : 18631
CloudKeyVersion    : 17153
CloudKeyUpdatedOn  : 2025/12/15 10:41:30
CloudTrustDisplay  : Microsoft.AzureAD.Kdc.Service.TrustDisplay

GUIでも確認しておこう。「Active Directory ユーザーとコンピューター」を開きDomain ControllersのCNを選択する。ここにAzureADKerberosのコンピューターアカウントが登録されている。

6. Entra Connectの同期を待つ

設定後、AzureADKerberosのコンピューターアカウント情報をクラウドに同期させる必要があることから、Entra Connectの同期を待つ。通常30分毎に同期となるが、コマンドで手動同期もできる。せっかちな人は手動で同期をしておこう。

Start-ADSyncSyncCycle -PolicyType Delta

以上で、Entra Kerberosの設定は完了となる。

Windows Hello for Business (WHfB) 設定手順

続けてWHfBの設定を行う。

1. GPOにてWHfBのグループポリシーを設定

設定はGPOでもIntuneでも可能だが、今回はGPOで行う。

「グループポリシーの管理」でGPOを作成し、以下グループポリシーの設定を行う。

  • 設定場所:コンピューターの構成 > ポリシー > 管理用テンプレート > Windowsコンポーネント > Windows Hello for Business
設定 状態 備考
Windows Hello for Business の使用 有効
オンプレミス認証にクラウドトラストを使用する 有効
ハードウェアのセキュリティ デバイスを使用する 有効 必須ではなく推奨項目。

2. ポリシーを適用

Windows 11の端末にログインし、以下コマンドでグループポリシーの適用を行う。適用後、端末を再起動しよう。

gpupdate /force

3. ログイン時に顔認証やPINの登録画面に遷移することを確認

再度ログインした際に、顔認証やPINの登録画面に自動的に遷移すれば成功となる。私の検証環境では、Windows 11は仮想マシンで作成しているので、顔認証は求められず、PINの設定が求められるようになった。

もし、顔認証やPINの登録画面に遷移しない場合は、イベントビューアーにて「アプリケーションとサービスログ > Microsoft > Windows > User Device Registration > Admin」でエラーや警告メッセージが出てないか確認しよう。

特に、以下のような「Windows Hello for Business のプロビジョニング」に関するメッセージがログイン時に出力されているはず。

いくつかパターンがあるが、以下★箇所が「Yes」になっていれば、設定としては問題ないはず。しばらく時間を置くと解決したりする。

Windows Hello for Business のプロビジョニングが起動されます。 
デバイスは Microsoft Entra 参加済み (またはハイブリッド参加済み): Yes ★
ユーザーが Microsoft Entra 資格情報でログオンしました: Yes 
Windows Hello for Business ポリシーが有効になっています: Yes ★
Windows Hello for Business のログオン後のプロビジョニングが有効になっています: Yes 
このデバイスは Windows Hello for Business のハードウェア要件に合致しています: Yes ★
ユーザーがリモート デスクトップ経由でコンピューターに接続されていません: Yes 
オンプレミス認証ポリシーのユーザー証明書が有効になっています: No 
マシンは none ポリシーに準拠しています。 
オンプレミスの認証ポリシーに対するクラウドの信頼が有効になっています: Yes ★
ユーザー アカウントに Cloud to OnPrem TGT があります: Yes 
詳細については、https://go.microsoft.com/fwlink/?linkid=832647 を参照してください。

逆に言えば、1日放置しても解消されない場合は、何らかの前提条件が満たされていない可能性がある。その場合は、上記の★箇所でYesとなっていない箇所の前提が満たされているかを確認しよう。
※例えば、「ハイブリッド参加済み」の確認は、Entra管理センターやdsregcmd /statusコマンドで確認することができる。

以下はdsregcmd /statusの実行結果例となる。★箇所が「YES」であることを確認する。

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES ★
          EnterpriseJoined : NO
              DomainJoined : YES ★

以上で、Windows Hello for Business (WHfB) をクラウド信頼で構成する手順は完了となる。

参考

2025年11月26日水曜日

Entra Connectを用いてWindows 11端末をハイブリッド参加させる手順

自宅環境ではEntra Connect (旧Azure AD Connect)を使って、オンプレADのユーザー情報をEntra IDへ同期する構成としている。今まではユーザー情報を同期させて、そのユーザーでM365環境にログインするといった用途ぐらいにしか使用しておらず、「ただ同期するだけ」の状態だった。

ただし、Entra Connectを使うと、オンプレのドメインに所属しつつ、Entra環境にも参加する「Entraハイブリッド参加 (Entra Hybrid Join)」という構成にすることができる。これをすると、オンプレADにログインすれば、M365へSSOできたり、M365の機能と連携して、デバイスのセキュリティ強化を行うことができる。

本記事では、Entra Connectを用いてWindows 11端末をハイブリッド参加させる手順を記載する。

環境

  • Entra Connect : 2.5.79.0
  • オンプレAD : Windows Server 2016
  • デバイス : Windows 11 24H2

Entraハイブリッド参加手順

1. Entra Connectにて「ハイブリッド参加の構成」の設定を行う

Entra Connectで「ハイブリッド参加の構成」が未実施の場合に作業を実施する。
※私の環境はEntra Connectをかなり古いバージョンの頃に初期構築したこともあり、本作業が未実施だった。

Entra Connectがインストールされているサーバーにログインし、Entra Connectの画面を開く。

「デバイスオプションの構成」を開く。

「Microsoft Entra IDに接続する」は、グローバル管理者のユーザー、パスワードを入力する。

「デバイスオプション」にて「ハイブリッドMicrosoft Entra ID参加の構成」を選択する。

「デバイスのオペレーティングシステム」では、「Windows 10以降のドメインに参加しているデバイス。」を選択する。
※さすがにWindows 10以前のOS (例:Windows 8など)を使っている環境はもう存在しないと思われるため。

「SCPの構成」では、以下を設定する。

  • 認証サービス : Microsoft Entra ID
  • エンタープライズ管理者 : ドメインのエンタープライズ管理者権限のユーザー、パスワードを入力

以上でハイブリッド構成が開始され、最後に「構成が完了しました」と表示されれば問題ない。

2. グループポリシーのテンプレートの最新化

GPOを設定するのだが、私の環境はWindows Server 2016という古い環境 (2026年中に更改予定)のため、設定したいポリシーがデフォルトでは存在しない

その場合は、以下URLから最新のポリシーテンプレートファイルをダウンロードし適用しておくこと。

https://www.microsoft.com/en-us/download/details.aspx?id=108394
Administrative Templates (admx) for Windows 11 Sep 2025 Update.msi

上記msiファイルをインストールすると、C:\Program Files (x86)\Microsoft Group Policy\Windows 11 Sep 2025 Update (25H2)\PolicyDefinitionsにファイルが展開されるので、\\<ドメイン名>\SYSVOL\<ドメイン名>\Policies\PolicyDefinitionsに以下ファイルをコピーする。

  • *.admx
  • en-USフォルダ
  • ja-JPフォルダ

3. GPOにてデバイスのEntra参加を有効化

以下GPOを作成し、Entraハイブリッド参加対象のコンピューターアカウントが登録されているOUにリンクさせる。

  • コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → デバイス登録
    • ドメインに参加しているコンピューターをデバイスとして登録する : 有効
  • コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → MDM
    • 既定のAzure AD資格情報を使用して自動のMDM登録を有効にします : 有効

4. デバイスにてハイブリッド参加

グループポリシーの適用のため、デバイスを再起動しておく。

ハイブリッド参加の確認は、dsregcmdコマンドを用いて実施する。以下★箇所がYESになっていれば問題ない。なお、EnterpriseJoinedは「オンプレAD FSによる参加」の状態を示す項目となり、ハイブリッド参加の場合は、NOのままで問題ない。

PS C:\> dsregcmd /status

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES ★
          EnterpriseJoined : NO
              DomainJoined : YES ★
                DomainName : TEST
           Virtual Desktop : NOT SET
               Device Name : DESKTOP-E05C3GD.test.local

もし登録されていない場合は、以下コマンドで登録を試みる。エラーが出る場合は、トラブルシュートが必要となるが、内容によるのでここでは割愛する。

PS C:\> dsregcmd /debug /join

最後に、Entra管理センターでも、対象のデバイスの状況を確認する。Entra管理センターの「デバイス」>「すべてのデバイス」にて対象のデバイスを確認し、「参加の種類」が「Microsoft Entra hybrid joined」となっていればOKとなる。

参考

2024年9月14日土曜日

Oracle VM VirtualBox (Windows版)&Guest Additionsインストール手順 (6.1、7.1対応)

WindowsやMACのPCにて手軽にLinuxなどの検証を行いたい場合がある。そのような場合には、PCにインストール可能なホスト側仮想化ソフトウェアを利用し、Linuxの仮想マシンを構築することができる。

ホスト型仮想化ソフトウェアとして利用可能なものは、以下のようなものがある。

製品名 プラットフォーム 説明
Oracle VM VirtualBox Windows, macOS, Linuxなど 様々なプラットフォームで動作し、無償であるにも関わらずかなり柔軟に仮想マシンの設定が可能。また、Vagrantを使えば構築の自動化も可能。
VMware Workstation Player Windows vSphereでおなじみのVMwareのホスト型仮想化ソフトウェア。
VMware Fusion Player macOS macOSを所有していないため評価不可。

今回は、「Oracle VM VirtualBox」をWindows環境にインストールし、VirtualBox上にWindows Server 2019とRHEL 8.4をインストールする手順を記載する。

環境

VirtualBoxをインストールする手ごろなWindowsクライアントがすぐに用意できなかったため、たまたまインストールしていたWindows Server 2022 PreviewにVirtualBoxをインストールしたが、他Windows環境でも手順に差異はないだろう。

また、VirtualBoxは6.1.24と7.1.0の二種類でインストールを確認しているが、本記事の画面は6.1.24のものを記載する。

  • Windows Server 2022 Preview
  • Oracle VM VirtualBox 6.1.24 / 7.1.0

なお、私の環境はESXi上のOSにVirtualBoxをインストールする構成となる。このような構成の場合は、ESXiのCPUの設定にて「ハードウェア アシストによる仮想化をゲスト OS に公開」を有効にすること。

Oracle VM VirtualBoxインストール手順

1. Oracle VM VirtualBoxのダウンロード

VirtualBox本家とOracle 日本のいずれかからVirtualBoxのダウンロードができる。Oracle 日本でダウンロードできるバージョンは少し古くなってしまうことから、特に理由がなければ本家からダウンロードすれば問題ない

また、同じサイトでダウンロードできるOracle VM VirtualBox Extension Packもダウンロードしておく。Extension Packをインストールすることで、USBコントローラやディスク暗号化などの拡張機能を利用することができる。

2. (VirtualBox 7以降)Pythonのインストール

VirtualBoxの前提として、Pythonとpywin32のインストールが必要となる。Pythonは以下からダウンロードしてインストールする。Pythonは管理者として実行してインストールすること。

Pythonインストール後、PowerShellを開き、pywin32をインストールする。

pip install pywin32 --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host pypi.org

3. VirtualBox本体のインストール

ダウンロードしたexeファイルをダブルクリックすれば、インストールウィザードを起動する。基本的には、すべてを「次へ」を押して進めばよい。

インストールが開始されると、「このデバイスをインストールしますか?」と表示されるので、「インストール」を選んでおく。

4. Extension Packのインストール

VitualBoxをインストールしたのち、Extension Packのファイル (vbox-extpack) をダブルクリックすることでインストールを開始することができる。

ライセンス規約が表示されるので、一番下までスクロールしたのち、「同意します」を選択する。

インストールが成功すると、以下のような「拡張機能パッケージ Oracle VM Virtual Box Extension Pack のインストールに成功しました。」のメッセージが表示される。
※完了メッセージが表示されない場合もある模様。

VirtualBox上にWindows Server 2019をインストール

1. 仮想マシンを作成

「新規」ボタンをクリックすることで、仮想マシンの作成ウィザードが表示される。以下のように設定を行い仮想マシンを作成する。

設定値 説明
名前 任意で指定。今回はwin2019とする。
タイプ Microsoft Windows
バージョン Windows 2019 (64-bit)
メモリーサイズ 任意で指定。デフォルトは2048MB
ハードディスク 「仮想ハードディスクを作成する」を選択
ハードディスクのファイルタイプ デフォルトの「VDI (VirtualBox Disk Image)」を選択する。なお、「VHD」 (Hyper-Vで使用) や「VMDK」 (ESXiで使用) も選択可能。
物理ハードディスクにあるストレージ 可変サイズと固定サイズが選択できる。いわゆるシックプロビジョニングとシンプロビジョニングに対応する。「固定」の場合はディスク作成時にすべての容量が割り当てられてしまい効率が悪いので、使用した分だけディスクサイズを割り当てていく「可変」を選択する。
ファイルの場所とサイズ 任意で指定。デフォルトは50GB

2. OSをインストールメディアから起動

作成した仮想マシンの「設定」を開き、「ストレージ」→「光学ドライブ」を選択する。CDマークを選択し、「ディスクファイルを選択」を選択し、Windows Server 2019のISOイメージを選択する。

仮想マシンの起動モードは以下3種類ある。VirtualBox用語となっており、初見では動作の違いが判らないため、それぞれの違いを以下に記載する。

起動モード 説明
通常起動 起動時に仮想マシンのコンソールが開く。コンソールを閉じる際は、「状態保存 (いわゆるサスペンド)」または「仮想マシンの停止」のみ選択が可能。
ヘッドレス起動 起動時に仮想マシンのコンソールが開かない。起動後に「表示」を選択することで仮想マシンのコンソールを開くことができる。コンソールを閉じる際に「バックグラウンドで動作を継続」を選択することで、仮想マシンのコンソールを閉じても起動状態を継続させることが可能。
デタッチモード起動 起動時に仮想マシンのコンソールが開く。それ以外は「ヘッドレス起動」と同様となり、「バックグラウンドで動作を継続」を選択可能。

通常は、仮想マシンのバックグラウンドでの起動が選択可能な、「デタッチモード起動」を選択しておけば問題ないだろう。

3. OSインストール

Windows Serverのインストールメディアを読み込むので、Enterを押しインストールを開始させる。インストール手順自体は特に通常と変更は不要であるため割愛する。

インストール完了後はインストールメディアは不要となることから、「デバイス」→「光学ドライブ」→「仮想ドライブからディスクを除去」を選択しインストールメディアを取り出しておこう。

4. Guest Additionsをインストール

VirtualBoxでは「Guest Additions」と呼ばれる、ESXiでいうところのVMware Toolsと同様の機能を待つエージェントのインストールが推奨される。

「デバイス」→「Guest Additions CDイメージの挿入…」を選択する。

すると、仮想CDドライブに「VirtualBox Guest Additions」というメディアがマウントされるので、これをダブルクリックすることでインストールウィザードが開始される。インストールウィザードでは、基本的には、すべてを「次へ」を押して進めばよい。

インストールが開始されると、「このデバイスをインストールしますか?」と表示されるので、「インストール」を選んでおく。

最後に再起動を求められるため、再起動して完了となる。

Guest Additionsが正常にインストールされていることの確認は、「仮想マシン」→「セッション情報」→「ランタイム情報」から確認することができる。


VirtualBox上にRHEL 8.4をインストール

1. 仮想マシンを作成~OSインストール

Windows Serverと同様の手順となるため割愛する。

2. Guest Additionsをインストール

RHELに対してGuest Additionsをインストールする場合は、GUIではなくCLIによるインストールを行う。

まず、前提パッケージとして以下が必要となる。

  • kernel-headers
  • kernel-devel
  • tar
  • bzip2
  • gcc
  • make
  • perl
  • elfutils-libelf-devel

上記パッケージをdnfまたはyumを使ってインストールを行うのだが、インターネット経由でインストールする場合、ネットワーク設定やサブスクリプション登録など手順が多くなる。そこで、今回はRHELのOSインストールメディアに含まれるパッケージを用いてインストールを行う。

まず、OSインストールメディアのパッケージが含まれるディレクトリをリポジトリとして登録する。

# cat << EOF > /etc/yum.repos.d/dvd-base.repo
[dvd-base]
baseurl=file:///media/BaseOS/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
EOF

# cat << EOF > /etc/yum.repos.d/dvd-appstream.repo
[dvd-appstream]
baseurl=file:///media/AppStream/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
EOF

次にOSインストールメディアをマウントし、dnfにてパッケージのインストールを行う。

# mount /dev/cdrom /media/
mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.
# dnf install kernel-headers kernel-devel -y
# dnf install tar bzip2 gcc make perl elfutils-libelf-devel -y
# eject /dev/sr0

次に、OSインストールメディアを「Guest Additions」のメディアに変更する。Windows Serverの手順と同様、「デバイス」→「Guest Additions CDイメージの挿入…」を選択したのち、VBoxLinuxAdditions.runを実行すると、自動的にGuest Additionsがインストールされる。

# mount /dev/cdrom /media/
mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.

# /media/VBoxLinuxAdditions.run
Verifying archive integrity... All good.
Uncompressing VirtualBox 6.1.24 Guest Additions for Linux........
VirtualBox Guest Additions installer
Removing installed version 6.1.24 of VirtualBox Guest Additions...
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel
modules.  This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel
4.18.0-305.el8.x86_64.
ValueError: File context for /opt/VBoxGuestAdditions-6.1.24/other/mount.vboxsf already defined

最後に再起動をしておく。

# reboot

再起動後、Guest Additionsのサービスvboxaddの正常起動を確認できれば完了となる。

# systemctl status vboxadd
● vboxadd.service
     Loaded: loaded (/opt/VBoxGuestAdditions-7.1.0/init/vboxadd; enabled; preset: disabled)
     Active: active (exited) since Fri 2024-09-13 22:13:12 JST; 56s ago
    Process: 43447 ExecStart=/opt/VBoxGuestAdditions-7.1.0/init/vboxadd start (code=exited, status=0/SUCCESS)
   Main PID: 43447 (code=exited, status=0/SUCCESS)
        CPU: 483ms

 9月 13 22:13:12 localhost.localdomain systemd[1]: Starting vboxadd.service...
 9月 13 22:13:12 localhost.localdomain vboxadd[43447]: VirtualBox Guest Additions: Starting.
 9月 13 22:13:12 localhost.localdomain systemd[1]: Finished vboxadd.service.

更新履歴

  • 2021/8/14 新規作成
  • 2024/9/14 VirtualBox 7.1.0のインストール結果を反映

人気の投稿