[cisco-voip] CCM Upgrade - Best Practices
Ryan Ratliff
rratliff at cisco.com
Wed Jan 9 09:46:21 EST 2008
Not at all.
-Ryan
On Jan 9, 2008, at 9:41 AM, STEVEN CASPER wrote:
I am sooooo glad I asked!
Is there any issue with having the CCM service disabled and stopped
on a server while upgrading the CCM application or OS? This is for
the 4.1.3sr train.
Steve
>>> "Ryan Ratliff" <rratliff at cisco.com> 1/9/2008 9:16 AM >>>
Don't ever deactivate the CCM service via Service Activation unless
you are permanently removing a subscriber from the cluster or turning
it off on the publisher for good.
As Lelio saw when you do this you lose all service parameters for the
server. Also when you re-activate the service the server gets a new
CTI node ID. This means that the CCM service on all other nodes in
the cluster will have to be restarted before they pick up this
change, ie no SDL links to this server. The last big thing de-
activation does is remove the server from all CM groups it is in.
Stopping/Starting/Disabling the service via the Win2k services.msc
doesn't hurt anything and if you need to prevent CCM from starting
automatically set it to Manual or Disabled there.
-Ryan
On Jan 9, 2008, at 9:10 AM, Lelio Fulgenzi wrote:
Redefining device pools has worked for us in the past, but they say
not to make changes during the upgrade, so there's no way to really
keep a phone away from a subscriber during the upgrade process other
than disabling it or setting it to manual.
I'm guessing setting it to manual in WIN2K should work, but they've
always told us not to do that. ;)
----- Original Message -----
From: STEVEN CASPER
To: Ryan Ratliff ; Lelio Fulgenzi
Cc: cisco-voip at puck.nether.net
Sent: Wednesday, January 09, 2008 8:53 AM
Subject: Re: [cisco-voip] CCM Upgrade - Best Practices
Well that is frightening possibility - hence my question!
The CCM service could be set to disable via the Services window in
WIN2K or I think by using the Service Activation window in Call
Manager Serviceability.
I am trying to come up with the least service effecting procedure for
CCM patching and upgrades since we just moved several 24x7 business
critical groups over to IPT.
>>> "Lelio Fulgenzi" <lelio at uoguelph.ca> 1/9/2008 8:42 AM >>>
I'm not sure what you're using to "disable" CallManager, but we tried
this once (perhaps we de-activated?), and all the service parameters
for that subscriber were lost (set to default) and anything that
relied on that subscriber, i.e. call park numbers, callmanager group
entry, etc, was deleted!
It did not make for a fun time.
------------------------------------------------------------------------
--------
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
“Life expectancy would grow by leaps and bounds if green vegetables
smelled as good as bacon.”
Doug Larson
----- Original Message -----
From: STEVEN CASPER
To: Ryan Ratliff
Cc: cisco-voip at puck.nether.net
Sent: Wednesday, January 09, 2008 8:36 AM
Subject: Re: [cisco-voip] CCM Upgrade - Best Practices
I like the idea of :
1. stopping the CM service on the server to fail everyone over to
next server
2. disable or set to manual startup the CallManager
service on the servers
Does it matter if this is done via CCM Control Center in
Serviceability to stop the CCM service and Service Activation to
disable the CCM service or can these actions be done under Win2k
Services?
Does the Call Manager service need to be running on a server during
an upgrade of the application or the OS?
Steve
>>> "Ryan Ratliff" <rratliff at cisco.com> 10/24/2007 11:44 AM >>>
The easiest way to ensure phones don't register to servers during the
upgrade is to disable or set to manual startup the CallManager
service on the servers being upgraded. That way you can do the
upgrade, reboot the server, and take a look at things before having
phones fail back to it.
-Ryan
On Oct 24, 2007, at 9:53 AM, STEVEN CASPER wrote:
Looking for some advice for the best way to do Call Manager
upgrades to minimize system disruptions. From a recent ES doc:
"You can minimize call-processing interruptions if you register all
devices
to servers that are running the same version of Cisco CallManager
during the
entire upgrade process; i.e., you register all devices to the backup
Cisco
CallManager servers or the primary Cisco CallManager servers, but not to
both types of servers."
I understand what the ES doc is saying what I am not sure about is
the best practice to ensure that all devices stay registered on the
backup or primary servers during the upgrade. Should you manipulate
your Call Manager groups during the upgrade?
For instance all of our devices are registered to Subscribers A, B,
C, & D. We have two back up subscribers X & Y. Do we:
1. Upgrade the Publisher.
2. Upgrade X & Y
3. Change our Call Manager Groups so X & Y subs are the primary.
4. Reset all devices so they re-register to X & Y.
5. Upgrade A, B, C, & D.
6. Change Call Manager groups so A, B, C, & D are primary again.
7. Reset devices.
Thanks!
Steve Casper
Voice Technologies
M&T Bank
(410) 347-6026
************************************
This email may contain privileged and/or confidential information
that is intended solely for the use of the addressee. If you are not
the intended recipient or entity, you are strictly prohibited from
disclosing, copying, distributing or using any of the information
contained in the transmission. If you received this communication in
error, please contact the sender immediately and destroy the material
in its entirety, whether electronic or hard copy. This communication
may contain nonpublic personal information about consumers subject to
the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley
Act. You may not directly or indirectly reuse or disclose such
information for any purpose other than to provide the services for
which you are receiving the information.
There are risks associated with the use of electronic transmission.
The sender of this information does not control the method of
transmittal or service providers and assumes no duty or obligation
for the security, receipt, or third party interception of this
transmission.
************************************
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
************************************
This email may contain privileged and/or confidential information
that is intended solely for the use of the addressee. If you are not
the intended recipient or entity, you are strictly prohibited from
disclosing, copying, distributing or using any of the information
contained in the transmission. If you received this communication in
error, please contact the sender immediately and destroy the material
in its entirety, whether electronic or hard copy. This communication
may contain nonpublic personal information about consumers subject to
the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley
Act. You may not directly or indirectly reuse or disclose such
information for any purpose other than to provide the services for
which you are receiving the information.
There are risks associated with the use of electronic transmission.
The sender of this information does not control the method of
transmittal or service providers and assumes no duty or obligation
for the security, receipt, or third party interception of this
transmission.
************************************
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
************************************
This email may contain privileged and/or confidential information
that is intended solely for the use of the addressee. If you are not
the intended recipient or entity, you are strictly prohibited from
disclosing, copying, distributing or using any of the information
contained in the transmission. If you received this communication in
error, please contact the sender immediately and destroy the material
in its entirety, whether electronic or hard copy. This communication
may contain nonpublic personal information about consumers subject to
the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley
Act. You may not directly or indirectly reuse or disclose such
information for any purpose other than to provide the services for
which you are receiving the information.
There are risks associated with the use of electronic transmission.
The sender of this information does not control the method of
transmittal or service providers and assumes no duty or obligation
for the security, receipt, or third party interception of this
transmission.
************************************
************************************
This email may contain privileged and/or confidential information
that is intended solely for the use of the addressee. If you are not
the intended recipient or entity, you are strictly prohibited from
disclosing, copying, distributing or using any of the information
contained in the transmission. If you received this communication in
error, please contact the sender immediately and destroy the material
in its entirety, whether electronic or hard copy. This communication
may contain nonpublic personal information about consumers subject to
the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley
Act. You may not directly or indirectly reuse or disclose such
information for any purpose other than to provide the services for
which you are receiving the information.
There are risks associated with the use of electronic transmission.
The sender of this information does not control the method of
transmittal or service providers and assumes no duty or obligation
for the security, receipt, or third party interception of this
transmission.
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20080109/6400e82c/attachment.html
More information about the cisco-voip
mailing list