Two Unitys, Primary and Failover. During the course of the day, Unity 1 is accidently unplugged from the network. Unity 2 takes over answering calls as expected. Unity 1 thinks it is still running but has not network connection. Before the problem is fixed a user logs into Unity and makes a change that is stored in the SQL database. (i.e. primary greeting, password change). When the ethernet is plugged back into Unity 1 is forces Unity 2 to become inactive and start answering calls again.
Something that I have noticed is that changes users make during this type of scenario. The Unity 2 database changes are not pushed to Unity 1. In fact if a user had recorded a new greeting. When Unity 1 is restored, the user greeting is defaulted to a system greeting. The only way to corrected to problem is to stop and restart the Unity service on Unity 1.
Should the database changes on Unity 2 be pushed to Unity 1? this is not a big problem for me. Just something I noticed during failover testing.
Failover in Unity 3.1.x supports two way SQL replication and changes made on the secondary server are pushed to the primary server. When the primary server comes back online, the new greeting file name that was recorded on the secondary server is pushed to the primary server's database. However, the actual greeting itself might take upto 10 minutes to replicate to the primary server since the default file replication interval is 10 minutes. So, within that 10 minutes, susbcribers on the primary server will hear the system greeting.
By the way, there were defects in 3.1.2 and 3.1.3 which would lead to recordings/prompts getting deleted during network outages that have been fixed in 3.1.4 and later versions of Unity.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.