First a little disclaimer… you should be backing up your data. If you’re not, stop reading and go work out a backup strategy.

We recently had an issue where our primary SCCM site server failed to boot after updates were applied to it. As it turned out, for whatever reason one of the secondary drives for the VM had been corrupted and we had to detach it from the VM to run a repair on the VHD. This drive happened to contain not only the entirety of our packaging efforts (source files, scripts, etc), but also was the default and only content storage location for our primary site DP role.

What we didn’t know - and what I’m sharing with you today - is now painfully obvious to me but slipped me by at the time. When we detached the drive from the VM and booted SCCM to reattach it and run repairs, the SCCM core components had already started up and didn’t see it’s content storage location. So after we repaired the drive when we expected everything to start working again (namely distributions from the DP) we were surprised when it refused to deliver anything that we didn’t refresh.

Come to find out that one of the things SCCM does when it boots up (or maybe when it goes to do some package validation), is verifies the existence of content libraries - or at least the content library usable drives. Since it didn’t see our “D” drive, it removed the D drive from the available content library drives and moved on to our SQL drive. This is why all of our content could be refreshed and delivered, but existing packages refused to work.

It all sounds so obvious now, but at the time we couldn’t believe that by bringing the drive offline for only a single boot cycle would cause SCCM to forget the drive entirely. So what do you do to resolve it? Run the content library transfer tool provided in the Configuration Manager Toolkit to move any content that may have been stored on the incorrect drive and to modify the registry keys to make your “D” drive available to SCCM again for content.

First you need to download and install the toolkit from here on the distribution point in question: 

https://www.microsoft.com/en-us/download/details.aspx?id=50012 (SCCM 2012/2012r2/15xx/16xx/17xx)

Once it’s downloaded you’ll run the following commands from an elevated command prompt:

cd "c:\Program Files (x86)\ConfigMgr 2012 Toolkit R2\ServerTools"

#XXX is the drive letter of your source, and YYY is the drive letter you're "restoring"
ContentLibraryTransfer.exe -sourceDrive XXX -TargetDrive YYY > c:\CLTResults.log

After the tool is complete, you should be back up and running! Hope this was helpful - if you’ve got other issues shoot me a comment and I’ll do my best to respond - and as always, happy admining!