09-06-2018 01:36 PM - edited 03-14-2019 06:28 PM
50002 errors can never be eliminated entirely, but how do you know you have done enough to eliminate them? What is normal vs excessive? We have developed a metric that can be shared across Cisco partners and customers that will help us all determine where we stand in the industry.
Run the query below against your UCCE instance and share the results. This query basically provides statistics and ultimately a ratio of 50002 errors per agent hour logged in (50002dedups_Hours_%).
select
convert(date, Date) Date,
count(1) Agents,
1.0*nullif(sum([50002_dedups]), 0) / nullif(sum(HoursLoggedIn), 0) [50002dedups_Hours_%],
sum(Logins) Logins,
sum(HoursLoggedIn) HoursLoggedIn,
sum([50002_dedups]) [50002_dedup],
sum([50002s]) [50002s]
from
(
select
*,
datediff(HH, LoginDate, LogoutDate) HoursLoggedIn -- hours logged in
from (
select
SkillTargetID,
convert(date, DateTime) Date,
max(case when Event=1 then 1 else 0 end) Logins, -- only count 1 login per agent per day
min(case when Event=1 then aed.DateTime else null end) LoginDate,
max(case when Event=2 then aed.DateTime else null end) LogoutDate,
sum(case when Event=3 and ReasonCode=50002 then 1 else 0 end) [50002s],
sum(case when Event=3 and ReasonCode=50002 and Duration<>900 and Duration<>1800 then 1 else 0 end) [50002_dedups] -- remove duplicate 50002 (15 min interval = 900 seconds, 30 min interval = 1800 seconds)
from Agent_Event_Detail aed
where aed.DateTime >= convert(date, getdate()-14) -- last 14 days
group by aed.SkillTargetID, convert(date, DateTime) -- group by agent, then day
) A
) B
group by convert(date, Date)
order by convert(date, Date)
I get asked about this error code everywhere I go, and when it is not correlated to a server-side or network event, it is often a rat hole that never seems to end. Use the results of this query to help determine if it is worth the effort or not to investigate causes of 50002 in your environment. The power of this data is when you share your results with the community. Thanks for participating.
04-01-2019 01:01 PM
04-11-2019 06:45 AM
04-11-2019 09:35 AM
In the thread prior, you can see other statistics from other customers. Yours look in line, but you do have some outliers that you might want to investigate root cause. For example: 10/04/2019 767 0.105475649760 731 3963 418 745. You had a low of 2% and high of 10%. What happened on 10/4/2019 that caused a significant increase? You might dig deeper into that day and see of a large number of agents threw a 50002 at the same point in time, suggesting a network issue or momentary failure of some component of your system.
04-22-2019 12:32 PM
Yes 10/04/2019 we had a network issue. I would like to now if my statics is normal or I need investigate anything, can you help me with this question? Case this to be normal, is there any Cisco's document talking about? I need show to my internal customer.
04-22-2019 01:23 PM
I am not a Cisco employee so cannot provide you any official answer. If you read the thread above, you will see several other statistical outputs which you can compare your stats to. In my opinion, your stats (with the exception of 10-Apr-2019) appear at the low end of what people have posted, meaning, in my experience, not worth investigating. In my case, the business/customer did not accept that answer, so what we did to investigate is run a dynamic report of 50002 errors with agent name/extension and timestamp for about 4 hours from morning to lunch, then after lunch, went around with a pad of paper and interviewed each agent with a 50002 and categorized the responses we got. We got things like "oh, yeah, I had my finesse window active in the background, accidentally, clicked on a link from a spreadsheet, and it opened the link in the active finesse window" or "my finesse tab just disappeared". things like that. We then provided the results to the business and indicated that it is nearly impossible to prevent agents from these types of behaviors and they stopped asking about them. If we found 50002 to all occur at a specific point in time, then that is likely a server/network side event cause and we always investigate those without being asked. Hope that helps.
10-29-2019 08:19 AM
Date Agents 50002dedups_Hours_% Logins HoursLoggedIn 50002_dedup 50002s
2019-10-15 964 0.038439205667 957 8611 331 484
2019-10-16 985 0.050887295804 981 8509 433 568
2019-10-17 949 0.035337423312 943 8150 288 437
2019-10-18 908 0.033250098567 897 7609 253 363
2019-10-19 78 0.042635658914 71 516 22 168
2019-10-20 70 0.060150375939 63 399 24 204
2019-10-21 991 0.046065479609 986 8705 401 611
2019-10-22 991 0.035629453681 986 8841 315 568
2019-10-23 1008 0.035935130089 1002 8571 308 584
2019-10-24 963 0.038165137614 957 8175 312 481
2019-10-25 914 0.035997882477 904 7556 272 448
2019-10-26 92 0.057082452431 77 473 27 204
2019-10-27 62 0.031545741324 53 317 10 142
2019-10-28 985 0.035203270497 983 8806 310 487
2019-10-29 884 0.805825242718 862 103 83 148
07-16-2020 05:45 AM
Hi
Statistics from our clients:
Date Agents 50002dedups_Hours_% Logins HoursLoggedIn 50002_dedup 50002s
2020-07-02 519 0.151751953617 504 3967 602 1658
2020-07-03 491 0.115311909262 475 3703 427 1273
2020-07-04 59 0.127562642369 54 439 56 210
2020-07-05 47 0.121875000000 41 320 39 211
2020-07-06 496 0.125062656641 490 3990 499 852
2020-07-07 505 0.100375469336 495 3995 401 956
2020-07-08 506 0.118794326241 495 3948 469 1109
2020-07-09 505 0.121036738802 494 3974 481 1376
2020-07-10 463 0.127200454287 451 3522 448 1135
2020-07-11 71 0.216157205240 60 458 99 715
2020-07-12 52 0.292452830188 42 318 93 747
2020-07-13 472 0.138076416337 462 3795 524 1226
2020-07-14 510 0.120029455081 497 4074 489 1379
2020-07-15 496 0.125908618899 482 3852 485 1395
2020-07-16 472 0.674321503131 458 479 323 838
09-29-2020 05:03 PM
Hi folks,
I work at a Cisco Partner and have used this query and this thread as an excellent resource. Thank you OP for the work on this, and thanks to those who've contributed results, which are only valid as a comparison. The more examples, the better.
I did also add <>1799 and <>1801 to account for a few more dups.
I've seen numbers ranging from low single digit percentages, to high teens. Currently working with a customer at around 10 - 12% 50002s, with many remote or at-home Agents. These Agents are competing for bandwidth during the Covid-19 pandemic with their children at home participating with Zoom or other e-learning applications, Netflix or Pandora users, on-line gaming, etc. Trying to nail down individual reasons for 50002's is difficult, if not impossible. Finesse client or server logs, CTIServer, PIM/OPC, or any other ICM/UCCE log can only tell you THAT the client disconnected, with some indication of a session timeout, etc. But almost never WHY, unless, as noted, there are a cluster of Agents all affected around the same time.
I just delete the rows for weekend days:
Date Agents 50002dedups_Hours_% Logins HoursLoggedIn 50002_dedup 50002s
---------- ----------- --------------------------------------- ----------- ------------- ----------- -----------
2020-09-14 422 0.124207858048 420 3156 392 588
2020-09-15 476 0.120220010476 475 3818 459 765
2020-09-16 474 0.104800000000 473 3750 393 729
2020-09-17 481 0.101306318315 479 3751 380 658
2020-09-18 500 0.128630705394 499 3615 465 835
2020-09-21 538 0.150787878787 538 4125 622 945
2020-09-22 605 0.134953352137 605 4609 622 951
2020-09-23 568 0.112925170068 567 4410 498 767
2020-09-24 668 0.102452202826 668 4812 493 827
2020-09-25 629 0.118402282453 628 4907 581 841
2020-09-28 623 0.180580762250 622 2204 398 575
screen cap of another customers' result, too. I'll come back and add a few more as I hit them.
01-19-2021 12:57 PM
I thought this recently updated defect might have some interesting content around the cause of this issue, but it looks like they only give examples, not specifics.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide