[cisco-voip] Unity Connection upgrade from 7.1(3) to 9.1(2)

Thu Apr 23 15:17:03 EDT 2015

Oh, I missed that part completely.

On 2015-04-23 13:50, Rasim Duric wrote:
> Thank you again Gentoo. There is a slight miscommunication here, my
> two servers are not in a Unity Connection cluster. These are
> independent servers, a CUC digital networking is established though.  
> 
> Rasim Duric
> Network analyst, Network Infrastructure
> Computing and Communications Services (CCS)
> University of Guelph
> 
> 519-824-4120 Ext 53146
> rduric at uoguelph.ca
> www.uoguelph.ca/ccs
> Room 037, Animal Science and Nutrition Building
> Guelph, Ontario, N1G 2W1
> 
> 
> 
> ----- Original Message -----
> From: gentoo at ucpenguin.com
> To: "Rasim Duric" <rduric at uoguelph.ca>
> Cc: cisco-voip at puck.nether.net
> Sent: Thursday, 23 April, 2015 2:32:07 PM
> Subject: Re: [cisco-voip] Unity Connection upgrade from 7.1(3) to 
> 9.1(2)
> 
> 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
>> rduric at uoguelph.ca
>> www.uoguelph.ca/ccs
>> Room 037, Animal Science and Nutrition Building
>> Guelph, Ontario, N1G 2W1
>> 
>> 
>> 
>> ----- Original Message -----
>> From: gentoo at ucpenguin.com
>> To: cisco-voip at 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
>>> rduric at uoguelph.ca
>>> www.uoguelph.ca/ccs
>>> Room 037, Animal Science and Nutrition Building
>>> Guelph, Ontario, N1G 2W1
>>> 
>>> -------------------------
>>> 
>>> FROM: "James Avalos" <javalos at adobe.com>
>>> TO: "Rasim Duric" <rduric at uoguelph.ca>, "voip puck"
>>> <cisco-voip at 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-bounces at 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
>>>  rduric at 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 at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip