Well we had an issue where the Package share was fine, but the pkgsrg folder was on a drive that was trying to be all things to all men, and started filling up when we started sending packages down to the secondary sites.  Even though there had been the NO_SMS_ON_DRIVE.SMS file placed on the drives, and the actual package share was correctly configured, SCCM was still sending the compressed packages to this drive.  Unfortunately these Secondary site servers also provided print, domain controller, SQL, and Backups as well as having the Windows page file on this exact drive, so as can be expected, people were less than happy, and it was one of the few times where there was a system issue that was caused by SCCM.

The fix was very straightforward.

Firstly In each site, open Computer Configuration, and change the software deployment settings to point at the drive you want to. (Note the drive has to be specified complete with colon and slash e.g. C:\, D:\)

Check the site messages – you should see one for SMS_SITE_CONTROL_Manager submitted a copy nnnn of the actual site control file .

Test with a small deployment package.

Doing this not only means that new packages will use the specified drive, when older packages have their DP’s  updated they will now have their compressed files moved to the new drive, so be careful when updating large older packages across slow links.

Depending on the number of secondaries / packages you could update the DP’s on all the packages, and let SCCM move them, then delete the contents of the old PKGSRC folder.  That all depends on how practical it is in the particular environment.

Note this is from my own experience, and is in no way guaranteed.