[cisco-voip] Jabber Directory Groups over port 3268

[Daniel Ohnesorge via cisco-voip]

 

Hi Guys, 

Just as a quick FYI, Jabber 11.0 - 11.5 doesn't seem to be able to
search for Directory Groups over port 389. CUCM>System>LDAP>Directory is
currently synced with port 389 and all User Groups (distribution groups
from AD) sync over fine. However when searching in Jabber using EDI over
port 389, the Groups don't show up. This is what we see in the logs; 

_2016-04-21 13:00:52,505 DEBUG [0x2358]
[rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource]
[WriteLogMessage] - ConnectionManager::ExecuteQueryOnGroupSearchers -
Succeeded - Query string:
[(&(objectCategory=group)(!(groupType:1.2.840.113556.1.4.803:=2147483648))(sAMAccountName=test
group*))], Attributes: [sAMAccountName]_
_2016-04-21 13:00:52,505 DEBUG [0x2358]
[rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource]
[WriteLogMessage] - QueryManager::ExecuteQuery - Query executed - about
to convert the results_
_2016-04-21 13:00:52,505 DEBUG [0x2358]
[rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource]
[WriteLogMessage] - QueryResultsConverter::ConvertResultSet - processing
handle [162896744]_
_2016-04-21 13:00:52,521 WARN [0x2358]
[rdsource\ADPersonRecordSourceLog.cpp(42)] [csf.person.adsource]
[WriteLogMessage] - QueryResultsConverter::ConvertResultSet - Query
Results Failed - COMException [0x80072030]_ 

0x80072030 means 'There is no such object on the server'. However, if I
use any LDAP Explorer and use the filter
(&(objectCategory=group)(!(groupType:1.2.840.113556.1.4.803:=2147483648))(sAMAccountName=test
group*)) the result comes up fine. 

Based on some research, I think the relevant Bug ID's are CSCuu47641,
CSCuu48043 and CSCuu48329 with the last 2 being internal bugs. All bugs
have little to no useful information. Work around is to use port 3268
and the Groups show up straight away. 
  ___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UCCX 10.6(1) SU1 & SU2 CAD Upgrade Warning

[Abhiram Kramadhati (akramadh)]

Justin,

Thank you for catching this, will get it corrected ASAP. We should be better at 
this - sorry about that.

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CCBU
CCIE Collaboration # 40065

From: Justin Steinberg >
Date: Thursday, 21 April 2016 at 4:55 AM
To: akramadh >
Cc: "cisco-voip@puck.nether.net" 
>
Subject: Re: [cisco-voip] UCCX 10.6(1) SU1 & SU2 CAD Upgrade Warning

Looks like the upgrade from 10.6(1)SU1 to 10.6(1)SU2 also requires a CAD 
upgrade even though the compatibility matrix again says it doesn't.

Per comparability matrix:

10.6(1)su1 CAD version is 10.6.1.1057
10.6(1)su2 CAD version is 10.6.1.1057

My lab testing:

10.6(1)su1 CAD version is 10.6.1.1057
10.6(1)su2 CAD version is 10.6.1.2011

Justin

On Fri, Oct 2, 2015 at 1:22 AM, Abhiram Kramadhati (akramadh) 
> wrote:
Closing the loop on this.

The CAD version for 10.6(1) is 10.6.1.95
The CAD version for 10.6(1)SU1 is 10.6.1.1057

The compatibility matrix for 10.6(1)SU1 has wrongly mentioned it as 10.6.1.95 
and CSCuw51442 has been filed to correct this.

As a side note, it would be best to plan for a client side upgrade for any 
server upgrade done. Please let me know if there are any questions, thank you.

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CBABU
CCIE Collaboration # 40065

From: Justin Steinberg >
Date: Friday, 25 September 2015 2:41 am
To: Cisco VOIP >
Subject: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning

The current UCCX compatibility matrix lists CAD 10.6.1.95 for both UCCX 10.6(1) 
and 10.6(1)SU1, implying there is no CAD upgrade forced after the SU1 upgrade.

This isn't the case.   Upgrading 10.6(1) to 10.6(1)su1 does force a CAD upgrade.

Hopefully this helps someone else.

Justin

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Constantly having db replication issues

[Brian Meade]

You can also do "file tail activelog cm/trace/dbl/sdi recent" which will
tail the most recent log file in the directory.  Saves you a few seconds.

