Refresh, Replace and … Pre-stage

Hi everyone, it’s been a while since I’ve written my last blog post and this one might be the first of a series of articles. Actually, I just came back from the MVP summit with a ton of new blog post ideas. This article, once again, is inspired by a situation I’ve been facing in real life projects and that will, hopefully, give you ideas to refine your deployment infrastructure and scenarios.

The context

During the past two projects I’ve worked on, the constraint was the same, I acted as a technical project manager and couldn’t implement my favorite deployment infrastructure (e.g. Full Zero Touch using SCCM + MDT and MDT DB or CMDB). In the first project, I was not even capable of modifying the solution that was design by a different engineering group (in a different country). In the second project, the team I was leading was reluctant to use MDT and I couldn’t convince them.

 

In both project, the deployment started with a majority of Refresh scenarios (as a reminder for the non MDT aficionados: deployment of a new OS on the same hardware with data migration). And the performances were poor because the level of human interaction was high and the scripts not reliable enough. Therefore, we ended up having some very rough deployment nights where we deployed only a few machines with an average deployment time of 4 to 6 hours (yes, average, which means some took longerL)

 

 

 

I had to change something and actually, in my current project, the senior Director had a very precise idea of how many machines per night were supposed to be deployed and how long it should take (30 minutes to an hour)

The problem

That being said, I didn’t know exactly how to tackle the problem until the deployment lead in my first project came up with an interesting idea. Instead of doing Refreshes that often crashed during the imaging process that always took a solid 2 hours, why not do only Replaces where we can control the imaging before the actual migration.

In the Replace scenario I usually chain the OS install with the data restore, which still takes a long time at night, the key here was to decouple the OS install with the data restore.

Here’s a table that summarizes the different options

 

Scenario

Day before Migration

Migration Night (Old Computer)

Migration Night (New Computer)

Day After Migration

Refresh

 

– Data Backup
– OS Install
– Custom Apps Install
– Data Restore

 

End User Support

Replace

 

– Data Backup

– Data Backup
– OS Install
– Custom Apps Install
– Data Restore

End User Support

Pre-stage

– OS Install
– Custom Apps Install

– Data Backup

– Data Restore

End User Support

 

The solution and its constraints

We decided to move on with the pre-stage scenario, the gains at night were immediate:

  • Deployments were shrunk to only data backup/restore and hardware swap.
  • Replacement machines were installed and tested before the migration. We could even ask the VIP or sensitive users to sign off on their replacement device before the actual migration
  • We were able to catch application issues very early in the process and during the day time when all application support teams were available (and awake)

 

BUT, this solution has a lot of constraints:

  • You need to build the machines ahead of time, most of the time, we were not able to do that directly at the site where the target machine was located. We had to create a pre-staging area and had to deal with the logistics of shipping the machines on time for migration
  • You need to know what applications will be needed on the replacement machine before the migration, therefore, you need a good control on your inventory

 

The last point is probably the most important one and it got me thinking about the interactions that we could create between CMDB products and MDT/SCCM. I am going to start blogging about that very soon, I am already in touch with vendors like Cireson to evaluate their solution based on SCSM and see how I can give it an OS deployment twist.

 

To give you some numbers, we started the pilot with 10 machines per night that took an average of 4 to 6 hours per machine to an average of 90 machines per night with an average of 45 minutes per machine (data backup, data restore, post migration verifications).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s