Technically Speaking

Recently I was working on a project to get an application prepared for rollout. When I received the initial email about the process that needed to be followed, I called the vendor to find out if our usual server configuration would work or if different considerations would be needed. Specifically we are considering virtualization in the future using Windows Server 2008 R2 guest machines.

The response I received was that this application would support Windows Server 2008 but not Windows Server 2008 R2. I asked about plans to support R2 and was told that the application would not support Server 2008 R2 for some time. In other words they have no plans right now to support it.

My first thought was that this was a bit of an odd practice since Windows Server 2008 R2 is the current version of Server OS from Microsoft. Then I got to thinking about some of the considerations I might need to make to work this application. The only testing to be done is to ensure that the application, once installed, communicates to its supported devices over our network.

My plan is to set the application up using a Windows Server 2008 R2 Virtual Machine just to see if it will even run. If it doesn’t work, a 2008 VM will be tested, but since the functionality of the application is very limited in scope, I thought it was worth a shot. My goal is to spin up a 2008 R2 guest for this testing very soon (next week sometime).

I also started thinking about the difference between “not supported” and does not work. There are many applications that vendors no longer support and configurations they choose not to support that work just fine. Case in point, Windows 2000. Microsoft doesn’t support Windows 2000 anymore. But if I install it, it will run just like it was 1999.

If an application can run on an operating system one step (or half step) prior to current, there are few things that would make it unusable on the current OS. This to me, warrants giving it a shot. I believe that the requirements I got didn’t rule out x64 architecture, thus making it likely to work just fine on the current version of Windows Server. This way all of the servers in our upcoming environment will be consistent on the same OS (for a little while anyway). I also have to admit there are times when I like a challenge… and this is one of those times.

When considering supported applications, it is generally good to follow supported guidelines given by the manufacturer. When the application or vendor provides no technical reasoning or explanation for this choice, it might be worth a try. It comes down to the cost of your time and availability of your resources. If you have the time and resources to test, go for it. If not, well, convenience (and downgrade rights) say that following the stated guidelines is the easiest course.

Applications like VMware do not work on things outside their stated hardware compatibility list. Sure there are some who might be able to work on the edges of that list, but mostly it is definitely easier to work amongst the guidelines of the HCL. Being someone new to VMware, I am following the HCL for sure.

My advice here is dependent on your time and interest. If you are curious and have the resources, test it. If not, do not bother testing it. Being a bit of a geek, I rather enjoy the idea of testing things just for the sake of trying them out. It has helped me learn many different ways to do things as well as just learning about technology. Which I certainly encourage.

Attitude is everything, even if the phrase is cliche.  Recently I began a project at the office to upgrade our CRM application to the latest version.  The actual software upgrade went off without a hitch, but the database upgrade behind the scenes has been quite the challenge.

I have involved MS support to assist with some of the issues, which has been helpful.  I ended up on SQL Server 2005 and the majority of the work is completed, however there is a bit of work to do yet.

We have remote sales staff that also uses the application and updates to information are pushed to the home office (and to the remote users) via FTP.  I am working on the last two of these this week.

Upgrades gone bad, or going outside the original plan, are a frustration that will likely be around as long as software.  The problem is that many times more time is required to get the upgrade done as needed.  And the employees within the organization who use the application may or may not understand what the issues with the upgrade are.

Keeping a positive attitude during times like these is definitely a challenge.  However, remember what you love about IT and working with computers.  This will help when things unravel, but you may need to step away for a bit to realize that things are not always going to go as they should, but they are not the end of the world.

During an upgrade or project of any size, remember to take some time for yourself.  See a movie on the weekend or during off hours, spend time with family, just keep in mind that the upgrade will come out eventually.  Hopefully this post will remind you that, while stressful at times, software upgrades can be handled and your sanity can remain in tact.