Migrating from XP in challenging circumstances
Colin Chaplin is a freelance Infrastructure Architect who helps large organisations transform Microsoft-based infrastructure.
The end of support for XP is… yes, you know when it was. Well run IT organisations should have moved to a modern operating system some time ago. There is a wealth of support information out there on how to successfully migrate away from XP. If you’re yet to migrate from XP, these will be vital. I’m willing to bet however, that some of your challenges aren’t quite covered in MVA courses.
The purpose of this document isn’t to cover this ground and the supporting infrastructure, it’s how to navigate when your IT estate isn’t quite the model of a good ship IT. It’s highly likely that all challenges won’t apply to you, but they all have been encountered in real-world migration scenarios and, no matter what size your organisation, should provide something to think about. Mostly, it’s not defining best practice, it’s about delivering a good experience to your users when you don’t have a blank chequebook.
Introducing a new operating system
Be it Windows 8.1 or Windows 7 it’s an opportunity to refresh your IT estate and introduce best practice, and, of course, you should strive to do so. You need, however, to balance the “best practice possible” against what is actually achievable. This is, unavoidably, a very obvious change to users, so a good time to introduce change (new OS, full disk encryption, software delivery, office suite, anti virus, web browser, VPN…), but not too much. A windows migration is challenging enough in itself without introducing a dozen different technology migration projects at the same time. It also almost guarantees that all these projects now tied together will all be late, rather than just some of them.
Now is a good time to understand your licensing position. There’s a lot of really great Microsoft tech out there like App-V and Med-V that you may already be licensed for. Determine if you are, and what licenses you should exploit.
Planning our Migration
Before we start pontificating about that though - how do we plan our migration? The answer is – measure it, audit it, check it!
You really, really need to know your existing IT estate, and it’s a really good time to do some housekeeping that will help with planning and put in place procedures. Let’s start with the hub of everything – Active Directory.
You should ensure your user and computer accounts are all live. It’s easy to measure last-login of both computers and users, then take some action on them – perhaps moving them to a Retired OU, disabling the account and so on (make sure you consider service accounts which you can usually identify with a UAC showing the password never expires). This is a few powershell commands away, and if run on a regular basis, will give you a directory of live accounts that you can rely on to measure. This means you know if you’re migrating 10,000 PCs or 12,000.
Where are These Computers and Who is Using Them?
The next step is to know where these computers are, and who is using them. With any luck you have some kind of audit tool, but remember this is an article on migrating from XP with nothing, so let’s look at what we can do.
The ‘description’ field of Computer and Users is a potential goldmine. It’s user-writable by default and ripe for inserting some info. Create a login VBScript (let’s not assume we’ve rolled out powershell to XP) that inserts username, IP address, perhaps AD subnet info into the description field of the computer accounts and something similar into a user account description. This is not foolproof and will not capture hot-desk PCs, and also assumes people do ‘proper logins’ and not just close their laptop lids. Over time however, it will begin to populate and start to give you a rough idea (or good-enoughski as an old colleague used to say) of users, their computer and locations.
Did I say locations? Well, hopefully your AD Site and Subnets are fully populated (check netlogon.log domain controller for reports of PCs logging in from missing subnets). And if they are not, this is a good excuse to do it. Building a table of IP addresses to physical locations is a useful tool to start getting an idea of where your computers are. Best of all, relying on a login script typically means that you don’t get IP addresses from computers when they are VPN’d in. Another option is to log what users default printers are set to; most people will have their nearest printer as the default.
What is on These Computers?
So, now we know roughly where our computers and users are, we now need to know what’s on them.
We can return to our login black magic to help us out.
Lets think about what we need to know - Basic PC spec, Form factor (is it a slimline PC, laptop etc) make, model, software installed. Maybe USB devices connected? A professional audit tool can give you all this and more, perhaps with better results. If you’re lucky enough to have such a tool, perhaps now is a good time to validate how much coverage you have versus how much coverage you think you have, but we’ve got nothing, so, how do we get this? Luckily, windows delivers this up to you on a plate through WMI, all you have to do is tickle it gently and it’ll reveal all.
Again, our weapon of choice is a login script calling a little VBscript that asks WMI all this information. It’s perhaps easiest if we split this into a simple text file on a fileshare (named, say computername!username.txt) for later analysis.
Especially if we’re moving people to a new PC, we need to be worried about how much ‘local data’ is on the PC. Many organisations will ‘hide’ the C: drive and redirect user folders to network drives, perhaps with roaming profiles. Others may not be so lucky. It’s important to understand the size of userdata stored on the PCs, even if you’re doing in place upgrades, understanding ‘what’s out there’ is important to understand impact. If you’re introducing new PCs, knowing the size of data is critical to migration timings. Best-case-scenario is taking data off old PCs at about 10GB/hour, so if all your users are hiding lots of multiple GB PST files you might get a surprise if you assume a high daily run rate.
What Data Do We Have?
So we need to look at what data we have here. There’s a few options. We could rattle something together in VBScript, taking care to check when we look in my documents and desktop to see if they’ve been redirected. Or, we can run USMT (more on this later) in reporting mode and pipe back the output that will tell us the data load to migrate. Whilst we’re at it, grabbing all registered file extensions is a good idea to determine what file extensions we’re going to feed to USMT.
So we’ve not got a list (or lots of lists) of what software is installed on PCs. Unfortunately, telling what software is used is probably beyond a simple script based solution (which, in itself may be a business case for buying such as software metering solution). So we therefore assume that if it’s installed, it’s used. Our first task is to build our ignore list – applications we don’t really care about (and why). Things like software related to drivers, middleware you’d include anyway like .Net Framework and obviously non business related software.
Media and Apps
Once we have filtered these out, we have our ‘list of doom’. All the software we need to deploy on the new OS. You have, of course, got install media, licenses for all these apps, business owners of these apps; you know your serial numbers and have other proof of entitlements, test scripts, willing testers, yes? You’re going to need all these and unless they’re already packaged (in a compatible software deployment system) you’ll need to get them packaged (or sequenced). At this point, you also need to consider if it’s time to invest to upgrade to newer versions of the app. Or you may need to. App Compatibility is always a concern. There are commercial solutions that will analyse your app set and tell you what works on your chosen OS (and potential fixes). Or you could get busy with your favourite search engine and the app name.
It’s very likely you’re rolling out a new version of Internet Explorer (and if not, a different set of Group Policies determining it’s behaviour). When asked about their applications they use, people will consider websites as an app, and popular websites need to be tested and considered in the same way as traditional apps. You’ll probably also have to figure out what are your popular apps websites – hopefully your proxy can provide lists of what websites are being accessed.
Apps are hard, very hard! This will be the hardest, and the latest part of the whole migration.
64 Bit OS
There’s no reason these days not to roll out a 64 bit OS; 64 bit drivers have been around for years, but perhaps not on your print servers. Your PCs pull drivers from a hidden share on print servers and silently install them. Unless the print server is 64 bit itself, it likely won’t have 64 bit print drivers. The world’s best XP migration will be deemed a failure if a secretary can’t print an itinerary. So again, let’s go and measure first. Grab all print servers advertised in AD, then prod each print server in question with a bit of powershell that will tell you if it offers a 64 bit driver. From thereon in it’s a case of carefully finding the right 64 bit driver and squirting it into the hidden driver share.
Drivers
Drivers are a continual pain in XP. Do you give all users admin rights so they can install drivers (eek!), get the support to do that bit, package a driver, go to windows update? We have a couple more options in Win 7. We can pare down the security settings so that any user can install drivers for class of devices that we see fit, but this still puts a skill demand on the user. You’ll be aware that windows has an internal driver store, and when a peripheral is plugged in, it will attempt to look for a driver in this and install? Well, you can also configure windows to search on a fileshare. So, you’ve audited USB connected devices above, find out what they are, put the drivers in a fileshare, told windows via a GPO where it is. Result? You can control what drivers are installed and devices will be setup automatically without user intervention.
One of the little-talked-about benefits of Windows 7 and greater operating systems is that SMBv2 means faster access to file servers. However, if your file servers are not windows servers, they may not support SMBv2 or it might need switching on. In extreme cases, some fileservers will not be able to comply with the default secure settings in Windows 7 and a decision will have to be made to migrate fileshares or weaken security. Do you know where your fileshares are?
There’s a lot of moving parts here – apps available and testing on the new build, people and places, what department they are in, what date they are going to move and how. What are the replacements, how do old apps map to new. And, with the best will in the world not all of your apps will be available when you want to start rolling out PCs.
Third Party Tools
We need some technology to help us out. There are a lot of third party tools that are designed specifically for this task, grabbing feeds from different data sources and applying a rules engine, so for example you can see who can be rolled out, and where. The advantage of these is that they are off the shelf and will give you the essence of a migration methodology. The disadvantage of these apps are that they are off the shelf and may constrain you to what you can do, and need some customization. The alternative approach is to roll-your-own solution which will need some substantial up-front development but you’ll end up with exactly what you want.
End Users
You can use your end users to help fill in any information gaps that – even with all the information gathering above, executed to perfection, you will still have. It’s a confusing (and worrying) time for end users so your communications plan needs to be built and delivered to the same high standard as your technology implementation. Communications to users need to be tailored just for them, and they will want to know that you’re taking care of the fact they have two docking stations, have an utterly business critical app, and need a souped-up PC. So tell each user, individually, what you know about them and what they are going to get. You are looking to almost provoke users into telling you what you’ve got wrong because it’s much easier to fix it beforehand than on the day. This communication approach needs to be tied in with your migration engine. Don’t assume you’ll get anything like complete engagement – but perhaps a supplier would like to donate some swag to help encourage feedback.
Testing
In particular your apps - is vital. But if your company has lots of offices, asking people to travel to a test site will not be an attractive proposition. We need to offer a range of testing options. The main ones should be use of virtual machines. Perhaps you have a ready-made virtual farm with capacity where you can host a number of VMs that people can RDP into. Failing that, a modern PC with 16-24GB of memory and two hard disks can run the free Hyper-V server 2012 with about 5 VMs and offer good performance to testers. Best of all, unlike other hypervisors you don’t have to bake-in VM drivers or additions. Put the .rdp files onto a fileshare representing each VM then name the file based on the user testing. You can then flex your powershell to stand up VMs, roll back and have them ready for your testers.
Getting data and settings off XP and onto your new build can be a challenge. Perhaps you dissuade local storage of data and redirect user data areas to a network share. We’re assuming the most challenging set of circumstances, in this circumstance that means data and settings strewn across the C: drive and registry. There’s a certain desirable purity in letting users start ‘fresh’, but your users won’t see it that way. They’ve got enough to worry about on receipt of their new OS than to worry about where their custom dictionary has gone, or what their WiFi passwords were. Fortunately, Microsoft help us out with the USMT utility which can work whether you are swapping out PCs or performing in-place upgrades and does an excellent job of migrating data and settings. It’s well worth spending the time to tweak with supplied XML files, in the first instance to remove settings you don’t want to migrate, and then think about what you do. The command line syntax is complex, so best to have it in some sort of batch file (possibly dynamically generated). Output logfiles to a fileshare so they can be reviewed and tracked for Management Information (MI) purposes.
To Conclude
Your end result should be a familiar environment to all users when they log back in. Even the ones who insist on hundreds of files on the desktop, arranged just so.
Don’t neglect your MI; there will be a lot of stakeholders and senior people involved, but no one will be knocking down their door to tell them it’s all gone well. So collect stats, and regularly share them. MB of data transferred, PCs upgraded, minutes-per-day save waiting for PC bootup, servicedesk calls.
All this work, and we haven’t even rolled out a migrated PC yet! When the build is fairly settled and usable, aim to get updated devices out to friendly users as-soon-as-possible, perhaps with the safety net of being able to return to their old device should something not operate as expected. Of course, you’ll be doing formal testing, but nothing beats getting your new creation in the hands of users and see what they do with it.
Finally, don’t forget to tell people what you’ve done (and why not right here!). Anyone can stand up a shiny, new windows desktop environment. No one has ever done the migration you’re about to do, nor met your unique challenges. But, delivering success by being armed with the preparation described here – others are sure to want to know.
Resources
Did you have to do a XP migration? What challenges did you face? Let us know in the comments section below, or via @TechNetUK.