Windows 7 Deployment: Part I

There is an old adage that claims “knowledge is power”, and if you believe that then, well, I’m going share a little bit of know-how in the realm of Windows migrations to those in the frantic rush to migrate off Windows XP before the April 14^th, 2014 deadline to do so.  This isn’t a comprehensive guide, but more “talking points” of things you need to consider. While I won’t claim a knowledge monopoly on the subject, having recently completed a 2-year, 150,000 client migration Windows 7 (with over 6,000 applications, 200+ countries, and nearly 10,000 physical locations), I think I know a little on the subject, and now happily share it with those on or about to go through the same trails and tribulations as I had the joy of enduring.

Assuming all of the pre-migration work of business case approvals, steering board committee commitments, approved budgets for resources, and even preliminary timelines/milestones have been set, let us get right into the migration fun.

Step 1. Discovery

Before one can begin migrating, one needs to know what they are migrating, how many they will migrate, and whether or not they can actually be migrated.  If you are a small, 1 location shop, more likely you can spend a few days physically counting the PCs and looking at their specs and applications to see if they meet Microsoft’s or your business’ requirements.  After all, not all of your PCs are going to be reusable.  However, in big shops, spanning hundreds or thousands of locations, multiple-countries, etc … it is just not feasible to do a manual discovery.  You’re going to need tools.

You’re going to need to know the following:

How many PCs are in scope

Although somebody used a relative “good guess” for the business case to start the project, you are going to need to find out how many PCs you have in your estate as best you can (by location, country, business unit, etc … helps with planning).  There are a few ways to do this:

a. Active Directory Object Count:  Depending on your Active Directory architecture, you can quickly get a good guess of how many objects you will need to migrate.  However, I’ve never seen a clear and accurate AD count.  Many machines somehow make it off of the domain, have server names instead of desktop names (or vice-versa), named wrong (location codes or even country codes can be wrong due to people moving locations within the company), etc.  The information is useful, but you’ll need to “triangulate” this information with better methods.

b. Centralized Desktop Management Tools:  The last contract I was on ran primarily an Altiris environment (lots of different tools exist however), so we were able to do Altiris queries for machines and their specs.  This tended to wield a good result, but it was still not accurate enough for our taste. Too many people in the old environment had local admin rights, and they usually removed the Altiris client when they had they chance, so you miss a lot of machines.  Not only that, the data in Altiris is only as good as Altiris (or any other system) is managed.  While it wasn't god awful, there were a lot of inaccuracies  with collections which were not suitable for gathering accurate data.  Again, good “triangulation” type data, but doesn't stand on its own.

c.  Discovery scripts:  What I found to be the best was a good ol’fashioned script that could be run locally (as an .exe) or as a login script via AD (or deployed as a task via Altiris or other tools if available).  In these cases, a nice PowerShell script can be your best friend.  Able to do a powerful WMI query, you’re able to pull all the information you need for a very robust discovery: host-name, physical specifications, applications, instances of those applications, user profiles … the whole lot!  What you will need is a good few weeks of running this script to get accurate data.  But after a few days, you can already get a good idea of what’s coming and start preparing for the next ugly steps.

The technical specs of those PCs

In some shops, you will go “greenfield” style which means that you will order (or already have ordered) new PCs for everybody.  This simplifies a lot of things, but it’s not the cheapest solution for most companies.  When “new PCs for everybody” isn’t feasible, the discovery information will tell you which PCs need to be replaced, which PCs can be upgraded to meet spec (ie...memory or HD upgrades), or which are already go to go for the OS swap. 

All these factors make a difference in re-deployment times and hence planning.  Moving data from one PC to another simply takes longer than keeping data on a machine and just upgrading the OS.  Therefore, make sure your company specs meet or exceed what will be needed for the new environment and get right to it.  New hardware orders take time.  When dealing with literally tens of thousands of new PCs, you can look at a 4-6 week delay easily.  Longer in most cases (see Global Images, Specs, Drivers below for additional duty to start in parallel)

The applications running on PCs

The real “meat & potato” of migration time deals with applications and packaging.  Don’t let anybody tell you different.  Yes, moving data from one PC to another can be cumbersome but you can buy or make tools that automate the process.  You can even automate to a large degree the installation of applications (as we did) on new/refreshed machines.  However, finding source files and testing those applications beforehand aren't easily automated.  You’ll need a team of packaging gurus, lots of luck, and some good testing if you want migration day to go smoothly. 

Take any liberty with shortcuts during this phase (no testing, lazy testing, messy testing environment), and you’ll pay.  Ooh, you’ll pay.  Make sure as the discovery script starts to populate the list of applications in use, you get the responsible people “white listing” the applications business will need, have licenses for, or are willing to pay for (and if they’re open source or free, are willing to support and pay packaging costs for).  Also if you’re packaging for remote deployment (via Altiris, or another centralized DMT), make sure you have a corresponding package to install manually as well.  This will save a lot of time when you find out a user is missing a business critical application.  In fact, all needed applications should be installed during the migration process, and desktop management tools should be use only in cases where local engineers aren’t available and something needs to get delivered.

Global Image, Specs, Drivers

The above processes are the first things you need to do, but at the same time, you should have already worked out a base image for your entire organization (Windows 7, company screen saver, applications that EVERYBODY gets, drivers for specific hardware types).  The image is the base of your migration.  However, it’s really only the base.  You cannot do a large, mass migration with an image because not everybody has the same software needs – and it’s a licensing nightmare (or non-compliance) if you deploy a lot more software than you have licenses for.  That’s why a base image should only contain software that your entire organization uses globally, nothing else.  Any software that is country specific, location specific, business unit or division specific, belongs to another process and not the global core the image.  This should be “made” and tested on the hardware you’re going to support (and include drivers for supported hardware only) during/before the discovery process is completed, so the tools needed to migrate can be completed and ready for duty.

Oh, and don't forget ... 32-bit or 64-bit ... what's needed and what are you willing to support?  95% of your organization won't need more than what 32-bit can offer.  So choose wisely, as support both platforms, means packaging for both, costs for both, etc ...

To be continued ... UATs and Pilots