Windows PowerShellのResolve-DnsNameコマンドレットで名前解決を確認する
Windows PowerShellで名前解決を確認するにはResolve-DnsNameコマンドレットを使います。
今までコマンドプロンプトでnslookupで名前解決を確認していましたが、それです。
(図1)Resolve-DnsNameコマンドレットの例
上段：
Resolve-DnsName <相手ホスト名>でIPアドレスが返って来ます
Type AAAAはIPv6で、Type AはIPv4です。
下段：
-Type Aを付けるとIPv4のアドレスだけが返って来ます
簡単です。私にも出来ました(^^)
(図2)OSとPowerShellのバージョン
今回はWindows Server 2016 + PowerShell 5.1で試してみました
今までコマンドプロンプトでnslookupで名前解決を確認していましたが、それです。
(図1)Resolve-DnsNameコマンドレットの例
| 管理者: Windows PowerShell |
PS C:\> Resolve-DnsName www.google.com |Format-Table -A Name Type TTL Section IPAddress ---- ---- --- ------- --------- www.google.com AAAA 63 Answer 2404:6800:4004:813::2004 www.google.com A 63 Answer 142.251.222.36 PS C:\> Resolve-DnsName www.google.com -Type A |Format-Table -A Name Type TTL Section IPAddress ---- ---- --- ------- --------- www.google.com A 57 Answer 216.58.220.132 PS C:\> |
上段：
Resolve-DnsName <相手ホスト名>でIPアドレスが返って来ます
Type AAAAはIPv6で、Type AはIPv4です。
下段：
-Type Aを付けるとIPv4のアドレスだけが返って来ます
簡単です。私にも出来ました(^^)
(図2)OSとPowerShellのバージョン
| 管理者: Windows PowerShell |
PS C:\> Get-ComputerInfo |Select-Object WindowsProductName,OsVersion WindowsProductName OsVersion ------------------ --------- Windows Server 2016 Standard Evaluation 10.0.14393 PS C:\> $PSVersionTable Name Value ---- ----- PSVersion 5.1.14393.5127 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.14393.5127 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 PS C:\> |
Windows PowerShellのGet-NetConnectionProfileでネットワークプロファイルを調べる
WindowsのネットワークプロファイルはNICごとに自動で割り当てられます
そこで現在選択されているネットワークプロファイルをPowerShellで調べてみます。
またそのネットワークプロファイルのWindowsファイアウォールが有効になっているかどうかも確認します。
(図1)ネットワーク接続の画面
「ネットワーク」(イーサネット2)はプライベートネットワークに割り当てられている
「識別されていないネットワーク」(イーサネット3)はパブリックネットワークに割り当てられている
(図2)Windowsファイアウォールの状態
「ネットワーク」(イーサネット2)はプライベートネットワークに割り当てられている
「識別されていないネットワーク」(イーサネット3)はパブリックネットワークに割り当てられている
(どちらもネットワーク接続の画面の表示と同じ)
そしてドメイン/プライベート/パブリックの3つ全てWindowsファイアウォールは有効
(図3)Get-NetConnectionProfileとGet-NetFirewallProfile
Get-NetConnectionProfile でNICごとのネットワークプロファイルがわかります
Get-NetFirewallProfile で各Windowsファイアウォールの有効・無効がわかります
(図4)OSとPowerShellのバージョン
今回はWindows Server 2016 + PowerShell 5.1で試してみました
そこで現在選択されているネットワークプロファイルをPowerShellで調べてみます。
またそのネットワークプロファイルのWindowsファイアウォールが有効になっているかどうかも確認します。
(図1)ネットワーク接続の画面
「ネットワーク」(イーサネット2)はプライベートネットワークに割り当てられている
「識別されていないネットワーク」(イーサネット3)はパブリックネットワークに割り当てられている
(図2)Windowsファイアウォールの状態
「ネットワーク」(イーサネット2)はプライベートネットワークに割り当てられている
「識別されていないネットワーク」(イーサネット3)はパブリックネットワークに割り当てられている
(どちらもネットワーク接続の画面の表示と同じ)
そしてドメイン/プライベート/パブリックの3つ全てWindowsファイアウォールは有効
(図3)Get-NetConnectionProfileとGet-NetFirewallProfile
| 管理者: Windows PowerShell |
PS C:\> Get-NetConnectionProfile |Select-Object InterfaceAlias,Name,IPv4Connectivity,NetworkCategory InterfaceAlias Name IPv4Connectivity NetworkCategory -------------- ---- ---------------- --------------- イーサネット 2 ネットワーク Internet Private イーサネット 3 識別されていないネットワーク NoTraffic Public PS C:\> Get-NetFirewallProfile |Select-Object Name,Enabled Name Enabled ---- ------- Domain True Private True Public True PS C:\> |
Get-NetFirewallProfile で各Windowsファイアウォールの有効・無効がわかります
(図4)OSとPowerShellのバージョン
| 管理者: Windows PowerShell |
PS C:\> Get-ComputerInfo |Select-Object WindowsProductName,OsVersion WindowsProductName OsVersion ------------------ --------- Windows Server 2016 Standard Evaluation 10.0.14393 PS C:\> $PSVersionTable Name Value ---- ----- PSVersion 5.1.14393.5127 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.14393.5127 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 PS C:\> |
Windows PowerShellのSet-ItemPropertyコマンドレットでファイルのタイムスタンプを変更する
とある検証をやろうと思って、Windowsのファイルのタイムスタンプを変更するツールを検索したのですが、今さらながらPowerShellでタイムスタンプを変更するコマンドレットがあることに気付きました。
(図1)PowerShellのSet-ItemPropertyコマンドレットでファイルの更新日時を変更する
最初に「C:\Temp\TEST.txt」の名前、作成日時、更新日時、最終アクセス日時を表示します。
次に「C:\Temp\TEST.txt」の作成日時を"2023/11/01 12:34:56"に変更します。
Set-ItemPropertyコマンドレットの「-name」オプションは。
最後にもう一度「C:\Temp\TEST.txt」の名前、作成日時、更新日時、最終アクセス日時を表示します。(最初のコマンドと同じ)
(図2)更新日時を変更する前後のファイルのプロパティ
(図3)上記はWindows 8.1 + PowerShell 4.0と
(図4)Windows Server 2022 + PowerShell 5.1で試してもどちらも同じ結果でした
(図1)PowerShellのSet-ItemPropertyコマンドレットでファイルの更新日時を変更する
| Windows PowerShell |
PS C:\> Get-ItemProperty C:\Temp\TEST.txt |Select-Object Name,CreationTime,LastWriteTime,LastAccessTime |Format-Table -A Name CreationTime LastWriteTime LastAccessTime ---- ------------ ------------- -------------- TEST.txt 2023/11/26 10:29:39 2023/11/26 10:36:49 2023/11/26 10:39:25 PS C:\> Set-ItemProperty C:\Temp\TEST.txt -name LastWriteTime -value "2023/11/01 12:34:56" PS C:\> PS C:\> Get-ItemProperty C:\Temp\TEST.txt |Select-Object Name,CreationTime,LastWriteTime,LastAccessTime |Format-Table -A Name CreationTime LastWriteTime LastAccessTime ---- ------------ ------------- -------------- TEST.txt 2023/11/26 10:29:39 2023/11/01 12:34:56 2023/11/26 10:39:25 PS C:\> |
最初に「C:\Temp\TEST.txt」の名前、作成日時、更新日時、最終アクセス日時を表示します。
Get-ItemProperty C:\Temp\TEST.txt |Select-Object Name,CreationTime,LastWriteTime,LastAccessTime |Format-Table -A
次に「C:\Temp\TEST.txt」の作成日時を"2023/11/01 12:34:56"に変更します。
Set-ItemProperty C:\Temp\TEST.txt -name LastWriteTime -value "2023/11/01 12:34:56"
Set-ItemPropertyコマンドレットの「-name」オプションは。
CreationTime：作成日時
LastWriteTime：更新日時
LastAccessTime：最終アクセス日時
最後にもう一度「C:\Temp\TEST.txt」の名前、作成日時、更新日時、最終アクセス日時を表示します。(最初のコマンドと同じ)
Get-ItemProperty C:\Temp\TEST.txt |Select-Object Name,CreationTime,LastWriteTime,LastAccessTime |Format-Table -A
(図2)更新日時を変更する前後のファイルのプロパティ
(図3)上記はWindows 8.1 + PowerShell 4.0と
| Windows PowerShell |
PS C:\> #Windows製品名 PS C:\> (Get-WmiObject -class Win32_OperatingSystem).Caption Microsoft Windows 8.1 Enterprise PS C:\> #PowerShellバージョン PS C:\> $PSVersionTable Name Value ---- ----- PSVersion 4.0 WSManStackVersion 3.0 SerializationVersion 1.1.0.1 CLRVersion 4.0.30319.42000 BuildVersion 6.3.9600.20719 PSCompatibleVersions {1.0, 2.0, 3.0, 4.0} PSRemotingProtocolVersion 2.2 PS C:\> |
(図4)Windows Server 2022 + PowerShell 5.1で試してもどちらも同じ結果でした
| Windows PowerShell |
PS C:\> #Windows製品名 PS C:\> (Get-WmiObject -class Win32_OperatingSystem).Caption Microsoft Windows Server 2022 Standard Evaluation PS C:\> #PowerShellバージョン PS C:\> $PSVersionTable Name Value ---- ----- PSVersion 5.1.20348.859 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.20348.859 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 PS C:\> |
Windows Serverバックアップでローカルディスクに保存した時のフォルダ名
Windows Serverバックアップでバックアップを実行した時、保存先に指定したドライブに作成されるフォルダについてです。
ここでは以下の通りとします。
・OSはWindows Server 2022
・バックアップ対象はCドライブ、ベアメタル回復、システム状態
・バックアップ保存先はEドライブ
・バックアップ方法はwbadmin start backupコマンド
保存先のボリュームには「E:\WindowsImageBackup\<コンピュータ名>」のフォルダが作成され、その下に実行した日時のフォルダが作成されます。
その中にはバックアップデータがvhdxファイルやxmlファイルの形式で保存されます。
こんな感じです。(WIN2022がコンピュータ名)
上図はこのコマンドを2回実行した結果です。
1回目のバックアップを実行した時にE:\WindowsImageBackup\WIN2022の下に作成されたフォルダ名は「Backup 2023-08-19 060124」でした。
2回目のバックアップを実行するとフォルダ名は「Backup 2023-08-19 081731」に変わりました。
wbadmin get versionsでバックアップの履歴を見てみると
1回目が2023/08/19 15:01 JST開始・・・UTCでは2023/08/19 06:01開始
2回目が2023/08/19 17:17 JST開始・・・UTCでは2023/08/19 08:17開始
このフォルダ名はバックアップ開始時点の「年-月-日 時分秒」のUTCなんですね。
(この図は2回目のバックアップ実行後のバックアップ保存先です)
1回目のバックアップ実行後と2回目のバックアップ実行後のバックアップ保存先のVHDXファイルを比較したのが下表です。
今回の場合、バックアップを2回実行してもVHDXファイルの名前や数は変わりませんでした。
しかし2回目のバックアップを実行すると各VHDXファイルはタイムスタンプが更新され、1つ目のVHDXファイルはサイズが少し大きくなっていました。
(上段：バックアップ1回目実行後のVHDXファイル、下段：2回目実行後のVHDXファイル)
とりあえずこの記事はここまで。
ここでは以下の通りとします。
・OSはWindows Server 2022
・バックアップ対象はCドライブ、ベアメタル回復、システム状態
・バックアップ保存先はEドライブ
・バックアップ方法はwbadmin start backupコマンド
保存先のボリュームには「E:\WindowsImageBackup\<コンピュータ名>」のフォルダが作成され、その下に実行した日時のフォルダが作成されます。
その中にはバックアップデータがvhdxファイルやxmlファイルの形式で保存されます。
こんな感じです。(WIN2022がコンピュータ名)
上図はこのコマンドを2回実行した結果です。
| C:\Windows\sysrem32\cmd.exe |
wbadmin start backup -backupTarget:E: -include:C: -allCritical -systemState -vssFull -quiet |
1回目のバックアップを実行した時にE:\WindowsImageBackup\WIN2022の下に作成されたフォルダ名は「Backup 2023-08-19 060124」でした。
| C:\Windows\sysrem32\cmd.exe |
E:\WindowsImageBackup>dir /s ドライブ E のボリューム ラベルは Backup1 です ボリューム シリアル番号は 003A-6227 です E:\WindowsImageBackup のディレクトリ 2023/08/19 15:01 <DIR> . 2023/08/19 15:12 <DIR> WIN2022 0 個のファイル 0 バイト E:\WindowsImageBackup\WIN2022 のディレクトリ 2023/08/19 15:12 <DIR> . 2023/08/19 15:01 <DIR> .. 2023/08/19 15:11 <DIR> Backup 2023-08-19 060124 2023/08/19 15:11 <DIR> Catalog 2023/08/19 15:12 <DIR> Logs 2023/08/19 15:01 16 MediaId 2023/08/19 15:11 <DIR> SPPMetadataCache 1 個のファイル 16 バイト ： ： |
2回目のバックアップを実行するとフォルダ名は「Backup 2023-08-19 081731」に変わりました。
| C:\Windows\sysrem32\cmd.exe |
E:\WindowsImageBackup>dir /s ドライブ E のボリューム ラベルは Backup1 です ボリューム シリアル番号は 003A-6227 です E:\WindowsImageBackup のディレクトリ 2023/08/19 15:01 <DIR> . 2023/08/19 17:18 <DIR> WIN2022 0 個のファイル 0 バイト E:\WindowsImageBackup\WIN2022 のディレクトリ 2023/08/19 17:18 <DIR> . 2023/08/19 15:01 <DIR> .. 2023/08/19 17:28 <DIR> Backup 2023-08-19 081731 2023/08/19 17:28 <DIR> Catalog 2023/08/19 17:28 <DIR> Logs 2023/08/19 15:01 16 MediaId 2023/08/19 15:11 <DIR> SPPMetadataCache 1 個のファイル 16 バイト ： ： |
wbadmin get versionsでバックアップの履歴を見てみると
1回目が2023/08/19 15:01 JST開始・・・UTCでは2023/08/19 06:01開始
2回目が2023/08/19 17:17 JST開始・・・UTCでは2023/08/19 08:17開始
| C:\Windows\sysrem32\cmd.exe |
C:\>wbadmin get versions wbadmin 1.0 - バックアップ コマンドライン ツール (C) Copyright Microsoft Corporation. All rights reserved. バックアップ時間: 2023/08/19 15:01 バックアップ対象: 固定ディスク ラベル付き E: バージョン識別子: 08/19/2023-06:01 回復可能: ボリューム, ファイル, アプリケーション, ベア メタル回復, システム状態 スナップショット ID: {0b54a2d7-d77e-4e13-a4ba-6725cff9d311} バックアップ時間: 2023/08/19 17:17 バックアップ対象: 固定ディスク ラベル付き E: バージョン識別子: 08/19/2023-08:17 回復可能: ボリューム, ファイル, アプリケーション, ベア メタル回復, システム状態 スナップショット ID: {3cc32db0-f1c9-4c63-a20a-f6a3ee589c3c} C:\> |
このフォルダ名はバックアップ開始時点の「年-月-日 時分秒」のUTCなんですね。
(この図は2回目のバックアップ実行後のバックアップ保存先です)
1回目のバックアップ実行後と2回目のバックアップ実行後のバックアップ保存先のVHDXファイルを比較したのが下表です。
今回の場合、バックアップを2回実行してもVHDXファイルの名前や数は変わりませんでした。
しかし2回目のバックアップを実行すると各VHDXファイルはタイムスタンプが更新され、1つ目のVHDXファイルはサイズが少し大きくなっていました。
2023/08/19 15:12 12,838,764,544 45438d33-b811-4232-b94e-b42f88bac505.vhdx 2023/08/19 15:12 530,579,456 5b3113e6-2d7f-42b4-b9b3-dc1ff3d017d9.vhdx 2023/08/19 15:12 52,428,800 Esp.vhdx |
2023/08/19 17:28 13,042,188,288 45438d33-b811-4232-b94e-b42f88bac505.vhdx 2023/08/19 17:28 530,579,456 5b3113e6-2d7f-42b4-b9b3-dc1ff3d017d9.vhdx 2023/08/19 17:28 52,428,800 Esp.vhdx |
とりあえずこの記事はここまで。
Robocopyコマンドでフォルダをコピーしたらログにどのように表示されるか確認してみた
仕事ではWindowsのフォルダをコピーする時は、ほとんどの場合robocopyコマンドを使います。
コピー元のファイルが削除されても、古いファイルに戻っても、コピー先に反映します。
名前が同じで更新日時もサイズも同じファイルはコピーをスキップしてくれます。
NTFSのアクセス権や所有権もコピーできます。
NTFSの機能(EFS)を使って暗号化されたファイルも暗号化されたままコピーできます。
詳細なログを記録する事も可能です。
そんなわけで日々のデータバックアップや、ファイルサーバーの移行などでrobocopyはお馴染みです。
しかしrobocopyを実行した時に表示されるログで、新しいファイルをコピーした場合、既存のファイルを上書きした場合、同じファイルなのでコピーをスキップした場合など、それぞれどのようなステータスが表示されるのかよくわかりませんでした。
なのでちょっと検証してみました。
これをやったのは3年近く前であり、画像はその時の物です。
環境:Windows Server 2016 (ワークグループ)
実行したコマンドはこれ
オプション
結果は以下の通りでした。
2)受け側が同一ファイルの場合
何もコピーされず、何も表示されない(スキップ1件)
3)受け側のファイルが古い場合
ファイルが上書きコピーされ、「新しい」と表示される(コピー済み1件)
4)受け側のファイルが新しい場合
ファイルが上書きコピーされ、「古い」と表示される(コピー済み1件)
5)受け側のみ存在する不要ファイルの場合
受け側からファイルが削除され、「*EXTRA File」と表示される(コピー済み1件、Extras 1件)
6)ファイルは同一だがアクセス権のみが違う場合
アクセス権のみがコピーされ、「更新済み」と表示される(コピー済み1件)
(参考1)Windows Serevr 2016のOSバージョン
(参考2)robocopy.exeのバージョン
コピー元のファイルが削除されても、古いファイルに戻っても、コピー先に反映します。
名前が同じで更新日時もサイズも同じファイルはコピーをスキップしてくれます。
NTFSのアクセス権や所有権もコピーできます。
NTFSの機能(EFS)を使って暗号化されたファイルも暗号化されたままコピーできます。
詳細なログを記録する事も可能です。
そんなわけで日々のデータバックアップや、ファイルサーバーの移行などでrobocopyはお馴染みです。
しかしrobocopyを実行した時に表示されるログで、新しいファイルをコピーした場合、既存のファイルを上書きした場合、同じファイルなのでコピーをスキップした場合など、それぞれどのようなステータスが表示されるのかよくわかりませんでした。
なのでちょっと検証してみました。
これをやったのは3年近く前であり、画像はその時の物です。
環境:Windows Server 2016 (ワークグループ)
実行したコマンドはこれ
ROBOCOPY D:\Data01 D:\Data02 /E /B /SECFIX /EFSRAW /COPYALL /MIR /R:0 /W:0
オプション
| オプション | 説明 |
| /E | 空のディレクトリを含むサブディレクトリをコピーします |
| /B | バックアップ モードでファイルをコピーします |
| /SECFIX | スキップしたファイルも含むすべてのファイルのファイル セキュリティを修正します |
| /EFSRAW | 暗号化されたすべてのファイルを EFS RAW モードでコピーします |
| /COPYALL | ファイル情報をすべてコピーします (/COPY:DATSOU と同等) |
| /MIR | ディレクトリ ツリーをミラー化します (/E および /PURGE と同等) |
| /R:0 | 失敗したコピーに対する再試行数をゼロにする(既定値は1,000,000) |
| /W:0 | 再試行と再試行の間の待機時間をゼロにする(既定値は30 秒) |
結果は以下の通りでした。
| 送り側と受け側の状況 | コピー結果 | ログ表示 | |
| 1 | 受け側に存在しない新規ファイルの場合 | ファイルをコピー(追加) | 「新しいファイル」と表示される コピー済みファイル1件 |
| 2 | 受け側が同一ファイルの場合 | (何もコピーしない) | 何も表示されない スキップ1件 |
| 3 | 受け側のファイルが古い場合 | ファイルをコピー(上書き) | 「新しい」と表示される コピー済み1件 |
| 4 | 受け側のファイルが新しい場合 | ファイルをコピー(上書き) | 「古い」と表示される コピー済み1件 |
| 5 | 受け側のみ存在する不要ファイルの場合 | 受け側フォルダからファイルを削除 | 「*EXTRA File」と表示される コピー済み1件 Extras 1件 |
| 6 | ファイルは同一だがアクセス権のみが違う場合 | アクセス権のみコピーする(*1) | 「更新済み」と表示される コピー済み1件 |
(*1)大きなサイズのファイルをコピーしてみて、タイムスタンプが違うためファイルを上書きコピーするときは時間がかかるが、アクセス権のみが異なる場合は一瞬でコピーが終了することで、「アクセス権のみをコピー」することを確認しています。
1)受け側に存在しない新規ファイルの場合
1)受け側に存在しない新規ファイルの場合
ファイルがコピーされ、「新しいファイル」と表示される(コピー済み1件)
2)受け側が同一ファイルの場合
何もコピーされず、何も表示されない(スキップ1件)
3)受け側のファイルが古い場合
ファイルが上書きコピーされ、「新しい」と表示される(コピー済み1件)
4)受け側のファイルが新しい場合
ファイルが上書きコピーされ、「古い」と表示される(コピー済み1件)
5)受け側のみ存在する不要ファイルの場合
受け側からファイルが削除され、「*EXTRA File」と表示される(コピー済み1件、Extras 1件)
6)ファイルは同一だがアクセス権のみが違う場合
アクセス権のみがコピーされ、「更新済み」と表示される(コピー済み1件)
(参考1)Windows Serevr 2016のOSバージョン
(参考2)robocopy.exeのバージョン
Windows Server 2022のパッチをWindows Updateカタログから事前にダウンロードしておきオフラインインストールする
Windows UpdateカタログからWindows Server 2022用のパッチを事前にダウンロードしておき、インターネットに接続しない状況でパッチをインストールする、いわゆるオフラインインストールをすることになり、その検証を行ってみました。
しかしまず戸惑ったのが検索窓に入れる製品名。
「Windows Server 2022」と入れて検索してもお目当てのパッチはヒットしません。
Windows Server 2019も、Windows Server 2016も、もっと以前のOSもその名前を入れて検索するとヒットしますが、Windows Server 2022はヒットしません。
Windows UpdateカタログでWindows Server 2022用パッチを検索するためには「Windows Server 21H2」と入力するとヒットしますが、これに気付くまでにかなり時間を使ってしまいました。。。
検索例
(図1)Windows UpdateカタログでWindows Server 2022用パッチを検索した例
これはWindows Server 2022用の2022年7月の累積更新を検索しています。
そのままだと.NET Framework用の更新も出て来るので、-Frameworkを付けて除外しています。
しかし2022年7月のパッチが2つ出てきましたね。
(図2)2022/07/12付けのKB5015827
Windows Updateカタログの検索結果からタイトル部分のリンク先をクリックし、「パッケージの詳細」タブを開きます。
この2022/07/12付けのKB5015827は、7/19付けのKB5015879で置き換えられたことが分かります。
(図3)2022/07/19付けのKB5015879
同じく「パッケージの詳細」を見ると、この2022/07/19付けのKB5015879は7/12付けのKB5015827を置き換えていることが分かります。
つまり7/12付けのKB5015827は不要で、この7/19付けのKB5015879だけダウンロードすれば良いことが分かります。(「2022年7月のパッチを適用する」の観点です)
(図4)Windows Server 2022をインストールした直後のGet-HotFix
(図5)Windows Server 2022に2022/07/19付けのKB5015879をインストールした後のGet-HotFix
(表1)KB5015879適用前後のGet-HotFixの違いまとめ
はい、これでWindows Server 2022のパッチを事前にダウンロードしておき、後からオフラインインストールする事が出来ました。
しかしまず戸惑ったのが検索窓に入れる製品名。
「Windows Server 2022」と入れて検索してもお目当てのパッチはヒットしません。
Windows Server 2019も、Windows Server 2016も、もっと以前のOSもその名前を入れて検索するとヒットしますが、Windows Server 2022はヒットしません。
Windows UpdateカタログでWindows Server 2022用パッチを検索するためには「Windows Server 21H2」と入力するとヒットしますが、これに気付くまでにかなり時間を使ってしまいました。。。
検索例
Windows Server 21H2 2022-07 -Framework
(図1)Windows UpdateカタログでWindows Server 2022用パッチを検索した例
これはWindows Server 2022用の2022年7月の累積更新を検索しています。
そのままだと.NET Framework用の更新も出て来るので、-Frameworkを付けて除外しています。
しかし2022年7月のパッチが2つ出てきましたね。
(図2)2022/07/12付けのKB5015827
Windows Updateカタログの検索結果からタイトル部分のリンク先をクリックし、「パッケージの詳細」タブを開きます。
この2022/07/12付けのKB5015827は、7/19付けのKB5015879で置き換えられたことが分かります。
(図3)2022/07/19付けのKB5015879
同じく「パッケージの詳細」を見ると、この2022/07/19付けのKB5015879は7/12付けのKB5015827を置き換えていることが分かります。
つまり7/12付けのKB5015827は不要で、この7/19付けのKB5015879だけダウンロードすれば良いことが分かります。(「2022年7月のパッチを適用する」の観点です)
(図4)Windows Server 2022をインストールした直後のGet-HotFix
(図5)Windows Server 2022に2022/07/19付けのKB5015879をインストールした後のGet-HotFix
(表1)KB5015879適用前後のGet-HotFixの違いまとめ
| Windows Server 2022インストール直後 | KB5015879のインストール後 |
| KB5008882 | KB5008882 |
| KB5010523 | KB5010523 |
| KB5011497 | (消えた) |
| ---- | KB5015879 |
| ---- | KB5015897 |
はい、これでWindows Server 2022のパッチを事前にダウンロードしておき、後からオフラインインストールする事が出来ました。
Windows PowerShellのSet-ADReplicationSubnetコマンドレットでIPサブネットを他のサイトに割り当てる
Windows Server 2012 R2のドメインコントローラーで検証しました。
某実環境がWindows Server 2012 R2なので。。。
福岡のFUKUOKAサイトを廃止して、OSAKAサイトに統合するような事を想定しています。
福岡支店のサブネット「192.168.201.0/24」は今までFUKUOKAサイトに割り当てられていましたが、これをOSAKAサイトに割り当てるように変更しますが、これをコマンドでやってみます。
この場合は Windows PowerShellのSet-ADReplicationSubnetが利用できますね。
簡単でした。
(画像)PowerShellのコマンドでIPサブネットを割り当てるサイトを変更する
(画像2)サイトの割り当て変更前後をActive Directoryサイトとサービスで表示する
テキストでも
某実環境がWindows Server 2012 R2なので。。。
福岡のFUKUOKAサイトを廃止して、OSAKAサイトに統合するような事を想定しています。
福岡支店のサブネット「192.168.201.0/24」は今までFUKUOKAサイトに割り当てられていましたが、これをOSAKAサイトに割り当てるように変更しますが、これをコマンドでやってみます。
この場合は Windows PowerShellのSet-ADReplicationSubnetが利用できますね。
簡単でした。
(画像)PowerShellのコマンドでIPサブネットを割り当てるサイトを変更する
(画像2)サイトの割り当て変更前後をActive Directoryサイトとサービスで表示する
テキストでも
| 管理者: Windows PowerShell |
PS C:\> Get-ADReplicationSubnet -Filter * |Select-Object Name,Site |Format-Table -A Name Site ---- ---- 192.168.1.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.2.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.3.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.4.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.101.0/24 CN=OSAKA,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.102.0/24 CN=OSAKA,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.201.0/24 CN=FUKUOKA,CN=Sites,CN=Configuration,DC=testdom,DC=local PS C:\> Set-ADReplicationSubnet 192.168.201.0/24 -site OSAKA PS C:\> Get-ADReplicationSubnet -Filter * |Select-Object Name,Site |Format-Table -A Name Site ---- ---- 192.168.1.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.2.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.3.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.4.0/24 CN=TOKYO,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.101.0/24 CN=OSAKA,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.102.0/24 CN=OSAKA,CN=Sites,CN=Configuration,DC=testdom,DC=local 192.168.201.0/24 CN=OSAKA,CN=Sites,CN=Configuration,DC=testdom,DC=local PS C:\> |
VMware vSphere 6.5のゼネラルサポートの期限が2022年10月までに延長され、6.7と同じになっていた
VMware vSphere 6.5のゼネラルサポートの期限が延長されていました。
変更前:2021/11/15
変更後:2022/10/15
この変更により、VMware vSphere 6.5は6.7と同じサポート期間になりました。
(6.5と6.7のテクニカルガイダンスの終了は以前から同じでした)
この変更を反映させた各バージョンごとのサポート期間は以下の通りです。
(VMware vSphereには、vCenter ServerとVMware ESXiを含みます)
ゼネラルサポートの範囲内に入るように、VMware vSphere 6.5から、6.7や7.0にバージョンアップをする計画を考えていたシステムは、6.5のまま最新アップデート・最新パッチを適用して延命する方法も選択肢になりますね。
その場合でも2022年10月までには7.0にバージョンアップを推奨します。
重要なシステムをVMware上で稼働させ、今までサポートに問い合わせたことがある人なら、ゼネラルサポートの対象になっている事がどれだけ重要かわかると思います。
変更前:2021/11/15
変更後:2022/10/15
この変更により、VMware vSphere 6.5は6.7と同じサポート期間になりました。
(6.5と6.7のテクニカルガイダンスの終了は以前から同じでした)
この変更を反映させた各バージョンごとのサポート期間は以下の通りです。
| Product Release | General Availability | End of General Support | End of Technical Guidance |
|---|---|---|---|
| VMware vSphere 7.0 | 2020/04/02 | 2025/04/02 | 2027/04/02 |
| VMware vSphere 6.7 | 2018/04/17 | 2022/10/15 | 2023/11/15 |
| VMware vSphere 6.5 | 2016/11/15 | 2022/10/15 | 2023/11/15 |
| VMware vSphere 6.0 | 2015/03/12 | 2020/03/12 | 2022/03/12 |
ゼネラルサポートの範囲内に入るように、VMware vSphere 6.5から、6.7や7.0にバージョンアップをする計画を考えていたシステムは、6.5のまま最新アップデート・最新パッチを適用して延命する方法も選択肢になりますね。
その場合でも2022年10月までには7.0にバージョンアップを推奨します。
重要なシステムをVMware上で稼働させ、今までサポートに問い合わせたことがある人なら、ゼネラルサポートの対象になっている事がどれだけ重要かわかると思います。
各製品ごとのサポート期間はここに掲載されています。
https://lifecycle.vmware.com/
Product Lifecycle Matrix
VMware vSphere 6.5のゼネラルサポート延長のお知らせはここに。
https://blogs.vmware.com/vsphere/2021/03/announcing-limited-extension-of-vmware-vsphere-6-5-general-support-period.html
Announcing Limited Extension of VMware vSphere 6.5 General Support Period - VMware vSphere Blog
SQL Server 2017 Express Editionをオフラインインストールする(4/4) - SQL Serverアップデート編
インターネットに接続できない環境で、Windows Server 2016上にSQL Server 2017 Express Editionをインストールする検証の続きです。(今回が最後)
ブログ記事は4回に分かれています。
(1/4)SQL Serverダウンロード編
(2/4)SQL Serverインストール編
(3/4)SSMS編 (SQL Server Management Studio)
(4/4)SQL Serverアップデート編 ←今回
SQL Server 2017およびそれ以降ではサービスパックは廃止されました。
Critical Update(CU)と呼ばれる累積的な更新プログラムが定期的にリリースされるモデルになっています。
これにより最新のCUを適用するだけで最新化されます。
パッチごとに適用するしない(しているしていない)で悩むことも無くなります。
このページから各CUのダウンロード先にリンクできます。
(図1)SQL Server 2017アップデートモジュールのインストール開始
ここでは「SQLServer2017-KB4557397-x64.exe」を起動してインストールを開始します。
(図2)インストールモジュールが解凍される
(図3)インストールの準備中画面
(図4)ライセンス条項に同意して次へ
(図5)そのまま次へ
(図6)Microsoft Rオープンのインストールで「承諾」して、次へ
(図7)Pythonのインストールで「承諾」して、次へ
(図8)Microsoft Machine Learning Serverコンポーネントのオフラインインストール
RとPythonのモジュールを置いた場所を指定して、次へ。
(図9)使用中のファイルの確認で次へ
(図10)更新準備完了で「更新」ボタン
(図11)インストールが開始されます
(図12)RとPythonの更新に失敗
どうしてかわからないのですが、RとPythonの更新に失敗しました。
どうしようもないので「閉じる」を押します。
(図13)SQL Server Management Studioの起動
試しにSQL Server Management Studioを起動してSQL Server 2017 Express Editionのインスタンスに接続してみます。
(図14)プロパティの表示
SQLEXPRESSインスタンスを右クリックしてプロパティを開きます。
(図15)バージョン情報の確認
SQL Server 2017 Express EditionのSQLEXPRESSインスタンスのバージョンが「14.0.3335.7」になっています。
「14.0.3335.7」はSQL Server 2017のCU21になります。
これは今日2020/9/23時点では最新のCUです。
RとPythonの更新に失敗する現象は未解決のままですが、SQL Server 2017の内部バージョンは更新されているので、今回はこれで完了とします。
インターネットに接続できない状態でSQL Server 2017をアップデートする際に、RとPythonの更新も成功させる方法を知っている人がいたら教えてくださいm(__)m
(1/4)SQL Serverダウンロード編
(2/4)SQL Serverインストール編
(3/4)SSMS編 (SQL Server Management Studio)
(4/4)SQL Serverアップデート編 ←今回
ブログ記事は4回に分かれています。
(1/4)SQL Serverダウンロード編
(2/4)SQL Serverインストール編
(3/4)SSMS編 (SQL Server Management Studio)
(4/4)SQL Serverアップデート編 ←今回
SQL Server 2017およびそれ以降ではサービスパックは廃止されました。
Critical Update(CU)と呼ばれる累積的な更新プログラムが定期的にリリースされるモデルになっています。
これにより最新のCUを適用するだけで最新化されます。
パッチごとに適用するしない(しているしていない)で悩むことも無くなります。
このページから各CUのダウンロード先にリンクできます。
https://support.microsoft.com/ja-jp/help/4047329/sql-server-2017-build-versions
SQL Server 2017 ビルド バージョン
(図1)SQL Server 2017アップデートモジュールのインストール開始
ここでは「SQLServer2017-KB4557397-x64.exe」を起動してインストールを開始します。
(図2)インストールモジュールが解凍される
(図3)インストールの準備中画面
(図4)ライセンス条項に同意して次へ
(図5)そのまま次へ
(図6)Microsoft Rオープンのインストールで「承諾」して、次へ
(図7)Pythonのインストールで「承諾」して、次へ
(図8)Microsoft Machine Learning Serverコンポーネントのオフラインインストール
RとPythonのモジュールを置いた場所を指定して、次へ。
(図9)使用中のファイルの確認で次へ
(図10)更新準備完了で「更新」ボタン
(図11)インストールが開始されます
(図12)RとPythonの更新に失敗
どうしてかわからないのですが、RとPythonの更新に失敗しました。
どうしようもないので「閉じる」を押します。
(図13)SQL Server Management Studioの起動
試しにSQL Server Management Studioを起動してSQL Server 2017 Express Editionのインスタンスに接続してみます。
(図14)プロパティの表示
SQLEXPRESSインスタンスを右クリックしてプロパティを開きます。
(図15)バージョン情報の確認
SQL Server 2017 Express EditionのSQLEXPRESSインスタンスのバージョンが「14.0.3335.7」になっています。
「14.0.3335.7」はSQL Server 2017のCU21になります。
これは今日2020/9/23時点では最新のCUです。
RとPythonの更新に失敗する現象は未解決のままですが、SQL Server 2017の内部バージョンは更新されているので、今回はこれで完了とします。
インターネットに接続できない状態でSQL Server 2017をアップデートする際に、RとPythonの更新も成功させる方法を知っている人がいたら教えてくださいm(__)m
(1/4)SQL Serverダウンロード編
(2/4)SQL Serverインストール編
(3/4)SSMS編 (SQL Server Management Studio)
(4/4)SQL Serverアップデート編 ←今回
気軽に話しかけてね
