Monday, January 11, 2016

Windows server environment for the setup, testing and putting 3rd party server apps into production

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.

No comments:

Post a Comment

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...