Top 10 Things to Know About OCS 2007 R2
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.
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.