VoIPNorm MythBusters: The Great Server Myth

Myth #4: “You need to buy hundreds of servers, one at every site”

I absolutely love this one, because it is so easy to bust. The competitors to Microsoft love to show the expanded OCS Enterprise Edition configuration because it makes it look true when in fact in 99.999% of cases expanded Enterprise Edition deployment is not recommended or required. They also forget to mention other improvements like hybrid gateways. How many servers you deploy is really up to what services and options you want to roll out. I think customers can also be confused by some of the terminology around OCS. The term server is used to describe what really can be a service or role running on an OCS Consolidated Front End. This in turn is confused as requiring a physical server when it does not.

Competitors also like to keep the conversation telephony or vertically focused. With OCS this just isn’t the case as the one platform is meant to be able to take on all workloads. Although I am not going to offer up a competitor comparison here, if you were to take the example UC services with server count I have presented and do a comparison, I think it would surprise most people that OCS and especially wave 14 typically would do more with less servers.

Example deployment

Let’s take as an example a 5000 user deployment for both R2 and wave 14. This really is a pretty typical number and there are great deal of organizations that are either at or under this number. The size of a deployment for this many users can vary from 1 Stand edition server doing IM and presence only (which could also be virtualized for this workload) right up to a fully blown UC deployment with high availability.

The server count below includes all OCS workloads on what is referred to as a consolidated Enterprise Edition configuration with high availability (99.999’s reliability for all workloads) around the front end servers and PSTN access. This configuration would allow remote VPNless connectivity, Public IM access, federation to external companies, SIP trunking, Unified Messaging, PSTN dialin Conferencing, Single Number reach, IM/Presence, web collaberation etc, etc.

OCS R2 Central Office for full UC with high availability:

2 Front end servers (SIP register, AVMCU etc)
2 backend SQl database cluster for HA
2 mediation servers (transcoding and encryption for PSTN connectivity)
2 PSTN Gateways (Audiocodes, NET, put vendors name here)
1 Consolidated Edge Server (Remote VPNless access for all UC workloads)
1 Monitoring server (CDR Records and Quality Statistics)
1 Communicator Web Access (web client access and dial-in audio conferencing web pages)
1 Exchange UM server (Unified Messaging, for voicemail HA +1)

Branch site

1 Hybrid Gateway

And of course with Wave 14 this number will be lower with integration of the mediation server and CWA on to the Front End Servers. The additional workloads plus the addition of survivability at the branch has reduced server count while increasing features.

Wave 14 with high availability and survivability for branch sites:

2 Front end servers (SIP register, AVMCU, Mediation server, Reach web client, etc)
2 Backend SQl database cluster for HA
2 PSTN Gateways
1 Consolidated Edge Server (Remote VPNless access for all UC workloads)
1 Monitoring server (CDR Records and Quality Statistics)
1 Exchange UM server (Unified Messaging, for voicemail HA +1)

Branch site

PSTN Gateway with onboard Survivable Branch Appliance (AudioCodes, NET, Dialogic, etc)

As for having a server at every site, this really depends again on your requirements. With the mediation function now available on the gateway itself in OCS R2 this is only true if you require local MCU resources and you do not want to have a centralized datacenter deployment. Again with Wave 14 the survivable Branch Appliance (SBA) will be an option but its only required if the customer deems it to be. The SBA is also cohosted on the gateway, so no increase in server count.

In all honesty if a thrifty company wants to remove high availability and settle for disaster recovery, still maintaining the magical 5 nines (99.999% uptime) for voice they could do so with less servers again in wave 14 using side by side Standard Edition Servers.

Wave 14 Stand edition with disaster recovery for voice and peer to peer UC.

2 Standard edition Servers (SIP register, AVMCU, Mediation server, Reach web client, SQL database etc)
2 PSTN Gateways
1 Consolidated Edge Server (Remote VPNless access for all UC workloads)
1 Monitoring server (CDR Records and Quality Statistics)
1 Exchange UM server (Unified Messaging, for voicemail HA +1)

Branch
PSTN Gateway with onboard Survivable Branch Appliance

Of course you could add more server roles to add different functionality. A good example is archiving, but most companies do not want to archive their IM sessions so I didn’t include it in this example. I also included the monitoring server in all these scenarios but it is an optional component as is the edge and CWA. It really just depends on your requirements.

So with 5 servers and 3 PSTN gateways for 5000 (SE supports up to 5000 users for all workloads) users, you could enable the full UC workloads including PSTN dial-in conferencing. Of course the number of PSTN gateways will vary depending on your branch count and voice load but I think you get what I am saying.

This has been a rather long myth to break down but I think we can safely say it is BUSTED.

Final thought…….

My advice to anyone doing an evaluation of Unified Communications architectures from the different vendors is to get a deep dive of the technology from the vendor in question. Map out all your requirements before the meeting as it relates to UC and not just voice, and get your questions answered in relation to your business needs. Having a different bunch of widgets is great from a choice perspective, but if they don't meet your business needs you might be buying into the wrong solution for the wrong reason.

Comments welcomed.

VoIPNorm

