none
Content Distribution for Failed Packages - Behaviour RRS feed

  • Question

  • Hello All,

    I'm trying to understand how SCCM would handle the distribution of packages/applications(content) which is in Failed status for whatever reason.

    We've had multiple applications (like Office 365 and the related ones) for which there were changes made in the source content. And then we had tried to do an Update Content on all of them we couldn't see any change or progress under Monitoring > Content status.. and basically most of them were showing in the failed category. And they've probably been that way the whole of last week. I understand by design the pkg redistribution is attempted for a certain no. of times and then it stops. 

    This was the status around the end of last week. And then over the weekend we had upgraded SCCM from 1806 to 1906 and there weren't any major issues.

    When we checked this week it looked like all the above mentioned Office applications are showing In Progress and even the distribution is succeeding for all the packages that were showing as 'Failed' at the end of last week. And this happened without anyone triggering the redistribution on the packages. 

    So we're now trying to figure out what could have triggered the above redistribution of failed packages from last week? Is it by design or a result of any queued up commands from a previous attempt? Or something else?

    Thank You in advance for your time and comments. 


    SamSV

    Friday, November 22, 2019 11:49 AM

Answers

  • First, don't confuse content redistribution and content update; they are two different operations.

    Next, it sounds like there was something preventing the content update process from happening and so it was queued up. My guess here is that there was a locked file that prevented ConfigMgr from grabbing the updated content and a reboot of the site server released these locks. Without reviewing distmgr.log and possible pkgxfer.log, there's no way to know for sure though.


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

    • Marked as answer by SamSV Wednesday, November 27, 2019 5:45 AM
    Friday, November 22, 2019 1:55 PM

All replies

  • First, don't confuse content redistribution and content update; they are two different operations.

    Next, it sounds like there was something preventing the content update process from happening and so it was queued up. My guess here is that there was a locked file that prevented ConfigMgr from grabbing the updated content and a reboot of the site server released these locks. Without reviewing distmgr.log and possible pkgxfer.log, there's no way to know for sure though.


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

    • Marked as answer by SamSV Wednesday, November 27, 2019 5:45 AM
    Friday, November 22, 2019 1:55 PM
  • Hi Jason.

    Thank You much for reverting back. This sounds like the most possible explanation to the observed behaviour. We were infact running a Content Extraction of multiple packages (including the above Office packages) earlier in the week for subsequent Prestage purposes. So that would have probably locked down some of the files. But when I looked in the DP Job manager queue, I didn't see any queued jobs for the above content updation attempts. Probably that's not the right place to see? Or such queued events might not be visible always?

    Also would I be correct in assuming my earlier observation.. <<I understand by design the pkg redistribution is attempted for a certain no. of times and then it stops. >>. There isn't any "automatic redistribution(or updation) of ALL failed packages" happening by default within SCCM, is it?

    Very greatful for your time, again.


    SamSV

    Friday, November 22, 2019 2:16 PM
  • There isn't any "automatic redistribution(or updation) of ALL failed packages" happening by default within SCCM, is it?

    Not to my knowledge, however, an upgrade may reset the counter for this.


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

    Friday, November 22, 2019 2:43 PM