SCCMインベントリ

「在庫」という言葉で、普通の人は店に来て閉じたドアの看板を見たときの状況を思い出し、さらにいくつかの家を通り抜けなければならないと考え、最悪の場合、必要なものを買うためにブロックします。 Microsoft System Center Configuration Managerを使用している珍しい人は、この言葉に言及して、結果の信頼性に関連する多くの問題を提示します。 解決策について説明します。







著者に発言権を与えます。



こんにちは同僚。 Microsoft System Center Configuration Manager（以降ConfigMgr）で作業する各管理者は、インベントリ機能を毎日使用します。 これは、管理対象環境に関するデータを収集する基本的な機能であり、将来、コレクション、クエリ、レポートの作成に使用されます。 インベントリ機能の設定と使用は明らかに簡単ですが、ConfigMgr管理者は、結果の信頼性に関する一定の問題に直面しています。 この記事の目的は、インベントリがどのように機能するか、問題を特定し解決する方法を完全に理解することです。 実際、可能な限り「ボンネットの下にあるもの」を考慮しようとします。

免責事項

深く掘り下げる前に、小さな免責事項について議論する必要があります。 ConfigMgrは、Windowsオペレーティングシステムでも、モバイルシステムでもLinux / Unix（nanoWbemを使用）で動作します。 ConfigMgrは当初、Windows OSを管理するための製品として開発されたため、記事ではWindows OSを実行しているクライアントのみを対象としています。 Linux / Unixのインベントリがどのように機能するかを理解したい場合は、コメントを書いて、記事を書くことを検討してください。 次に、最も興味深いものに移りましょう。

在庫に移りましょう

ConfigMgrには、ハードウェアインベントリ（ ロシア語のドキュメントではハードウェアインベントリ）とソフトウェアインベントリ（ それぞれ、ソフトウェアインベントリ）の2種類のインベントリがあります。 この記事では、英語の名前を使用します。 ここで重要なのは、本質的に「名前がコンテンツと一致しない」ということです。 これが、管理者の主な間違いの1つの理由です。 実際、ハードウェアインベントリはWMIインベントリであり、ソフトウェアインベントリはファイルインベントリ（特定のマスクによるファイルプロパティのコレクション）です。 これが、インストールされたConfigMgrソフトウェアのリストがハードウェアインベントリを介して収集される理由です。この情報はWMIクラス（一部はデフォルト、一部はConfigMgrクライアントWMIクラス）にあります。



実際には、毎日のタスクを正常に完了するために、より多く使用され、より重要です-ハードウェアインベントリ。 したがって、この記事では慎重に検討します。

この機能を使用するには、プライマリサイト側のクライアント設定（クライアント設定->ハードウェアインベントリ）を「有効」にし、スケジュールを設定し、WMIクラスを選択し、そこから情報を収集する必要があります（一部のクラスはデフォルトで有効になっています）。 WMIクラスの詳細な説明は、 MSDNで入手できます。



ConfigMgrは、\ inboxes \ clifiles.src \ hinvにあるConfiguration.mofファイルを使用します。これは、使用されるWMIクラス、WMIプロバイダーを示します。 クライアントがスケジュールに基づいて（管理ポイントに）サーバーにアクセスすると、このファイルが添付されているポリシーがダウンロードされ、ローカルでコンパイルされます。 その後、スケジュールに基づいて、ConfigMgrクライアントはハードウェアインベントリプロセス（以下、hinvと呼びます）を開始します。



ここで、少し余談をする必要があります。 ConfigMgrクライアントはエンジンとエージェントで構成され、それぞれが特定の機能を担当します。 同時に、ConfigMgrクライアントはトリガーコード（リストはここにあります ）を使用して、エージェントでアクションを開始します。 hinvエージェントを開始するには、トリガーコード{00000000-0000-0000-0000-000000000001}を使用します。



クライアントで次の一連のアクションが実行されます。





1. hinvをスケジュールに従って実行します 。 inventoryagent.logには次のエントリがあります。

在庫：アクション{00000000-0000-0000-0000-000000000001}のストアを開いています...

インベントリ：アクション=ハードウェア、レポートタイプ=デルタ、メジャーバージョン= 1、マイナーバージョン= 5

ReportType-プライマリサイトに送信されるレポートのタイプ（DeltaまたはFULL）。 FULL-レポートには、収集されたすべての情報が含まれます（デフォルトでは、最初のインベントリ中に送信されます）。 デルタ-前のhinv以降の変更のみを含むレポート。 デルタレポートを使用すると、ネットワーク経由で送信される情報のサイズを削減できます。



2. WMIからのデータ収集 ：

... ...

<！[LOG [コレクション：名前空間= \\。\ Root \ cimv2; クエリ= SELECT __CLASS、__ PATH、__ RELPATH、UUID FROM Win32_ComputerSystemProduct; タイムアウト= 600秒。] LOG]！>

<！[LOG [コレクション：名前空間= \\。\ Root \ ccm \ invagt; クエリ= SELECT __CLASS、__ PATH、__ RELPATH、Domain FROM CCM_ComputerSystem; タイムアウト= 600秒。] LOG]！>

... ............................

WMI調査が完了すると、このマシンで見つからなかったWMIクラスの数を示すレポートが生成されます。 これは、これらのクラスがコレクションのクライアント設定で指定されたが、このクライアントには存在しないことを意味します。 この情報は、クライアントに要求されたデータがあるかどうかを理解するのに役立ちます。

収集：55/63インベントリデータアイテムが正常にインベントリされました。

インベントリ：収集タスクは67.422秒で完了しました

インベントリ：8収集タスクが失敗しました。

3.管理ポイントに送信するためのxmlファイルが生成されます 。 ファイルは、％WinDir％\ CCM \ Inventory \ Tempフォルダに生成されます。

