none
After Update Content in the deplyoment type, on PC Client Content CCMCache Client Not download the new source defined in the deplyoment type but download old content RRS feed

  • Question

  • For the first time, we're detecting an anomaly after we've updated the source files to deploy an application.

    Although we did the update content above the deployment type, and verified by the monitoring section that the content is registered as up-to-date, the deployment recipients continue to download the old source files to the cache.

    The source of the setup is an .exe file.
    The .exe file has been overwritten with a new version. the file name has not changed, but only the version has changed.

    We've already tried to completely remove the content from the distribution points and then redistribute it, but the problem persists.
    What's not working?

    -The application has about 30 deployment types.

    -Each deployment type uses the same content location.

    -The difference in each deployment type is the program string and requirements.

    What's not working?

    NOTE : some time ago, I had read somewhere that anomalies might occur during content deployment, if multiple applications or multiple deployment types use the same content source path for setup. I never understood if they were isolated cases or if it is a certified behavior rule of the SCCM product.
    We have other applications that have more than one deployment type with the same source content, which use different strings, but until now we had never had this anomaly. Is there a limit on the number of deployment types for applications?
    We also eliminated all revision history and left the most recent one, but it didn't help.


    I have no other idea of what the cause of our problems might be.

    Thank you for your support.
    Thursday, November 7, 2019 11:14 AM

All replies

  • Did the machine policy update (either automatically or through manual initiation) on the client(s) after the content was updated on the DPs?

    Was the deployment previously enforced on the client?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, November 7, 2019 1:51 PM
  • Machine Policy Retrieval & Evaluation Cycle =  We start manually from the computer.

    Before I forced Update Policy, I deleted the cache content by using the prevented option on the agent on the computer.

    Yes, the deployment was already in deployment state when we changed the setup source.

    The anomaly also occurs above new computers that had never received this distribution.

    Thursday, November 7, 2019 2:04 PM
  • > Yes, the deployment was already in deployment state when we changed the setup source.

    Sorry, don't know what "in deployment state" means. I asked whether it was enforced yet or not?

    Also, when and how exactly are you checking that the content is updated on the client?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, November 7, 2019 3:10 PM
  • > Yes, the deployment was already in deployment state when we changed the setup source.

    Sorry, don't know what "in deployment state" means. I asked whether it was enforced yet or not?

    > Yes.

    Also, when and how exactly are you checking that the content is updated on the client?

    delete the contents of the "ccmcache" using the option in the configuration manager agent installed on the client computer.

    Thursday, November 7, 2019 3:52 PM
  • When you added the new content to the source location did you select the Update Content option on the applicable deployment type or did you redistribute from the Content Location tab of the application (or elsewhere) or did you do something else?

    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, November 7, 2019 7:46 PM
  • The Update Content action was, and it was performed multiple times. The location of the content location has not changed. Only one .exe file has changed in the content location. Same name but different version and size. other actions? installation program strings for each deployment type have been modified.
    Friday, November 22, 2019 8:26 AM
  • If the deployment was already enforced on a target client system, there is no reason for the client to (re-)download the content whether it's changed or not and whether you've deleted the cache or not.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, November 22, 2019 2:36 PM
  • but if I changed the "Date Published" and the "software version" in the application properties, in addition to the file "setup.exe", there are more reasons why the computer should reevaluate the application, and then download the new "setup.exe".

    If not, you would say use the "Supersedence" feature, or take a global action to ensure that the computer cache is successfully deleted.

    But that's not the problem!!! ; Although I would be interested in figuring out how to clean up the computer cache in a global but automated way, and correctly for the current branch system center configuration manager agent to correctly recognize this status.

    The main problem that we do not explain, is the following :  

    A computer that has never downloaded and installed this application, because, when it becomes target of this application, from the distribution point downloads the old "setup.exe" if we have updated it with a new one !!!!!

    - done so many times the action of "update content" above one of the 30 deployment types.
    - also tried to remove the content from each distribution point, waited a day and then distributed again above the 30 distribution points !!!

    Thank you for your support and understanding.


    • Edited by Vid3al Friday, November 22, 2019 3:28 PM
    Friday, November 22, 2019 3:27 PM
  • but if I changed the "Date Published" and the "software version" in the application properties, in addition to the file "setup.exe", there are more reasons why the computer should reevaluate the application, and then download the new "setup.exe".

    These are all irrelevant. The Application deployment is already enforced which is the only thing that matters here.

    done so many times the action of "update content" above one of the 30 deployment types.

    Updating content on one deployment type does not also update the content for any other deployment type. You must initiate the update content on each deployment type that is affected by the content change.

    Redistributing content does not include changes.

    Side question: why 30 deployment types? What's the difference between them and if they all share the exact same content, wouldn't using a script in a single deployment type be a better solution?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, November 22, 2019 5:00 PM
  • we then found confirmation in your suggestion. Using contentlibraryexplorer.exe, we noticed that not all deployment types we had the "setup.exe" updated. it only actually updates only if you run update content over each deployment type.
    Each Deployment Type has its own ID, and each ID has file content associated with it, even if it is shared with other deployment types. The shared content change will update only if update content is performed for each deployment type.

    the application that we have been distributing for years, installs the company antivirus. The antivirus console manages, for different policies per location, in different tenants each location.

    each tenant has a different id. the ID parameter is specified as a switch in the command line that starts the "setup.exe".

    so each deployment type corresponds to a location. and each deployment, it has as a requiriment the verification of the organizational unit in active directory. each location has a different organizational unit.

    Setup files are the same for all locations. changes the setup startup string, because each location has a different command line.

    So either we did an application with a deployment type for each location, or as we did in this case, a single application with n deplyoment type that correspond to the number of remote locations.

    at this point, I wonder if there is a way to update n deployment type in a single action. but if it's off-topic, I'll open a new thread.

    I found a powershell command that could help us, but if I got it right, we should run this command n times for each deployment type. each deployment type has a different name.

    Update-CMDistributionPoint -ApplicationName "Application X" -DeploymentTypeName "Install Application X"

    Thank you for your support and understanding.
    Monday, November 25, 2019 3:29 PM
  • As noted, why not use a script in a single deployment instead?

    The script would determine location and then run the command line with the proper ID. Much simpler.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, November 25, 2019 3:58 PM