Deployment and Imaging Group

Hello! 

I have a doubt about Symantec Deployment Solution.

We can create a job for thousands machines and run as a task, Is that correct?
So, how many such tasks can run simultaneously? 
I heard that only three tasks  are recommended... but I guess that number is too little for such a robust tool such as Symantec Deployment Solution 7.1

You should be able to send a task to as many computers you want, but it really depend on the tasks also, if it is an image deploy, the NS will unicast to a random computer (which will be set as a master) and wait for the other computers to be ready before start to multicast the image to the others computers. Under the image task > Advanced > Multicasting there is a timeout option, which is how long the “master” computer will wait until start the image.

In our environment we image between 20 to 80 computers at the time, if there is more normally we set the jobs 30 to 45min apart.

Now if is just a WoL task, I had send to 2000 computers before and that work fine, since the task will get send once the client talk back to the task server.

If you are doing Software deployment, you might want be careful with bandwidth limitation, if the software packages are too big. We had a problem with a Software Deploy job that have around 15 software packages inside and some of the packages were between 4G to 15G, so we had to limit to 10 to 20 computer at the time (he have multicast disable for packages).

So base on bandwidth and CPU utilization, these are the numbers we current try to use:

• Boot into PXE – up to 20 wks
• Image and Driver injection -  up to 80 wks
• Software Deploy (depend on size) – large apps ( up to 20), small apps (up to 50)
• Regular tasks, like: WoL, agent reset, restart – up to 2000 wks

I hope this help.

Thanks for answering ortolani. Helped me a lot. 

But then, is there a limitation for different tasks running at the same time?

For example, in a deploy:
I want to send various applications for about 5000 computers.  Each application will be in a separate task. Following the best practices, how many tasks at most I can start simultaneously?

thanks again.

THAT is an interesting question that takes a bit more study on your port.

First, a JOB is a single task execution to the NS.  200 tasks in a job - one execution.  Why?  Because the entire JOB is sent to the assigned Task Server, and the Object Host service actually manages the tasks within the job, NOT the SMP.

A similar principle applies to deployments by the way.  They are not all sent out from the SMP, but from each site server instead, so it scales a bit better than initial indicated here.

CAN the NS get all tied up in tasks?  Yeah, but generally it doesn't unless you set some tasks up to not expire and.or they simply continue to run into perpetuity for whatever insane reason.  It scales remarkably well IF you have your Task Servers set up per recomendation (no more than 5K clients per TS).  Frankly, you'd probably have a harder time scheduling the jobs than the SMP would have kicking them off.  OH, and of course your DB had better be able to handle the traffic.

All that said...

Don't use Tasks for software deployments if you can avoid it.  It's dumb.  Use managed delivery policies.  If you do, the rollout is more reliable, easier to track, self healing, and literally scaled to any level, ONLY limited by your bandwidth.  FAR better methodology.

 

PS>  Remember that the test results above are for that environment.  When in support, I saw a wide range of results - that one is in the middle.  For instance, I had some customers swear that they could unicast to 50 systems simultaneously and it was faster than a multicast.  I had others say that over 7 and the network would go down.  Go figure.  Eash place was different, so YOU will have to do some testing.

I would agree that software deployment using delivery policies is a prefered method, the tracking was horrible in 7.1.  I will have to test it under 7.5.  We use delivery policy for large scale deployment and still have jobs and tasks to do single or "smaller" groups.

Interesting question as I have some trouble here When I run a job with several sub jobs on up to 50 clients starting with a WinPe boot, SOI and then a lot of jobs with quick deliveries, it happens from time to time on a client that some sub jobs (e.g. 1and 2) start again running containing tasks parallel - task 1a, 2a, 1b, 2b, 1c, 2c and so on... 90 percent is ok, but these are totally out of control.....

The only time I've seen something "like" this is when the Object Host service is restarted.  There are ways to prevent that kind of behavior, but my biggest recommendation is not doing so much daisy-chaining in Tasks. The Task specialists at Symantec may differ with this, but I've seen "odd" results from large chains for years.  We cleaned it up a LOT while I was there, but completely?  Pretty sure not.  This is why again, we recommend SWD over Tasks for much of the work.  There are simply better ways.  You can daisy chain SWD policies as well - tie together a bunch of packages that would all get distributed in a bundle.  Maybe not QUITE as fast as tasks, but...  I dunno.  I think it would be worth researching.

Yeah, I know :-S Sometimes customers are not very "open minded"... Thank's JT.

Ahhhh - customer.  Good point.  Hmmm...  Well, then my suggestion is to document clearly your concerns in writing so they can't come back to you if they don't like the results.  GL!

It seems Rollup Pack V9 solved my troubles with the task jobs. I was able to run 20 clients in one schedule. No hopping :-)