差分ダウンロードのログ解析調査

下記の公開情報にある通り、ダウンロード時にはWindowsUpdateAgent を利用してダウンロードを行う。
また、配信の最適化も有効にしておく必要がある。今回はダウンロードモードを「LAN」で検証している。

クライアントが利用可能な場合に差分コンテンツをダウンロードできるようにする

**************************
以下、検証環境の設定一覧
**************************
・利用バージョン
CB 2207

・クライアント設定

・WSUS の設定（代替ダウンロードサーバー）

・配信の最適化

**************************
以下はインストール開始時のログ（DeltaDownload.log は流れて採取できなかった）
**************************

ContentTransferManager.log
---------------------------------------------
11-22-2022 20:58:25.281    ContentTransferManager    5672 (0x1628)    CTMJob({0CFC7586-6924-4427-A61F-D80B65F7AE68}): CCTMJob::ProcessDownloadSuccess - successfully processed download completion.
11-22-2022 21:04:50.162    ContentTransferManager    4852 (0x12f4)    This client will report download history every 1440 min.
11-22-2022 21:05:06.115    ContentTransferManager    4320 (0x10e0)    CTM_StartJob - Starting CTM job {139F183F-7F56-4F21-ACD3-184A1C486746}
11-22-2022 21:05:06.147    ContentTransferManager    4320 (0x10e0)    Created CTM job {139F183F-7F56-4F21-ACD3-184A1C486746} for user S-1-5-18

CMBITSManager.log
---------------------------------------------
11-22-2022 20:58:25.289    CMBITSManager    5808 (0x16b0)    For CMBITS job {D18A6008-66DB-442C-8F92-A04CFA1DA15A}, CTM job {0CFC7586-6924-4427-A61F-D80B65F7AE68} entered phase CCM_DOWNLOADSTATUS_DOWNLOAD_SUCCESSFUL
11-22-2022 21:04:50.162    CMBITSManager    3452 (0xd7c)    Loaded persisted job with ID {D18A6008-66DB-442C-8F92-A04CFA1DA15A}, DisplayName Express Job  for content 7ca4f9b0-d72c-4974-9f24-183150df320f.1, on startup
11-22-2022 21:04:50.162    CMBITSManager    3452 (0xd7c)    CCMBITSManagerStartup::FinalRelease()
11-22-2022 21:05:05.959    CMBITSManager    4320 (0x10e0)    Added CMBITS job with ID:{4485462C-66C3-429B-A5C1-5BB976DAC373}, DisplayName:Express Job
11-22-2022 21:05:05.959    CMBITSManager    4320 (0x10e0)    Download manifest for the job 

**************************
ダウンロード中のログ
**************************

ContentTransferManager.log（配信の最適化（DO）を利用して、配布ポイントからコンテンツをダウンロードしている）
---------------------------------------------
11-22-2022 21:17:28.741    ContentTransferManager    4320 (0x10e0)    Created CTM job {792F9C7D-BDF4-4780-86FE-A052CD3AA690} for user S-1-5-18
11-22-2022 21:17:28.944    ContentTransferManager    3372 (0xd2c)    CTMJob({792F9C7D-BDF4-4780-86FE-A052CD3AA690}): CCTMJob::_PersistLocations - Persisted locations 
	(SUBNET) http://mpdp.gibson.com/SMS_DP_SMSPKG$/7ca4f9b0-d72c-4974-9f24-183150df320f
	(SUBNET) https://mpdp.gibson.com/CCMTOKENAUTH_SMS_DP_SMSPKG$/7ca4f9b0-d72c-4974-9f24-183150df320f
11-22-2022 21:17:28.959    ContentTransferManager    3372 (0xd2c)    CTMJob({792F9C7D-BDF4-4780-86FE-A052CD3AA690}): CCTMJob::_DownloadContent - Created corresponding DTSJob({624860B5-17D8-45D3-A644-EDC5B6718521})
11-22-2022 21:17:28.959    ContentTransferManager    3372 (0xd2c)    CTMJob({792F9C7D-BDF4-4780-86FE-A052CD3AA690}): CCTMJob::_DownloadContent - DTSJob({624860B5-17D8-45D3-A644-EDC5B6718521}) started to download from 'http://mpdp.gibson.com/SMS_DP_SMSPKG$/7ca4f9b0-d72c-4974-9f24-183150df320f' for full content download.
11-22-2022 21:17:28.959    ContentTransferManager    4788 (0x12b4)    CTMJob({792F9C7D-BDF4-4780-86FE-A052CD3AA690}): CCTMJob::ProcessProgress - entered phase CCM_DOWNLOADSTATUS_PREPARING_DOWNLOAD
11-22-2022 21:17:28.991    ContentTransferManager    3540 (0xdd4)    CTMJob({792F9C7D-BDF4-4780-86FE-A052CD3AA690}): CCTMJob::ProcessProgress - entered phase CCM_DOWNLOADSTATUS_DOWNLOADING_DATA
11-22-2022 21:17:29.413    ContentTransferManager    3540 (0xdd4)    CTMJob({792F9C7D-BDF4-4780-86FE-A052CD3AA690}): CCTMJob::ProcessDownloadSuccess - successfully processed download completion.
11-22-2022 21:24:50.231    ContentTransferManager    3540 (0xdd4)    CTMAggregateDownloadHistoryTask::HandleDownloadHistory: preparing to aggregate and send download history to server.

