さっしーの試してみるか3

2020年11月21日土曜日

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

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

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

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

開始されました。

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

続行しています。

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

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

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

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

2020年11月15日日曜日

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 との通信が一時的に切れると、上記一覧から一時的に表示が消えることもあるようです。

以上

2020年11月8日日曜日

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 に移動して、さらに細かく状況が確認できますね。

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

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

2020年11月7日土曜日

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 を使ったほうが良いケースもあるようです。

2020年11月3日火曜日

Azure Stack HCI 20H2 を Nested Hyper-V で構成するには、Known issues for Azure Stack HCI を回避しないと

Known issues for Azure Stack HCI があるから、Nested Hyper-V で構成するにはコツがいると教えていただきました。つまり、Azure Stack HCI OS 20H2だと、Windows Admin Center だけで Azure Stack HCI を構成できないということなんですね。。。

というわけで、ようやく

Windows Admin Center 2007 と Azure Stack HCI OS 20H2 による Azure Stack HCI のデプロイその1

の続きが確認できそうですね。

Azure Stack HCI 20H2な Gen. 2仮想マシンを用意します。この仮想マシンは、Nested Hyper-V を有効化しました。

まず、

ということで、