Hi all. We only have 2 packages that contain all of the Software updates we deploy. Each package is about 20GB right now. Based on my research, there is no limit on size or number of updates within an update package.

Recently, we downloaded the latest out of cycle patches MS released on August 20th, and I did a "Update Distribution Points" on the package we downloaded the updates to. Now this is where things started to get strange:

- In the SCCM console, the package content status was stuck at In Progress for both my primary and remote pull DP

- Found a status message for the pull DP that said "Site System Status Summarizer has not been able to access the storage object". Found a related forum post that had me add a registry entry: HKLM\SOFTWARE\Microsoft\SMS\Operations Management\SMS Server Role\SMS Distribution Point, Name: Availability State, Type: REG_DWORD,Data: 0.

-The registry entry (added to primary and Pull DP) caused the package to update on my primary DP, but my pull DP failed out with a generic "failed distributing content" message in the Distribution Point Configuration Status Details tab.

- There are no messages in distmgr.log or status messages for the Distribution Manager component that indicate anything is wrong. In fact, logs and status messages usually report that processing was successful, but the SCCM console never reflects that. I removed the package from my DPs then re-added it, but now the content status is now stuck at 0 targeted DP's!?

Just wondering if anybody had any advice for me? Should I delete and re-create the update package? I'd rather not as it will be difficult. Is there any other logs I should be looking at?

It's never a good idea to use such huge packages. Smaller ones can be handled much easier (in troubleshooting scenarios). Try splitting them up (on a per product basis for example).

To add to Torsten comment i would read this :

https://technet.microsoft.com/en-us/library/hh692394.aspx?f=255&MSPPError=-2147217396

So you can make sure to limit your software update group to max of 1k

You must limit the number of software updates to 1000 for each software update deployment

Yes, currentlyl we only break them by "OS related" updates and "Non OS related", but now I think I will break up each of those categories into years as well.

However there is no published limit on package size from MS.

Yes, I have read that Technet page, and I am aware of the 1000 limit for Software Update Groups, which I adhere to. However there is no published limit on the number of updates in a software updates package.

Really, the package is just a virtual directory on the DP HTTP server, and clients can just download the single update they need, not the whole package. So, technically, there doesn't need to be a limit.

However in hindsight, the large package size makes troubleshooting and distributing the packages more difficult for an administrator. It would be nice if there was no problems with the packages tho.

I have broke up the offending package into a couple smaller bits and will see if that helps. It's going to take most of the day to re-download 2000+ updates though.

However, the original issue of success messages in the logs, yet problems in the console remains.

The status message is completelt benign however if you want to make it go away see http://eskonr.com/2013/12/configmgr-2012failed-to-get-the-availability-state-on-server-for-role-sms-distribution-point-error6-sitestat-log/

I've found that once update packages get corrupted, there's no recovering them and thus always make sure I have smaller packages thus echoing Torsten's recommendation. And yes, there are no stated technical by design limitations on package size, that doesn't mean there aren't practical limits or points where things break. note also that package size here is more about number of files. Many/most Windows Updates only contain one a just a small handful of files. Many Office updates however contain hundreds and in the case of Office 2013 SP1 almost a thousand files and the packages containing these updates are the ones I have issues with. Thus, I would recommend splitting out your Office updates into their own packages even going so far as to put the Office service packs into their own packages.

Thanks everybody. I halved my big package into to 2 smaller ones, but I was still having major problems getting my remote Pull DP to actually download the package. The PullDP log files were all idle for hours even after refreshing content.

I ended up disabling the Pull DP feature and things are looking better so far.

In retrospect, I don't think the package was the problem, but my Pull DP was. However, I agree with you guys about shrinking my package sizes in preparation for these situations! I guess I just prefer a simple, clean setup that is easy for the Service Desk staff to figure out where to put stuff.

Thanks again.