Rebuild a content library on a Distribution Point
A function to instruct a distribution point to clean-up/rebuild its content library would be great. This would be particularly useful to fix the "package list in content library doesn't match the one in WMI" errors.
We have 260+ DPs, all members of the same Distribution Group, and 35% of them have mis-matched content library sizes. So obviously content clean-up does not succeed. A way to force them to re-evaluate (without redistributing existing content) would be great.
A producrtion version of the content clean up tool shipped today in ConfigMgr 1702
Emiliano Prosseda commented
We have some errors :-)
1) The tool si going to crash if any distribution is in-progress or failed state
2) when the tool starts to delete orphaned files sometimes will fail with a generic error like "DirectoryNotFoundException: Could not find a part if the path" followed by a INI file
Yep, just came up against this headache recently and fortunately our environment is very small by comparison to most, so I can't even begin to imagine how much of a PITA it is for you guys in massive organisations! Anyway, I had to manually redistribute every package in order to weed out the problem we were having but in all honesty I don't really understand what is happening in those distribution folders, how much junk is in there, how much could go, I just keep growing the disks!
The library explorer is not that helpful, you can see 'stuff' but you can't action any of it through that interface - this all needs to be better managed! Not all of us have dedicated SCCM teams, I'm just an admin at a school trying to do my best with what I have.
We just ran in "out of disk space error" in SCCM-ContentLib. By comparing FileLib;PkgLib and DataLib we detected nearly 30GB wasted diskspace in some Folder below FileLib. It would be great to have such a Trigger.
+1 on this suggestion
There is no way for CM Admin to verify hash manually for any particular package or application. One of the reason this will be useful is because if this is happening on WIM file then it is hard to run the quick test as it is part of the OS deployment TS. I tried almost everything (Removing and redistributing package to this Secondary site DP and many other things) but the only thing works is updating the DP which is not ideal specifically for WIM file package which is around 6 GB. In CM07 days, at least we could set the flag in database to resend the package to specific DP but in CM12 that does not seem to work and only solution I found which works is to update the package. This is time consuming for many of the remote DPs with slow link as we don't want to update packages to all DPs whenever we have Hash mismatch issue. Even Hash verification completes successfully but when we tried to use package then it gives the following error and there is no easy way to check manually.
We already confirmed that correct version of the package is on that Secondary site DP. Customer already updated the package last week and it went through the verification without any issues. Package on DataLib and FileLib are correct. We also check and compare the Hash in the database and within INI file on FIleLib and they are also matching. The same WIM works fine on remaining 10 Secondary sites. This happened in the past whenever they updated WIM and it could be any Secondary site DP which runs into this mismatch hash issue which is annoying
I have to say, this is an excellent suggestion. Managing content is a royal pain, to say the least. Even with the tools like the Content Library Explorer, finding and eliminating problems is a terrible experience. A wipe and reset functionality would be a great start for fixing DP woes.