If the physical hardware (and therefore MAC) address changes, you&#39;ll need to engage TAC to re-host your license.<br><br>This begs the question - why would it take a week of downtime?  Even if you do a publisher rebuild and restore, it should take 24 hours top and that&#39;s including getting new hardware from Cisco provided you&#39;re in a moderately serviced area.  If you&#39;re not in a moderately serviced area, I have two questions.  1) why is the callmanager publisher not in an area where proper hardware replacement coverage can be guaranteed and/or 2) why is an on-site spare not there for a cluster servicing 30K+ phones.  Just some thoughts...<br>
<br clear="all">Matthew Saskin<br><a href="mailto:msaskin@gmail.com">msaskin@gmail.com</a><br>203-253-9571<br><br>July 18, 2010 - 1500m swim (in the hudson), 40k bike, 10k run<br>Please support the Leukemia &amp; Lyphoma Society<br>
<a href="http://pages.teamintraining.org/nyc/nyctri10/msaskin">http://pages.teamintraining.org/nyc/nyctri10/msaskin</a><br>
<br><br><div class="gmail_quote">On Thu, Jul 1, 2010 at 10:43 AM, Andrius Kislas <span dir="ltr">&lt;<a href="mailto:andrius-conf@kislas.lt">andrius-conf@kislas.lt</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why would I need to involve TAC? I haven&#39;t done publisher restoration<br>
process, but reading Desister Recovery doc I haven&#39;t noticed any notes<br>
ragarding MAC address change. So I am guessing restoration procedure<br>
from backups will take care of new MAC, won&#39;t it?<br>
<br>
Also I do agree this is a already redundant system from call processing<br>
perspective, but imagine 60K mega cluster and not being able to make any<br>
changes for a week (that&#39;s without publisher). So I am adressing exactly<br>
this situation.<br>
<font color="#888888"><br>
Andrius<br>
</font><div><div></div><div class="h5"><br>
On 2010.07.01 16:59, Eric Butcher wrote:<br>
&gt; The cost / benefit analysis of this is a pretty hard sell, but if you&#39;re looking to squeeze that last bit of redundancy out of an already very redundant phone system...  It can be done.  Not as simple as plugging it in, powering it up, and loading licenses though.  There would need to be a tac case involved anyway.<br>

&gt;<br>
&gt;<br>
&gt; Eric Butcher<br>
&gt; Cisco Unified Communications Engineer<br>
&gt; CDW Professional Services<br>
&gt; 11711 N Meridian, Ste 225<br>
&gt; Carmel, IN  46032<br>
&gt; C 317.569.4282 - IP Phone<br>
&gt;   765.744.1458 - Mobile<br>
&gt;   <a href="mailto:eric.butcher@cdw.com">eric.butcher@cdw.com</a><br>
&gt; <a href="http://www.cdw.com" target="_blank">www.cdw.com</a><br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Ryan Ratliff<br>

&gt; Sent: Thursday, July 01, 2010 9:28 AM<br>
&gt; To: Bill<br>
&gt; Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
&gt; Subject: Re: [cisco-voip] Standby publisher<br>
&gt;<br>
&gt; No you can&#39;t.  All database changes can only be made to the publisher.  This changes a bit in 6.x where the &quot;user facing features&quot; are written on each node, and replicated out to other nodes in realtime.  This is what lets you set and clear CFA with the pub down in later versions.<br>

&gt;<br>
&gt; See <a href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/6_0_1/cucm-rel_note-601a.html#wp44437" target="_blank">http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/6_0_1/cucm-rel_note-601a.html#wp44437</a> for specfics.<br>

&gt;<br>
&gt; Having a standby publisher installed and ready for restore is not a bad idea but you will be restricted by licensing (P1 TAC SR with the licensing team should get you rehosted pretty quickly I hope).  The only thing to worry about wrt to IP address is if the pub is specified in System-&gt;Server by IP address this would cause problems after the restore.   This could be avoided simply by changing the IP address to match the failed publisher before starting the restore.<br>

&gt;<br>
&gt; -Ryan<br>
&gt;<br>
&gt; On Jul 1, 2010, at 9:18 AM, Bill wrote:<br>
&gt;<br>
&gt; Also, at least in the 4.x days, you can still make changes to the subscriber if the publisher is down.<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
&gt; [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Ahmed Elnagar<br>
&gt; Sent: Thursday, July 01, 2010 7:43 AM<br>
&gt; To: Andrius Kislas<br>
&gt; Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
&gt; Subject: Re: [cisco-voip] Standby publisher<br>
&gt;<br>
&gt; What about the license? The license relates to the MAC address of the server??<br>
&gt;<br>
&gt;  Best Regards;<br>
&gt;   Ahmed Elnagar<br>
&gt;   Senior Network PS Engineer<br>
&gt;   Mob: +2019-0016211<br>
&gt;  CCIE#24697 (Voice)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
&gt; [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Andrius Kislas<br>
&gt; Sent: Thursday, July 01, 2010 1:17 PM<br>
&gt; To: Cisco Voip<br>
&gt; Subject: [cisco-voip] Standby publisher<br>
&gt;<br>
&gt; Hi All.<br>
&gt;<br>
&gt; Correct me if I am wrong, but when the publisher fails the biggest impact we have is not being able to change configuration. In large environments this might be serious impact.<br>
&gt;<br>
&gt; My question is - does anybody use a standby/cold publisher that has the only task - sit and wait until the primary publisher fails? This standby published would ba standalone (not a member of existing cluster), would have different IP address (in the same subnet) and the same name as existing publisher, would have no licenses uploaded and would be kept in the same version as primary publisher. During primary publisher failure we would need to change IP address and perform disaster recovery. This would save us some time that we would typiacly need to get new server, install new publisher, upgrade it and finally perform recovery.<br>

&gt;<br>
&gt; Does it sound fine or are there any caveats for such approach?<br>
&gt;<br>
&gt; Regards,<br>
&gt; Andrius<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; cisco-voip mailing list<br>
&gt; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
&gt; <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
&gt; Disclaimer: NOTICE The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately.<br>

&gt; The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Raya will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any malicious code or virus being passed on. Views expressed in this communication are not necessarily those of Raya.If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message.<br>

&gt;<br>
&gt; _______________________________________________<br>
&gt; cisco-voip mailing list<br>
&gt; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
&gt; <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; cisco-voip mailing list<br>
&gt; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
&gt; <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; cisco-voip mailing list<br>
&gt; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
&gt; <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; cisco-voip mailing list<br>
&gt; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
&gt; <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
&gt;<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div></div></blockquote></div><br>