2019年6月30日日曜日

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

第二水曜日を過ぎたので、Windows Server 2016、Windows Server 2019 を新規インストールした際のパッチ適用を具合を見てます。
※要は、オフラインでパッチ適用したい場合、どの更新プログラムを用意すればよいのかを把握するのが本稿の目的です。
 といっても、既に2週間以上経過していますので、あくまでも本稿執筆時点の状態ということです。ご理解いただけますと幸いです。
 いずれも、同一の Hyper-V ホストで動作する仮想マシンで確認しました。
 ほぼ同じタイミングで仮想マシンを新規作成し、アップデートし始めてます。
 仮想マシンを作成したのが午前10時ごろです。下記に記載ある適用確認の完了時間は、あくまでも当該環境のものです。実際の適用時間は仮想化基盤のパフォーマンスによります、ご注意ください。

Windows Server 2019の場合
今回、3回再起動しましたが、こちらが先に終わりました。

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

Windows Server 2016の場合
こちらも再起動が要ります。(2回再起動。イベントログから後日改めて確認します)
累積更新プログラムは、まず2018/05が必要です。
サービススタック更新プログラム(SSU)は、2019/06版がリリースされています。


Windows Server 2019と比較すると、「Windows Server 2016で再起動前の%表示となるまでが長い。」と、毎度思います。

2019年6月24日月曜日

Windows Terminal の Preview 版です

新しいターミナルアプリ「Windows Terminal」が“Microsoft Store”でプレビュー公開
とありましたので、早速ダウンロードしようとしたのですが、うまくいかず。

今日リトライしたらインストールできました。



現状、PowerShell、コマンドプロンプト、WSLとしていれている Ubuntu 18.04が選択できます。


ほかの WSL ディストリビューションを追加したらメニューに追加されるかは未確認です。
と思ったら、2019/05/07付の下記ページにインストール済みディストリビューション毎で選択できるようになっていますね。
MicrosoftはWindows向けの新しいコマンドラインアプリ「Windows Terminal」を発表

タブ間の切り替えは、CTRL+Tab で行けますね。
起動済みのコマンドプロンプトに切り替え


起動済み Ubuntu 18.04 に切り替え

※Windows Terminal の Ubuntu 18.04 は、system32 で開いてしまう。これはどうにかしてもらうようにフィードバックですかね。。。
 ちなみに、WSL 単体で起動するとこういうホームディレクトリになりますよ。

2019年6月15日土曜日

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 も読んでおくとよいですよ。

2019年6月9日日曜日

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

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



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

2019年6月6日木曜日

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を関連付けたところ、問題なく成功しました。


2019年6月2日日曜日

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
にできた旨、書いてみました。