[cisco-voip] CCM4.1.3 - Add Secondary TFTP Server

James Brown james.m.h.brown at googlemail.com
Mon Oct 27 13:08:57 EDT 2008


Just to close off this thread, I got in touch with our vendor last week 
and was fortunate enough to speak with an Ex-TAC engineer. The fix we 
implemented in the end was:

1. Locate the installation log for the new server.
  - Typically C:\Install\DBInstall\DBInstall00000000.txt
2. Search this file for two SQL queries on the "ProcessConfig" table.
They will look like:
  - INSERT INTO ProcessConfig (pkid, tkService, fkProcessNode, paramName,
tkParam, primaryData) VALUES ('{FD54F781-6D98-4EDA-8167-944514373EEC}',
9, '{735A18BD-974A-4896-9B9B-0F3F4DD3542F}', 'DBConnection', 3, 1)
  - UPDATE ProcessConfig SET
paramValue='DSN=CiscoCallManager;SERVER=LOGISIPTTFT002;DATABASE=CCM0302;
Trusted_Connection=yes' WHERE  paramName='DBConnection' and tkService=9
and fkProcessNode='{735A18BD-974A-4896-9B9B-0F3F4DD3542F}'

3. Bear in mind that fkProcessNode value is a foreign key based on the
pkid within the ProcessNode table.
  - You therefore might need to change it to match the pkid assigned for
this new server.
  - The new pkid (and therefore fkProcessNode) will become apparent when
the new server has been added via System->Server in CCMAdmin.

So it turns out that because we built LOGISIPTTFT002 offline, the SQL 
INSERTS into the ProcessConfig table on the publisher were not actually 
performed. As soon as we manually executed the above statements, DBL 
Helper showed the new server.

Apparently, after a reboot the HKLM\software\Cisco Systems, 
Inc.\DBL\DBConnectionX registry strings are also updated automatically.

Hope this helps someone in future.

All thes best

James.

Ryan Ratliff wrote:
> I'd strongly recommend against messing around in the registry unless you A)
> have a backup and B) know what you're doing.  If the database connection
> string wasn't correct the TFTP service wouldn't even start on the
> subscriber. 
> 
> The correct registry entry for the db connections is HKLM\software\Cisco
> Systems, Inc.\DBL\DBConnectionX where X starts at 0 and goes up.
> DBConnection0 should always be the publisher. 
> 
> 
> -Ryan 
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of James Brown
> Sent: Sunday, October 19, 2008 6:33 AM
> To: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] CCM4.1.3 - Add Secondary TFTP Server
> 
> Jason,
> 
> Thanks, that's a great help. I did activate the new TFTP service yesterday
> and as you described, the .conf.xml files started appearing. 
> I'm guessing the TFTP and DBL Monitor service work together to generate
> these? I'll also remember to copy across the phone loads manually.
> 
> One aspect which is really concerning me though, is that the "Database
> Connection Sring" field under the DBL Monitor service parameters for the new
> TFTP server is blank! That field is also locked, so I can't enter something
> manually.
> 
> I did a "SELECT * FROM ProcessConfig WHERE ParamName LIKE 'DBConection';"
> and noticed that every server appart from this new TFTP has an entry. Also,
> when I run DBLHelper on the publisher, I see every server except this new
> one.
> 
> However, MSSQL replication looks to be working within Enterprise Manager. I
> also tried manually adding a new registry key under
> "HKLM\Software\Cisco...\DBL\DBConnectionX", then deleted and readded the new
> TFTP to the cluster. No joy.
> 
> Perhaps this will get resolved as part of the cluster reboot, but I'm not
> hopeful. Does anyone have any suggestions please?
> 
> Regards
> 
> James.
> 
> Jason Burns wrote:
>> James,
>>
>> 2. All of the device configuration files like SEPXXXXXXXXXXXX.conf.xml 
>> are generated in memory when the TFTP service starts. The TFTP service 
>> reads the phone configuration from the database and by default never 
>> writes this file out to disk. It's faster this way. You can change 
>> this behavior in the TFTP Service Parameter page.
>>
>> To get things like new phone loads onto the TFTP server you would have 
>> to run through the phone load installer on the new TFTP server or 
>> extract the zip files into the TFTP directory.
>>
>> 3. Whenever you add a new server, a cluster reboot is necessary to 
>> make sure all the other servers in the cluster know it is there. This 
>> is so change notification will work properly. This will be required 
>> even for a TFTP server because it will have to get change notification 
>> to update the in memory config files when you do something like change 
>> a CallManager group around.
>>
>> -Jason
>>
>> On Fri, Oct 17, 2008 at 12:07 PM, James Brown 
>> <james.m.h.brown at googlemail.com 
>> <mailto:james.m.h.brown at googlemail.com>>
>> wrote:
>>
>>     James Brown wrote:
>>
>>         All,
>>
>>         [...]
>>
>>
>>         1. How do I get the new TFTP server recognised in the
>>         servicability page on the publisher? My guess is that I'd need
>>         to momentarily start the Call Manager service on the new TFTP to
>>         allow the heartbeat to begin. I can't see any way of manually
>>         programming servers into the servicability page.
>>
>>         2. When I have all the services configured correctly on this new
>>         TFTP server, how should I begin getting the publisher to sync
>>         the device config files out to the new repository? Should this
>>         be done by a manual copy/paste, or does the publisher
>>         automatically start writing the files when it recognises a new
>>         TFTP service is started?
>>
>>         3. This is a new server in the cluster, with a copy of the CCM
>>         database, but it's not actually going to have process callls. Is
>>         a cluster reboot therefore necessary?
>>
>>         [...]
>>
>>
>>     I think I can answer question 1 now. On CCM 4.x, the server can be
>>     defined under System->Servers within CCMAdmin. Once it's added on
>>     this screen, it should also appear within Serviceability. No need to
>>     activate the CCM Service on a TFTP Server.
>>
>>     I'm still unsure about questions 2 and 3 though.
>>
>>
>>     _______________________________________________
>>     cisco-voip mailing list
>>     cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>>     https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip



More information about the cisco-voip mailing list