インベントリ：一時レポート= C：\ SMS_CCM \ Inventory \ Temp \ 1870d2e7-631c-49e3-87f2-60b90bc1d410.xml InventoryAgent

インベントリ：レポートタスクを開始しています。 InventoryAgent

レポート：88のレポートエントリが作成されました。 InventoryAgent

インベントリ：レポートタスクは0.937秒で完了しましたInventoryAgent）

4. xmlファイルが管理ポイントに送信され、削除されます（デフォルト） 。

インベントリ：レポートが正常に送信されました。 宛先：mp：MP_HinvEndpoint、ID：{CF597D3C-8D61-47FC-8292-9711F5AC8430}、タイムアウト：80640分MsgMode：署名済み、暗号化なし

xmlを保存する必要がある場合（問題の識別および解決中）、特別な「秘密」ファイルARCHIVE_REPORTS.SMSを作成する必要があります。



hinvランタイムは、クライアントのWMIに保存されています：root \ ccm \ invagt \ C00000000-0000-0000-0000-000000000001。 したがって、フルインベントリを強制的に開始する必要がある場合は、前のhinvの日付のレコードを削除するだけです。ConfigMgrは自動的にFULL hinvを開始します。



管理ポイントでさらにアクションが実行されます。





5-7。 管理ポイントは、hinvレポートを受信して​​処理します。 次に、プライマリサイトに転送します。

<！[LOG [Hinv Retry：********************タスクの開始******************** *] LOG]！>

<！[LOG [Hinv：ロードされたクラス定義マップ; DBポリシーのタイムスタンプ= 2016-12-28 08：07：10.000] LOG]！>

<！[LOG [Hinv：正規化されたDBポリシータイムスタンプ：20161228080710.000000 + 000.] LOG]！>

<！[LOG [Hinv Sax：loading C：\ CM2012CB \ inboxes \ auth \ dataldr.box \ HinvAttachmentYNWMKIXC.xml] LOG]！>

<！[ログ[クライアントからのデルタレポート****、アクションの説明=ハードウェア]ログ]！>

<！[ログ[Hinvタスク：レポートの添付ファイルをファイル「C：\ CM2012CB \ inboxes \ auth \ dataldr.box \ HCJ91LAV.MIF "に変換して0が返されました] LOG]！>

7 *。 管理ポイントがプライマリサイトの外部にインストールされている場合、 MPファイルディスパッチマネージャーコンポーネント（MPFDM.log）が使用されます。



プライマリサイト側のアクション：





8.データローダーコンポーネント （hinv処理を担当）は、そのinboxes \ auth \ dataldr.boxルートフォルダーで新しい* .mifファイルを検出し、それをさらに処理するためにinboxes \ auth \ dataldr.box \ process \フォルダーに移動します。



9-10。 mifファイルを処理するとき、データはConfigMgrデータベースに書き込まれます。



9 *。 mif 処理中にファイルが拒否された場合、ファイルは inboxes \ auth \ dataldr.box \ badフォルダーに移動され、14日間保存されます。 14日後、ConfigMgrはそれを自動的に削除します。 したがって、情報はデータベースに入力されないため、信頼性が低下し、ConfigMgrの機能全体に影響します。



mifファイルを不良ファイルに移動すると、ConfigMgrは処理エラーのタイプをフォルダーの名前として使用してサブフォルダーを作成します。 例：

InvalidMachine、NonExistentRow、MissingSystemClass、InvalidFileName、ExceedSizeLimit

mifファイルを拒否する理由とその対処方法の詳細な説明は、 記事Umair Khan（サポートエスカレーションエンジニアMicrosoftサポート）に記載されています 。 この記事は、どのバージョンのConfigMgrを使用している人にも絶対にお勧めします。



私の経験に基づいて、ロシア語環境（キリル文字が使用されている環境）では、mifファイルが拒否される別の理由があることを追加できます-dbo.INSTALLED_SOFTWARE_DATAおよびdbo.INSTALLED_SOFTWARE_HISTテーブルのServicePack00フィールドの次元の不一致です。 デフォルトでは、ServicePack00（dbo.INSTALLED_SOFTWARE_DATA）の次元は255（nvarchar）であり、ServicePack00（dbo.INSTALLED_SOFTWARE_HIST）の次元は8（nvarchar）です。 その結果、ConfigMgrがmifファイルの処理中にデータをHISTに移動しようとすると、ディメンションのためにデータが渡されず、mifが拒否されます。 修正オプションは、HISTテーブルのフィールドの次元を変更することです。 ただし、完全なテストを行った後にのみ、運用サーバー上のConfigMgrデータベースに変更を加えることができ、これが重大な障害につながる可能性があることに留意する必要があります。



ConfigMgr管理者は、拒否されたmifファイルの蓄積を常に監視する必要があります。 これを行うには、組織で使用可能な運用監視システムまたはInbox Monitorユーティリティを使用できます。



ハードウェアインベントリ自体は、多数のビューとしてConfigMgrデータベースに保存されます。 現在のハードウェアインベントリはv_GSで始まるビューに保存され、履歴データはv_HSで始まるビューに保存されます。 すべてのビューの説明を含む詳細情報は、 ここから入手できます 。 この情報を使用すると、最小限の労力で必要なレポートを簡単に受け取ることができます。



この記事がConfigMgr管理者がhinvプロセスをよりよく理解し、この機能の操作中に発生する障害を探して修正する方法を明確に理解するのに役立つことを願っています。

著者について

Andrey Petrovは、インフラストラクチャサポート、クラウドコンピューティング、DevOpsを専門とする15年の経験を持つITスペシャリストです。



このトピックに関する以前の記事： 略語SCCM [Crib]で混乱しないようにする方法 。