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

2020年12月20日日曜日

SCDPM 2019 を作り直したら、ID 31313を引いた

物理サーバーのディスク構成を見直し、SCDPM 2019 を作り直しました。

Windows Server 2008などの仮想マシンをバックアップしようと設定を作成しようとしたところ、下記のエラーが発生。

調べると、下記のようなエントリーがありました。

System Center Data Protection Manager 2016 Error 31313 during creation of protection group

SQLをアレンジして、実行してみました。

仮想マシンが選択できるようになりましたー

SQL Server のサービスパックや累積更新プログラムについて、最新版を確認できるページがあるんですね

Microsoft SQL Server の最新の更新プログラム

SQL Server 2008からSQL Server 2019（おそらく今後リリースされる最新バージョンもでしょうね）について、累積更新プログラムやサービスパックで最新版を確認できますね！

このページはちょくちょく確認することになりそうです、ありがたい！

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

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

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

Azure Update Management でオンプレミス用の展開スケジュールを作成

結論から申し上げますと、Azure VM のやり方と変わらないです！
※Log Analytics エージェントが関連付けられている Azure サブスクリプションを選択することになるため、結果的に同じやり方になってました。

Azure Update Management の「更新プログラムの展開のスケジュール」も併せてご覧ください。

展開スケジュールの作成画面を開きます。名前を入力したところです。ちなみに、名前は後から変更できないので、命名規則を先に考えたほうが良いですね。

次に[更新するグループ]を選択します。

こちらの操作が、「オンプレミスなサーバーにインストールしてあるLog Analytics エージェント」が関連付けられている Azure サブスクリプションを選択することになります。

ここでは、すべてのサブスクリプションを選択しています。

次に、対象とするマシンを選択します。

赤枠の[タイプ]で"マシン"を選択します。

[タイプ]で"マシン"を選択すると、対象になるマシンが表示されます。対象にしたいマシンンの名前をクリックし、

[OK]をクリックします。

次に、スケジュール設定を行います。

この例だと、3週間おきということですね。（この後、2週間おきに修正しました）

ほかのパラメーターは既定値のままにします。[作成]をクリックします。

こんな感じで出来上がりです。

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月

セッション動画は、

です。

質問を一ついただいたようですが、その場でご回答できず申し訳ありません。

調べたところ、下記に情報がありました。

サポートされているクライアントの種類
こちらは、上記スライドに記載した通りですね。
サポートされていないクライアントの種類
Windows クライアント、Windows Server 2016 Nano Server、Azure Kubernetes Service ノードが、サポートされていないということです。

あと、「展開スケジュール構成」の選択項目について、下記の通り補足します。

「更新プログラムの分類」は、下記の項目があります。
「更新プログラムの包含/除外」は、下記の項目があります。
「スケジュール設定」は、いろいろな設定パターンがあります。

2020年12月9日水曜日

SCVMM 2019 Update Rollup を管理コンソールへ適用する前に、.NET 4.8になっているかを確認したほうがよさそう

コンソールの最新のアクセシビリティ修正プログラムが利用不可

という情報があることを知りました。

たとえば、SCVMM 2019 Update Rollup 2を SCVMM 管理コンソールへ適用した場合、.Net 4.8以前だと問題が発生するようです。一例として下記のような事象を見ました。。。

SCVMM 2019 Update Rollup 2を管理コンソールへ適用後、Hyper-Vクラスターのプロパティが表示できずに、SCVMM 管理コンソールがクラッシュというか異常終了する

回避策としては、.NET 4.8にしておくのが良いみたい。
皆様もお気を付けくださいませ。

2020年12月4日金曜日

Azure Stack Hub の NW スイッチコンフィグを作成する機会がありましたので

Azure Stack Hub の NW スイッチコンフィグを作成するやり方、最近はちがうよーと教えてもらいました。

知る人ぞ知るリソースをダウンロードして、去年を思い出しながらやってみようとしましたが、確かに全く変わってしまった。。。

W スイッチコンフィグのフォルダーを探し当てたところ、去年のやり方は、全く通用しない事実に呆然。

といっても始まりません。

NW スイッチコンフィグのフォルダーにあったモジュールを import-module する。
そのあと、このコマンドレットだよねーと実行したのが、下記の画面。

Hyper-Vの役割をインストールしていました。あと、Container の有効化も実行する感じ。同じフォルダーに docker.exeもあったな。。。
これを踏まえて、調べてみたところ、下記情報と一致しましたよ。

Get started: Prep Windows for containers

以上、「Azure Stack Hub の NW スイッチコンフィグは、Container を使って作成します」ってことでした。

追伸
仮想マシンの Windows 10を使っていたので、一度シャットダウンして、Nested Hyper-V を有効化しておきました。

注）Get started: Prep Windows for containers では、仮想マシンで実行できるとは書いていないので、この記事は鵜呑みにしないようお願いしますー

2020年12月1日火曜日

Hyper-V レプリカの解説記事が、リンク切れしていた

Hyper-V レプリカに関して、イベントソース：hyper-v-vmmsとイベントID：32326トラブルシューティング情報を集めています。

Gathering event source: hyper-v-vmms and event ID: 32326 troubleshooting information about Hyper-V Replica.

(Hyper-V Failover Cluster) highly available VM replicated on standalone Hyper-V replica server.

にいくつか振り返っておくと良さそうな情報を見つけました。
In the above article, I found some information that would be good to look back on.

Step 1: Prepare to Deploy Hyper-V Replica
http://technet.microsoft.com/en-us/library/jj134153.aspx
Why adding Hyper-V Replica Connection Broker Fails (in Failover Cluster Manager)
http://blogs.technet.com/b/askpfeplat/archive/2012/12/10/why-adding-hyper-v-replica-connection-broker-fails-in-failover-cluster-manager.aspx
Hyper-V Replica Explained, Windows Server 2012 Style
http://blogs.technet.com/b/yungchou/archive/2013/01/10/hyper-v-replica-explained.aspx
http://blogs.technet.com/b/virtualization/archive/2013/05/10/resynchronization-of-virtual-machines-in-hyper-v-replica.aspx

ですが、Microsoftのブログプラットフォームが変わったこともあり、いずれもリンク切れ。。。
But due to the change in Microsoft's blogging platform, the links are all broken.

元記事がクローズされているため、新しいリンクを追記することができません。

New links cannot be added because the original article is closed.
マッピングが完全かは自信ないのですが、移行先を下記に記載しておきます。

I'm not sure if the mapping is complete, but I'll list the migration destination below.

訂正あれば、バシバシコメントください！

Please comment on any corrections!