October 6, 2005 at 2:23 pm
I have always upgraded the OS on test servers before upgrading on production. We are in the process of upgrading hardware for a production server and are considering installing Windows Server 2003 Standard Edition vs. what previously existed on the server, Windows 2000 Standard Edition. How much of a risk would this present? I'm leaning towards not changing the OS until we have a chance to upgrade the test servers first.
Dave
October 7, 2005 at 2:11 am
I wouldn't even contemplate it without testing it first. Even a fairly small upgrade to Windows components should be tested first.
I've seen too many innocuous looking upgrades cause problems e.g MDAC
In your case, it sounds as though you are upgrading the hardware as well as the OS. That's far too risky without a thorough test in my opinion.
October 7, 2005 at 4:56 am
Your proposed upgrade strategy appears to be designed to cause an outage.
I would look for an alternative, such as testing it first!
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
October 7, 2005 at 7:04 am
I should have explained the situation a bit better. We had planned to test the hardware upgrade, but the testing involved for a hardware upgrade is fairly basic since we are primarily concerned with connectivity, performance and security testing. Application functionality testing wouldn't come into play for a hardware upgrade, assuming the OS and SQL Server versions (including hot fixes and service packs) remained unchanged.
We found a Q article (Q329332) that addressed a problem with Linked servers and Windows Server 2003. Once I heard about this issue yesterday we decided that testing the application functionality was necessary.
I appreciate the feedback.
Dave
October 7, 2005 at 3:04 pm
If you have to ask the question, the O/S is the LEAST of your worries.
<insert favorite winking emoticon>
October 7, 2005 at 3:35 pm
I'm afraid I don't find your comment amusing.
October 10, 2005 at 8:01 am
I should hope not.
Now, to rephrase it so as not to appear amusing:
If, for whatever reason, the policies in place at an organization would permit changes to a system without some sort of testing plan, then the policies are likely a greater risk than any individual change.
So, if you have a policy, follow it: You don't need to ask the question because the answer is in the policy.
If you don't have a policy, get one in place before something bad happens: The question is not ready to be asked.
jg
October 10, 2005 at 2:29 pm
I asked because there are certain situations where regression testing may not be necessary. Many companies are willing to apply an OS hot fix without regression testing their applications. The thought being the risk is too small to justify the resource cost. Since I am unfamiliar with the underlying code used in Windows 2003, I was curious how much of a risk exists moving from Windows Server 2002 to 2003. With Windows 2000, for example, the base code was taken from Windows NT technology. In theory if you had a dedicated database server (no IIS or other software) and you kept the configurations identical (FAT, NTFS, timezone, etc...) an upgrade would have no impact on SQL Server. I've been involved with a number of NT to 2000 upgrades for database servers and not one yielded a problem.
We decided in this case the risk was too great to not test the new OS and our server is currently being prepared for the developers to begin testing. I guess a good rule-of-thumb would be if it comes from Microsoft, test it.
Thanks, Dave
October 10, 2005 at 3:15 pm
There are 2 kinds of applications: home-grown and vendor's
For the home-grown applications you would know the technologies that are used: ASP or ASP.NET, VB, C++, C##, MS ACCESS , SQL Server, Excel, Java, WebLogic... you name it. So you have to find out if your technology is compatible with and supported on Windows 2003 server
For vendor's applications you have to find out from the vendor what are the supported platforms.
That is in addition to testing.
Just to name a few, you may have issues with IIS6 if it is a web app. IIS6 is implemented differently then IIS5 on the kernel level. You may also have issues with Distributed Transactions in SQL Server. Additionally a lot of things are configured differently in Windows 2003 server by default so you may need to make configuration changes for things to work. Directories named differently, task scheduler log changed its location. I have a machine that was upgraded to Windows 2003 from Windows 2000 right after the initial OS install, the system directory there is WINNT, I am not sure if WINNT was kept during the upgrade by the upgrade process or the system engineer helped it, but for the fresh install the system folder called Windows. Which may lead to the application problem if it uses explicit hardcoded paths.
Yelena
Regards,Yelena Varsha
October 11, 2005 at 8:52 am
Thanks for your input. We found the MSDTC issue in a Q article. As soon as we saw it we decided testing was necessary. I appreciate your help.
Dave
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply