Do you really need a build depot?

I recently was at a customer that used a build depot for Windows OS deployment to new and previously used computers before they were delivered to employees’ offices. The depot enabled the customer to build up to 100 computers a day and the customer had the peace of mind knowing that every computer being built was getting the same Windows image and applications. This process has been in place for well over a decade and had been accepted by employees as the standard process for receiving their computer. As a result of building computers at this central location, many new employees had to wait several days before they got their computer often causing many hours of lost productivity for new hires. This customer has been using Configuration Manager 2012 for several years but didn’t have the bandwidth to their plethora of sites throughout the United States and other countries.
In the build depot, the customer had two Configuration Manager 2012 distribution points with each server deploying to a set of two tables each. Each table could build as many as 20 computers at one time. A deployment technician managed these tables and was responsible for unboxing, placement, deployment, and repackaging the computers. The deployment process took about one hour but the computers had to remain on the tables for several hours to allow the encryption process to complete.
Another side effect of the build depot process was that many field technicians created their own full Windows images on a USB key or other media to avoid having to get equipment from the build depot just to get a freshly built image on a desktop. This would cause discrepancies in the customer’s Configuration Manager database due to identity duplication within the image being copied around. Also, some applications which installed unique values on the original computer were duplicated causing issues in the license tracking for those respective applications. Security and stability were also difficult to maintain since the image on the USB key quickly fell out-of-date with patch compliance.
1E was engaged to deploy Nomad 5.5 throughout the customer’s desktop infrastructure initially to aid in bandwidth reduction of software updates and application deployment. As part of our project, 1E Professional Services integrated Nomad into the OS deployment task sequences being used in the customer’s build depot. Due to the flexibility of the Nomad task sequence steps design, we easily added Nomad functionality into the customer’s build depot task sequence and began enabling field technicians to easily build or rebuild employees’ computers in place. This same OS deployment process done at the build depot could even been done on multiple computers in the customers office with a 1.5 megabit DSL line and finish in about two hours.
The build process is now easy to use and builds can be done in any location so the field technicians have no need to create their own images. This ensures the build is constant. The field technicians resort to using the Nomad-integrated deployment task sequence which always provides the latest Windows image along with the latest versions of the company’s additional software. Each week, only the changes in the image or applications are deployed to designated computers throughout the environment.
Another benefit of using Nomad is the enormous bandwidth savings due to the use of Nomad and the single-site download functionality within the product. Our reports indicated that within the first month of the Nomad implementation to 70 percent of the computer they had saved over a terabyte of bandwidth. Your networking team should be delighted to see that level of savings in bandwidth.
Are you interested but still a little skeptical? Another 1E customer has something to share with you then. If you would like to find out how you could decommission your build depot contact a Sales person in your region.