Deploying Office Live Communications Server 2005 and Office Communicator 2005 at Microsoft
Provided in this blog by David Cochrane
How Microsoft IT deployed and operates a reliable, enterprise-wide real-time presence and communications infrastructure
Technical White Paper
Published: July 2005
Microsoft Office Live Communications Server 2005 System Components
Understanding Live Communications Server 2005 with Service Pack 1
Internet Access and Federation Between Organizations
Performance and Capacity Planning
New Capabilities Enabled with Live Communications Server 2005 Service Pack 1
Upgrading to Live Communications Server 2005 with Service Pack 1
Remote User Access and Federation Between Organizations
Updated Remote Access and Federated Access Architecture
Lessons Learned and Best Practices
Increasingly, companies regard real-time presence and communications—such as instant messaging (IM), audio/video conferencing, data collaboration, whiteboarding, application sharing, remote assistance, and file transfer—as key services for connecting employees and improving their productivity.
Today, Microsoft employees are more mobile than ever. To increase their personal productivity, they frequently work from remote or home office locations, with little face-to-face contact with fellow employees, and collaborate with people they have never met in person. Microsoft® Office Live Communications Server enables Microsoft information workers to take advantage of real-time communications and presence to increase productivity without compromising security and manageability.
Previously, Microsoft had deployed Microsoft Exchange 2000 Server instant messaging services to support employee needs for basic presence information and instant messaging.
In the spring of 2003, Microsoft Information Technology (Microsoft IT) deployed Live Communications Server 2003 to replace the original deployment of Exchange 2000 Server instant messaging services. Designed for tighter presence integration into Microsoft Office System applications, and built using the industry-standard Session Initiation Protocol (SIP), Live Communications Server 2003 was the replacement for Exchange 2000 Server instant messaging services.
In the summer of 2004, Microsoft began deploying early releases of Live Communications Server 2005 to test the product in a large, worldwide enterprise environment. When fully deployed, five front-end servers and a two-node database cluster will support more than 80,000 enabled instant messaging accounts at Microsoft.
Subsequently, Microsoft IT deployed Live Communications Server 2005 with Service Pack 1 (SP1) to update its existing Live Communications Server 2005 infrastructure to support enhanced federation; public IM connectivity (PIC) and enhanced security and Spam over IM (SPIM) control; as well as support for Microsoft Office Communicator 2005 (Communicator). Communicator, in addition to supporting a significant new user interface and enhanced presence information, extends real-time communications to include the management of incoming and outgoing telephone calls over private branch exchange (PBX) networks, public switched telephone (PSTN) and voice-over-IP (VoIP) networks. Multi-party telephone calls and conference-calling capabilities are also supported using the services provided by the corporate PBX and third party conference-call services providers, respectively.
The focus of this paper is the experiences of the Microsoft IT Communications Operations team in planning, deploying, and operating its upgraded, protected, real-time, person-to-person communications solution based on Live Communications Server 2005 and the subsequent upgrade of this infrastructure to support Live Communications Server 2005 SP1 and Communicator.
This paper was specifically written for enterprise business and technical decision-makers, IT architects, and operations managers who are considering an upgrade (or initial deployment) of a real-time presence and communication infrastructure.
Customers frequently ask Microsoft IT about the methods employed and lessons learned when Microsoft products and technologies are deployed internally. In 1999, Microsoft IT deployed Microsoft Exchange 2000 Server instant messaging services to support its employees’ needs for basic presence information and instant messaging. In the spring of 2003, Microsoft IT deployed Live Communications Server 2003 to improve the ability of Microsoft employees to find and communicate with each other in real time.
Subsequently, in the summer of 2004, Microsoft IT worked together with the Live Communications Server product development group to plan and deploy Live Communications Server 2005. Microsoft IT identified six business needs related to real-time communication:
· Internet access without a virtual private network (VPN) connection
· Federation of real-time communications services with external organizations
· High-availability deployment
· Improved reporting
· Support for Microsoft SQL Server™ 2000 in addition to Microsoft SQL Server 2000 Data Engine (MSDE)
· Multiple forest management
In addition to running the global IT service internally, Microsoft IT is also committed to testing Microsoft enterprise products in production before releasing them to customers to ensure that they will scale to meet the business challenges of other large enterprises. In the spring of 2005, Microsoft IT and the Live Communications Server product group developed a strategy for deploying Live Communications Server 2005 SP1 and Communicator that enabled:
· In-place upgrade of the Microsoft IT production Live Communications Server server pool, director, access proxy server, and back-end database infrastructure
· Changes necessary to support the new Enhanced Federation features in Live Communications Server including federated support for the Microsoft IT third-party conference-calling services provider and retirement of its federated clearinghouse
· Support for managed connectivity with public IM Internet service providers such as MSN®, AOL® and Yahoo!®.
· Enhanced security and SPIM controls
· Back-end integration of the Live Communications Server infrastructure to support integration with the Microsoft IT telephone PBX and PSTN networks within the Puget Sound, WA area.
Because every organization is unique, each IT organization must develop its own plan for deploying Live Communication Server 2005. There were tasks in the Microsoft deployment plan that other organizations may never encounter, or that may need to be completed at different times in the process. For example, at the same time that Live Communications Server 2005 was originally deployed, Microsoft IT was also implementing network domain isolation based on Internet Protocol Security (IPSec), and deploying Microsoft Windows® XP Professional Service Pack 2. This affected the overall timing of the migration from Live Communications Server 2003 to Live Communications Server 2005.
Although this paper is not intended to serve as a step-by-step guide for deploying Live Communications Server, Microsoft is sharing this information to assist its customers in deploying this product in their own environments. Additional information about Live Communications Server is available at http://www.microsoft.com/office/livecomm.
Note: For security reasons, the names of forests, domains, and other internal resources do not represent real names used within Microsoft and are for illustration purposes only.
In 2003, Microsoft deployed Live Communications Server 2003 to provide a more secure, standards-based, real-time presence and instant messaging solution for its employees. The original Live Communications Server 2003 configuration deployed by Microsoft IT is illustrated in Figure 1.
Figure 1. Previous Live Communications Server 2003 Architecture
Nine Live Communications Server 2003 Standard Edition home servers were required, primarily because each forest was required to have one or more home servers to host the users in that forest. Live Communications Server 2003 Standard Edition was not designed for the high-availability requirements of large organizations like Microsoft. In addition, it was difficult to configure and support external Internet access for Microsoft employees to access their home servers without establishing a VPN connection. Lastly, configuring and enabling the federation of real-time presence and communications services at Microsoft with those of selected organizations and customers was not supported by Live Communications Server 2003.
Live Communications Server 2005 Enterprise Edition introduces a highly scalable, high-availability deployment model based on the concept of server pools. Live Communications Server 2005 Enterprise Edition supports multiple front-end servers per server pool and the use of clustered back-end SQL Server 2000 database servers. A large enterprise deployment can mix multiple Standard Edition servers and Enterprise Edition server pools.
Microsoft Office Live Communications Server 2005 System Components
In its simplest terms, three components need to be deployed to create a protected, real-time, person-to-person communications solution:
· Real-time presence and communications-enabled client application
· Real-time communications server
· Operating system and networking infrastructure.
Real-Time Communications Clients
Previously, Microsoft IT had deployed and supported Windows Messenger 5.1 as the standard client application for real-time communications. The latest real-time communications client from Microsoft is Microsoft Office Communicator 2005 which, when used with Live Communications Server, provides significantly enhanced presence and telephony integration in addition to improved instant messaging.
Microsoft Office Communicator 2005
While Live Communications Server 2005 SP1 supports Microsoft Windows Messenger 5.1 for basic presence and IM scenarios, it also delivers additional support for Communicator. New client features supported by Live Communications Server 2005 SP1 include:
· The ability to easily search for contacts using the Live Communications Server 2005 Address Book Service. This allows users to search for contacts from their corporate global address list (GAL), as well as local address information on their computer. This removes the need for a user to add a contact to their contact list before starting an instant messaging session.
· Integration with Microsoft Office Outlook® and Microsoft Exchange Server. This lets users view free/busy information for contacts based on their Exchange Server calendar information, and displays their 'Out of Office' messages directly in Communicator.
· Extended presence, including the ability to allow users to set “custom notes.” This provides richer information to other contacts, enabling them to make more-informed decisions on how to interact. This information is displayed whether or not a user is online, using the offline presence capabilities of Live Communications Server.
· The ability to control enterprise phones directly from a personal computer. With the appropriate PBX or PSTN gateway infrastructure in place, Communicator provides integration with enterprise telephony systems, allowing the user to initiate and even divert calls to a remote location when they are not at their desk.
· The ability to initiate conference calls with service providers and multi-party PBX-based PSTN telephone calls directly from Communicator, making it easier for information workers to communicate with others.
With Live Communications Server and third-party solutions for telephony integration, Microsoft Communicator supports enterprise telephony integration, including call control, call intercept, and presence-enabled call forwarding, as well as easy-to-initiate PSTN conference calling and Microsoft Office Live Meeting sessions.
A key new feature of Communicator used by many Microsoft employees is the ability to right-click on a contact group name and initiate an instant messaging session with all of the members of that contact group (for example, a support team for a specific product or the feature team in a development group). To provide each employee with an initial list of contacts and make them more immediately productive, each person’s contact list was pre-populated by Microsoft IT with four groups of contacts:
· Their direct reports (if the person is a manager)
· Their manager
· Their manager’s direct reports (their peers in their department)
· All the people in the organization of their manager’s manager.
Administration assistants found this particularly useful when they needed to know if a particular person in their organization is online and available to be contacted by telephone or instant messaging.
Windows Messenger 5.1
Windows Messenger differs from Communicator with its simultaneous support for three real-time communications protocol stacks:
· Session Initiation Protocol (SIP) to support Live Communications Server
· Rendezvous Protocol (RVP) for backward compatibility with Microsoft Exchange 2000 Server instant messaging services
· Mobile Status Notification Protocol (MSNP) supported by .NET Messenger Server public instant messaging service and used by the MSN Messenger consumer instant messaging client
The deployment of Windows Messenger, with its triple-protocol stack ("triple-stack"), enabled Microsoft employees to more easily make the transition from using Microsoft Exchange 2000 Server instant messaging services to Live Communications Server while also providing access to the MSN public IM service.
However, Microsoft IT and Microsoft customers found that it was difficult to manage and control employees’ access to public IM services including MSN, AOL, and Yahoo!. The solution is Communicator that supports a single protocol stack (SIP) to connect to the corporate real-time presence and communications infrastructure based on Live Communications Server. Live Communications Server, in turn, includes features for managing and controlling public IM connectivity (PIC) using a centralized set of server-based capabilities.
Withdrawing Microsoft IT Internal Support for Windows Messenger
Currently, Microsoft employees are encouraged to upgrade to Communicator based on the new telephony call control and enhanced real-time presence features. Over time, Microsoft IT will restrict the use of other instant messaging clients by using the administrative controls in Live Communications Server to restrict the protocol versions supported by Microsoft IT.
Live Communications Server 2005 Enterprise Edition
Live Communications Server 2005 Enterprise Edition is designed for large-scale deployments supporting over 100,000 users. This includes support for high scalability and availability with a load-balanced Microsoft Windows Server™ 2003 front-end server pool and a SQL Server 2000 SP3a back-end database server that can be clustered for high availability.
Live Communications Server 2005 is dependent on the following Windows Server 2003 services:
· Transport Layer Security (TLS) for client/server encrypted communications
· Mutual Transport Layer Security (MTLS) for server-to-server encrypted communications
· Active Directory® directory services for user authentication (including Kerberos and NTLM authentication)
· Directory forest and domain management
· Live Communications Server management console (with Microsoft Management Console)
· Domain Name Service (DNS) support for SRV (service) records enabling automatic configuration of connections between Communicator and Windows Messenger 5.1 (or 5.0) with Live Communications Server 2005.
Network and Active Directory Structures
Microsoft IT deployed an Active Directory design based on a primary forest as the container of user accounts, groups, and resources in the corporate domains controlled by Microsoft IT.
Domains within the primary corporate forest have multiple external trusts to child domains in the product development and test secondary forests. The child domains and secondary forests are used, for example, for developing and testing updated versions of Active Directory and Exchange Server in a production environment.
All of the forests are based on Windows Server 2003 except for one forest that is used for testing backward-compatibility with Microsoft Windows 2000 Active Directory services. Because of this backward-compatibility requirement, the trust relationship between the domains in this forest and domains in the primary corporate forest must be configured on a domain-by-domain basis. Kerberos transitive trusts exist between the primary corporate forest and the other Windows Server 2003 secondary forests.
The multiple-forest design allows Microsoft IT to centrally manage the network users and resources in the corporate, development, and testing forests; while at the same time isolate each environment from Active Directory schema changes being made in the other forests.
Because of the mixed forest environment and the Microsoft IT decision to deploy Live Communications Server 2005 Enterprise Edition using a high-availability configuration in a central forest, Microsoft IT needed to configure the new Live Communications Server 2005 director servers to use NTLM authentication.
To better appreciate how Live Communications Server 2005 was deployed at Microsoft, it is useful to understand the background information that drove the planning, design, and deployment decisions.
Microsoft Information Technology
Microsoft IT is responsible for driving global operations and delivering information technology services to the entire Microsoft organization. The IT group directs all activities related to running and maintaining Microsoft information systems worldwide: technology infrastructure and corporate and marketing information systems including production, distribution, and other key internal systems. Microsoft IT works to provide a world-class utility and excellence in business operations through its leadership in the design and integration of company strategies, processes, and architecture.
Microsoft IT provides a full range of services including server and end-user support, telecommunications management, network operations, and information security. They are responsible for managing connectivity for more than 300,000 devices worldwide. Microsoft IT also ensures that more than 60,000 employees and 20,000 contractors and vendors in over 400 Microsoft locations are able to access corporate network services and resources 24 hours a day, seven days a week, from around the world.
Because the primary business of Microsoft is software design, Microsoft IT has an additional responsibility that is unique among global providers. In addition to operating the company’s IT utility, Microsoft IT is an early adopter of Microsoft technologies. They are responsible for testing and deploying Microsoft products such as Windows Server 2003, Microsoft Exchange Server 2003, and Microsoft SharePoint® Products and Technologies before these products are released to customers. This process is known by those within Microsoft as “eating our own dog food” or simply “dog-fooding.”
Previous Experiences in Deploying Live Communications Server 2003
The Microsoft IT experience in deploying and managing Live Communications Server 2003 greatly influenced how it chose to deploy Live Communications Server 2005.
With Live Communications Server 2003, users were statically assigned to a single home server, and user profile and presence information was stored in the MSDE database on each home server. When a home server was unavailable, users assigned to that server needed to wait for the server to come online before the service was restored.
In addition, the recommended maximum number of users supported per server needed to scale beyond the limit of 10,000 to enable large deployments. Reducing the number of servers is a key factor in reducing overall hardware, software, and operating costs.
Lastly, employees, external organizations, and customers were looking for improved Internet access to the real-time person-to-person communications solution that Microsoft IT operated inside the Microsoft corporate firewall. Real-time presence provides its greatest value when it is easily available all of the time, regardless of whether an employee is connected to the Internet or the corporate network.
The Live Communications Server 2003 setup process also made it difficult for the Active Directory management team to independently plan and deploy the schema extensions required by Live Communications Server. The Live Communications Server 2005 setup program solves this by separating the Live Communications Server 2005 schema extension, installation, and activation tasks into distinct, installer-controlled steps.
Microsoft uses multiple forests to separately manage the product divisions, sales and marketing, and product support teams. Implementing multi-forest scenarios with Live Communications Server 2003 was a tedious process requiring schema changes in all forests, and custom identity synchronization solutions to be built using Microsoft Identity Integration Server 2003 (MIIS). More information on the Microsoft IT deployment of MIIS can be found in the IT Showcase white paper Enabling Cross-Forest Identity Management with Microsoft Identity Integration Server 2003 available at http://www.microsoft.com/technet/itsolutions/msit/deploy/cfimwiis.mspx.
Benefits of Deploying Live Communications Server 2005
Microsoft IT was able to address the above issues by deploying the Enterprise Edition of Live Communications Server 2005. The following Enterprise Edition features were key to the successful deployment of a new large-scale, high-availability real-time communications solution at Microsoft.
High Availability Deployment Scenarios
Live Communications Server 2005 Enterprise Edition provides a new option of configuring multiple front-end servers into a server pool with load balancing and fail-over. Server pools also enable server software upgrades to be implemented on a server-by-server basis without interrupting end-user services.
Support for SQL Server in Addition to MSDE
Live Communications Server 2005 Enterprise Edition uses SQL Server-based databases to maintain user-profile information, including a person’s contact list and blocked users list. In the 2003 release of the product, database server support was limited to MSDE, which was not scalable, could not be clustered, could not be administered remotely, and was more tedious to backup and restore. Live Communications Server 2003 automatically installed MSDE, and SQL Server was unavailable as a database server option.
Microsoft IT wanted the option of deploying either SQL Server or MSDE. Live Communications Server 2005 Enterprise Edition provides this option by including support for clustered, highly available database servers.
Multiple Forest Management
Deployment of Live Communications Server 2003 in a multi-forest environment like the one at Microsoft presented a number of challenges, including the inability to manage multiple forests from a single administrator logon, and difficulties in moving users from one forest to another.
The 2005 release of Live Communications Server was specifically designed to remove the cross-forest deployment and management barriers found in the earlier version of Live Communications Server through its support of a central forest model for large-scale deployments.
External Internet Access without needing a Virtual Private Network Connection
Another lesson learned from the Microsoft IT experience with Microsoft Exchange Server is the need to support remote access to selected messaging services without requiring a user to first establish and log on to a VPN connection.
In Microsoft Exchange Server 2003, this feature is referred to as “RPC over HTTP” (“Remote Procedure Call over HTTP"). In Live Communications Server 2005, this is referred to as the “remote user” scenario.
Reduced use of VPN services reduces hardware, software, and operating costs. More importantly, accessing real-time presence information without requiring a VPN provides true real-time indication of availability of the people on a user’s contact list.
Microsoft employees are active instant messaging users. They provide a model environment for the Live Communications Server product group to test updated releases of Live Communications Server in a large, worldwide, enterprise setting. A partial list of goals for the deployment of Live Communications Server included:
· Product stability and availability, as measured by days without a priority one failure, and actual versus planned server uptime.
· Usage as measured by number of enabled users, number of concurrent logged-on users, number of concurrent active users, and number of servers deployed or upgraded.
· Manageability, which includes the ability to migrate user information using in-the-box tools and Microsoft Operations Manager (MOM) support.
In addition, a matrix of tracking metrics is maintained that includes, for example, the total message traffic categorized by the number of messages and data volume, the number of help desk calls, and the number of product group software updates.
A detailed description of the Microsoft IT deployment of Live Communications Server 2005 is provided in the Solution section of this white paper. For readers unfamiliar with the new features found in Live Communications Server 2005, they are described in the next section, Understanding Live Communications Server 2005 with Service Pack 1.
Understanding Live Communications Server 2005 with Service Pack 1
To understand how Microsoft IT deployed its protected, real-time communications solution, it is important to understand the new deployment and management features in Live Communications Server 2005; and the new and updated features in Live Communications Server.
Readers already familiar with these features may choose to skip to the Solution section, which specifically addresses the Microsoft IT deployment of Live Communications Server 2005. Additional information can also be found on the Live Communications Server 2005 Web site at http://www.microsoft.com/office/livecomm.
The original 2003 release of Live Communications Server focused on five key attributes:
· Increase individual productivity using presence, IM, and real-time communication capabilities
· Familiar tools for managing users, client software, servers, and network settings
· Extensible, real-time communications platform for custom client- and server-side solution development
· Standards-based signaling and communications protocols based on Session Initiation Protocol (SIP) and SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) protocols
· Integration with the Microsoft Office System.
Live Communications Server 2005 builds on these key capabilities to provide new connectivity features and high-availability and scalability options to support large enterprise deployments.
Live Communications Server 2005 is designed to improve business efficiencies by enabling information workers to find and communicate with their colleagues in real time with a security enhanced enterprise-grade environment that is integrated with the Microsoft Office System.
Live Communications Server 2005 is available in two product configurations: Standard Edition and Enterprise Edition. Live Communications Server 2005 Standard Edition is installed as a single-server configuration using MSDE as the local database server; Enterprise Edition offers high-availability and scalability options using multiple front-end servers and SQL Server 2000 as the back-end database server, optionally clustered for high database server availability.
Live Communications Server 2005 Enterprise Edition provides the following enterprise deployment and scalability options:
· Distributed, two-tier architecture for fault tolerance
· Ability to use clustered or unclustered SQL Server 2000 back-end database servers
· Resilient client connectivity that enables clients to automatically reconnect to a different front-end server should the original server become unavailable due to planned or unplanned outages
· Third-party backup and restore support
· Scale-out support from a single server supporting 15,000 users, to server pools supporting more than 100,000 simultaneously active users
· Bandwidth-optimized protocol support
· Storage Area Network (SAN) interoperability.
Figure 2 is representative of a typical high-availability Live Communications Server 2005 Enterprise Edition solution that is capable of supporting over 100,000 simultaneously active users. There are two roles for the primary servers in an Enterprise Edition server pool: front-end servers, and database servers. Additionally, to support external Internet access and inter-organization federation of real-time communications services, one or more Live Communications Server 2005 access proxy servers may be deployed in the perimeter network. Live Communications Server 2005 director servers may be required in situations where specialized SIP message routing is required (for example, when additional Live Communications Server 2005 application servers are deployed outside of the enterprise server pool).
Figure 2. Live Communications Server 2005 high-availability server pool example
Director Servers
In the high-availability server pool example depicted in Figure 2, the director servers are the first servers to receive SIP message streams from Communicator or Windows Messenger intranet users or, via a Live Communications Server 2005 access proxy server, remote users. For intranet requests, the director server redirects users to the server pool. For Internet requests, the director server forwards the SIP message to the appropriate server because Internet users do not have a direct connection to servers in the intranet. During migration to Live Communications Server 2005, director servers enable users to communicate with a mixed Live Communications Server 2003 and Live Communications Server 2005 environment without changing their client configuration.
Front-End Servers and Server Pools
A server pool is a group of front-end servers that appear as a single virtual IP address resource. This is achieved with a hardware network load balancer. When a director server directs a user to a server pool, it directs the user to the virtual IP address of the network load balancer; which in turn selects the available front-end servers to handle the user connection.
Additional front-end servers can be added to a server pool as required during a phased deployment of Live Communications Server 2005 (or as an organization grows). In addition, the hardware network load balancer enables selected front-end servers–usually one at a time–to be temporarily taken out of service for maintenance or replacement without affecting service levels. Often an additional front-end server is added to the server pool to provide additional capacity to support fail-over in the event of planned or unplanned server outages.
Database Servers
With Live Communications Server 2005 Standard Edition, the database is a local MSDE database service running on each home server. With Live Communications Server 2005 Enterprise Edition, in a typical enterprise configuration, the database server is a SQL Server 2000 server that is both logically and physically separated from the front-end servers. In a high-availability scenario, the database server is configured as a two-node active-passive clustered SQL Server database server connected to a shared storage device; typically, a storage-area network (SAN). The latter scenario is depicted in Figure 2.
Access Proxy Servers
Similar in function to Live Communications Server 2003 forwarding proxy servers, the role of an access proxy server in a Live Communications Server 2005 configuration is to act as a secure connection point for remote users as well as users from other selected organizations who have been configured for federated access. A single proxy server can be deployed, or, for a more scalable and highly available remote access solution, multiple access proxy servers can be placed behind a network load balancer.
Access proxy servers check that the inbound message headers are valid (including the destination domain) and mark each message as originating from outside the firewall. Messages from an access proxy server are sent to a director server. Messages are then forwarded to a Live Communications Server Standard Edition server or Enterprise Edition server pool. This deployment model can support very large traffic volumes more easily and provides for authentication on the access proxy server.
Archiving Agent and Database Servers
Microsoft IT configured one archive agent server and one archive database server as part of its production Live Communications Server 2005 environment. The archiving database server uses the SAN environment to store statistics collected by the archiving service. Microsoft IT chooses not to archive message content.
Microsoft IT uses the data to analyze the Live Communications Server 2005 environment. The archived data is not stored for long-term retrieval. In addition, deployment of the archiving infrastructure was an important part of the Live Communications Server testing effort.
In addition, Microsoft enabled the flat-file logging feature in Live Communications Server 2005. Live Communications Server 2005 flat-file logging logs only the session header information, not the message content. While the SQL Server archive logs are easier to analyze, Microsoft also enabled flat- file logs because they contain more detailed information about audio/video sessions, PC-to-phone sessions, etc. than is available by using SQL Server archiving logs alone.
Internet Access and Federation Between Organizations
Many enterprise users also use public instant messaging services to communicate with fellow employees, customers, friends, family members, and other associates. Live Communications Server 2005 helps IT departments manage these diverse needs by supporting:
· More secure, inter-enterprise federation of real-time presence and communications
· Managed access to public instant messaging services
Federation enables a trust to be established between two organizations that allow presence and instant messages to be freely but more securely exchanged between the Live Communications Server 2005 infrastructures running in each organization. Access proxy servers run in the perimeter network to verify each incoming request. Depending on whether a server pool or individual home server approach is used to deploy Live Communications Server 2005, the incoming request will be directed to a director server or front-end server.
Performance and Capacity Planning
Microsoft IT found that Live Communications Server 2003 was able to support a maximum of 10,000 active users on a single home server using MSDE. The Microsoft IT goal was to support 15,000 active users per server using the front-end server pool and clustered back-end database deployment model available in Live Communications Server 2005 Enterprise Edition.
Using Live Communications Server 2005 Enterprise Edition, a single server running with a separate SQL Server back-end database server can be expected to support approximately 15,000 to 20,000 active users; or over 100,000 simultaneously active users in a server pool consisting of five front-end servers and a separate clustered SQL Server back-end database server. Product group testing has found CPU utilization is typically much lower with Live Communications Server 2005 and user logons execute much faster because of protocol optimizations that reduce the number of round trips to the server.
In addition, the support for real-time communication services that is built into Microsoft Office 2003, Windows SharePoint Services, and SharePoint Portal Server 2003 must also be considered. After the deployment of Live Communications Server, Microsoft Office System users are able to see presence information for other enterprise users and can send an instant message from within an Office application such as Microsoft Outlook and Microsoft Word, and from within Web sites created through Windows SharePoint Services. This causes additional load on the front-end servers and needs to be taken into account during capacity planning (the 15,000 active users per Enterprise Edition server accounts for this additional load).
New Capabilities Enabled with Live Communications Server 2005 Service Pack 1
Live Communications Server enables the following new and enhanced capabilities in addition to its support for Communicator:
· Public IM connectivity (PIC)
· Enhanced federation
· Enhanced security and SPIM control.
Public IM Connectivity
Live Communications Server 2005 SP1 delivers the tools necessary to connect customers to PIC Internet service providers, including MSN, AOL, and Yahoo!. Live Communications Server users who are licensed for PIC are able to use Communicator to add contacts, send instant messages, and share presence information with users of MSN Messenger, AOL Instant Messenger, and Yahoo! Messenger.
Live Communications Server provides administrators with controls for enabling PIC on a per-user basis. A user is enabled for either all configured public instant messaging services or none. Where appropriate, administrators can also choose to log messages sent to and from the public IM Internet service providers. As with any types of Live Communications Server federated access, individual public IM Internet service providers can be blocked on a domain-by-domain basis by configuring the appropriate access proxy server.
Public IM connectivity is available only with Live Communications Server 2005 SP1. It requires the acquisition of PIC-specific service licenses. For more information on the provisioning process, refer to https://main.livemeeting.com/LCSVL/.
Enhanced Federation
Federation is the ability to establish trusted relationships between your organization and one or more external organizations that allow users to initiate and share IM sessions and subscribe to user presence across network boundaries.
Enhanced federation simplifies the deployment model for the federation in Live Communications Server 2005 by supporting dynamic discovery of external Live Communications Server environments, which reduces the need for static direct federation configurations. Live Communications Server also gives network administrators the ability to control enhanced federation access to their organizations by being explicitly able to designate external domains that can or cannot access the organization’s access proxy server(s).
The enhanced federation of Live Communications Server 2005 SP1 uses Domain Name System Service Location (DNS SRV) resolution to locate a federated organization’s Live Communications Server access proxy server. This enhancement therefore eliminates the need to specify the access proxy server of each and every federated organization, and provides the Full Qualified Domain Name (FQDN) of your organization's access proxy server to these organizations. While simplifying the process, Live Communications Server uses mutual Transport Layer Security (TLS) to secure the federated connections.
By using enhanced federation (and decommissioning its federated clearinghouse infrastructure), Microsoft IT was able to deploy a simpler solution which required less administration and lower operations overhead, and which provided more direct control, making it more secure.
From a security perspective, Microsoft IT deployed enhanced federation using a restricted access model where the domain of each external organization is specifically added to the access proxy server configured to support federation.
Enhanced Security and Spam over IM Control
Live Communications Server 2005 SP1 introduces two new filters to help protect your organization, and each enterprise-to-enterprise federated connection, from malicious attacks.
The first is an optional spam over IM (SPIM) filter that reduces unauthorized or unsolicited messages and is configurable to suit the needs of your organization. Instant messaging and sharing presence information with users connected to public IM Internet service providers, MSN, AOL, and Yahoo!, are restricted to names explicitly specified in each user’s Allow or Block list. This restriction provides additional control of SPIM.
Live Communications Server also introduces a new IM filter application that blocks messages containing URLs or file transfer requests. This filter application can be enabled when your organization is under threat of a virus being propagated through these methods. The Microsoft IT deployment of Live Communications Server blocks all file transfer requests as well as URLs that appear in instant messages.
Additional Improvements
The following additional improvements are also included with Live Communications Server 2005 SP1:
· Support for multiple-tree forest topologies previously documented in Knowledge Base article KB#889327. An Active Directory forest with multiple trees does not appear as expected in the Live Communications Server 2005 Microsoft Management Console (MMC) snap-in.
· Improved server API performance can handle approximately three times more messages with a significantly lower CPU utilization on the server.
· The improved in-place upgrade process from Live Communications Server 2005 to Live Communications Server 2005 SP1 means the manual exporting and importing of existing databases is no longer necessary, as it was previously with a migration from Live Communications Server 2003 to Live Communications Server 2005.
The original planning and deployment of Live Communications Server 2005 to create a security enhanced, real-time, person-to-person communications solution occurred in six stages. In addition to the project goals discussed earlier, Microsoft IT defined the following four objectives for this project:
· Deploying Live Communications Server 2005 using a central forest deployment model
· Ensuring that previous versions of Live Communications Server can co-exist and interoperate with Live Communications Server 2005 Standard Edition servers and Live Communications Server 2005 Enterprise Edition server pools. This objective is important for many Microsoft customer upgrade and co-existence scenarios and is a specific requirement for upgrading the Microsoft IT Live Communications Server 2003 deployment
· Giving users the ability to retain their individual contacts list and a blocked users list after migrating from the 2003 to the 2005 release of Live Communications Server
· Reusing existing server hardware that continued to meet the Live Communications Server 2005 prerequisites.
The six major stages that Microsoft IT used to plan its deployment of Live Communications Server 2005 were based on the work that needed to be accomplished, and the effect that the work would have on the groups of users targeted by each stage. As exit criteria, each stage needed to be executed completely and successfully before the project could advance to the next stage. The following is a brief description of each of the six stages that Microsoft IT used for the deployment phase of this project:
1. Preparation. The basic components of the Live Communications Server 2005 environment were put in place. These included: deploying a central forest to host the Live Communications Server 2005 server pool; deploying the 2005 Active directory schema extensions; installing and configuring the SQL Server database server cluster (including a dedicated SAN); and installing a single Live Communications Server 2005 Enterprise Edition front-end server. Selected users from Microsoft IT were enabled for this environment so they could test each of the 2003 and 2005 interoperability scenarios.
2. Server Pool Deployment. Extend the server deployment to add Live Communications Server 2005 Enterprise Edition servers in the server pool as users were migrated from Live Communications Server 2003 infrastructure. Users from three of the smaller Active Directory forests were migrated to the Live Communications Server 2005 central forest during this stage.
3. User Mass Migration. Having tested and verified the interoperability between the 2003 and 2005 releases of Live Communications Server, the migration of the remaining large forests was undertaken.
4. Live Communications Server 2003 Cleanup. This stage involved: removal of the remaining Live Communications Server 2003 environment; updating of the performance log data monitoring and gathering processes; and updating the installation, disaster recovery, and troubleshooting and operations guides for the new Live Communications Server 2005 environment.
5. Test Server Deployment. In preparation for production testing of the ongoing deployment of product updates, a Live Communications Server 2005 Standard Edition server was deployed. Selected users from Microsoft IT and the Live Communications Server product group were migrated from the Enterprise Edition server pool to the new Standard Edition production test server.
6. External Internet Access. An external director server dedicated to the access proxy server was deployed to provide remote access for employees and selected external customers and contacts, without having to go through a VPN.
Overall, the strategy consisted of a side-by-side installation and configuration of Live Communications Server 2005 with the predecessor release followed by the migration of successive groups of users to the new platform.
The deployment of Live Communications Server 2005 SP1 was facilitated by the enhanced in-place upgrade process that did not require the manual exporting and importing of existing databases that was required when Microsoft IT migrated from Live Communications Server 2003 to Live Communications Server 2005. The following sections describe The Microsoft IT original experience upgrading to Live Communications Server 2005. The description of the Live Communications Server upgrade process at Microsoft follows these sections.
To provide continuous instant messaging service during the deployment of Live Communications Server 2005, and to accommodate the new two-tier, server-pool deployment model, Microsoft IT was required to deploy the Live Communications Server 2005 server pool and then migrate the 2003 users. When no longer needed, the 2003 servers would then be erased, rebuilt, and redeployed within one of the data centers at Microsoft.
Active Directory Planning
Live Communications Server requires that Active Directory provide optimal security and manageability of servers and clients. Live Communications Server supports Active Directory on either Windows 2000 Service Pack 3 (SP3) or Windows Server 2003. However, for multiple-forest organizations, all forests must be pure Windows Server 2003 forests to provide cross-forest Kerberos authentication.
If an organization does not have all Windows Server 2003 domain controllers in a forest, the initial authentication from a Communicator or Windows Messenger client may fail. The solution is to configure Live Communications Server to use NTLM authentication on director servers. In this scenario, after the client is authenticated as an end user through NTLM, the internal director server directs the client to the appropriate server pool server.
The Live Communications Server database minimizes the impact on domain controllers. The only cases in which Live Communications Server communicates with a domain controller are as follows:
· Full Active Directory synchronization during initial server start-up
· Incremental synchronization when Active Directory is updated. Active Directory is checked approximately every five minutes and has little impact on domain controllers after the initial server start-up
· When a user is provisioned for real-time communications services
· When the Live Communications Server service starts up.
With Live Communications Server 2005 Enterprise Edition, Microsoft IT was able to deploy its internal real-time communications service as a high-availability solution in the central corporate forest. This implied that Microsoft IT was able to limit the deployment of the Live Communications Server 2005 Active Directory schema extensions to the central corporate forest (and not deploy the schema extensions across the secondary product development and test forests).
Domain Name Service Planning
Microsoft IT used automatic, rather than manual, configuration of Communicator and Windows Messenger clients. Microsoft IT set up automatic configuration at the time each client was installed, and then configured the Domain Name Service (DNS) service to support the use of automatic configuration for the Live Communications Server namespace.
When an organization uses automatic configuration of the client, the client looks up a DNS service location (SRV) record for the Live Communications Server service. The DNS SRV record has the effect of mapping the namespace of the Live Communications Server service to a specific server name and TCP/IP port number.
When Communicator or Windows Messenger starts, it performs a DNS SRV record lookup based on the namespace in the user's SIP communications server account. For example, for a user logging into the contoso.com namespace, Communicator (and Windows Messenger) uses the following convention to look up the name of the Live Communications Server DNS SRV record:
_sip._tls.contoso.com
The DNS SRV record lookup returns the DNS name of the server, server pool, or director server that the user is to connect to as well as the TCP/IP port to be used (typically, port 5061 for encrypted TLS connections and port 5060 if unencrypted TCP/IP connections are used).
If the DNS SRV record is not available, the client performs a conventional DNS lookup for a server name comprising "sip." followed by the namespace of the user's account. Using the above example, the DNS "A" record would be named:
sip.contoso.com
Once the DNS name and port have been resolved, Communicator (or Windows Messenger) is then able to connect to the Live Communications Server 2005 services.
Automatic configuration gives greater flexibility in managing the servers to meet the needs of the users and the environment while decreasing client management and operations costs.
Configuring DNS for Remote User and Federated Access
To support federated access via a Live Communications Server 2005 access proxy server, a conventional DNS "A" record for the access proxy server needs to be configured in the organization's external DNS server. Typically, the name of the DNS record is same as the internal name (for example, sip.contoso.com). TLS (and MTLS) encrypted connections are established using the default port 5061.
To support remote user connections to the central forest server pool at Microsoft, Microsoft IT chose a slightly different approach. Microsoft employees are often mobile users working from customer offices and home offices. In these environments, port 5061 is often blocked by the local firewall while port 443, the default port used for Secure HTTP (HTTPS) access, is left open. To address this situation, Microsoft IT configured the Live Communications Server 2005 access proxy server (and the corresponding external DNS SRV record) to use port 443 rather than the default port 5061. TLS is used to encrypt these remote user connections.
Support for remote access over port 443 has proved extremely valuable for Microsoft Consulting Services consultants needing to communicate with each other; as well as product developers and support engineers working inside the firewall at Microsoft.
Certificate Services
To ensure that TLS can be used as the transport protocol by Live Communications Server 2005, an organization must have a public key infrastructure (PKI) available. Certificates are used to initiate a TLS connection between the server and the client. Because Microsoft already deployed an internal PKI based on Windows Server 2003 certificate services, Microsoft IT used the automatic enrollment features of Microsoft Windows to obtain certificates for the servers running Live Communications Server. Automatic enrollment allows each server to automatically request and receive its certificate from the enterprise certificate authority (CA) as soon as the server joins the domain.
Because every server and every client at Microsoft is automatically enrolled and receives a certificate when it joins a Microsoft IT-controlled domain, no additional work was required for certificates. That is, Live Communications Server does not require the explicit creation of special certificates. Live Communications Server uses certificates that meet the following requirements:
· The certificate must enable client and server authentication.
· The certificate must contain the fully qualified domain name (FQDN) of the server.
In the Live Communications Server architecture, the underlying operating system caches certificate information for the clients and servers.
Network Capacity Planning
Live Communications Server consumes, on average, 1.6 kilobits per second (Kbps) of network bandwidth per user over an eight-hour period for presence and instant messaging traffic. Microsoft IT arrived at this value based on previous Live Communications Server product group testing. This value was sufficient to convince Microsoft IT that it was able to centralize the deployment of its Live Communications Server servers, because the high-bandwidth connections between the Redmond data center and the regional data centers had sufficient capacity to handle the traffic across wide area network (WAN) links. Network data compression helped reduce the bandwidth used by the real-time communications services.
Microsoft IT recognized that a centralized model would increase overall logon time when a user logged on to a server. However, the measured increase in logon time was a fraction of a second and was not noticeable to users. The centralized model offered more tangible cost savings benefits through simplified management.
Security Planning
Microsoft IT increased the security of the Live Communications Server service by deploying Communicator with high-security mode enabled, and by disabling all transport modes except for TLS.
With the preceding settings and high-security mode on the client, behavior in the Microsoft environment is as follows:
· TLS encrypts information between servers and clients across TCP/IP ports. The default communications protocol in Live Communications Server is unencrypted TCP.
Note: On the server side, Microsoft IT configured mutual TLS (MTLS) to encrypt information that travels between servers.
· Live Communications Server requires Kerberos or NTLM authentication. Kerberos is the default authentication method for Live Communications Server. For backward compatibility with Windows 2000–based computers maintained by Microsoft test and product support teams, Microsoft IT uses NTLM for authentication on front-end servers. If only Kerberos were used on the front-end servers, security would be improved but users in a Windows 2000 forest would not be authenticated.
· Universal Plug and Play for network translation tables, which is dependent on unauthenticated HTTP protocols, is disabled on the client.
· Peer-to-peer connections are disabled for all IM sessions. This forces all communications, including audio/video and data collaboration session invitations, to be routed through Live Communications Server. Allowing instant messages to go directly from one client to another creates a security risk because instant messages cannot be archived and cannot be scanned for inappropriate uses.
· Audio/video conferencing and data collaboration sessions themselves still use peer-to-peer connections after the initial invitation has been accepted.
High-security mode contains optional features, such as disabling connectivity to the MSN .NET Messenger Service and Exchange IM. However, Microsoft IT did not disable the MSN .NET Messenger Service on the client pending the selection of alternative means for providing Microsoft employees with access to family members on public instant messaging networks.
In addition to the preceding security considerations, an organization can use Group Policy to require audio and video encryption. Microsoft IT did not use this configuration because audio and video encryption increases the time needed to set up a conference. In this case, Microsoft IT was more concerned about the user experience than the security of the connection. Because the data traverses only the internal network, there is little risk of someone being able to reconstruct individual network packets for an audio or video communication.
This is in addition to the Microsoft IT deployment of IPSec to support network domain isolation. For more information on the enterprise-wide deployment of IPSec at Microsoft, refer to the Microsoft IT Showcase white paper Improving Security with Domain Isolation: Microsoft IT Implements IP Security (IPSec) available at http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx.
Communications Plan
All Microsoft IT employee communications regarding the ongoing software deployments are coordinated by and originate from a dedicated client services team in Microsoft IT. This ensures that employees receive e-mail messages from Microsoft IT that are of a consistent quality, and are properly timed and coordinated with other Microsoft IT projects that also need to communicate their plans and needs to Microsoft employees.
For the original Live Communications Server 2005 migration and subsequent upgrade to Live Communications Server 2005 SP1, e-mail notifications were used to advise employees when the migration would affect them individually, the location of the end user support help page, and how to contact Helpdesk if they have any further questions or issues.
Microsoft IT creates an end-user support Web page for each product it supports (including Communicator, Windows Messenger and services provided by the deployment of Live Communications Server 2005). This Web page includes a list of frequently asked questions (FAQs), additional self-help and troubleshooting information, and a link to the internal software distribution servers where Microsoft employees can download and install the latest real-time communications client.
Microsoft IT took advantage of a key enterprise deployment feature in the release of Live Communication Server 2005: the ability to deploy a high-availability server pool using a central forest deployment model.
Central Forest Deployment Model
From an Active Directory perspective, the Live Communications Server 2005 server pool was deployed into a central forest (the Microsoft corporate forest). This is where the greatest number of user objects had been created. Microsoft IT enabled Live Communications Server features for every user object that was enabled for e-mail. If the e-mail enabled user object was already in the central forest, the central forest user object was enabled for real-time communications services.
If an e-mail enabled user object is in one of the secondary forests, Live Communications Server 2005 supports using an Active Directory contact object in the central forest as a user principal. Microsoft IT used Microsoft Identity Integration Server 2003 (MIIS) to automate the creation and synchronization of the central forest contact objects with the user objects in the secondary forests.
Previously known as Microsoft Metadirectory Services (MMS), MIIS is a centralized service that stores and integrates identity information for organizations with multiple directories. The goal of MIIS is to provide organizations with a unified view of all known information identifying users, applications, and network resources. MIIS helps improve productivity, reduce security risk, and reduce the total cost of ownership associated with managing and integrating identity information across the enterprise.
The process flow for exporting secondary forest/child domain user objects and the creation of the corresponding central forest contact objects is illustrated in Figure 3. MIIS selects the user-object information from the secondary forests and creates the contact objects in the central forest. One-way trusts must be created from the central forest to each of the secondary forests if they do not already exist.
Figure 3. Microsoft IT cross-forest topology
Server Pool Architecture
The original Live Communications Server 2005 server pool architecture deployed by Microsoft IT is illustrated in Figure 4. Having all Microsoft employees and contractors configured in the central forest as either local user objects or imported contact objects is sufficient for Live Communications Server 2005 to provide protected, real-time presence and communications services to all users regardless of their home domain. This centralized, highly scalable design eliminated the need to deploy separate Live Communications Server servers into each secondary forest or child domain.
Figure 4. Original Live Communications Server 2005 corporate central forest architecture
The Live Communications Server 2005 applications server included in Figure 4 hosts custom server-side code that allows applications to intercept and reroute IM messages intended for application agents (rather than conventional, real-time communications client users). Microsoft IT developers use the Standard Edition applications server to test and support new applications.
This section describes the Microsoft IT experience deploying the original Live Communications Server 2005 server pool architecture depicted in Figure 4; and migrating from the previous deployment of Live Communications Server 2003 to Live Communications Server 2005.
The key steps that Microsoft IT included in its original deployment of Live Communications Server 2005 can be summarized as follows:
· Select the forest to be used as the central forest, and extend the Active Directory schema using the Live Communications Server 2005 setup wizard
· Set up the Live Communications Server 2005 front-end server pool, initially with one front-end server, and the clustered SQL Server back-end database server and SAN
· Configure MIIS Live Communications Server synchronization
· Export users’ Live Communications Server 2003 data from secondary forests
· Import users’ data into central forest contact objects
· Re-home contacts in central forest
· Disable Live Communications Server 2003 user object in secondary forests
· Decommission and recycle existing Live Communications Server 2003 servers
· Clean up Active Directory contact objects and Live Communications Server 2003 attributes from secondary forest user objects.
Server Hardware
Microsoft IT used server hardware configurations that were based on the Microsoft IT standard configurations that most closely matched the hardware requirements for Live Communications Server 2005.
Table 1. Microsoft IT Deployed Server Hardware
| Server Role | Configuration |
| Access Proxy Server | Dual Intel Xeon 3.06 GHz, 1 MB Cache, 533 MHz FSB 2 GB DDR 266 MHz RAM 2 x 18 GB HDD (15,000 RPM SCSI), 2 GB Network Interface Card (NIC) Windows Server 2003 Service Pack 1 Live Communications Server 2005 with Service Pack 1 (Access proxy server setup option) |
| Director Server | Dual Intel Xeon 3.06 GHz, 1 MB Cache, 533 MHz FSB 2 GB DDR 266 MHz RAM 6 x 18 GB HDD (15,000 RPM SCSI) 100 MB Network Interface Card (NIC) Windows Server 2003 Service Pack 1 Live Communications Server 2005 Standard Edition with Service Pack 1 |
| Pooled Front-End Server | Dual Intel Xeon 3.06 GHz 1 MB Cache 533 MHz FSB 2 GB DDR 266 MHz RAM 4 x 18 GB HDD (15,000 RPM SCSI), 100 MB NIC Windows Server 2003 Service Pack 1 Live Communications Server 2005 Enterprise Edition with Service Pack 1 |