Hi,

Does anyone know if this is normal behaviour?

A while back, I read a book "System Center 2012 Configuration Manager Unleashed" and it mentioned that clients do not participate in delta replication, so if a client downloads a package and the source files are changed, it will re-download the whole package, not just the changes. Maybe I misunderstood?

This week, I notice the opposite in my prod environment. While deploying an update (Update Content) of a in-house application (old content present in the client cache), the client agent copied the (new) updated files (of the application) from the DP, but the files that were not updated (still part of the application) were not copied from the DP! Instead, they were copied from the old client cache folder to the new client cache folder.

I determined this because there is a very large file (1GB) that was not modified and the network utilization remained almost not used. However, the CPU usage was high. I assume that the client was doing a hash check on the large file and determined that it was not changed, so it copied it form the old cache folder instead of re-downloading it from the DP. The small files that did change, were copied from the DP and retained the original date stamp.

The issue here, is that when unchanged files are copied from the old local cache folder to the new folder, it also modifies the date/time stamp of  those files. Why does it change the date/time stamp? This breaks the in-house app. I know, why does a developer depend on the dates of a file?!

This appears to be normal. I came across this blog "http://blog.kloud.com.au/tag/sccm/" (thank you for sharing).

Even though, it is talking about detection methods, it mentions the same issue:

"The other issue we found is that SCCM has a habit of changing the Date Modified timestamp of all files it delivers when it detects an upgrade of the source files for that application. It typically does not touch the timestamp of the source files if it delivers a brand new install to a client that has never received the software, however if a single file in the source folder is changed for that application, then SCCM tries to use a previous version of the application in the cache (C:\windows\ccmcache) and only downloads the new file that has change. This results in all files having their Data Modified timestamp changing (except for the brand new file). Therefore determining if that application has delivered successfully using Date Modified timestamps is not recommended. The key to seeing this process in action is looking at the file properties in the C:\windows\ccmcache\<sccm code> folder for that application, particularly before and after a file is updated in the original source SCCM application folder."

Questions:

1- does the client really only download updated files for an application, form the DP, or is it supposed to re-download the whole content, when the previous version is still available on the local ccmcache folder?

2- If the client copies files that are available in ccmcache, instead of re-downloading from the DP (hash check), why does it modify the date/time stamps of those files?

Reproducing:

On the console:

- create an application

- create a deployment type, source files can be a large 1GB+ file and a small text file

- distribute the content to a DP. wait for distribution to complete.

- deploy the application to 1 client (required, immediately)

On the client:

- clear the ccmcache (ease of troubleshooting)

- run the machine policy action and monitor the network bandwidth usage. once the client starts to download, a cache folder is created, along with a BDRTEMP folder. the network bandwidth should be high for a few minutes (downloading the large file)

* the ccmcache subfolder will have the correct time of the original files (small text file and large file). this is the same as found on the applications' source path

Proving the client doesn't redownload the large unmodified file:

- open the small text file from the source folder of the application, and modify the contents, save the file

- Update Content on the DT of the application. wait for distribution to complete.

- delete the previous deployment and create a new one for 1 client (required, immediately)

- run the machine policy action and monitor the network bandwidth usage. once the client starts to download (it may take a while), a new cache folder is created. the network bandwidth should be very low and quick (only downloading the small text file). if you compare the date and time stamp of both files:

* the newer ccmcache subfolder will have the correct time for the modified small text file (after being modified), but the large file will have a modified date/time as of when the client copied the file from the old cache folder to the new one. It is not the same as found on the applications' source path...

If you run a hash check tool on the large file from the source path, and the old cache folder and the new cache folder, all have the same hash, but the new cache folder is the only one with a newer date stamp!

SCCM 2012 R2 CU5

thanks

• Edited by fern.santos 12 hours 57 minutes ago

I think this was added in R2 and is only valid for Applications (and not packages).