0

Our company uses several 3rd-party server applications (Installed as services and desktops have client applications) installed on Windows Servers (virtual) along with SQL Server. All of this is under the same domain (Maybe that's the problem?). Each application has its own way (config files and database entries) of managing the typical settings: server names, database names, accounts services run under, etc.

Here is a typical upgrade scenario:

  1. Current System with former version is maintained. Name: Current
  2. Test server is created (often upgrade operating system from 2003 to 2008) and new version of application is installed from scratch, configured and tested. Name: Test
  3. New production server is created, the new system is installed and configured (Hopefully the same as test.). Name: New ** all of these systems are all running simultaneously and continue to be used. Current will eventually be removed, but not until we know the New system is running and we don't need to see how "the old system worked".

Problems:

  1. We have to leave the Current system in tact, because we never know when we have to refer to it for various settings or keep it in production when the new system blows up. Even if we install the former version and perform upgrades, configurations are lost. I'm not just referring to server names but other settings as well.
  2. Configuration files cannot just be copied from one server to another because server names are different.
  3. Many of these applications have several components that run as different services and all have their own configurations. i.e there's more than one configuration.
  4. We don't have anyone in our company that was there when the original apps were installed and configured and they left no documentation.
  5. Many of the companies we deal with cannot give us complete answers on how upgrades will affect configuration settings and rely on "just see what breaks and try to fix it" approach.

How can we create test environments where the test servers and databases have the same names so we don't have these conflicts? Do we need separate domains? Does that present other problems and limitations like trying to copy files from one domain to another? Shouldn't renaming virtual servers be easy?

Sorry, network administration is not my area of expertise. I'm hoping to shed some light for those in our company that are making these decisions.

1

What I used to do in a similar situation (academic environment, five campuses, five servers running the same product which were all based on SQL Server):

First step, which is roughly analogous to your test environment: Get a VM (can be VMware workstation at this point) and practice the upgrade on it, and document everything. That should help you figure out which config items you need to save and copy, and will also teach you how to change the server name. ;) Then get a new VM and do it again. If you get new horrible errors, get a new VM and practice a third time. Keep doing this until it's not horrible, or at least until you feel relatively confident about upgrading prod. (Note: Often the DB name and DB server name is stored in the registry. If you're copying a registry key over, look for that to make sure you don't prematurely upgrade prod's DB. Similarly, you might need to change this value after you change the server name.)

Then, during scheduled down time, the actual upgrade of [oldname], during which I would:

  • Save any config items I knew about in advance (in one case, registry keys with regexp values in them and a text config file, for example).
  • Get my shiny new VM. Name it [oldname]-new.
  • Install SQL.
  • Attach the old database (copy the files [productdbname].mdf and [productdbname].ldf to the new server and use the "attach database" command--SQL must be stopped on the old server to do this, which means you need to stop the [productname] service, too).
  • Copy any other required files (those registry keys/text files)
  • Run the installer, which will generally detect the database and offer to upgrade the database for you (Yay!)
  • Rename the old server [oldname]-old and give it the new IP number.
  • Rename the new server [oldname] and give it [oldname]'s IP number.

The first upgrade is sometimes rough, even with practice. By the fifth, you're an old pro and it's easy. Take notes of any problems and how you fixed them.

As for those config items, they're usually in the registry under HKLM/Software/[product or vendor name] or in the program files directory, but not always. There was one vendor that had things in an odd path (although it was referred to in the registry) and a text file that had to be copied to c:\windows\system32 for the software to find it (encryption settings). Alas, you won't find those until you try (and maybe call the vendor for the last one, sigh).

Good luck!

  • Ideally, I'd like to setup Test and copy to the New server once it is working. – JeffO Apr 4 '14 at 14:51
  • Perhaps, but that's two installs and testings instead of one. I mean, obviously, they're your servers and you should do them any way you like, but I'm just saying. – Katherine Villyard Apr 4 '14 at 14:55
  • I need two instances of the new version: Test (we would use this to test any small patches, customizations, etc. going forward) and New which would go into production. We use VM for all servers; thought that would make this whole thing easier. – JeffO Apr 4 '14 at 16:44
  • That's fine. In my case, I would have one test instance rather than five, however. – Katherine Villyard Apr 4 '14 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.