ラベル Azure Log Analytics の投稿を表示しています。 すべての投稿を表示
ラベル Azure Log Analytics の投稿を表示しています。 すべての投稿を表示

2020年12月20日日曜日

Azure Update Management 展開スケジュールの実行履歴

 Azure Update Management 展開スケジュールの実行履歴も見れるようになりましたので、例としてご覧ください。

任意の実行履歴を見るとこんな感じで、状況が確認できます。



2020年12月19日土曜日

サーバーを構成し直すので、Azure Update Management の登録を外してみる

 SCDPM にしているサーバーのディスク構成を大幅に変えることにしました。Azure Update Management の登録してあるので、外します。

Azure ポータルから外すのだろうと思って、進めてみました。[エージェントの更新の準備]にある[表示]をクリックしてみました。

[削除]をクリックします。


Remove-HybridRunbookWorker で削除しろとのメッセージが表示されました。

Remove-HybridRunbookWorker は、何だろうと思って調べたところ、
Hybrid Runbook Worker を削除する
がありました!
コマンドライン例を下記に引用します。
Remove-HybridRunbookWorker -Url <URL> -Key <primaryAccessKey> -MachineName <computerName>

まず、Azure Automation の URL とプライマリーキーを入手します。確認画面は、下記のとおりです。

入手した URL とプライマリーキーを基に、Remove-HybridRunbookWorker コマンドレットを実行します。
失敗しますね。。。登録はあるようですが。。。
ということで、強行します!

消えてないけど。。。

Log Analytics エージェントの登録解除を試します。
登録しているサーバーのコントロールパネルから、Microsoft Monitoring Agent を開きます。

[OK]をクリックして確定させましょうー

Log Analytics エージェントの一覧には、まだいます。

Azure Update Management 側は、接続が切れている形に変わりました。
Remove-HybridRunbookWorker コマンドレットの実行が失敗しているのが影響してそうなのかな。
ちなみに、Log Analytics エージェントの一覧からは、しばらくすると消えていました。

サーバーを構成し直したので、改めて Log Analytics エージェントをインストールしました。
見事に同じサーバーがダブっている。。。Hybrid Runbook Worker は、新しいほうだけになっているのですが?!

一旦様子を見ます。。。

2020/12/20 追記
半日ほど放っておいたら、重複していたサーバーのエントリーが消えていました。

Hybrid Runbook Worker の削除もあながち間違いではなかったのかもしれません。
ともあれ、Log Analytics エージェントの登録と連動して、一定時間でガーベージコレクションされるのかもしれないですね。


2020年12月11日金曜日

Azure Update Management 2020年12月のセッション資料、と補足

【オンライン開催】Azureからすべてを管理?! ~データサービスとOS更新管理~
HCCJP(ハイブリッドクラウド研究会) 第15回勉強会

にて、録画セッションを公開させていただきました。セッション資料を下記に公開します。
Azure Update Management 2020年12月

セッション動画は、
です。

質問を一ついただいたようですが、その場でご回答できず申し訳ありません。
調べたところ、下記に情報がありました。
あと、「展開スケジュール構成」の選択項目について、下記の通り補足します。
  • 「更新プログラムの分類」は、下記の項目があります。

  • 「更新プログラムの包含/除外」は、下記の項目があります。

  • 「スケジュール設定」は、いろいろな設定パターンがあります。






2020年11月22日日曜日

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

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

該当サーバーの Windows Update を実行してみました。。。先週、実行していなかったのか?!
ということで、実行しています。

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

ということで、本稿の後半は、「更新プログラムの展開のスケジュール」を作成してみます。まずは[更新するグループ]をクリックして指定します。
フィルターを調整して、対象にするマシンを絞ります。下記のケースは、Azure サブスクリプションの含まれる仮想マシンを対象にしてみました。

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

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

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

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

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

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

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 の設定が入りっぱなしでした。。。
を見ていただきたいのですが、Azure Log Analytics は、エージェントとして、Microsoft Monitoring Agent を使います。この Microsoft Monitoring Agent は、SCOM のエージェントでもあるわけです。つまり
Microsoft Monitoring Agent = Log Analytics エージェント = SCOM エージェント
ということで、エージェントのバイナリ自体は、同じものが使えます。
ちがいは、接続先ということです。Log Analytics なのか、 SCOM なのかということですが、両方に接続も可能なのは、
にも書いています。

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

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

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

[チェックを実行]をクリックしてみました。
下記のような確認結果が表示されます。これ詳細が分かってよいですね。

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

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

以上