First Hand Experience with upgrade from Windows Server 2003, Exchange Server 2003, Windows XP and Office 2003 to latest and greatest

I recently helped a friend of mine update his office network environment from some older outdated stuff to newer stuff. What am I referring to, you may ask? I helped them get from Windows Server 2003, Exchange Server 2003, Windows XP Professional and Office 2003 Professional to Windows Server 2008 R2, Exchange Server 2010, Windows 7 Professional (64 bit and 32 bit) and Office 2010 Professional.

I thought, “How hard can this be? Should take a weekend (or maybe two) and everything should be good to go.” WRONG!!!!! The thing to keep in mind is that I don’t do day to day support or even get to work with production environments in my role. I did figure I would encounter a few challenges, but nothing too major. This is where I was wrong so I thought I would share my experiences with all aspects of this upgrade.

There is way too much information for me to write up this entire experience in one blog post so I have decided to break this up into multiple posts. I will start by giving some background on the old environment without giving away any confidential information. To avoid any legal issues, I will refer to this company as Tailspin Toys.

Tailspin Toys is a small business that has standardized on the Microsoft platform to run their business. All of the domain controllers, file servers and Exchange server were running Windows Server 2003 with the latest patches. The Exchange Server was at SP2 and any post SP2 hotfixes were applied. The workstations were all running Windows XP Professional and Office 2003 Professional with all the latest Service Packs and hotfixes applied. The entire environment was 32 bit (servers and workstations).

In this first blog post, I will go through the workstation upgrade process. In subsequent posts, I will cover the Server side of the upgrade.

First, Tailspin Toys contacted the key manufacturers of the key applications that they used to confirm that the applications were indeed supported on Windows 7. All of them confirmed that the current versions of the applications were indeed supported on Windows 7 – great news here. The thing that I forgot to have them ask about was support for 64 bit Windows 7 (this caused some problems later).

When I evaluated the workstation hardware, I found that the majority of them were quite old and it would probably make sense to purchase new machines. Tailspin Toys told me they wanted to get machines with at least 4 GB of RAM and a processor that would last them another 4 – 6 years before having to buy new hardware (they are open to upgrading the OS within that timeframe though). With that in mind, I recommended they purchase workstations with an Intel Core i-5 processor and 4 GB of RAM. In order to take advantage of all the memory, I suggested they go with the 64 bit edition of Windows 7.

Before replacing all the machines, we did test with one to make sure the applications did indeed work fine. During this test, we realized that they would need to run some of the older versions of their applications in order to access some of the older data – this would be infrequent, but still necessary. With further testing, I found some of the applications did install and run fine on Windows 7 (just not officially supported) while others did not. This is where XP Mode came to the rescue. I was able to use disk2vhd to grab the hard drive of the existing XP machine and run it just fine within Windows 7 Virtual PC. Since I wasn’t sure about the licensing aspect of doing this, I did spend time to configure the XP Mode VM so Tailspin Toys didn’t have to purchase any additional OS licenses. [Side bar: This was a good experience as I found that I could literally image an existing XP machine using disk2vhd and successfully run it in Windows 7 Virtual PC with the XP Mode integration capabilities enabled to seamlessly run applications directly from Windows 7 – just like using the XP Mode image. Also, I found that it wasn’t all that difficult to configure the XP Mode VM to do the same.]. I then took the XP Mode VHD that I modified with all the older applications and copied it to the other workstations that needed the VHD and replaced the original file on the hard drive. This worked like a champ so I didn’t have to install all the applications numerous times.

We decided to upgrade all the workstations prior to upgrading the server infrastructure since this seemed like the path of least issues. One of the issues we immediately ran into was around print drivers. Tailspin Toys did not purchase new printers and some of the printers they were using have been around forever. I hit the printer manufacturer’s website to download the Windows 7 compatible drivers. According to the website, Windows 7 had built in support for these printers, yet we were getting prompted for driver files. After further research, I found that Windows 7 32 bit had the drivers included, but not 64 bit – ARGH! I had to have Windows 7 search Windows update for the drivers at which time the print drivers for all the printers appeared. I hit the Windows Update catalog and downloaded the appropriate 64 bit drivers for all the printers so that I could install them onto the Windows Server 2003 print server. No matter what I did, I could not get these drivers to be installed as additional drivers on the Windows Server 2003 Print Server. Rather than waste more time on this, we decided to stand up one of the new File / Print Server running Windows Server 2008 R2 sooner versus later to be the active Print Server for all the new 64 bit Windows 7 Professional workstations.

Another workstation component we ran into was that some applications had the built in ability to print to PDF directly within the application. Without fail, all of these applications installed a “special” printer driver to accomplish this Print to PDF capability. Here’s where we ran into another doozy. One particular application installed a 32 bit version of this printer driver which is totally incompatible with 64 bit Windows 7 and would lock up the application every time we attempted to create a PDF within this application. A few hours on the phone with Technical Support and we had a work around, but the work around is not a 100% fix so there are some issues still today with this item. These application vendors need to find a better solution to creating PDFs within their applications without the need for these “fake” Print to PDF printer definitions and associated weird drivers.

I forgot to mention that the workstation “upgrades” took place over a period of 3 weekends.

Harold Wong

Comments

• Anonymous
  February 15, 2011
  Great post!  Really looking forward to the Exchange migration.

• Anonymous
  February 15, 2011
  Harold, Oh wow!  I'm about to do the same type of upgrades starting in March.  I've started with the workstations at least.  Some what nervous about the Exchange server due to not getting a handle on Powershell. I started off well, but literally I have so many projects that I forgot most of what I knew for lack of use.  Well, maybe I will make it to one of your tech events again.  I'm the guy that still writes you at least once a year with some question even though I am in Colorado.

• Anonymous
  February 16, 2011
  I will have the follow up posts on AD, File Servers an Exchange up over the next few days. Harold