WSL 2を入れてみた

いろいろ記事になっているので、興味があって入れてみたいと。

Installation Instructions for WSL 2
を見ると、

Please note that you'll need to be running Windows 10 build 18917 or higher to use WSL 2, and that you will need to have WSL already installed (you can find instructions to do so here).

となっています。
※すでに WSL はインストール済みです、あしからず。

確認したところ、要件の build より低い。

Insider Preview の fast ring に変更します。。。

get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
を実行してみました。確かに disable です。


システム要件の build になりました。


Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
を実行します。

enable になったので、再起動します。

ディストリビューションの名前を確認して、WSL 2を有効にしてみます。

完了しました。
既定を WSL 2にします。


ディストリビューションがどの WSL になっているか確認したら、インストールは完了。


ウィンドウ自体が何か変わるわけではないですが、起動してみました。



入りましたので、いろいろ記事を参考にしながら、使ってみます。
あ、WSL 2 FAQ も読んでおくとよいですよ。

Windows Update からも Windows Admin Center のアップグレードできます

Windows Admin Center 1904が動作しているサーバーで、Windows Update を行ったところ、Windows Admin Center 1904.1 がリストに載ってきました。
残念ながらインストール前の画面ショットは取り損ねましたが、インストール後の画面ショットを下記に貼っておきます。



上記画像だと build 番号になっているので、改めてバージョンを確認しておきます。

Hyper-V Replica Broker を構成してから ASRを構成しましょう

フェールオーバークラスターを組みなおして、Azure Site Recovery(ASR)を構成しようとしたらエラー。。。

メッセージを見ると、両方のフェールオーバークラスターに Hyper-V Replica Broker が無いってことです。
※後でアドバイスもらったところ、下記にその旨、すなわち"Site Recovery doesn't support a VM in a Hyper-V cluster if the Hyper-V Replica Broker isn't configured for the cluster."がありました。
Analyze the Azure Site Recovery Deployment Planner report
要するに、フェールオーバークラスターで Hyper-V Replica を構成するのと同じ要件ですね。

両方のフェールオーバークラスターで、Hyper-V Replica Broker を作成しました。



というわけで、改めてレプリケーションにVMMを関連付けたところ、問題なく成功しました。

ASR で初期同期をオフラインで実行させようとしてハマった

Azure Site Recovery(ASR) で初期同期をオフラインで実行させようとしてハマったので、その顛末を記しておきます。
構成としては、プライマリーサイトにVMM、復旧サイトにVMMで、コントローラーとしての ASR があります。

レプリケーションポリシーで初期同期をオフラインで実行させようとして、
プライマリーサイトのエクスポート用途となるファイル共有と、復旧サイトのインポート用途となるファイル共有を指定したのですが。。。



それで、ネットを検索したら同じ目にあっている人はいましたが、解決策は書いてない。。。
Azure site recovery- replication policy for offline initial replication
上記エントリーの文面読んで、同じように隠し共有で構成しているなと。（ファイル共有名末尾に$がついています）
じゃあ、管理共有ではなく、通常のファイル共有にすればいいのではないかと。
プライマリーサイトのエクスポート用途となるファイル共有と、復旧サイトのインポート用途となるファイル共有は、まあ誰にでも触ってほしいものではありませんから、共有アクセス権は「ローカル管理者へのフルコントロールのみ」にしてみた。

リトライします。




プライマリーサイトのエクスポート用途となるファイル共有と、復旧サイトのインポート用途となるファイル共有の共有アクセス権、ファイルアクセス権を確認してみます。
プライマリーサイトのエクスポート用途となるファイル共有の共有アクセス権、ファイルアクセス権は、そのサーバー自体(今回はプライマリーサイトの Hyper-V ホスト)のコンピューターアカウントに権限がついています。



復旧サイトのインポート用途となるファイル共有の共有アクセス権、ファイルアクセス権は、、そのサーバー自体(今回は復旧サイトの Hyper-V ホスト)のコンピューターアカウントに権限がついています。


即ち、この権限が付与できないことでエラーになっていたと推測できます。

というわけで、
Azure site recovery- replication policy for offline initial replication
にできた旨、書いてみました。

VMM ライブラリと通信できていますか？

SCVMM 2019から仮想マシンを展開しようとしたら、こんな感じのメッセージが出ました。。。
vmm cannot locate a virtual hard disk that is marked as equivalent to the virtual hard disk with id GUIDの文字列
※すみません、画面取り損ねました。

色々調べたら、
SCVMM Template issue
に該当しそうな感じ。
VMM ライブラリは稼働していましたので、変な感じですよね。。。