CMBITSManager.log
---------------------------------------------
11-22-2022 21:17:29.475    CMBITSManager    3540 (0xdd4)    CCMBITSManager::NotifyDownloadComplete
11-22-2022 21:17:29.475    CMBITSManager    3540 (0xdd4)    For CMBITS job {C7CE0550-B5BE-4EA6-8F25-48E9F1413632}, CTM job {792F9C7D-BDF4-4780-86FE-A052CD3AA690} entered phase CCM_DOWNLOADSTATUS_DOWNLOAD_SUCCESSFUL
11-22-2022 21:46:45.760    CMBITSManager    2756 (0xac4)    Loaded persisted job with ID {D18A6008-66DB-442C-8F92-A04CFA1DA15A}, DisplayName Express Job  for content 7ca4f9b0-d72c-4974-9f24-183150df320f.1, on startup

差分コンテンツダウンロードは BITS ではなく、DO で実現しているので、BITS Explorer に表示されない。
ただし、CMBITS job は、BITS Explorer に表示される前の CM 内で生成される Job のようなので、ログには「Express Job」記録される。

CMBITSManager.log
---------------------------------------------
11-22-2022 21:05:05.959    CMBITSManager    4320 (0x10e0)    Added CMBITS job with ID:{4485462C-66C3-429B-A5C1-5BB976DAC373}, DisplayName:Express Job
11-22-2022 21:05:05.959    CMBITSManager    4320 (0x10e0)    Download manifest for the job 

**************************
ダウンロード完了のログ
**************************

DeltaDownload.log
---------------------------------------------
11-22-2022 21:17:28.694    DeltaDownload    4320 (0x10e0)    CDeltaBitsManager::ProcessRanges - batched 1048576 bytes
11-22-2022 21:17:33.756    DeltaDownload    4320 (0x10e0)    Bytes Transferred: 1048576
11-22-2022 21:17:33.756    DeltaDownload    4320 (0x10e0)    CDeltaBitsManager::DownloadRanges - updated m_workingJobMap for request -720575938231795590, BGJobState = 6
11-22-2022 21:46:47.198    DeltaDownload    3788 (0xecc)    ===========================================================

ccmcache をパッケージ展開を利用してスクリプトでコンテンツを削除

 ccmcache の最大キャッシュサイズについては、クライアント設定から設定が可能です。

ただし、ソフトウェア更新プログラムについては、こちらの最大キャッシュサイズの制限は効かない動作となっております。

そのため、機能更新プログラムを配信すると、すぐにキャッシュサイズが大きくなる場合があります。

そのような場合、クライアント側であれば、クライアントコンソールから下記のボタンより、ccmcache をクリアすることが可能です。

しかし、サーバー側から直接削除するための指示というのは、標準機能では存在しません。

そのため、このクライアント側の容量をサーバー側からなんとかしたい、ということを管理者は考えます。

その場合、ccmcache のフォルダーを直接削除するスクリプトを配布するのはNG です。

ccmcache フォルダーはWMI 空間で管理されているので、下記のPowerShell コマンドから削除しないといけません。

$UIResourceMgr = New-Object -Com "UIResource.UIResourceMgr"
$Cache = $UIResourceMgr.GetCacheInfo()
$Cache.GetCacheElements() | % {$Cache.DeleteCacheElement($_.CacheElementID)}

あとは、こちらを test.ps1 などのファイルにして、パッケージ展開をするだけです。
パッケージ展開で気をつけるところは、PowerShell コマンドの実行には、下記のようにコマンドを指定しないとうまく動きません。

powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File test.ps1

こちらのコマンドは、以下の画面の [コマンド ライン] へ入力します。

