クラウド監視の作成は、こちらがわかりやすい！

 Azure Stack HCI のドキュメントを見ていましたら、クラウド監視の作成がわかりやすい記事を見つけましたので、共有します。

Windows Admin Center を使用して監視をセットアップする
フェールオーバークラスターマネージャーを使うのとは、別の方法ということで覚えておくと役立ちますね。

クラウド監視として使用する Azure Storage アカウントを作成する
こちらが、冒頭で取り上げた内容です！

Windows PowerShell を使用して監視をセットアップする
こちらは、PowerShell にて、ファイル共有監視やクラウド監視をセットアップする方法です。

ちなみに、

フェールオーバー クラスターのクラウド監視を展開する

にフェールオーバークラスターマネージャー、PowerShell を使う方法も載っていますので、併せて参考にしてください。

Azure Update Management の「更新プログラムの展開のスケジュール」

 Azure Update Management の更新プログラム一覧を表示させてみました。

該当サーバーの Windows Update を実行してみました。。。先週、実行していなかったのか？！

ということで、実行しています。

それはさておき、Update Management には、更新プログラムをスケジュール展開できる機能があります。

下記のような画面です。

ということで、本稿の後半は、「更新プログラムの展開のスケジュール」を作成してみます。まずは[更新するグループ]をクリックして指定します。

フィルターを調整して、対象にするマシンを絞ります。下記のケースは、Azure サブスクリプションの含まれる仮想マシンを対象にしてみました。

更新プログラムの種類を指定します。規定値のまま、全て指定としています。

スケジュールを指定します。

[再起動のオプション]を指定します。既定値どおり、"必要に応じて再起動"にしています。

[作成]をクリックして、しばらく待つと完了します。

こんな感じでできました。

追伸

[更新プログラム]をクリックすると、こんな感じで表示されます。参考まで。

Windows Admin Center でクラスターの検証（プレビュー）

 Windows Admin Center でクラスターの検証（プレビュー）を試してみます。すでにクラスターノードの追加と削除は、実装されています。クラスターの一連の操作を Windows Admin Center から完結できる日も遠くないですね。
※Azure Stack HCI のデプロイは、すでに実装されていますしね。

クラスターに移動して、[詳細]→[クラスター検証（プレビュー）]をクリックします。

確認のダイアログが表示されるので、[はい]をクリックします。

開始されました。

CredSSPの有効化についての確認ダイアログが表示されます。[はい]をクリックします。

続行しています。

進んでいましたが、途中で表示が止まる。。。

しばらく待っていたのですが、しびれを切らしました。[詳細]→[検証レポートの表示]をクリックします。

結果が生成されてました。。。

Nested VM で S2D なのか、いくつか警告や失敗が出ていました。。。

Azure Update Management は、Azure Log Analytics と関連しているので Microsoft Monitoring Agent の接続設定も気を付けましょう

Windows Admin Center から Azure インテグレーションを設定する　5.2 Update Management Microsoft Monitoring Agnet は、両方につながるわけですが

も関連します。

Azure Update Management 側から、監視対象となるコンピューターを追加した際に、留意するポイントを書いておきます。

Azure Update Management には、すでにオンプレミス側のコンピューターを一台追加してあります。

こちらの Azure の仮想マシンを追加します。

同様の手順で、Azure の仮想マシンを追加しました。が、先に追加したほうがいつまでも表示されません。。。

んー、何だろうと思って該当のコンピューターで、色々見てみたところ、すでに Microsoft Monitoring Agent が導入済み。もしやと思って、見てみたら過去に使っていた SCOM の設定が入りっぱなしでした。。。

Management Microsoft Monitoring Agnet は、両方につながるわけですが

を見ていただきたいのですが、Azure Log Analytics は、エージェントとして、Microsoft Monitoring Agent を使います。この Microsoft Monitoring Agent は、SCOM のエージェントでもあるわけです。つまり

Microsoft Monitoring Agent = Log Analytics エージェント = SCOM エージェント

ということで、エージェントのバイナリ自体は、同じものが使えます。

ちがいは、接続先ということです。Log Analytics なのか、 SCOM なのかということですが、両方に接続も可能なのは、

Management Microsoft Monitoring Agnet は、両方につながるわけですが

にも書いています。

Azure Update Management は、Log Analytics と連携して動作します。

ということで、Azure Update Management で使えるようにするため、Log Analytics への接続設定を入れました。

これで、無事に Azure Update Management で管理できます。

