Solved: MCS Firmware, OS and CCM Upgrade Query

nickpalmermorewood · ‎03-24-2010

We have two MCS-7845-H2 running as Subscriber and Publisher and in order to support our new 7941 and 7942 phones it's time for an upgrade to 4.2.(3)SR4b.

However I noticed that we are way behind in terms of Firmware and OS updates as once the system was operational it was left as is.....not ideal perhaps but stable. OS version is 200.4.5a

I have the Cisco FW2.4.1-H latest cumulative firmware update bootable CD in addition to OS upgrade 2000.4.6 and 2000.4.6.SR9, things like our RAID controller are on an old 2.08 firmware version etc.

We're going to take an image of the publisher prior to the upgrade as it's RAID 1 so easy to do, but I just wanted to confirm the below flow:

1.) Reboot server, check and note current bios version - Cross reference against latest HP BIOS online

2.) Boot from Cisco Build Firmware Update CD 2.4.1-H

3.) Let the program update the various HP drivers, namely BIOS, Storage Controller and Drives

3.) Once Windows is up and running again, apply the Cisco/Windows OS upgrade from version 2000.4.5a to 2000.4.6 - 2 reboots are required

4.) Apply the Cisco/Windows OS upgrade from version 2000.4.6 to 2000.4.6SR9 - 2 reboots are required

5.) Once Windows is up and running again, apply Call Manager upgrade 4.2.(3)SR4b

6.) Check event viewer etc

Is this the correct process or will the OS upgrades also take care of firmware upgrades, meaning I don't need to use the firmware CD? Also should I disable the NIC card on the subscriber during the Publisher upgrade processs or is it okay to leave it connected and speaking with the Publisher.

Works will be done after hours so call processing disruption is not a problem.

Thanks in advance, Nick

David Hailey · ‎03-24-2010

I think your process logic is fine just make sure you keep each server at an even level throughout. In other words, take each task as a singular item and perform it on both servers before moving to the next task in sequence. I don't believe the OS updates include system firmware or BIOS updates; however, it's been a while since I've managed a Windows CCM. Just double check the OS update release notes for what's included and that should solidify the answer on that. As for the Pub-Sub communication, DO NOT disable the NIC on the Subscriber while you are doing updates. This is particularly true for the CCM upgrades. SQL on the Publisher will gracefully stop updating the Subscriber during the upgrade process and then replication will restart after the Subscriber has been upgraded to the same CCM revision and rebooted.

Hailey

Please rate helpful posts!

View solution in original post

David Hailey · ‎03-24-2010

I think your process logic is fine just make sure you keep each server at an even level throughout. In other words, take each task as a singular item and perform it on both servers before moving to the next task in sequence. I don't believe the OS updates include system firmware or BIOS updates; however, it's been a while since I've managed a Windows CCM. Just double check the OS update release notes for what's included and that should solidify the answer on that. As for the Pub-Sub communication, DO NOT disable the NIC on the Subscriber while you are doing updates. This is particularly true for the CCM upgrades. SQL on the Publisher will gracefully stop updating the Subscriber during the upgrade process and then replication will restart after the Subscriber has been upgraded to the same CCM revision and rebooted.

Hailey

Please rate helpful posts!

nickpalmermorewood · ‎03-24-2010

Thanks David, didn't occur to me to match each step on both servers as I had the frame of mind of trying to get the Publisher fully upgraded first as peace of mind that the process works!

Thanks for the pointers and fingers crossed all goes well tonight!

David Hailey · ‎03-24-2010

No problem. Definitely keep them at the same revisions as you go thru each "task" and good luck.

Hailey

Please rate helpful posts!

nickpalmermorewood · ‎03-26-2010

Hi David,

Thanks again for your guidance. Everything went smoothly and as planned by mirroring each step of the upgrade across the two severs - the only error I got was this:

HP Network Team #1: PROBLEM: A non-Primary Network Link is not receiving. Receive-path validation has been enabled for this Team by selecting the Enable receive-path validation Heartbeat Setting. ACTION: Please check your cabling to the link partner. Check the switch port status, including verifying that the switch port is not configured as a Switch-assist Channel. Generate Broadcast traffic on the network to test whether these are being received. Also make sure all teamed NICs are on the same broadcast domain. Run diagnostics to test card. Drop the NIC

In terms of updates, our iLO version should have gone up to 1.9x can't remember the exact revision as stated in the OS updates but instead it only went up to 1.43. P56 bios version was revised to 2008.11 even though on HP's website you can find 2009.07.10 but again doesn't seem like a big deal. I figured rather than tempt fate from a smooth upgrade and apply HP patches may as well leave it with the Cisco builds - what it wanted to upgrade/update it did!!

And after several hours babysitting the reboots and updates I can confirm that the 7941 phone that through up a remote scripting error in 4.2.(3) works very well in 4.2.(3)SR4b which no problems so far.

Thanks again, Nick

Aaron Harrison · ‎03-26-2010

Hi

The NIC error sounds like you may have NIC teaming enabled, but only one NIC connected, or one NIC connected to a different L2 broadcast domain?

It's basically saying that one NIC in the team cannot 'see' the other. Probably worth checking over the connections...

Re: firmware - there's always newer firmware available than you get on the Cisco builds, it's just a case of what's on the Cisco builds/updates being the tested release rather than the latest. As you suggested, it's best to leave it alone unless you have a specific issue to resolve.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

nickpalmermorewood · ‎03-26-2010

Hi Aaron,

I double checked the settings. We have Team #1 Type: Network Fault Tolerance Only

NIC 1: Role Tx/Rx

NIC 2: Role Standby

They are both connected and active within the same VLAN but on different core switches. However both core switches are in the same VTP domain, and interconnected via an LACP link, dot1q trunk. udld port.

Regards, Nick