Windows Admin Center 1804.25でHAを構成 その2 S2Dにインストールできるかな

結論、インストールできました。

Deploy Windows Admin Center with high availability
の前提条件をStorage Spaces Direct(S2D)も満たすからです。
※サポート的にはどうなんだろう？！

3ノードあるうちの一台に、

• High-availability deployment scriptsのスクリプト
• Windows Admin Centerのインストール用MSIファイル

を配置しました。

Windows Admin Center 1804.25でHAを構成
と同様の構成でインストール開始。


Windows Admin Center 1804.25でHAを構成
と同様にフォルダーが作成されています。


ログファイルもノード数分あります。

Windows Admin Center 1804.25でHAを構成

Deploy Windows Admin Center with high availability
に基づいて構成します。

• 2ノードのWindows Server 2016 failover Cluster
  iSCSIターゲットでクォーラムとCSV用のストレージを用意し、つないでみました。
  
• 10GB以上のcluster shared volume (CSV)ということだったので、16GBのCSVを上記の通り用意しました。
• High-availability deployment scriptsのスクリプトをダウンロード。
• Windows Admin Centerのインストール用MSIファイル

を用意しました。

High-availability deployment scriptsのスクリプトを展開。
Windows Admin Centerのインストール用MSIファイルを相対パスなどで指定できる場所に置きます。というか両方同じサーバーに置く必要があります。以降の画像を見てもらえるとわかりますが、フェールオーバークラスターの1ノードだけで作業すればOKです。

High-availability deployment scriptsのスクリプトには、インストール、アップデート、アンインストールが用意されています。
では、インストールのスクリプトを使います。

• -clusterStorage でCSVのパスを指定
• -clientAccessPoint でWebのアクセスポイント名を指定
  ここで指定されたものが、クラスターのサービス名、DNSエントリーとして登録されます
• -staticAddress でWebのアクセスポイント名用の静的IPアドレスを指定
• -msiPath でWindows Admin Centerのインストール用MSIファイルをパスで指定
• -generateSslCert で自己署名証明書の生成を指定

というオプションでインストールしました。

インストールは5分ほどで完了です。


DNS登録済み。

クラスターのコンピュータアカウントとして登録済み。

フェールオーバークラスターのサービス名としても登録済み。


Webアクセスポイントにアクセスすると、ツアーの画面が出まーす。



さて、
Interact 2018
では、この記事の内容に加え、インストール用スクリプトの中身、インストール先のデータフォルダー配置、容量、証明書の変更なども突っ込んでご説明いたします～

Windows Admin Center 1804.25でもChromeだと認証ダイアログ出まくる

1804.25に上がりました。
Windows Updateで配信されてます。



で、設定がきれいに初期化されてるw
※グレーアウトしている部分でサーバーが一台しかない。



Browser Specific Issues
の既知問題に載っているのは、ワークグループ環境なんですが、症状自体はそれそのもの。。。


ちなみに、サポートを明確に表明していないFirefoxは問題無し！
※Edgeは別途確認予定。

しらべたらフィードバックしている人がいた。
Chrome may pop-up multiple credential prompts
ということで、コメント残すとともに一票投じておきました。

Project Honolulu 改め Windows Admin Center いれたよ

Project Honolulu 改め Windows Admin Center がGAしたので、早速入れてみました。

これまで確認してきたインストールファイルとともに。


Windows Admin Center のインストール開始。最初はライセンス条項を受け入れからです。


チェックして、受け入れ。[Next]ボタンを押します。


デスクトップにショートカットを置きたいので、

チェックを入れて[Next]ボタンを押します。


ここで、接続先ポートと証明書を選択します。
SCOMのWebコンソールで443を使っていますから、10443にままとします。

自己署名証明書を新規作成するので、ラジオボタンで設定を変更します。

[Install]ボタンで、開始。
インストール中。


インストール完了。


早速アクセスしてみてます。
画面ごとに認証を求められるのは、この環境だけなのでしょうか。。。



というわけで、サーバーの管理画面は見えました！


さて、そろそろ自己署名証明書ではなく、エンタープライズ証明書を入れようかと思っています。
そこで、どうやって変更するのかを調べておきます。
とはいえ、Windows Admin Center の管理画面では変更できないです。
そこで、コントロールパネル経由でできないかを探ります。


変更でダイアログを進めていったら、証明書の拇印を入れる項目があります。
インストールの最後と同じです。


