Top 10 Things to Know About OCS 2007 R2

Published 11 January 09 09:59 PM | Sean Olson 

Our virtual launch is coming very soon, but I thought I would share some tidbits of information that you should know about OCS 2007 R2.  Just something to whet your appetite …

10.   64-bit

We’ve made the switch to 64-bit at last.  Industry trends all point to this being the right time to make such a switch.  The cost and availability of 64-bit hardware is unbelievable.  In just the short time between the release of OCS 2007 and the release of R2, hardware has grown by leaps and bounds.  We wanted to take advantage of that hardware and the only way to truly unlock it’s potential was to go native 64-bit.  This is not just a recompile.  There are significant changes involved.  For this and many other reasons, we have decided to bid farewell to the 32-bit server.

9.   Windows Server 2008

Customers demanded it and we have delivered – R2 has been re-designed to work effectively on Windows Server 2008.  This is also not just a simple recompile.  This means leveraging things like the improved (default) firewall in Windows Server 2008,  IIS 7.0,  EEC certificates, and much more.  

8.   Consolidation

In OCS 2007, we had two different options for deploying our Enterprise Edition:  consolidated and expanded.   Consolidated was simple to deploy because every server was running all the services (instant messaging, presence, conferencing, and voice).  But it was limited in scale at the time (30,000 concurrent users per pool) and so our largest customers would deploy expanded instead.  Expanded meant we took the resource intensive workloads (mainly web conferencing and audio/video) and offloaded them to dedicated servers.

Moving to 64-bit meant we could take advantage of the natural improvements in hardware and suddenly we could have the best of both worlds:  easy to manage and scalable.  We now recommend consolidated configuration for all deployments and we have the scale to match:  100,000 concurrent users per pool.  (Or 200,000 if all you need is IM and presence)

But we didn’t stop at the core server roles.  We also consolidated the Edge Server role so that there is now a single server role to deploy and you deploy multiple instances for scale.

7.   No More DNAT

We use load-balancers to effectively scale out deployments and most load balancers support two different modes of operation.  Load balancers inherently implement a network address translation (NAT) function as they attempt to make a single virtual IP address distribute across multiple physical servers.  There are two obvious ways to do NAT:  based on the destination address/port (DNAT) or based on the source address/port (SNAT).  In OCS 2007, we supported either mode.  In R2, we no longer support DNAT.

Why?  Because DNAT has some peculiarities when one of those physical OCS servers behind the load balancer wants to communicate with different OCS server in the same pool and wants to load balance that communication as well.  There’s no good way to make this work with DNAT.  With SNAT, this works just fine.  What’s the impact to you if you have already deployed?  A simple re-configuration of your load balancer.   No change in functionality or scale.

6.   System vs. Config

We leverage Active Directory extensively.  This comes directly from our vision statement where we believe a single identity is the core of any UC system.  For Microsoft, that single identity comes from Active Directory.  AD is effectively a smart, replicated, database.  There is a lot of information stored in Active Directory in general and so this replication can be network intensive.  For most deployments, this is a complete non-issue.  However, for very broadly distributed global deployments, the network connectivity between all sites is not always reliable.  The good news is that AD has a solution for this type of situation.  It involves putting your application settings into a different container (config) than the normal default (system).  The benefit of doing this is that you have a local copy of the config information that is available even when network connectivity between sites is down.

In previous releases, we gave you the option of using either (System or Config) but defaulted to System.  That made sense for typically centralized IM and presence deployments. It makes less sense for global, typically de-centralized voice deployments.  Our recommendation (and default) moving forward is the Config container.  If you have already deployed using the System container, don’t worry.  We have a tool to help you with the migration.  What you should know is that you need to do this migration BEFORE you attempt to deploy R2.

5.   Improved Updates

