XP Pro rollout on multiple hardware platforms

[Guest]

Hello,

I've just started a new contract working on an XP rollout for a client. They
have about 100 PC's to upgrade from Win98 to XP Pro and told me they had
developed a standard image and just needed assistance in planning the
deployment and the physical rollout itself.

It now transpires that they have about 20 different models of unbadged
desktops and half a dozen different laptops. They were planning to lay the
same ghost image on each machine and then add extra drivers, copy the hal.dll
etc to get them to work.

Now, I've been involved in about a dozen large corporate rollouts and have
never come across this type of approach. I usually deploy a seperate image
for each model of hardware, and in a medium/large business environment they
tend to buy desktops in bulk (100's to 1000's at a time). This makes an OS
upgrade easier as there is a common platform.

What is going to be the most stable way to deploy a build in this case?

My initial feeling is that there isn't going to be one image as the client
thinks, but dozens - it's going to be down dictated by common motherboard
chipset and CPU etc.

I have a feeling they are up against it here, however it means that my
contract may run longer than I thought.

Any thought or ideas please.

PS - the client is a registered charity, and the option of a complete
hardware refresh is not an option.

Thanks,

Andy

 

[Tigerliu]

hi,All:
I learned that Windows XP 64bit version supports EFI bios.
I have a Windows XP 64bit version installation disc, but it does not
support efi bios.
I want to know whether there are another XP 64bit ver installation disc
for EFI bios.

 

[Guest]

Hello,

What I see as the biggest problem here are drivers. Gathering all the
drivers and putting them in a common area on the hard drive (ie c:\drivers)
is what I see as a major issue. Also, replacing all the hal.dll files will
NOT work after you image a system.

Include this in your sysprep.inf file...

;SetupMgrTag
[Unattended]
OemSkipEula=Yes
DriverSigningPolicy=Ignore
Autoactivate=yes
OemPnPDriversPath=
UpdateUPHAL=Yes
UpdateUPHAL=ACPIPIC_UP,C:\WINDOWS\Inf\Hal.inf
UpdateUPHAL=ACPIAPIC_UP,C:\WINDOWS\Inf\Hal.inf
UpdateUPHAL=MPS_UP,C:\WINDOWS\Inf\Hal.inf

Even if you have an Intel Chipset or AMD Chipset, it works. Also, you may
have to get involved with the team who built the image as to see the common
area where they put the drivers. For every system I have (we have appox. 4
different manufacturers of desktops/laptops at my job), I have ONE common
drivers folder and I reflect that in the Sysprep.inf to where that location
is; and every time we get a new system, I update the drivers folder and copy
into our Master Image.

Hope this helps.

 

[Guest]

Have you had any problems using 1 master image when going between different
chipsets?
I am currently in an environment with 3 generations of IBM laptops and
desktops. Currently using sysprep and Ghost for imaging. What are you using
to deploy your images?

Hello,

What I see as the biggest problem here are drivers. Gathering all the
drivers and putting them in a common area on the hard drive (ie c:\drivers)
is what I see as a major issue. Also, replacing all the hal.dll files will
NOT work after you image a system.

Include this in your sysprep.inf file...

;SetupMgrTag
[Unattended]
OemSkipEula=Yes
DriverSigningPolicy=Ignore
Autoactivate=yes
OemPnPDriversPath=
UpdateUPHAL=Yes
UpdateUPHAL=ACPIPIC_UP,C:\WINDOWS\Inf\Hal.inf
UpdateUPHAL=ACPIAPIC_UP,C:\WINDOWS\Inf\Hal.inf
UpdateUPHAL=MPS_UP,C:\WINDOWS\Inf\Hal.inf

Even if you have an Intel Chipset or AMD Chipset, it works. Also, you may
have to get involved with the team who built the image as to see the common
area where they put the drivers. For every system I have (we have appox. 4
different manufacturers of desktops/laptops at my job), I have ONE common
drivers folder and I reflect that in the Sysprep.inf to where that location
is; and every time we get a new system, I update the drivers folder and copy
into our Master Image.

