You shouldn't have to delete any subscribers. In order to do so you'll have to go through a lot of pain removing them from CM groups, etc.
What you want to do will save time assuming everything works perfectly and no phone touches the new cluster until all the subs are installed and replication is 100% ok. Off the top of my head you will lose: - Any firmware, ringlists, or other TFTP files on your subs. - Any custom MOH files on your subs - All certificates on the subs. If any one of those things is important enough for your customer that it can't go wrong then take the time to do the full documented jump procedure. -Ryan On Feb 11, 2014, at 8:39 PM, Bill Talley <btal...@gmail.com<mailto:btal...@gmail.com>> wrote: In other words, you're saying delete the subscriber BEFORE upgrading? i.e. move the pub to an isolated network, delete the sub, upgrade, backup, install new instance to align partitions, restore pub, add new sub to cluster, etc etc etc? Sent from an Apple iOS touchscreen device with very tiny touchscreen input keys. Please excude my typtos. On Feb 11, 2014, at 7:25 PM, Matthew Loraditch <mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>> wrote: Ted What you want to do with rebuild the sub is technically unsupported. I have done it myself and it seems to work ok as long as you remember custom tftp files and moh. However there are a lot of other possible gotchas that I heard straight from one of the BU folks during a session when they introduced Jump. Supposedly they were working on documenting the steps necessary to avoid these issues but I have heard of no progress. The gotchas mostly involved things having to do with service activation. I will try to see if I can find the recorded session tomorrow. Sent from my iPad On Feb 11, 2014, at 7:13 PM, "Ted Nugent" <tednugen...@gmail.com<mailto:tednugen...@gmail.com>> wrote: I have a similar upgrade coming up next week.. 7.1.5 to 9.1.2 MCS to B200 M3 blades. Only question I really have is... are there any potential issues with just restoring the PUB and rebuilding the SUB from scratch, other than TFTP files etc? We're having to do it in production without an official maintenance window because it's a hospital with allot of moving parts. The idea is to take down the PUB, build the PUB on the same IP, restore just the PUB and then upgrade. Failover to the new PUB and rebuild the Sub from scratch, move over the MOH files etc. Thoughts one that? BTW.. thanks for updating on your progress Lelio, very helpful in seeing the gotcha I've not hit previously. On Tue, Feb 11, 2014 at 4:59 PM, Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: lol. thanks Matthew. I think I'm going to have to engage our partner for an official answer this week, while I try out some scenarios. Bottom line is, if Cisco isn't going to officially support this or help out, then I have to go to management and let them know, and they can raise the roof. ;) It would be nice to at least get a "no, sorry, the COP refresh file does not properly disable upgrade restrictions on MCS hardware" - or something like that. I can't believe I'm the only one out here that doesn't have the money to go to VM just yet, and has enough hardware to do an off-line install with supported hardware. I guess if the supported way to is to get licenses rehosted, than I'm OK with that, as long as our partner will support us when the requests go to licensing. Interestingly enough, I was reading the main page (https://supportforums.cisco.com/docs/DOC-35163) and found the following bug listed there (https://tools.cisco.com/bugsearch/bug/CSCtb86875) which states that I need install the license after the DRS restore. So this would make the correct order: 1. install v7 2. install COP/refresh 3. do DRS 4. reboot servers 5. perform dbreplicate fixes if required 6. upload license 7. perform upgrades We'll have to see how my next test goes. Funny thing is, the license reporting page shows no problem with the licenses. Weird. Oh well, tomorrow's another day. --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354<tel:519%E2%80%90824%E2%80%904120%20Ext%2056354> le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 ________________________________ From: "Matthew Loraditch" <mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>> To: "Lelio Fulgenzi" <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> Cc: "cisco-voip" <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> Sent: Tuesday, February 11, 2014 4:37:50 PM Subject: RE: [cisco-voip] Upgrades prohibited... *sigh* Yes you are technically correct about the refresh file. The original version was designed to allow the OS upgrades that happened with <8.6 to 8.6+. They then added the removal of the license check with v1.2 and 1.3 of the refresh solely for the Jump upgrade. So yes you will need the refresh file to install 9.1.2 but you won’t have to deal with the licensing crud if you rehost. The jump upgrade is the recommended path because VMWare is the recommended path what you are doing is what every cisco partner, TAC and sales employee doesn’t want you to do, but technically still supports. We all still love you Lelio, but I know the PM in charge of the OS stuff and he’d cringe knowing you were doing this :) I would install your licenses before the refresh file but I’d guess it won’t matter. <image001.jpg> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518<tel:443.541.1518> fax. 410.252.9284<tel:410.252.9284> Twitter<http://twitter.com/heliontech> | Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> | Website<http://www.heliontechnologies.com/> | Email Support<mailto:supp...@heliontechnologies.com?subject=Technical%20Support%20Request> Support Phone. 410.252.8830<tel:410.252.8830> <image002.png> From: Lelio Fulgenzi [mailto:le...@uoguelph.ca<mailto:le...@uoguelph.ca>] Sent: Tuesday, February 11, 2014 4:17 PM To: Matthew Loraditch Cc: cisco-voip Subject: Re: [cisco-voip] Upgrades prohibited... *sigh* Hi Matthew, re-hosting licenses is definitely an option. I wanted to make sure that this path _didn't_ work first, because it is the recommended/advertised approach. I'm lucky in that I already have the licenses for my test cluster which match this isolated publisher MAC, since they were issued on this isolated pub first, and I rehosted to another one due to some issues. For my production cluster, it means rehosting to the isolated pub MAC and going forward. Your comment regarding "the only reason you need the refresh file is because 6.1 and 7.1 can’t read licenses when running on VMWare" is interesting because according to the readme file, it's for more than that. In fact, it doesn't mention licensing at all. The refresh upgrade COP file delivers changes to the user experience on the CLI and GUI that are related to a refresh upgrade, and basic functionality needed to support refresh upgrades. Refresh upgrade is a new feature in 8.6(x) that allows upgrades between incompatible OS versions. The question then becomes, at what point do I install the license files, before or after the COP_refresh file? Lelio --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 ________________________________ From: "Matthew Loraditch" <mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>> To: "Lelio Fulgenzi" <le...@uoguelph.ca<mailto:le...@uoguelph.ca>>, "cisco-voip" <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> Sent: Tuesday, February 11, 2014 3:42:06 PM Subject: RE: [cisco-voip] Upgrades prohibited... *sigh* Just being devil’s advocate but since you aren’t going to VM, why don’t you just rehost the license files. It seems like you may have spent more time trying to JUMP when the only reason you need the refresh file is because 6.1 and 7.1 can’t read licenses when running on VMWare. You can do that once and since it’s hardware the MAC isn’t going to change no matter how many times you have to run through the install. Seems easier to open that case once and wait a few hours for rehosted licenses. <image001.jpg> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518<tel:443.541.1518> fax. 410.252.9284<tel:410.252.9284> Twitter<http://twitter.com/heliontech> | Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> | Website<http://www.heliontechnologies.com/> | Email Support<mailto:supp...@heliontechnologies.com?subject=Technical%20Support%20Request> Support Phone. 410.252.8830<tel:410.252.8830> <image002.png> From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Lelio Fulgenzi Sent: Tuesday, February 11, 2014 3:34 PM To: cisco-voip Subject: [cisco-voip] Upgrades prohibited... *sigh* OK, so, I've attempted the upgrade from v7.1(5b)SU3 to v9.1(2)SU1 and I've got the dreaded "upgrades prohibited during license grace period" error. *big sigh* I'm using this as a resource: https://supportforums.cisco.com/servlet/JiveServlet/download/35163-6-15369435/Drive_to_Nine_Jump_upgrade_versions_4.1.3-7.1.5_to_9.1.2-3%5B1%5D.pdf Some comments: * I am not recreating my cluster on VM ware, I am using supported MCS servers * I installed 7.1(5b)SU3 via a "install with patch" process, using 7.1(3a) media * I installed the the v1.3 COP refresh file next and did NOT reboot the cluster * I performed a DRS restore and recovered first the publisher, then the subscriber * I rebooted the subscriber first, then the publisher * Performed dbreplication recovery (with an unfortunate reboot in the middle) I guess the biggest question is whether or not the COP refresh files disables the licenses restrictions on MCS servers or not. Or whether I should attempt this again, or call the TAC for them to allow upgrades via root. I'm on an isolated network, so it means some fancy routing on a laptop if the TAC is necessary. Suggestions? Lelio --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto: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