こちらのパッケージを作成したら、今度は対象のコレクションへ配信するために展開を作成します。

ここでも注意が必要です。下記のように、配布ポイントの展開オプションで [配布ポイントからプログラムを実行する] を選択する必要があります。

こちらの展開オプションを選択しない場合、クライアントはローカルにスクリプトをダウンロードして実行してしまうため、以下のエラーが execmgr.log に記録されます。

CacheManager: Cache is in Use. DeleteCacheItem cannot proceed.
CacheManager.DeleteCacheItem failed with 0x87d01203

エラーコード：0x87d01203 は、今回のシナリオでは、削除対象のコンテンツがダウンロード中であったり、実行中である場合に記録されるものとなるため、ローカルにスクリプトをダウンロードして実行すると、こちらのエラーが発生します。

そのため、上記の配布ポイントの展開オプションは必須となりますが、こちらは SMB プロトコルで通信をしますので、ポート445 が開放していない環境では利用できませんので、ご注意ください。

Japan Microsoft Endpoint Manager Support Team のブログ公開

下記のリンクから、Japan Microsoft Endpoint Manager Support Team のブログにいけます。

日本マイクロソフト サポート情報 (cssjpn.github.io)

今までのフォーラムの情報もアーカイブとして残っていますが、いつ削除されるかわからないので、保存しておきたい情報はスクショしておきましょう。

ちなみにブログのリンクは以下。

Japan Microsoft Endpoint Manager Support Blog (jpmem.github.io)

MECM/SCCM でのBranchCache とPeerCache を併用した場合の動作について

MECM/SCCM では、BranchCache とPeerCache の設定を両方有効にすることが可能です。

その場合、どちらの機能を利用してコンテンツをダウンロードするの？という疑問が湧いてきます。

これは結論から言うと、通常の環境であれば、PeerCache が有効になるケースがほとんどとなります。

理由としては、BranchCache は配布ポイントからダウンロードされる場合に有効となりますが、コンテンツのダウンロードソースの優先順位はPeerCache ソースの方が優先順位が高いため、PeerCache が有効になります。

ただ、PeerCache ソースがダウンしているような状況であれば、配布ポイントからのコンテンツダウンロードが動作するため、その場合はBranchCache が利用される動作となります。

コンテンツのダウンロードソースの優先順位は下記の公開情報に情報がありますので、確認してみてください。

 コンテンツ管理の基礎 - Configuration Manager | Microsoft Docs

MECM/SCCM のピアキャッシュの一部ダウンロードの動作検証

MECM では、ピアキャッシュという機能があります。

簡単にいうと、ピアキャッシュソースというコンテンツを持つクライアント端末に対して、他のコンテンツを持たないクライアントが、ピアキャッシュソースからコンテンツをダウンロードする、というもので、配布ポイントからのダウンロードをしない動作となります。 

クライアントのピア キャッシュ - Configuration Manager | Microsoft Docs

この中で、MECM の管理コンソールの下記のチェックを有効にした場合に、上記の公開情報にある一部ダウンロードという機能が有効になります。

このチェックを入れてピアキャッシュの機能を検証してみたところ、下記のようなログが出力されました。

黄色の部分と白色の部分で、別端末のログを示しています。

まず緑の部分を上から見ていくと、最初に白のクライアントがブロック２をダウンロードしています。このダウンロード上に黄色のクライアントがブロック３をダウンロードしています。

その後、白のクライアントがブロック２をダウンロード完了し、次にブロック４をダウンロードしようとしています。

その後、黄色のクライアントがブロック３をダウンロード完了し、白のクライアントがすでにダウンロード完了した、ブロック２をダウンロードし始めます。

つまり、この機能は同時に同じブロックのコンテンツを複数端末にダウンロードさせないように制御されています。

そのため、最大でもファイルのコンテンツサイズのダウンロード分の帯域しか利用されないため、設定のところにも記載があるように、「WAN の使用率を下げる」ことができる、ということになるようです。

SCCM Client Agent のパッケージ配信インストール方法

SCCM Client Agent をパッケージ展開してClient Agent をインストール（アップグレードも可）する場合、まずプライマリサイトサーバの最新バージョンのClientフォルダを展開のパッケージ作成時に指定するフォルダにコピーします。

デフォルトでClient フォルダは以下になります。

C:\Program Files\Microsoft Configuration Manager\Client

そのフォルダ内に下記のサンプルコマンドを持つバッチファイルを「install.bat」として保存します。

