Upgrade Call Manager from 8.5(1) to 10.5(1) and migrate from MCS to UCS...
We are upgrading UCM from 8.5(1) to 10.5(1) and migrating from MCS to UCS. We used UCM 8.5 OVA (7500 user) and migrated to UCS.
Once migrated to UCS we upgraded UCM to 10.5(1). We wanted to use OVA to accommodate 10,000 users, hence took backup of 10.5(1) cluster and installed new servers with new 10.5(1) OVA (10,000 users).
While doing DRS restore, system we were not able to perform a restore. It seems UCM is not recognizing the XML file. It is strange as we took the back from UCM 10.5(1) and trying to restore same version, only difference is upgrade was done with 7500 user OVA and we are now trying to install 10,000 user OVA.
Has anyone run into similar issue? any help will be great.
I am not aware of any issues in restoring the backup from a cucm running on different ova. Can you check / try the following:
1. The backup tar file ( does it have all the drs components present )
2. The IP address, hostname, deployment type, security password etc are the same in both the clusters ( the one backed up and the one on which it is to be restored ), apart from the cucm versions being exactly the same.
3. Restart the DRF MA and LA services on all the nodes.
4. If possible, try taking a new backup from the old cluster and restore it on the new one.
This thread is 5 months old but doesn't seem resolved...
I ran into this same scenario last week. Was using the same SFTP server for backups and restores during migration from 7.1(5) to 10.5 and during final rebuild/restore of the "to-be" production 10.5 Publisher, the DRS server was unresponsive and blamed the Master Agent or SFTP server. I had restarted Master and Local agent repeatedly, and regenerated ipsec certs to no avail.
TAC suggested I try a different SFTP server (which I already had, with the same files), and try deleting the .xml files that were included with the backup (drfComponent.xml and processhost.xml). I installed TitanFTP, per TAC's recommendation, deleted the processhost.xml file, regenerated the ipsec certificate one last time, restarted DRF Master, and then DRF Agent, and was able to start a DRS Restore.
Try the above process if you're still having issues.
I resolved my issue, it was a mismatch on hostname of virtual machine, i didnt realise that the hostname of machine i am restoring on is not same..in my case the DRS was not at all being recongnized.. once i matched the hostname it worked however i am running into another isse where CAR fails during restore because of some stupid sftp error but that is diffrent issue
Result Code : 110-Unable to transfer the tar file over SFTP channel as currently configured SFTP server does not support input stream
Hi, I am running into same issue, i upgraded CM from 7.x to 10.5 using OVA 8.5 ( the system errors about unaligned partition which is understood ), and my plan was to backup it and restore on a brand new VM using OVA of 10.5 but newly built VM cannot recognize DRS files, i powered off 10.x VM and updated RAM,vCPU to match with existing VM but no change.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...