dism /Online /Cleanup-Image /RestoreHealth でエラーが起きた

トラブル発生後のリカバリで、dism /Online /Cleanup-Image /RestoreHealth を実行したときのこと。

エラーを修復できないから、Sourceオプションを指定せよとのメッセージが。。。

Sourceオプションと聞けば、install.wimの何番目を指定する形だよなと思いつつ、もう少し簡単にできないのかと思い、調べてみました。結果、

DISM で 0x800f081f エラーになる。

を見つけました。
※こちらのサイトが役立ちましたので、この場をお借りして御礼申し上げます。）

これによると管理共有経由で、別サーバーのc:\windowsを指定すればよいとのこと。早速試してみました。

うまく復元でき、大変助かりました。

System Center Virtual Machine Manager 2019 Update Rollup 4 (UR4)が出てます。

2週間ほど前に、

System Center 2019 Update Rollup 4

として、リリースが公になってます。

SCVMM 2019 UR4としての機能改善は、下記の通り（System Center 2019 Update Rollup 4より引用）

• Added support to manage Windows Server 2022 guest virtual machines.
• Smart card support has been added to enhanced session Mode in SCVMM Console
• Added support to manage Windows 11 guest virtual machines.

ということで、新しいOSは、ゲストOSでのみサポートしている状況です。

Windows Updateに出てこなかったので、手動インストールします。cabファイルから、mspファイルを取り出して、msiexec /updateを実行します。

アップデート中にVMMのサービスを止めてよいか否か聞かれます。これは止めてアップデートする方を選択します。

しばらく待つとウィンドウが終了します。

System Center - Virtual Machine Manager のビルド バージョン にて、UR4にアップグレードできております。

エージェントをアップグレードします。下記画面のようにアップグレードがある旨、メッセージが出ていなければホストを更新してみましょう。

※ちなみに、エージェントのファイルパスが分かるように、画面キャプチャーしておきました。

Run as Accountを指定して、[OK]をクリックします。

しばらく待ったのですが、エラーです。

ホストを更新してみましたが、問題ない。

lodctr /R

（最初の文字は、小文字のL）を実行して、WMIパフォーマンスカウンターを再構築したら良いという情報があったので、VMMサーバー側で試してみます。

がVMMサーバー側ではないようです。

SCVMM にクラスターを追加すると、エラー 2912 で失敗します (不明なエラー (0x800007d0))を見ると、ノード側ということなので、エージェントのアップグレード対象サーバーで、再度実行します。

まだだめ。

WMIのサービスを再起動してみるも、ダメです。

アンインストールして、再インストールを試してみます。

進まないな。。。

一度stopして、Refreshしたところ、表示されました。

やっぱりだめ。

エージェントの手動インストールができるか確認。VMMエージェントの新しいバージョンがインストールされていました。

アンインストールしてから、手動インストール。

VMMエージェント自体は、インストールされていました。関連付けが必要だと思ったのですが、なぜか居る？！

解せない挙動だ。。。

System Center Data Protection Manager 2019 Update Rollup 4 (UR4)が出てます。

2週間ほど前に、

System Center 2019 Update Rollup 4

として、リリースが公になってます。

SCDPM 2019 UR4としての機能改善は、下記の通り（System Center 2019 Update Rollup 4より引用）

• Removed file catalog dependency for online backup of file/folder workloads
• Added private endpoint support
• Improved reliability while restoring to original location when DPM agent is uninstalled
• Provided easy upgrade path from DPM 2019 UR3 to DPM 2019 UR4

さて、Windows UpdateにUR4が出てきてくれないので、

Update Rollup 4 for System Center 2019 Data Protection Manager

に基づいて手動インストールしてみます。

Microsoft Updateカタログから下記のファイルをダウンロードしました。

• dataprotectionmanager-kb5014054_ce0294f8f31dfa619376f326173518097e8befc2.exe
• dpmcentralconsoleserver-kb5014054_65a55717a4d701e19c83ae6b36e2d9d674ae4278.exe
• dpmmanagementshell-kb5014054_13a9077e6f38c6a176f01028dba8c3dddfc5e348.exe

実行ファイルを順にインストールします。

[dataprotectionmanager-kb5014054_ce0294f8f31dfa619376f326173518097e8befc2.exe]

ここでいったん再起動します。

dpmcentralconsoleserver-kb5014054_65a55717a4d701e19c83ae6b36e2d9d674ae4278.exe