On Wed, Apr 20, 2016 at 6:00 PM, Daniel Ohnesorge via cisco-voip <
cisco-voip@puck.nether.net> wrote:

> Hi Nick,
>
> At the time of failure, I like to tail the dbl logs to see whats
> happening. First, run the command to see which log is the latest; file list
> activelog cm/trace/dbl/sdi date detail. That output will list the last
> written log file at the bottom for example log16.log. Then you can tail
> file using the command; file tail activelog cm/trace/dbl/sdi/log16.log.
> This will give you some idea of what is happening at that time.
>
> On 2016-04-21 07:20, Nick Barnett wrote:
>
> Thanks James
>
> Ok, yes, there's a lot in rhosts. They are all identical, and each of them
> has forward and reverse lookups.
>
>
>
> On Wed, Apr 20, 2016 at 12:39 PM, James Buchanan <
> james.buchan...@gmail.com> wrote:
>
>> Hello,
>>
>> Even though you are not using DNS, do you have DNS servers and a domain
>> name configured? If so, you should have forward and reverse entries
>> configured for all servers. When you look in Unified Reporting, do you see
>> anything about the rhosts under Database Status?
>>
>> Thanks,
>>
>> James
>>
>> On Wed, Apr 20, 2016 at 1:07 PM, Nick Barnett 
>> wrote:
>>
>>> Thanks Ryan.
>>>
>>> We have 3 CCM and 1 TFTP node in each of our two data centers. The main
>>> data center is here, and that is where our DRS sftp server (and publisher)
>>> is located. Nothing is using DNS right now, all of the servers are entered
>>> into CUCM as IP addresses... this cluster has been around for years. It was
>>> upgraded from 7.BeforeMyTime to 8.6 to 10.0.
>>>
>>>
>>>
>>> On Wed, Apr 20, 2016 at 11:54 AM, Ryan Huff 
>>> wrote:
>>>
 Hi Nick.

 Let me ask you a few things;

 - How is the cluster laid out (how many nodes in the cluster and what
 nodes are in which DC)?

 - Are you using DNS and if so, where is the DNS server located and do
 you have redundant DNS in both DCs?

 - Where is your DRS server in relation to the cluster publisher (same
 DC or no)?

 Thanks,

 Ryan

 On Apr 20, 2016, at 11:09 AM, Nick Barnett 
 wrote:

 I'm wondering how many others have had as many issues with db
 replication? It seems that any time we lose a connection to our 2nd data
 center (even a 2 minute MPLS planned maintenance outage causes the issue),
 our database synchronization has errors.  After a WAN blip, within an hour
 or so, I get a message from RTMT about a subscriber being in "blocked"
 state:


 %[AppID=Cisco Database Layer
 Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change
 notification client is busy (blocked). If the change notification client
 continues to be blocked for 10 minutes, the system automatically clears the
 block and change notification should resume successfully."



 After that, if I run utils dbreplication status, it will have errors...
 so then I run the "repair all" option and it fixes it. Then I'm good for a
 few weeks until something else happens that starts the whole cycle over.

 Something else that happens after a WAN blip is that DRS begins to
 fail, so we have to restart the master DRS and the subsequent DRS services
 on the subs. Am I doing something wrong? Is this normal?

 I'm on CUCM 10.0.1.12900-2.

 Thanks,
 Nick

 ___
 cisco-voip mailing list
 cisco-voip@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-voip


>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Constantly having db replication issues

[Daniel Ohnesorge via cisco-voip]

 

Hi Nick, 

At the time of failure, I like to tail the dbl logs to see whats
happening. First, run the command to see which log is the latest; file
list activelog cm/trace/dbl/sdi date detail. That output will list the
last written log file at the bottom for example log16.log. Then you can
tail file using the command; file tail activelog
cm/trace/dbl/sdi/log16.log. This will give you some idea of what is
happening at that time. 

On 2016-04-21 07:20, Nick Barnett wrote: 

> Thanks James 
> Ok, yes, there's a lot in rhosts. They are all identical, and each of them 
> has forward and reverse lookups. 
> 
> On Wed, Apr 20, 2016 at 12:39 PM, James Buchanan  
> wrote:
> 
> Hello,
> 
> Even though you are not using DNS, do you have DNS servers and a domain name 
> configured? If so, you should have forward and reverse entries configured for 
> all servers. When you look in Unified Reporting, do you see anything about 
> the rhosts under Database Status?
> 
> Thanks,
> 
> James 
> 
> On Wed, Apr 20, 2016 at 1:07 PM, Nick Barnett  wrote:
> 
> Thanks Ryan. 
> 
> We have 3 CCM and 1 TFTP node in each of our two data centers. The main data 
> center is here, and that is where our DRS sftp server (and publisher) is 
> located. Nothing is using DNS right now, all of the servers are entered into 
> CUCM as IP addresses... this cluster has been around for years. It was 
> upgraded from 7.BeforeMyTime to 8.6 to 10.0. 
> 
> On Wed, Apr 20, 2016 at 11:54 AM, Ryan Huff  wrote:
> 
> Hi Nick. 
> 
> Let me ask you a few things; 
> 
> - How is the cluster laid out (how many nodes in the cluster and what nodes 
> are in which DC)? 
> 
> - Are you using DNS and if so, where is the DNS server located and do you 
> have redundant DNS in both DCs? 
> 
> - Where is your DRS server in relation to the cluster publisher (same DC or 
> no)?
> 
> Thanks, 
> 
> Ryan 
> 
> On Apr 20, 2016, at 11:09 AM, Nick Barnett  wrote:
> 
> I'm wondering how many others have had as many issues with db replication? It 
> seems that any time we lose a connection to our 2nd data center (even a 2 
> minute MPLS planned maintenance outage causes the issue), our database 
> synchronization has errors.  After a WAN blip, within an hour or so, I get a 
> message from RTMT about a subscriber being in "blocked" state: 
> 
> %[AppID=Cisco Database Layer 
> Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change notification 
> client is busy (blocked). If the change notification client continues to be 
> blocked for 10 minutes, the system automatically clears the block and change 
> notification should resume successfully." 
> 
> After that, if I run utils dbreplication status, it will have errors... so 
> then I run the "repair all" option and it fixes it. Then I'm good for a few 
> weeks until something else happens that starts the whole cycle over. 
> 
> Something else that happens after a WAN blip is that DRS begins to fail, so 
> we have to restart the master DRS and the subsequent DRS services on the 
> subs. Am I doing something wrong? Is this normal? 
> 
> I'm on CUCM 10.0.1.12900-2.   
> 
> Thanks,
> Nick 
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip 

  ___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Constantly having db replication issues

[Nick Barnett]

Thanks James

Ok, yes, there's a lot in rhosts. They are all identical, and each of them
has forward and reverse lookups.



On Wed, Apr 20, 2016 at 12:39 PM, James Buchanan 
wrote:

> Hello,
>
> Even though you are not using DNS, do you have DNS servers and a domain
> name configured? If so, you should have forward and reverse entries
> configured for all servers. When you look in Unified Reporting, do you see
> anything about the rhosts under Database Status?
>
> Thanks,
>
> James
>
> On Wed, Apr 20, 2016 at 1:07 PM, Nick Barnett 
> wrote:
>
>> Thanks Ryan.
>>
>> We have 3 CCM and 1 TFTP node in each of our two data centers. The main
>> data center is here, and that is where our DRS sftp server (and publisher)
>> is located. Nothing is using DNS right now, all of the servers are entered
>> into CUCM as IP addresses... this cluster has been around for years. It was
>> upgraded from 7.BeforeMyTime to 8.6 to 10.0.
>>
>>
>>
>> On Wed, Apr 20, 2016 at 11:54 AM, Ryan Huff  wrote:
>>
>>> Hi Nick.
>>>
>>> Let me ask you a few things;
>>>
>>> - How is the cluster laid out (how many nodes in the cluster and what
>>> nodes are in which DC)?
>>>
>>> - Are you using DNS and if so, where is the DNS server located and do
>>> you have redundant DNS in both DCs?
>>>
>>> - Where is your DRS server in relation to the cluster publisher (same DC
>>> or no)?
>>>
>>> Thanks,
>>>
>>> Ryan
>>>
>>> On Apr 20, 2016, at 11:09 AM, Nick Barnett 
>>> wrote:
>>>
>>> I'm wondering how many others have had as many issues with db
>>> replication? It seems that any time we lose a connection to our 2nd data
>>> center (even a 2 minute MPLS planned maintenance outage causes the issue),
>>> our database synchronization has errors.  After a WAN blip, within an hour
>>> or so, I get a message from RTMT about a subscriber being in "blocked"
>>> state:
>>>
>>> %[AppID=Cisco Database Layer
>>> Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change
>>> notification client is busy (blocked). If the change notification client
>>> continues to be blocked for 10 minutes, the system automatically clears the
>>> block and change notification should resume successfully."
>>>
>>>
>>> After that, if I run utils dbreplication status, it will have errors...
>>> so then I run the "repair all" option and it fixes it. Then I'm good for a
>>> few weeks until something else happens that starts the whole cycle over.
>>>
>>> Something else that happens after a WAN blip is that DRS begins to fail,
>>> so we have to restart the master DRS and the subsequent DRS services on the
>>> subs. Am I doing something wrong? Is this normal?
>>>
>>> I'm on CUCM 10.0.1.12900-2.
>>>
>>> Thanks,
>>> Nick
>>>
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Constantly having db replication issues

[Ryan Huff]

Nick,

Each time time you have one of these DB replication issues, have you always 
been able to tie it into a WAN event? The reason I ask is because you may be 
having these issues regardless of WAN, although once or twice it has lined up 
with a WAN event.

Do me a flavor; send me the output of:

- utils diagnose test
- utils ntp server list
- utils dbreplication runtimestate
- show network cluster
- run sql select name,description,nodeid from processnode

That is a lot of output, so you may want to throw it in a spreadsheet or 
something instead of inline to this email. All of this syntax should be ran 
from the CLI of the CUCM publisher.

Thanks,

Ryan

Sent from my iPad

On Apr 20, 2016, at 1:08 PM, Nick Barnett 
> wrote:

Thanks Ryan.

We have 3 CCM and 1 TFTP node in each of our two data centers. The main data 
center is here, and that is where our DRS sftp server (and publisher) is 
located. Nothing is using DNS right now, all of the servers are entered into 
CUCM as IP addresses... this cluster has been around for years. It was upgraded 
from 7.BeforeMyTime to 8.6 to 10.0.



On Wed, Apr 20, 2016 at 11:54 AM, Ryan Huff 
> wrote:
Hi Nick.

Let me ask you a few things;

- How is the cluster laid out (how many nodes in the cluster and what nodes are 
in which DC)?

- Are you using DNS and if so, where is the DNS server located and do you have 
redundant DNS in both DCs?

- Where is your DRS server in relation to the cluster publisher (same DC or no)?

Thanks,

Ryan

On Apr 20, 2016, at 11:09 AM, Nick Barnett 
> wrote:

I'm wondering how many others have had as many issues with db replication? It 
seems that any time we lose a connection to our 2nd data center (even a 2 
minute MPLS planned maintenance outage causes the issue), our database 
synchronization has errors.  After a WAN blip, within an hour or so, I get a 
message from RTMT about a subscriber being in "blocked" state:


%[AppID=Cisco Database Layer 
Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change notification 
client is busy (blocked). If the change notification client continues to be 
blocked for 10 minutes, the system automatically clears the block and change 
notification should resume successfully."


After that, if I run utils dbreplication status, it will have errors... so then 
I run the "repair all" option and it fixes it. Then I'm good for a few weeks 
until something else happens that starts the whole cycle over.

Something else that happens after a WAN blip is that DRS begins to fail, so we 
have to restart the master DRS and the subsequent DRS services on the subs. Am 
I doing something wrong? Is this normal?

I'm on CUCM 10.0.1.12900-2.

Thanks,
Nick

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UCCX 10.6(1) SU1 & SU2 CAD Upgrade Warning

[Justin Steinberg]

Looks like the upgrade from 10.6(1)SU1 to 10.6(1)SU2 also requires a CAD
upgrade even though the compatibility matrix again says it doesn't.

Per comparability matrix:

10.6(1)su1 CAD version is 10.6.1.1057
10.6(1)su2 CAD version is 10.6.1.1057

My lab testing:

10.6(1)su1 CAD version is 10.6.1.1057
10.6(1)su2 CAD version is 10.6.1.2011

Justin

On Fri, Oct 2, 2015 at 1:22 AM, Abhiram Kramadhati (akramadh) <
akram...@cisco.com> wrote:

> Closing the loop on this.
>
> The CAD version for 10.6(1) is 10.6.1.95
> The CAD version for 10.6(1)SU1 is 10.6.1.1057
>
> The compatibility matrix for 10.6(1)SU1 has wrongly mentioned it as
> 10.6.1.95 and CSCuw51442 has been filed to correct this.
>
> As a side note, it would be best to plan for a client side upgrade for any
> server upgrade done. Please let me know if there are any questions, thank
> you.
>
> Regards,
> Abhiram Kramadhati
> Technical Solutions Manager, CBABU
> CCIE Collaboration # 40065
>
> From: Justin Steinberg 
> Date: Friday, 25 September 2015 2:41 am
> To: Cisco VOIP 
> Subject: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning
>
> The current UCCX compatibility matrix lists CAD 10.6.1.95 for both UCCX
> 10.6(1) and 10.6(1)SU1, implying there is no CAD upgrade forced after the
> SU1 upgrade.
>
> This isn't the case.   Upgrading 10.6(1) to 10.6(1)su1 does force a CAD
> upgrade.
>
> Hopefully this helps someone else.
>
> Justin
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Constantly having db replication issues

[James Buchanan]

Hello,

Even though you are not using DNS, do you have DNS servers and a domain
name configured? If so, you should have forward and reverse entries
configured for all servers. When you look in Unified Reporting, do you see
anything about the rhosts under Database Status?

Thanks,

James

On Wed, Apr 20, 2016 at 1:07 PM, Nick Barnett 
wrote:

> Thanks Ryan.
>
> We have 3 CCM and 1 TFTP node in each of our two data centers. The main
> data center is here, and that is where our DRS sftp server (and publisher)
> is located. Nothing is using DNS right now, all of the servers are entered
> into CUCM as IP addresses... this cluster has been around for years. It was
> upgraded from 7.BeforeMyTime to 8.6 to 10.0.
>
>
>
> On Wed, Apr 20, 2016 at 11:54 AM, Ryan Huff  wrote:
>
>> Hi Nick.
>>
>> Let me ask you a few things;
>>
>> - How is the cluster laid out (how many nodes in the cluster and what
>> nodes are in which DC)?
>>
>> - Are you using DNS and if so, where is the DNS server located and do you
>> have redundant DNS in both DCs?
>>
>> - Where is your DRS server in relation to the cluster publisher (same DC
>> or no)?
>>
>> Thanks,
>>
>> Ryan
>>
>> On Apr 20, 2016, at 11:09 AM, Nick Barnett 
>> wrote:
>>
>> I'm wondering how many others have had as many issues with db
>> replication? It seems that any time we lose a connection to our 2nd data
>> center (even a 2 minute MPLS planned maintenance outage causes the issue),
>> our database synchronization has errors.  After a WAN blip, within an hour
>> or so, I get a message from RTMT about a subscriber being in "blocked"
>> state:
>>
>> %[AppID=Cisco Database Layer
>> Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change
>> notification client is busy (blocked). If the change notification client
>> continues to be blocked for 10 minutes, the system automatically clears the
>> block and change notification should resume successfully."
>>
>>
>> After that, if I run utils dbreplication status, it will have errors...
>> so then I run the "repair all" option and it fixes it. Then I'm good for a
>> few weeks until something else happens that starts the whole cycle over.
>>
>> Something else that happens after a WAN blip is that DRS begins to fail,
>> so we have to restart the master DRS and the subsequent DRS services on the
>> subs. Am I doing something wrong? Is this normal?
>>
>> I'm on CUCM 10.0.1.12900-2.
>>
>> Thanks,
>> Nick
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Constantly having db replication issues

[Nick Barnett]

Thanks Ryan.

We have 3 CCM and 1 TFTP node in each of our two data centers. The main
data center is here, and that is where our DRS sftp server (and publisher)
is located. Nothing is using DNS right now, all of the servers are entered
into CUCM as IP addresses... this cluster has been around for years. It was
upgraded from 7.BeforeMyTime to 8.6 to 10.0.



On Wed, Apr 20, 2016 at 11:54 AM, Ryan Huff  wrote:

> Hi Nick.
>
> Let me ask you a few things;
>
> - How is the cluster laid out (how many nodes in the cluster and what
> nodes are in which DC)?
>
> - Are you using DNS and if so, where is the DNS server located and do you
> have redundant DNS in both DCs?
>
> - Where is your DRS server in relation to the cluster publisher (same DC
> or no)?
>
> Thanks,
>
> Ryan
>
> On Apr 20, 2016, at 11:09 AM, Nick Barnett  wrote:
>
> I'm wondering how many others have had as many issues with db replication?
> It seems that any time we lose a connection to our 2nd data center (even a
> 2 minute MPLS planned maintenance outage causes the issue), our database
> synchronization has errors.  After a WAN blip, within an hour or so, I get
> a message from RTMT about a subscriber being in "blocked" state:
>
> %[AppID=Cisco Database Layer
> Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change
> notification client is busy (blocked). If the change notification client
> continues to be blocked for 10 minutes, the system automatically clears the
> block and change notification should resume successfully."
>
>
> After that, if I run utils dbreplication status, it will have errors... so
> then I run the "repair all" option and it fixes it. Then I'm good for a few
> weeks until something else happens that starts the whole cycle over.
>
> Something else that happens after a WAN blip is that DRS begins to fail,
> so we have to restart the master DRS and the subsequent DRS services on the
> subs. Am I doing something wrong? Is this normal?
>
> I'm on CUCM 10.0.1.12900-2.
>
> Thanks,
> Nick
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Constantly having db replication issues

[Ryan Huff]

Hi Nick.

Let me ask you a few things;

- How is the cluster laid out (how many nodes in the cluster and what nodes are 
in which DC)?

- Are you using DNS and if so, where is the DNS server located and do you have 
redundant DNS in both DCs?

- Where is your DRS server in relation to the cluster publisher (same DC or no)?

Thanks,

Ryan

On Apr 20, 2016, at 11:09 AM, Nick Barnett 
> wrote:

I'm wondering how many others have had as many issues with db replication? It 
seems that any time we lose a connection to our 2nd data center (even a 2 
minute MPLS planned maintenance outage causes the issue), our database 
synchronization has errors.  After a WAN blip, within an hour or so, I get a 
message from RTMT about a subscriber being in "blocked" state:


%[AppID=Cisco Database Layer 
Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change notification 
client is busy (blocked). If the change notification client continues to be 
blocked for 10 minutes, the system automatically clears the block and change 
notification should resume successfully."


After that, if I run utils dbreplication status, it will have errors... so then 
I run the "repair all" option and it fixes it. Then I'm good for a few weeks 
until something else happens that starts the whole cycle over.

Something else that happens after a WAN blip is that DRS begins to fail, so we 
have to restart the master DRS and the subsequent DRS services on the subs. Am 
I doing something wrong? Is this normal?

I'm on CUCM 10.0.1.12900-2.

Thanks,
Nick

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Constantly having db replication issues

[Nick Barnett]

I'm wondering how many others have had as many issues with db replication?
It seems that any time we lose a connection to our 2nd data center (even a
2 minute MPLS planned maintenance outage causes the issue), our database
synchronization has errors.  After a WAN blip, within an hour or so, I get
a message from RTMT about a subscriber being in "blocked" state:

%[AppID=Cisco Database Layer
Monitor][ClusterID=ProdVoiceCluster][NodeID=XXX1]: A change
notification client is busy (blocked). If the change notification client
continues to be blocked for 10 minutes, the system automatically clears the
block and change notification should resume successfully."


After that, if I run utils dbreplication status, it will have errors... so
then I run the "repair all" option and it fixes it. Then I'm good for a few
weeks until something else happens that starts the whole cycle over.

Something else that happens after a WAN blip is that DRS begins to fail, so
we have to restart the master DRS and the subsequent DRS services on the
subs. Am I doing something wrong? Is this normal?

I'm on CUCM 10.0.1.12900-2.

Thanks,
Nick
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] 8851 BLFs with Extesnion Mobility Work for random period and then freeze

[Erick Bergquist]

Seeing same issue.  Bug id CSCuu62252 still shows as other.  No fixed
in version yet.

Does anyone know if there is a ES firmware?

Thanks, Erick




On Fri, May 15, 2015 at 6:37 AM, Antonis Kouloglou  wrote:
> Hi all,
>
> i have recently upgraded my 8851 console with 36 expansion module to 10.3.1.
> CUCM is 9.1
> The user uses extension mobility.
> All 36 buttons have BLF speed dials.
> After the user logs in to her profile, BLF works fine but after a random
> period ( 1hour maybe less) the leds freeze and stop working.
> They freeze to a state showing other users available and other not.
> Call list BLFs work always so on the screen, user has correct info.
>
> in 10.2.2.1 i had the same issues (among others) that is why i have
> upgraded.
>
> Has anyone seen that?
>
> BR
>
> Antonis
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip