Build a Corporate SOE in 5weeks - Advice.

[molman]

Ok, lets say your in a senario where you need to have a deployable corporate SOE (Standard Operating Environment), and you only have 5weeks.

The SOE has to be deployable on 11-14lines of different hardware.

You have no available application deployment infrustructure (RE: SMS etc..).

The SOE needs the usual: WinXP+Patches, MS Office+Patches, PDF Reader, AV Software, Java, Citrix Client, Flash, Quicktime.. etc..

The SOE will then need to be deployed on 55 (in use) machines in a proceeding 4week period... more later.

Please rule out external help, design, etc.. at this stage.

How would you approach this senario? (Helpful comments only please)

[mmarable]

Spend a couple of days building a DVD that autoinstalls everything. Take the next 4 weeks off for vacation.

You're pretty well painted into a corner with this one. You have no enterprise deployment like SMS or RIS, so you're left with disk based installs.

You have 14 or so different hardware platforms, so using Ghost or some other imaging method would prove to be too difficult for the time frame you're looking for.

If you're open to developing an enterprise deployment process, you could use the Business Desktop Deployment system from Microsoft, but that is going to rely on WinPE so if you don't have that you're out of luck.

Do you have access to a server, or even a workstation that you could use to serve out the binaries to install over the network? You could use BartPE to boot the workstations and then install over the network.

[IcemanND]

If your 11-14 models all have compatible HALs you could do a ghost image, but you would need to know what HAL is on each of the models you are deploying to.

If you can convince the powers to be to spend some money you can get the Universal Image Utility from Binary Research and then the HAL issue is dead, and they provide a driver database with the program so you normally don't have to find all the drivers for the machine either.

[CoffeeFiend]

I don't even see what you're worried about. 55 PCs only? Over 4 weeks (20 work days), that's not even 3 PCs/day. One person could manage that installing everything manually (non-unattended).

Make basic unattended setups (optional) to install from. Then sysprep, ghost, and use that image for the other PCs (much like IcemanND said). I don't ever recall having a single HAL issue over the years (the most likely part would be mass storage adapters and such). Pack the necessary drivers somewhere (right in the ghost image perhaps so it ends up on the HD), let it detect new hardware and you're done. It only takes a few minutes to restore the ghost image (depending on size of image mainly) and detect drivers.

