Thank you for this. I still think it's ridiculous that because my CPU is BETTER than the one specified that it won't work. With Microsoft coming in as fast as they are into the UC space, I hope that this rigidness will loosen up a bit. I can install Exchange 2007 on any computer that meets minimum requirements and I can successfully serve up thousands of email and voicemail boxes with no problem. And if I ever have a problem Microsoft suports me! Exchange has already taken our business away from Unity, and silly hurdles like this make us more seriously consider OCS as a CUPS/MPX alternative.

Ok enough ranting I'm just frustrated. Cisco does own a good portion of VMware though right! I can only dream of the possibilities! :)

i do agree that with the technology this days you always want to be a step ahead in order to have the HW running some more time before there's something even better and what you have becomes obsolete but unfortunately the PCDs require some very specific specs on the HW on which they will be installed.

trust me that i know of this, this is not the 1st time i've had to tell someone about this stuff of their HW not being supported.

the thing is that for many of the PCDs there are some minimum requirements like for example HDD or RAM and another hard specs like the processor. some more CPU cannot hurt, or at least i think so =)

but then again, i'm just the messenger of higher powers

HTH

javalenc

if this helps, please rate

This is not ridiculous. Think about it, would you prefer that Cisco force you to buy a proprietary appliance for $$$ rather than spend the countless hours testing the commodity HP DL320/380 hardware?

While you may not care that Cisco's internal testing may have revealed SERIOUS IO or SDRAM wait-state performance issues across otherwise equivalent hardware simply by changing the CPU speed or family, many companies do care. Cisco's reputation is at stake, and voice is still considered a critical application in most companies.

Cisco cannot be expected to test and, more importantly, blindly approve all versions of the constantly changing HP or IBM servers.

I am equally frustrated that this year has been particularly troublesome for finding the approved HP DL320/380 server configurations directly from HP or through distribution. Hopefully the MCS7816-H3 equivalent HP part # will be available as promised with the UC7.0 release this week.

I would love nothing more than Cisco to support the DL360 with ACTUAL HARDWARE RAID and REDUNDANT POWER, but this has not happened yet. I find myself quoting DL380 servers far to often and they are such overkill, not to mention space and power.

Finally, let me weigh in on Virtualization support. While VMWare ESXi is now free and most of the Cisco voice apps will install, they are explicitly not supported, at least for now.

I can see Cisco supporting presence, mobility, mobile communicator, etc. on a single VM box; but they won't EVER support CUCM, meetingplace express, CUCCX, or voicemail in a VM, and for good reason. The Intel chips make terrible voice DSPs anyway and require considerable CPU cycles for functions such as prompt playout, MOH, recording, voicemail, MTP, and voice recognition.

I have been involved in several installs where the client insisted on 'trying' VMWare ESXi on really solid hardware, and they have all failed miserably. This is due to performance, consistency, and particularly voice quality.

The server and virtualization landscape will change so much over the next 2 years that we all won't recognize the data center of tomorrow. However, critical voice apps on generic silicon (i686) is not there yet.

Since my post earlier this year we've been running CM, CUPS, and OCS all on the same ESX virtual host and it has worked flawlesly on a Dell (gasp!) PE 2950. The HPs that I bought for my voice infrastructure have all slowly taken on less glamorous roles. I haven't had any quality problems so I've had quite a different experience than you thus far.

Perhaps I could use a little education on this, but what role does CCM have anyway other than call setup and teardown in the lifespan of a call? The RTP streams bypass CCM unless you need transcoding and we use hardware DSPs for those anyway. So what does the CCM do during a call that requires the extremely short latency that virtualization or "generic silicon" shouldn't be able to provide?

On the otherhand I understand your point and realize that especially in enterprise critical situations that the less variables involved the better regarding supported configs and hardware. Thank you for the thoughts.

The discussions of hardware and configuration support have been going on since Cisco first started in the VoIP environment. I was with Cisco in the field in the very early days of Call Manager on Compaq and other devices.

At one point Cisco com,pletely unbundled the software from the hardware saying that as long as the hardware met certain memory, disk and speed parameters, you could use anything you wanted. In those days, close to 90 % of the TAC cases related to Call Manager installations revolved around hardware configurations that were not quite what was tested.

Cisco then took the stance from a support and Customer Satisfaction standpoint that only a very few hardware platforms were to be supported going forward. HP, IBM and at one point Dell were the platforms tested and selected. You can either purchase the platform from Cisco or if you have better discounts, buy the specified platforms from HP or IBM. Anything outside of that may work, but do not expect Cisco Support.