Greetings!

I am working on retiring a package in our production environment which is updated on all the distribution points. We still have the package contents copied over to the package share and not just in the content library.

So all I did is, updated the package source location with an empty text file and updated content to all DPs and then deleted the package from the console hoping it would remove the folder and its empty.txt file from the package share as well. But it didn't!

Is there a best approach to follow during package retirement process or should I use a PowerShell script to remove the folder from all the DPs?

Please suggest!

That content should be deleted automatically. What version of SCCM are you running? There was a bug in earlier versions where content would not be deleted automatically.

Regardless of the version, check distmgr.log on hour Primary site server and see if the content you're looking for was deleted or not.

What does the monitoring node tell for that package?

I am sorry if I wasn't clear enough.

I did delete the package from the console and its gone from the console. The content status in Monitoring workspace shows nothing when I search using the package id in the content status node.

What does distmgr.log tell you? Does it say it's deleting the file on the DP?

Yes, I did check the distmgr.log and found the package deletion was successful in the DPs.

So distmgr.log indicates that the file was deleted from the content library, but doesn't have any reference to deleting the file from the share? Do you by any chance have the option to "manually copy the content in this package" set on the package properties?

All I could see is "Successfully removed the package XXX00000 from server [Display=\\servername.domain.com\*]......"

This is what I see for all the DPs.

We have the option "Copy the content in this package to a package share on distribution points" checked for all package properties so it puts a copy of the package in the share. I did remove this check mark before deleting the package from the console but that didn't make any difference. (I am not sure if this is what you meant)

My guess is that you have clients that the package share mounted. The files under the package share will be removed by the package folder itself will still be there.

My guess is that you have clients that the package share mounted. The files under the package share will be removed by the package folder itself will still be there.

Sorry Kerwin, I couldn't quite understand it.

Kerwin was asking if the share is being used by clients.

Yes. It's the package share from where the users would manually install the software. This particular package was not deployed via SCCM but was updated in the share for the users to manually pull it.

Sorry for the typo which made my post meaningless.

I meant to say:

The files under the package share will be removed *but* the package folder itself will still be there.

This happens if you have clients that are using the package share and have them mounted.

In Windows, if a folder is in use, you won't be able to delete it.

Can you please clarify a few things?

1. Did the files get deleted from the share?

2. Did the folder get deleted form the share?

If it's just the folder that didn't get deleted, I'm sure Kerwin is right and it's being held open by a client connection. You can close the open file handle or just reboot the DP to make it possible for that folder to be deleted. But is it a problem to have the empty folder there? 

The files within the folder have been deleted but the empty folder itself remains in the share. I am curious to know if all the

I don't know if that is the way the package deletion is supposed to work. But once the package is deleted, our customer recommends all references of that package be deleted from the server share.

It would be good if someone can provide a script or a tool which can be used to remove the empty folder from the share.

Thanks for your replies.

You are using the DP package share outside of its intended purpose. The share is there so that the SCCM client can run the package from the network without having to download it. But it looks like you have users directly mounting and accessing the share. Because of that, the DP cannot delete the package folder.

You need to disconnect those users so that you can delete the package folder.

It seems this link will help you with Automation 

http://eskonr.com/2014/02/configmgr-2012-updated-powershell-script-add-packages-applications-drivers-to-distribution-point/

It's actually been a while ever since I deleted the package and this application is not a widely used one.

I did logon to a few production servers randomly and saw this file or folder was not in use. Moreover, all our production servers have been restarted after the patching activity was done for July month. But I still could see the folders in the share.

Once I make sure the file/folder is not used, should I do anything to remove the folders from the share?

The DP will only try once to delete the package folder. If it fails, then its up to you delete it.

To sum up: 

• The empty folders should not hurt anything
• SCCM seems to be functioning as expected in your environment
• If they were not deleted on the first pass SCCM will not delete them again automatically
• If they really bug you, you can delete the manually or script the deletion (but I suggest leaving them alone)

I am personally not concerned if the folder exists in the share :) but my customer is...

I can't manually delete the folder on all 200 DPs and there has to be a way to use a script that can help do this job easier which is why I requested if anyone could provide a script which you would have used.

Yes, I know this is an old post, but Im trying to clean them up. Did you solve this problem, if so what was the solution?

Since no one has answer this post, I recommend opening  a support case with Microsoft Customer Support Services (CSS) as they can work with you to solve this problem.