で、System Center Operations Manager 2019 における"Log on as a Service"のデモを行いました。
SlideShare 資料のスライド番号29（SlideShareでのスライド番号30）に下記の通り記載しました。
「全サービスアカウントは、Log on as a Service権限が必要」
Log on as a Service権限がなかった場合、どういう挙動になるのでしょうか。これは、デモでお伝えしていたのですが、当ブログとして記載していないかったので、改めて本稿で書いておこうと思い立ちました。
Security changes in SCOM 2019 – Log on as a Service
に書かれている「What you might notice is a failure to “find” the agents you are trying to deploy:」の画像がその挙動です。
要は、Agent インストールしようとして、デバイスの検出で失敗するというものです。
こちら、SlideShare 資料のスライド番号29（SlideShareでのスライド番号30）に記載した元ネタでもあります。
実際に、アクションアカウントから、Log on as a Service 権限を抜いてみると、
Security changes in SCOM 2019 – Log on as a Serviceと同じ挙動を示しますね。
ということで、「全サービスアカウントは、Log on as a Service権限が必要」をお忘れなきようー。
System Center Operations Manager 2019 の Agent として、Microsoft Monitoring Agent を使う場合にも、「Log on as a Service権限が必要」です。
SlideShare 資料のスライド番号29～30（SlideShareでのスライド番号31～32）に記載した内容ですので、こちらもお忘れなきよう。
※2019/11/10 追記
これだけでは権限不足のようです。
Security changes in SCOM 2019 – Log on as a Service
を読み直したところ、Log on as a Service権限に含める範囲を広げないとだめですね。
Agent をプッシュインストールするアカウントも Log on as a Service 権限に含めましょう！
※要するに、プッシュインストール時に、インストール対象サーバー上の管理者権限ユーザーにも Log on as a Service 権限に含めるということです。
私も、Kevin にならい、SCOM サービスアカウントと、管理系のアカウントを一つのセキュリティグループ SCOM_Admins にまとめ、Log on as a Service 権限に含めました。
これで、ばっちりコンピューターの一覧が表示されますよ！
