Discussing Deployment Logistics

A part of the desktop refresh project that is often overlooked is the discussion on deployment logistics, the questions like who will deploy? when will we deploy? what will we deploy? This post aims to help you understand the different logistic models people go for and discuss the pros and cons.

Before we get into this post, first thing… Hands up if the introduction sounds like your last deployment project? I would expect a few hands up to that question normally. Some places I visit are really good at planning and others not so. It is more down to that they think about it, leave it, put it off, then all of a sudden we are a couple of weeks away from our advertised start date. So once you have your technical deployment scenarios figured out and you know how you will deploy in project and maybe in business as usual what is available to us from a logistics point of view?

Off Premise

First we have the off premise method. If you are going with one of the big vendors like Dell, HP, Lenovo etc then you may find yourselves with a ready made service in your hands. Dell call their service Custom Factory Integration or CFI for short. Using the off premise model you provide the vendor with your task sequence in an offline state and they produce the deployment onto your equipment before it leaves the factory.

This method has both benefits and some consideration points. Benefits wise, you are removing the whole build process outside of your control, some may see this as a bad thing but I don’t think so. This method leaves my deployment project team free to do other things. For those of you that have done this before you will know how valuable that extra time really is!

On the flip side think about security. I know some CFI customers who have provided the vendor with a distribution point and management point to distribute content locally, meaning you can still take advantage of MDT and all the cool things that come with it. However, don’t forget this box is on a network, probably a VPN link back to your corporate network. Think about maybe using IPsec or HTTPS roles with certificates on the clients.

You can also think about how far you want the build to go. Should it be 100% complete when it arrives on the users desk? Or should some additional configuration be required at first boot? These are all personal decisions, neither is right or wrong.

On Premise

I like the on premise model a lot. The reason is everything is exactly the same as off premise but without the security concerns and you can without a doubt finish off your deployment before delivering the kit to the user. You can even try and get a 3rd party in to run this for you, then you still have control over your environment and the whole process. It can be a stressful time running it like this but also very rewarding and make your deployment very quick.

This model tends to work well when you have invested lots of time in the planning stage, if you haven’t this is when you know about it with missing user state, missing applications or applications which don’t work with Windows 7. It all comes back to something I really cannot say enough when on this subject, make sure you plan the hell out of this and double check everything, especially your applications.

Opt-In

Another popular deployment method is the opt-in scheme. This is where you allow users to submit that they are ready for upgrade. This process can include the running of an automated script or program to check the readiness of the machine for deployment. Anything down to user state limits you have set to checking applications have been accounted for.

What isn’t so great about this model is that it can take a very long time. Some people don’t like change so will never opt-in, then you have the situation that you are managing two live environments, double the work for everything from patching to deploying new applications. Consider setting a deadline on the opt-in scheme so that after a certain date everyone will be upgraded anyway.

This is a great deployment model for organisations that are tech savvy. This means that people will be able to get the latest and greatest when they want, something which will keep your users and the business happy.

Replace on Failure

A valid deployment model but not really practical in most organisations is the replace on failure. This simply means that when hardware or software fails you are upgraded. IF you have even 1,000 machines which is considered a small deployment in enterprise terms then think how long that could potentially take. Say you had four failures a month with 1,000 clients, that would take 250 months or slightly under 21 years! Not really an option at all but some people do it.

In Summary

I guess the key message here is no single method is right, we have a few because everywhere is different. Don’t rule out using a combination either, some customers of mine are using the opt-in and on premise models in different scenarios, think about using one model for your pilot and one for your live deployment.

Advertisements

Tags: , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

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

%d bloggers like this: