DELL EMC OpenManage Integrationから、DELL PowerEdge （Azure Stack HCI 用の AXノード含む）の情報を引っ張ってこれない場合があると教えてもらいました。
DELL EMC OpenManage Integration With Microsoft Windows Admin Center（OMIMSWAC）がホスト情報のクエリーに失敗する
今回のケースは、エラー2でした。再現させるために、PowerShell 実行ポリシーを Restricted に変更したところ、事象が再現しました。。。
PowerShell 実行ポリシーを RemoteSigned に変更したところ、事象は解消。
追伸
DELL EMC OpenManage Integration は、2.1.0がリリースされているようですー
エラーコード 0x0000142 を含む画面は、下記にあります。
Can't use remote powershell or console to containers: winpty-agent.exe error
これから解決に向けて、いろいろ調べることになりますが、下記が参考になるのではないかと考えています。可能性としては、権限の問題なのか、ウィルス対策の除外なのか？！
Azure Bastion FAQ - VNet peering
がありましたので、改めてどういうことができるのかを確認しました。
上記 docs 文書にある見出し部分について、日本語への意訳をまとめておきます。
※別途、検証しないとな。
Azure Bastion Standard SKU public preview
なる記事を見つけました。
この SKU だと下記が使えるそうですね。
Azure IaaS で NAT 仮想スイッチを構成 その1からの続き
作ってみて、動きを理解するために、tracert を実行してみます。
NAT ネットワークのセットアップ
入れ子になった仮想化による仮想マシンでの Hyper-V の実行
のコマンドを入力していきます。（一部アレンジしてます）
New-VMSwitch -SwitchName "SwitchName" -SwitchType Internal
諸々の方々がすでに下記の記事を書いてくださっています！
とはいえ上記記事の紹介だけでは、ここに書く意味が薄いです。。。
各操作で何が起こっているのか、図を描いてみようと思い立ちました。そもそも図を描いてみようと思ったのは、PowerShell コマンドレットを順に追っていたものの、何が起きているかイメージしにくかったからなんです。そのため、理解が違っているところは、ご指摘いただきたいと考えています！
図を描くための元ネタとしては、下記を引用させてもらうことにしました。
NAT ネットワークのセットアップ
入れ子になった仮想化による仮想マシンでの Hyper-V の実行
最初のコマンドレット実行する前の状態は、下記だと思ってます。
最初のコマンドレット
New-VMSwitch -SwitchName "SwitchName" -SwitchType Internal
を実行すると、下記の状態になると思ってます。
次のコマンドレット
New-NetIPAddress -IPAddress <NAT Gateway IP> -PrefixLength <NAT Subnet Prefix Length> -InterfaceIndex <ifIndex>
を実行すると、下記の状態になると思ってます。
NAT ゲートウェイを構成されるので、Azure IaaS の仮想ネットワークに紐づく vNIC にトラフィックが行くようになるはず。ここの理解がちょっと怪しい。。。
次のコマンドレット
New-NetNat -Name <NATOutsideName> -InternalIPInterfaceAddressPrefix <NAT subnet prefix>
を実行すると、下記の状態になると思っています。
仮想マシンに、NAT ネットワークの IP アドレス、サブネット、NAT ゲートウェイをデフォルトゲートウェイにすると、通信できると理解しました。
というわけで、ここの解釈が違うといったコメントをお待ちしてますー。
Windows Server 2022 Insider Preview が一時的のホールドされています。
Visual Studio Subscription でリリースされている Build 20348.1を用いて、記憶域スペース ダイレクトの展開に基づき、(毎度ですがNested Hyper-V で) Storage Spaces Direct を組んでみました。
TrustedHosts、役割と機能の追加、SET の構築を済ませて、ディスククリーンアップを行います。
テストクラスターは、想定通り警告が出たもののパスしました。
クラスターを作成します。
Storage Spaces Direct を組みます。
Windows Admin Center 2103.2に登録してみました。
CSV を作ります。
リザーブ領域を確保した状態で、3つの CSV を作成しておきました。
Windows Admin Center 2103.2にプリインストールされている、リモートデスクトップ拡張でリモートデスクトップできなくて焦った話。
※すべての環境でこうなるとは限りませんので、ご注意ください。
事象がおこったリモートデスクトップ拡張のバージョンは、1.101.0です。
上記バージョンでは、リモートデスクトップ接続できなくてエラーになります。そして Windows Admin Center 自体も不安定になってました。
※Windows Admin Center サービスの再起動でもダメで、OS再起動して解消してみたり。
こんなこともあるといった感じです。
のエントリー自体は、理解していたつもりでした。が実際に自分でやっているとうまくいかないこともあり、結構焦りましたね。。。しかも今回同じ NIC が4ポートあったため、結構やっつけな手順になってしまいました。
OSのインストールメディアから、起動してウィザードを先に進めます。
[コンピューターを修復する]をクリックします。
[トラブルシューティング]をクリックします。
[コマンド プロンプト]をクリックします。
Windows PE のコマンドプロンプトから、startnet を実行します。
startnetが完了したタイミングで、wmicコマンドで VLAN を付与しようとしても、名前空間がない旨、エラーです。
結果、ベアメタルリカバリー時に VLAN 設定したい の最下部にある手法を試しました。
Windows PE のコマンドプロンプトから、レジストリエディターを起動します。
今回同じ NIC が4ポートあったため、全てに VLAN ID 付与しました。
※諸事情により、画面キャプチャは無し！
このレジストリ編集は、Windows PE に対するものです。リカバリーが完了すると VLAN の設定は揮発します。
そのあと、
netsh interface set interface NIC1 disable
netsh interface set interface NIC1 enable
みたいな感じで実行したところ、デフォルトゲートウェイに ping が疎通しました。
※実際には、NIC 4ポートすべてに上記を実施しました。決め打ちで設定したことによる手戻りが怖かったのです。
あー良かった。
