CMS R16.3 on Windows 7 (32 or 64 bit) 1

[andybond]

We are currently migrating users from XP to Windows 7 Pro.
When using CMS supervisor R16.3 we are experiencing issues when running real time reports where they freeze (Not responding).
We then have to restart CMS supervisor for the user to logon back onto CMS.
Wondering if you had come across this before. Our current CMS server is R12.

The error in the Windows Application log is as follows:
Event Type: Error
Event Source: Application Hang
Event Category: (101)
Event ID: 1002
Date: 18/10/2012
Time: 10:26:51
User: N/A
Computer: xxxxxx
Description:

Hanging application acsRep.exe, version 16.1.0.0, hang module 13a0, version 01cd4d2335ab7917, hang address 0x6.
For more information, see Help and Support Center at

http://go.microsoft.com/fwlink/events.asp.

Data:
0000: 55 00 6e 00 6b 00 6e 00 U.n.k.n.
0008: 6f 00 77 00 6e 00 00 00 o.w.n...
0010: 00 00 ..

Tried this om a 32bit and 64bit PC, it seams to be happening very randomly, work for days/weeks fine then freeze.

We have upgraded from R16.3 KD16/17/21 all with the same results.

Very gratefully for any input

 

[nohuhu]

A little bit of shameless self-advertising: the best way to solve CMS Supervisor compatibility problems is avoid it. See CMS Webdash demo, login 'cms' with any non-empty password.


Regards, Alex.
My Avaya blog:

http://avaya.dwalin.ru

 

[Stinney]

In older versions of CMS this could be resolved by increasing the AckTimeOut registry entry under:

HKEY_CURRENT_USER>Software>Avaya>Supervisor>16.0>Link

I believe the Windows 7 Version puts the registry information somewhere else now so look around and see if you can find this folder and increase the AckTimeOut.

- Stinney

Quoting only proves you know how to cut and paste.

 

[BIS]

Or alternatively, Tools > Advanced (before you log in to CentreVu)

 

[Stinney]

BIS, what do you change there? This section only looks like it turns on/off logs.

- Stinney

Quoting only proves you know how to cut and paste.

 

[BIS]

Server Time out:

http://i45.tinypic.com/2edtnj8.jpg

 

[Stinney]

That doesn't appear to change the Link registry key value. It looks like it's changing the HKEY_CURRENT_USER>Software>Avaya>Supervisor>16.0>Automation>TimeOutSec value.

In addition, you have to turn on logging to effect this setting.

This is from the readme.txt file for R16:

12. REAL-TIME REPORTS STOP REFRESHING AT USER-DEFINED INTERVAL

If CMS Supervisor reports stop refreshing at the interval that you
specify, it is because CMS Supervisor was not able to receive data from
the CMS server within that interval. If CMS Supervisor cannot receive
report data within the user-defined interval, it will automatically reset
the refresh rate to a 1-minute interval. This problem can be caused by
network or server performance issues.

To keep CMS Supervisor from resetting the refresh rate, increase the value
found under the following registry key:

HKEY_CURRENT_USER\SOFTWARE\Avaya\Supervisor\<rel #>\Link

This change will allow more time to pass before CMS Supervisor resets the
refresh rate.



- Stinney

Quoting only proves you know how to cut and paste.

 

[BIS]

Hmm - I learned something new today

Today is a good day, thanks Stinney.

Have a star.

 

[Stinney]

andybond,

Have you checked your server's performace?

Read the Avaya CMS Capacities document, it's only 8 pages long:

http://support.avaya.com/css/P8/documents/100059412

When considering capacity limitations, consider that agent logins are a report element. We ran into issues when supervisors were running real-time agent reports with over 100 agents in each group. Every one of the agents in the report are counted as a report element. A skill report on the other hand, is a single report element.

You can see what's happening on the server by checking the CPU usage in real-time by logging onto the server either as cms or root and running the sar command.

Example: sar 10 100

This would provide a snapshot every 10 seconds, 100 times.

The output would liok something like this:

14:38:19 %usr %sys %wio %idle
14:38:29 7 0 0 93
14:38:39 0 0 0 99

%usr: The percentage of time the CPU is spending on user
processes, such as applications, shell scripts, or interacting with the user.

%sys: The percentage of time the CPU is spending executing kernel tasks.

%wio: The percentage of time the CPU is waiting for input or output from a block device, such as a disk.

%idle: The percentage of time the CPU is idle.

If your having capacity issues, you'll see a high spike in %usr and a very low %idle.


- Stinney

Quoting only proves you know how to cut and paste.