Boy meets OS. Both are driven in their careers, with Screenbert working as a Systems Administrator and Windows XP working as reliable operating System. They are pushed to the breaking point after their latest, "Why can't you do this one little thing for me?" argument. Screenbert believes he should have the latest and greatest features and deserves more thereby drawing attention to XP's inflexibility. XP, on the other hand, believes she should have free time to herself after long working days and really doesn't need to provide updates for years on end. Here's the story of how it went down.
XP Savings vs. W7 Technology
Anytime you have a single OS you are certainly saving money in costs related to training, support and other areas. Your entire TCO is lower. We have been successfully using a single operating system for years and many IS team members have forgotten what it was like to support two Operating Systems.
I know it's been said that Windows 7 x64 is just a 64 bit upgrade from a 32 bit extension of a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. However that being said, the arguments were compelling. The main argument being that Windows XP will no longer be supported in any form roughly four years from now. What they means is no security patches or anything else.
We used a lifecycle migration strategy, that Gardner has suggested for previous OS migrations. That being said we have to get there now.
Our first step was to identify a group of people that would make up the "Windows 7 Investigation" Team. Once identified we went through our internal processes to get management prioritization and approval.
Big Decisions
We had to make some big decisions and quick. The first decision was what OS version. Since we are primarily an OEM customer we had already been buying Windows 7 Professional and using the downgrade rights to install them on our new XP machines.
Next we had to decide which 32 bit vs. 64 bit. This was a big decision. Would everything work on a 64 bit OS? What happens if we go with a 32 bit version? Ultimately we decided the benefits of going 64 bit were greater. With memory requirements continually go up and 32 bit being restricted to less than 4GB, we knew that if we migrated to Windows7 32 bit, we would have another big project before the next major OS release that would entail moving our image to a Windows 7 64 bit image. If we had to go through the pain of "breaking up" we really only wanted to do it once.
Image building
We decided to use our document outlining our XP image build as our base and go from there. However I had already jumped ahead of myself before the "windows 7 investigation" team was created and started building and testing a 32 bit version. This becomes an issue because you have to use the Windows AIK to build your "new" sysprep instructions. However this file is unique depending on whether you are running 32 bit or 64 bit. Further there are several different passes it uses to build the image and understanding them is a bit more complicated that it was with XP. If you have a 32 bit Vista sysprep file, you can't use it either. 64 bit is a whole new world.
It took some time to get it tweaked but eventually we got it finished and an image created that we could use for testing. One of the greatest new features is the PNP util for adding drivers. I created a batch file that runs right before I sysprep the machine that inject whatever drivers I want. Just drop the batch file in a folder that has all your drivers and it should inject them. I'll have more information about the gotchas with this later. For now I injected about drivers for four common hardware models we use. Here's the file:
dir *.inf /s /b >InfList.txt
for /f "tokens=*" %%i IN (InfList.txt) do CALL :PNP "%%i"
GOTO END
:PNP
pnputil -a %1
:END
Testing
Now that the image was built we had all of our application teams create a requirements for the their applications and testing them. We've literally had hundreds and hundreds of test cases entered with only a handful of major issues. The key here is getting it done in an organized manner.
Each team in IS that needs to test is added to our time tracking system and then they request a W7 machine to test on. Instead of creating a group of 70 test machines we created 70 virtual test machines running Windows 7. We requested that they use terminal services to connect and run their test cases. Once they were complete with testing we then would reimage the VM and assign it out to the next group. We had some capacity issues along the way but it's work really good overall.
Meanwhile we've given about 25 technology IS Team members the image on their PCs. We treated it like a lifecycle using tools like PC Transplant and Altiris Inventory to "migrate" their OS. Where we've run into several issues is around newer Hardware models.
Factory Image Installation
We use our hardware vendor to install our image in the factory before it's shipped to the end user. However their automated image building tool will not support 64 bit until later this year. Our initial thoughts were to create an image in the interim that could be used. This image could be used on the newer hardware models team members were using but were having Blue Screens with because of driver issues.
I started building it based on the same process I had used before and thought that I could just use the PNPutil to inject every driver I needed. After rebuilding the image and injecting all the drivers we needed, I discovered that on every boot I received a blue screen. It turns out some of the drivers for each model have the same name and step on each other.
Meanwhile our hardware vendor agreed to do a custom image for us until their online utility has 64 bit support. This meant rebuilding the image AGAIN from scratch following a simple 41 step process and then following our internal 58 step process.
Review
If you have to go through the pain of a breakup, let me recommend that you do it completely and don't leave any lingering what-ifs. Have a plan and make sure that management supports you. Don't jump ahead of yourself. However when you inevitably do jump ahead of yourself great documentation minimizes the time it takes to run through the process again. Having new features such as the problem steps recorder, user switching and advanced search has made the transition easier, but it's still not without pain.