Microsoft Entra ID の動的メンバーシップ グループは、管理者がグループ メンバーシップの管理を自動化できる強力な機能です。 通常、メンバーシップの変更は数時間以内に処理されます。
ただし、特定の条件下では、メンバーシップの更新が遅れる可能性があります。 処理には 24 時間以上かかることがあります。 基になる原因を理解することは、管理者が構成を最適化し、不要な処理のボトルネックを回避するのに役立ちます。
動的グループ処理のしくみ
動的なグループ処理は、順番に動作します。 1 つのテナントの変更は、一度にすべてではなく順番に評価および適用されます。 大量の変更 (特に多くのユーザーまたはデバイスに影響を与える場合) は、長い処理キューにつながる可能性があります。 長いキューは、更新が処理を完了するために必要な時間を延長できます。
処理時間に影響する主な要因
処理に影響を与え、メンバーシップの更新に時間がかかる可能性がある 3 つの最大の要因は次のとおりです。
動的グループの数: 多数の動的グループを持つテナントでは、より多くの評価が必要で、処理時間が長くなります。
オブジェクト変更の数: 大量のユーザーまたはデバイスの変更により、長い処理キューが作成され、処理時間が長くなる可能性があります。 たとえば、拡張機能の属性の変更、デバイスの追加または削除、ユーザーの一括更新などがあります。
ルールの構成: 特定のルール構成が処理時間に影響を与える可能性があります。 たとえば、
Match、Contains、memberOfなどの非効率的な演算子を選択すると、処理時間が長くなる可能性があります。 ルールの複雑さも一因です。
テナントで動的メンバーシップ グループを管理するためのベスト プラクティス
効率的な処理を確保し、遅延を最小限に抑えるには、次のベスト プラクティスを検討してください。
テナント内の動的メンバーシップ グループの数を監視する
テナント内のグループの数を定期的に確認します。 非アクティブなグループまたは古いグループを削除します。
不要なグループを一時停止する
不要なグループを一時停止して、処理のパフォーマンスを向上させることができます。 このような状況では、グループ処理を一時停止することを検討してください。
- 計画された大規模な更新: グループ メンバーシップに多数の変更を加える予定です。 たとえば、500 を超えるグループに変更を加えたり、20,000 を超えるメンバーシップを変更したりする予定です。
- 予期しない遅延: グループ メンバーシップが変更されておらず、予期しない遅延が発生していることがわかります。
処理を一時的に停止するには、[ すべてのグループの一時停止] スクリプトを使用します。 再開する前に、サービスの復旧を許可します。
すぐにグループの一時停止を解除しないでください。 グループ処理が追いつくためには、少なくとも 24 時間待機することをお勧めします。 次に、監査ログを調べて、それらがベースラインに戻っているかどうかを確認します。 必要に応じて、一度にすべてではなく、段階的にグループの一時停止を解除します。
ルールの効率を最適化する
ルールで
Match演算子を使用することは、できるだけ避けてください。 代わりに、StartsWith、Equals、またはEndsWith演算子を使用します。ルールで
Contains演算子を使用することは、できるだけ避けてください。 処理時間の増加につながる可能性があります。使用する
-or演算子の数を減らします。 代わりに、-in演算子を使用して、ルールを 1 つの条件にグループ化します。 ルールをグループ化すると、簡単に評価できます。可能であれば、
memberOf演算子を使用しないでください。 現在プレビュー段階であり、バグと制限事項が付属しています。 また、特にテナントに多数のグループや頻繁な更新がある場合は、より複雑になる可能性があります。 テナント内の既存のmemberOfグループを削除することをお勧めします。
動的グループ処理の最適化に関する詳細については、「 Microsoft Entra ID での動的メンバーシップ グループに対するよりシンプルで効率的なルールの作成」を参照してください。
概要
動的グループ処理の遅延は、主に大量の変更と多数のグループが原因で発生します。 IT 管理者は、ルールの効率の最適化、変更の監視、必要に応じて不要なグループの一時停止などのベスト プラクティスに従うことで、処理のパフォーマンスを向上させ、不要な遅延を回避できます。