Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Element Manager - Can't Save Node Properties

Status
Not open for further replies.

wiredawg_cst

Technical User
Nov 8, 2016
7
0
0
US
I’m getting an error when I try save and transfer the node properties in Element Manager. “The node cannot be saved with the current configuration. Server with hostname sigserv0 does not exist in security domain of CS1000 system”. This was after a signaling server rebuild… Call server is joined, VGMC registered, synced and sig server synced. Maybe I missed something. Release is 7.65.
 
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 =
 
You will more than likely need to redeploy that SS
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top