[エージェントの更新の準備]で"構成されていません"と出ていた二つ目のリンクをクリックしてみました。

[チェックを実行]をクリックしてみました。

下記のような確認結果が表示されます。これ詳細が分かってよいですね。

最終的に３台とも、準備完了になっていました。

※Microsoft Monitoring Agent との通信が一時的に切れると、上記一覧から一時的に表示が消えることもあるようです。

以上

Azure Automanage を新規作成の仮想マシンで有効化してみる

まだプレビュー機能ですが、Azure Automanageというものが使えるようになっています。ベストプラクティスに基づく自動管理ということのようです。

Azure Automanage for virtual machines によるとまだ、西ヨーロッパ、米国東部、米国西部 2、カナダ中部、米国中西部ということですね。

米国東部リージョンにおいて、

クイック スタート:Azure portal で仮想マシンに対して Azure Automanage を有効にする
のうち、

新規の VM で VM に対して Automanage を有効にする
に基づいて、新規作成仮想マシンを対象に有効化してみます。

仮想マシンがデプロイできると、下記赤枠のようなリンクが出現します。
※上記リージョンにデプロイした場合ですよ

新規作成した仮想マシンは、このリンクをクリックして進めます。

とは言え、セットアップの画面は、下記だけです。

現時点で、AutoManage の構成プロファイルは、Dev/Testと運用の二つあります。そしてそのに含まれる構成の基本設定には、

• 仮想マシンの分析情報の監視
  運用のみに存在
• バックアップ
  運用のみに存在
• Azure Security Center
• Microsoft Antimalware
• 更新の管理
• 変更履歴とインベントリ
• Azure Automation アカウント
• Log Analytics ワークスペース

があります。構成の基本設定は、新規作成ができるようですから、ニーズ併せてというのも考慮できそうです。

各々の構成プロファイルにおいて、どういう構成がなされているのか画面を撮ってみました。
一つ目が Dev/Testです。

二つ目が運用です。

設定を確認したら[有効にする]をクリックして、有効化します。

しばらくすると完了するのですが、元の画面に戻ります。。。

通知には、完了した旨のメッセージが並びます。

AutoManage/自動管理のページに遷移したところ、まだ処理中となっていました。通知に完了した旨が出ていたとしても、処理が続いているということですね。

状態が"構成済み"になるまで、そこそこ時間がかかりますね。

構成済みになったので、先ほどの構成プロファイルで指定した Dev/Test が割り当てられたということでしょうか。

ということで、更新の管理（Azure Automation にある更新プログラムの管理）を覗いてみます。

仮想マシンをクリックすると、Log Analytics に移動して、さらに細かく状況が確認できますね。

仮想マシンへ個々の設定を入れていくことを考えると、自動管理という仕組みで簡単になると考えられます。

今回は、新規仮想マシンを対象にしましたので、別稿では、既存仮想マシンにも構成するところを確認したいですねー。

SCVMM 2019の前提条件で、Microsoft Command Line Utilities 15 for SQL Server ではなく Microsoft Command Line Utilities 13 for SQL Server が必要となることがある

System Center Virtual Machine Manager 2019 のインストール　今までのやり方と同じか見てみます

を過去に書いたのです。改めてインストールソフトウェアを確認したところ、Microsoft Command Line Utilities 15 for SQL Server をインストール後に、SCVMM 2019をインストールしていました。

2019/03/30時点の Microsoft Command Line Utilities 15 for SQL Server のバージョンは、15.0.1300.359です。

が、最近、Microsoft Command Line Utilities 15 for SQL Server をインストールすると、SCVMM 2019インストール時の前提条件に引っ掛かると聞いたので試してみました。

Microsoft Command Line Utilities 15 for SQL Server のバージョンは、15.0.1300.359ですが、確かに前提条件で警告が出ますね。。。

警告を外すためには、Microsoft Command Line Utilities 14.0 for SQL Server が必要と思っていたのですが、ダウンロードしたら、Microsoft Command Line Utilities 13 for SQL Server がインストール開始されるということなのです？！

※ちなみに、Microsoft Command Line Utilities 15 for SQL Server とは共存できません！

Microsoft Command Line Utilities 13 for SQL Server をインストールしまして、

SCVMM 2019のインストールを進めて前提条件を確認したところ、パスしました。。。

この細かな違いについて、深く掘り下げるに至っていませんが、

Microsoft Command Line Utilities 13 for SQL Server を使ったほうが良いケースもあるようです。