2026年1月28日水曜日

Proxmoxバージョンアップ手順 (8.4→9.1)

Proxmoxのサポートポリシーは、メジャーバージョンのリリース後、おおよそ3年となる。

Proxmoxは現在バージョン8と9がサポート期間となっているが、バージョン8については、2026年8月がEOLとなっており、バージョンアップ対応が必要となる。

本記事では、Proxmoxをバージョン8からバージョン9にバージョンアップする手順を記載する。

環境

Proxmoxのバージョンは以下の通り。バージョンアップ作業では再起動が必要であるため、仮想マシンは事前に停止させておくこと。

  • バージョンアップ前Proxmox: 8.4.14
  • バージョンアップ後Proxmox: 9.1.4

バージョンアップ手順

1. 最新までアップデートを実施

まずは、現在のProxmoxを最新化しておく。

apt update
apt dist-upgrade

2. チェックスクリプトpve8to9実行

バージョンアップの各種チェックを行うスクリプトとしてpve8to9が用意されているのでこちらを実行する。

最後にサマリーが表示されるが、通常はいくつかのWARNINGSとFAILURESが出力される。必ずしもすべて解消しなければならないものではないので、以降の手順で私が遭遇したエラーに対する対応を記載する。

# pve8to9

~(中略)~

= SUMMARY =

TOTAL:    58
PASSED:   38
SKIPPED:  13
WARNINGS: 4
FAILURES: 1

3. (必要な場合) GRUBの設定修正

以下エラーは、「EFI の「リムーバブルメディア用ブートローダー」が存在するが、今後 GRUB の更新対象にならない可能性がある」ことに対する警告となる。

WARN: Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it!
Run the following command:
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
Then reinstall GRUB with 'apt install --reinstall grub-efi-amd64'

対処としては、メッセージに記載の通りのコマンドを実行して修正するだけでよい。

echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
apt install --reinstall grub-efi-amd64

4. (必要な場合) systemd-bootパッケージの削除

以下エラーは、「Proxmox の想定ブートローダー(GRUB)とは別系統の systemd-boot が同居しており、 今後のブートローダー更新や OS アップグレードで問題を起こす構成になっている」ことに対する警告となる。

FAIL: systemd-boot meta-package installed. This will cause problems on upgrades of other boot-related packages. 
Remove 'systemd-boot' See https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#sd-boot-warning for more information.

対処としては、systemd-bootパッケージをアンインストールする。

apt remove systemd-boot

5. リポジトリの修正

Debian 12 (Bookworm)からDebian 13 (Trixie)へリポジトリの変更を行う。

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

また、Debian 13 (Trixie)用のpve-no-subscriptionリポジトリの追加を行う。

cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

6. チェックスクリプトpve8to9再実行

バージョンアップの直前に再度チェックスクリプトを実行しておく。私の場合は1件WARNINGSを残しているが、バージョンアップ作業には影響がなさそうなので無視して進めることにする。

# pve8to9

~(中略)~

= SUMMARY =

TOTAL:    57
PASSED:   43
SKIPPED:  9
WARNINGS: 1
FAILURES: 0

7. バージョンアップ

バージョンアップを実行する。多数のパッケージダウンロードとインストールが発生するため、完了までは15分程度要した。

apt update
apt dist-upgrade

途中、入力を求められる場面があるため、以下の通り進める。

Configuration file '/etc/issue'

Configuration file '/etc/issue'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** issue (Y/I/N/O/D/Z) [default=N] ? ★そのままエンター。

Configuring libc6:amd64

There are services installed on your system which need to be restarted 
when certain libraries, such as libpam, libc, and libssl, are upgraded. 
Since these restarts may cause interruptions of service for the system, 
you will normally be prompted on each upgrade for the list of services you wish to restart.  
You can choose this option to avoid being prompted; instead, 
all necessary restarts will be done for you automatically so you can avoid being asked questions on each library upgrade.                                                               
                                                                                                                                            
Restart services during package upgrades without asking?                                                                                    
                                                                                                                                            
