Ask the Expert: Deployment and Troubleshooting Cisco Unified Con

ciscomoderator · ‎04-19-2013

With Anirudh Ramachandran and Abhiram Kramadhati

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about the latest advancements in Cisco UCCX (such as the integration of Cisco Social Miner to provide agent chat and better reporting using the Cisco Unified Intelligence Center), as well as the existing features of Historical Reporting, custom reporting using the historical database, Agent Email services, JTAPI integration with CUCM, and the HA over WAN cluster mechanism.

Anirudh Ramachandran is a customer support engineer at the Cisco Backbone Technical Assistance Center in Bangalore, India. Working in the Asia-Pacific time zone for the last two years, he focuses on Cisco Unified Contact Center Express issues and specializes in Linux, JTAPI/CTI integration, and UCCX system and database issues. He holds the CCNP Voice and UCCX Specialist certifications, and is also a Red Hat Certified Engineer. Anirudh writes tools and automates bug workarounds for UCCX in addition to working on TAC service requests, and currently has authored and co-authored seven such tools. Anirudh graduated from the National Institute of Technology Karnataka with a Bachelor of Technology in Computer Engineering.

Abhiram Kramadhati is an engineer with the Contact Center Backbone team in the Asia Pacific timezone. He has been working with UCCX since he started with Cisco 2 years ago. During his time at Cisco, he has built his expertise around UCCX Telephony applications, JTAPI integration, UCCX system behaviour, LDAP components and also UCCX as IPIVR in UCCE environments. He also works on other technologies including Unified Communications Manager and UCCE. He has been involved in many technical escalations in the region. Abhiram is a Telecommunications engineer from Bangalore, India.

Remember to use the rating system to let Anirudh and Abhiram know if you have received an adequate response.

They might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Collaboration, Voice and Video Contact Center subcommunity discussion forum shortly after the event. This event lasts through May 3, 2013. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

Anthony Holloway · ‎04-20-2013

Thank you for holding this event gentlemen.

To start things off easy, could you explain the reasoning behind only allowing customers to set the External Call Forward Busy setting on UCCX Triggers? My version is 8.5(1)SU2, but I have been working around this feature since v4.5. Admittidly, I have not used UCCX 9x, so I'm not aware if the behavior has changed or not.

Example

I understand that I can set the CFB Internal within CUCM, but then my JTAPI sync throws a fit, and my custom setting will be erase at the next resync.

Not being able to set the CFB Internal limits the contengency planning for internal applications. I.e., Help Desk or Receptionists. And in some cases, internal employees, calling typically external facing applications. I.e., I work for the same company for which I have health insurance through, and sometimes I need to call the DID of the customer service department from my desk.

Thanks again, and I look forward to the rest of this thread.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Abhiram Kramadhati · ‎04-22-2013

Hi Anthony,

Thanks for the question.

This is an interesting requirement, since the UCCX trigger's configuration is translated only to the Call Forward Busy External setting on the CUCM.

Trigger creation:

144768: Apr 22 21:54:23.789 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet.updateNewTrigger() - Creating a new Trigger :1234

144876: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet routePoint = 1234

144877: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet description = testt

144878: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet deviceName = testt

144879: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet devicePool = {1B1B9EB6-7803-11D3-BDF0-00108302EAD1}

144880: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet devicePoolName = Default

144881: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet callingSearchSpace =

144882: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet callingSearchSpaceName = None

144883: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet redirectCSS = default

144884: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet location = {29C5C1C4-8871-4D1E-8394-0B9181E8C54D}

144885: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet locationName = Hub_None

144886: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet partition =

144887: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet partitionName = None

144888: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet voiceMailProfile =

144889: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet voiceMailProfileName = None

144890: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet forwardBusyVM =

144891: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet forwardBusyDestination =

144892: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet forwardBusyCSS =

144893: Apr 22 21:54:23.884 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerServlet forwardBusyCSSName = None

144953: Apr 22 21:54:23.913 IST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-569.CCMLineSOAPAdmin: try makeRequest() on AXL: 10.106.113.142, AXLUser: axl, AXLPassword: XXXXXX

