Whats the actual recommended procedure for this one?<br><br>Wouldnt you just build it online as a sub and then deactivate the CallManager services that you dont need?<br><br>Cheers,<br><br>Tim.<br><br><div class="gmail_quote">
On Mon, Oct 27, 2008 at 6:16 PM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>></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;">
I'm glad to hear you got it inserted manually into the database. Frankly<br>
I'm amazed the install even proceeded if it couldn't reach the publisher.<br>
<div class="Ih2E3d"><br>
<br>
-Ryan<br>
-----Original Message-----<br>
From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
[mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of James Brown<br>
</div><div><div></div><div class="Wj3C7c">Sent: Monday, October 27, 2008 1:09 PM<br>
To: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
Subject: Re: [cisco-voip] CCM4.1.3 - Add Secondary TFTP Server<br>
<br>
Just to close off this thread, I got in touch with our vendor last week and<br>
was fortunate enough to speak with an Ex-TAC engineer. The fix we<br>
implemented in the end was:<br>
<br>
1. Locate the installation log for the new server.<br>
- Typically C:\Install\DBInstall\DBInstall00000000.txt<br>
2. Search this file for two SQL queries on the "ProcessConfig" table.<br>
They will look like:<br>
- INSERT INTO ProcessConfig (pkid, tkService, fkProcessNode, paramName,<br>
tkParam, primaryData) VALUES ('{FD54F781-6D98-4EDA-8167-944514373EEC}',<br>
9, '{735A18BD-974A-4896-9B9B-0F3F4DD3542F}', 'DBConnection', 3, 1)<br>
- UPDATE ProcessConfig SET<br>
paramValue='DSN=CiscoCallManager;SERVER=LOGISIPTTFT002;DATABASE=CCM0302;<br>
Trusted_Connection=yes' WHERE paramName='DBConnection' and tkService=9 and<br>
fkProcessNode='{735A18BD-974A-4896-9B9B-0F3F4DD3542F}'<br>
<br>
3. Bear in mind that fkProcessNode value is a foreign key based on the pkid<br>
within the ProcessNode table.<br>
- You therefore might need to change it to match the pkid assigned for<br>
this new server.<br>
- The new pkid (and therefore fkProcessNode) will become apparent when the<br>
new server has been added via System->Server in CCMAdmin.<br>
<br>
So it turns out that because we built LOGISIPTTFT002 offline, the SQL<br>
INSERTS into the ProcessConfig table on the publisher were not actually<br>
performed. As soon as we manually executed the above statements, DBL Helper<br>
showed the new server.<br>
<br>
Apparently, after a reboot the HKLM\software\Cisco Systems,<br>
Inc.\DBL\DBConnectionX registry strings are also updated automatically.<br>
<br>
Hope this helps someone in future.<br>
<br>
All thes best<br>
<br>
James.<br>
<br>
Ryan Ratliff wrote:<br>
> I'd strongly recommend against messing around in the registry unless<br>
> you A) have a backup and B) know what you're doing. If the database<br>
> connection string wasn't correct the TFTP service wouldn't even start<br>
> on the subscriber.<br>
><br>
> The correct registry entry for the db connections is<br>
> HKLM\software\Cisco Systems, Inc.\DBL\DBConnectionX where X starts at 0<br>
and goes up.<br>
> DBConnection0 should always be the publisher.<br>
><br>
><br>
> -Ryan<br>
> -----Original Message-----<br>
> From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of James Brown<br>
> Sent: Sunday, October 19, 2008 6:33 AM<br>
> To: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: Re: [cisco-voip] CCM4.1.3 - Add Secondary TFTP Server<br>
><br>
> Jason,<br>
><br>
> Thanks, that's a great help. I did activate the new TFTP service<br>
> yesterday and as you described, the .conf.xml files started appearing.<br>
> I'm guessing the TFTP and DBL Monitor service work together to<br>
> generate these? I'll also remember to copy across the phone loads<br>
manually.<br>
><br>
> One aspect which is really concerning me though, is that the "Database<br>
> Connection Sring" field under the DBL Monitor service parameters for<br>
> the new TFTP server is blank! That field is also locked, so I can't<br>
> enter something manually.<br>
><br>
> I did a "SELECT * FROM ProcessConfig WHERE ParamName LIKE 'DBConection';"<br>
> and noticed that every server appart from this new TFTP has an entry.<br>
> Also, when I run DBLHelper on the publisher, I see every server except<br>
> this new one.<br>
><br>
> However, MSSQL replication looks to be working within Enterprise<br>
> Manager. I also tried manually adding a new registry key under<br>
> "HKLM\Software\Cisco...\DBL\DBConnectionX", then deleted and readded<br>
> the new TFTP to the cluster. No joy.<br>
><br>
> Perhaps this will get resolved as part of the cluster reboot, but I'm<br>
> not hopeful. Does anyone have any suggestions please?<br>
><br>
> Regards<br>
><br>
> James.<br>
><br>
> Jason Burns wrote:<br>
>> James,<br>
>><br>
>> 2. All of the device configuration files like<br>
>> SEPXXXXXXXXXXXX.conf.xml are generated in memory when the TFTP<br>
>> service starts. The TFTP service reads the phone configuration from<br>
>> the database and by default never writes this file out to disk. It's<br>
>> faster this way. You can change this behavior in the TFTP Service<br>
Parameter page.<br>
>><br>
>> To get things like new phone loads onto the TFTP server you would<br>
>> have to run through the phone load installer on the new TFTP server<br>
>> or extract the zip files into the TFTP directory.<br>
>><br>
>> 3. Whenever you add a new server, a cluster reboot is necessary to<br>
>> make sure all the other servers in the cluster know it is there. This<br>
>> is so change notification will work properly. This will be required<br>
>> even for a TFTP server because it will have to get change<br>
>> notification to update the in memory config files when you do<br>
>> something like change a CallManager group around.<br>
>><br>
>> -Jason<br>
>><br>
>> On Fri, Oct 17, 2008 at 12:07 PM, James Brown<br>
>> <<a href="mailto:james.m.h.brown@googlemail.com">james.m.h.brown@googlemail.com</a><br>
>> <mailto:<a href="mailto:james.m.h.brown@googlemail.com">james.m.h.brown@googlemail.com</a>>><br>
>> wrote:<br>
>><br>
>> James Brown wrote:<br>
>><br>
>> All,<br>
>><br>
>> [...]<br>
>><br>
>><br>
>> 1. How do I get the new TFTP server recognised in the<br>
>> servicability page on the publisher? My guess is that I'd need<br>
>> to momentarily start the Call Manager service on the new TFTP to<br>
>> allow the heartbeat to begin. I can't see any way of manually<br>
>> programming servers into the servicability page.<br>
>><br>
>> 2. When I have all the services configured correctly on this new<br>
>> TFTP server, how should I begin getting the publisher to sync<br>
>> the device config files out to the new repository? Should this<br>
>> be done by a manual copy/paste, or does the publisher<br>
>> automatically start writing the files when it recognises a new<br>
>> TFTP service is started?<br>
>><br>
>> 3. This is a new server in the cluster, with a copy of the CCM<br>
>> database, but it's not actually going to have process callls. Is<br>
>> a cluster reboot therefore necessary?<br>
>><br>
>> [...]<br>
>><br>
>><br>
>> I think I can answer question 1 now. On CCM 4.x, the server can be<br>
>> defined under System->Servers within CCMAdmin. Once it's added on<br>
>> this screen, it should also appear within Serviceability. No need to<br>
>> activate the CCM Service on a TFTP Server.<br>
>><br>
>> I'm still unsure about questions 2 and 3 though.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> cisco-voip mailing list<br>
>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a> <mailto:<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>
>><br>
>><br>
>><br>
>> ---------------------------------------------------------------------<br>
>> -<br>
>> --<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>
><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>
<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>
<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>