I meant to write this much sooner, but I have to say it’s been a busy past few months. In my previous post I wrote about a lot of the thoughts that crossed my mind during my discovery phase. This was a somewhat tedious process that is often forgotten through the project scoping phase and could later cause issues during the execution phase of a project.
As mentioned on part 1, my organization had decided that SCCM 2012R2 would be used to perform automated OS upgrades on machines running Windows XP to Windows 7. Initially a lot of time was spent trying to get the process working on virtual machines while a list of models and drivers was being compiled.
There was a lot of effort and time spent trying to get SCCM 2012R2 to support Windows XP out of the box, as previously mentioned a hotfix from Microsoft had to be introduced for the SCCM environment and all managed clients. In addition to the hotfix, we could not get WinPE 5.0 support out of the box so this forced us to spend additional time modifying a working WinPE 3.1 boot wim file. I written up a lengthy post on “How to create a WinPE 3.1 boot image and import it to SCCM 2012R2” that would later on become fundamentally important to making the Operating System upgrade smooth sailing.
The initial upgrade process would leverage SCCM 2012R2’s native task sequence process to upgrade Operating Systems and be integrated with MDT 2013. A lengthy task sequence would be utilized to perform an OS upgrade leveraging hard-links to keep the data local to the machine. Several task sequence steps had to be introduced to assist with detailed logging based on success or failure type events. These logs would be copied over to a central repository and would later come very handy.
In addition to the basic task sequence improvements, custom reports needed to be prepped so we could have a birds eye view of the overall deployment. Daily reports displaying the total count of daily successes and failures along with a weekly report that would be provided to upper management. This was a time consuming process but it was very well worth the effort.
Once the necessary test was completed, we begun working on roll out dates and user experience on the various administrative sites. What we did was stagger everything into 4 groups based on our organization’s architecture leaving administrative buildings at the end. The administrative sites also had an additional step that was taken to send them an informational pop-up telling them about XP’s end of life and how they could perform a self-upgrade or could contact the service desk. This message would re-appear once a week until their mandatory start time would begin. Once the task sequence had been deployed to machines we would carefully examine deployment windows and the location in which our detailed logging was dumping the success/failed logs.
In the end we were able to upgrade more than 25,000 computers automatically with this process while a large number of other workstations got freshly re-imaged by many of the site techs during the five months. Some of the most important items to note are as follows:
- Choose an upgrade method and go through the numbers best/worst case scenarios.
- When creating an upgrade task sequence create several fall back steps in case of partial failure.
- Create a set of minimum pre-requisites and add checks to the task sequence in case collections fail.
- Create reports or modifying task sequence reports to get detailed numbers of success and failures daily/weekly.
- Set a end date for those machines that failed to upgrade or could not be upgraded to a later OS.
- Security tends to help here by using policies as a reason to remove the assets or disconnect them from the network.