<Yes>    <No>
↑★「Yes」を選択。

/usr/share/chrony/chrony.conf

lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu Modified configuration file tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x A new version (/usr/share/chrony/chrony.conf) of configuration file /etc/chrony/chrony.conf is available, but the version installed   x
x currently has been locally modified.                                                                                                  x
x                                                                                                                                       x
x What do you want to do about modified configuration file chrony.conf?                                                                 x
x                                                                                                                                       x
x                                         install the package maintainer's version                                                      x
x                                         keep the local version currently installed                                                    x
x                                         show the differences between the versions                                                     x
x                                         show a side-by-side difference between the versions                                           x
x                                         show a 3-way difference between available versions                                            x
x                                         do a 3-way merge between available versions                                                   x
x                                         start a new shell to examine the situation                                                    x
x                                                                                                                                       x
x                                                                                                                                       x
x                                                                <Ok>                                                                   x
x                                                                                                                                       x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

↑★「keep the local version currently installed」を選んでエンター。

Configuration file '/etc/lvm/lvm.conf'

 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** lvm.conf (Y/I/N/O/D/Z) [default=N] ? Y ★「Y」を入力しエンター。

8. 再起動

Proxmoxを再起動する。

reboot

9. aptリポジトリのフォーマット最新化

最後にaptのリポジトリ設定を新しいフォーマットに変換するコマンドを実行しておく。

apt modernize-sources

参考

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月27日土曜日

Linuxでオレオレ認証局作ってオレオレ証明書作る手順

サーバー証明書はきちんとしたものを用意しようとするとお金と手間暇がかかるので、検証用としては不向きである。以前のRHEL 7以前は、CAという証明書作成用のスクリプトがあって、それを用いた手順は過去記事にしてある。

しかし、RHEL 8以降は同梱されなくなったため、今回はLinuxのopensslコマンドを用いて、オレオレ認証局作ってオレオレ証明書作る手順を記載する。

環境

環境は以下の通り。OpenSSLだけあれば認証局と証明書は作成できる。

  • OS : AlmaLinux release 9.4
  • OpenSSL : OpenSSL 3.0.7

オレオレ認証局(CA)作成手順

1. CA用のディレクトリを作成

CA用のディレクトリを以下構成で任意の場所に作成する。

pki/
├─ ca/
│  ├─ private/
│  ├─ certs/
│  ├─ newcerts/
│  ├─ index.txt
│  ├─ serial
│  └─ openssl.cnf
└─ server/
mkdir pki
cd pki/
mkdir -p ca/{private,certs,newcerts} server

CAが署名する際に必要となるファイルとして、index.txtserialのファイルを事前に作成しておく。index.txtは空のファイルを、serialは任意の数字1行を記載したファイルを作成する。

touch ca/index.txt
echo 1000 > ca/serial

2. 設定ファイルopenssl.cnfを作成

openssl.cnfはデフォルトのものをコピーして、必要な個所を書き換える。

cp /etc/pki/tls/openssl.cnf ca/

書き換え箇所は以下の通り。

設定項目 設定値 説明
dir ./ca CA証明書の読み込みパスのベースとなるディレクトリを指定。
certificate $dir/certs/ca.crt CA証明書の保存場所を指定。
private_key $dir/private/ca.key CAの秘密鍵の保存場所を指定。
copy_extensions copy 証明書作成時にCSRに含まれる拡張属性(サブジェクト代替名(SAN)も拡張属性に含まれる)の値を引き継ぐかどうかの設定。copyにすることで引き継ぐよう設定する。
default_days 3650 証明書の有効期限。オレオレ証明書を定期的に更新する必要性はないため、10年に設定する。
extendedKeyUsage serverAuth, clientAuth, codeSigning, emailProtection [ usr_cert ]セクションに追記する。CA署名時にextendedKeyUsage (EKU)の拡張属性を付与させる。
policy policy_anything CA証明書とCSR証明書のサブジェクトの一致、不一致をどこまで許容するかを設定する。policy_anythingにすることで、サブジェクトで設定するCSTOなどが一致しなくても証明書の作成が可能となる。

