Windows Subsystem for Linuxをアップグレードしなさいと

久しぶりにWindows Subsystem for Linux (WSL)のUbuntuを起動したところ、下記のメッセージが出ました。

コマンドラインの

wsl.exe --update

でアップグレードしました。

wsl -l -v

を実行してみましたが、細かいビルド番号が出るわけもなく、以前から使用しているWSL 2であることを確認しました。

ubutu的には、バージョンの変更ないな。

Windows Store的には、22.04.3があるようだ。

スタートメニュー上も、22.04.3となっている。

スタートメニューで検索した際に、下記も出ていた。新しくなってはいるようだ。

ubuntuを再インストールして、何か変わるか見てみる。

22.04.3に変わった。ということで下記を実行すればよかっただけかもしれない。

sudo do-release-upgrade -c
sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo apt autoremove
sudo apt autoclean
sudo do-release-upgrade

ということで、wslとwsl for ubuntuは別管理でよさそうかな。。。

ADドメインに参加しているメンバーサーバーのホスト名が変更できません。

過日、タイトルに記載した事象に遭遇しました。

検索キーワードをいろいろ試していく中で、下記を見つけました。

Windows ベースのコンピューターをドメインに参加させるときに発生するエラーのトラブルシューティング方法

に、NetSetup.log　をみると何かわかりそうです。所在は、%windir%\debug\Netsetup.log であることもわかりました。

実際に、内容を確認してみました。0x54fがエラーコードのようですね。

0x54fについて、調べてみたのですが、下記にあるような0x54bしか見つからない。。。

• Unable to join to domain
• エラー コードの0x54b

ログをさかのぼって見ていて、下記に目が留まりました。

NetpChangeMachineName: generated netbion name

ということです。NetBIOS名だとすれば重複できないと判断しました。

結果、いろいろご協力をお願いした結果、サブドメインに同じNetBIOS名のコンピューターオブジェクトがあると判明。。。サブドメインのコンピューターオブジェクトを削除したところ、無事に ADドメインに参加しているメンバーサーバーのホスト名が変更できました。

• シングルドメイン環境では、ホスト名の重複は検出しやすいと思います。
• シングルフォレストのマルチドメイン環境では、NetBIOSホスト名という観点で、ホスト名重複とみなされると理解しました。これはグローバルカタログでの検出になります。よってトップドメイン、サブドメインのすべてでホスト名重複を調べる必要有りです。

ということで、シングルフォレストのマルチドメイン環境で、ホスト名重複にご注意ください。

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ノードクラスター化する際に、不要なストレージ層を削除しても良さそうですし、削除しない選択肢もあるのかなと感じました。

Bastionでキーボード言語が選べるようになっていました

Bastionで仮想マシンに接続しようとした際、キーボード言語が選べるようになっていました。

これは、助かります。

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

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

Windows Admin Center 2311 の更新版その2 「1.5.2403.08001」がリリースされています

Windows Admin Center 2311 の更新版その1がリリースされていたのは、認識していました。が、最近、更新プログラムの表示が出ているので、リンク先を確認しました。

リンク先を確認すると、先月、Windows Admin Center 2311 の更新版その2がリリースされていました。以降、この更新版その2を「2312の2403ビルド」と略します。

ダウンロードして、2023年12月リリースのGA版とサイズ比較です。当然のように、2312の2403ビルドは、サイズが大きいですね。

インストールウィザードを見てみます。結論としてパラメーターは同じですね。

ビルド番号が1.5.2403.08001であることを確認して本稿を終わりとします。

Azure Network Managerってなに？

Azure Virtual Network Managerとも呼ぶようです。

トポロジー、セキュリティ、リージョン感のデプロイを安全に行うための機能だと認識しました。

機能を触ってみたいので、Network Managerを実際にデプロイしてみます。

サブスクリプション、リソースグループ、インスタンス名称、リージョンおよび利用する機能を指定します。

管理する範囲を選択します。

タグはとりあえず空欄のままとします。

概要を確認したら、作成します。

リソースに移動したら、エラーになりました。が気にせずちょっと待ってからリロードしたところ、概要が出ました。

デプロイしましたので、ネットワークグループを開いてみました。まだ何も無いです。

ネットワークグループを作ってみます。

ネットワークグループにメンバーとなる仮想ネットワークを追加します。リージョンは気にせつ仮想ネットワークを追加してみました。

メンバーの削除も可能ですね。

ネットワークグループのポリシーを見てみます。

Azure Policyの定義と割り当てが作成可能です。とりあえず作成しないで、そのままとしました。

構成を見てみます。既定では何も無いです。

「接続構成の作成」を進めてみます。

メッシュかハブアンドスポークを構成するための機能として捉えるのが良さそうですね！

ネットワークグループを追加します。

先ほど削除した別リージョンに対してネットワークグループをここで作成します。

複数のネットワークグループで構成したので、ハブを指定できます。

ハブアンドスポーク構成になりました。

構成の可視化を見てみます。

本環境は、すでにハブアンドスポーク的になっているので、作成は見送りました。

スクラッチから仮想ネットワークを作成する際、Network Managerを使えば容易にハブアンドスポーク構成を作れると感じます。（設計は事前に行なっておく必要ありますけどね）

セキュリティは、機会があれば確認したいな。