■サンプルコマンド

 \\<ServerName>\<ContentsPath>\ccmsetup.exe /source:"\\<ServerName>\<ContentsPath>" SMSSITECODE=<SiteCode>

※適宜、管理ポイントを指定するオプション等を追加してください。 （*1）

パッケージ展開作成時に、[このパッケージにソースファイルを含める] を選択して、先ほどコピーしたフォルダを選択し、コマンドラインに下記のように指定します。

%windir%\sysnative\cmd.exe /c install.bat

こちらのパッケージを展開すれば、クライアントのインストール、もしくはアップグレードが可能になるかと思います。
すでにClient Agent がインストールされているクライアントにインストール（アップグレード）する場合、サイズの制限に達していなければ、ccmcache は削除されませんので、検証してみてください。

(*1) CCMSetup.exe のコマンドライン パラメーター

SCCM で管理しているクライアントで、意図せずパッチが適用され再起動されてしまう場合

SCCM で管理しているクライアントに再起動をしないように展開設定してパッチを適用しているが、意図せずクライアント側でパッチ適用、及び再起動が実行されてしまう場合があります。

この原因の多くは、WSUS のグループポリシーによるものです。

具体的には、下記のグループポリシーが有効になっている場合、WSUS 側で管理されているパッチが適用され、再起動がされてしまいます。

そのため、クライアントのパッチのすべてをSCCM で管理したい場合は、こちらの項目を[無効] にするのがよいでしょう。

ダウンロード済みのソフトウェア更新プログラムをダウンロードしていない状態に戻す方法

前回、ソフトウェア更新プログラムのコンテンツをダウンロードするのに、VPN 回線を利用させない方法をご紹介しましたが、１つの展開設定に関して、前提条件を満たさないと表示されない設定がありました。

それは配布ポイントからコンテンツをダウンロードさせない設定になるのですが、展開設定の中で、「展開パッケージなし」を選択する、というものでした。

この選択画面を表示させる場合、対象のコンテンツがダウンロードされていない状態でないと、この画面は表示されません。

そのため、これをダウンロードされていない状態に戻すやり方があります。
参照している展開をすべて削除することで[ダウンロード済み] 列が[はい] から[いいえ] に変わります。

やり方としては、QU であれば、下記の[展開パッケージ] より、[メンバーの表示] を表示させると、その展開パッケージが参照しているQU を確認できるので、ダウンロード済みを[いいえ] にしたいQU がある場合は、その展開パッケージを削除します。

FU の場合は、展開] タブより、展開を削除していただければOK です。

ただ、すでに展開をしているような状況であると、展開を削除しなければいけないため、削除してよいかを確認する必要がありますが、間違えて展開を削除しても、また対象のコレクションに対して展開を作成してあげれば、QU, FU が適用されていないコレクションに対して、再度適用する動作となります。
ただ、自身が作成していない展開設定であれば、確認をして削除することをお勧めします。

VPN回線を使わないで、VPNクライアントにソフトウェア更新プログラムをダウンロード

SCCM でVPN クライアントを管理する場合、VPN 回線を利用して何GB ものコンテンツを配布ポイントからダウンロードしてしまうことが、管理者にとっての悩みになるかと思います。

しかし、VPN Split Tunneling を利用できる環境であると、VPN 回線でSCCM サーバーとのポリシー情報を同期し、インターネット回線でFU, QU などのソフトウェア更新プログラムを取得することが可能になるかと思います。

じゃあ、実際にどうやるかというと、下記の前提条件を元に、いくつか設定する項目がありますので、そちらを設定して上げるとうまくいくと思われます。

前提条件：VPN クライアントを特定の境界、境界グループに所属させる。

この前提条件を満たすことにより、境界グループの下の設定を利用できます。

この設定にチェックを入れておくことで、通常配布ポイントにコンテンツを取得しに行く動作が、最初にクラウドベースのソース、すなわちWindows Update 等を参照しに行きます。
VPN Split Tunneling を利用して、これにチェックを入れるということは、展開設定はVPN 通信でサーバーからクライアントに同期され、クライアントはこのチェックの通り、インターネット経由でコンテンツをダウンロードする、ということが可能となります。

ただ、インターネット経由でのダウンロードに失敗した場合、やはり配布ポイントにコンテンツを取得しに行こうとする動作は依然として残っています。

その場合は、展開設定で[展開パッケージなし] を選択してあげると、配布ポイントにコンテンツが存在しない状態となります。

これに加えて下記の設定をしてあげることで、配布ポイントにコンテンツがない場合、インターネット経由でコンテンツをダウンロードする動作となりますので、検証して頂ければと思います。