BDD 2.5 Image deployment troubles.

[Guest]

Att: Michael Niehaus

Michael,

I hoping you can give us some valuable advice to help solving our BDD 2.5
implementation woes.

BDD as far as imaging building (config.hta) is great and it has saved a lot
of time for us. Where we are having difficulty is with BDD's OSD deployment,
particularly with managing multiple images for our various PC HALs.

We're at a situation where we have a single OS setup/ configuration, split
into 5 images (different only by HAL) for our fleet of 2200. Our goal is to
rollout WinXP in a staged fashion, group by group (geographic). A typically a
group might be 10-20 users/PC's and probably consists of 3 to 4 PC model /
image variants.

Our challenge is minimizing the number of collections and advertisements
needed to get the OS out. However it seems this is difficult to achieve.
Ideally we would like to have a single Image Package, containing some smart
logic to choose the right image(HAL) for the platform. This we can then
target directly at collections as needed.

My questions are...

1. What is the best way in SMS to target workstations with the correct OSD
image, if we want to rollout to a group of different PC’s?

2. How are other MS BDD customers solving this issue, without the
self-provisioning piece?

3. Is there a way to direct OSD to use a specific image based on PC model
identified? Does OSDInstallWIM.exe accept arguments or can you specify the
wim file in the Customsettings.ini

I look forward to your answers.

Regards
Rob Ardill

(e-mail address removed)

 

[Michael Niehaus [MS]]

On the questions below:

1. We normally recommend creating one package per HAL (since OSD only
supports one image per package). Then, you can create collections to target
the appropriate packages to the appropriate groups of machines. The easiest
way to do this is by the make (manufacturer) and model of the PC, adding a
new collection rule for each combination. One advertisement can then be
used to target to each collection.

2. Using the recommendation above.

3. There is no way to do this via an advertisement, since the advertisement
targets a specific package to the machine - once the advertisement runs,
it's too late to switch packages. (This isn't the case for bare metal
deployments, where you can set the OSDInstallPackage and OSDInstallProgram
variables to direct OSD to install a specific package.) We have seen some
more "creative" workarounds, where all packages are advertised to a machine;
another advertisement can then run a script that decides which "real"
package to execute via the SMS advanced client SDK.

-Michael Niehaus
Systems Design Engineer
(e-mail address removed)
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Michael,

Is it possible to write an exit script attached to the end of the Preinstall
phase to rewrite the value in OSDENV.INI and effectively point OSD to the
rigt Image package? Or Does this break the reporting and later phases?

[OSDEnvironmentBlock]
OSDPACKAGEPATH=
OSDPACKAGEID=
OSDPROGRAMID=

 

[Michael Niehaus [MS]]

I don't know, as I've never tried it. Even if it worked, it wouldn't be
supported.

-Michael Niehaus
Systems Design Engineer
(e-mail address removed)
This posting is provided "AS IS" with no warranties, and confers no rights.

Michael,

Is it possible to write an exit script attached to the end of the
Preinstall
phase to rewrite the value in OSDENV.INI and effectively point OSD to the
rigt Image package? Or Does this break the reporting and later phases?

[OSDEnvironmentBlock]
OSDPACKAGEPATH=
OSDPACKAGEID=
OSDPROGRAMID=

On the questions below:

1. We normally recommend creating one package per HAL (since OSD only
supports one image per package). Then, you can create collections to
target
the appropriate packages to the appropriate groups of machines. The
easiest
way to do this is by the make (manufacturer) and model of the PC, adding
a
new collection rule for each combination. One advertisement can then be
used to target to each collection.

2. Using the recommendation above.

3. There is no way to do this via an advertisement, since the
advertisement
targets a specific package to the machine - once the advertisement runs,
it's too late to switch packages. (This isn't the case for bare metal
deployments, where you can set the OSDInstallPackage and
OSDInstallProgram
variables to direct OSD to install a specific package.) We have seen
some
more "creative" workarounds, where all packages are advertised to a
machine;
another advertisement can then run a script that decides which "real"
package to execute via the SMS advanced client SDK.

-Michael Niehaus
Systems Design Engineer
(e-mail address removed)
This posting is provided "AS IS" with no warranties, and confers no
rights.