Hi everybody,

One of my customer wants to have an emergecy procedure to stop copying one or various SMS Packages from the SMS Site Server to one or various SMS Distribution point in order to lower the network load.

I've made some research about this functionality and find only one possibility which is the use of STOPJOB.exe utility.

Does someone knows this tool ? Do you kown where I can find it ?

Do you know an other way to respond to my needs ?

Thanks for your help.

Regards

stobjob.exe was designed for SMS 2.0 (I am not sure, but I guess it was part of the backoffice resource kit (BORK)). I am not aware of a SCCM version.

There is not a supported version of that tool for Configuration Manager. The only way I know of to stop a distribution in progress is to stop Distribution Manager.

The best way to control this before distribution is to ensure that you do not have too many threads enabled for Distribution Manager - the default is 5 per package - so we try to distribute to 5 DPs simultaneously. You can set that on the Distribution Points tab of the Software Distribution component in Component Configuration.

Thanks for this enlightened answer, Wally. I knew that you were the right man for this question.

Thanks a lot and have a nice day.

Hello:

Just a quick question. When you stop the distribution manager and restart it, does the distribution job continue from where it left off?
Do you need to delete the job in someway to ensure that the distribution does not restart?

Also, to clean up the package distribution, do you need to delete the package deployment to that site through the console?

Thanks again folks.

Rgds,

Sean

Hello:

Just a quick question.  When you stop the distribution manager and restart it, does the distribution job continue from where it left off?
Do you need to delete the job in someway to ensure that the distribution does not restart?

Also, to clean up the package distribution, do you need to delete the package deployment to that site through the console?

Thanks again folks.

Rgds,

Sean

The distribution does continue where it left off.

Wally or anybody else, do you know how to cancel the distribution of a package?

In my case, I added a dp to a package, then I decided not to distribute it there so I removed the dp from the package.  However, it wants to continue distributing the package to the dp and then it will remove it.  It's a 5GB OSD package going across the WAN and will take about 10 hours.

Thanks,

Tom

 

 

We have come across the same situation lot of times where we had to stop pushing the package to a DP. We used to modify the name of the source directory, it works. However, the side effect is, none of the DPs can get the package. I just wanted to share my experience, I hope this helps.

We used to modify the name of the source directory, it works. However, the side effect is, none of the DPs can get the package. I just wanted to share my experience, I hope this helps.

That doesn't help in every situation (especially when distributing packages to child sites and compressed package sources come into play).

@Tom: you could modify the share permissions of the targetted DP so that distmgr is not able to copy the files on the DP. Plus modify the retry settings (Component configuration -> software distribution) so that ConfigMgr will give up after X retries ( http://support.microsoft.com/kb/978021/en-us needed if you're on SP2)

There's really not a good way to do this. There's no big red stop button in SMS/SCCM. It's best to make sure you know what you are doing and what the ramifications of your actions will be.

I set all of my senders to only send medium and high priority traffic from 7a-7p and I set all my packages to low. This effectively stops all packages from being sent during the day. It's a safe guard and it seems to help.

 

 

 

Always nice to be perfect, but sometimes mistakes happen.  Sure would be handy to have a stopjob.exe type of tool available.  Especially when you are talking about multiple gig OS install packages these days.  You add a package to a distribution point and then decide, oh wait, I don't need it there, and delete it, it will copy the whole thing down and then remove it.  This isn't so bad locally, but when you have a slow WAN connection this process can take all day, and in the meantime, it just sucks bandwidth.

Even if this isn't happening during normal business hours, it's a pain if you are trying to get other packages out to said DP...

Is there a way to do this on the database?  I doubt I'll be given access to the SQL server, but if I have something I can give our DBA I might be able to have them stop such for me.

Lee,

What is it you're trying to stop?

 

 

John,

In my case, we had a bunch of driver packages (around 28, some XP x86, some Win7 x64) deployed to 7 DP's out of 34 - I was hired on to get OSD working and my proof of comcept WAS working well...  I update the "Thick" image every month and this time the image is not making it to the DP's.

I was told to deploy them to all the DP's and I responded with - there is not enough space on half of the DP's. I was told to deploy them anyway, and that someone else would work through the space issues... Also, in the middle of all this we went from a single site server to a central and 2 primaries and the old central is now a primary site server instead of the central... Package ID's can be confusing now because ABC00001 might be on the new central or the old central (have to look for the padlock).

...deleting some of my complaints... except...  I'm tired of waiting for others to figure this out and fix it (been over 2 weeks).

I changed the retrys to 1 which seems to have helped. I also removed all but 7 of the driver packages (looks like that was a mistake). Right now most threads are being taken up removing driver packages, but the errors seem to have gone away and it looks like it is making progress now.

Any guidance would be greatly appreciated!

Thanks,
Lee

• Edited by Stephen Lee Parker Tuesday, October 04, 2011 8:26 PM

John,

In my case, we had a bunch of driver packages (around 28, some XP x86, some Win7 x64) deployed to 7 DP's out of 34 - I was hired on to get OSD working and my proof of comcept WAS working well...  I update the "Thick" image every month and this time the image is not making it to the DP's.

I was told to deploy them to all the DP's and I responded with - there is not enough space on half of the DP's. I was told to deploy them anyway, and that someone else would work through the space issues... Also, in the middle of all this we went from a single site server to a central and 2 primaries and the old central is now a primary site server instead of the central... Package ID's can be confusing now because ABC00001 might be on the new central or the old central (have to look for the padlock).

...deleting some of my complaints... except...  I'm tired of waiting for others to figure this out and fix it (been over 2 weeks).

I changed the retrys to 1 which seems to have helped. I also removed all but 7 of the driver packages (looks like that was a mistake). Right now most threads are being taken up removing driver packages, but the errors seem to have gone away and it looks like it is making progress now.

Any guidance would be greatly appreciated!

Thanks,
Lee

• Edited by Stephen Lee Parker Tuesday, October 04, 2011 8:26 PM

I'm assuming when you say DP you really mean DP and not secondary site? If so, you are basically hosed. This is one of the many reasons I do not use stand-alone DP's. If these are (or were) secondary sites you'd have a couple options. You could delete the sender address to the site, create a new sender address with a fake server name that is actually in the same data center as the sending server, let the send "complete" then fix the address or you could use the preinst.exe tool to delete the jobs. Stand alone DP's do simple SMTP copies, once it's started stopping it is nearly impossible. You can go back and remove it from those DP's but I don't even know if that will stop it. You could call CSS and see if they can help, they may be able to work some magic in the database to stop it.

Sounds like the entire hierarchy could use some TLC. :-)

Thanks...  Looks like it finally caught up about 15 minutes ago...  There are no secondary sites and no proxy management points...  My manager is getting a "health check" done, so maybe things will get better before long.

I know this thread is old but it is still a relevant question and I've found a fix that works for me on SCCM 2012 R2.  I was distributing a software update package and wanted to stop it.

• Open the sender.log in cmtrace so that you see the package being distributed.
• Either delete the package or remove just the distribution point on which you're trying to stop the job.
• Run sccminstalllocation\bin\X64\00000409\preinst.exe /deljob sitecode to kill the job. This will kill all targeted jobs to the site so be careful if you may have other jobs running.
• Using Cfg Mgr Service Manager, stop the SMS_LAN_SENDER and start it again
• You'll see in the sender.log that distribution has stopped.