<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That’s how we do it. During your import of your lab ucs build you should change the ip address so you can do a parallel install. This is our path usually if
it can be done over a weekend and depending on how many remote locations on the cluster you could make the changes on each gw one at a time. This way you can have a back-out plan with little downtime.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Check the firmware upgrade path but you should be fine at your current level os.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1F497D">Gregory Wenzel<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1F497D">Solution Engineer, CCNP Voice<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1F497D">Continental Resources Inc<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net]
<b>On Behalf Of </b>Ryan Hitch<br>
<b>Sent:</b> Friday, May 04, 2012 4:54 PM<br>
<b>To:</b> cisco-voip@puck.nether.net<br>
<b>Subject:</b> [cisco-voip] CUCM Bridge Upgrade Question 7.1 to 8.6<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div id="yiv1134542064">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">I am planning an upgrade for a (3) node 7835-H1 cluster running 7.1(5)SU2 to a (3) node cluster running 8.6(2)a on VMs.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">Since these servers only support a bridged upgrade I was wondering if I could do the following to reduce the risk and amount of downtime required for the extended "refresh" upgrade.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">1. Install 7.1(5)SU2 on a 7845-H2 lab server<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">2. Perform a DRS restore on this lab server from the production 7.1(5) publisher<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">3. Upgrade the lab server to 8.6(2)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">4. Perform a DRS backup of 8.6(2)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">5. Restore the DRS backup on 8.6(2) Publisher VM (pre-built in an isolated environment using the same IP address).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">6. Build Subscriber VMs in isolated lab environment using the same IP addresses.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">7. Switch routing from the production environment to the pre-built lab environment.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">I find this very appealing since our original cluster will still be running untouched in case we have to switch back.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">Any concerns with this "modified bridge" approach?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">The only concern that I see is that the subscribers will not be connected to the lab publisher server when I do the upgrade from 7.1 to 8.6.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">Is that going to be an issue? Any other concerns?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">I see a few posts with similar questions, but I just want to be clear about the subscriber portion.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">I do not think that the disconnected subscribers should matter, but would love to hear from someone who has used this method.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="color:black">Ryan<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>This message w/attachments (message) is solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any products.
</body>
</html>