Communicator 14 Media Device Selection

In Communicator 2007 R2 selecting the device you wanted to use as your audio device was a little painful. Having to search through a menu to get to the Audio Video Tuning Wizard is a little bit of a pain especially if you’re like me and you are constantly using different devices. I lost track of the number of times I was switched to my laptop speaker and microphone after a startup. Well in Communicator 14 this is pretty much a thing of the past.



Along with an improved monitoring capability to listen for multiple USB devices it is now easier to select the right device as shown with this screen shot above. This enables you to select the device you want straight from the main window. It also provides easier access to the Audio Video Tuning Wizard, which I pretty much haven’t had to use since switching to C14.This capability is also ported through to the call window where you can change devices on the fly while in a call.



It seems like a small change but I bet down the road it has a big impact on calls to the help desk.

Comments welcomed.

VoIPNorm

F5 Configuration for OCS R2

This week I have been trying to help one of my peers with an F5 issue. Getting the configuration settings right with F5 for OCS R2 is an art form so I want to reprint the material from a previous post I did and add some new context to help people avoid probably the number one issue. Incorrectly setting the persistence and protocol settings.

Reprint of my original post with new content.

The table below should help anyone get the right settings to have all the different working parts of an OCS R2 deployment working when using an F5 to load balance multiple front end servers in a consolidated deployment.



You Virtual Server profile for the SIP ports used with OCS should look something like this when viewing the text file print out of the .conf file:

VS: ocs-pool-sip
Port: 5061
Type: Standard TCP
Profile: ocs-TCPtimeout-1200
SSL: None
SNAT: Automap
Persistence: source_addr

Things to be on the lookout for are the Type and persistence settings. If these are set to SIP, which F5 has a profile for, this will cause TCP sync issues. This leads to logon failures and dropped session among other things.

Also ensure that the F5 isn’t terminating the SSL session. In OCS’s case no encryption should be terminating on the F5 and should be passed through to OCS blindly as it were. I have seen some excetions to this in the case of CWA but as a general rule it should be set to none.

To configure a health monitor for 5061:
1.On the Main tab, expand Local Traffic, and then click Monitors. The Monitors screen opens.
2.Click the Create button. The New Monitor screen opens.
3.In the Name box, type a name for the Monitor.
4.From the Type list, select HTTPS.The TCP Monitor configuration options appear.
5.From the Configuration list, select Advanced. The advanced configuration options appear.
6.In the Configuration section, in the Interval and Timeout boxes, type an Interval and Timeout.
7.In the Alias Service Port box, type 5061.
8.Click the Finished button.

From the .conf file it will look something like this:
}
monitor ocs-frontend-sip-5061 {
defaults from https
interval 30
timeout 91
dest *:5061
}

Also, you will need to create a TCP profile with an Idle timeout of1200 seconds and enable TCP resets on idle timeout which will need to be applied to each of the VIP created.

Of course all this information is on the internet in various places. The following document is available from MSFT on load balancing requirements for OCS R2 but it’s a general document not specific for F5.

F5 have released an OCS R2 document which also covers the persistence setting I mentioned above. In the original documentation this was missing.In the document they recommend Source Address Affinity as the correct setting for persistence.

Comments welcomed

VoIPNorm

Communicator 14 and Voicemail

This post will be more about look see with the client than a deep technical dive. I wanted to talk a little about two new OC features that I really like in Communicator 14. The first one is the dial pad that has been added. This is really more about comfort levels than feature/function improvement as you have always been able to type in a number in OC 2007 R2 to make a call. I know from experience one of the first things people asked when using OC R2 was where do I enter a number. Well, now you have two options. This feature is cool in respect to adoption. I think once people get used to Communicator they will minimize dial pad but certainly those new to Communicator will really like this option.



Note: Screen shot was edited to hide certain details (phone numbers etc.)

The second one is visual voicemail. I get more excited about this option. Firstly because I no longer have to have outlook open to get my voicemail and listen to it and secondly I can launch straight from Communicator to Outlook if I want to reply with email. This uses Exchange Web Services (MAPI is also supported) to retrieve voicemail which is delayed after startup to ensure there is no delays in the clients registration. This tight integration is really a great evolution of Microsoft’s UC appraoch of tightly integrating across its product line of CS, Exchange and Sharepoint.



Although not related to voice directly the contact card was a really nice addition as well. This really opens up all the communication channels without need to go to another application. I use this functionality a great deal not just in Communicator 14 but also in Outlook 2010.

Over the next few months I will be talking a great deal about CS 14 since the NDA is lifted. It is really an exciting new product that I am happy to be able to finally talk freely about.

Comments welcomed.

VoIPNorm

NorthWest UCDoers July

The NorthWest UCDoers are back this July and back on the MSFT campus. This time around I will be doing a talk about Communications Server wave 14 and some of the new features. There may even be some demos and white boarding in there as well.

Here is the link to register:
http://www.pingg.com/rsvp/2hjr267wq358t7khz

BTW There will be food and adult beverages.

Comments welcomed.

VoIPNorm

Device Review: Plantronics Blackwire 420

