In this article, the last in our series on Windows 7 migration, we look further at the practical steps you'll need to take once you've decided to upgrade and kicked off the process.
More on applications
We've already discussed how to track down software incompatibilities — but what do you do once you've identified those potentially troublesome apps?
In a lot of cases all you'll need is a new driver or, possibly, a patch to make the application work. Easy enough to incorporate into your deployment, perhaps, but there's no guarantee it will work every time. Also, it's not uncommon to discover that the only solution is a chargeable upgrade. If you've decided to go for 64-bit Windows 7 and want to take full advantage of what it has to offer, then the need for an application upgrade is all the more likely.
Migration presents you with the opportunity to bring everyone into line, running the same application versions across the whole organisation. This does add to the up-front costs, but not hugely — check your licensing agreements, as you may be able to upgrade for free or at a discount — and can deliver maintenance and support savings in the long run.
This isn't an uncommon approach. Indeed, in a recent Symantec survey of over 1,300 organisations that had migrated to Windows 7, just over 70 percent had opted to replace incompatible apps rather than expend time and money trying to make them work. Over half had also chosen to deploy XP Mode virtualisation on the desktop to cope with exceptions, while a similar number used the migration to tighten up on authentication and security measures.
The browser question
While on the subject of applications, consider the web browser you're going to deploy. Internet Explorer 8 (IE) is what Microsoft would have you use, but it can't always cope with applications that rely on older, IE6-specific, technologies. Some of these issues can be addressed by activating IE8's 'compatibility mode' (you can arrange to do this by default), but others may be more intractable, so it's important to include web apps fairly early on in your application testing schedule.
One way around this issue is to allow users to run IE6 in XP Mode alongside IE8 on the desktop. However, IE6 is nearly a decade old and can't be patched to take advantage of the latest fast-moving web technologies, so XP Mode deployment should only be used as a last resort. IE9 isn't that far off either, plus there are other browsers, such as Mozilla Firefox and Google Chrome, that you might want to consider including in your desktop rollout, either instead of or alongside the Microsoft product.
Another small issue is the absence of a number applications that were bundled with previous versions of Windows (including both XP and Vista) but dropped from the Windows 7 release. These include Windows Mail, Messenger and Address Book, plus Photo Gallery and Movie Maker.
Many users can get by without these apps and may not even notice they've gone — indeed, their absence may be a blessing in disguise. If necessary, you can get them back by installing Windows Live Essentials: latest Live Essentials 2011 release not only lets you add these missing applications, but also includes Silverlight and Outlook connectors for Hotmail and social networking sites.
If you want users to have the apps you should...
...plan to incorporate them into your deployment images. Otherwise you can either leave users to download and install them or ban their use altogether. In which case, you should look at encouraging the use of alternatives — such as Outlook for email, calendaring and contacts — that are easier to manage and support.
One last major issue, and one you should address as soon as possible, is how you're going to activate your Windows desktops.
In a small company you might be able to do this manually — especially if you're deploying retail copies of Windows 7 or an OEM version preinstalled by a computer vendor. However, most businesses will have some kind of volume licensing agreement and will want to automate the activation process as far as possible. Two volume activation technologies can be used here: Multiple Activation Key (MAK) and Key Management Service (KMS).
Either or both can be employed, and neither presents any major technical challenges. However, there are a couple of practical considerations: MAK activates systems on a one-time basis using Microsoft's hosted activation services, while KMS customers can activate systems themselves from a server on their own network.
According to Microsoft, KMS is the preferred approach and should be used by the majority of customers migrating to Windows 7; it's the easiest to automate and everything occurs within the secure customer environment. It does require a server to host the KMS service, but this doesn't have to be dedicated, and there's also support for Windows 2003 as well as later 2008 platforms.
MAK is better suited to smaller companies or individual standalone machines and those disconnected from the network. A server isn't required, but a Volume Activation Management Tool is included in the Windows AIK (Automated Installation Kit) to help with the process.
Other practical issues include whether you go for a staged rollout or migrate all of your desktops in one go. The latter should be avoided, except in small organisations, and you should try to get each stage of your migration working correctly before you move onto the next, incorporating the lessons learned as you go.
Likewise, it's important to anticipate the problems that will, inevitably, arise. For example, you'll need to deal with disconnected systems separately and have a proper strategy for branch offices where bandwidth will dictate what's possible — you may have to schedule site visits. And don't forget your mobile users: it's not straightforward to deprive road warriors of their notebooks, even for a few hours.
And one last bit of advice. If you haven't done so already, subscribe to Microsoft's TechNet service: it's packed full of resources designed to make your Windows 7 migration as smooth and successful as possible.