mackerelq

Peter, thank you for your input. According to the documentation I have read, the "NO_SMS_ON_DRIVE.SMS" file only does its "magic" before the distribution point is established or before a drive receives any packages on it. The issues I experienced were experienced before I created that file. What I ended up doing is removing the reference to that DP from all packages, then removing and reinstalling the Distribution Point role. As the drive "D:" was no longer the official drive that the distribution point was using, it did not remove the package or signature files from the original drive "D:", only the ones on "F:". I did have to manually remove the SMSSIG$ share as it was still pointing to "F:" (which involved me having to re-create the directory as the share was "orphaned"). Once I started reassigning packages to that DP, the files that were already on the "D:" drive seemed to do what a package "refresh" does- which seems to be a shorter process (maybe I'm wrong). The packages that were on drive "F:" had to be re-copied to the DP through the distribution manager process. It all happened overnight, so I came in this morning to a happy and fully functioning Distribution Point. And now that I have the magic "NO_SMS_ON_DRIVE.SMS" file on drive "F:", SCCM is behaving itself and only using drive "D:" for the packages.

I appreciate, at this point, all 74 people who have viewed this post. Would have hoped for even just a morsel of advice after that many people looking at this. I suppose I will try removing the association to any packages that are on drive "F:" and keep the packages on drive "D:" then remove and re-add the distribution point role in the hopes that it will just re-use the existing packages. ...not holding my breath. If anyone has any sage advice regarding this, I would definitely not discourage you from posting.

Recently a new drive was installed on my remote SCCM 2007 distribution point. This new drive (F:) was larger and had more space on it than my previous drive designated to be used for my packages (D:). After distributing and updating a few packages, I realized (too late) that these files were being copied to drive "F:". I tried to reverse this process by creating a "NO_SMS_ON_DRIVE.SMS" file on drive "F:", but apparently this is not how this works. I now have these issues: The SMSPKGD$ share no longer exists In the database packages that have not been added or updated since the new drive was added still point to SMSPKGD$ for this DP and now do not work Packages that existed before the new drive was added that have been updated since the new drive installation now have package files on both "D:" and "F:" and will not install on clients properly. I believe this is because the SMSSIG$ directory on the original drive "D:" still holds the package signatures for these packages and there is not a matching package signature in the new SMSSIG$ directory on "F:". I would like to be able to do the following (if possible): Change the drive that SCCM uses on this distribution point server from "F:" to "D:" Prevent the "F:" drive from being used for SCCM packages Copy the packages and signatures from "F:" back to "D:" Update the database pointers for these packages on this DP to "SMSPKGD$" instead of "SMSPKGF$" Perform these steps without having to purge the files from this DP. I believe this last point is the biggest sticking point as this DP is remote and it would take a large amount of bandwidth and time to re-copy these packages back to this DP. It also seems silly to have to remove and re-copy files over the WAN that are already on that server to begin with. Any guidance or assistance that leads me to be able to fix this "in-place" would be a godsend and a huge time saver.