This last week or so I was lucky enough to receive a Platronics Blackwire 420. This is a wired USB dual earpiece headset. I am a big dual ear headset fan due to some industrial deafness from a previous life working as an electrician and in the military where I spent a lot of time working in noisy environments (that and loud heavy metal concerts in my youth). That makes it hard for me to discern conversation from background noise. Although the Blackwire isn’t specifically designed for someone with such a problem it certainly goes a long way to blocking out background noise without totally removing it(although when I was listening to music it did block out my wife trying to talk at me, no comment :-)). This may have something to do with the larger than normal earpiece which is well padded and also extremely comfortable.





This week I was on the road so of course the Blackwire came with me on its first road trip. I am currently using the beta Communicator 14 Client and the headset worked seamlessly. I actually had someone on a call ask what headset I was using because of how clear I was. The headset also comes with a neoprene travel bag (this is a great option) , which because of the swivel earpiece lies pretty flat in your bag. So although it doesn’t pack up very compact area wise it is flat making it easy to slide into a laptop bag.

The controller is pretty well laid out and doesn’t leave you guessing what each button does.



It also comes with a bunch of audio related features like wide band support and full range high fidelity stereo that do give it great audio quality not just for using with Communicator but also more general use like listening to music.



I have only been using the Blackwire the last week or so but it is fast becoming my go to device out of a whole draw full of devices. Quite literally I have an excess device problem (last count was about 12 different devices). So if you are like me and always on the hunt for a better headset the Blackwire will certainly be a step in the right direction.

Comments welcomed.

VoIPNorm

Configuring a Broadvox SIP Trunk in OCS 2007 R2

If you’re not already familiar with DR Rez here is your chance. This last post is configuring OCS to connect to Broadvox SIP Trunk.

CS 14 PowerShell site

Bookmark it, bookmark this site now or forever be lost in the world of CS 14 PowerShell.
http://blogs.technet.com/b/csps/

I haven't had time to look into this yet but I am sure it is going to be a popular site.

Comment welcomed.
VoIPNorm

Microsoft V Cisco End User Experience

It’s been no secret of late that these two have been head to head in an all-out marketing war. In fact right here on VoIPNorm, I have been knocking down a few of the interesting (incorrect) things Cisco has been saying about OCS. Here, here and here.

So in the spirit of competition (which my job wouldn’t be nowhere as interesting without) here is an interesting video based on the current release from Microsoft and Cisco around the end user experience.



Yes, this is a video produced by Microsoft, just want to make that perfectly clear.

Here is another similar end user experience video available on Showcase.

Call Forwarding: http://www.microsoft.com/showcase/en/us/details/5c07d511-b7d6-4bf2-912a-7deda3816256

This is the video I have posted here, available on Showcase.

SNR: http://www.microsoft.com/showcase/en/us/details/8eda1df0-d9d6-4691-9c27-55ebd120302c

Comments welcomed.

VoIPNorm

More on the UCIF

Interesting Podcast from the folks over at UCStrategies.

Comments welcomed.

VoIPNorm

VoIPNorm Ponders

This week as you may know from my previous post I am in New York on vacation. One of the many attractions I have had a chance to see in NY has been the Museum of Modern Art. This is my first time to NY and obviously to MoMA. Generally it was a pretty cool experience, I got to take in some interesting art and ponder at others.



The above shot was one of a couple of strange pieces but it certainly got my attention, not because of the way it looks but I nearly walked into it. I basically concluded anything to bizarre to comprehend must in some way be a sculpture of some part of the female antimony. Although I have no aptitude for art (if you can’t already tell) this piece reminds me of an RFC. If you guessed an RFC reminds me of a female body part you guessed wrong , what I meant was open to interpretation. Which brings me to my next point. The UC Interoperability Forum.

The UCIF is what I see as a critical junction in the embrace of UC in the enterprise. I think the UCIF is a requirement because RFC’s are so open. The unfortunate thing about the UCIF at the moment is that most companies that have joined out of the gate already have strong relationships (although some not directly to each other). Although this formally brings them altogether, which is a positive thing, there are some obvious missing names among them (don’t make me spell it out). Most interop issues are among competitors and at the moment there are some major UC competitors missing.

With such a large scope which encompasses UC, the UCIF has a noble charter that may be difficult to pull off. As companies like Cisco trying to drive their own protocols to be standards (telepresence) how the UCIF handles issues like these will be interesting to see. The UCIF may also be a great platform for vendors that want their protocols adopted as a standard. Although the UCIF has clearly stated that it is not in the business of creating standards, having a chance to have other companies in the UCIF adopt the protocol of another member could be seen as significant.

Just how effective the UCIF will be remains to be seen, but it is a positive step forward. Testing and certification against standards is something that IETF has really not addressed. The IETF is a casual organization which has no regulated testing procedures for vendors that implement any of the RFC’s it produces. How the UCIF will market their seal of RFC compliance will be interesting but it could be quite desirable in a market place that has no other way to tell if a vendor has implemented an RFC correctly.

Comments welcomed.

VoIPNorm