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 14th, 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.
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.
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
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 ...
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