Hope this helps.

Hello,

I've just started a new contract working on an XP rollout for a client. They
have about 100 PC's to upgrade from Win98 to XP Pro and told me they had
developed a standard image and just needed assistance in planning the
deployment and the physical rollout itself.

It now transpires that they have about 20 different models of unbadged
desktops and half a dozen different laptops. They were planning to lay the
same ghost image on each machine and then add extra drivers, copy the hal.dll
etc to get them to work.

Now, I've been involved in about a dozen large corporate rollouts and have
never come across this type of approach. I usually deploy a seperate image
for each model of hardware, and in a medium/large business environment they
tend to buy desktops in bulk (100's to 1000's at a time). This makes an OS
upgrade easier as there is a common platform.

What is going to be the most stable way to deploy a build in this case?

My initial feeling is that there isn't going to be one image as the client
thinks, but dozens - it's going to be down dictated by common motherboard
chipset and CPU etc.

I have a feeling they are up against it here, however it means that my
contract may run longer than I thought.

Any thought or ideas please.

PS - the client is a registered charity, and the option of a complete
hardware refresh is not an option.

Thanks,

Andy

 

[Guest]

I have had no issues going between different chipsets. I am using Ghost 8 as
well.

Have you had any problems using 1 master image when going between different
chipsets?
I am currently in an environment with 3 generations of IBM laptops and
desktops. Currently using sysprep and Ghost for imaging. What are you using
to deploy your images?

Hello,

What I see as the biggest problem here are drivers. Gathering all the
drivers and putting them in a common area on the hard drive (ie c:\drivers)
is what I see as a major issue. Also, replacing all the hal.dll files will
NOT work after you image a system.

Include this in your sysprep.inf file...

;SetupMgrTag
[Unattended]
OemSkipEula=Yes
DriverSigningPolicy=Ignore
Autoactivate=yes
OemPnPDriversPath=
UpdateUPHAL=Yes
UpdateUPHAL=ACPIPIC_UP,C:\WINDOWS\Inf\Hal.inf
UpdateUPHAL=ACPIAPIC_UP,C:\WINDOWS\Inf\Hal.inf
UpdateUPHAL=MPS_UP,C:\WINDOWS\Inf\Hal.inf

Even if you have an Intel Chipset or AMD Chipset, it works. Also, you may
have to get involved with the team who built the image as to see the common
area where they put the drivers. For every system I have (we have appox. 4
different manufacturers of desktops/laptops at my job), I have ONE common
drivers folder and I reflect that in the Sysprep.inf to where that location
is; and every time we get a new system, I update the drivers folder and copy
into our Master Image.

Hope this helps.

Hello,

I've just started a new contract working on an XP rollout for a client. They
have about 100 PC's to upgrade from Win98 to XP Pro and told me they had
developed a standard image and just needed assistance in planning the
deployment and the physical rollout itself.

It now transpires that they have about 20 different models of unbadged
desktops and half a dozen different laptops. They were planning to lay the
same ghost image on each machine and then add extra drivers, copy the hal.dll
etc to get them to work.

Now, I've been involved in about a dozen large corporate rollouts and have
never come across this type of approach. I usually deploy a seperate image
for each model of hardware, and in a medium/large business environment they
tend to buy desktops in bulk (100's to 1000's at a time). This makes an OS
upgrade easier as there is a common platform.

What is going to be the most stable way to deploy a build in this case?

My initial feeling is that there isn't going to be one image as the client
thinks, but dozens - it's going to be down dictated by common motherboard
chipset and CPU etc.

I have a feeling they are up against it here, however it means that my
contract may run longer than I thought.

Any thought or ideas please.

PS - the client is a registered charity, and the option of a complete
hardware refresh is not an option.

Thanks,

Andy