Communications Faulted CCR 3

[h382]

So, I installed CCR on a Virtual Machine running 2K3 and SQL Express 2005. The first day, everything ran great, the 2nd day when logging into the admin account for CCR, I get Communications Faulted for the SQL Database section, so no data is being saved.

I uninstalled/re-installed numerous times, could not get it to come back up. I built a new Virtual Machine, installed it again, worked perfect... for a day. The next day I come in, same thing.

I do not have any anti-virus or firewalls running on this server. I did notice around 3am there was a security policy being run, and I saw a few CCR errors at the same time. I'm guessing that's where the fault is, but I've asked the guys who manages the policies and he isn't aware of anything he has set to run at that time.

I've run the gpresult to look at the policies, and none of them would affect SQL or security.

Any ideas?

 

[latitude12]

The CCR alerts you that there was an error, not that the error is necessarily still active. You must acknowledge the error incident by clearing the Windows event log (and probably saving it first if you really care to). For example, a loss of communication that has cleared itself up is still important enough to look into thus the error notification remains until you acknowledge and clear the log.
This isn't a bug; it is working as it should. The only bug is as latitude12 mentioned that the connection shows disconnected but it isn't really disconnected. This can be cleared by restarting the World Wide Web Publishing service."

Sorry, I don't buy this. The whole reason the event log exists is so applications can log problems and when they are resolved. You shouldn't have to manually clear the log every time a single application experiences an error. Also, if CCR thinks that the administrator needs to look in the event log then it should display a message to that effect, not use the same 'faulted' condition as when a service has actually failed.

 

[hairlessupportmonkey]

Kyle - I don't buy that one either, Scansource here have acknowledged this is a known bug that clearing the event logs clears the status warnings and stops the services from Faulting. Apparently Avaya were the ones that pointed this out to ScanSource but it never got fixed in the latest release. Who the heck has the time and inclination to go in and clear down event logs every time CCR "hiccups?" Certainly not the end user or the poor support monkeys!

When you clear the logs the comms to the switch also fails over so having to restart the service, and then re-entering the password for the switch and updating.

This is the errors on our CCR atm

Database Monitor Service VALE-CCR Running Restart
Historical Reporting Service VALE-CCR Faulted Restart
Management Service VALE-CCR Running Restart
Printer Discovery Service VALE-CCR Running Restart
Realtime Calculation Service VALE-CCR Running Restart
SQL Database (LOCAL) 1.2.1.0 Communications Faulted Restart

Its not even a busy server.....

 

[kholladay]

You'd prefer never to know that there was an issue? With the method that you request you could easily lose communication with the SQL database for hours throughout the day and thus lose data however if the connection to SQL were restored you would have no indiciation unless you happened to proactively go into the event logs to check. That is unless someone happened to point out that there was that little red square during the errored event.

I agree that the bug with the comms to the switch needs to be resolved as it doesn't truely indicate a failure to communicate with the PBX and restaring the

http://WWW publishing

service clears that which is obvioulsy broken.

However in my opinion, and it may differ from others, with a true call center just as in a true NOC ever error should be acknowledged. No error should be ignored simply because it was able to be resolved without my interaction.

Kyle Holladay
ACSS SME Communications
ACE Implement: IP Office
MCP/MCTS Exchange 2007
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[tlpeter]

Every error should be displayed on the wallboard and on the supervisors screen.


To go another bug:
I like it

CQ43421 Unable to log on a CCR Supervisor using the Advanced Edition license 1.2.2.78 SP_RELEASE_3Q10_CCR 2-Required

Even with a license you cannot login.

Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

A yard full of tards

 

[hairlessupportmonkey]

I don't mind being advised that there are errors but having clear event logs is the wrong way to acknowledge the errors. 99.9% of the time the faults are very minor but you still have to trawl through the logs and clear them down - and if you have a machine you don't necessarily manage as such then this isn't great as the IT dept might not want you clearing down event logs just to stop CCR moaning.....

Avaya needs to have an interface that allows a user to acknowledge the errors and advise the maintainer accordingly.

 

[kholladay]

I agree. Although I like the use of the Windows event log as I can now use existing applications for notifying the administrator of errors along with other server/hardware events there is no real way to dump a single errored event.

Kyle Holladay
ACSS SME Communications
ACE Implement: IP Office
MCP/MCTS Exchange 2007
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[latitude12]

However in my opinion, and it may differ from others, with a true call center just as in a true NOC ever error should be acknowledged. No error should be ignored simply because it was able to be resolved without my interaction. "

I agree with this, but surely an email, snmp trap or some kind of specific application warning is a better idea than using the same method as when the app/service is actually not working.