Configuration Managerのコレクションのベスト プラクティス

  • [アーティクル]

Configuration Manager (現在のブランチ) に適用

コレクション管理のガイダンスによっては、矛盾する場合があります。 たとえば、パフォーマンス上の理由から、頻繁に更新されるコレクションの数を制限する必要があります。 ただし、ほとんどのConfiguration Manager機能はコレクションに依存するため、コレクションを頻繁に更新すると便利です。 コレクションとコレクションの評価を設計および構成するときは、パフォーマンスへの影響とビジネス要件の両方を慎重に検討してください。

Configuration Managerのコレクションには、次のベスト プラクティスを使用します。

更新プログラムのメンテナンス期間を構成する

デバイス コレクションのメンテナンス期間を構成して、これらのデバイスにソフトウェアConfiguration Managerインストールできる時間を制限できます。 メンテナンス期間が小さすぎるよう構成した場合、クライアントは重要なソフトウェア更新プログラムをインストールしない可能性があります。 この状態により、クライアントは更新プログラムによって軽減される問題に対して脆弱になります。

メンテナンス期間を計画する際に留意すべき重要な考慮事項:

  • 既定のソフトウェア更新プログラムの最大実行時間は 60 分です。
  • Configuration Managerは、更新プログラムをインストールできるかどうかを計算するときに、再起動を考慮して最大実行時間に 5 分を追加します。
  • メンテナンス期間の残りの期間は、ソフトウェア更新プログラムの最大実行時間と 5 分を超える必要があります。

収集の評価を頻繁に行わないようにする

完全なコレクション評価では、対象のコレクションだけでなく、更新が発生した場合にコレクションが制限するコレクションも評価されます。 また、スケジュールのないコレクションは、コレクションの制限が更新された場合も評価されます。 そのため、一部のコレクションは、予想よりも頻繁に評価される可能性があります。

ビジー状態のConfiguration Manager環境では、コレクション評価を繰り返さないようにスケジュールをスケール バックすることで、コレクション評価のパフォーマンスを向上させることができます。 ディープ ツリーでは、コレクションがツリーの深く下がると、コレクションの評価頻度を減らすことができます。これは、より高いレベルのコレクション評価によって、より低いレベルのコレクション評価もトリガーされるためです。

コレクション評価グラフを理解する

適切なコレクション構造を設計できるように、コレクション評価グラフのしくみに注意してください。 すべてのコレクションを常に更新するために、完全なコレクション評価に依存しないでください。 増分更新されたコレクションがスケジュールに基づいて更新された場合、増分更新が有効になっていないコレクションを参照しても更新されない可能性があります。 増分評価中に更新が発生する可能性があるため、完全な評価ではコレクションが更新されず、そのサイクルのコレクション評価グラフが終了する可能性があります。 その場合、参照元のコレクションの評価は行われません。 詳細については、「 コレクションの評価グラフ」を参照してください。

増分更新を制限する

多くのコレクションに対して増分更新を有効にすると、評価の遅延が発生する可能性があります。 増分更新されたコレクションの数を 200 に制限することをお勧めします。 正確な数値は次に依存します。

  • コレクションの合計数
  • 階層内で新しいリソースが追加および変更される頻度
  • 階層内のクライアントの数
  • 階層内のコレクション メンバーシップ ルールの複雑さ

増分評価サイクルが構成された更新頻度よりも長くかかる場合、Configuration Managerはコレクション評価を絶えず処理しているため、システムのパフォーマンスに影響を与える可能性があります。 増分更新されたコレクションの数を減らすか、増分評価サイクル間の時間を長くします。

増分コレクションの潜在的な影響を考えると、コレクションを作成し、更新スケジュールを割り当てるポリシーまたは手順を作成することが重要です。 ポリシーに関する考慮事項の例を次に示します。

  • セキュリティ スコープ、クライアント設定、メンテナンス期間に使用されるコレクションに対してのみ増分更新を使用します。 これらのコレクションの更新は、クライアントの動作とリソースへのアクセスに影響します。
  • ライセンスの承認がないアプリケーションの場合は、アプリケーションを既存のコレクションにアドバタイズし、グローバル条件を使用して可用性を制限します。
  • コレクションの完全な更新がスケジュールされている他のコレクションの適切な期間を概説します。

CAS からの大きなツリーの評価を避ける