ここで、インストール前に取得しておいた自己署名証明書の拇印を見ておきます。




Windows Admin Center をインストールすると自己署名証明書ができています。

拇印はこちら。

でも、使っている自己署名証明書は、これではなかったです。

設定されているのは、

でした。
よって、こちらの60日期限な自己署名証明書を使っています。

これで、証明書の差し替えはできそうですね。

Project Honoluluは、MMCを置き換えようとしているのか

答えはYesですが、サーバー管理が当面の目標に見えますね。
Q: Is Honolulu a complete replacement for all traditional Microsoft Management Console (MMC) tools?
にその答えがあります。

逆に対応していない点についても、上記に言及があります。
基本的には、RSATで提供される「役割と機能」に関するものですね。記載されている情報を抜粋しておきます。

• AD関連、グループポリシー
• クラスター関連
• DNS、DHCP、リモートアクセス、RRAS
• ファイル関連（DFS、FSRM、iSCSIイニシエーター）
• プリント管理
• NLB
• パフォーマンスモニター
  タスクマネージャーのパフォーマンス相当は、現在のHonoluluでも表示できます。が、パフォーマンスモニターの粒度は対尾いうされていません。
• シールドデータファイル
• タスクスケジューラー
• ボリュームアクティベーション
• WSUS

上記ページは、ほかにもサポートOSや、コスト、Hyper-V Serverの管理に対する回答が書かれているので、ご一読をお勧めします。
FAQページとしてのリンクを下記に再掲しておきます。
Microsoft Project Honolulu Frequently Asked Questions

Project Honolulu 1803のDedupで有効化できたみたいだけど

Project Honolulu 1803のDedup使ってみてるんですが、
から、2時間半ほどほったらかして置いたら、DeDupを有効化したCSVの状態が採れるようになってました。
※仮想マシンでやっているPoCゆえにこの所要時間なのかは、わかりませんが。

こちらは、PowerShellを実行したのは17079です。情報取れていますね。

でもHonolulu HCIの方は、Onになっているように見えないけど？！

DeDup指示から5時間ほど経過したけど、状態の変化なし。


17093はどうなのか見てみます。
まだget-dedupstatusには何も出てきてない。

DeDup指示から4時間ほど経過しましたが、こちらは変化なし。


17079は動きつつあるようなので、仮想ハードディスクの重複排除を別途確認してみます。

Project Honolulu 1803のDedup使ってみてるんですが、

Announcing Project Honolulu Technical Preview 1803 and RSAT Insider Preview for Windows 10
Hyper-Converged Infrastructure
項を深堀してみます。

DedupのOn/Offは、実際、こんな感じになっています。
※赤枠内がOn/Offの制御です。
また、S2DのReFSでDedupをサポートするのは17074以降です。本稿は、17079を使います。あと17093も必要に応じて使います。


以前、下記の記事を書いています。

1. Windows Server Insider Preview Build 16278でReFSのデータ重複除去を試してみる その1
2. Windows Server Insider Preview Build 16278でReFSのデータ重複除去を試してみる その2
3. Windows Server Insider Preview Build 16278でReFSのデータ重複除去を試してみる その3 上手くいった！

というわけで、Dedupの役割機能が入っているか確認します。
Windows Server Insider Preview 17079は、Server Coreですから、Project Honoluluはとても便利に使えますね。
※画像は1台だけですが、4ノード分確認済み。


Dedupの役割機能が入っているので、安心してOnを実行。
確認ダイアログが表示されます。


Dedeupのモードを聞かれますので、Hyper-Vを選びます。


と、エラー発生。。。

通知はこういう状態。


dedupのジョブはあるようです。。。


比較のために、17093を見ていきます。
まず、Dedupの機能が入っていないので、有効化しなければなりません。
役割機能をインストールします。

依存関係のある役割サービスも一緒にインストール。たぶん必要ないはずだけど、再起動が必要であればそうするようにチェックぼっくをチェック。

進捗状況は、通知で確認できます。

役割サービスのインストール完了。

と、これを4ノード分実施完了。


17093なS2Dでも、CSVのDeDupを有効化してみます。


これもまたエラー。

結果、二つのversionがGetting thingになってしまって。。。

DeDupのジョブはあるのだよな。。。


最新の17623なS2Dでなければだめなのだろうか？！
というわけで、続く。。。