We’ve made some significant improvements in the way we handle updates to the clients and devices in R2.  In OCS 2007, we introduced the Update Server role which allowed you to keep your desktop phone and RoundTable device software up-to-date.  With R2, we now allow you to do the same with the Office Communicator desktop software as well.  What’s more we’ve addressed most of the shortcomings of the previous implementation including:

  • No more Sharepoint dependency (this stuff works out of the box)
  • Fully authenticated downloads
  • Better support for remote phones outside the firewall
  • Support for cross-language updates (go from English to French, for example)

4.   RDP-based Application Sharing

Ever use Remote Desktop or Terminal Server to access a remote machine?  Works pretty well, right?  Well now we use the same technology for application sharing in our product.  It’s so good I forget I’m even using it.  This is really fast, high fidelity, silky smooth application sharing – the way it’s meant to be.   And it works in a web browser… on a Mac… from anywhere.

3.   Dial-In Conferencing

You use them all the time.  Audio Bridges are a natural way people work nowadays.  Only now you no longer need to buy a separate bridge or pay per month or per minute.  The nice thing is that this is fully integrated with the rest of the UC solution.  You don’t have to worry about forgetting your PIN or remembering what your special meeting ID was meant to be. And you have complete control over who can join which calls – something that is hard to impossible to do in other systems.  More on this to come …

2.  Group Chat

We acquired a company called Parlano over a year ago.  Since then, we have been busy integrating this world-class group chat product into our overall UC solution.  With the release of R2, we are proud to announce the first Microsoft release of the new group chat functionality. Why is this important?  Because IM has become mission critical at many companies but they aren’t tapping the full value of those IM conversations.  With group chat, you get an indexed archive of these group collaboration sessions which you can search at any time.  The institutional knowledge that was once lost can now be preserved and leveraged.

1.  We’re Not Done Yet

We are still busy putting the finishing touches on things like SDKs, localizing into more languages, improving the planning tools, building the best documentation ever, and some pleasant surprises which I can’t discuss (yet).  I will share more as these pieces fall into place over the next few months.  There are some really exciting announcements coming at launch.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Petri said on January 21, 2009 5:30 PM:

Many thanks to you Sean, but you must clarify one thing!!

> 7. No More DNAT

When we are using virtual IP addresses for front end servers we are saying it as a DNAT. So far it seems that you (OCS team) have different mean for DNAT. Could you draw few pictures and show us the differences about this. Please

# Alenat said on March 13, 2009 9:16 AM:

The same question as for Petri. NAT is the way LB operates. If we connect from a Client to a VIP of LB the device translates destination IP to an IP of one of balanced FE. From my understanding it is DNAT since destination IP was changed. At the same time the LB should operate in SNAT replacing source IP of the Client to IP address of the LB so FE replies to LB, not to the Client directly. So it looks for me that LB must operate in both DNAT and SNAT modes. Where is my mistake? A network diagram would be great.

Thank you!

Alex

# Sean Olson said on March 13, 2009 5:05 PM:

To answer your question Alex, a given virtual IP address on a load balancer will be configured either to work in DNAT mode -or- in SNAT mode.  They are not used in combination.  As you point out, any load balancer is going to act as a NAT.  All we are saying is that we want the VIP used for OCS 2007 pools to be configured to use source NAT instead of destination NAT.  Specifically, I'm talking about NAT as seen by the server and not by the client.  Source NAT is preferrable for the server when it needs to connect to another server in the same pool (behind the same VIP)

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required

About Sean Olson

Sean Olson is the Group Program Manager for the Office Communications Server product at Microsoft. His team is responsible for all engineering aspects of conferencing, instant messaging, presence, and voice within the server product. He has over 10 years experience in the area of real time communications and voice over IP and is an industry expert in the Session Initiation Protocol (SIP) standardized by the IETF. Since joining Microsoft in 2002, he has delivered five releases of the Office Communications Server product line working on everything from protocols, to security, to performance.

Search

This Blog

Twitter

Syndication

Page view tracker