は、上記で適用済みとなったようで、インストールが走りません。

dpmmanagementshell-kb5014054_13a9077e6f38c6a176f01028dba8c3dddfc5e348.exe

System Center – Data Protection Manager のビルド バージョン を確認したところ、UR4のビルド番号であることを確認できました。

以上です。そろそろ SCDPM 2022にアップグレードしてみないといけませんね。

Windows Server ＆ Cloud User Group Japan 第30回 勉強会動画 「Azure Arc Virtual MachineとAzure Arc Resource Bridge」を公開します

「Azure Arc Virtual MachineとAzure Arc Resource Bridge」をYoutTubeで公開します。

Windows Server ＆ Cloud User Group Japan 第30回 勉強会資料 「Azure Arc Virtual MachineとAzure Arc Resource Bridge」を公開します

Windows Server ＆ Cloud User Group Japan 第30回 勉強会資料　「Azure Arc Virtual MachineとAzure Arc Resource Bridge / VM provisioning through Azure portal on Azure Stack HCI (preview)」を公開します。

docswell、speakerdeckにもアップロードしました。Slideshareが閲覧できない場合にご利用ください。

Azure Arc Virtual MachineとAzure Arc Resource Bridge / VM provisioning through Azure portal on Azure Stack HCI (preview) by @sshzk

Azure Arc Virtual MachineとAzure Arc Resource Bridge / VM provisioning through Azure portal on Azure Stack HCI (preview)

PowerShellでAKS on Azure Stack HCIをデプロイしていたが、認証関連のエラーでハマった

Quickstart: Set up an Azure Kubernetes Service host on Azure Stack HCI and Windows Server and deploy a workload cluster using PowerShell

に基づいて、デプロイを進めていたときのこと。

Step 4: Log in to Azure and configure registration settings

Set-AksHciRegistration -subscriptionId "<subscriptionId>" -resourceGroupName "<resourceGroupName>"

を実行して、デバイスログイン後、認証が全く通らなくなりました。。。

そのあと、Connect-AzAccountは、通ったものの、サブスクリプションの切り替えでも同じようなことに。

何回かリトライしたのですが、ダメなので思いつくキーワードを入れて検索したところ、

【Azure】Unable to acquire token for tenant ‘xxxx-xxxx-xxxx’

を見つけました。

Clear-AzContextを実行してから、Set-AksHciRegistrationを実行したところ無事とおりましたよ。

Azure Stack HCIにデプロイ失敗した仮想マシンリソースがなかなか削除できなかった

Azure PortalからAzure Stack HCIへAzure Arc VMを展開する

でAzure Stack HCIにデプロイ失敗した仮想マシンリソースがなかなか削除できませんでした。

結論から申し上げますと、オンプレミスのAzure Stack HCIとAzureが通信できてないと削除できません。Azure Stack HCIにデプロイ失敗しており、仮想マシン自体はAzure Stack HCI展開できていなくてもです。

赤枠内が、デプロイ失敗した仮想マシンリソースです。

仮想マシンを削除しているので、リソースは残ります。

NICのリソースを先に削除しても、リソースは残っています。

追加Diskのリソースを削除しても、リソースは残っています。

この辺りで、Azure Stack HCIが、Azureと通信できていないことに気づきます。

Azure Arc Resource Bridgeの仮想ネットワーク設定（仮想スイッチ指定）を間違えて環境を壊した

で、復旧させたところ、仮想マシンリソースが無事に削除できました。

以上、デプロイ失敗した仮想マシンが、Azure Stack HCIに無くとも、Azure Stack HCIとAzureが連携していることが分かり、理解が深まりました。

Azure Arc Resource Bridgeのアンインストールが途中でうまくいかない

環境をクリーンアップするため、

Azure Arc リソース ブリッジをアンインストールする

に基づいてアンインストールしていたときのこと。

Kubernetes 拡張機能を削除します。

az k8s-extension delete --cluster-type appliances --cluster-name $resource_name --resource-group $resource_group --name hci-vmoperator --yes --verbose

 の部分で、タイムアウトしてしまいます。

タイムアウトまで1時間強かかりますー。
結局、合計3回試したのですが、いずれも失敗。forceオプションないのかなと思って

az k8s-extension delete

を見たらありました。--forceオプションを付加して再トライ。

48秒で無事完了しました。

この後、最後のステップまで無事完了し、Azure Arc Resource Bridgeのアンインストール完了しました。