2019年11月24日日曜日

Windows Admin Center 1910 の接続先をクリーンアップしましょう

Windows Admin Center 1910 GA されたことによって、HCI とフェールオーバークラスターへの接続が一緒になりました。

結果、今まで別々に作ってあった接続が重複していませんか?
※たとえば赤枠のところですね。


この例は、"共有接続"なので、設定から不要になった接続を削除します。




共有接続でなければ、"すべての接続"から削除すればOKです!

2019年11月17日日曜日

Install-WindowsAdminCenterHA-1907で、Windows Admin Center 1910 HA 構成を Storage Spaces Direct に展開できますか?

結論、できませんでした。


ということで、2ノード以上のクラスターで構成してください。
※繰り返しますが、Storage Spaces Direct(S2D)じゃなくて、共有ディスクを使うクラスターですよ!

2019年11月10日日曜日

Windows Admin Center HA 1907 スクリプト

Windows Admin Center HA 1907 スクリプト
見逃しておりました。
Preview 1907~1909までは、このスクリプトを使えばよいですね!

先日 GA された1910は、もしかすると対応の Windows Admin Center HA スクリプトが出るのかもしれませぬ。
が、別途、Windows Admin Center HA 1907 スクリプトを使って、Windows Admin Center 1910を展開してみたいと考えています。

Windows Admin Center 1910が GA しました

Windows Admin Center 1910が GA しました!

新機能リストは、下記をご参照ください。
What’s new in Windows Admin Center 1910
クラスターと HCI への接続が統合されたとか、仮想マシンでインポート/エクスポートができるとか、新しいパフォーマンスモニターがあるとか、Azure hybrid services tool としてオンプレミスと Azure の連携がまとめられたわかりやすくなったとか、各社の BMC 連携とか、それはそれは盛りだくさん!

インストールそのものは、従来と変わりありません!

インストール直後の画面


冒頭で触れましたが、クラスターと HCI への接続が統合されおります。

接続後は、それぞれ最適なものが表示されますよ。

サーバーの設定に、サーバー用 Azure Arc がプレビュー機能として使えるようになっています。


追加可能な拡張のリスト上部に、Azure Cloud Shell、Azure Extended Network があってプレビューが公開されていますー


そして追加可能な拡張のリスト内にある、Dell EMC OpenManage Integration も1.0.1になりました。

※うちのDELL サーバーだとうまく動かない。。。1.0は動いていたのに。

Azure Bastion が GA してます。

Ignite で発表あった通り、Azure Bastion が GA してます。
これまでは、プレビューの画面に切り替える必要がありました。
GAしたので、通常のポータルから利用できます。




セッションの一覧も確認できます。


ブラウザ画面越しで、文字のコピー&ペーストが可能です。
しかし、ファイルのコピー&ペーストはサポートされていない模様。


ぜひ、使ってみてください。
展開ガイドは、こちらからアクセスできます。

2019年11月4日月曜日

System Center Operations Manager 2019 における"Log on as a Service"


で、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 権限に含めました。


これで、ばっちりコンピューターの一覧が表示されますよ!

SQL Server 2017 Reporting Service の拡張子フィルターと System Center Operations Manager 2019

オペレーション マネージャ 2019 および 1807 レポートの展開に失敗
https://support.microsoft.com/ja-jp/help/4519161/operations-manager-2019-and-1807-reports-fail-to-deploy
というサポート情報があることをご存知でしょうか。

この設定を変えないと、System Center Operations Manager 2019でレポートの展開ができません。

ということで、SQL Server 2017 Reporting Service (SSRS)の拡張子フィルターを変更します。
SQL Server Management Studio を起動して、SSRS のインスタンスに接続します。

※SSRS のインスタンスをプルダウンメニューから選択するのが、ポイントですよ。

SSRS のインスタンスが起動できたら、プロパティから Advanced(詳細設定)をクリックします。


AllowedResourceExtensionsForUpload を探し出し、冒頭に"*.*"を追加しましょう。

※サポート情報 オペレーション マネージャ 2019 および 1807 レポートの展開に失敗 に記載ある通り、SSRS サービスの再起動をお忘れなきよう。

SCOM 管理コンソールから、Reporting を確認します。
すでにインポート済みの管理パックに関するレポートが見えるようになれば、完了ですー。