I'm a big proponent of scripted installs. If we do find we have to use images, I make the images as basic as possible. For example, with XP, the image would just be a CD install of XP, remove unnecessary components, tweak some settings, run updates, clean up, and then sysprep. I didn't install anything other than Windows patches. Then, after we drop the image, we install all of our standard software using scripted installs. The nice part of this is that I can update any application in a matter of seconds if the package exists. The problem is that new systems don't maintain 100% consistency for more than a week or two at a time. Using LD for patching helps, since it will update everyone to the newest version of these programs, but it's still nice to have a group of systems that are 100% identical. Anyways, I view scripted installs of Windows as better than imaging, but imaging does still have a small place. Thick images are a waste unless you are doing a large group of 100% identical systems in a short time frame. Generally, the hour or two you save using a fat image is lost in patching time I've found.
As you see from above I could not agree more!!!!!!
If you can move to LDMS 9, take what Dan does and use HII and you can really reduce the amount of space and time to build a machine. I have tested this and found it was a good combo.
We are running LDMS 9.0 SP2, for stablity reasons we do not use images at all. I do not have the bandwidth to distribute a 5+GB image to 200+ sites over a set of T-1 lines. I can react faster to any change to the OS by changing an include in the scripted install. I am asking this question to see if there is a time, cost of support, cost of ownership savings between the two methods. I understand HII is there to remove the need for multiple images as at one time three years ago we had 10 different models in service.
Current time for just windows 7 to get installed is 9 to 11 minutes at the most. And I dont have to update the image, no copy profile issues, I patch the install at the end of the process. Total time to a usable machine is 90 minutes with profile migration built in. All of the files used in the install are stored locally in the DFS so the machine does not have anything to pull from the core and I dont have to use the preferred server in LDMS. There is almost no WAN impact other than the http traffic and the provisioining agent. The Windows 7 install files are also stored in the DFS and used in the install. No need to perform any offline servicing unless I can find a compelling reason to do so.
I have tried Dans method for both XP and 7 and this does not by me any time savings. It is roughly about the same amount of time and I tried it last night again right after reading his post just to see if it does buy me any time. Most enterprises are not distributed like ours is so this makes it a little more challenging on my end as nothing can be pulled across these with any real speed. If I have to image 5 boxes in a remote site I have to stagger them if I use the HII and an image as it still pulls drivers from the core server. I dont need to rely on any third part imaging software as what I am doing is all included on the WIndows 7 DVD. The scripted installl is like throwing the disk in the machine but I can add the drivers to the actual C:\Windows\System32 driver store with the unattended.xml file.
1 of 1 people found this helpful
We only have 18 sites to deal with here. Unfortunately, our connection speed is closer to 512kbps to each site. I couldn't get any storage space on our plant servers, so we couldn't use DFS replication. Instead, we have a desktop in the server room where our technicians do any local testing/work/storage that we need. I've created shares on them and utilized the replication feature of LDMS 9.0 SP2 to automate keeping them in sync. Then we add those shares as a linked share in DFS and we get the beneffit of DFS replication with the cost of desktop storage. Since the data is all replicated, we don't care about resiliency. And since the largest remote site is only 200 computers, the desktop OS limitations aren't so bad. It works well.
I understand what you're saying about HII. I believe that preferred servers are supposed to work with that. It just adds some delay. If I wasn't using the built in HII, I would use a system similar to what I did with MDT 2008. I had a vbscript that would pull out the model via wmi calls. Then, based on that, it would copy the folders off of the UNC path based on %make%\%model%\%OSVersion%_%Architecture% to the local driver store of the computer. Then I would inject the drivers using dism with Windows 7 or sysprep.inf injection with XP. It worked a treat. The major downside to it was that the drivers had to be stored in a logical fashion that wouldn't allow for the consolidation of drivers between different models. So for example, if the Lenovo X201Tablet and the T410 shared a NIC driver, I had to store two copies of it. If you wanted to program a method that would use some kind of manifest xml file to tell it what drivers to use for each make/model, you could probably fix that problem. However, by then you would have just about duplicated all of LANDesk's work, and gained very little for your work.
On a side note, while we may have less sites than you, we have infinitely more models of computers than you. We have an average 5-8 year life on our systems (Yes, I know how awful that is. No, no one will listen to me when I recommend enforcing a 5 year max life on computers). So currently, I have to support deploying to roughly 25 different main release models. (That doesn't include that we may have 4-5 variations of the same model). Yeah, my life sucks. Just imagine the fun when they tell me they want to be able to deploy XP, W7 x86, and W7 x64 based on their whim to about half of those models. :-) My driver store is very large and bloated.
What it really boils down to is what works for you. As I mentioned, I tried a variety of scenarios and did I notice much of a difference in time, probably not. Which one would I use? Well, because I have a potential of 350-700 sites all over the globe (no that isn't a typo), and HII is not able to be exported/imported, then I might stick to scripted OS installs. Keep in mind that most drivers can be installed silently and pushed like software or added to a provisioning templete. It really depends on what my support techs agree is the best and has the least amount of administrative overhead while providing the most consistancy and stability.
Iin my environment, due to the bandwith constraints, images are not used as the amount of data tranferred between sites. This is what pushed into the use of the scripted installation.