Prior to my starting at my current company some secondary site servers were setup and NO_SMS_ON_DRIVE.SMS was not placed on the C: drive.  After some time the D (intended) volume filled up and SCCM began using the C drive for packages.  I've since created the NO_SMS_ON_DRIVE.SMS file on the root of C: to prevent any other packages going there.  But, what happens with the existing content that is on there?  My current understanding is that SCCM will not add any additional content to that drive, but it will still continue to access the content that had previously made it there without issue.

I'd like to get this data off of the C drive and over to the D drive where it should be (at least in our environment).  What would be the "clean up" process to do this properly?  My guess with that is I'd just manually move the folders over and then run some SQL update to point to the new spot, but I figured that I would ask around first since I'm unsure.

Thank you

Try this,

http://blogs.technet.com/b/smsandmom/archive/2008/09/04/moving-the-smspkgc-share-to-a-different-drive.aspx

Try this,

http://blogs.technet.com/b/smsandmom/archive/2008/09/04/moving-the-smspkgc-share-to-a-different-drive.aspx

I've seen that one before.  You are correct, that would work, but seems like more of a workaround.  Then we're left with a SMSPKGC$ and SMSPKGD$ which doesn't seem very clean.  For the PKG share I'd prefer to get everything under SMSPKGD$ (if possible). 

I'm also assuming another way to achieve this is to make a copy of the *.PKG file in D:\SMSPKG , remove the package from the DP in the console (which would remove the files from C:\SMSPKGC$), put the *.PKG file back in D:\SMSPKG, run the pre-stage package command, and then let it expand back out into SMSPKGD$.

That process you linked may work for some other shares however.  For example, some packages that were distributed have the "Share the distribution folder" setting enabled which put their share folder on C:.  For those I could follow that process and they would look no different from if they were originally transferred to the D drive since the drive letter isn't in the share name.

Hi,

NO_SMS_ON_DRIVE won't work on the drive you actually installed ConfigMgr on.

You may see the similar issue on the following link:

NO_SMS_ON_DRIVE not working as intended?

Regards,

Sabrina

Hi,

NO_SMS_ON_DRIVE won't work on the drive you actually installed ConfigMgr on.

You may see the similar issue on the following link:

NO_SMS_ON_DRIVE not working as intended?

Regards,

Sabrina

Yep, I know that part.  SCCM is installed on D: and i'm not placing the file there.  Just trying to get the few items that made it onto the C: drive back over to D:

Any other thoughts on moving to another drive?

Also, I'm still trying to figure out how NO_SMS_ON_DRIVE.SMS works exactly.  I.E. what happens if the following is true:

1) NO_SMS_ON_DRIVE.SMS is not on a drive initially

2) SCCM is not installed on that drive, but is on another drive

3) distmgr determines this is the best drive on the distribution point, creates an SMSPKG<DriveLetter>$ share and places content there.

4) NO_SMS_ON_DRIVE.SMS is added to that drive.

I understand that no further content will go there, because distmgr will ignore the drive.  But do the packages that are already on that drive still work just fine when clients request the package?  And what happens if the package is updated or refreshed.  Does distmgr see that the content already exists on the server, but since the NO_SMS_ON_DRIVE.SMS file is there now look for a new drive and begin placing the updated content there (and leave the old content as an orphan never to be cleaned out)?

I may have to set up a test if nobody knows, but it would be helpful if someone understands this process better than I and knows.