You might want to follow some of the two suggestions below
Primary UCM replacement:
a. If a backup archive of old Primary is available (aka sysbackup), then restore operation on new Primary UCM should restore all Linux Base system settings, UCM data (security configuration, element registry, deployment views, etc), application data.
There is no need to re-join any members or backup servers to sec domain because sec domain is not changed.
Application deployment and a patch deployment is needed on the Primary UCM.
Note: The FQDN of the new Primary server must be the same as what was previously used.
b. If there is no sysbackup data available, then new Primary UCM can only be reinstalled from scratch: Linux Base system settings, security configuration, all members and backup servers should be re-joined to sec domain, deployment view, deploy of applications, configuration of applications, patch deployment…
What needs to be done on Backup UCM in case of Primary UCM replacement:
a. If Primary UCM is restored from backup archive, no action for existing backup server is required (there is no change in security domain).
Note: If IP address of Primary server changes, then the new IP address must be known to all the existing backup security servers and member servers.
b. If Primary UCM is reinstalled from scratch (not restored), then security domain is changed and existing backup server should be either demoted to a member server in the new domain (this operation is supported starting from Rls 7.0) or re-installed from scratch and re-joined as a backup server.
So, existing backup server cannot be simply re-configured to new security domain.
Note: backup server application data can be restored by 'sysrestore --deployed_apps' (restore only the 'Deployed Application' (ie. Non-Base Apps) information).
See Unified Communications Management Common Services Fundamentals, NN43001-116
Making changes on a member server
Important:
The primary and backup server cannot be reconfigured.
Demoting a primary and backup server
The UCM primary and backup security server can be demoted to a member server in a new domain. The security domain of the demoted primary server is no longer valid so the existing backup server must also be demoted to a member server in the new domain.
What needs to be done on Member UCM in case of Primary UCM replacement:
a. If Primary UCM is restored from backup archive, no action for existing member server is required (there is no change in security domain).
Note: If IP address of Primary server changes, then the new IP address must be known to all the existing backup security servers and member servers.
b. If Primary UCM is reinstalled from scratch (not restored), then existing member server should be simply re-joined to a new domain.
More info can be found in
- Avaya Linux Platform Base and Applications Installation and Commissioning, NN43001-315
- Unified Communications Management Common Services Fundamentals, NN43001-116
########################################################
CS1000 rls 6: Security Domain registration failures
Avaya has identified a condition that can cause Security domain registrations to fail from the CS 1000 Call Server along with SFTP failures.
This condition may exist when MPLR30184 is installed on the call server and can trigger a flag to be set incorrectly thus causing the domain registration failures.
The condition has been addressed by removing MPLR30184, and installing the replacement patch, MPLR30845.
MPLR30184 was Released and added to the DepList as of September 20, 2010. MPLR30184 is set to OBE category and has been removed from the Release 6.0 Dependency List as of April 14th, 2011. MPLR30845 is set to Released status and added to the Dependency Lists as of April 14th, 2011 to replace MPLR30184.
If you are seeing the condition where SFTP is failing (per details noted below), you will need to do a REG UCM SYS after MPLR30845 is activated
The problem will happen under the following conditions:
1). Both patches (MPLR28935 and MPLR30184) are activated on the Call Server.
2) Secure transfers are turned ON on the Call Server.
3) Performing a 'REG UCM SYS' (register UCM system) from ld 117 to register the call server and MGCs with the security system.
These steps will result with the MGC to be unable to perform an SFTP to the Call Server, and so every attempt to obtain the mgcdb.xml file from the Call Server via SFTP will fail. This will cause an outage on the MGC until the situation can be corrected.
A restart of the Call Server will resolve the issue, but only until the next time a 'REG UCM SYS' is performed.
It is recommended to install MPLR30845 before registering the Call Server and associated elements via 'reg ucm sys' from overlay 117 (ld 117). MGC loadware MGCCAP02 or later should also be in service.
mplr30845 is now superseded by mplr31378
Firebird Scrambler
Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer
Website =
