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、回復パスワードが表示されました。

PowerShellモジュール AsHciADArtifactsPreCreationTool を手動インストールしてみた

Azure Stack HCI バージョン 23H2 デプロイ用に Active Directory を準備する

に基づいて進めるわけですが、前提条件の

Install-Module AsHciADArtifactsPreCreationTool -Repository PSGallery -Force

がうまくいかない事態が発生しました。PSGalleryへのリセットが何度リトライしても上手くいかないため、モジュールを手動インストールすることとなり。。。

AsHciADArtifactsPreCreationTool 10.2402

から、Manual Downloadをクリックし、「Download the raw nupkg file」をクリックしてnupkgファイルをダウンロードします。

パッケージの手動ダウンロード を見たところ、拡張子をzipに変更すると普通に解凍できました。_rels フォルダーにある.rels ファイルを見たところ、インストール時の依存関係は特にないようです。

拡張子psd1とpsm1を"C:\Program Files\WindowsPowerShell\Modules\ashciadartifactsprecreationtool\10.2402.0"にコピーします。

Import-Moduleでインポートしましたが、バージョンが無いですね。手動インストールはこういうことが起きるのですね。

ADドメインコントローラー以外で、実行してみたところ下記のエラーを得ました。

AD用のPowerShellとグループポリシー管理ツールを追加すれば、問題無く実行できますね。

Azure Stack HCI 23H2のプロキシ設定例のタイプミスと思われる箇所

Configure proxy settings for Azure Stack HCI, version 23H2 の

Configure proxy settings for Environment Variables

ですが、プロキシ設定例のタイプミスと思われる箇所あります。下記に引用し該当開所を赤字表記します。

# If a proxy server is needed, execute these commands with the proxy URL and port.

[Environment]::SetEnvironmentVariable("HTTPS_PROXY","http://ProxyServerFQDN:port", "Machine")

