Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Historical Reporting Client Login Failure - UCCX 7.0(1)

We're experiencing intermittent login failures with the Historical Reporting Client, extract from the log file below:

1: 28/04/2010 11:58:25 %CHC-LOG_SUBFAC-3-UNK: Error # 35761 ,Description= Request timed out ,LastDllError= 0

2: 28/04/2010 11:58:25 %CHC-LOG_SUBFAC-3-UNK:Authentication response was NOT received from (http://<ip address>/histRepWebSrvrComp/histRepClientsServlet)

3: 28/04/2010 11:58:25 %CHC-LOG_SUBFAC-3-UNK:Login Error | Invalid server name or IP address. Check the server name or IP address and login again.

4: 28/04/2010 11:58:30 %CHC-LOG_SUBFAC-3-UNK:Authentication response was NOT received from (http://ip address/histRepWebSrvrComp/histRepClientsServlet)

5: 28/04/2010 11:58:30 %CHC-LOG_SUBFAC-3-UNK:Login Error | Invalid server name or IP address. Check the server name or IP address and login again.

6: 28/04/2010 11:58:30 %CHC-LOG_SUBFAC-3-UNK:Connection to web server failed due to: 12017 : Operation cancelled

7: 28/04/2010 11:59:05 %CHC-LOG_SUBFAC-3-UNK:Connection to web server failed due to: 12017 : Operation cancelled

8: 28/04/2010 11:59:05 %CHC-LOG_SUBFAC-3-UNK:Failed to load authentication response due to empty XML buffer from authentication servlet)

9: 28/04/2010 11:59:05 %CHC-LOG_SUBFAC-3-UNK:Login Error | Invalid server name or IP address. Check the server name or IP address and login again.

Does anyone know why this may be happening as it's driving the customer mad. User can usually login after a few attempts.

The authentication timeout is set to 15 seconds, surely this is more than enough time or should we increase the timer?

Any advice much appreciated.

Everyone's tags (2)
8 REPLIES

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

Hi Jubug

Can you please state what version your on exactly with the sr for UCCX.

- Check the following and test again and let me know the results

On the UCCX
Make sure that your routable nic is the first choice in the nic binding order.

Control Panel-->Network Connections-->Advanced-->Advanced Settings etc.

On the workstation

Under your windows installation/system32/drivers/etc

Edit your host file and make sure you have the UCCX ip address/host name listed.

I want to take out the possiblity of your DNS playing up, as DNS will never retry a second attempt within 15 seconds.

New Member

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

We're using CCX 7.0(1) with no service releases installed as yet. There's only one active nic, the other disabled during set up so we're routing through the active nic as first choice.

I've increased the authentication timeout to 150 seconds whilst we're looking into this which has masked the issue. Looking at the network config on the client pc we noticed a difference between a client pc that's working and the one that isn't which is the DNS server list so we're checking the DNS configs so fingers crossed this will resolve the issue.

Thx

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

By default, Cisco's Win2k3 media will placed the disabled NIC on top of the active NIC.  Just FYI, you may want to double check this.

Anthony Holloway

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

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

i am having the same issue. have you been able to resolve this? i opened a tac case but they have not yet offered a solution?

Thanks

Chris

New Member

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

We never fully got to the reason why authentication was timing out intermittantly although we believe it had something to do with the customer network as the user could login with no problem over VPN or in other locations within their network however we've found that the workaround is sufficient (albeit it does sometimes take a while to logon).

The workaround we used was:

The Historical reporting login authentication timer settings needs extending from the default of 15 seconds. Do this by editing the HrcConfig file which should reside in C:\Program Files\Cisco UCCX Historical Reports. Update the timeout setting to 150 seconds: AuthReqTimeOut= 150

I hope this helps.

Cisco Employee

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

This doesn't really sound like you got a resolution.  I would recommend a couple of items based on experience.

     1.) Upgrade to UCCX 7.0SR5.  This is a very stable release of code with few open bugs or caveats agaist it.

     2.) Verity that the active NIC is indeed at the top of the bindings order.  Just having it active isn't enough, there needs to be the further test of moving to the top of the bindings order.

     3.) Verify that the hosts file on the UCCX server(s) has the external IP and hostname of the server in it.

     4.) Check the remote locations to verify that the network is correctly configured, there are no line errors on the WAN circuits, no misconfiguration on the switch/router ports and that QOS is in place across the network.

     5.) Try to take a test system that is on the same network as the one having HRC errors.  See if it's seeing the issues.  If not, progressively move out to other offices/locations until you replicate the issue and then see what has changed.  Something there should hopefully point to the cause of the error.

     6.) Finally, you may want to consider creating external data warehouse servers so that your UCCX servers aren't serving up the HRC data.

Let me know if these make sense/have been tried, and what the results are.  Thank you.

Regards,

Robert W. Rogier

New Member

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

Hi Robert

Thanks for the response and all very good suggestions which should help Chris narrow down his particular issue.

It's been about a year since we last looked at this so I'd quite forgotten most of the diagnostics we'd done however we did go through most of the same diagnostics ourselves but the resolution was hampered due to the fact we support the telephony/WAN and another third party supports the desktops and LAN infrastructure so after months of to and fro with the customer and their third party (and many, many man hours) we eventually left the risk with the customer and investigations never progressed any further.

1.) Upgrade to UCCX 7.0SR5.  This is a very stable release of code with few open bugs or caveats against it.

            - Agreed. We also ran into other bugs which required an upgrade.

2.) Verify that the active NIC is indeed at the top of the bindings order.  Just having it active isn't enough, there needs to be the further test of moving to the top of the bindings order.

            - We did check this.

3.) Verify that the hosts file on the UCCX server(s) has the external IP and hostname of the server in it.

            - Did this too.

4.) Check the remote locations to verify that the network is correctly configured, there are no line errors on the WAN circuits, no misconfiguration on the switch/router ports and that QOS is in place across the network.

            - This part of the investigation stalled due to another 3rd party supporting the onsite network however no WAN issues were found.

5.) Try to take a test system that is on the same network as the one having HRC errors.  See if it's seeing the issues.  If not, progressively move out to other offices/locations until you replicate the issue and then see what has changed.  Something there should hopefully point to the cause of the error.

            - We did this also, using my laptop I connected from various locations and even when using the same network connection as the end user had no problems, we did note the successful connection attempts used a slightly different network route/DNS/WINS however again got nowhere with the third party supporting this aspect of the network.

6.) Finally, you may want to consider creating external data warehouse servers so that your UCCX servers aren't serving up the HRC data.

            - Not an option for this customer, again this aspect of the service is a different third party on their own network and customer not willing to pay for additional servers for the telephony estate to provide this functionality when they only have a few CCX users.

Regards

June

New Member

Re: Historical Reporting Client Login Failure - UCCX 7.0(1)

TAC had me go through the same steps listed in this post. Nothing helped. When all else fails reboot so we did and HRC started working. TAC was not able to determine the root cause. My guess is that this will happen again at some point.

2602
Views
5
Helpful
8
Replies
CreatePlease to create content