2019年9月1日日曜日

Windows Server 2012 R2 Hyper-V と Windows Server 2019 Hyper-V 間での Hyper-V レプリケーション

色々調べたのですが、ドキュメントが見当たらなかったので試しました。

Windows Server 2012 R2 Hyper-V と Windows Server 2019 Hyper-V で各々 Hyper-V レプリカの設定を行います。
Windows Server 2012 R2 Hyper-V で仮想マシンを作成、今回は Windows Server 2012 R2 をインストールします。

仮想マシンでレプリケーションを有効にした結果は、下記の通りで、うまくいっています。
フェールオーバーして、素の OS としては問題なさそうな感じ。
※情報が見当たらないので、公式にサポートされるものかはわかりません。Your own risk ということです。上手くいかなくても当記事が責任を持つことはありません。

Windows Server 2012 R2 Hyper-V での Hyper-V レプリカ状況


Windows Server 2019 Hyper-V での Hyper-V レプリカ状況


Netjoin 4097 1316

物理機に入っていたドメインコントローラーを降格したものの、クリーンアップが不十分であった件。

ドメインコントローラーを降格しましたが、情報が残っていたので下記の対応を実施。
  • ntdsutilでクリーンアップを実行
  • DNSから該当ホストの情報を根こそぎ削除
  • サイトとサービスから、該当ホストの情報を削除
だけど、相変わらずドメイン参加できない。


本記事のタイトルで調べてみました。

Windows Server 2012 Standard - Domain Join Failed
にコンピューターアカウントも削除せよとあったので、削除。ちなみに画面取り損ねたのですが、ドメインコントローラーとしてコンピューターアカウントが存在してました。。。これが直接の原因ですね。
※同じコンピューターアカウントを使う予定で削除していなかったのが、良くなかった。

Visual Studio Code に Remote WSL が入ってた

Visual Studio Code をアップグレードしたら、Remote WSL なるものが入った旨、右下に表示されまして。


これはナンダ?となりました。

調べてみると、Visual Studio Code の Insider で既に使えるものでした。
VSCode + WSL

使い方は、Remote - WSL に記載ありました。
かかれている通りに、やってみましたよ。

新しいウィンドウを開いて

で、こうなりました。


現在の環境は、Ubuntu 18.04 のみなので、Visual Studio Code で開けると、これはこれで楽ですね!

2019年8月25日日曜日

Windows Admin Center 1908 リリースされてます。

Windows Admin Center 1908 リリースされてます。

インストール時のダイアログを比較したところ、変更点があります。1908の変更点である「HTTPS を利用した WinRM」を使うか指定できます。
1907の場合、「HTTPS を利用した WinRM」を使うか指定は、無し。


1908の場合、「HTTPS を利用した WinRM」を使うか指定がありますね。

このダイアログにあるということは、証明書の変更と同じように、設定変更できるかな?

できなかった。。。インストールもしくはアップグレード時に設定変更してください。

1907 で確認し忘れていた、仮想マシンインポート時、名前が重複する際、別名を提案してくれる機能は、こんな感じです。


接続の追加、UIが変更になってます。タイル状のUIになってます。タイルと押した後のUIはあまり変わらないかな。(見出しの文言が変わった感じ)
共有接続の場合

通常の接続の場合


セキュリティ機能で、Windows Defender の状態が見れる画面です。



これ以外にも、1908の変更点があります。別稿で確認していきます。

Windows Server な仮想マシンで NIC の MAC Address 設定を切り替えてみる

Azure Site Recovery というか、Hyper-V レプリカの絡みで挙動確認、備忘録として残します。

CentOS の挙動確認したので、Windows Server だとどうなるの? というエビデンスが必要になった次第。
※ CentOS の挙動確認 も、備忘録として残しておきたいところ。。。

結論としては、同じ NIC (いわゆる"イーサネット n")のままで IP アドレス情報を維持しています。ただ、MAC Address はちゃんと変わってました。

第1世代仮想マシン Windows Server 2012 R2
動的から静的に変更した画面キャプチャーです。



NIC 、IP アドレスは変わらず。


静的から動的に変更した画面キャプチャーです。


NIC 、IP アドレスは変わらず。


第2世代仮想マシン Windows Server 2012 R2
動的から静的に変更した画面キャプチャーです。



NIC 、IP アドレスは変わらず。


静的から動的に変更した画面キャプチャーです。


NIC 、IP アドレスは変わらず。


第2世代仮想マシン Windows Server 2016
動的から静的に変更した画面キャプチャーです。



「NIC 、IP アドレスは変わらず」の画面撮り忘れ。。。
まあ、ここは同じ MAC Addressだからということで。

静的から動的に変更した画面キャプチャーです。


NIC 、IP アドレスは変わらず。

2019年8月17日土曜日

Windows Server 2019のフェールオーバークラスタマネージャーから、ロック状態の仮想マシンをシャットダウンすると、停止になってしまうの?

フェールオーバークラスターマネージャーから仮想マシンをシャットダウンすると強制停止となってしまう事象について は、Windows Server 2016のフェールオーバークラスターマネージャーから、ロック状態の仮想マシンをシャットダウンすると、停止になってしまうというものです。。。

じゃあ、Windows Server 2019のフェールオーバークラスタマネージャーから、ロック状態の仮想マシンをシャットダウンすると、停止になってしまうの?
ということで、試してみます。

Windows Server 2019のフェールオーバークラスタということで、手元には、S2D の環境があるのでそちらで確認しました。
結論から申し上げますと、「Windows Server 2019のフェールオーバークラスタマネージャーから、、ロック状態の仮想マシンをシャットダウンすると、停止になってしまう」でした。
Nested の環境なので、画面見づらいですが、一連の流れを貼っておきます。








2019年8月11日日曜日

System Center Operations Manager の Web Console で SSL

まあ、2019に限らないと思いますが。

要は IIS で HTTPS のバインドを先に済ませておきましょう、というお話。

いままで、Web Console で SSL を使う構成ってやってませんでした。(オイオイ)
じゃあ、インストールのついでに Web Console で SSL 有効化してみるかと思い立ち。
インストーラーで、チェックを入れたところ、インストーラーに叱られる。。。


SANも定義済みな証明書をインポートしただけでは、だめですね。
IIS のコンソールを開きます。証明書は認識していますね。


HTTPSは、バインドされていないので、これが原因ですね。

先ほどの証明書をバインドしました。


一度チェックを外して、

チェックを入れ直すと、赤いバッテンアイコンが消えました。

これでつつがなくインストールを進められました!

インストール完了後、https で、Web Console を開いてみました。