Assuming there isn't anything to keep on the PC's HDs, one guy could come in on the odd saturday or sunday (when no one's there) and do them all the same day by himself... (roughly 10 minutes/PC for a full day - not bad; worst case scenario a slightly longer day)

[IcemanND]

the HAL issues tend to come up if you build you image on a new machine and try deploying to the older machines. It can also crop up if you build it on a really old machine that has a non acpi hal and put it on saya dual core machine it will not use the dual core, only a single core.

The mass storage drivers can be easily taken care of with sysprep, the incompatible HALs are the b iggest headache.

[CoffeeFiend]

the HAL issues tend to come up if you build you image on a new machine and try deploying to the older machines. It can also crop up if you build it on a really old machine that has a non acpi hal and put it on saya dual core machine it will not use the dual core, only a single core.

The mass storage drivers can be easily taken care of with sysprep, the incompatible HALs are the b iggest headache.

That's mostly my point. We don't keep ancient hardware around. Normal ACPI HAL always worked for every PC I've ghosted (hundreds of them - haven't seen non-ACPI compliant hardware in many years; and most businesses don't have or need fancy super-fast CPUs on desktops). As for Mass Storage Adapters, no, sysprep won't always reliably make a normal "plain IDE" install work on a SATA RAID/SCSI setup or such (you'll get Stop 0x7b Inaccessible Boot Device; in theory it should work, but in practice it often won't)

[Noise]

Spend the first week or two developing the server infrastructure. For this environment I use two servers. One for Active Directory / DHCP / DDNS; the other for WSUS and Group Policy application deployment (and redundant Active Directory).

Forget Ghosting - that's a stupid way of deployment. Create an unattended Windows XP installation CDROM. You will probably have to use different versions of Windows XP Pro (OEM, VLP, Retail) depending on the current installed license base. If any PC are running XP Home, you will have to upgrade them. If you're lucky you can get a VLP license for the whole lot of them and make your deployment much easier.

The installation CDROM should install Windows XP Pro with SP2 and all current Critical Hotfixes integrated. Don't use nLite for this, I recommend you do it manually - but HFSLIP is another option. If all your PC's have a floppy disk drive you can load the the winnt.sif file from the floppy disk while the CDROM is booting. This is how I do it and it makes it very easy. You can also use RIS for OS deployment, but I think the CDROM/Floppy method is easier and faster.

Then use Group Policies to deploy your applications. Use the WSUS server to keep all your clients updated with the lastest Windows and Office hotfixes.

[IcemanND]

@crahak - I agree I wouldn't want to see xp on a non-acpi box, but I have. And if I had a HT/Dual core processor I would want to be using what I paid for. You won't with a standard acpi hal. Also some drivers will not install correctly with the wrong HAL on the machine. As far as the massstoragedrivers section of sysprep, I have never had a problem with it, not to say that it does not fail but I have moved systems from PATA to SATA to SCSI and back without and issue accross multiple manufacturers. I've even uses the driverpack from bashrat to do it and not had problems.

@ nois3 - ghost is not a "stupid way of deployment" if done correctly it can be a very effective way of deploying multiple machines, even accross multiple hardware platforms. Try installing 18gb of software along with the os and patches to 45 machines in an hour . You can't do it without a product like ghost. SMS and RIS won't even get it done that fast.

If I was doing this particular deployment Iwould likely look at doing unattended installs. But it would all depend upon what the 11-14 system models are.

I've setup and installed 50 machines in a week from scratch, it just depends upon the amount of work you want to do and when. And it also depends upon what you want when finished and you have to replace a failed hard drive in a system when it's in use by someone and how long you feel you can make them wait.

[bluescreens]

Ok, lets say your in a senario where you need to have a deployable corporate SOE (Standard Operating Environment), and you only have 5weeks.

The SOE has to be deployable on 11-14lines of different hardware.

You have no available application deployment infrustructure (RE: SMS etc..).

The SOE needs the usual: WinXP+Patches, MS Office+Patches, PDF Reader, AV Software, Java, Citrix Client, Flash, Quicktime.. etc..

The SOE will then need to be deployed on 55 (in use) machines in a proceeding 4week period... more later.

Please rule out external help, design, etc.. at this stage.

How would you approach this senario? (Helpful comments only please)

1. On your 2003 servers (you DO have 2003 servers, right?) add the RIS service.

2. Add an XPSP2 image to the RIS server, using an update.bat or similar textfile as the kickoff batch file to run once XP is installed.

3. In update.bat, install all the hotfixes you want, install all the applications you want, and do all the other things you want.

All done.

If you have some idea of the drivers you need, you can include them too. For example, in the [unattend] section of ristndrd.sif, put in something like:

[unattended]

DriverSigningPolicy = Ignore

OemPreinstall = yes

OemPnPDriversPath="x\c\intel;x\card\o2micro;x\card\ti;x\m\conexant;x\m\pctel;x\n\3c90x;x\n\broadcom"

...and put in the appropriate .sys/.inf drivers for that hardware (above, intel chipsets, o2micro cardbus drivers, ti cardbus drivers, conexant modem drivers, pctel modem drivers, 3c90x nic drivers, broadcom nic drivers.)

[HwagPo]

For 55 PCs only, I'd just use Ghost. An imaged copy of your SOE will be good enough to install to most of your workstations. For some with unusual/special drivers, it will prompt you when the OS starts anyway so just manually install the drivers, otherwise add them to your image. For all other PCs where your ghost image doesn't work, I'd just install manually.

[molman]

I don't even see what you're worried about. 55 PCs only? Over 4 weeks (20 work days), that's not even 3 PCs/day. One person could manage that installing everything manually (non-unattended).

Make basic unattended setups (optional) to install from. Then sysprep, ghost, and use that image for the other PCs (much like IcemanND said). I don't ever recall having a single HAL issue over the years (the most likely part would be mass storage adapters and such). Pack the necessary drivers somewhere (right in the ghost image perhaps so it ends up on the HD), let it detect new hardware and you're done. It only takes a few minutes to restore the ghost image (depending on size of image mainly) and detect drivers.

Assuming there isn't anything to keep on the PC's HDs, one guy could come in on the odd saturday or sunday (when no one's there) and do them all the same day by himself... (roughly 10 minutes/PC for a full day - not bad; worst case scenario a slightly longer day)

I should clarify, that the 5weeks does not refer to the available man hours for the project, but rather the time in days. Full manual install is not an option due to the time constraints, including the fact that these machines are all in use, so would need to task this work out of hours, or have it done in short order if in hours.

Windows 2003 Server, AD will be available, but possibly not till day 1 of deployment. So RIS option can not be effectively tested. Network install option is possible.

WSUS is in the works, but again will likely not be available on day 1.

Ghost software will likely be available.

Windows XP should be a volume license, all Pro verson.

As an side, what is the best way to check a machines HAL type?

Thanks for the advice/comments so far.

[nivlacckw]

I don't even see what you're worried about. 55 PCs only? Over 4 weeks (20 work days), that's not even 3 PCs/day. One person could manage that installing everything manually (non-unattended).

Make basic unattended setups (optional) to install from. Then sysprep, ghost, and use that image for the other PCs (much like IcemanND said). I don't ever recall having a single HAL issue over the years (the most likely part would be mass storage adapters and such). Pack the necessary drivers somewhere (right in the ghost image perhaps so it ends up on the HD), let it detect new hardware and you're done. It only takes a few minutes to restore the ghost image (depending on size of image mainly) and detect drivers.

Assuming there isn't anything to keep on the PC's HDs, one guy could come in on the odd saturday or sunday (when no one's there) and do them all the same day by himself... (roughly 10 minutes/PC for a full day - not bad; worst case scenario a slightly longer day)

I should clarify, that the 5weeks does not refer to the available man hours for the project, but rather the time in days. Full manual install is not an option due to the time constraints, including the fact that these machines are all in use, so would need to task this work out of hours, or have it done in short order if in hours.

Windows 2003 Server, AD will be available, but possibly not till day 1 of deployment. So RIS option can not be effectively tested. Network install option is possible.

WSUS is in the works, but again will likely not be available on day 1.

Ghost software will likely be available.

Windows XP should be a volume license, all Pro verson.

As an side, what is the best way to check a machines HAL type?

Thanks for the advice/comments so far.

MS Devcon.exe (command line device manager) can be used to check and change HAL.

Inserting mass stroage driver for offline Windows installation is possible and has been implemented in tools for server migration. (eg. Vmware P2V, leostream and helperapps)

There is a free solution which is pebuilder based from the below web.

Ultimate-P2V

http://www.rtfm-ed.co.uk/?page_id=174

Brandon Gordon’s (AKA Notorious_bdg’s “HAL_Update.txt” Plug-in

http://www.rtfm-ed.co.uk/downloads/HAL_Update.txt

[Mordac85]

Not a problem, but we need to get hopping. You'll need the following up front to start development:

• A sample of each unit that may require a discrete HAL (Desktop, Workstation, etc)
  
• Ghost 8.0 Corporate at a minimum (Ghost Solution Center is probably overkill, but may be Symantec's only current offering)
  
• Server space to stage the images, drivers and user data backups
  

Start w/a vanilla build of WXP w/SP2 & current hotfixes slipstreamed. Note the HAL and install your apps and other tweaks. Customize the default user profile and set any local policies as well. Consider your post install needs and script your GuiRunOnce or RunOnceEx to take care of it. Copy in your sysprep dir and setup your INF for your environment, run sysprep and image it.

Now have someone else test your image to make sure it runs how you want while you move onto the next HW type. Try using the initial HAL type image for other platforms to save development time. The single image can cover a variety of system models if you can include the various drivers you'll need.

Considering your time constraint a master unattended install would be nice, and a cleaner solution. However, scripting the unattended app installs may eat up more time than you have and, as IcemanND pointed out, will extend the rebuild time. Dropping an image only takes a few minutes whether pulling from a network share or a CD/DVD. Also, it will help your deployment if you have a standardized script/process for backing off user data. If you have any non-std apps that a few users will need, identify them up front so you know what you're walking into.

The only major problem you will run into, beside drivers which can still be corrected later, is the HAL. Screw that up and you'll get a BSOD.

Feel free to PM me for specific questions. I maintain our SOE's so I know what you're facing. Don't underestimate the time required to complete this either.

[Noise]

Use Ghost and I'll guarentee you you will have problems later. I'm speaking from 15 years of experience of corporate support. I am just saying this as a lesson learned: DO NOT USE GHOST TO DEPLOY WINDOWS

I also do not wish to argue this point with the Ghost supporters. I consider them amatures, and they usually just keep making excuses and work-arounds for Ghosts (or any image deployment) shortcommings. They just like to use Ghost because it's easy and they don't have to understand how real deployments work. They don't usually support a large infrastructure. Few of them understand how link-tracking, SSIDS, Registry permissions and default profiles work - all of which are affected by image based deployment.

The problems encountered by users of Ghost deployed images are usually not recognized by the support staff. They chalk up the intermittent application crashes and slow response times to "Windows Bugs" or some such thing.

Again, I do not wish to argue this point again in these forums, you can do a search where I argued this point last year in detail. I just bring this up again because I hate to see image deployed buggy installations give XP a bad reputation because some amature admin doesn't know what the hell he's doing.

[Mordac85]

While your post could be considered very inflaming and offensive, I pay it no heed b/c I think you did so only due to your own past experiences and aggravation over the problems you encountered. If not, I'll just assume you are strongly expressing your own heavily biased opinion, are welcome to do so. No one is forced to agree, but you can voice it. That's the beauty of the forum, molman can benefit from all the points brought out. However, common courtesy would ask that you refrain from the derogatory labels and speculation concerning other member’s abilities and motives where you have little or nothing upon which to base it. It’s immature and counter-productive.

I'm not an amateur but support a corporate business unit environment of ~8500 systems that is part of a much larger global conglomerate. But I know there is always something else to learn or see in a new light, that's why I 'm here. Since Ghost first came out in '96, I'm assuming you've been and admin for 15 years rather than working on deployments for that long. I'll agree that Ghost is not a panacea, but it is a very good tool if used properly. Some things should not be part of the master image but customized after the image is in place and maybe that is the thrust of your point, once you filter out the nonsense. For a basic vanilla install and app deployment, what I recommended is the prudent choice. Granted, there may be situations that may preclude them from being a part of the image. Like I said, imaging is not an end-all-be-all solution, and the best way to build a system is w/an unattended install. In my opinion, it's just not a practical soultion in this instance. Everything has limitations and given his situation, I believe imaging is his best course of action.

However, the topic question was how to get started w/little time to prepare. Not knowing what apps he has to include that may not have been mentioned, I would always recommend imaging over an unattended install simply b/c of the time differences.

I am intrigued by your statement:

The problems encountered by users of Ghost deployed images are usually not recognized by the support staff. They chalk up the intermittent application crashes and slow response times to "Windows Bugs" or some such thing.

In these instances, how did you verify that it was the image that caused the problems and not the process of applying the image to the system, or an event that occurred afterwards? There have been times that I strongly suspected an image had problems from the get go, but not that the image itself was faulty. That is not something that I have found can easily be proved. How did you do it?

In the end, molman needs to decide which route to take that fits his environment, timeline and expertise level. And, if needed, I'm sure the forum members will assist him with whatever problems he will run into. That's will, not may, b/c we all realize that no one knows it all.