7 Replies Latest reply on Jan 6, 2011 5:58 PM by Zferrini

    Scripted Install vs Image


      Hi again all,



      I am not starting this thread as a debate, more as a "Benefits of" discussion.  We are med size enterprise, roughly 2500 nodes +, and many satellite offices.  Our bandwidth is limited to a t-1 so everything is stored locally in the DFS. That kills the ability to store even a single image for use with provisioning due to update and distribution issues.  I turned to Windows AD GP and full scripted installations of WinXP SP3 using LDMS 8.8 a couple of years ago.  Drivers for HW were the biggest challenge but after putting in about 3 months of work I could install in place, 3 desktop and 4 laptop models dynamically.  The time to install varied depending on the speed of the machine and HD.  The average time to complete for the desktop was around 2 hours, with laptops 3 due to the extra software needed.  I know you all are thinking, I can have a machine imaged in 30 minutes.  I have always had issues with the time it takes to build, update all of the software, the security patches, and the various extra work to maintain them.  My maintenance time has now dropped to, on a bad MS patch Tuesday, 20 minutes.  I can react to a new model in one day, roughly.  I can add base working software in minutes and any of the aforementioned can be available to the local subnet in as little as an hour.


      I posted an unattended file earlier on the community to show that this is possible and efficient.  I take criticism, as long as it is reasonable, as a lesson.  I am by no means a master at this or LANDesk provisioning. I can post the full set of templates but it will take a while to clean them.


      My question, am I wrong in my assumptions?



        • 1. Re: Scripted Install vs Image

          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.

          • 2. Re: Scripted Install vs Image

            As you see from above I could not agree more!!!!!!

            • 3. Re: Scripted Install vs Image

              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.

              • 4. Re: Scripted Install vs Image

                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.



                • 5. Re: Scripted Install vs Image

                  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.

                  1 of 1 people found this helpful
                  • 6. Re: Scripted Install vs Image

                    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.

                    • 7. Re: Scripted Install vs Image

                      Absolutely agree,


                      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.