3. CA用の秘密鍵と証明書を作成

CA用の秘密鍵作成する。アルゴリズムは、楕円曲線デジタル署名アルゴリズム「ECDSA P-256」を用いる。RSA 2048ビットと同程度の暗号強度でありながら、鍵長を短くでき、処理も高速というメリットがある。

openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out ca/private/ca.key
chmod 600 ca/private/ca.key

秘密鍵に対応する証明書を作成する。この証明書がいわゆるCA証明書となり、Windowsであれば、「信頼されたルート証明機関」に登録することで、ブラウザなどで証明書エラーを出なくすることができる。
※Linuxの場合は過去記事を参照。

openssl req -key ca/private/ca.key -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign \
  -subj "/C=JP/ST=Tokyo/O=MyPrivateCA/CN=MyRootCA" -out ca/certs/ca.crt

作成した証明書の内容は以下コマンドで確認できる。

openssl x509 -in ca/certs/ca.crt -text -noout

実行結果例は以下の通り。

# openssl x509 -in ca/certs/ca.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6b:1b:16:0b:64:c0:f1:49:ec:de:d0:e6:bc:3e:c9:95:de:6f:6c:20
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = JP, ST = Tokyo, O = MyPrivateCA, CN = MyRootCA
        Validity
            Not Before: Dec 26 22:55:06 2025 GMT
            Not After : Dec 24 22:55:06 2035 GMT
        Subject: C = JP, ST = Tokyo, O = MyPrivateCA, CN = MyRootCA
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:32:0e:69:35:ef:eb:31:29:25:30:64:63:97:64:
                    68:22:7d:d3:67:4e:21:82:91:9d:45:94:c5:d1:2c:
                    12:e8:0a:dd:50:2e:3d:ee:44:18:9d:69:f8:9c:8e:
                    21:3c:ec:06:bc:36:be:4f:5f:63:e6:04:33:22:55:
                    6c:dd:47:0a:6a
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                7E:68:99:E9:DB:F1:A9:6C:A0:CA:6E:A2:E8:53:AD:22:33:B4:D2:69
            X509v3 Authority Key Identifier:
                7E:68:99:E9:DB:F1:A9:6C:A0:CA:6E:A2:E8:53:AD:22:33:B4:D2:69
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:45:02:21:00:aa:1a:20:c2:e3:37:c7:63:99:97:5a:36:31:
        af:96:84:51:8f:93:46:e6:42:ac:7b:a0:39:5f:c2:ff:85:1a:
        c1:02:20:36:a2:23:1d:85:ff:58:1a:95:f7:e0:0e:29:3a:0b:
        1e:db:bd:e9:78:ff:c7:2b:f9:b5:19:ff:2e:0c:15:4d:32

以上で、CA用の秘密鍵と証明書を作成は完了となる。

オレオレ証明書作成手順

「秘密鍵作成→CSR作成→CAにて署名」の順に対応する。

以下コマンドの証明書ファイル名(filename)、サブジェクト(subj)、サブジェクト代替名(subjectAltName)を適切なものに変更して、上から順に流せばよい。

# 証明書ファイル名
cd ~/pki/
filename="server"

# 秘密鍵作成
openssl genrsa -out server/${filename}.key 2048
chmod 600 server/${filename}.key

# CSR作成
openssl req -new -key server/${filename}.key -out server/${filename}.csr \
  -subj "/C=JP/ST=Tokyo/O=test/CN=example.test.com" \
  -addext "subjectAltName=DNS:example.test.com,IP:192.168.1.1"

# 署名
openssl ca -batch -config ca/openssl.cnf -in server/${filename}.csr -out server/${filename}.crt

# 確認 (*.keyが秘密鍵、*.crtがSSL証明書)
ls -l server/

以上で、Linuxでオレオレ認証局作ってオレオレ証明書作る手順は完了となる。

参考

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 手動での同期手順を追加

人気の投稿