Deployment Solution

Hi folks,

So I'm having a little trouble with image restore, but only if I schedule the same image restore task on multiple systems at the same time. I have 3 servers, and 10 client machines, and they all have a "clean" image in their automation partition.

If I schedule my "clean" image restoration task on a single server, it takes 3 minutes to do the restore (copying data at around 330MB/s), and then a few minutes to configure the OS.

However, if I schedule the same task on 2 servers, the data transfer speed reduces to 4MB/s on each of them.

I only found this out when I scheduled the "clean" image restore on all 13 systems. It resulted in my servers (which run 2008 R2) having Windows 7 on them, and they didn't boot due to BCD issues.

Am I doing something horribly wrong, or just completely misunderstanding the concept of scheduling image tasks?

Thanks for any help!

Tim

To answer my own question, it looks like multicast is being automagically used. To get around this, I'm looking at running the rdeploy command manually in a script for the job. This should work, right?

Thanks,

Tim

Even better:

Start ---> Programs ---> Altiris --->  Deployment solution ---> Configuration ---> Options

Under "Transport", disable multicast support.

Under "Disk Imaging", set to 0 clients to disable multicast.

Hope this helps someone!

Tim

There are three solutions to this problem, each with their advantages/disadvantages.

1. Use a script to deploy the image
   The is the easiest (I think). When you use an script to deploy your image files, you bypass the deployment engine's native multicast functionality which can be invoked when multiple clients are scheduled to be image simultaneously.
    
2. Use Unique Filenames
   When you save images to the local automation partition,  if you use the DS unique ID token to create the image (so a filename of  %ID%.img) then every image will be unique and multicast will not be invoked. This method works best when you are delivering an image to a machine, boot into production, and then run the job to save the image to the local image store.
   
   
   
    
3. Disable Multicast
   As you've seen, this also works as it gets to the fundamental root of the problem at  a low level by disabling this functionality all together. Problem with this approach though is that if you ever want to leverage multicast in the future, you can't.

I always advise altiris admins to go for options 1 or 2 above, as multicast does have it's uses and you want to leave that capability open to you in the future where possible.

Kind Regards
Ian./

Hi Ian,

Many thanks for the info! It now makes an awful lot more sense why you'd want to create images with the machine ID in the file path!

In my case, I didn't really want to spend the time on the scripted approach. I wasn't sure if the pre/post configuration steps would occur, or if I'd have to do that myself (e.g. joining domain). And because our environment is very self-contained (it's a small research lab), it's quite clear that we won't be needing multicast. And being able to specify a single image name without embedded macros does seem like an easier concept for our end users to grasp :)

Cheers!

Tim

Hi Tim,

Just for completeness, here is a screen grab of an example script to deploy of a local partition,