First Hand Experience with Upgrade (Part 2 of 4)

Once the workstations were working decently well, we tackled the server side of the upgrade. Since we were only working during the weekends while I had time, we decided to break this into two components – Active Directory and File & Print Servers as the first phase and then Exchange Server as the final phase.

Tailspin Toys also decided to go with virtualization to reduce the number of physical servers while maintaining isolation of roles. I opted to use the full version of Server 2008 R2 with Hyper-V rather than a core install or the free Hyper-V 2008 R2 Server. The install of the host server went without a hitch and was very fast. After configuring Hyper-V, we installed our first VM to be a File & Print Server in the domain. The only thing we configured on this initial server was the Print Server role and all the print drivers for the Windows 7 64 bit clients. [Remember we decided to do this during the workstation upgrade phase].

The second VM we installed was slated to be the first 2008 R2 DC / GC in the environment. This install was blazing fast!!! The process of running ADPREP and DCPROMO went without any problems and we soon had our first 2008 R2 DC / GC introduced into the domain. We then moved the DHCP role to the new server, updated all the appropriate options and forced all the clients to refresh their IP settings to start grabbing their IP information from the new server. After verifying the DC / GC information had fully replicated, I moved all the FSMO roles off the old Domain Controllers to the new ones.

We then finished configuring the File & Print server we setup earlier in the process so that it would function as the main File server. It took a little bit of time to move over all the data, but that process was smooth and had no issues. We then had to reconfigure all the drive mappings for the clients to point to the new File Server. I chose to implement DFS at this point so that it would be an easier process in the future should Tailspin Toys decide to move files / shares around in the future.

The final step of this phase was installing the appropriate server applications. This is where I ran into a bit of an issue. One of the applications would not install onto a 64 bit Server OS. As luck would have it, the ISV did not have phone support on weekends so we had to push this last piece to yet another weekend until we had a chance to speak with support during the weekday. Once Tailspin Toys contacted support, they were informed that they needed a newer version of the application which would support Server 2008 R2 and 64 bit! Whew! The tech support was also kind enough to inform my friend that they would need to rerun the workstation install on all the client machines to reconfigure them to use the new application server.

Once we got the application installed and migrated the database over to the new server, we went around to all the client machines and reran the workstation install. Without fail, every single one of the client machines was still attempting to connect to the old server. Since tech support was not available on the weekend, we either had to take time to troubleshot on our own or wait until next weekend to finish the move (yet another weekend). Since I was already there, I decided to take some time to see if I couldn’t figure out the issue. I found that an install of the client software on a brand new machine (that never had it installed before) worked fine and connected to the new application server. I went to one of the existing computers and uninstalled the application and then reinstalled with no success. I then searched the registry as well as for application specific INI files. I did find application INI files, but as far as I could tell they had the correct information in them. Alas, we had to wait one more weekend.

After another call to tech support, my friend found out that the application wrote the INI file to the users profile in the AppData\Roaming folder (which I did not search in my troubleshooting since it is a hidden directory). We had to delete the INI file in that directory and then rerun the workstation install. ARGH!!! That took all of 30 minutes for us to walk around to all the workstations and complete.

What should have only taken one weekend ended up taking us three because of technical issues and the fact that I wasn’t available during the weekdays. However, I will have to say that this portion of the upgrade was fairly simple.

*****************************************************************************************************************************************************************
I do have to make a note here regarding the Workstation phase as I forgot to put that in my last post. There were two applications in use on all workstations that would not run correctly unless the user had local administrator privileges. Calls to the ISV’s tech support lines confirmed that the “fix” for these applications was to make the user a local administrator. My friend had hoped to give all the users non admin access to their computers, but was not able to accomplish this goal due to these two applications.
******************************************************************************************************************************************************************

Harold Wong

Comments

• Anonymous
  February 16, 2011
  Could you run either Process Monitor or LUA Buglight to determine where the disconnect was and maybe change permissions to accomadate the user?  I have done that in the past with good results. Can you tell us what the apps are?

• Anonymous
  February 16, 2011
  Art: I haven't used those types of tools in a long time so it didn't occur to me to do that.  I will look into that to see what is going on.  In terms of naming the applications, I was asked by my friend not to mention any of that information publicly.  I am also not specifying exactly how many servers total are in play - other than that they have one Exchange Server (next post). Harold Wong