まず、VMM ライブラリを疑似的に落として（NICを無効化等々、今回は仮想マシンなので保存状態にしてみました）、確認してみました。
が、再現しませんでした。。。

Windows Updateのどさくさに紛れたパターンも試してみました。


ふと、VMM データベースに仮想ハードディスク存在するが、VMM ライブラリに無い状態を作ればよいのかと。。。（ファイル名変更ですかね）
これも再現しない。。。

また再現するようなことがあれば、追記していきます。

Raspberry PI の Samba をファイル共有監視にして S2D 組んでみますよ

Windows Server 2019 の2ノード S2D では、ルーターに接続された USB メモリをファイル共有監視にできるというのがあります。
※詳細は、
　Windows Server 2019での記憶域スペースダイレクトの改善ポイント５つを公表。
　をご参照ください。

これについて、
「Raspberry PI の Samba でSMB2 が有効になっていればできるらしい」
と小耳にはさんだので試してみます。
まあ、「PoCとしてこういうこともできるよ」ということで読み進めていただければ幸いですー。

さて久しぶり過ぎて、Sambaが構成できなくなっておりましたが、
SAMBA: SET UP A RASPBERRY PI AS A FILE SERVER FOR YOUR LOCAL NETWORK
のパスをアレンジして構成しました。
net use での確認コマンドは、下記を参考にさせていただきました。
Windows：net use コマンドでネットワーク上の共有名に接続する

やっぱり常に触ってないとだめですねぇ。
ということで、4.5.16-Debian の導入完了。

testparm で確認できたコンフィグを載せておきます。
※ min protocol の部分は、
windows10にてsambaのファイルサーバーにアクセスできなくなった件について
を参考にさせていただきました。

pi@raspberrypi:~ $ sudo testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Processing section "[quorum2019n2]"
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
log file = /var/log/samba/log.%m
max log size = 1000
panic action = /usr/share/samba/panic-action %d
usershare allow guests = Yes
server min protocol = SMB2
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
server role = standalone server
unix password sync = Yes
dns proxy = No
idmap config * : backend = tdb


[homes]
comment = Home Directories
browseable = No
create mask = 0700
directory mask = 0700
valid users = %S


[printers]
comment = All Printers
path = /var/spool/samba
browseable = No
printable = Yes
create mask = 0700


[print$]
comment = Printer Drivers
path = /var/lib/samba/printers


[quorum2019n2]
comment = Pi shared folder
path = /var/samba/quorum2019n2
create mask = 0777
directory mask = 0777
guest ok = Yes
read only = No

上記構成のうち、quorum2019n2 共有を S2D の FileWitness に指定します。

2ノードの S2D を組んでいきます。
まずフェールオーバークラスターが有効化出来たら、ファイル共有監視を追加します。
Raspberry PI は、ワークグループですから、Set-ClusterQuorum で認証情報を指定しないといけません。
調べたところ、ムッシュのブログ記事を発見！
Windows Server 2019 の WSFC の機能拡張
Set-ClusterQuorum に -Credential $(Get-Credential) を加えれば大丈夫です。
実行結果は下記の通り。

Raspberry PI からファイル共有監視のディレクトリを確認した結果は、下記の通り。


OSディスク以外のクリーンアップが完了したら、


いよいよ S2D を有効化します。
※最新の累積更新プログラムが適用済みか念のため確認しておきましょう。

無事に有効化完了！


Get-VirtualDisk では、CSV となる仮想ディスクは作っていないので、"ClusterPerformanceHistory"だけしかありません。

Get-PhysicalDisk は、片方の OS ディスクが見えていますが、それ以外はデータディスクですー。


Windows Admin Center から CSV を作ってみましょう。



もう一度、Get-VirtualDisk を実行してみます。


以上です！

5月の第二水曜日、Windows Server 2016、Windows Server 2019 のパッチ適用

第二水曜日を過ぎたので、Windows Server 2016、Windows Server 2019 を新規インストールした際のパッチ適用を具合を見てます。
※要は、オフラインでパッチ適用したい場合、どの更新プログラムを用意すればよいのかを把握するのが本稿の目的です。
いずれも、同一の Hyper-V ホストで動作する仮想マシンで確認しました。

Windows Server 2016の場合

2019/05として新しいサービススタック更新プログラム(SSU)がリリースされていますね。


Windows Server 2019の場合
※画面キャプチャーで、日時が入れ忘れました...


これまでも何回か確認しているのですが、月次定例の更新プログラム適用状況は、Windows Server 2019 のほうがわかりやすいですね。
加えて、Windows Server 2019のほうが所要時間短いと思われます。（更新プログラムの数やサイズは、まったく同じではないですけれども）