$env:HTTPS_PROXY = [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY","Machine")

[Environment]::SetEnvironmentVariable("HTTP_PROXY","http://ProxyServerFQDN:port "Machine")

$env:HTTP_PROXY = [System.Environment]::GetEnvironmentVariable("HTTP_PROXY","Machine")

$no_proxy = "<bypassliststring>"

[Environment]::SetEnvironmentVariable("NO_PROXY",$no_proxy,"Machine")

$env:NO_PROXY = [System.Environment]::GetEnvironmentVariable("NO_PROXY","Machine")

赤字表記している箇所では、"が閉じていないのと、,が足りてないです。不足している文字を補った正しい表記は、下記になるかと（補完した箇所を赤字表記します）。

[Environment]::SetEnvironmentVariable("HTTP_PROXY","http://ProxyServerFQDN:port", "Machine")

すでにプルリクエストしているのでそのうち直ると思います。

New-HciAdObjectsPreCreation は、PDCエミュレーターで実行したほうがよいのかも

Azure Stack HCIクラスターの命名順から、別のOUを指定して New-HciAdObjectsPreCreation しました。が、失敗。。。

※今回は、AzureへのAzure VPNセッションは接続済みであることを確認済みです。念のため。

なぜこのようなことになるか。新しく作成したOUが、PDCエミュレーターに複製していないから。オンプレミスとAzureのADサイトは別々ゆえ、複製タイミングに合わないから、複製されていないわけです。

ただちにレプリケートして New-HciAdObjectsPreCreation を再実行したところ、問題なく成功。

OUを作成するADドメインコントローラー (AD DC)とPDCエミュレーターのADサイトが別々の場合、New-HciAdObjectsPreCreation はPDCエミュレーターで実行したほうがよいのかも。

通信が不安定だったため、New-HciAdObjectsPreCreationの実行中に引かなくても良いトラブルを引いた

Azure Stack HCI OS 23H2のデプロイを進めています。

Prepare Active Directory for Azure Stack HCI, version 23H2 deployment

を実行していた時のこと。
※ユーザー名だけでよいのに、ドメイン名をつけてしまった失敗は、さておき。

コマンドレットの内容を見ていると、GPOの継承ブロックで失敗しているような。。。「指定されたドメインがないか、またはアクセスできません」とのこと。

OUとユーザーは、作成できていました。

Prepare Active Directory for Azure Stack HCI, version 23H2 deployment に載っている別スクリプトも試しに実行してみましたが、当然うまくいかない。

Copilotに上記画像のキーワードを与えて、いくつか当たってみました。下記に近いかなと。

Cannot disable group policy inheritance from domain

ということで、グループポリシーの管理コンソールを開こうとすると、接続不調によると思われるダイアログが表示されました。

続行してみたらダメ。

何度かリトライしてもだめ。

本環境のPDCエミュレータは、Azure上にあるので、Azure VPNの状態を見ます。案の定、未接続。。。

（固定IPアドレスではない故）ローカルゲートウェイのパラメーターを修正して再接続完了。

New-HciAdObjectsPreCreationの実行がようやく成功。。。

Storage Spaces Directのストレージ層を改めて見返してみる

Azure Stack HCI 22H2をSingle Server/Single Nodeから、2ノードクラスターへ変更する

の続き。

あたらめて

ストレージ層の概要テーブル

について再考しました。

Azure Stack HCI Single Node/Siingle Serverからノード追加すると、双方向ミラーが利用できるAzure Stack HCI 2ノードクラスターとなります。

この両者には、MirrorOnHDD, MirrorOnSSD, MirrorOnSCM（以降、MirrorOn*と呼称します）というストレージ層が共通項としてあります。が下記の差異もあります。

• Azure Stack HCI Single Node/Siingle Server
  ParityOnHDD, ParityOnSSD, ParityOnSCM（以降、ParityOn*と呼称します）
• Azure Stack HCI 2ノードクラスター
• NestedMirrorOnHDD, NestedMirrorOnSSD, NestedMirrorOnSCM（以降、NestedMirror*と呼称します）
• NestedParityOnHDD, NestedParityOnSSD, NestedParityOnSCM（以降、NestedParityOn*と呼称します）

一つの考えとして、Azure Stack HCI Single Node/Siingle Serverからノード追加すると、双方向ミラーが利用よきるAzure Stack HCI 2ノードクラスターにした際、ParityOn*は無くても良いストレージ層ともいえます。

ここで、さらにAzure Stack HCI 3ノードクラスターに拡張すると、MirrorOn*のみがストレージ層になります。

さらにAzure Stack HCI 3ノードクラスターに拡張すると、パリティが使えるようになるため、ParityOn*が再び登場します。

Inline fault domain changesには、不要なストレージ層を削除するよう記載があります。ここまでの考えをもとに、Azure Stack HCI Single Node/Siingle ServerからAzure Stack HCI 2ノードクラスター化する際に、不要なストレージ層を削除しても良さそうですし、削除しない選択肢もあるのかなと感じました。

物理サーバーのAzure Stack HCI OS 22H2でもValidate-DCBを起動してみた

Azure Stack HCI 22H2をSingle Server/Single Nodeから、2ノードクラスターへ変更する

は、Nested Hyper-Vだったのですが、必要に迫られ物理サーバーのAzure Stack HCI OS 22H2で確認しました。

そういえば、物理サーバーでもValidate-DCBを起動することになるので、画面を採取しておきました。

インストールは、気のせいか前よりスムーズになっているような。

インストール完了したので、Validate-DCBを起動。
注）すでにスイッチ埋め込み型チーミングが設定されているため、途中までの確認と相成りました。

起動直後の画面。

下記は、確認対象を設定する箇所ですね。

NICの選択など。すでにスイッチ埋め込み型チーミングが設定されているためここから先の確認はできず、見送り。

保存しないとエラーっぽくなるのは、前と変わらずです。

PowerShellのAksHciモジュール都合により、Az.ResourcesとAz.Accountsが複数バージョン並列配置せざるを得なかった

Az.StackHCI、Az.Resources、Az.ccountsを最新化するPowerShellスクリプト でPowerShellモジュールを最新化できたと思ったら、そうは問屋が卸さなかった。。。

PowerShellモジュールのAksHci 1.1.83は、Az.Resource 4.40、Az.Accounts 2.6.0を要求しています。。。
※あくまでも本校執筆時点の2023年9月3日での話です。AksHci がバージョンアップしたら状況は変わるかもしれません。

Import-Module -Name AksHci
後は、クラスターの全ノードでAz.ResourcesとAz.Accountsが複数バージョンの並列インストールとなりました。

2023/09/03追記

同じPowerShellモジュールを並列でインポートしたせいか、下記のエラーが発生しました。

PowerShellウィンドウをいったん閉じてから開きなおし、Az.Accounts 2.6.0、Az.Resource 4.4.0の順でインポート後、AksHciをインポートしました。結果、上記のエラーは収まった模様。

Windows Admin Center 2306のTool updates -> Improved Hyper-V virtual machine management その2

Windows Admin Center 2306のTool updates -> Improved Hyper-V virtual machine management その1　から続く

Windows Admin Center version 2306 is now generally available!

のTool updates -> Improved Hyper-V virtual machine managementの中から、下記についてみていきます。

• Ability to move virtual machine between clusters
• Ability to move virtual machine with storage
• Ability to pop out a VM’s RDP session, so you don’t have to switch context and leave your current view

Ability to move virtual machine between clusters

「管理」から「移動」を選択します。
移行先で別のクラスターを選んでから、配置先のストレージを選びます。

設定項目を確認後、「移動」クリックしてしばらく待ちます。

上記画像の後、移行元の仮想マシンは、さっと消えてしまいますが、移行先にはなかなか出てこないので、失敗したと焦らず待ちましょう。しばらくすると仮想マシンマイグレーションの結果が表示されます。

仮想ハードディスクのパスを念のため確認しておきます。問題無いですね。

Ability to move virtual machine with storage

※移行先に仮想マシン名のフォルダーを作成しておいたほうが、変な配置にならずに済みます。フェールオーバークラスターマネージャーでストレージ移行をする場合とおんなじ感じです。

変な配置になってしまった例から記載します。

「管理」から「移動」を選択します。

c:\ClusterStorage\Volume2配下を選択して、「移動」をクリックします。

しばらく待つと結果が表示されます。

c:\ClusterStorage\Volume2配下にHyper-Vフォルダーを作成してそこへストレージ移行しました。。。

ということで、移行先に仮想マシン名のフォルダーを作成してから、移行先として指定し「移動」をクリックします。

結果が表示されます。

希望した配置になりました。

Ability to pop out a VM’s RDP session, so you don’t have to switch context and leave your current view

※対象の仮想マシンに対して、RDPやWinRMの許可設定、名前解決が必要です。念のため。

　同じADドメインがベストかもしれませんね。

仮想マシンを選択後、「接続」→「接続」→接続アイコンの右端を下図のように選択します。

認証情報を入力します。

リモートデスクトップ接続しました。この後、「Ctrl+Alt+Delを送信」をクリックすればログオンできます。