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の実行がようやく成功。。。

Windows Server Insider Preview 26085で、Hyper-VクラスターというかStorage Spaces Direct関連の役割サービスをみてみた

Windows Server Insider Preview 26085で、Hyper-VクラスターというかStorage Spaces Direct関連の役割サービスは、なにか変わったのかを現時点のスナップショットとして調べました。

参考にしたのは、下記の二つです。

• Deploy Azure Stack HCI on a single server
  に記載されているコマンドラインとしては下記のとおりです。
  Install-WindowsFeature -Name "BitLocker", "Data-Center-Bridging", "Failover-Clustering", "FS-FileServer", "FS-Data-Deduplication", "Hyper-V", "Hyper-V-PowerShell", "RSAT-AD-Powershell", "RSAT-Clustering-PowerShell", "NetworkATC", "Storage-Replica", "NetworkHUD" -IncludeAllSubFeature -IncludeManagementTools
  ※役割サービスがここにしかないようなので、いったんこちらを参照しています。ご了承ください。
• Deploy Storage Spaces Direct on Windows Server > Step 1.4: Install roles and features
  Install-WindowsFeature -Name "Hyper-V", "Failover-Clustering", "Data-Center-Bridging", "RSAT-Clustering-PowerShell", "Hyper-V-PowerShell", "FS-FileServer"

Azure Stack HCI OSとWindows Server Insider Preview 26085の差異を見ます。そこでDeploy Azure Stack HCI on a single server に記載されているコマンドラインをそのまま実行してみました。結果としては、NetworkHUD がWindows Server Insider Preview 26085にないため、失敗です。

で、結果として下記で役割サービスをVHDXに対してインストールして成功しました。

Install-WindowsFeature -Vhd "E:\Hyper-V\wsip26085hv01\Virtual Hard Disks\127GB.vhdx" -Name "BitLocker", "Data-Center-Bridging", "Failover-Clustering", "FS-FileServer", "FS-Data-Deduplication", "Hyper-V", "Hyper-V-PowerShell", "RSAT-AD-Powershell", "RSAT-Clustering-PowerShell", "NetworkATC", "Storage-Replica" -IncludeAllSubFeature -IncludeManagementTools

上記にNetworkATCが含まれています。Get-WindowsFeatueの実行結果からも、NetworkATCがWindows Server Insider Preview 26085に含まれていることを確認しました。

Windows Server 2025のリリース時点でどうなっているかは予想できませんが、Windows Server Insider Preview 26085ではこのような状態であるということです。

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

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

いくつかのOSで回復パーティションサイズを確認した。

Windows 10向けの更新プログラム「KB5034441」が、Windows Update適用時に「0x80070643」エラーとなりました　解消しました！

にて回復パーティションのサイズが重要だとわかりました。また、ITライターの山内氏より下記記事がある旨、ご連絡いただきました。

Windows 10／11で「2024年1月の更新プログラム」のインストールが失敗（エラー0x80070643）！　その原因は？

ご連絡いただいた際、下記の情報を連携いただいたこと、申し添えます。上記記事含め、改めて御礼申し上げます。

• UEFIパーティション要件を鑑みると、最終的に空き52MB+5～15MBのあきがあれば成功するはずだろう。
• Windows 22H2以前なら+50MBくらいで成功すると思います。Windowsセットアップの既定だと確か83MBくらいの空きで回復パーティションを作る故。

いろいろ情報を教えていただきました。GUIかdiskpartのいずれかで、Windows Server系の回復パーティションの配置やサイズをメモしておきます。

Windows Serve 2016

450MBで先頭に配置されているサーバーがありました。

Windows Serve 2019

全3台で確認したところ、499MBで先頭に配置されているサーバーがありました。
※全3台ともOSインストール時に、手動でパーティション作成していません。おそらくこれはパターンの一つでしょうかね。

Windows Serve 2022

597MBの回復パーティションが一番後ろにあります。

Azure Stack HCI OS 22H2

515MBの回復パーティションが一番後ろにあります。

遅まきながら、Convert-WindowsImageによるISOファイルからVHDXファイル生成

だんだん検証用途の環境がおかしくなっているような気がして、Convert-WindowsImageによるISOファイルからVHDXファイル生成に手を出すことにしました。

いろいろ探したところ、下記が一番新しそうです。

https://github.com/x0nn/Convert-WindowsImage

下記のコードでWindows クライアントで試したところ、うまくいきました。