144954: Apr 22 21:54:23.913 IST %MADM-LIB_AXL-7-UNK:CCMVersionSOAPAdmin.getAXLVersion():7.1

144955: Apr 22 21:54:23.913 IST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-569.CCMLineSOAPAdmin: makeRequest() - Start REQUEST ====================

144956: Apr 22 21:54:23.913 IST %MADM-LIB_AXL-7-UNK:POST /axl/ HTTP/1.1

Connection: keep-alive

Host: 10.106.113.142:8443

Authorization: Basic YXhsOmF4bA==

SOAPAction: "CUCM:DB ver=7.1"

Accept: text/*

Content-type: text/xml; charset="utf-8"

Cache-Control: no-cache

Pragma: no-cache

Content-length: 440

http://schemas.xmlsoap.org/soap/envelope/">

MADM_569

1234CRS Line descriptionCallPark

144957: Apr 22 21:54:23.913 IST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-569.CCMLineSOAPAdmin: makeRequest() - End REQUEST ==================

144958: Apr 22 21:54:23.914 IST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-569.CCMLineSOAPAdmin: getSocket: MADM_LIB_AXL_AXL_SOCKET_POOL-0-79[TLS_RSA_WITH_AES_128_CBC_SHA: Socket[addr=10.106.113.142,port=8443,localport=44913]]

144987: Apr 22 21:54:24.195 IST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-570.CCMCTIRoutePointSOAPAdmin: makeRequest() - Start REQUEST ====================

144988: Apr 22 21:54:24.195 IST %MADM-LIB_AXL-7-UNK:POST /axl/ HTTP/1.1

Connection: keep-alive

Host: 10.106.113.142:8443

Authorization: Basic YXhsOmF4bA==

SOAPAction: "CUCM:DB ver=7.1"

Accept: text/*

Content-type: text/xml; charset="utf-8"

Cache-Control: no-cache

Pragma: no-cache

Content-length: 839

http://schemas.xmlsoap.org/soap/envelope/">

MADM_570

testttesttCTI Route PointCTI Route PointCTI Route PointSCCPUserRing1000010000

144989: Apr 22 21:54:24.195 IST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-570.CCMCTIRoutePointSOAPAdmin: makeRequest() - End REQUEST ==================

145014: Apr 22 21:54:24.647 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerUtil.createRPAndLineOnCCM() - CTI RP created.

145015: Apr 22 21:54:24.647 IST %MADM-ADM_CFG-7-UNK:JTAPITriggerUtil.createRPAndLineOnCCM() - Created a Route Point = 1234

As you would aready know, the UCCX will send an AXL request (within the SOAP envelope) to the CUCM to create this RP. Looking at the existing code, there does not seem to be a method where we are differentiating between CFB_internal and CFB_external while sending this request.

We have taken this as an enhancement request and also spoken to the business unit about the same. It has been added to the roadmap, we will reach out to you offline to understand the business case so that the process can be expedited if needed.

Keep the questions coming

Cheers,

Abhiram Kramadhati

Anthony Holloway · ‎04-22-2013

Thank you for responding to my question!

The first thing I want to show you is the AXL request to update the CFB field:

7853082: Apr 22 12:38:28.221 EST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-1954.CCMLineSOAPAdmin: makeRequest() - Start REQUEST ====================
7853083: Apr 22 12:38:28.221 EST %MADM-LIB_AXL-7-UNK:POST /axl/ HTTP/1.1
Connection: keep-alive
Host: :8443
Authorization: Basic 
SOAPAction: "CUCM:DB ver=7.0"
Accept: text/*
Content-type: text/xml; charset="utf-8"
Cache-Control: no-cache
Pragma: no-cache
Content-length: 639

http://schemas.xmlsoap.org/soap/envelope/">

MADM_1954

{153134E4-543C-D744-9707-49048B86BFB2}

{60E768D2-DE7F-4C0D-954C-FDA75D534C50}

false

1234


7853084: Apr 22 12:38:28.221 EST %MADM-LIB_AXL-7-UNK:AXL-ExecutionCmd-1954.CCMLineSOAPAdmin: makeRequest() - End REQUEST ==================

Now that we see that the callForwardBuy attribute is being used, and nothing else, we can then go to the AXL documentation and note that there is also a callForwardBusyInt attribute which applies to the Internal setting; whereas the former is the External setting, though not specifically stated in its name. I.e., callForwardBusyExt

Source: http://developer.cisco.com/axl/Files/AXLSoap_updateLine.html

Off the top of my head I would say there's three options here:

Change the wording on the AppAdmin page to state "External" in the field name
Change the AdppAdmin UI such that administrators can set Internal and External CFB settings indepently
Change the AXL integration to use both callForwardBusy and callForwardBusyInt behind the scenes, setting both to the single value provided by the administrator. But from seeing your logs, it looks like that might mean a change to the JTAPI implementation as well. Not positive though.

I like number 2 myself, because you both overcome the misconception about which one it's setting, and also allow the administrator to independtly set each one, offering a superior solution to the user.

The use case for an Internal CFB here is simple: not all application are externally facing. E.g., An internal IT helpdesk.

If you are going to offer the ability to CFB the trigger at all, then why discriminate between Internal and External callers.

I realize that there is a much larger issue at hand here, and that is when would I even call foward a Trigger, followed by when would UCCX even return the appropriate cause code to CUCM to casue a route to the CFB destination.

E.g., I would want to forward all triggers to an offsite call center when the IVR licensing is exceeded. Another example: forward calls to an OnCall tech when Help Desk triggers sessions are exceeded.

I hope that helps add to the discussion. And again, thank you so much for taking the time to answer questions from the community!

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Abhiram Kramadhati · ‎04-22-2013

Hi Anthony,

Please find my response below:

Off the top of my head I would say there's three options here:

Change the wording on the AppAdmin page to state "External" in the field name
Change the AdppAdmin UI such that administrators can set Internal and External CFB settings indepently
Change the AXL integration to use both callForwardBusy and callForwardBusyInt behind the scenes, setting both to the single value provided by the administrator. But from seeing your logs, it looks like that might mean a change to the JTAPI implementation as well. Not positive though.

The first option is very straightforward and cosmetic, and it should be something which can be taken care of. I understand that this is something which adds more clarity to the admin who is making the changes.

The second option is the one which looks to be a little more complicated than the third: this is because this will involve the tweaking of both the AppAdmin component and the backend AXL. The third option will just be the changing of the backend AXL to copy the CFB entry and update both CFB_I and CFB_E, but will not give the flexibility of setting CFB_I and CFB_E seperately.

I have spoken to Ryan and he will be reaching out to you (if not already done) to understand the business case. That will help us in taking a call on the options available.

Thanks for your detailed response and the questions!

Cheers,

Abhiram Kramadhati

kbenoit33 · ‎04-22-2013

Greetings,

Thank you holding this event!

Regarding HA over WAN.

We've recently had a couple of experiences where the 2nd node has gone down for extended periods. Generally the second node is down because of power issues, and it has taken as long as 48 hours to restore power to the facility.

So, when the second node goes down we lose the capability to reskill agents. It is also highly recommended we do not make any changes that could cause inconsistencies with the database. So, essentially, we are unable to adapt to the circumstances.

We're curious. Are there any plans to include some kind of temporary disaster functionality to the database so we can handle things like this? Any reskilling, or changes to prompts, would be a temp thing and could "go away" when the 2nd node came back.

Thanks for your time and attention!

Keith

aniramac · ‎04-22-2013

Hi Keith,

Thanks for posting!

When intra-cluster communication is down, go to UCCX Serviceability for the Publisher and to Tools > Datastore Control Center > Replication Servers. Once there, click on "Disable CDS and HDS" and wait till the button changes to "Enable CDS and HDS". You may get an error saying that the Subscriber is unreachable, but the change in the button text will tell you that this activity is done. Now you will be able to make config changes.

Page URL: https :// /uccxservice/dsreplservers.htm?method=getreplicationservers

Normally, this will disable the Config Datastore and Historical Datastore on the Subscriber, thus breaking the replication of config and historical data. When intra-cluster communication is down, this will just ensure that the Publisher does not try reaching out to the Subscriber to update config (and historical) data.

When config replication is active but UCCX intra-cluster communication is down, configuration changes cannot be made. This includes changes to the RmCm resources: reskilling comes under this, as you will know. Disabling the CDS will let you make the changes.

Once the Subscriber is back up and running, go back and click on "Enable CDS and HDS", and wait till the button changes back to "Disable CDS and HDS". Then, click on "Reset replication". The changes you made will be synced across, as will the historical data.

Take a look at the Expected Behavior During A Failover document for UCCX 9.0 for further details about expected behavior during failovers and island mode.

Once again, keep 'em coming!

Thanks & Regards,

Anirudh

"Protocol, then product"

Thanks & Regards, Anirudh "Protocol, then product"

jspilde · ‎04-22-2013

Hello,

Thank you for this opportunity to ask questions. We are running UCCX 8.5.1 and quickly found that CAD logins are case sensitive. Our CUCM userIDs contain capitalized initials in the format FLast. As we look to enable LDAP with CUCM, this format will be required. Since CAD logins differ from most OS's/apps in that the userIDs are case sensitive, this becomes a huge training issue as users are unaccustomed to logging in this way. Is there a way to remove the case sensitivity and/or will this case sensitivity go away in future UCCX versions?

Thanks,

Jason

Abhiram Kramadhati · ‎04-22-2013

Hi Jason,

Thanks for your question!

From your question, I would appreciate if you could provide more information on what you mean by "

Since CAD logins differ from most OS's/apps".

Eitherway, the UCCX relies on the CUCM for the authentication. What happens in the backend (LDAP etc.) is immaterial to the UCCX. For example, take this username: sart06

The below log snippets shows the AXL communication used by UCCX to send the authentication request to the CUCM:

544802: Apr 16 20:49:06.708 EDT MADM-LIB_AXL-7-UNK AXL-ExecutionCmd-187.CCMUserAuthenticationSOAPAdmin: try makeRequest() on AXL: 10.191.32.61, AXLUser: administrator, AXLPassword: XXXXXX

544803: Apr 16 20:49:06.708 EDT MADM-LIB_AXL-7-UNK CCMVersionSOAPAdmin.getAXLVersion():7.0

544804: Apr 16 20:49:06.708 EDT MADM-LIB_AXL-7-UNK AXL-ExecutionCmd-187.CCMUserAuthenticationSOAPAdmin: makeRequest() - Start REQUEST ====================

544805: Apr 16 20:49:06.708 EDT MADM-LIB_AXL-7-UNK POST /axl/ HTTP/1.1

Connection: keep-alive

Host: 10.191.32.61:8443

Authorization: Basic YWRtaW5pc3RyYXRvcjpWb2lwdGVjaDE=

SOAPAction: "CUCM:DB ver=7.0"

Accept: text/*

Content-type: text/xml; charset="utf-8"

Cache-Control: no-cache

Pragma: no-cache

Content-length: 277

http://schemas.xmlsoap.org/soap/envelope/">

MADM_187

sart06XXXXXX ;

544806: Apr 16 20:49:06.708 EDT MADM-LIB_AXL-7-UNK AXL-ExecutionCmd-187.CCMUserAuthenticationSOAPAdmin: makeRequest() - End REQUEST ==================

544830: Apr 16 20:49:16.945 EDT MADM-LIB_AXL-7-UNK AXL-ExecutionCmd-187.CCMUserAuthenticationSOAPAdmin: makeBlockingRequest() - Start RESPONSE ====================

544831: Apr 16 20:49:16.945 EDT MADM-LIB_AXL-7-UNK AXL-ExecutionCmd-187.CCMUserAuthenticationSOAPAdmin: http://schemas.xmlsoap.org/soap/encoding/" ; xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/">

http://www.cisco.com/AXL/API/7.0" ; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance">true0 ;

544832: Apr 16 20:49:16.945 EDT MADM-LIB_AXL-7-UNK AXL-ExecutionCmd-187.CCMUserAuthenticationSOAPAdmin: makeBlockingRequest() - End RESPONSE ==================

As you can see, the UCCX does not really play a part in the actual authentication; it requests the CUCM to do the same for it. In summary, the requirement of the CAD login credentials is something which comes from the CUCM since the CUCM is the entity which will authenticate the user. The UCCX just passes the credentials through an AXL request to the CUCM. It does not matter to the UCCX whether the CUCM is integrated to the AD or it is local authentication, as long as the response comes within the timeout.

Therefore, the case-sensitivity of the credentials is not controlled by the UCCX but rather something which needs to have the blessing of the CUCM.

I hope your query has been addressed, but please let me know if you need any further clarification.

Cheers,

Abhiram Kramadhati

jspilde · ‎04-22-2013

Hi,

In regard to "most OS's/apps" Most operating systems and applications I have used (assuming my login is JSpilde), allow me to login as JSPILDE, JSpilde, or jspilde - only the password is case sensitive.

With the agent desktop application, I must login as JSpilde if my CUCM userid is JSpilde. I cannot login as jspilde or JSPILDE. If I login to CUCM /ccmadmin or /ccmuser or UCCX appadmin I can login as JSPILDE, jspilde, or JSpilde.

Most users are used to logging into Windows and applications with the format jspilde. When they try to login to CAD and it requires the FLast format, it often results in a call to the IT help desk.

Thanks,

Jason

Aaron Harrison · ‎04-22-2013

Hi

That's funny - my CallManager does not enforce case-sensitive usernames on CCMUser, CCMAdmin or any other 'user facing' page. It DOES enforce case sensitivity for the OS/DRF/CLI methods of access, which in itself is quite annoying.

And by 'my CallManager' I mean all the CUCMs I've deployed over the years..

I'd strongly agree that the case sensitivity of CAD is a bad thing, it goes against common practice in virtually any other application.

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

aniramac · ‎04-23-2013

Hi Aaron,

Checked it again, and you are right. "flast" and "FLast" both log in just fine on CCMUser.

We'll look into what goes on during CAD login and get back.

Thanks & Regards,
Anirudh
"Protocol, then product"

Thanks & Regards, Anirudh "Protocol, then product"

Abhiram Kramadhati · ‎04-23-2013

Hi Jason/Aaron,

My apologies, I completely misread the question and the requirement. I read it more as a requirement asking for local UCCX authentication.

Here is the logical flow of events(in short) in an agent login:

CAD will connect to the UCCX (LRM service) to check if there are licenses available. If it fails at this stage, we get the error "License Server is Down". The login screen is not even provided.
Once the user enters the userid/password, the same is sent to the UCCX. Now, the user is searched within the LDAP database of the UCCX. If the user is not present, we get the "Invalid User" error.
The AXL request is sent to the CUCM for authentication. Post that, the CTI Control is opened on the agent device. Here we either get the "Authentication fail" or the "Error with CTI or RMJTAPI" respentively if either fails.
User configuration is loaded from the LDAP of UCCX i.e. agent specific config such as integrated browser setting etc. and also the connection is made to all the services such as recording, chat, playback and so on.

Take the example of user FLast. The 'limitation' for us comes in the second step. The user object in the UCCX LDAP database is created with the id FLast. Therefore, when the agent enters flast we get the error "invalid user". The case sensitivity is not defined by AXL, since the user can login to the UCCX AppAdmin page with either FLast or flast (assuming the user is an admin also). Let me give you a peek at the UCCX LDAP database:

If you notice the empID, it is stored as FLast. Therefore, when the user enters flast; the comparison with the LDAP database fails and authentication is not even attempted.

For FLast:

2013-04-23 12:45:22:847 DEBUG [0xa94] AgentConnectionManager.cpp[545] CAgentConnectionManager::RetrieveAgentProfile: ACM0545 Name: First Last

2013-04-23 12:45:22:847 DEBUG [0xa94] AgentConnectionManager.cpp[546] CAgentConnectionManager::RetrieveAgentProfile: ACM0546 Desktop ID: FLast

2013-04-23 12:45:22:847 DEBUG [0xa94] AgentConnectionManager.cpp[547] CAgentConnectionManager::RetrieveAgentProfile: ACM0547 Login Name: FLast

2013-04-23 12:45:22:847 DEBUG [0xa94] AgentConnectionManager.cpp[548] CAgentConnectionManager::RetrieveAgentProfile: ACM0548 Agent work flow group: default

2013-04-23 12:45:22:847 DEBUG [0xa94] AgentConnectionManager.cpp[549] CAgentConnectionManager::RetrieveAgentProfile: ACM0549 Agent team: Default

2013-04-23 12:45:22:847 DEBUG [0xa94] AgentConnectionManager.cpp[550] CAgentConnectionManager::RetrieveAgentProfile: ACM0550 Agent is supervisor?: No

2013-04-23 12:45:22:847 DEBUG [0xa94] AgentConnectionManager.cpp[580] CAgentConnectionManager::RetrieveLicense: Requesting license type

2013-04-23 12:45:22:971 INFO [0xa94] DESK1101 RetrieveLicense: Verify agent license.

2013-04-23 12:45:23:252 DEBUG [0xa94] AbstractLRMClient.cpp[48] lrm::AbstractLRMClient::checkoutLicense: Checkout license succeeded.

2013-04-23 12:45:23:252 DEBUG [0xa94] AgentConnectionManager.cpp[580] CAgentConnectionManager::RetrieveLicense: End.

2013-04-23 12:45:23:252 DEBUG [0xa94] AgentConnectionManager.cpp[918] CAgentConnectionManager::LoadConfiguration: Begin.

2013-04-23 12:45:23:377 INFO [0xa94] DESK1119 LoadConfiguration: Load the agent configuration.

For flast:

2013-04-23 12:44:59:752 DEBUG [0xcf8] Configuration.cpp[1559] GetLDAPProfileInt: CC1559 Could not read [PhoneNumbersApp::PhoneBook::CurListType] from LDAP with error Could not find specified entry.

2013-04-23 12:44:59:752 DEBUG [0xcf8] LCLDAP.cpp[466] ldap_client::LCLDAP::Get: Failed to find base

Notice the difference: for flast, the object is not identified since the userid (empID) which is used to compare does not match. This 'limitation' can be addressed by tweaking both the LDAP database structure and the logic to check the agent's existence, becasue the AXL authentication works fine. However, I am sure there are more factors which will have to be accounted for when considering this change. I have documented this as an enhancement request and can be tracked under CSCug51416.

Cheers,

Abhiram Kramadhati

billmatthews · ‎04-23-2013

Thanks very much for this opportunity.

I'm trying to document the implications of various service restarts in a UCCX 8.5 HA deployment. In Serviceability, Control Center - Network Services, there are a number of services that can be restarted. I'm trying to document/understand the production implications of restartng each. For example some might impact CAD agents, but not callers in queue. As suggested by Anthony Holloway I am trying to setup a lab and test this all myself.

But I was wondering if Cisco has a document about the production implications of restarting various services.

Bill

aniramac · ‎04-23-2013

Hi Bill,

Saw your other post just yesterday.

Restarting any service will, of course, cause its functionality to become unavailable until it comes back up. I understand that you would like to get more details on the relationship of services to each other, and to the UCCX features and functionality.

Reading through the CCX Serviceability Admin Guide and the SRND will give you the best picture of this. For example, page 59 of the SRND ("Unified CCX Engine and Database components") will give you a description of what the Unified CCX Engine service is, and what functionality it provides.

A lab HA cluster, printouts of these 2 guides, and a gallon of coffee is what will help you best here. Of course, you are welcome to get back with additional queries here as well as on the Contact Center forum, we would love to help more! Here are two to get you started:

1. "Why does restarting the Cisco Unified CCX Engine kick out my agents, supervisors, and enqueued calls, but does not affect calls already with agents and database replication?"

2. "While the Cisco Unified CCX Cluster View Daemon is restarting, why are the web admin pages inaccessible? Why can't I control that service from the GUI?"

Thanks & Regards,

Anirudh

"Protocol, then product"

Thanks & Regards, Anirudh "Protocol, then product"

Ask the Expert: Deployment and Troubleshooting Cisco Unified Contact Center Express (UCCX) Deployments