Azure Arcとは
オンプレ等のAzure以外で動作する仮想マシンをAzureポータルで管理するサービスです。Azure Arcの管理下においたサーバーをAzure Arc対応サーバーと呼びます。Azure Arc対応サーバーにすることで、Azure以外の仮想マシンに対して、Azureサービスを利用した管理を行うことができます。例えば、Defender for Serversを有効にすることで、サーバーの保護機能を提供できます。Defender for Serversについてはこちらの記事をご参照ください。
Azure Arcの料金
有効になっているAzure管理サービスに応じて料金が発生します。Azure Arc対応サーバーを構成するだけであれば費用は発生しません。
Connected Machineエージェント概要
Connected Machineエージェント
対象の仮想マシンをAzure Arc対応サーバーにするためには、Connected Machineエージェントのインストールが必要です。Connected Machineエージェントは、下記3つのコンポーネントによって動作します。
- Hybrid Instance Metadata Service (HIMDS) ：Azureへの接続、接続したマシンのAzure IDを管理を行います。
- Guest Configuration：マシンが特定のポリシーに準拠しているかの評価や、コンプライアンスの適用などの機能を提供します。
- Extension Manager：VM拡張機能のインストール、アンインストール、アップグレードなどを行います。
詳細は、下記のドキュメントをご参照ください。
前提条件
下記のドキュメントをご参照ください。
また、ネットワーク要件にも注意しましょう。Windowsでは、最新のエージェント（バージョン1.56以降）を利用する場合、TLS1.2に対応している必要があるなどの要件があります。
展開方法
Connected Machineエージェントの展開方法について、下記のドキュメントにまとまっています。
一番シンプルな展開方法は、手動でインストールスクリプトを実行する方法です。Azure Arc画面からインストール用のスクリプトを生成し、対象のマシン上で実行します。
しかし、複数のマシンに対して個別にスクリプトを実行する方法は非常に大変です。そこで、Windows環境（Active Directoryドメイン環境）では、グループポリシーを利用した展開方法を利用することが多いかと思います。以降で、グループポリシーによる展開方法をご紹介します。
グループポリシーでAzure Arc対応サーバーを構成する
手順概要
公式ドキュメントの手順に従い、Azure Arc対応サーバーを構成します。
※個人的に分かりやすいよう、少し順番を変えています
①ファイル共有の準備
②サービスプリンシパルの作成
③インストーラーパッケージの配置
④グループポリシー作成用スクリプトのダウンロード
⑤グループポリシー作成用スクリプトの実行
⑥グループポリシーの適用
検証環境
下記の環境にて、手順を検証します。すべて、Hyper-V上で動作しています。
- ドメインコントローラー×1台
- Windows Server 2022
- メンバーサーバー×3台
- Windows Server 2022
- 上記ドメインに参加
- LAB-MEMBER-1はファイルサーバーとして動作（下記画像参照）
今回は、「Tokyo」という名前のOUに3台のメンバーサーバーを配置しています。実際の現場では、OU内の特定サーバーにだけグループポリシーを適用したい（特定のサーバーだけAzure Arc対応サーバーとしたい）場合も考えられるため、セキュリティフィルターでLAB-Member1と2だけをAzure Arc対応サーバーとして構成する手順を紹介します。セキュリティフィルターの設定用に、事前に対象のサーバーを含むセキュリティグループを作成しておきます。
展開手順
①ファイル共有の準備
Connected Machineエージェントのインストーラーパッケージを配置するためのファイル共有（リモート共有）を準備します。アクセス権としては、下記を構成します。
- Domain Admins：フルコントロール
- Domain Computers：変更
- Domain Controllers：変更
Windows共有のアクセス権限は、「アクセス許可」と「共有」の2か所で設定されます。両方の設定で許可されている場合のみアクセスが許可されます。一般的には、管理を煩雑にしないため、「共有」の設定を「Everyone」にし、「アクセス許可」でアクセス権を制限する場合が多いです。Windowsファイルサーバでは、「共有」設定がデフォルトで「Domain Users」になっている場合がありますので注意してください。「共有」設定は「フォルダのプロパティ > 共有 > 詳細な共有 > アクセス許可」から設定可能です。
※下記の設定画面では、「共有」の権限を編集できません
②サービスプリンシパルの作成
Azure Arcの画面から、サービスプリンシパルを作成します。
サブスクリプション・リソースグループ等を指定します。
有効期限は任意の期間を設定します。ロールとしては、「Azureに登録されたマシンのオンボード」を指定します。
サービスプリンシパルのIDとシークレットのダウンロード画面が表示されますので、ダウンロードして控えておきます。（⑤のスクリプトで利用します）
③インストーラーパッケージの配置
Connected Machineエージェントのインストーラーパッケージをダウンロードし、①で作成した共有フォルダに配置します。
※リンクをクリックするとインストーラーがダウンロードされます
④グループポリシー作成用スクリプトのダウンロード
グループポリシー作成用スクリプトをダウンロードして解凍し、ドメインコントローラーに配置します。
※下記画像ではデスクトップに配置しています
⑤グループポリシー作成用スクリプトの実行
④で配置したスクリプト（解凍したフォルダ内にあるDeployGPO.ps1）を実行します。パラメーターにはそれぞれ、下記を指定します。
- DomainFQDN：ドメイン名
- ReportServerFQDN：インストーラーパッケージを配置しているサーバーのFQDN
- ArcRemoteShare：インストーラーパッケージを配置しているファイル共有名
- ServicePrincipalSecret：②で作成したServicePrincipalClientSecret
- ServicePrincipalClientId：②で作成したServicePrincipalId
- SubscriptionId：Azure Arc対応サーバーをデプロイするサブスクリプションID
- ResourceGroup：Azure Arc対応サーバーをデプロイするリソースグループ
- Location：Azure Arc対応サーバーをデプロイするリージョン
- TenantId：Azure Arc対応サーバーをデプロイするテナントID
- AgentProxy：（必要な場合）プロキシ名
.\DeployGPO.ps1 -DomainFQDN contoso.com -ReportServerFQDN Server.contoso.com -ArcRemoteShare AzureArcOnBoard -ServicePrincipalSecret $ServicePrincipalSecret -ServicePrincipalClientId $ServicePrincipalClientId -SubscriptionId $SubscriptionId -ResourceGroup $ResourceGroup -Location $Location -TenantId $TenantId [-AgentProxy $AgentProxy]
ArcRemoteShareパラメーターですが、サーバーのFQDN直下にフォルダがある場合は、フォルダ名を指定します。FQDN直下にない場合は次のように指定します。（下記例は、sharefolderにインストーラーパッケージを配置した場合です）
folder\subfolder\sharefolder
下記参考までに私が実行した際のキャプチャです。事前に環境変数を設定（$env:xxxx = "xxxx"）して実行しています。
スクリプトが成功するとGPOが作成されます。スクリプト実行後に「グループポリシーの管理」が起動します。
また、スクリプトの実行によって指定したフォルダに「AzureArcDeploy」と「AzureArcLogging」フォルダが作成されます。
「AzureArcDeploy」には、Connected Machineエージェントのデプロイに必要なファイルが配置されています。
「AzureArcLogging」には、作成時点ではファイルは存在しません。
実行ポリシーの設定によってはスクリプトが実行できない場合があります。必要に応じて、Set-ExecutionPolicyで設定を変更してください。
⑥グループポリシーの適用
特にフィルター処理を行わない場合は、Azure Arc対応サーバーが所属するOUにGPOをリンクすればOKです。セキュリティフィルターを行う場合は、下記の手順に従います。
セキュリティフィルターはGPOの適用スコープを制御する設定です。まずはデフォルトで設定されている「Authenticated Users」を削除します。
警告がでますが、そのまま「OK」で進みます。
もう一度警告がでますが、「OK」で進みます。
事前に作成しておいたセキュリティグループを追加します。
これにて準備は完了のため、GPOをリンクします。
「Authenticated Users」にはドメイン内のコンピューターアカウントも所属しています。セキュリティフィルターからAuthenticated Usersを削除した後に追加の処理を行わないと、コンピューターアカウントにグループポリシーが適用されません。
動作確認
GPOをリンクした後、一定期間待機するとAzure Arc対応サーバーに登録されることが確認できます。
GPOでデプロイされたサーバーは専用のタグが付与されるようです。
OSからは、下記のコマンドで正しくGPOが適用されていることを確認できます。コマンドプロンプト、または、PowerShellを管理者権限で起動して実行してください。
gpresult /r
イベントビューアーからは、イベントID 106でインストールタスクが登録されていることを確認できました。
アプリケーションとサービスログ > Microsoft > Windows > TaskScheduler > Operational
なお、今回の手順で作成したGPOでは一時タスクが作成されるため、タスクスケジューラーにはタスクが残りません。タスクの内容としては、ファイル共有からEnableAzureArc.ps1をコピーして実行した後、ファイルを削除するもののようです。
エージェントがアクセス不可になると、「AzureArcLogging」>「NotConnected」フォルダ配下にログとしてxmlファイルが作成されるようです。
また、Azure Arcのオンボードに失敗した場合も、「AzureArcLogging」にxmlファイルが作成されることを確認しました。小規模な環境であれば良いですが、大規模環境ではファイルサーバへの負荷は気を付けておいた方が良さそうです。（安易にADに共有フォルダ作るのは辞めておくのが無難ですね）
事後処理
サーバーがAzure Arcに正常に反映されることを確認したら、GPOのリンクを外します。これによりタスクがグループポリシーの更新時に再度実行されないようになります。再度実行してもAzure Arcの動作としては問題なさそうですが、公式ドキュメントの推奨に従うのが無難でしょう。また、グループポリシーを再利用する場合は、サービスプリンシパルの有効期限に注意してください。