WindowsServer2022 OS Build 20348.1547 の仮想マシンが起動しなくなる現象について

いきなり長いタイトルですが、障害が起きた時の事をネタにするとこんなもんですね。

というわけで本題
この現象は、vSphere ESXi 6.7 U2/U3 vSphere ESXi 7.0.x
且つ仮想マシンOSが
WindowsServer2022 アップデートKB5022842 (OS Build 20348.1547）で
セキュアブートが有効に構成されていると発生します。
※セキュアブートはデフォルトで有効 ←ここがポイント

何が起きるかと言うと、

VMが起動できなくなります！

SecurityViolation でvDiskが見えなくなっちゃうのです。

 

この現象の正体に気付かないと、俺みたいに「vm壊れちゃった？」って何度もvm作り直すという無駄な苦労をする事になります。

 

この現象の回避方法は既に幾つかリリースされています。

１：セキュアブートを無効化する
２：Microsoftから2023年3月14日にリリースされたWindowsServer2022 KB5023705 をインストールする
３：Vmware ESXi 7.0U3k にアップデートする

※ vSphere ESXi 6.7 U2/U3 自体にはパッチは提供されていません

現実的なところで、簡単な回避方法は１のセキュアブートを無効化する１択って事なんでしょうか。

 

実際セキュアブートを無効化する方法です。

vSphere上で仮想マシンのサマリから、仮想マシンのハードウェアの”編集” 

／設定の編集／ 仮想マシンオプションタブ ／ 起動オプション

まで展開しないと設定項目が見えません。

この部分の「セキュアブート」のチェックを外して「OK」をクリックすればOK

※ この設定は仮想マシン稼働中でも設定可能です。

今更だがVM環境のWindowsServer2019 Build1809 のライセンス認証問題をちゃちゃっと解決してみた（対症療法

職場の仮想基盤で運用しているWindowsServer2019は以前からライセンス認証がある日突然外れたりして”なんか変な動き”をしていたのだが、どうせ基本塩漬けだしまあいいか、、、という超テキトーな管理をしていた。（おい

※誰もツッコむヤツいないし、、、

 

しかしながらいい加減「ライセンス認証しろやヴォケ！」っていういわれなき表示に消えていただきたくなったため色々調べ始めた。

ところがなかなか日本語のサイトでハマるところがない、、、

なんででしょ？クソどマイナーな問題は日本のTech系ブロガーさんは書かないんですかね？ 個人的には「ってか書けよ！」とか思っちゃうわけですがｗ

という事で辿り着いたのは海外のブロガーさんのサイトでした。
同時期に同僚と調べ始めてほぼ同時にこのサイトに行き着いたというのもなんだかなｗ

martinssblog.dk
Windows Server 2019: Activation fails on a freshly installed server!

この問題、WindowsServer2019 build 1809 でのみ発生する事象だったんですね。

ウチの環境ドンピシャｗｗｗ

で、この問題の解決方法は、、、

コマンドプロンプトで認証キーを打ち込んで終了！！！！！

「ナ！ナンダッテー！！」

MSサイトとの接続云々ばかり気にしてた俺に謝れ！ヽ(｀Д´#)ﾉ→MS

 

というわけでやってみました、、、

あっと言う間に終わったｗｗｗ

 

打ち込むコマンドはこちら

c:\cscript c:\windows\system32\slmgr.vbs /ipk 「プロダクトキー」

超カンタン！！

注意：わかってると思いますが、プロダクトキーはハイフン付きで入れてくださいね

 

 

、、、そういえばvSphere 6.7 U3 環境で今まで作ったWindowsServer2019 何台あったっけ？(´・ω・`)
※説明しよう、、、vSphere 6.7 U3環境ではWindowsServer2019は「Microsoft Windows Server 2016 or later (64-bit)」としか表示されないので、WindowsServer2016以降のサーバーと混在してしまうのですｗ 良い子のみんなは仮想マシンのメモ欄にOSのバージョンを入れておこうね！ｗｗｗ

Citrix Virtual Apps and Desktops Standard for Azure の接続障害（実は2日目）

昨日からCVAD環境（Citrix Virtual Apps and Desktops Standard for Azure）で接続障害が多発している。

昨日より今日の方が酷い、、、

しかも、Citrixの管理コンソールからコントロールできないって草も生えない

導入当初から疑わしかったのですが、CitrixとAzure親和性悪すぎだろ。

○○からは操作できるけど、△△からは操作できませんとかね、DaasサービスでこっちはAzure側触れないのに、Azure側で操作しないと直らない（→のちAzure側でも修正不能）とか

 

ないわー！！！

 

 

しかも！！！

障害出て状況確認やらしてる最中、

、、、管理コンソール落ちやがったｗｗｗｗｗ

 

 

タノムヨ、、、

DRサイトの障害祭り勃発

週末に会社のスマホに送られてきたDRサイトのサブ回線の通信断を知らせるメールはほんの序章だった。

月曜日：

• サブ回線の通信機器が電源ランプ以外全部沈黙していることが発覚！

火曜日

• HPEのESXiホスト1台でキャッシュバッテリーエラー
• QNAPのディスク障害
• サブ回線はNTT対応が必要→日程調整

水曜日

• HPEのホストは保守期限切れたばかり
• 何故かQNAPの通信設定の一部がおかしくなってて、ログ抜く前にアプリのアップデートができない。

とりあえずQNAPは通信設定を直してログ落として業者に送って、オンサイト作業の日程調整待ちとなった。

通信回線の調査は明日に決まったんだけど、まだ作業者の情報が来ないな。。。

 

ってか保守期限切れた途端壊れるHPEのホストって、、、

 

なんか「ソニータイマー」を思い出してしまったｗｗｗ

vmware Site Recovery Manager を構築してみる（その1）

これから数回に渡り、vmware Site Recovery Manager（SRM）について書いてみたいと思う。

初回は前提条件について


メインサイトとDRサイトで同仕様の環境を構築し、データセンター間をL2回線で結ぶ構成。

ウチの機器構成は3Tierの構成なので、

・ESXiホスト
・仮想環境用ストレージ
・ファイルサーバー

及び、それらを繋ぐネットワーク基盤からなる。



ホストはHPEとDELL
仮想環境用のストレージはTintri EC6075
ファイルサーバーはNetApp AFF C190
ネットワークはAruba 5400R


仮想サーバーは殆どがWindowsServer


ドメイン構成の場合には、これらの環境の他も必要なものがある。


ドメインコントローラー(DC)だ

DCは、メインサイトには当然存在するが、DRサイトにも必要になる。

しかも物理サーバーで（笑）

これはSRMがDCのSRM移行を推奨していないためだ。

それにはちゃんとした理由があって、もしもDRサイトで立ち上げた仮想のドメインコントローラーの情報に齟齬がある場合に、他のサーバーに不具合が起きる可能性があるためだ。


DRサイトのドメインコントローラーなんて仮想で十分だろって思ってた俺は、SRM構築の前段階として久しぶりに実機でDCを構築する羽目になりました。