Best Practice: How Often To Reboot Your Call Manager (both Pub & Sub) ???

[MitelInMyBlood]

Apparently nowhere has it been written what the best practice is in regard to periodically rebooting the Call Manager.

I ask because we just solved a delayed message waiting issue by rebooting our Sub (last reboot was 396 days ago) (!)

I have tried unsuccessfully to get my mgmt to allows us a scheduled recurring reboot of all systems, at least quarterly, but it falls on deaf ears.

What are others doing and is there any suggested reboot frequency?

Thanks

Original MUG/NAMU Charter Member

 

[MrNick0483]

If it is not broke don't reboot it.... is my method.

 

[vnetmanager]

I agree with Nick. You don't reboot application servers on a scheduled basis "just because", so don't reboot the CUCM, or Unity, or UCC, etc.

JB

 

[MitelInMyBlood]

So what you're saying is "Run To Fail" ?

Unfortunately we have a poor history of success with that approach.

I realize the redundant sub(s) are there for that reason, but the concept still seems unintuitive. If the PUB crashes, your users are screwed for their features and you're screwed for doing any reconfiguration or MACD work until you get the PUB back on line. If that happens in the middle of implementing your disaster plan (we're in hurricane country) at the end of the day you may not have enough ass left to make a good sandwich.




Original MUG/NAMU Charter Member

 

[kalashnikov118]

TAC has told me to only reboot CUCM etc for a specific reason. However, I have found that if I don't reboot CUCM and UCCX every Sunday night UCCX WILL eventually go down. Last time it was the trigger for one of the call centers went unregistered and wouldn't come back. TAC deleted it and recreated to get the center back up. Their explanation was that one of the services on UCCX was crashed even though they all showed up and green. This was an almost monthly thing until I started rebooting. No problems in 6 months.

 

[hanluc6933]

I wouldn't reboot a call manager cluster unless there was a specific reason, no matter what size sandwhich I could make with my ass.

It doesn't happen often but after your stung by a database replication issue, post cluster reboot. You may think twice before doing it again.

~Han




The great use of life is to spend it for something that outlasts it. ~William James

 

[archer1300]

My fall back solution to solving all issues with Cisco phones is a reboot.

I've been on CM with unity and UCCX for three years. I have to reboot about every 6 to to 7 weeks to clear issues with CM.

My typical response from TAC and our vendor is try a reboot to see if it corrects its self.

 

[MitelInMyBlood]

Thanks all.

Indeed, the usual response from TAC when reporting an issue, and after some trace collections is they will generally advise you to reboot, so rebooting is not a bad thing... just make sure to do it off-hours.

In fact if you will observe the resource pools in RTMT you will notice that your pool of virtual memory is being gradually depleted with each passing day. Memory leak is a known issue in CUCM, particularly on the Publisher, though it's gotten much better since the release of 8.6

Our specific issue was "delayed message waiting set/clear" A function which should occur immediately after deleting your messages but in our case was taking up to a minute.

Indeed we called TAC like obedient little minions. They looked at Unity Cxn and took some traces, reporting that Msg Wtg was on time and not delayed. We even started & stopped some services, no improvement. Then TAC says reboot the cluster (everything, pub and all subs). The problem cleared the moment we rebooted the SUB.

Original MUG/NAMU Charter Member