Deployment Solution

Hello, all..

I'm slowly but surely starting to lose the will to live with Altiris DS... Just when I think I'm starting to make progress, I get hit with what appears to be a bug that causes me to have to go rethink everything.

The latest bit of fun is this...

We have one DS in our data centre, and multiple package servers in each school. Each package server has a share called ATLSHRE$.

Each package server has images relevant to that particular school.

For imaging, I've written a script which calculates the IP address, and maps drive P: to the relevant package server's share.

So far, I've been doing this on the workstation from which I'm rolling out jobs..

Map P: \\[package server for the school]\altshre$
Run DSConsole
New Job
Distribute Disk image
P:\blah.img

So far, so good. Everything has been working great.

The snag..

I've recently had to configure a job to deploy P:\blah.img, and resize the partition to 32768 (which is significantly smaller than its original size, but still plenty big enough for the data itself).

No problem, say Altiris... Just pick Advanced and set the size... Same as Ghost.

The results..

If I check "Disable image path validation", then I can't see the resize tab in Advanced because it doesn't even attempt to read the image file. Fair enough.

So I leave it unchecked - I've mapped the drive previously when I ran DSConsole.. Go into advanced, make the changes..

Run the job, and it exits with Invalid Disk Image or file not found pretty much immediately.

The official solution appears to be that the source image file has to be on the DS server (drive F) - anything else is a no-go.. Which is completely unacceptable, as it means I have to yoink a 8Gb image across a 10Mb pipe when I have a Gigabyte connection within each building!

There must surely be a way to fix this?! After all, it didn't exactly come cheap.

I digress..

If I run a job with simply F:\rdeploy\dos\rdeploy.exe, and then select it manually to resize to 32768, then it runs absolutely fine.

I'd contemplated using a command line, along the lines of this:

f:\rdeploy\dos\rdeploy.exe -md -f "P:\Images\HardInd\GX260\NTFS\GX260\XPNOSP.IMG " -noprompt -sz1:32768m

but that still doesn't do it, so I'm guessing I've got my syntax wrong?

Also with this command line, doesn't this mean it's running in Unicast? I plan to roll it out to 20+ PCs at the one time, so Unicast is no use...

Oh, and this is in DOS by the way, but the above error happens with PE as well..

I'm sorry if I sound grumpy, or whatnot, but I just want to resize a partition while restoring it... I shouldn't have to jump through any hoops!!

Any advice gratefully received.

Regards,
Gerard

I use 6.8 sp2

I have the Disable image path validation checked and then I use the Additional Parameters option with this information "-sz1:36000m" minus the quote this tell it to only use 36 gigs in the destination.

I also have an image repository pointing to various location depending on what subnet it is on.
hope this helps.

BTW
is your image syspreped? if so are you specifying ExtendOemPartition? if not then no worries.
if so then you need to do some more scripting setting that to disable or removing that line in sysprep.inf

Thanks for getting back to me - it's also good to know I'm not the only one hosting image files on building based servers while the DS lives elsewhere.

I'd already tried your suggestion, but no go.. Sorry - I forgot to include that in my original posting, such was my frothing at the mouth fury!

So I tried a straight copy/paste of your text, in case I'd made a booboo when I last tried it - it'd been one of those days yesterday, so I wasn't discounting anything!!

Still no go - so at least I didn't get that bit wrong yesterday

After getting a colleague to take the crowbar out of my reach before I went all Gordon Freeman on my DS Server, I had a quick swearing session, and gathered the few remaining thoughts that didn't involve brutal violence against our expensive server!

Here's my thoughts..

Source image:
[DELL maintenance partition1]
[40Gb NTFS volume "SYSTEM"]

Target hard drive:
[DELL maintanance partition2]
[80Gb free space]


If I do a straight deploy image, then I end up with
Target hard drive:
[DELL maintanance partition2]
[80Gb NTFS volume "SYSTEM"]

If I use the SZ1 switch, I still get the 80Gb NTFS volume system.

Looking at the "Additional options" under "Advanced" in the GUI (once I'd mapped the drive, and unchecked disable path validation), it quite clearly just shows:

Partition 1 = NTFS (0x05)

Well, I know that's technically not correct because my image has 2 partitions, right? The maintenance one, and then my System one.. That's confirmed if I open the source image file in Image Explorer. And so does my target hard drive, though that shouldn't really matter..

Surely it couldn't be as simple as...

I changed the sz1 to sz2, to specify partition 2.. Which - according to the GUI if you use it - doesn't exist, remember?

I went for a coffee, and to retrieve the crowbar, just in case.. The image deployed. And... It worked!! $DEITY be praised, it actually worked!!

So what gives? Am I just being stupid here? Have all of my thoughts of crowbars and servers finally caused something to break inside my diseased brain? (Frankly, I'd be surprised if the answer was no)

To my mind, the sz switch refers to the SOURCE image's partition number. I'm saying deploy this image, and resize the partition that the resize GUI tells me is partition number 1. Or am I missing something? (It's been a long week!!)..

Ah well, it works, so I can get on with some work and leave the ultraviolence for another day!

Regards,
Gerard

PS.. Sorry for the rambling format of this text - I was watching Dave Gorman's Googlewhack last night!

Erm..

Possibly a shiny new development here..

With the resize switch added, it appears that my images aren't multicasting, but Unicasting, in that they all have different boot times/progress, rather than the obvious synchronised setup you'd expect..

Time is seriously against me today, as I have to get this ICT Suite reimaged for tomorrow morning, so I doubt I will have time to investigate this for a while, since it obviously means blitzing all of the PCs..

Does anyone know if this "add switch breaks multicast" is a known issue? Or if it's possibly something (ELSE!) to do with the DS?


Cheers,
Gerard