どのクライアントがディストリビューションの更新を失敗させているのかを見つけるにはどうすればよいですか？
それは時々起こります。パッケージを更新し、配布ポイントを更新する必要があります。複数のDPがあり、通常はすべて正常に実行されますが、時々、メインDPがパッケージの更新に失敗します。 コンテンツステータスログは、失敗について多くを語りません。管理ポイントまたはDPへのバックエンドサーバーのアクセス権がありません。SCCM管理者です。SCCMのログを確認したり、レポートを実行したり、すべてを実行したりできますが、どこを見ればいいのかわかりません。 過去に、問題のあるパッケージの「Disconnect Users from Distribution Point」設定を両方のサブ設定を0に設定しようとしましたが、実際には機能しません。問題はしばらくすると自然に解消されるようですが、時には数日かかることもあります。大部分（実際にはすべてですが、見落としている1つまたは2つがある場合があります）は、クライアントを "配布ポイントからプログラムを実行する"に設定します。原因は。 更新 私はレポート、特にAll Status Messages for a Specific Package at a Specific Siteクエリでもう少し情報を見つけました。クエリにパッケージIDを使用すると、DP更新が再び失敗した後、際立ったエントリが1つ表示されました。 配布マネージャーは、パッケージ「構成の更新」の処理に失敗しました（パッケージID = SOM00013）。 考えられる原因：配布マネージャーに、パッケージソースディレクトリまたは配布ポイントへのアクセス権がありません。解決策：配布マネージャーがパッケージソースディレクトリ/配布ポイントにアクセスできることを確認します。 考えられる原因：パッケージソースディレクトリに長いファイル名のファイルが含まれており、パスの全長がオペレーティングシステムでサポートされている最大長を超えています。解決策：パッケージに定義されているフォルダーの数を減らすか、ファイル名を短くするか、圧縮ユーティリティを使用してファイルをバンドルすることを検討してください。 考えられる原因：サイトサーバーコンピューターまたは配布ポイントに十分なディスク領域がありません。解決策：サイトサーバーコンピューターと配布ポイントに十分な空きディスク領域があることを確認します。 考えられる原因：パッケージソースディレクトリには、アクティブなプロセスによって使用されている可能性のあるファイルが含まれています。解決策：ソースディレクトリ内のファイルを使用している可能性のあるプロセスをすべて閉じます。この失敗が続く場合は、ソースディレクトリの代替コピーを作成し、それを指すようにパッケージソースを更新します。 私は単純な理由で中央の2つの原因を疑っています ソースフォルダーは、NTFSの長いファイル名を格納するほど深くはありませんが、完全性を確認しようとします。 DPにファイルを問題なく追加できるので、ファイルスペースの問題ではなく、他のパッケージを問題なく更新できます。 私が予期していなかったのは、3番目の原因がソースディレクトリがどこかで使用されていると言っていることです。とにかくそれはどのような違いをもたらすでしょうか？ファイル共有からSCCM DP共有にファイルをコピーするだけではありませんか？さらに私をループb / cクライアントに投げつけても、ソースディレクトリにアクセスすることはありません。sccmがファイルをコピーするためのステージングディレクトリにすぎません。 それは最初の原因を残すだけですが、それは同じことに戻ります：他のパッケージは問題なく更新できます。