$IsoPath = "C:\Sources\20349.1129.221007-2120.fe_release_hciv3_svc_refresh_SERVERAZURESTACKHCICOR_OEMRET_x64FRE_en-us.iso"

$VhdFormat = "VHDX"

$SizeByte = 127GB

$DiskLayout = "UEFI"

$VhdPath = "C:\Sources\g2azshcios127GB.vhdx"

Convert-WindowsImage -SourcePath $IsoPath -VHDFormat $VhdFormat -SizeBytes $SizeByte -DiskLayout $DiskLayout -VHDPath $VhdPath 

-RemoteDesktopEnable

※Set-ExecutionPolicy Unrestricted -Scope CurrentUser などでPowerShellの実行ポリシーは事前に変更ください。

このConvert-WindowsImageコマンドレットには、-Featureオプションで役割と機能を追加できるようなんです。ただ書き方が悪いのかうまくいかない。

役割と機能の追加については、Install-WindowsFeatureを使えばよいですね。

ここまでWindows クライアント上で実行していました。がWindows クライアントではInstall-WindowsFeatureが、使えないわけです。Windows Server上に移動して続行しましたよ。

2023年10月14日追記

-RemoteDesktopEnableは、うまく機能しない模様です。コンソール画面から改めてリモートデスクトップを有効化しました。

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を送信」をクリックすればログオンできます。

Az.StackHCI、Az.Resources、Az.ccountsを最新化するPowerShellスクリプト

Az.StackHCIモジュールのバージョン違いによる挙動なのか否か での気付き（凡ミスを繰り返したくない）をもとに、メンテナンスを簡素化することとしました。

元ネタは、Uninstall older versions of PowerShell after successful upgrade に記載がある古いPowerShellモジュールを削除するスクリプトです。

こちらをもとに、Update-Moduleをコードに追加、更新および古いモジュールを削除する対象としてAz.StackHCI、Az.ccounts、Az.Resourcesを指定した下記を作成しました。

※後ほどこの並びだとダメだと、スクリプトの動作確認で判明します。。。

太字部分が追加や変更したコードです。

$modules = @("Az.StackHCI", "Az.Accounts", "Az.Resources")

foreach($module in $modules)

{

    $current = Get-InstalledModule -Name $module -ErrorAction Ignore

    if (-not $current)

    {

        Write-Host $("[Module: $module] Is not installed, skipping")

        continue

    } else {

        update-module -Name $module -Force

    }

    Write-Host $("[Module: $module] Newest installed version is $($current.Version)")

    $versions = Get-InstalledModule -Name $module -AllVersions

    foreach($version in $versions)

    {

        if ($version.Version -eq $current.Version)

        {

            Write-Host $("[Module: $module] Skipping uninstall for version $($version.Version)")

            continue

        }

        Write-Host $("[Module: $module] Uninstalling version $($version.Version)")

        $version | Uninstall-Module -Force -Confirm:$false

    }

}

スクリプト実行前は、下記の通りでした。

スクリプト実行後は、下記の通りとなりました。Az.Resourcesのスペルミスを修正したので、2回実行しました。Az.Resourcesがデグレードしているので、まだ改良が必要かなぁ。。。

依存関係の関係で、"Az.StackHCI", "Az.Resources", "Az.Accounts"の順で処理しないとだめでした。あと"Az.Accounts"は、"Az.StackHCI"の依存関係に伴いインストールされますね。

でも、別環境では、下記の通り新しいバージョンを削除しているので、改良が必要です。。。

ということで現時点のコードを下記に貼っておきます。（上記の改良はまだ未反映）

$modules = @("Az.StackHCI", "Az.Resources", "Az.Accounts")

foreach($module in $modules)

{

    $current = Get-InstalledModule -Name $module -ErrorAction Ignore

    if (-not $current)

    {

        Write-Host $("[Module: $module] Is not installed, skipping")

        continue

    } else {

        update-module -Name $module -Force

    }

    Write-Host $("[Module: $module] Newest installed version is $($current.Version)")

    $versions = Get-InstalledModule -Name $module -AllVersions

    foreach($version in $versions)

    {

        if ($version.Version -eq $current.Version)

        {

            Write-Host $("[Module: $module] Skipping uninstall for version $($version.Version)")

            continue

        }

        Write-Host $("[Module: $module] Uninstalling version $($version.Version)")

        $version | Uninstall-Module -Force -Confirm:$false

    }

}