<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I'd agree with Chris on all points. At the least you exposed a DRF bug because it allowed the restore to complete. If such a restore is to be allowed then you've exposed a bug with the duplicate certs. <div><br></div><div>If this is a test cluster you can play with then I'd open a TAC SR and work to figure out exactly what happened and get some things fixed. If you need it back 100% operational then do your restore on the caps hostnames and then change them using the correct procedure. If you go this route pay attention to the certs after the hostname change to see if they also broke there.</div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>-Ryan</div></span>
</div>
<br><div><div>On Jul 6, 2012, at 9:54 AM, Chris Ward (chrward) wrote:</div><br class="Apple-interchange-newline"><div>Someone who is still in TAC can correct me if I am wrong, but I was under the impression that a DRS restore had to be done with the same IP/hostname as with what the backup was taken with. So while I understand the argument about hostnames being cap-agnostic, I think we all know how seriously the linux operating system takes capitalization.<br><br>You can absolutely change hostnames on your CCMs (I probably would have too, so I won't judge), you just have to do it in the proper method.<br><br><a href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_6_1/ipchange/ipchg861.html">http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_6_1/ipchange/ipchg861.html</a><br><br>I would probably revert back (DRS restore on same IP/hostname) and then follow the method outlined in the link to change the hostname. Who knows what else isn't set to what it is supposed to be set to right now in the system.<br><br>+Chris<br>Unity Connection TME<br><br><br>-----Original Message-----<br>From: cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Beck, Andre<br>Sent: Friday, July 06, 2012 5:55 AM<br>To: cisco-voip@puck.nether.net<br>Subject: [cisco-voip] CUCM hostname case-only change?<br><br>Hi,<br><br>when upgrading a CUCM cluster all the way from 6.1.2 to 8.6.latest, I found the original cluster members named as CCM1 and CCM2, yes, with all caps in the names. Given hostnames are considered to be case insensitive and all-caps hostnames are a pot-ugly Windows meme that tends to infect Unix platforms, I tried whether changing them to lower case would be feasible. The change was performed by DRF backup (on 8.6.2a), fresh installation of a new 8.6.2a cluster named ccm1 and ccm2, followed by DRF restore. The actual naming in the CUCM configuration is completely name-agnostic and uses IP addresses only (and the platforms have no DNS resolver configured either). Initially, nothing broke.<br><br>Later I recognized a number of certificates were now "doubled", the "old ones" for CCM1/2 still existed and new ones for ccm1/2 had appeared in addition. So my next step was to remove all the all-caps certificates.<br>Even after that, nothing seemed broke regarding call handling.<br><br>Then I recognized DRF was dead. Essentially, the DRF Local process would not come up and always log certificate issues. Trying to configure anything in DRF would just freeze/time out, not presenting the expected pages.<br><br>To make the long story short, I would like to ask: How bad of an idea was the name fix (it isn't really a name change, given they are semantically equivalent, but not every component seems to think the same way)? Is there a way to correct that? Or should I consider keeping the original names even down to the specific casing mandatory for a supported upgrade?<br><br>As all this was just a test for the actual upgrade path, I still have a chance to return to the all-caps names. The only issue will be licensing, as (of course, who would have thought otherwise) the License MAC creation algorithm is one of the components that deals with host names in a case sensitive way. Let's see how often I can rehost that licenses again...<br><br>Thoughts on this? Warnings? Outright declarations of me being stupid wasting time on a cosmetic issue?<br><br>TIA,<br>Andre.<br>-- <br> Cool .signatures are so 90s...<br><br>-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-<br>_______________________________________________<br>cisco-voip mailing list<br>cisco-voip@puck.nether.net<br>https://puck.nether.net/mailman/listinfo/cisco-voip<br><br>_______________________________________________<br>cisco-voip mailing list<br>cisco-voip@puck.nether.net<br>https://puck.nether.net/mailman/listinfo/cisco-voip<br><br></div></div><br></div></body></html>