はじめに

現在は、Azure Virtual Desktop (AVD) で、ホストプールと仮想マシンを作成する際に、どれだけシンプルな画面からデプロイさせられるか？を研究しています。
その際には、いくつかのハードルがあったのですが、そこで得られたノウハウを記事にしていこうと思っています。以下のリンク先でシリーズ化していますので併せて参照ください。

本記事では、Teams アプリの起動時に以下のような Windows Defender ファイアウォールのブロック確認画面が出てしまう事象に遭遇したのですが、うまく対策を講じることができました。
その際のノウハウを共有したいと思います。
私は AVD 環境で検証していますが、その他の環境の場合でも参考にしていただけると思います。

（上記の画面内のテキスト文：検索ワード用）

このアプリの機能のいくつかが Windows Defender ファイアウォールでブロックされています
すべてのパブリック、プライベート、ドメインネットワークで、Windows Defender ファイアウォールにより Microsoft Teams の機能のいくつかがブロックされています。

なぜこの対策が必要なのか？

Teams に必要な通信のためには、この画面が出た際に「アクセスを許可する」を押す必要があります。そうすることで Teams のために必要な通信の許可ルールが作成されます。
しかし、一般ユーザーでは権限が足りずにこのルールを作ることができません。

結果として、「キャンセル」を押すか「×」を押して閉じるしかなくなります。
その場合は、Teams に必要な通信をブロックするルールが作成されてしまいます。
これでは、不都合が生じます。

一般ユーザーに対して、Teams に最適な通信を行わせるためには、あらかじめこの通信を「許可」するルールを構成しておく必要がある・・・ということになります。

本事象については、以下の公式ブログ記事でも説明されています。
（公式ブログ記事）
https://jpwinsup.github.io/blog/2021/04/11/Networking/Firewall/Conditions-for-displaying-FW-pop-ups/

どういうシーンで抑止を実施すべきか？

本ソリューションは、以下のような場合にお勧めします。

ユーザーにローカル管理者の権限を許可していない
キオスク端末などで、仕組み上毎回が初回ログオンのシチュエーションになる
AVD などの VDI環境でユーザーがサインインするごとにサインイン先の VM がランダムに変わる場合
出来栄え・見栄えの良いデスクトップ環境をユーザーに提供したい
　→　正直、ブロックの確認画面が出てしまうのは、カッコ良くない。
　　ユーザーエクスペリエンス的に低いレベルに見えてしまいます。

導入方法による対処策の違い

Teams の導入は「マシンごとのインストール」と「ユーザーごとのインストール」の２通りの方法があります。この導入方法ごとに、対処策が違ってくるので、注意が必要です。

導入方法について

導入方法の違いを分かりやすく説明した情報がなかなか見つからなかったのですが、そんな中でも以下のリンク先が比較的わかりやすい方でした。
（参考）
https://learn.microsoft.com/ja-jp/azure/virtual-desktop/teams-on-avd#install-teams-on-azure-virtual-desktop

以下のように導入方法によってインストールされるパスに違いが生じます。
このパスの違いによって、対処策が違ってきます。

導入方法	コマンド	導入先のパス
マシンごと	msiexec /i /l*v ALLUSER=1 ALLUSERS=1	Program Files配下で固定 64bit：C:\Program Files (x86)\～ 32bit：C:\Program Files\～
ユーザーごと	msiexec /i /l*v ALLUSERS=1	各ユーザープロファイルの AppData配下で可変 %AppData%～

AVD の場合は、あらかじめ "Microsoft 365 Apps" が導入済みのイメージが存在します。
その場合は、"マシンごとに導入" の場合と同じ扱いになります。

対処方法について

導入方法によって、ブロック確認画面の抑止のためには、以下の対処方法を行います。

導入方法	対処法	具体的な対処内容
マシンごと	グループポリシー	次章にて解説
ユーザーごと	スクリプト	後述するサンプルスクリプトの公開情報を参照

マシンごとのインストールでは、導入されたパスが一律なのでグループポリシーで URL を配布するだけで簡単に済みます。

ユーザーごとのインストールでは、導入されるパスが各ユーザーのフォルダ配下になっているため、グループポリシーで配布することができません。
そのため、スクリプトで対処する必要があるのです。
私は AVD で使うことを中心に記事を書いているので、スクリプトの方法の検証はしていません。
以下の公開情報の記事を参考にサンプルスクリプトを活用して対策を行ってください。

マシンごとの導入向け、対策手順

「Windows Defender ファイアウォール」で「着信プログラムの例外を定義する」の項目を設定することで、ブロック画面が抑止されます。

グループポリシー管理エディタを使い「コンピューターの構成」－「ポリシー」－「管理用テンプレート」－「ネットワーク」－「ネットワーク接続」－「Windows Defender ファイアウォール」－「ドメインプロファイル」を開きます。
そして、「Windows Defender ファイアウォール、着信プログラムの例外を定義する」を開きます。

下図の通り「プログラムの例外」の値として、以下の値を設定します。
※実際に Teams.exe が導入されている場所を確認してそのパスを設定してください。

C:\Program Files (x86)\Microsoft\Teams\current\teams.exe:*:enabled:Teams1

上記で作成したポリシーを適用させたいコンピューターが所属する OU にリンクします。

動作確認

以下のいずれかの方法で Teams を導入したマシンにサインインします。

初回ログオン
管理者ユーザーで、テストユーザーのユーザープロファイルを削除してからログオン
※一度、サインインしてしまうとファイアウォールルールが作られてしまうため、ユーザープロファイルが作成されていない状態でテストしてください。

サインインした際に、ブロックの確認画面が出なければ OK です。

ご参考

本文内で紹介していた URL も含めて、以下に紹介します。

Teams クライアントの導入方法

Teams のページで紹介されている「マシンごと」「ユーザーごと」の導入方法の記事です。
ですが、これがかなり判りづらい。

Teams on Azure Virtual Desktop をインストールする

「マシンごと」「ユーザーごと」の導入方法は、こちらの説明の方が判りやすいです。

Windows ファイアウォールにより「Windows セキュリティの重要な警告」ポップアップが表示される条件と対処方法について

ブロックの確認画面が出てしまう事象についての解説になっています。

注意点：上記の記事より抜粋

アプリケーションをユーザーフォルダーにインストールする場合、実行ファイルのフルパス名はユーザーごとに異なるものを指定する必要があるため、グループポリシーによる展開等ができません。（%USERPROFILE% 環境変数を利用した指定もできません。）
このため、弊社では、弊社製 Microsoft Teams アプリケーションを対象に、ユーザーフォルダーにインストールされたプログラムに対する受信許可の規則を自動作成する PowerShell スクリプトを以下の技術文書中で公開しております。

ユーザーごとの導入をした場合の対処策

公式には、以下のサンプルスクリプトを実行するように案内されています。

なお、Windows Defender ファイアウォールに %UserProfile% のパスは指定できない・・と公式で明言されているのですが、以下の記事で紹介されている内容を見る限りは、うまく制御出来ているっぽいことが書かれています。これでうまく動作するなら、サンプルスクリプトを動かさなくても良いことになりますね。
これは自己責任で試してみてください（私は、検証できていません）