Windows Server ＆ Cloud User Group Japan 第47回 勉強会セッション動画「Windows Admin Center 2410のPowerShell概要」

 

Azure Arc GatewayがGAしました。

Announcing the General Availability of Arc Gateway for Azure Local

ということなので、公式手順に則り、Azure Portalから作成し終えるところまでを本稿にまとめます。

Azure Local 用 Azure Arc ゲートウェイについて

にそってリソースを作成します。

Azure ArcのManagementから、Azure Arc gatewayをクリックし、新規に作成します。

サブスクリプション、リソースグループ、gateway名、Regionを設定します。サブスクリプション、リソースグループ、Regionは、デプロイ対象になるAzure Localと同じところを指定します。

タグで、標準でサポートするカスタムタグを1つ以上指定することになっているので、タグBillに対応する値を選択します。

作成します。

10分ほど待つと作成されました。

概要/OverviewにあるResource ID（下図の赤い箇所）をメモしておきます。Resource IDは、Azure Arcへの登録時に使用しますので。

Proxyサーバーの準備がないため、一旦ここで確認を区切ります。

Windows Server ＆ Cloud User Group Japan 第47回 勉強会資料「Windows Admin Center 2410のPowerShell概要」

Windows Admin Center 2410のPowerShell概要_PowerShell Overview for Windows Admin Center 2410 by @sshzk

アジェンダは下記の通りです。

PowerShellコマンドレットの比較概要
構成管理関連コマンドレット
接続管理関連コマンドレット
拡張関連コマンドレット
管理関連コマンドレット
移行関連コマンドレット
PowerShellTools関連コマンドレット
まとめ
参考情報
---
Comparison of PowerShell cmdlets
Configuration Management Cmdlets
Connection Management Cmdlets
Extensibility Cmdlets
Management Cmdlets
Migration Cmdlets
PowerShell Tools Cmdlets
Summary
Reference Information

Nested Hyper-Vを使う公式のAzure Local仮想マシンデプロイ手法を使ってみた その2

Nested Hyper-Vを使う公式のAzure Local仮想マシンデプロイ手法を使ってみた

でマイクロソフトの公式資料である

仮想 Azure ローカル システムをデプロイする

を使ってNested Hyper-Vとして仮想マシンでAzure Localのデプロイを試しています。

デプロイ前の最終バリデーションで、エラーになりました。

こちらは、同僚に聞いてみたところ、 WSMan:\localhost\Client\TrustedHostsは、何も設定していないとのこと。改めてお手製スクリプトから、WSMan:\localhost\Client\TrustedHosts へ設定をはずしてみました。

結果、久しぶりにAzure Localのデプロイに成功しました。

今後もデプロイを通じて確認を進めていけそうです。

Nested Hyper-Vを使う公式のAzure Local仮想マシンデプロイ手法を使ってみた

仮想 Azure ローカル システムをデプロイする

を見つけました。

こちらをベースにお手製のスクリプトを改良しました。加えて、再認識しましたが、ゲストOSのタイムゾーンはPST/PDTのままだなと（統合サービスとの時間同期を無効化、w32tmによるタイムサービスとの同期を行った上で、ゲストOSのクロックをPST/PDTに手動で合わせた）。

2508のデプロイにおいて、Extensionは、インストールされたものから触らない。下手に手動アップグレードすると、BasicのValidateに失敗するという気づきを得ました。

ということで、本稿作成時点でのExtensionsは、下記のままで進めました。

デプロイ前の最終的なValidateは、TrustedHostsの指定方法がよろしくないような。*だとダメなのかな。。。また調べ直さないと。

引き続き調べるとして、22H2以来のデプロイを成功させたいものですね。

Active DirectoryでBitLocker回復パスワードを表示する

BitLocker回復パスワードをActive Directoryに保存できますね。Azure Localのノードで使われるBitLocker回復パスワードも同様に保存できます。

Azure Localのノードではないのですが、本稿ではWindows 11でBitLockerを有効化し、BitLocker回復パスワードをActive Directoryに保存した結果を閲覧してみます。

Windows 11でBitLockerを有効化

設定から、BitLockerドライブ暗号化を開きます。この例では、暗号化されていません。ここから暗号化を有効化します。

UACにて管理者権限を取得します。

回復キーはファイルに保存しました。

BitLockerをアクティブ化します。

有効化できました。

Active DirectoryドメインコントローラーにBitLocker回復パスワードビューアーをインストール

サーバーマネージャーから役割と機能の追加をクリックして、ウィザードを起動します。

「役割ベースまたは機能ベースのインストール」をクリックして、「次へ」をクリックします。

指定されたサーバーのまま、「次へ」をクリックします。

サーバーの役割はそのままにして、「次へ」をクリックします。

機能で、「リモートサーバー管理ツール」→「機能管理ツール」の順で展開します。

「BitLocker回復パスワードビューアー」をクリックして、「次へ」をクリックします。

「インストール」をクリックします。

しばらく待つとインストールが完了しました。

BitLocker回復パスワードをActive Directoryに保存

グループポリシーは未構成のまま試してみることとしました。

manage-bde.exeのオプションを確認します。

manage-bde.exe -statusで状態を見ておきます。

ファイルに保存した回復キーを確認しました。

リトライした結果、manage-bde.exeよりBitLocker回復パスワードをActive Directoryに保存しました。回復キーのIDは、そのまま指定できません。下図の通り、'{回復キーのID}'という形式で囲っておく必要がありました。

該当のコンピューターアカウントにて、BitLocker回復タブをクリックしたところ、回復キーのID、回復パスワードが表示されました。

Windows Kerberosに対する脆弱性CVE-2025-26647の続報

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

という記事を書いていました。

先日続報がリリースされましたので、ご紹介します。

CVE-2025-26647 への対応とその影響について

が日本マイクロソフトのWindowsサポートチームよりリリースされています。この記事によると強制モードの開始日（更新プログラムのリリース日）が2025年10月14日で確定しています。

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

に記載した通り、強制モードは下記のような状況になります。

このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。

ということで、証明書認証をお使いの場合は、残り1か月で対応が必要になります。

CVE-2025-26647 (Kerberos 認証) の保護　はサポート情報でした。今回は日本マイクロソフトのWindowsサポートチームによる記事のため、すでにリリース済みの更新プログラムに対する不具合情報が記載されています。各々の不具合情報は、CVE-2025-26647 への対応とその影響について に詳細がございますのでご確認ください。下記では、その不具合情報が、すでに改善済みか否かを抜粋して記載いたします。

• 2025 年 4 月 8 日の更新プログラムに含まれている不具合は、2025 年 6 月 10 日の更新プログラムで改善済みとのこと。
• 2025 年 7 月 8 日の更新プログラムに含まれている不具合は、上記とは別とのことです。そのため、今後改善する見込みとのこと。
  ただし、6 月の更新プログラムを適用済みの状態で ID:45 が記録されていない状況であれば、ID:21 イベントによる実影響がないとも記載ありました。