This is the bug and is very useful as it contains the resolution
(requires root): https://tools.cisco.com/bugsearch/bug/CSCta76014
Here is the process for physical to physical the process should be the
same as replacing a CUC pub/sub from the CUC docs. If you go the VM
route you will need a version of ESXi that allows you to change the MAC
of the NIC (there are updates that permit this around 5.1 I think) and
the ability to change the license MAC on CUC (this is only temporary and
not needed once licenses are migrated to ELM/PLM) assuming licensing is
still unable/willing to issue compatible 7.x licenses for VMware. As
long as the license MAC and vNIC match it should work.
YMMV, be sure to completely test before attempting. Especially in a VM
environment as this is very unlikely to be supported by TAC.
On the existing system replace the publisher:
cluster management:
1. make <CUC Subscriber> the primary node
2. stop taking calls on <CUC Publisher>
3. deactivate <CUC Publisher>
remove the original pub from service (shutdown the port)
Install the replacement pub, using EXACTLY the same info as the old:
hostname: <CUC Publisher>
IP: _____________
Mask: _____________
GW: _____________
Primary DNS: _____________
Secondary DNS: _____________
Domain: _____________
platform: user: _____________ pass: _____________
SSL:
Org: _____________
Unit: _____________
Loc: _____________
State: _____________
County: _____________
first node in cluster: Yes
NTP: _____________
Security Password: _____________
SMTP location: _____________
Application username: _____________
Application password: _____________
Installed time is ~2 hours to reach CLI on VM
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ensure you have license files that are valid for CUC
If running on physical hardware you will need licensing to issue these
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Apply license file on pub.
Add sub to pub:
System Settings --> Cluster --> Add New
Hostname/IP Address: <IP of Subscriber>
Description: <CUC Subscriber>
Save.
Signout of cuadmin on pub.
On subscriber run: utils cuc cluster renegotiate
publisher will reboot once this is completed (~90 - ~120 minutes on VM,
time depends on voicemail store size)
show cuc cluster status: will show <CUC Publisher> idle.
Activate the pub in Cluster Management.
Database will sync. Once database is sync'd promote the publisher to
primary.
Verify license is applied on both pub and sub
The process is similar for the sub, the CUC docs should be enough for
that.
On 2015-04-23 09:22, Rasim Duric wrote:
Thank you Gentoo. This is very useful. Our plan is to test and perform
the upgrades in an off-line network. Once all is done, shut-down the
existing v7.x servers and re-connect the upgraded v9.x servers
on-line. In this case we would have a short downtime.
It would be great if you could find more about the bug and write up
some generic instructions.
Thanks again.
Rasim Duric
Network analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph
519-824-4120 Ext 53146
rdu...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
----- Original Message -----
From: gen...@ucpenguin.com
To: cisco-voip@puck.nether.net
Sent: Thursday, 23 April, 2015 8:59:38 AM
Subject: Re: [cisco-voip] Unity Connection upgrade from 7.1(3) to
9.1(2)
Its also possible to do this without COBRAS or DRS.
Basically you just replace each node one at a time on the current
version but running on the new HW.
Once you have the current version running on the new hardware you
upgrade as usual. (Don't forget to get your 7.x licenses ahead of time
for the new HW)
Its possible that you will encounter a bug in 7.x when doing this that
will prevent you from adding new users. There are Informix commands
that are run to resolve this (just be sure to test that you can add new
users). I believe root access (or TAC) is required to correct this.
At
one time the instructions were published on CCO.
This provides a seamless upgrade as there is always a CUC node in
service that can answer calls and large message stores don't have to be
manually migrated (they are migrated as part of the initial install
from
the production node).
I can probably did up some generic almost step by step instructions and
the fix for the creating new users if this is something you are
interested in.
Its also possible to do this direct to VM, though you will need root
access (only to change license mac to from virtual MAC to physical) and
won't have TAC support while running 7.x on VM. Also, once you reach
9.x your partitions will be unaligned and a 9x VM to 9x VM migration
would be required to correct this.
Not saying this is the right option in your case, but it does work.
On 2015-04-21 15:55, Rasim Duric wrote:
Thank you James. I can conclude that the statement from the document
refers to COBRAS. I'll be using DRS so shouldn't be concerned.
Rasim Duric
Network analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph
519-824-4120 Ext 53146
rdu...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
-------------------------
FROM: "James Avalos" <java...@adobe.com>
TO: "Rasim Duric" <rdu...@uoguelph.ca>, "voip puck"
<cisco-voip@puck.nether.net>
SENT: Tuesday, 21 April, 2015 4:31:11 PM
SUBJECT: RE: [cisco-voip] Unity Connection upgrade from 7.1(3) to
9.1(2)
Rasim,
I did an upgrade from Unity 7 to Unity Connection 9.1.2 a couple years
back, and I think I know what you mean.
For my upgrades, I wanted to build Unity CxN in parallel with my
production Unity 7, so that I could do a migration at my chosen pace.
For this I went with COBRAS. It’s been a while, but I don’t
remember whether or not this jump allowed for a backup and restore
type of upgrade.
But it sounds like that’s your plan of attack.
For COBRAS export from Unity, use breifcase mode. This does not
require network path from source and target server.
also, does not make any changes to source sever the way "hot mode"
does.
For what its worth, here’s some information on what COBRAS gets you
for this type of upgrade. In case you change your mind…
COBRAS gets most data for the following parameters:
Call Handlers
Subscribers
Interview Handlers
Directory Handlers (will be called Name Loop Handlers in UC)
Public Distribution Lists
Schedules
Routing Rules (typically recommending for restores only, not
migrations)
Custom Key Mapping Coversation Data (UC to UC restores only)
COBRAS DOES NOT get data for the follwoing:
Class of Service
Restriction tables
Locations
Contacts ( SMTP/AMIS/Bridge/VPIM subscribers)
Holidays
Sys Config Data ( LDAP integration, IMAP login, RSA config, Advanced
settings, etc.)
Subscriber Templates
Call Handler Templates
Password policy information
Securty messages from older UC revs.
- J
FROM: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] ON BEHALF
OF Rasim Duric
SENT: Tuesday, April 21, 2015 12:56 PM
TO: voip puck
SUBJECT: [cisco-voip] Unity Connection upgrade from 7.1(3) to 9.1(2)
Hello everyone,
I'm planning to upgrade our two Unity Connection servers 7.1(3)ES11 to
9.1(2)SU3. In the Cisco document at this
URL:http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/requirements/9xcucsysreqs.pdf
[1], page 30, you can read the following:
_DURING THE MIGRATION, ONLY USER DATA AND, OPTIONALLY, VOICE MESSAGES
ARE PRESERVED. SYSTEM-LEVEL CONFIGURATION DATA (FOR EXAMPLE, TEMPLATES
AND CLASSES OF SERVICE) MUST BE MANUALLY CONFIGURED._
I'm migrating CUC 7.1(3)ES11 from one physical server to another
physical server (compatible with 9.1(2)SU3 specs). The plan is to
install 7.1(3) from scratch on the new server and then restore the old
server via DRS. After the 7.1(3) is up and running on the new server,
perform the 9.1.(3)SU3 upgrade. I think all data should be preserved
including the templates, the Class of Services, etc. in my case.
When would someone actually experience the above statement from the
Cisco document? What else is not preserved?
If anyone has done a similar upgrade, I'd like to hear any tips and
tricks or issues you ran into.
Thanks.
Rasim Duric
Network analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph
519-824-4120 Ext 53146
rdu...@uoguelph.ca
www.uoguelph.ca/ccs [2]
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
Links:
------
[1]
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/requirements/9xcucsysreqs.pdf
[2] http://www.uoguelph.ca/ccs
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
