|
| Search Microsoft.com for: |
|
| Search Microsoft.com for: |
Deploying Office Live Communications Server 2005 and Office Communicator 2005 at MicrosoftHow Microsoft IT deployed and operates a reliable, enterprise-wide real-time presence and communications infrastructurePublished: July 1, 2005
On This Page
Executive SummaryIncreasingly, 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. IntroductionCustomers 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:
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:
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. SituationIn 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. Note: In Live Communications Server 2003, the servers that hosted the real-time communications services were called home servers. Live Communications Server 2005 Standard Edition is based on a similar design where the MSDE is used to store user data on each local server. 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 ComponentsIn its simplest terms, three components need to be deployed to create a protected, real-time, person-to-person communications solution:
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:
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:
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:
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:
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. BackgroundTo 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. 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. Project GoalsMicrosoft 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:
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 1To 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. The original 2003 release of Live Communications Server focused on five key attributes:
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. Availability and ScalabilityLive Communications Server 2005 Enterprise Edition provides the following enterprise deployment and scalability options:
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 OrganizationsMany 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:
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 PlanningMicrosoft 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 1Live Communications Server enables the following new and enhanced capabilities in addition to its support for Communicator:
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:
SolutionThe 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:
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:
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. PlanningTo 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:
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:
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:
Note: On the server side, Microsoft IT configured mutual TLS (MTLS) to encrypt information that travels between servers.
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). 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. ArchitectureMicrosoft 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. DeploymentThis 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:
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.
Central Forest Active Directory Synchronization The following table is the list of Live Communications Server 2005 directory attributes that required synchronization between the secondary forests and the central forest.
Microsoft IT used MIIS to perform the synchronization of user objects in the secondary forests with the MIIS database and subsequently, from the MIIS database to the Active Directory contact objects in the central forest. OperationsThe Communications Operations group performs routine tasks for maintaining Live Communications Server. For example, Communications Operations collects daily counters that monitor key functions of servers to determine the load on those servers. Other routine maintenance tasks include backing up the servers and examining available disk space, memory usage, and processor performance. These tasks are similar to the operations of other IT services deployed at Microsoft. Support Structure When a problem with a server running Live Communications Server is identified at Microsoft, the problem is escalated through the Microsoft organization as follows:
Microsoft has four service level agreement (SLA) response times in place to resolve issues for any service. These response times, shown in the following table, apply across all tiers of support.
Training of Client Support PersonnelDuring the early-adopter deployment of Live Communications Server at Microsoft—before training material for client support personnel was released to the public—Communications Operations held training sessions with the client services team for the issues unique to Tier 2 of the escalation hierarchy. In general, client services deals with account problems (such as issues in Active Directory) that prevent a user from using services such as Live Communications Server. To ensure that Helpdesk personnel were prepared to handle user issues related to Communicator and Windows Messenger, the Communications Operations group held a separate training session with Helpdesk subject matter experts (SMEs). The SMEs then trained their own staff to support the real-time communications client applications. Communications Operations created a troubleshooting guide for Tier 1 and Tier 2 Helpdesk staff to use in handling client-side issues. Operations Support Once fully deployed, the Live Communications Server central forest consisted of seven servers and supported approximately 80,000 enabled accounts at Microsoft. The solution is monitored and maintained by a senior operations analyst on the Microsoft IT Communications Operations team. The senior operations analyst relies on the Microsoft IT data center infrastructure for server backup services, first- and second-level Helpdesk services, and basic server monitoring. The senior operations analyst uses the Live Communications Server 2005 Microsoft Operations Manager 2005 (MOM) management pack to configure a MOM console for monitoring and tracking key operational metrics. All third-level support problems and solutions are documented on an internal Microsoft IT site available to Tier 1 and Tier 2 Helpdesk personnel. Server Monitoring At Microsoft, MOM is used to manage the server tier of a computer infrastructure, including core services such as Active Directory, DNS, and dynamic host configuration protocol (DHCP). MOM collects, in a central SQL Server database, predefined events from event logs on thousands of servers. MOM also runs health-monitoring scripts on many servers. In response to the most important events, MOM creates alerts that are routed to central consoles. In addition, MOM collects performance data from all managed servers and raises alerts for performance threshold exceptions. Live Communications Server 2005 includes a MOM management pack that allows the service to be centrally monitored in a similar manner through the MOM application. MOM provides useful operations manageability information. For example, it provides alerts when a server goes offline and can show the number of users logged on to the Live Communications Server service at a given time. Note: To obtain the MOM management pack for Live Communications Server, an organization must license both MOM and Live Communications Server. The management pack is then available from the download area of the MOM Web site. Most of the time, MOM catches potential problems and sends alerts to the server support team; the server support team escalates issues to Communications Operations when the Tier 1 and Tier 2 support documentation doesn’t list a resolution for a particular issue. Public views provide a graphical representation of the health of home servers, which affects how the service functions. The MOM management pack for Live Communications Server contains three public views:
Communications Operations also works with teams that support and manage elements of the Microsoft environment that are not usually directly related to Live Communications Server, but that can be in certain situations. For example, when the network group receives a MOM alert for a major network outage between two data centers, it notifies Communications Operations about that alert because the Live Communications Server service may be affected. Similarly, if the infrastructure support team encounters an issue in which replication of information in Active Directory is taking longer than the SLA requires, it sends that alert to the Communications Operations team. Even though the Active Directory issue may not affect Live Communications Server service immediately, this kind of communication can prepare Communications Operations for service requests that may appear in the near future, when people who were enabled for the service are unable to log on. Proactive communication throughout an organization helps maintain the services that employees use regularly. The MOM management pack for Live Communications Server does not provide server statistics such as the number of text messages, audio messages, video messages, or short- and long-distance communications at a given time. As part of Microsoft IT 's role of testing and troubleshooting Microsoft products, Microsoft IT uses alternative methods such as Windows Performance Monitor and the Live Communications Server archive logs to collect and analyze performance and operation data from services that are being tested. Product development groups, such as the one for Live Communications Server, use this data to improve their products. Backup, Restore and Recovery Performing regular backups is an important part of Live Communications Server daily operations and is the first step in the preparation for a disaster recovery scenario. An organization must also plan for, and practice, restoring and recovering those backups. The following sections represent the backup, restore, and recovery procedures in place for the components of the Live Communications Server 2005 architecture at Microsoft. Live Communications Server 2005 Access Proxy Servers Access proxy servers do not maintain any application state or user data. Backup procedures are limited to backing up the machine system state. Outside access from the Internet to the internal IM environment is not considered a mission-critical service. In a worst case scenario, recovering an access proxy server involves Microsoft IT re-imaging a replacement Windows Server 2003 server, re-installing Live Communications Server 2005 using the access proxy server setup option, and then restoring the machine system state. This approach assumes that the replacement server has the same server machine name as the previous server. Live Communications Server 2005 Director Servers Director servers maintain a database of user information to enable user authentication of new user sessions. No additional application or session data is maintained on the server. During a recovery scenario, the director server automatically rebuilds this database when it is installed and configured into the existing environment. Microsoft IT only backs up the machine system state on its director servers. Live Communications Server 2005 Enterprise Edition Server Pools and Database Servers All Live Communications Server 2005 application state and user information is maintained by the clustered SQL Server database servers, and the SQL Server database file resides in the dedicated partition on the server pool SAN. Microsoft IT uses SQL Server 2000 to schedule a snapshot daily backup of the individual Live Communications Server 2005 databases. The backup files are written to another partition on the server pool SAN where they are subsequently backed up from disk to tape by the standard Microsoft IT backup service. A front-end server running Live Communications Server 2005 Enterprise Edition in the central forest pool can be recovered by simply replacing it with a newly installed front-end server and configuring it into the hardware load balancer and the central forest server pool. As mentioned earlier, Microsoft IT included an additional front-end server in the central forest server pool (beyond what was indicated from a capacity planning perspective) to provide additional capacity for planned and unplanned outages (including rolling upgrades of the individual front-end servers). In addition, a custom script is scheduled to run each morning and each evening that uses the Live Communications Server 2005 DBImpExp utility to back up each user's contact list to an XML file. This enables a single user's contact list to be quickly restored without having to do a full database restore from tape. Live Communications Server 2005 Archiving Agent and Database Servers The role of the archiving agent and database servers is primarily for metrics gathering and are not considered mission-critical by Microsoft IT Communications Operations. Except for the machine system state, no other data is backed up on the archiving servers. Upgrading to Live Communications Server 2005 with Service Pack 1Microsoft IT upgraded several software components of its original Live Communications Server 2005 infrastructure as part of the project to upgrade the Live Communications Server servers with Live Communications Server. The new or upgraded components included:
The post-Live Communications Server 2005 SP1 updated architecture for the Redmond corporate resource forest deployment is illustrated in Figure 5.  Figure 5. Updated Live Communications Server 2005 SP1 central forest and PBX architecture Upgrading the Front-End Server Pool Although Microsoft as an organization continues to rely heavily on e-mail and Windows SharePoint Services for non-real-time communication and collaboration, the real-time presence and communications features of Live Communications Server have become a staple for most Microsoft employees. As a result, long service interruptions are not tolerated. Hence, the most important phase of the upgrade project was applying the Live Communications Server 2005 SP1 upgrade of the software on the Live Communications Server 2005 servers in such a way that minimized service disruptions to end users and external organizations. Microsoft IT started the upgrade process on a Friday evening with the goal of providing continuous service with one front-end server while the other four of the five front-end servers in the server pool were being upgraded. Following by a short interruption while the fifth server and SQL Server back-end databases were upgraded, all five front-end servers were returned to service. The goal of this approach was to have a minimal impact on Microsoft employees using the real-time communications services. Microsoft IT used the following detailed steps to apply Live Communications Server 2005 SP1 to the front-end server pool:
No hardware upgrades were required or planned. Live Communications Server 2005 SP1 was installed in-place on the existing pool of front-end server hardware used for the original deployment of Live Communications Server 2005. This was enabled in part by the increased front-end server pool performance that raised the total number of supported users from 100,000 to 125,000 per server pool (using five front-end servers). Related Live Communications Server Infrastructure Changes Second Archiving Agent Server As part of the overall upgrade project, a second archiving agent server was deployed by Microsoft IT to:
The overall mission of the archiving solution deployed by Microsoft IT remains unchanged: to capture basic session initiation and status information (and no message content) for historical service-level analysis and reporting purposes. Microsoft Operations Manager 2005 Management Pack for Live Communications Server 2005 SP1 Microsoft IT continues to use Microsoft Operations Manager 2005 (MOM) as the key server event- and service- monitoring and management tool for the updated Live Communications Server environment. Backup and Restore No changes in the Microsoft IT backup and restore processes were required as a result of the upgrade to Live Communications Server. dbexport continued to be used to back up the contact information stored in the SQL Server back-end database every 12 hours. dbimport was used as needed to restore an individual user’s contact list, or the contact lists for all of the servers on a particular front-end server. Remote User Access and Federation Between OrganizationsTo support the communication of presence information and instant messages between Microsoft employees working inside the Microsoft firewall and employees and other contacts working outside the firewall, Microsoft originally deployed the Live Communications Server 2005 remote user and federated access architecture depicted in Figure 6. The updated version of the architecture following the Microsoft IT deployment of Live Communications Server 2005 SP1 is illustrated in Figure 7.  Figure 6. Original Live Communications Server 2005 remote user and federated access architecture This environment supported three types of external communications:
Remote User Access Remote access by Microsoft employees is enabled using direct TLS access to the Microsoft IT Live Communications Server 2005 access proxy server. The access proxy server forwards presence information and instant messages generated by Communicator and Windows Messenger to the external director server. The external director server then forwards these messages between the access proxy server and the server pool load balancer. Direct Federation With direct federation, the Live Communications Server 2005 access proxy servers from two different organizations are configured to use a trusted MTLS connection to connect their internal deployments of Live Communications Server 2005. To simplify configuration of the Live Communications Server 2005 access proxy servers in each organization, Microsoft used server certificates from a public certificate authority (CA) to configure the MTLS connections. In addition, Microsoft IT ensured that the access proxy server and external director servers were configured as follows:
Clearinghouse Federation When several organizations want to federate their Live Communications Server 2005 environments, the pair-wise configuration of each MTLS connection between the access proxy servers in each organization can be tedious to set up and manage. Clearinghouse federation is an alternative strategy for Live Communications Server 2005 deployment that simplifies the configuration and maintenance tasks when several organizations want to exchange real-time presence information and instant messages. A Live Communications Server 2005 clearinghouse is an external Live Communications Server 2005 deployment that is directly connected to the Internet. A clearinghouse consisting of one Live Communications Server 2005 Standard Edition server, one access proxy server, and one Microsoft Internet Security and Acceleration 2004 server was originally deployed as part of the upgrade from the 2003 to the 2005 release of Live Communications Server. As part of the upgrade to Live Communications Server, the clearinghouse was decommissioned in favor of supporting the more easily managed enhanced federation capabilities supported in the new server pack. For more details, see the next section Updated Remote Access and Federated Access Architecture. Controlling Federated Access Control over whether a particular organization is allowed to access a Microsoft IT Live Communications Server 2005 access proxy server is established when the federated connection is created by Microsoft IT. After an external organization is configured for direct federation with the Microsoft IT Live Communications Server 2005 access proxy server, each user in the organization's namespace that is enabled for federated access is allowed to add Microsoft employees to their contact lists, exchange presence information, and send instant messages to each other. External contacts must know the SIP address of the Microsoft employee they want to contact; they are not permitted to search the internal directory of Microsoft employees. It is also possible to configure a Live Communications Server 2005 access proxy server to block specific namespaces (Internet domains) from connecting through their local access proxy server. Updated Remote Access and Federated Access ArchitectureAs part of the Microsoft IT architecture strategy for providing external e-mail and Web server access, employee remote access to internal resources is separated from business partner and Internet access to public resources such as the Microsoft public Web site. To support Live Communications Server remote access and federation, a similar approach was used as part of the upgrade to Live Communications Server: one access proxy server for remote employee access and a second access proxy server to support federation with external organizations and third-party conference-calling services providers, as well as public IM connectivity (PIC) with external instant messaging Internet service providers such as MSN, AOL and Yahoo!. The new upgraded Live Communications Server remote and federated access architecture appears in Figure 7. To support the new Enhanced Federation capabilities in Live Communications Server, an organization needs to publish a DNS SRV record for enhanced federation that has the following format: _sipfederationtls._tcp.contoso.com This SRV record is defined so that it will resolve to the external fully-qualified domain name (FQDN) and port of the access proxy server for federation purposes (or the externally facing access proxy server load balancer if multiple access proxy servers are used for federation). The way that the enhanced federation DNS SRV record is used by Live Communications Server is analogous to the way an e-mail server uses DNS MX (mail exchange) records to locate and connect to another organization’s corporate e-mail service. Enhanced federation in Live Communications Server is an improvement over the existing direct and clearinghouse federation models. It enables external organizations running Live Communications Server to federate more easily their real-time presence and instant messaging services with other organizations. The external organization can simply configure their access proxy servers to federate with your organization by enabling enhanced federation on their access proxy servers and publishing the appropriate SRV records in their DNS servers. To provide control over which external organizations can use enhanced federation to connect with your organization, Live Communications Server 2005 provides secure management of enhanced federation connections by allowing each company to specify which organizations are allowed to federate with their access proxy server infrastructure. In addition, it is also possible to specify which organizations are to be blocked from a federation perspective. Both filters are based on the federating organization's Internet domain namespaces. Figure 7. Updated Live Communications Server 2005 SP1 remote user and federated access architecture Upgrading the Access Proxy Servers The access proxy servers at Microsoft were upgraded to Live Communications Server 2005 SP1 to provide the functionality needed to support PIC and enhanced federation; and to significantly improve messaging processing performance. Providing Support for Communicator Integration with PBX and PSTN Networks While Figure 7 illustrates how the external telephony components of the Microsoft IT real-time presence and communications solution is architected, Figure 5 illustrates how employees using Communicator access the corporate telephony infrastructure over the updated Live Communications Server 2005 SP1 infrastructure using SIP and European Computer Manufacturers Association (ECMA) 323/SIP protocols. Communicator can use this infrastructure and these protocols to initiate several different types of telephone conversations:
All of these call types are initiated by Communicator using SIP session initiation messages and EMCA-323/SIP call control messages that are exchanged with the bridgehead server used to connect the Live Communications Server environment with back-end telephony/PBX infrastructure used by Microsoft employees in the Puget Sound area. Multi-party calls are hosted on the corporate PBX and support up to eight people in a single call using the remote call control (RCC) functionality of the PBX infrastructure. Conference calls that include external employees, customers, or more than eight internal employees are hosted by a third-party conference-calling services provider. In addition to basic multi-party and conference-call control features, Communicator and Live Communications Server provide for remote PC-based call control of a person’s desktop telephone including automatic notifications of incoming calls, dynamic routing of the call to another telephone or mobile phone, and forwarding to any telephone number associated with the user. Calls can be initiated by simply right-clicking on a person’s name anywhere it appears in Communicator, any of the Microsoft Office 2003 applications include Word and Outlook, or in a Windows SharePoint Services Web site. Using the PC-to-phone capability and the dial plan configured in to the PBX infrastructure at Microsoft, employees are able to call any Microsoft office number in the Puget Sound area as well as any local telephone number in the USA. Bridgehead, CTI-enabled PBX Gateway and PSTN Gateway Servers Microsoft IT needed to add updated and new server components to its real-time presence and communications solution to support the new telephony features supported by Communicator with Live Communications Server 2005 SP1. These included:
Third-party Conference-calling Services Integration with third-party conference-calling services providers is based on the same Live Communications Server 2005 infrastructure and protocols used inside Microsoft. Live Communications Server direct federation is used to set up and exchange messages with the Microsoft IT conference-calling services providers. SIP and ECMA-232/SIP are used to set up and tear down conference-call sessions – the same protocols used for exchanging presence, starting instant messaging sessions, and PBX-based single-party and multi-party calls inside Microsoft. Deploying Microsoft Office Live Communications Server 2005 Address Book Service To support rapid local searching of instant messaging contacts and caller ID-based lookups, the Communicator includes a server-side component called the Live Communications Server address book service. The service is installed on one of the servers updated to use Live Communications Server. At Microsoft, the Live Communications Server address book service is installed on one of the internal director servers. The Live Communications Server address book service provides "in-band provisioning", or downloading, of contact information from the Live Communications Server environment to the local user’s computer using the HTTP protocol. All searches for contact information in Communicator ("find" operations) are executed as queries against the local downloaded copy of the Live Communications Server address book. A local copy of the Live Communications Server address book is needed to support:
Microsoft IT has scheduled a full rebuild of the Live Communications Server address book once a week as well as daily incremental builds. Deploying Public IM Connectivity Public IM Connectivity (PIC) is key feature of Live Communications Server 2005 SP1. When used with Communicator, it enables support for all internal and public presence and instant messaging over a single, centrally managed, server-based infrastructure. From a corporate perspective, this centralized approach will increase corporate compliance, decrease Internet security vulnerabilities (through message encryption) as well as reduce overall complexity and systems administration costs. Once deployed, PIC and federation can be independently enabled by the access proxy server in one of three ways:
At Microsoft, all employee accounts are enabled in Active Directory for both PIC and federation. Note: When Microsoft (or any Live Communications Server 2005 SP1 customer) deploys PIC, the organization’s Internet domain name (for example, microsoft.com) becomes a reserved domain name on Microsoft Passport, the Internet authentication service used by the MSN instant messaging service, Hotmail, and the other MSN Internet services. If there are existing or former Microsoft employees who were using their Microsoft e-mail addresses for their personal Passport accounts, the domain of these existing accounts is automatically changed to messengeruser.com to insure that a particular organization’s Internet domain name is only used by internal Communicator and Live Communications Server 2005 SP1 users. Instant Messaging Security In addition to the server-side ability to block an external organization from federating with the Microsoft IT access proxy servers, Communicator includes a group policy-controlled registry setting for determining whether a hypertext link in an instant message is “clickable” or not. In addition, a server-side setting can be used to filter out all hypertext links from the body of an instant message. Microsoft IT takes advantage of Live Communication Server 2005 SP1 to encrypt the following types of messages.
Note: Requiring encryption on the access proxy server assures that messages from another service are encrypted, but not that those messages traveling within the other service are encrypted. ConclusionThe Microsoft IT deployment of a protected, real-time, person-to-person communications solution based on Live Communications Server 2005, Windows Server 2003, Active Directory, and Microsoft Identity Integration Server has provided Microsoft employees, Microsoft IT, and the Live Communications Server 2005 product group with specific benefits listed in the next section. Benefits The deployment of Live Communications Server 2005 Enterprise Edition at Microsoft resulted in the following benefits. Increased service levels by deploying a more available, more scalable, and higher-performance real-time communications solution The most significant change between Live Communications Server 2003 and Live Communications Server 2005 is the Enterprise Edition support for higher-availability and large-scale deployments. This comes from an architecture based on a two-tier, load-balanced pool of front-end servers and a clustered SQL Server back-end database server. With moderate increases in hardware and installation costs, Microsoft IT was able to provide Microsoft employees with increased service availability at equal or reduced management and operations costs. Microsoft IT now has a real-time presence and instant messaging solution that can scale up on the fly, and that allows for removal of a single server machine for applying updates, service packs, or product upgrades – with minimal interruption of service. Further, there is a single point of control for managing all Live Communications Server 2005 users and servers. Lastly, with the centralized, clustered database server solution, there is one set of storage volumes that need to be backed up on a nightly basis (instead of the individual instances of Microsoft SQL Server 2000 Data Engine (MSDE) that previously ran on each Live Communications Server 2003 home server in the Redmond data center). Internal and remote access that is more secure and easier to set up, manage, and track Remote User Access from the Internet with No VPN Connections Many Microsoft employees are mobile users traveling from building to building for meetings or working from remote locations and home offices. Access to real-time presence information without a VPN connection makes service seamless whether a user is connected to the Internet or the Microsoft corporate network by wire or by wireless. Encrypted Communications The ability to encrypt content within an enterprise is an important security consideration. When using Exchange 2000 Server instant messaging services and the public instant messaging networks, all communications are transmitted in clear text. Clear text communications through a firewall to public IM clients can provide an entry point for viruses and other attacks, and make it possible for someone to eavesdrop on an instant messaging conversation. Live Communications Server 2005 includes enhanced security features, such as encryption across network hops using the Transport Layer Security (TLS) protocol, and full authentication using Active Directory. The ability to encrypt and decrypt traffic between the clients and servers helps prevent attempts to capture and read communications that are traversing the network. All communications between Live Communications Server 2005, Communicator and Windows Messenger (as well as all server-to-server communications) are encrypted through the enforcement of high-security mode on the client and the configuration of TLS and MTLS protocols on the server. The benefit is substantial, especially for Microsoft employees accessing the service from the Internet. Less complex (and less costly) deployment and management options for multi-forest network environments Restricting Active Directory Schema Extensions to a Single Forest Using the central forest deployment model, the Active Directory schema extensions for Live Communications Server 2005 no longer needed to be applied to every forest that needs to participate in enterprise instant messaging. Only the forest selected as the central forest needs to have its Active Directory schema extended, simplifying the initial deployment, replication, and maintenance of the schema changes. User Account Lifecycle Management With MIIS, managing contact object creation or deletion when employees are hired or leave the company is automated. This allows for more efficient use of IT resources and lower ongoing management costs. Single Namespace Across Forests With Live Communications Server 2005, an organization must deploy a live communications service in each forest that contains users who want to use the service. As long as directories between forests are synchronized, Live Communications Server uses a single namespace across forests to help provide more secure cross-forest communications. For example, at Microsoft, the SIP address of users in any forest consists of an alias combined with the "microsoft.com" namespace. A user can search by first name, last name, or account name in Communicator and Windows Messenger and easily find someone in a secondary forest. In addition, rather than putting all users in a parent domain to support users in two child domains, an organization can host all the Live Communications Server users in one of the child domains. This ability reduces the number of servers that Microsoft administrators need to manage, because they can use the infrastructure set up in one child domain to support users in the other child domain. Although the Microsoft environment consists of multiple forests and domains, Microsoft IT did not need to place servers in every forest and domain. Lessons Learned and Best Practices During the planning and deployment of Live Communications Server 2005, Microsoft IT encountered and addressed a number of new situations resulting in the following lessons learned and best practices. Use High-Security Mode Use the registry setting that enables high-security mode client connections. The high-security mode implies the following changes: enabling TLS and MTLS to encrypt information between servers and clients, requiring Kerberos and NTLM authentication, disabling Universal Plug and Play, and disabling peer-to-peer connections for all instant messages and for invitations to other features of Communicator or Windows Messenger. High-security mode provides increased levels of security in key parts of the service through a single setting. The key benefit is the end-to-end encryption of all client/server and inter-server communications including logon credentials, text of instant messages, and presence information. For other features such as audio and video conferencing and file transfer, Communicator and Windows Messenger establishes direct network connections between each user. These features use peer-to-peer protocols once the audio/video conferencing or file transfer session has been established between the users. Be Aware of Seemingly Unrelated Infrastructure Changes Overlapping with the deployment of Live Communications Server 2005, Microsoft IT was also completing or starting several projects that could potentially affect the deployment of Live Communications Server. Examples of these projects include the deployment of Windows XP Service Pack 2, network domain isolation based on IPSec, upgrading the wireless networking infrastructure, testing of new server operating system service packs, and the deployment of alternative load-balancing solutions. During the deployment of Live Communications Server 2005, the Microsoft IT Communications Operations team worked to resolve minor issues involving each of the above technologies. This was facilitated by broad, open, electronic communication across the Microsoft IT service organizations. Deployment Planning When planning a deployment of Live Communications Server, an organization should be aware that the phases of deployment, and the number and configuration of servers running Live Communications Server, depend on a number of factors such as:
Additional information on planning for the deployment of Live Communications Server 2005 can be found at http://www.microsoft.com/office/livecomm. Educate Users Answer common questions in advance through e-mail and through an internal Web site that contains a list of frequently asked questions (FAQs) and pointers to other sources of information. Centralize the Live Communications Server Architecture If you install servers allocated for Live Communications Server 2005 in a central location and if your organization has multiple forests, you can create one DNS entry and replicate that entry among all the corporate forests. A centralized model simplifies the management and maintenance of DNS records required for the service. However, if data centers are widely dispersed—for example, on different continents—you must ensure that there is sufficient bandwidth (at least 1.6 Kbps per user over an eight-hour period) in the connections between data centers to support a centralized model. A centralized model may increase the time needed for users to log on to the service. You can determine the impact by measuring the current network delay. As a basic example of how to measure the network delay, you can use the PING protocol to send 100 1-kilobyte packets between the server and a computer in the target location. For Microsoft, the delay was approximately 107 milliseconds. This small delay was not sufficient for Microsoft IT to consider a distributed server deployment strategy. Other network environments that experience significantly longer delays may choose to distribute one or more of their home servers. The updated deployment of Live Communications Server 2005 with SP1 resulted in the following lessons learned and best practices. Normalization of Telephone Number Formats in Active Directory Communicator includes strict enforcement of the E-164 international standard for encoding country or region codes, area codes, and telephone numbers. Active Directory does not enforce a particular telephone number format. This may require the telephone numbers in Active Directory, and subsequently the Live Communications Server database and the Live Communications Server address book service, be normalized to follow the E-164 standard. A critical factor for a successful telephone number normalization project is determining the authoritative source for each telephone number (office, home office, mobile, and personal). Frequently, there may be different authoritative sources for each telephone number (for example, a human resources system, Active Directory, corporate PBX databases, or other user-profile management systems). Increased Number of Contacts in the Average User’s Contact List Microsoft IT found they needed to increase the maximum number of contacts per user from 150 to 200. The major reason for the increase is that employees were now consolidating their previous MSN Messenger and Windows Messenger external contact lists into one list in Communicator. Microsoft IT recommends that large organizations use a cautious approach to increasing the maximum number of contacts, because the downloading of the initial contact information and the dynamic updating of presence information requires additional server resources and can affect performance. Value of Federation, Public IM Connectivity, and Remote Access Microsoft conducts business with a large number of external organizations. Microsoft employees have made extensive use of the initial deployment of enhanced federation, PIC, and remote connectivity to provide support that is more responsive and interactive using a single, centrally managed server-based infrastructure. This includes internal employees connecting with external businesses and customers; and remote Microsoft employees connecting and communicating with clients as well as colleagues inside the Microsoft firewall. Value of Extended Presence in Communicator At Microsoft, there is an established culture where each person relies heavily on meetings being scheduled and managed through their Outlook calendar as well as setting an out-of-office notification message when they expect to be physically or electronically unavailable. The extended presence features in Communicator have improved employees' productivity by allowing a user’s current meeting status and descriptive information as well as their out-of-office message to be available to everyone who has that user on their contact list. Making Server Availability Information Readily Available in Communicator Similar to Windows Messenger, the Communicator user interface (UI) can be extended using “tabs”. Tabs enable alternative Web-based content or applications to be hosted in the main body of the Communicator UI. Microsoft IT uses this capability to display the availability of e-mail servers, key line-of-business applications, web services, and other server applications; as well as a small (mobile) version of Microsoft Web, the primary employee portal at Microsoft. Summary The Microsoft IT deployment of Live Communications Server 2005 Enterprise Edition served a dual purpose: testing of the product in a large, real-life enterprise environment with more than 80,000 accounts; and providing Microsoft employees with real-time communication features such as presence and instant messaging. Live Communications Server 2005 Enterprise Edition is a complete enterprise solution because it offers:
Deploying Live Communications Server 2005 can decrease costs in an organization by helping users communicate more efficiently and more securely—thereby increasing worker productivity—while minimizing the complexity of managing an instant messaging service. Live Communications Server 2005 also provides long-term value as a platform for applications and solutions (such as custom real-time communications, Voice over IP (VoIP) telephony applications and the Microsoft Office System) that use SIP to extend communications beyond instant messaging. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