Configuration Manager環境では、中央管理サイト (CAS) はコレクション メンバーシップを評価しません。 プライマリ サイトは、コレクションを評価する唯一のサイトです。 セカンダリ サイトは、プライマリ サイトからレプリケートするデータのみを使用するプロキシとして機能します。

コレクションの更新を要求するために、CAS は各プライマリ サイトに要求を送信します。 プライマリ サイトはコレクションを評価し、結果を CAS に返します。 コレクション評価の結果は、すべてのコレクション評価命令がすべてのサイトにレプリケートされ、すべてのサイトですべてのコレクションが評価され、すべてのデータが CAS に返され、結合された後にのみ表示されます。

次の図は、CAS が手動のコレクション更新を要求するときのフローを示しています。

CAS からの手動コレクションの更新

複数のプライマリ サイトを持つ CAS からのコレクションの更新には時間がかかる場合があります。 コレクションがタイムリーに評価されない場合は、要求を繰り返したくなる場合があります。

コレクション評価スレッドが開始され、評価グラフが読み込まれると、コレクション評価グラフが空になるまで評価が続行されます。 その後、スレッドは終了し、次の評価に使用できるようになります。 ただし、スレッドがコレクションを評価している間に別のコレクション評価サイクルがキューに入った場合、スレッドはすぐに再起動して"見逃された" サイクルの評価を試みます。

各評価メソッドは、独自のスレッドで実行されます。 スレッド内で、Configuration Managerが同じコレクションを複数回グラフ化しようとする可能性があります。 Configuration Manager、2 番目以降の要求が削除されます。

このようなシナリオを回避するには、特に複数のサイトを使用して CAS から作業する場合は、大規模なツリーの手動収集評価を避けてください。

コレクションの深さとクロスリファレンスを検討する

ビジネス要件とパフォーマンスのバランスを取るには、作成するコレクション構造とその他のコレクションへの依存関係を理解することが重要です。 他のコレクションを参照する 1 つ以上のコレクションを参照するルールを持つコレクションを作成すると、それらのコレクションがすべて評価され、コレクションのメンバーシップが作成されます。

Configuration Managerに含めるおよび除外するコレクション規則を使用すると、カスタム WQL クエリを記述するよりもコレクションの参照が簡単になります。 ただし、include コレクションと exclude コレクションを使用するとパフォーマンスの高い料金が発生する場合は、代わりに WQL クエリ メソッドを使用できます。 次のクエリ例を使用し、コレクション ID XYZ0003F の例を含めるか除外するコレクションの ID に置き換えます。

次の内容を含めます。

Select * from SMS_R_System where SMS_R_System.ResourceId in (select ResourceID from SMS_CM_RES_COLL_XYZ0003F)

除外：

Select * from SMS_R_System where SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_XYZ0003F)

CEViewer を使用してコレクションの評価を監視する

コレクション評価ビューアー (CEViewer) を使用して、評価されるコレクションの数と、各コレクションの更新にかかる時間を監視できます。 CEViewer は、サイト サーバーの CD.Latest フォルダーにあります。

ヒント

バージョン 2010 Configuration Manager以降、この機能はコンソールに組み込まれています。 詳細については、「 コレクションの評価を表示する方法」を参照してください。

SQL で同様のチェックを手動で行うには、次のクエリを使用できます。

SELECT [t2].[CollectionName], [t2].[SiteID], [t2].[value] AS [Seconds], [t2].[LastIncrementalRefreshTime], [t2].[IncrementalMemberChanges] AS [IncChanges], [t2].[LastMemberChangeTime] AS [MemberChangeTime]
FROM (
    SELECT [t0].[CollectionName], [t0].[SiteID], DATEDIFF(Millisecond, [t1].[IncrementalEvaluationStartTime], [t1].[LastIncrementalRefreshTime]) * 0.001 AS [value], [t1].[LastIncrementalRefreshTime], [t1].[IncrementalMemberChanges], [t1].[LastMemberChangeTime], [t1].[IncrementalEvaluationStartTime], v1.[RefreshType]
    FROM [dbo].[Collections_G] AS [t0]
    INNER JOIN [dbo].[Collections_L] AS [t1] ON [t0].[CollectionID] = [t1].[CollectionID]
    inner join v_Collection v1 on [t0].[siteid] = v1.CollectionID
    ) AS [t2]
WHERE ([t2].[IncrementalEvaluationStartTime] IS NOT NULL) AND ([t2].[LastIncrementalRefreshTime] IS NOT NULL) and (refreshtype='4' or refreshtype='6')
ORDER BY [t2].[value] DESC