cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2981
Views
35
Helpful
11
Replies

CUCM Upgrade - Hardware Supported?

refram
Level 3
Level 3

We have MCS7835-H2s running CUCM 6.1(3b)SU1.  We want to upgrade to 8.6.  Looking at the compatibility charts it looks like these servers are supported for a bridge upgrade only.  But if we upgrade the memory to 4 GB and the hard drives to 146 GB would the servers be supported then?

1 Accepted Solution

Accepted Solutions

Joseph Martini
Cisco Employee
Cisco Employee

If by increasing the RAM and HD size the server model "changes" into one of these supported ones yes it would work:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/prod_brochure0900aecd8062a4f9.html  Looks like the only difference is the 72 > 146 GB drives and 2GB > 4GB RAM so you should be good.

View solution in original post

11 Replies 11

Joseph Martini
Cisco Employee
Cisco Employee

If by increasing the RAM and HD size the server model "changes" into one of these supported ones yes it would work:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/prod_brochure0900aecd8062a4f9.html  Looks like the only difference is the 72 > 146 GB drives and 2GB > 4GB RAM so you should be good.

Rob Huffman
Hall of Fame
Hall of Fame

Hi there,

From the great doc that Joe nicely linked (+5 Joe)

The 7835H2 with the upgraded memory & drives gets an (X2) supported designation for

CUCM 8.5 but a (B5) Bridged Upgrade only designation for CUCM 8.6. So I don't think

the 7835H2 will pass the hardware check in 8.6 no matter what you do

Cheers!

Rob

Hmmm...

Thanks for the responses folks, altough the second cast some doubt on the first, in spite of the fact that the first was rather definitive.  It's looking like our best bet may be to see if we can unearth a 7835-H2 server that isn't doing anything, slap the hardware in there, and find out if the application lets it pass.  There is a real possibility that we may be able to accomplish this.  But the follow on question - which really was at the heart of the first question - is, "Presuming that the application installation routine reads the hardware and says that it's cool, does that automatically mean that Cisco will support it?"  Any feedback on that?

So, this is my read on that:

The MCS-7835-H2 gets a Bridge upgrade designation for CUCM 8.6; however, it notes the equivalent is the HP DL380-G5 with 72GB disk drives.

The MCS-7835-H2 V02 is supported with caveats for 8.6 and the HP equivalency is HP DL380-GB with 146GB disk drives.

The only difference I see in the specs for the H2 vs. the H2 V02 is the storage capacity of the disk drives installed.  For 8.6, a minimum of 4GB RAM and 146GB disk drives is required.  So, if you upgrade the disk drives to 146GB on a stock H2 then it would essentially be an H2 V02.  From there, you'd need to upgrade the RAM to 4GB to meet all the pre-requisites.

I believe when the installer runs it's hardware check, it is first checking for the base model (i.e., MCS-7835-H2) and then for RAM and hard disk size.  If all three meet requirements, then the software will be installed.

Rob / Joe - any thoughts/confirmation on my thoughts above?

Hailey

Please rate helpful posts!

Agreed that you would need to upgrade both the hard drives and RAM, the installer *should* detect that hardware specs and allow the upgrade,  if not there are ways to change the machine type in the BIOS (at least there used to be) to reflect the newer V02 which definately would allow the upgrade to work.

i´ve the same case... you have any test to confirm do you say ?. because i´ve a requirement to upgrade cucm 7.0 to 8.6 on same server 7835-h2. if only change de ram and hard drive. it´s work fine??

All I can say is that

1) It worked:

  • Made sure we had original licenses and media
  • Downloaded most recent version of application
  • Made sure we had documentation about exactly how the application had first been installed
  • Did a backup
  • Shut down machine
  • Put in new hard drives and memory
  • Reinstalled OS and application from media using same configurations as first time and made sure replications was good (we did this to 4 machines)
  • Licensed
  • Upgraded to most recent version and checked replication
  • Restored from backup and checked replication
  • Tested/prayed
  • Left when it was working and celebrated

2) So far there has not been any question about support.  We've had to open a couple of TAC cases for other things and no one has blinked.

Hi there (refram),

Thanks so much for your kind consideration in following

up on this thread with your actual results, +5 my friend

This will likely help someone else down the road!!

Cheers!

Rob

Quick couple of questions regarding the above procedure.

The "Licensed" portion...  would this actually be necessary, or would it be restored in the 'restore from backup' portion?

Also, when installing the OS and CUCM from original media, did you give the server a different name and IP address (assuming it would revert back to the correct name/IP after the restore)?

I'm doing this on the publisher first, and don't want the 'blank' install with original publisher name/IP bouncing around on the same subnet.

Thanks in advance,

D&S

You'll have to forgive me because I can't put my hands on the document whose recommendations we followed, but we followed them in the way that was outlined above and were successful.  But aside from just following a document blindly, I can see a number of potential pitfalls if you don't properly license the cluster before you restore from backup.  For one thing I would assume you wouldn't be able to do the restore correctly. 

I know this whole thing is icky and I understand you not wanting to operate without a net during that window when you essentially have a blank cluster.  However, I don't think there's any other way to do it.  Just MAKE SURE you have the media, the licenses, the documentation, and good backups.  Remember, too, that you always have the old hard drives that you could pop back in if there is a tradegy.

To answer your other question, after the hardware was switched out and we began the reinstall, we gave the servers the same name and IP that they had originally before we did the restore.

One other thing worth pointing out is that the above steps just got us back to where we had begun except we had new hardware in the servers.  We were running the same version of everything and with the same configurations as restored from backup.  The step AFTER THAT was to do the upgrade to the new version. 

After having gone through it, my suggestion is to  give yourself a couple of windows in which to complete the entire operation.  We actually did it over two weekends.  It was a little less nerve-wracking that way. On the first weekend we performed the above tasks.  On the second weekend we did the upgrade.  This allowed us to monitor the cluster with the new hardware for a few days and feel good about its stability before we went to 8.6.

I agree, and that was my plan...

Do the hardware upgrades first - wait and make sure things are stable.

Then, tackle the 8.x upgrade.

Our only other obstable is the Attendant Console, and we are looking at 3rd party software for that.

Thanks for sharing!