Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: mduran22 on July 06, 2009, 08:23:50 PM
-
Hi all,
We are refreshing the servers on which Genesys production apps run, and I figure that there have been a few of you that have gone through this before and wanted to hear all of the tips, tricks, and lessons learned from others experiences.
To be sure we don't introduce any new Unannounced Genesys Features (UGF's), otherwise known as bugs, we are going to keep the application versions exactly the same.
The database(s) will all remain the same as well, so this is only a Hardware/OS upgrade. All of the servers will be running Windows Server 2003 Service Pack 2. We will be using name aliases for 3rd party clients.
We are contemplating whether it is better to migrate the same apps to new hosts or create new apps for the new hosts, or modify the existing hosts with the new IP's.
Any thoughts or experiences with this would be appreciated.
Mike
-
Hi there, Mike!
Do u plan process with minimal complete downtime or u can shutdown u solution for this job done?
For me - better plan the downtime window that provide to u match enough time for shutdown old servers, install Genesys App at the new hosts with same name and ip address's and start solution again.
WBR Timur Karimov
-
We upgraded the OS and cluster software on one of our platforms. We created a temporary server whilst the mian cluster was down. But the basic steps would be similar to what you are trying to do.
Create the database server, and if you run Config Server on it load that too. Ensure it is working and you can connect via CME.
Organise a data freeze, so that the active config database is not changed.
Copy the config database data, onto you new server and test that it looks OK.
Overnight or at a weekend, switch all your apps to point to the new server - if you are using DNS this is made easier.
Test again and stop the old server.
Lift the data freeze.
You can then go through a similar process with the other servers.
-
Hi,
we've process similar migration few months ago by following steps:
- new db tablespaces has been created - really new one for cfg db and tempory for log, ods, dm
- we arranged with customer freeze of cfg db (they didn't keep it but is is other story)
- cfg db has been migrated by Conversion Wizard to new instance
- we migrate apps to new hosts and provide all necessary tests
- in day D we've stop old environment and in new environment switched DAPs and other db links to production database (except for the cfg)
Pavel