<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Verdana; font-size: 10pt; color: #000000'>ah, yes. that gets us every time too. forgot to mention that because, well, i forgot! ;)<br><br>something i did before hand was to get an inventory of all the phones and see which phones had this setting enabled and visit them manually. <br><br>a remote control software will also help if you can't visit them or ask clients to make changes.<br><br>you can use something like curl or wget or an inventory software program.<br><span><br><span name="x"></span>---<br>Lelio Fulgenzi, B.A.<br>Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>Cooking with unix is easy. You just sed it and forget it. <br>                              - LFJ (with apologies to Mr. Popeil)<br><span name="x"></span><br></span><br><hr id="zwchr"><b>From: </b>"Steven Casper" <SCASPER@mtb.com><br><b>To: </b>cisco-voip@puck.nether.net<br><b>Sent: </b>Tuesday, July 26, 2011 3:22:42 PM<br><b>Subject: </b>Re: [cisco-voip] IP Phone TFTP Server Change Problem<br><br>Thanks for the suggestions! I may have found the problem, on 4 of the 5 phones that failed they had  the setting Alternative TFTP Server enabled. This setting overrides the DHCP TFTP server assignment.  I suspect that with this setting turned on it did not allow a new TFTP address to be learned. The erase of the IPv4 settings  removed the enable on this setting. Got another test scheduled this week.<br><br><br>-----Original Message-----<br>From: cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Andy Carse<br>Sent: Tuesday, July 26, 2011 12:40 PM<br>To: cisco-voip@puck.nether.net<br>Subject: Re: [cisco-voip] IP Phone TFTP Server Change Problem<br><br>we had a similar issue with tftp being 255.255.255.255 and the resolution was to configure a dhcp helper address on the vlan for the tftp server.<br><br>Rgds Andy<br><br>On 26/07/11 14:17, Lelio Fulgenzi wrote:<br>> When we did our migration, we had the following scenario:<br>><br>>     * same DHCP server<br>>     * same voice VLANs<br>>     * different TFTP server<br>>     * different cluster (on new network)<br>><br>> We took advantage of the fact that when phones can't communicate to <br>> the CallManagers, they get into a tizzy and end up restarting. This <br>> restart forces them to send out a new DHCP request. I'm pretty sure if <br>> they can't reach the DHCP server after a bit, they send out a new <br>> broadcast request (not 100% sure on this one, you'll have to test).<br>><br>> So before the migration, we modified the TFTP option on our DHCP <br>> server and then put in an ACL which prevented access to the old CallManagers.<br>> Other than a few phones at a remote site, all went well.<br>><br>> I'm pretty sure this is also how we changed over DHCP servers earlier <br>> in the year, but I could be wrong.<br>><br>> It's worth trying out.<br>><br>> ---<br>> Lelio Fulgenzi, B.A.<br>> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) <br>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>> Cooking with unix is easy. You just sed it and forget it.<br>> - LFJ (with apologies to Mr. Popeil)<br>><br>><br>> ----------------------------------------------------------------------<br>> --<br>> *From: *"Steven Casper" <SCASPER@mtb.com><br>> *To: *cisco-voip@puck.nether.net<br>> *Sent: *Monday, July 25, 2011 10:45:34 AM<br>> *Subject: *[cisco-voip] IP Phone TFTP Server Change Problem<br>><br>> I have about 20 sites to convert from one Call Manager Cluster on <br>> 7.1.3 to another on 7.1.5. Testing this weekend we took a site and <br>> changed the Voice and Data VLANs to point to new VLANs with new <br>> associated IP and IP Helper addresses and reloaded the router. About <br>> half of the phones came up on the new Call Manager but the other half <br>> did not. They got new IP addresses and all other associated settings <br>> but the old TFTP server address stayed in the phone config. Resetting <br>> the phones, disconnecting and reconnecting the phones or shut/no shut <br>> on the switch ports did not help. The only way to get the phones to <br>> register to the new cluster was to erase the IPv4 config on each <br>> phone. The phones then reset and received the correct TFTP server <br>> address and registered correctly to the new Cluster.<br>><br>> Anybody seen this before and came up with a fix other than touching <br>> each phone? Phones are 7962 running SCCP 9-0-2SR1S<br>><br>> Thanks,<br>><br>> Steve<br>><br>> ************************************<br>> This email may contain privileged and/or confidential information that <br>> is intended solely for the use of the addressee. If you are not the <br>> intended recipient or entity, you are strictly prohibited from <br>> disclosing, copying, distributing or using any of the information <br>> contained in the transmission. If you received this communication in <br>> error, please contact the sender immediately and destroy the material <br>> in its entirety, whether electronic or hard copy. This communication <br>> may contain nonpublic personal information about consumers subject to <br>> the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act.<br>> You may not directly or indirectly reuse or disclose such information <br>> for any purpose other than to provide the services for which you are <br>> receiving the information.<br>> There are risks associated with the use of electronic transmission. <br>> The sender of this information does not control the method of <br>> transmittal or service providers and assumes no duty or obligation for <br>> the security, receipt, or third party interception of this transmission.<br>> ************************************<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>><br>><br>><br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>_______________________________________________<br>cisco-voip mailing list<br>cisco-voip@puck.nether.net<br>https://puck.nether.net/mailman/listinfo/cisco-voip<br><br>************************************<br>This email may contain privileged and/or confidential information that is intended solely for the use of the addressee.  If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission.  If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy.  This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act.  You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.<br>There are risks associated with the use of electronic transmission.  The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.<br>************************************<br><br><br><br>_______________________________________________<br>cisco-voip mailing list<br>cisco-voip@puck.nether.net<br>https://puck.nether.net/mailman/listinfo/cisco-voip<br></div></body></html>