Microsoft Office Communicator Web Access Planning and ...
Microsoft Office Communicator Web Access Planning and Deployment Guide
Published: April 2006
[pic]
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2006 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Internet Explorer, Windows, Windows NT, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
Introduction 1
Overview 1
Communicator Web Access 1
Comparing Communicator Web Access and Communicator 2005 2
Reference Architecture 5
Other Components in a Communicator Web Access Deployment 6
Planning 7
Active Directory Considerations 8
Supported Topologies 8
Reference Topology 8
Colocation with Live Communications Server 9
Multiple-Domain Topologies 9
Multiple Forest Topologies 9
Internal and External Web Access on a Single Server 10
Branch Office Topologies 11
Federation 11
Communicator Web Access Requirements 11
Supported Server Operating Systems 13
Supported Client Operating Systems 13
Supported Client Browsers 14
Client Interoperability 14
Server Requirements 15
Server Hardware Requirements 16
Additional Infrastructure Information 16
Planning Certificates 17
Planning for Communicator Web Access Certificates 17
Planning for Live Communications Server Certificates 19
Planning Certificates for Hardware Load Balancing 19
Planning for ISA Server 2004 Certificates 19
Authentication and Authorization 19
Pop-up Blockers 20
Cookies 21
Capacity Planning 21
Increasing Capacity 21
Performance Considerations 22
Availability Planning 22
Planning for High Availability 23
Load Balancing 24
Disaster Recovery Planning 30
Standby Recovery Server 30
Transitioning Service from a Failed Server to a Standby Server 31
Deployment 31
Communicator Web Access Setup Overview 31
Preparation 32
Preparing the Server for Installation 32
Preparing Certificates for Communicator Web Access 33
Installing Communicator Web Access 35
Installing Communicator Web Access by Using the Deployment Tools 35
Creating Additional Virtual Servers 40
Enabling the AJAX Service for Communicator Web Access 42
Installing Communicator Web Access by Using the Command Line 43
Preparing Clients and Signing in to Communicator Web Access 43
Signing in to Communicator Web Access 44
Java Script Signing for Mozilla and Firefox Browsers 46
Configuring Search 48
Search Results 49
Manually Configuring Attribute Replication to the Global Catalog Server 50
Configuring ISA Server 2004 51
Prerequisites 52
Install ISA Server 2004 54
Configure Certificates on the ISA Server Firewall 54
Create the External Communicator Web Access Virtual Server 55
Configure the ISA Server 55
Management and Operations 60
Managing the Communicator Web Access Server 60
Managing Virtual Servers 62
Monitoring 66
Removing Communicator Web Access 68
Appendixes 68
Appendix 1: Accounts 68
Accounts Created by Communicator Web Access Setup 69
Administrator Groups 69
Appendix 2: Enabling Activation Without Using Domain Admins Credentials 69
Appendix 3: WMI Settings 72
Appendix 4: Configuring IIS 6.0 73
Introduction
Microsoft® Office Communicator Web Access is a browser-based client for Microsoft Office Live Communications Server 2005 with SP1. Live Communications Server provides a stable, extensible, enterprise-ready instant messaging (IM) and presence awareness platform that is based on the SIP (Session Initiation Protocol) and SIMPLE (SIP IM and Presence Leveraging Extensions) standards. This guide helps you plan and deploy Communicator Web Access for your organization. The guide covers the following topics:
▪ Evaluating your environment for the deployment and use of Communicator Web Access.
▪ Network infrastructure, hardware, and administrative considerations.
▪ Considerations for designing a highly reliable and consistently available Communicator Web Access instant messaging system, including performance tuning, security considerations, and capacity.
▪ Steps for installing Communicator Web Access server, configuring the server, and preparing clients.
▪ Management and operations options, including monitoring.
This guide assumes that you have already installed Live Communications Server 2005 SP1. For detailed information, see the technical documentation for Live Communications Server 2005, available at .
Overview
Presence awareness is the ability to detect another user’s availability on one or more devices. By using Live Communications Server 2005, enterprises comprising as many as tens of thousands of users can track and manage presence information and IM. A user’s presence is reported as a status, such as “Online,” “Away,” or “Busy.” Presence, more than any other factor, has propelled instant messaging to the level of a necessity.
Your organization can also use the federation features in Live Communications Server to extend IM and presence information to remote users and trusted customers, suppliers, and partners. By using Communicator Web Access, employees who are working offsite can collaborate in real time with their onsite colleagues without having to go through a VPN (virtual private network).
This section describes Communicator Web Access and compares the two Live Communications Server 2005 clients, Communicator Web Access and Microsoft Office Communicator 2005. It also presents a reference architecture for supporting Communicator Web Access in an existing deployment of Live Communications Server 2005 with SP1.
Communicator Web Access
Microsoft Office Communicator Web Access enables users to access the instant messaging and presence features in Live Communications Server through a Web browser, without requiring client-side software or a VPN (virtual private network) connection. Users, who may be connecting to Communicator Web Access either within the corporate network or through the Internet, simply enter a Uniform Resource Identifier (URI), for example, imserver., in a supported Web browser. For a list of supported browsers, see “Supported Client Browsers” later in this guide.
Communicator Web Access offers the following features:
▪ Web access – Users can access the IM and presence features in Live Communications Server 2005 SP1 through any supported Web browser.
▪ Instant messaging – Communicator Web Access users can initiate an IM conversation with one or more other users in the organization.
▪ Presence – Communicator Web Access users can determine the status of other SIP users and update their own presence information.
▪ Personal notes – A user can publish a personal note that is displayed along with the user’s presence information.
▪ Extensive contact management – Users can add contacts to a contact list, tag contacts to be notified when those contacts’ presence status changes, and organize listed contacts into groups.
▪ Federation – When federation is enabled in Microsoft Office Live Communications Server 2005 with SP1, Communicator Web Access users can view the presence of users in external organizations and send instant messages to those users.
▪ Multiple browser and operating system support – Users with Windows-based and non-Windows-based browsers and operating systems can use Communicator Web Access. For details about supported operating systems, see “Supported Client Operating Systems” and “Supported Client Browsers” later in this guide.
▪ Zero installation – Users connect to Communicator Web Access through a supported browser. Communicator Web Access does not require the installation of any ActiveX controls.
▪ Digital certificate security (MTLS/SSL) – HTTP traffic and traffic between the Communicator Web Access server and the Live Communications Server can be secured with SSL.
▪ User search – The Communicator Web Access server connects to the Microsoft Active Directory® directory service. By using the Find feature of Communicator Web Access, users can search for other users who are enabled for SIP communications. The Find feature queries the user’s local contacts and Active Directory. Unlike Communicator, however, Communicator Web Access does not query the Live Communications Server Address Book.
Communicator Web Access is a client for Live Communications Server 2005 with SP1. Communicator Web Access provides access to Live Communications Server instant messaging and presence features through a Web browser; beyond a supported Web browser, no additional installation is required on the client. Communicator 2005, another client for Live Communications Server, is a client-side application that provides access to Live Communications Server collaboration features, including instant messaging, video conferencing, telephony, application sharing, and file transfer.
Comparing Communicator Web Access and Communicator 2005
Communicator Web Access provides browser-based access to the instant messaging and presence features of Live Communications Server. Communicator Web Access shares some of ’the essential features and configuration settings of Communicator 2005. Table 1 compares the features available in each client.
Table 1. Feature Comparison Between Communicator 2005 and Communicator Web Access
|Feature |Communicator |Communicator Web |
| | |Access |
|Instant Messaging with one or more contacts |( |( |
|Application sharing |( | |
|Whiteboard sessions |( | |
|File or photo transfer |( | |
|Audio communication |( | |
|Video communication |( | |
|Communication with MSN®, AOL® and Yahoo! ® users, if supported by |( |( |
|your organization’s Live Communications Server deployment (separate | | |
|license required) | | |
|Communication with organizations that are federated through Live |( |(1 |
|Communications Server | | |
|Free and busy calendar information in status |( |( |
|Incoming IM pop-up notification ("Toast") |( |( |
|Personal note |( |(2 |
|Automatic "Away" status after a period of inactivity |( |(3 |
|Access for users outside of the corporate network without connecting |(4 |( |
|through a VPN | | |
|Zero client installation | |( |
|Support for other operations systems and browsers | |( |
1 Information from a user’s Outlook calendar is available in Communicator Web Access only if the user signs in to Communicator 2005 before Communicator Web Access, and then runs both Communicator Web Access and Communicator 2005 simultaneously.
2 As long as the user runs both Communicator and Communicator Web Access simultaneously, if the user’s Out of Office Assistant is enabled and the user has not entered a personal note, the Out of Office Assistant information will display as a personal note.
3 Like other browser-based applications, Communicator Web Access cannot detect activity in other client applications. Therefore, if the user is inactive in Communicator Web Access, the user may still be using other applications, but Communicator Web Access cannot detect this activity and changes the user’s status to "Away" after a user-configurable period of time, by default 15 minutes. ’
4 Remote Communicator users can connect directly to their Live Communications Server domain through an Access Proxy if the domain has been enabled for remote user access.
The main page in both clients is similar, with the user’s status at the top, a search frame, and a contact list. Additional contact information is available in the pane at the bottom of the page. The Communicator Web Access and Communicator main pages are shown in Figure 1.
Figure 1. Communicator Web Access and Communicator Main Pages
|Communicator Web Access |Communicator |
|[pic] |[pic] |
There are also similarities in the Conversation windows. The Communicator Web Access (left) and Communicator Conversation windows are shown in Figure 2.
Figure 2. Communicator Web Access and Communicator Conversation Windows
|Communicator Web Access |Communicator |
|[pic] |[pic] |
Reference Architecture
Communicator Web Access is an extension of your existing Live Communications Server 2005 SP1 deployment. Generally, you install Communicator Web Access server software on servers inside your corporate network and configure them so that both internal users and remote users have access. The Communicator Web Access server provides contact list and instant messaging features.
Figure 3 shows a typical Communicator Web Access architecture. In this architecture, remote users connect through the Internet by using a URI, for example . The firewall routes incoming traffic to the Communicator Web Access server or array of servers, which in turn connects to Live Communications Server to provide presence and instant messaging features.
Figure 3: Communicator Web Access Architecture
[pic]
Figure 3 shows Internal users connecting to the internal Communicator Web Access server array behind a load balancer. The pool/load balancer can be replaced with a single server for more modest deployments. Internal users are physically separated from remote users by deploying both an internal and external pool to handle internal and external requests, respectively.
Remote users access the external pool by the SSL-published Communicator Web Access external site on the reverse proxy server. Only one of the many firewall configurations that Communicator Web Access supports is shown. Communicator Web Access supports any firewall or reverse proxy configuration for creating the Perimeter Network, including ISA Server 2000, ISA Server 2004, and other firewall and reverse proxy solutions. See the following link for additional information about ISA Server.
ISA Server:
Other Components in a Communicator Web Access Deployment
In addition to Communicator Web Access, the reference architecture consists of the components described in the following sections.
Live Communications Server SP1
Live Communications Server manages client connections, presence, and other real-time communication features like instant messaging.
Active Directory
The Live Communications Server environment has a strong dependency on Active Directory. As you are aware from deploying Live Communications Server 2005, Active Directory is used for authenticating, authorizing, provisioning, and configuring Live Communications Server. In Communicator Web Access and Communicator 2005, Active Directory supplies the enterprise address list to facilitate search-based lookups.
Firewalls
Firewall software helps protect your network against Internet attackers and enables your computers to connect to the Internet. By using a firewall application such as ISA Server, you can securely publish your Communicator Web Access servers to remote users.
The firewall is the first computer Internet intruders try to attack because it is directly connected to the Internet. For this reason, the firewall computer itself should be configured as securely as possible, and perform only duties directly related to intrusion prevention and detection.
Load Balancer
A load balancer is used with Communicator Web Access /Live Communications Server to distribute user traffic in the following cases:
▪ Multiple Communicator Web Access servers
▪ Multiple Live Communications Server 2005 SP1, Enterprise Edition Servers forming a pool
▪ Multiple Live Communications Server 2005 SP1, Directors
▪ Multiple Live Communications Server 2005 SP1, Access Proxies
See the Configuring Load Balancing Topologies section for more information.
Internet Information Services 6.0
Internet Information Services (IIS) 6.0 is the Web server, available in all versions of the Microsoft Windows Server™ 2003 operating system, used to host Communicator Web Access. IIS 6.0 introduces many features that can help increase the reliability, manageability, scalability, and security of your Communicator Web Access deployment.
.NET Framework Version 2.0
Communicator Web Access was developed using the Microsoft .NET Framework Version 2, which represents a significant milestone for the Web services and XML Serialization stack in the .NET Framework.
2.0
Microsoft 2.0, part of the .NET Framework 2.0, is the newest version. Version 2.0 provides both developers and Web site administrators new and improved features. Communicator Web Access is built upon 2.0, and together with Microsoft Internet Information Services (IIS) 6.0 and the Microsoft .NET Framework 2.0, provides easier and more powerful deployment, configuration, and maintenance of Web sites and applications. The new administrative Web site included with 2.0 is a secure Web interface that enables you to easily administer and configure Communicator Web Access for scalability and performance.
Ports Used by Communicator Web Access
For purposes of configuring firewalls or troubleshooting communications issues, it may be useful to know the TCP ports that Communicator Web Access uses. The ports used are summarized below.
Incoming Ports:
▪ TCP port 80 (HTTP) or TCP port 443 (HTTPS), depending on how the virtual server (Web access server) is configured
▪ Dynamic port for incoming traffic from Live Communications Server (Communicator Web Access listens on a random port)
Outgoing Ports:
▪ TCP port 3268 (LDAP) on the global catalog server
▪ TCP port 389 (LDAP) on the domain controller
▪ TCP port 5061 (MTLS) on the server or pool running Live Communications Server
Planning
This section discusses considerations for planning your Communicator Web Access deployment. It covers the following topics:
▪ Active Directory
▪ Topologies
▪ System requirements
▪ Certificates
▪ Authentication and authorization
▪ Capacity
▪ Availability
▪ Disaster recovery
Active Directory Considerations
Communicator Web Access does not impose any additional requirements on your Active Directory design. If you have already deployed Live Communications Server, your Active Directory topology already meets the requirements of Communicator Web Access.
In an organization with multiple forests and domains, you must ensure that the Communicator Web Access server and Live Communications Server 2005 SP1 are deployed in the same Active Directory forest and domain.
For information about Active Directory planning for Live Communications Server, see the Live Communications Server 2005 Active Directory Preparation document in the Deployment Resources area at: .
Supported Topologies
This section describes various topologies supported for Communicator Web Access:
▪ Reference topology
▪ Communicator Web Access on the same server as Live Communications Server
▪ Multiple domains
▪ Multiple forests
▪ Internal and external Communicator Web Access on the same server
▪ Branch offices
▪ Federation
Reference Topology
The reference topology is shown in Figure 3 earlier in this guide.
In the reference topology, an array of Communicator Web Access servers is deployed for internal users, who connect from within the corporate network. A separate Communicator Web Access server array supports remote users, including users at a branch office and users who connect from other remote locations (for example, home or an airport kiosk). This topology provides physical separation between traffic originating from internal users and the Internet, which provides security benefits.
Access to each Communicator Web Access server is provided by a virtual server (also called a Web access server) that is configured for either internal or external access. A separate virtual server for each type of access is required because the requirements for external connections are different from those for internal connections. The following are some examples of these differences:
▪ Internal access – Internal users may be authenticated through Integrated Windows Authentication; remote users must use forms-based authentication. Internal users can take advantage of single sign-on, so they are not required to be authenticated again when they connect to Communicator Web Access after they have already been authenticated on the network.
▪ External access – Users must use forms-based authentication in order to gain access. Communicator Web Access also checks whether the user is allowed to connect to Live Communications Server from outside the corporate network, a setting that is configured for the user in Active Directory. In addition, the external Web access server enforces timeouts after a period of inactivity (for example 15 minutes) in case the user is using a public computer.
The reference topology contains two hardware load balancers to distribute load among the servers in the internal pool and the external pool. If the deployment is greater than the capacity of one Communicator Web Access server, then multiple servers and a load balancer must be deployed.
Colocation with Live Communications Server
Deployment costs can be reduced by colocating server roles. Locating Microsoft Office Communicator Web Access on the same server as Live Communications Server 2005 SP1, Standard Edition or Enterprise Edition, is supported. However, whenever possible, you should deploy each server role on a separate physical server. Active Directory contains a single entry for the physical server, even if both server roles are running on the server. Deactivating one of the server roles removes the physical server entry in Active Directory, and consequently, both server roles become unavailable. Therefore, you should deactivate one of the roles only if you intend to remove both server roles.
Multiple-Domain Topologies
Small and medium organizations typically deploy a single forest, single domain Active Directory topology. In larger organizations, a multiple domain topology is common, in which there is a single root domain and several child domains. In a multiple domain topology, it is important to deploy the Communicator Web Access server in the same domain as Live Communications Server.
Requirements and support for multiple domain topologies are dictated by Live Communications Server 2005 with SP1, and Communicator Web Access imposes no additional requirements on your Active Directory deployment. For details about deploying Active Directory for Live Communications Server, see the Live Communications Server 2005 with SP1 Active Directory Preparation guide at .
Multiple Forest Topologies
In a multiple forest topology, it is important to deploy the Communicator Web Access server in the same forest and domain as Live Communications Server. In addition, ensure that the appropriate user attributes are synchronized across domains so that authorization and search features function properly.
If you have deployed LCSSync to synchronize Live Communications Server attributes across domains, all of the attributes that are required for Communicator Web Access will be synchronized by default. If you use another method for synchronizing forests—for example, using a tool such as GALSync or deploying a resource forest and provisioning changes across forests—you must make sure that the required attributes are replicated to each forest.
The attributes that LCSSync maps to contact objects are listed in the Live Communications Server with SP1 Resource Kit. See “Deploying in a Multiple Forest Environment” in the LCSSync folder. The resource kit is available at .
Internal and External Web Access on a Single Server
To reduce deployment costs, you can host both internal and remote users on a single Communicator Web Access server. By using the application isolation feature that is provided by IIS 6.0, you can run two instances of Communicator Web Access on a single server. You can create one virtual server instance during Communicator Web Access setup, and after setup is complete you can create other virtual server instances in Communicator Web Access Manager.
[pic]
Note
Although this scenario reduces hardware costs, it is recommended only for small deployments. Deploying two separate servers for physical isolation is the most secure mechanism and is recommended when your budget permits.
In general, the same deployment guidelines that apply to other Communicator Web Access topologies also apply to the single server scenario. However, the following considerations apply specifically to using a single server for both internal and external access:
▪ Two virtual servers cannot share the same IP address and listen on the same port; therefore, you must differentiate them either by IP address or by port number. If both virtual servers use the same IP address, you will need to differentiate them by port number. Many proxy servers accept SSL traffic only on port 443; therefore, you may need to configure the external virtual server with port 443.
▪ You must configure your firewall/reverse proxy to map to the appropriate port for each virtual server.
▪ Although server isolation reduces security risk, it is still possible for the server to be compromised, which would impact both external and internal users. In contrast, using a separate external server would limit the impact of an attack on the external server to remote users only.
Figure 4 shows an example of a single Communicator Web Access server that is used for both internal and external access.
Figure 4. External and Internal Access on a Single Server
[pic]
In figure 4, the Communicator Web Access server contains an internal virtual server and an external virtual server that share the same IP address. The internal virtual server uses port 443, and the external virtual server uses port 444. The firewall/reverse proxy server is configured to redirect incoming SSL traffic bound for port 443 to port 444 on the Communicator Web Access server.
This example represents a way to configure the scenario so that neither internal users nor remote users need to specify a port when entering a URI to connect to Communicator Web Access. The internal virtual server is configured to accept internal requests over the default SSL port 443. Likewise, the firewall is configured to accept external requests over the default SSL port 443, but it then redirects the requests to the external virtual server.
If you decide to use different port numbers, users may need to specify the port number when entering the Communicator Web Access URL. For example, if you use port 444 on the internal server, users would need to specify the port number by typing .
Branch Office Topologies
Many large organizations are reducing IT expenses associated with branch offices by centralizing the technical support staff and consolidating servers in a data center. This branch office topology is practicable if there is fast, reliable network connectivity between the data center and most of the remote branch offices. With the appropriate network connectivity, users can have a direct connection to the corporate network, or they can tunnel through the Internet as remote users.
If network connectivity between the data center and a remote office is slow or unreliable, the branch office may need to deploy its own local server. For Communicator Web Access, this would mean deploying an HTTP proxy or a Communicator Web Access server in the branch office.
Regardless of the assumed quality of the network connection, the bandwidth and latency between the data center and any branch office cannot be guaranteed. Therefore, you should always design a system that can accommodate slow, unreliable network connections. One of the factors you must account for is that connections to the Communicator Web Access server from other organizations or over the Internet will probably pass through one or more HTTP proxy servers. HTTP proxies are not necessarily designed to keep HTTP connections open for long periods of time. Such connections can be considered abnormal and can be terminated at any time. For this reason, when planning your topology, take into consideration the HTTP proxies in the path between client and server.
For more information about branch office topologies in Live Communications Server deployments, see the Live Communications Server 2005 Planning Guide, which is available from the Live Communications Server Deployment Resources page at .
Federation
When federation is enabled in Microsoft Office Live Communications Server 2005 with SP1, Communicator Web Access users can view presence and send instant messages to users of MSN, AOL, Yahoo! instant messaging, in addition to other external organizations with which federation has been established. Users can readily identify the origin of a contact by the branding icon that appears next to a federated contact’s display name.
The branding icon of the federated partner must be accessed with an HTTPS connection. For federated organizations, the administrator must ensure that HTTPS is used to access branding icons instead of HTTP. Otherwise, if a Communicator Web Access user adds a federated contact to his or her contact list, a security alert will appear whenever the user signs in. The security alert will also appear whenever users search for federated contacts or start instant messaging conversations with federated contacts. If your users see this behavior, you should verify which federated organization is using HTTP for the branding icon and request that they use HTTPS instead.
For more information about federated topologies in Live Communications Server deployments, see the Live Communications Server 2005 with Service Pack 1 Access Proxy and Director guide, which is available from the Live Communications Server Deployment Resources page at .
Communicator Web Access Requirements
This section describes the hardware and software that are required to install Communicator Web Access.
Table 2: Requirements for installing Communicator Web Access
|Computer |Component |Required For |
|Active Directory Domain |Microsoft Windows® 2000 Server SP4 |Operating system |
|Controller |Windows Server 2003 | |
| |Active Directory |Directory service |
| |DNS |Name resolution |
|Live Communications |Microsoft Office Live Communications Server 2005 |Schema |
|Server |with SP1* | |
|PKI |Windows Server 2003 SP1 Enterprise certification |PKI Infrastructure |
| |authority (CA) (recommended) or a trusted | |
| |third-party certification authority | |
| |infrastructure | |
| |IIS 6.0 |Certificate services Web enrollment support only |
|Communicator Web Access |NTFS |File system |
|server | | |
| |Windows Server 2003 SP1 |Operating system |
| |.NET Framework 2.0 |Communicator Web Access/ |
| |Windows Installer 3.0 (installed as part of |Communicator Web Access / |
| |Windows Server 2003 SP1) | |
| |IIS 6.0 |Communicator Web Access |
| | 2.0 |Communicator Web Access |
| |Live Communications Server 2005 SP1, Standard |Communicator Web Access requirement |
| |Edition or Enterprise Edition | |
|Client |See Supported Client Operating Systems |Operating System |
| |See Supported Client Browsers |Browser/Client |
|Remote Computer |Communicator Web Access Manager |Remote management |
| |IIS 6.0 Manager | |
| |The remote computer and the Communicator Web | |
| |Access server should be located in the same | |
| |Active Directory domain. | |
Table 3: Permissions required for installing Communicator Web Access
|Computer |Action |Required Permissions |
|Communicator Web Access |Install Communicator Web Access |User must be a member of local Administrators |
|server | |group. |
| |Activate Communicator Web Access |User must be member of the DomainAdmins group and|
| | |the RTCDomainServerAdmins group. |
| |Create a virtual server |User must be a member of local Administrators |
| | |group. |
|Remote Computer |Install Communicator Web Access Manager on a |User must be a member of local Administrators |
| |remote computer |group of the remote computer. |
*Communicator Web Access will not connect to previous versions of Live Communications Server. Your organization may contain previous versions, but Communicator Web Access users must be homed on servers that are running Live Communications Server 2005 with SP1.
Supported Server Operating Systems
The Communicator Web Access server is supported on Windows Server 2003 Service Pack 1 only. The following Windows Server 2003 SP1 versions are supported:
▪ Standard
▪ Enterprise
▪ Datacenter
[pic]
Important
The server must be a member of the same domain as a server that is running Live Communications Server 2005 with SP1. Installing Communicator Web Access on a workgroup computer is not supported and will result in an error during setup.
Supported Communicator Web Access Manager Operating Systems
You can use the Communicator Web Access Manager snap-in to manage one or more Communicator Web Access servers from a remote computer. The following operating systems are supported for remote Communicator Web Access management:
▪ Windows XP Professional Edition
▪ Windows Server 2003, Standard Edition
▪ Windows Server 2003, Enterprise Edition
[pic]
Note
Communicator Web Access Manager is not supported on any version of Windows 2000.
[pic]
Important
Before installing the Communicator Web Access Manager snap-in on a remote computer, you must first install Internet Information Services (IIS) Manager. Only the management components are required; you do not need to install IIS on the computer. You can use Add/Remove Windows Components in Control Panel to install the Internet Information Services Snap-in (Windows XP) or Internet Information Services Manager (Windows Server 2003), or you can download Internet Information Services (IIS) 6.0 Manager for Windows XP.
Supported Client Operating Systems
Communicator Web Access is supported on the following versions of the Windows operating system:
▪ Windows 98 Second Edition
▪ Windows 2000 (All)
▪ Windows XP
▪ Windows XP SP1
▪ Windows XP SP2
[pic]
Note
If Windows 98 is the client operating system, the password hashing protocol will ignore case when authenticating Communicator Web Access passwords.
Other Devices
Communicator Web Access includes the AJAX (Asynchronous JavaScript and XML) service, which is an application programming interface (API) for creating client programs that are compatible with Communicator Web Access and Microsoft Office Communicator 2005. Because the API can be used with any program that is built by using AJAX programming techniques, the client programs are not limited to running on the Microsoft Windows® family of operating systems on a desktop or laptop computer. For example, mobile device providers can create a gateway that allows users of their devices to access presence and instant messaging features. For information about the Communicator Web Access AJAX service, see the Microsoft Office Communicator Web Access AJAX Service Software Development Kit (SDK) 1.0, available at .
To make a developer’s program available to users, you create a virtual server and enable the AJAX service on the virtual server. You then direct users of the custom program to sign in to the new virtual server. For details about creating a virtual server and enabling the AJAX service, see “Enabling the AJAX Service for Communicator Web Access” later in this guide.
Supported Client Browsers
Microsoft Office Communicator Web Access supports the following browsers:
▪ Internet Explorer 6.0
[pic]
Note
Install Internet Explorer 6.0 SP1 to avoid issues with the title display in desktop alerts, options dialog boxes, and permissions dialog boxes.
▪ Firefox 1.0
▪ Safari 1.2.4 on Mac 10.3.7
▪ Netscape Browser 7.2 or later
Client Interoperability
This section describes interoperability with various clients.
Communicator
The user can run Communicator 2005 and Communicator Web Access on the same computer. Desktop alerts for new instant messages will appear in both programs, and the user can choose which one to accept. Incoming IM alerts continue to appear on both clients, but the message automatically opens in the active client.
Both Communicator 2005 and Communicator Web Access have a mechanism that changes the user’s status after there has been a period of inactivity. In Communicator, the user’s status changes to Away. However, because Communicator Web Access is a Web application, it can detect activity only in its own windows and dialog boxes. It cannot detect whether a user is active in other programs on the same computer. Therefore, after a period of Communicator Web Access inactivity, the user’s status in Communicator Web Access as it appears to other users automatically changes to Away, but the user may still be actively using his or her computer.
For more information about Communicator 2005, see the Microsoft Office Communicator Planning and Deployment Guide, which is available from the Microsoft Office Communicator 2005 deployment resources page at .
Windows Messenger 5.1
A user can experience inconsistencies in the way presence displays when he or she has signed in to both Windows Messenger 5.1 and either Communicator Web Access or Communicator. These inconsistencies can occur when Windows Messenger 5.1 is on the same computer or on a different computer than Communicator Web Access or Communicator 2005. However, a Windows Messenger 5.1 user can participate in IM conversations with a Communicator Web Access user without these inconsistencies.
For additional information about Windows Messenger 5.1, see the Windows Messenger 5.1Planning and Deployment Guide at .
Server Requirements
This section describes the requirements for deploying the Communicator Web Access server.
Infrastructure Requirements
The following infrastructure must be in place before you deploy Communicator Web Access:
▪ Active Directory is deployed.
▪ Domain controllers are running Microsoft Windows 2000 SP4 or Windows Server 2003.
▪ Global catalog servers are running Windows 2000 SP4 or Windows Server 2003, and at least one global catalog server in the forest root domain.
▪ PKI is deployed and configured, using either PKI from Microsoft or a third-party certification authority (CA) infrastructure. Please see Live Communications Server 2005 Certificate Configuration at .
▪ DNS is deployed and configured correctly.
▪ Live Communications Server 2005 Service Pack 1 with SP1 must be deployed.
Communicator Web Access server Setup Requirements
This section describes the requirements for the computer that will be running the Communicator Web Access server. It is assumed that all infrastructure requirements described in the previous section are met.
The following are required for the computer on which Communicator Web Access server is installed:
▪ Windows Server 2003 SP1
▪ The Communicator Web Access server is a member server of the same Active Directory forest and domain as Live Communications Server 2005 with SP1.
[pic]
Note
Installing Communicator Web Access on a workgroup computer is not supported and will cause an error during setup.
▪ Live Communications Server 2005 with SP1 schema updates as specified in Live Communications Server 2005 SP1 Active Directory Preparation at .
▪ DNS.
▪ IIS 6.0.
▪ Windows Installer 3.
▪ .NET Framework Version 2.0.
▪ You must be logged on as a member of the DomainAdmins and RTCDomainServerAdmins groups to activate Communicator Web Access.
▪ The root CA chain is trusted, and a certificate from the trusted root CA is located in the local computer trusted root authorities store. For information about how the certificate should be configured, see “Planning Certificates” later in this guide.
Communicator Web Access Active Directory Account Requirements
The following table lists the minimum group membership requirements for Communicator Web Access.
Table 4: Minimum Group Membership
|Group |Minimum Requirement |
|Administrators (local) |The user installing Communicator Web Access server must be logged on as|
| |a member of the local Administrators group. |
|Domain Admins |The user activating the Communicator Web Access server must be logged |
| |on as a member of the DomainAdmins group |
|CWAService (default) |The service account under which Communicator Web Access runs is added |
| |to the RTCHSDomainServices group created by Live Communications Server |
| |2005 SP1. |
|RTCDomainServerAdmins (created by Live |The user activating the Communicator Web Access server must be logged |
|Communications Server 2005 SP1) |on as a member of the RTCDomainServerAdmins group. |
Server Hardware Requirements
This section discusses the hardware requirements for Communicator Web Access.
Communicator Web Access server Hardware Requirements
The recommended minimum hardware requirements for the Communicator Web Access server are:
▪ Dual 3.06 GHz processor, 1-MB Cache, 533 MHz FSB (front side bus)
▪ 2 GB DDR (double data rate), 266 MHz RAM
▪ 18-GB hard disk
▪ 100-megabit network adapter
Additional Infrastructure Information
This section provides links to infrastructure requirement documents. For information on Live Communications Server 2005 SP1, see the following documents available from the Live Communications Server 2005 Deployment Resources page:
Live Communications Server 2005 SP1
▪ Live Communications Server 2005 Deployment Overview guide at .
▪ Live Communications Server 2005 Standard Edition Deployment Guide at .
▪ Live Communications Server 2005 Enterprise Edition Deployment Guide at .
Active Directory
▪ Live Communications Server 2005 SP1 Active Directory Preparation at .
DNS
▪
PKI and Certificates
▪ Live Communications Server 2005 Configuring Certificates at .
Planning Certificates
Communicator Web Access requires certificates that are issued from a Windows Server 2003 SP1 Enterprise CA (recommended) or a trusted third-party certification authority. Certificates are also required for deployments of Live Communications Server 2005 SP1 that support Communicator Web Access. If a hardware load balancer is deployed in front of a Communicator Web Access array, the hardware load balancer also requires a certificate. If you choose to publish the Communicator Web Access site for remote users by using ISA Server, you will need to configure certificates for the ISA Server. The next sections describe these certificate requirements.
If you are using Windows Server 2003 PKI, see “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” at .
Planning for Communicator Web Access Certificates
Communicator Web Access uses digital certificates to authenticate servers and users. During your preparation for Communicator Web Access server setup, you must configure the computer with trusted certificates for MTLS and HTTPS (SSL):
▪ MTLS certificate – The MTLS certificate is used to authenticate connections to the Live Communications Server. The MTLS certificates that are used by Communicator Web Access and Live Communications Server must be issued by the same trusted certification authority.
[pic]
Important
The MTLS connection will succeed only if the subject name for the MTLS certificate is the FQDN (fully qualified domain name) of the Communicator Web Access server.
▪ HTTPS (SSL) certificate – The SSL certificate is used by clients that are connecting to the Communicator Web Access server. Each virtual server that is configured with HTTPS must have an SSL certificate.
These certificates must already be installed on the server before you run Communicator Web Access setup. These certificates must be issued by your CA, and the certification authority must confirm the identity of each computer or user in the authentication transaction.
The requirements for these certificates depend on whether you are running Live Communications Server Standard Edition or Enterprise Edition. In either case, the subject name for the HTTPS (SSL) certificate must match the host name clients use to connect to the Communicator Web Access server (either the host name of the server or the host name of the virtual IP address that is published on behalf of the server).
The following sections describe the certification requirements for various scenarios.
Separate Server
If you are running Communicator Web Access on separate server from Live Communications Server, certificates must be configured as follows:
▪ MTLS certificate – The subject name must be the FQDN of the Communicator Web Access server.
▪ HTTPS (SSL) certificate – The subject name must be the host name that is used by clients to access the Communicator Web Access server, which may or may not be the FQDN.
For example, if the Communicator Web Access server FQDN is LCS-01., and clients use to connect to Communicator Web Access, the MTLS certificate subject name would be LCS-01. and the HTTPS (SSL) subject name would be cwa..
Colocation with Live Communications Server, Standard Edition
The requirements when running Communicator Web Access on the same server as Live Communications Server Standard Edition are the same as in the previous scenario. Certificates must be configured as follows:
▪ MTLS certificate – The subject name must be the FQDN of the Communicator Web Access server.
▪ HTTPS (SSL) certificate – The subject name must be the host name used by clients to access the Communicator Web Access server.
For example, if the Communicator Web Access server FQDN is LCS-01., and clients use to connect to Communicator Web Access, the MTLS certificate subject name would be LCS-01., and the HTTPS (SSL) subject name would be cwa..
Live Communications Server Enterprise Edition
If you are running Communicator Web Access on one of the servers in a Live Communications Server Enterprise Edition pool, you must use the FQDN of the server pool in the MTLS certificate. Certificates must be configured as follows:
▪ MTLS certificate – The subject name must be the FQDN of the Live Communications Server pool.
▪ HTTPS (SSL) certificate – The subject name must be the host name used by clients to access the Communicator Web Access server.
For example, if the Live Communications Server pool FQDN is LCS_Pool., and clients use to connect to Communicator Web Access, the MTLS certificate subject name would be LCS-Pool. and the HTTPS (SSL) subject name would be cwa..
Using a Single Certificate
In any of the above scenarios, depending on your certification authority, you can use a separate certificate for MTLS and HTTPS (SSL) or you can use a single certificate for both. If you are using a Microsoft Certificate Authority or if your third-party certification authority supports a subject alternate name, you can use a single certificate.
In order to use a single certificate for both MTLS and HTTPS (SSL), the certificate must be configured as follows:
▪ The certificate subject name must be the FQDN of the Communicator Web Access server or the FQDN of the Live Communications Server 2005 pool.
▪ The subject alternate name must include both of the following:
▪ The Communicator Web Access server FQDN or the Live Communications Server pool FQDN
▪ The host name used by clients to access the Communicator Web Access server.
For information about setting a Subject Alternative Name, see Microsoft Office Live Communications Server 2005 Certificate Configuration at:
Both NetBIOS names and FQDNs are supported as the subject name of a certificate when you request a certificate from a Certification Authority. For more information on how to configure certificates by using the NetBIOS name, see: .
Planning for Live Communications Server Certificates
Microsoft Office Live Communications Server 2005 with SP1, which is required for Communicator Web Access, requires certificates. For more information about Live Communications Server 2005 certificates, see Live Communications Server 2005 Certificate Configuration at .
Planning Certificates for Hardware Load Balancing
For information about certificate requirements for your load balancer hardware, contact the manufacturer.
Planning for ISA Server 2004 Certificates
You can publish the Communicator Web Access server by using ISA Server 2004 to provide remote users with access to Communicator Web Access while protecting the internal network. The recommended ISA configuration has at least two network adapters, one at the internal edge and one at the external edge. An SSL certificate must be requested, and the CA certificate chain must be downloaded to the Trusted Root Certification Authorities, Certificates folder for the local computer. The SSL certificate will be bound to the Listener for the external edge network adapter on the ISA Server 2004 computer. For details about certificate requirements and procedures, see “Digital Certificates for ISA Server 2004” at .
[pic]
Note
ISA is not required. You can use any reverse proxy.
Authentication and Authorization
The Communicator Web Access server performs both authentication and authorization on clients that access the Communicator Web Access server. The use of an MTLS certificate ensures that the Communicator Web Access server is trusted by the Live Communications Server.
Communicator Web Access confirms that the SIP URI of the client matches the credentials for that user, and ensures that the user has been authorized to use Live Communications Server. If the user is outside the corporate network, Communicator Web Access also confirms that the user has been granted remote access to Live Communications Server.
Communicator Web Access requires that clients be authenticated by one of the following methods:
▪ Forms-based authentication
▪ Integrated Windows (NTLM/Kerberos) Authentication
Forms-Based Authentication
Forms-based authentication can be used by internal users (for example, those who are using a non-Windows operating system) and must be used by remote users. In forms-based authentication, a sign-in page is submitted to the server with the user’s credentials. The Communicator Web Access authentication module and the use of SSL ensure that credentials are encrypted.
Integrated Windows (NTLM and/or Kerberos) Authentication
Integrated Windows authentication uses Kerberos V5 authentication and NTLM authentication and is available only to internal users. Except for remote users, NTLM is used by default, but you can configure the server to use only Kerberos.
[pic]
Note
If Internet Explorer users are challenged for their credentials when signing in to Communicator Web Access from within the internal network, you can configure Internet Explorer to bypass the proxy server for the Communicator Web Access site. If a user has already been authenticated, this configuration allows the user to sign in without being required to be authenticated again. To configure Internet Explorer to bypass the proxy server for all users, edit the Internet Explorer group policy to include a proxy server exception for the Communicator Web Access site (for example, im.).
Single Sign-on
Communicator Web Access uses single sign-on. After a user has already been authenticated through Integrated Windows Authentication, the user does not have to enter domain credentials to sign in to Communicator Web Access. For example, with single sign-on, a user can enter the following URI to access Communicator Web Access:
In this example, user@ is the user’s SIP sign-in name. If the user is already authenticated through IWA, Communicator Web Access will open immediately with no further authentication requests. For remote users, the forms-based authentication window will appear.
You can also configure the server allow a user name without the host information:
Both of these settings are configurable in the Communicator Web Access server properties on the Authentication tab.
For single sign-on to work, the following conditions must be met:
▪ The Communicator Web Access site must be recognized as an intranet site, or it must be included in the client’s list of trusted sites.
▪ The user’s browser must support Integrated Windows Authentication.
▪ The user must be logged on to the computer with his or her domain credentials.
[pic]
Note
Using these URIs to code single sign-on from other Web applications is not a supported scenario and may result in unexpected behavior.
Pop-up Blockers
The Communicator Web Access server uses pop-ups for both internal users and remote users. For example, pop-ups are used for incoming instant message desktop alerts and new conversation windows. Therefore, users must configure pop-up blockers to allow pop-ups on the Communicator Web Access site.
For client users who are using supported versions of Firefox, Mozilla, and the Netscape Browser, the number of windows open at any one time is limited to help safeguard against pop-ups. When accessing Communicator Web Access from these clients, users can reach this limit if several conversation windows or desktop alerts are open at one time. In this case, the client browser will prevent any new windows from opening, which can result in missed conversations or notifications. To prevent this issue, the user can change or remove the limit on the number of allowable open windows.
Cookies
Cookies are issued to the client by the Communicator Web Access server after successful authentication by both internal users and remote users. Therefore, clients must accept cookies from the Communicator Web Access server to function correctly.
Capacity Planning
When you use Communicator Web Access, you can add or remove servers without interrupting service. Even clients currently participating in IM sessions at the time of the change are unaffected. This enables customers to be proactive when planning for and responding to corporate restructure and growth.
You should consider a load balanced configuration so that you can add or remove servers as your needs change. The load balancer ensures that the same Communicator Web Access server is used for the entire user’s session. For details, see “Load Balancing” later in this document.
This section discusses capacity planning for both current and future needs.
Increasing Capacity
Over time, regular monitoring of system usage may reveal that your configuration of Communicator Web Access no longer meets the needs of users during periods of normal usage.
The following are some methods for increasing capacity:
▪ Increasing search thresholds – Communicator Web Access contains a threshold setting that determines the number of searches that are allowed at one time. This setting is configurable in the global settings for Communicator Web Access. You can use Microsoft Operations Manager to monitor how often users are reaching this limit over time. If users continually reach the limit and the search activity represents normal usage, you may want to increase the search limit. However, you need to consider any impact that increasing the limit will have on performance.
For more information about using Microsoft Operations Manager, see “Microsoft Operations Management Pack” later in this document.
▪ Optimizing IIS 6.0 scalability – IIS 6.0, running on the Microsoft Windows Server™ 2003 operating system, includes a new architecture and new features to help your application server scale. For detailed information about optimizing IIS 6.0, see “Improving Scalability by Optimizing IIS 6.0 Queues,” “Improving Scalability by Optimizing IIS 6.0 Caches,” and “Additional Resources for IIS 6.0 Scalability” at .
At some point, increasing search thresholds and optimizing other performance settings may actually result in degraded performance, and you will need to consider adding servers to the Enterprise pool or upgrading the processing power or memory of existing servers.
▪ Adding servers to the Communicator Web Access array – If your Communicator Web Access servers are configured in an array, as your organization grows, you can add Communicator Web Access servers to the array without interrupting service. Clients who are currently participating in IM sessions at the time of the change are unaffected.
▪ Adding storage capacity – Data storage for Communicator Web Access is handled by Live Communications Server. Static data, such as contact lists and ACLs (access control lists), are stored as persistent data on the Live Communications Server Back-End Database. To increase the back-end storage capacity, follow the guidelines and procedures for Live Communications Server. For more information, see the Live Communications Server 2005 Enterprise Edition Deployment Guide, which is available from the Live Communications Server Deployment Resources page at .
Performance Considerations
This section discusses ways in which you can improve the performance and reliability of a Communicator Web Access deployment.
Network Performance Considerations
Communicator Web Access performance is only as good as network performance, which depends on the following factors:
▪ Device speed: How fast a device can route or filter packets.
▪ Network speed: The bit rate of the network interfaces and connectivity devices or server ports.
▪ Filtering: The type of filtering being performed on packets (the inspection of packets above level 3 of the OSI model). The higher the level of filtering, the greater the likelihood of degraded performance. If needed, additional CPU resources should be added to bring the performance back to desired levels.
▪ Encryption: When encryption is used—for example, on VPN devices—the network traffic performance deteriorates. If this overhead proves to be too great and the network performance falls below an acceptable level, additional CPU resources should be added to the devices performing encryption to help bring performance back to desired levels.
▪ Number of devices: The latency introduced into the overall performance of the network increases as the number of devices on the network increases.
Examine your current network and determine if there are areas that may affect the performance of your Communicator Web Access deployment.
Availability Planning
Configuring your servers for availability and reliability is a process, which should be continuing, evolving, and balanced between need and cost. This section discusses the concepts and technologies that help you design an available and reliable Communicator Web Access deployment, including failover mechanisms and load balancing. To plan a highly available network, you must consider more than just Communicator Web Access. However, only Communicator Web Access-specific considerations are discussed in this document. For example, this document does not discuss failure of the supporting components (such as DNS, Active Directory, NTLM/Kerberos, Reverse Proxies, Load Balancers, Firewall, Live Communications Server, and CLR), upon which Communicator Web Access server relies. Total failure or lack of connectivity to any of these supporting components can result in degraded performance or loss of service.
For information about availability planning in general, see “Overview of Planning for High Availability and Scalability” at .
Planning for High Availability
Communicator Web Access has a failover mechanism to help provide reliability and high availability. However, it is recommended that you additionally use people and processes and that you continually evaluate and adjust your availability plan. High availability typically requires a data center with uninterrupted power and continuous maintenance and operations, as well as a trained, experienced staff.
This section describes some of the failover mechanisms in Communicator Web Access and other measures you can take to increase reliability and availability. It covers the following topics:
▪ Communicator Web Access failover mechanism
▪ Connection retry mechanism
▪ Detecting faults
▪ Containing failure
▪ Controlling overload
▪ Ensuring stable initialization
▪ Handling exceptions
Communicator Web Access Failover Mechanism
Microsoft Office Communicator Web Access provides failover support. You can choose from a number of options for achieving reliability and availability, depending on your needs and your budget.
You can improve availability by increasing MTBF (mean time between failures) and by decreasing MTTR (mean time to recover). You can increase MTBF for hardware by using any or all of the following:
▪ Dual power supplies
▪ Hot swap disks with RAID
▪ Heat-sink temperature sensors
▪ Fan sensors
▪ Redundant systems
You can lower MTTR by doing any or all of the following:
▪ Detecting faults as soon as possible
▪ Using standby and redundant systems
▪ Using server pools and load balancing
Connection Retry Mechanism
The Communicator Web Access failover mechanism contains the Client Retry recovery mechanisms. Repeated failures to connect to any one Communicator Web Access server result in the connection being attempted with the generic DNS name for the VIP (virtual IP) address of the load balancer so that the client can be connected with any available server in the array.
If a brief network interruption occurs, the client will attempt to reconnect to the same server. If reconnection fails within two minutes, the user will be signed out. The user can then attempt to sign in again, and any available server will be used for the new session.
The new Communicator Web Access server in the recovery process performs SIP optimizations to ensure that the failure does not replicate and cause an overloaded condition on any component in the Live Communications Server system. The recovered connection causes no user state change, except for loss of only the data that is between endpoints at the time of failure.
Detecting Faults
The Communicator Web Access failover mechanism contains the following fault detection mechanisms:
▪ Client to Server
▪ Client from Server
▪ Live Communications Server from Server
▪ Active Directory from Server
Containing Failure
In the event of a failure, it is important to be able to isolate the failure and to prevent it from becoming the proximate cause of other failures. For example, isolating servers for internal users from those for remote users can contain a failure to just one group of users.
This server isolation capability ensures that in the event of a system overload, performance may be degraded, but the entire system will not fail.
Controlling Overload
The Communicator Web Access server uses throttling to help prevent a total system failure and a cascade of subsequent failures that are caused by the initial failure. To prevent a system overload, throttling mechanism denies and/or delays sign-in attempts.
The Communicator Web Access overload mechanism has damping built into it to prevent a normal, momentary spike in traffic from producing an overload. Similarly, if the server is already overloaded, Communicator Web Access continues to treat the server as overloaded for a brief period in order to allow the server to return to stability. This delay help prevents the server from immediately returning to the overloaded condition.
Client requests to sign in during an overload are returned with a message indicating that the server is temporarily unavailable. This prevents the client from overloading the server by immediately trying again to sign in. Client requests to log in during an overload in which no bandwidth is available are dropped, and the client times out.
Ensuring Stable Initialization
During failover, Communicator Web Access causes the server to perform a cold restart. This restart, which is independent of the order in which other components start, results in a stable, predictable initialization of the Communicator Web Access server or array that is providing service.
Stable initialization provides Communicator Web Access server arrays to tolerate Live Communications Server switchovers and individual Communicator Web Access servers being taken offline for any reason, including a power failure.
Handling Exceptions
Exceptions occur when the server or array has a failover, recovery, initialization, or boot process in progress. Exceptions are handled in the same way as overloads: client sign-in attempts are denied, delayed, or dropped until the system is stable again.
Load Balancing
This section describes planning for distributing the load among multiple Communicator Web Access servers that use a hardware load balancer. Load balancing is a type of redundancy that can help improve the reliability and availability of Communicator Web Access. Load balancing is an element of horizontal clustering, in which multiple servers are configured to perform the same function on the network.
Load balancing can be required for the following reasons:
▪ Size of deployment: If the deployment requires more capacity than one Communicator Web Access server can provide, then multiple servers must be deployed. A load balancer ensures that the user load is distributed equally across these machines.
▪ High Availability: If Communicator Web Access is mission-critical for your organization, the loss of Communication Web Access servers due to the failure of a server can be catastrophic. As part of the design and implementation of your Communicator Web Access deployment, a load balancer can help provide high availability and protect against overloads that can result in server failures.
A load balancer can be used for both internal and external access, potentially with a dedicated load balancer for each type of access. Alternatively, you can use a single load balancer for both Live Communications Server connectivity and Communicator Web Access. This approach will probably affect the scalability of the load balancer, and having both sets of traffic traverse one load balancer does not guarantee that each server deployment will have the same capacity;. However, both sets of traffic can flow through the same Load Balancer without any functional impact.
Like typical Web applications, Communicator Web Access requires affinity. Communicator Web Access supports any load balancer that provides HTTP or HTTPS client affinity. Communicator Web Access does not support network load balancing topologies, because these topologies do not maintain client affinity. If you configure network load balancing on your Communicator Web Access servers, whenever a server fails or restarts, client connections are rebalanced across the Communicator Web Access server pool and users are disconnected.
The following figure shows the reference Load Balancing architecture.
Figure 5: Load Balancing Topology
[pic]
HTTPS and HTTP traffic between client and Communicator Web Access server is routed through the load balancer, as is SIP traffic between the Live Communications Server and the Communicator Web Access server. Management traffic between the Communicator Web Access server and the administrator, which is not shown in the preceding figure, does not go through the load balancer. Neither does DNS traffic or LDAP traffic.
[pic]
Note
You can deploy Communicator Web Access on either side of your hardware load balancer. Connections between Communicator Web Access and Live Communications Server consist of client SIP traffic only.
Configuring Load Balancing Topologies
Load balancing topologies can be described by three network attributes:
▪ Network address translation (NAT) type used
▪ Number of nodes used
▪ Number of subnets used
Load balancing uses NAT at layers 2 and 3 of the TCP/IP stack. There are three types of NAT:
▪ Destination NAT (half-NAT)
▪ Source NAT (full-NAT)
▪ Direct Server Return (out-of-path mode)
Load balancers can be connected to the network as an independent node (one-arm topology) or as an intermediary device (two-arm topology) between the Communicator Web Access servers and the remaining network.
Load Balancer topologies can be further classified by the number of subnetted network IDs (subnets) used. A subnet is a range of IP addresses that by convention is described by the lowest IP address in the range and by the subnet mask.
A complete discussion of NAT and subnetting is beyond the scope of this document. For more information, see the following:
▪ The NAT Technical Reference at
▪ The TCP/IP Technical Reference at
Supported Load Balancing Configurations
This section describes the supported load balancing configurations for internal and external client access. All supported load balancing configurations meet the requirement of maintaining state for a user’s session. The load balancer accomplishes this by using cookie inspection, IP address, or another mechanism, depending upon the specific load balancer. The load balancer ensures that the same Communicator Web Access server is used for the entire user’s session.
[pic]
Note
Multihomed network adapters or multiple network adapters, each with a different IP address, are not supported for load balancing in Communicator Web Access.
The following load balancing configurations are supported for Communicator Web Access:
Table 5. Supported Load Balancing Configurations
|Type of NAT |Supported Configurations |
|Destination NAT |Two arms and one IP subnet |
| |Two arms and two IP subnets |
| |One arm and two IP subnets |
|Source NAT |Two arms and one IP subnet |
| |Two arms and two IP subnets |
| |One arm and one IP subnet |
| |One arm and two IP subnets |
|Direct Server Return |One arm and one IP subnet |
| |One arm and two IP subnets |
| |Two arms and one IP subnet |
| |Two arms and two IP subnets |
Unsupported Load Balancing Configurations
The following load balancing configurations are not supported for Communicator Web Access:
▪ One arm destination NAT and one IP subnet
▪ Network load balancing
SSL Accelerators
A load balancer can be used as an SSL accelerator by configuring it to perform SSL decryption. Configuring the load balancer in this way can decrease the load on the Communicator Web Access server, thereby improving its performance.
In this scenario, the load balancer decrypts HTTPS traffic and passes it to the Communicator Web Access server as HTTP traffic. Because the information sent between the load balancer and Communicator Web Access is unencrypted, we recommend that you secure this traffic to prevent unauthorized access.
Connectivity Requirements
The following connectivity requirements must be met for successful load balancing of Communicator Web Access servers.
▪ The VIP (virtual IP) address of the load balancer must support the Address Resolution Protocol (ARP).
▪ The VIP of the load balancer must have only a single DNS registration, including an FQDN (fully qualified domain name) called the pool FQDN.
▪ The VIP address of the load balancer must have one or more client ports. The port can be TCP port 80, SSL port 443, or defined by the system administrator.
▪ The Load Balancer must support HTTP/SSL affinity.
▪ The Communicator Web Access servers must have Active Directory access.
▪ The administrative computer must be able to connect directly to each Communicator Web Access server behind the load balancer without going through the load balancer.
▪ Each Communicator Web Access server behind the Load Balancer must be able to connect with the Live Communications Server (server or pool) using mutual TLS (MTLS) on port 5061.
Load Balancer Configuration Requirements
The following load balancer configuration requirements must be met for successful load balancing of Communicator Web Access servers.
▪ The load balancer must support PING of the Communicator Web Access server through a TCP port, typically 80/443, which is opened by the Communicator Web Access server.
▪ The load balancer service check retry interval and TCP idle timeout must be configurable and set to 30 seconds and 92 seconds, respectively.
▪ The load balancer must support either IP address forwarding or source network address translation (NAT).
▪ If the load balancer supports only source NAT, and not IP address forwarding, it must support source NAT pooling if it is to support more than 65,000 concurrent connections.
Load Balancer Configuration Recommendations
The following load balancer configuration recommendations should be met for optimal Load Balancing, but they are not required.
▪ The load balancer should have a setting for maximum number of connections to each Communicator Web Access server behind the load balancer.
▪ The load balancer should be capable of a slow start, in which the load on the servers is increased gradually.
▪ The TCP idle timeout should be at least twice the maximum client polling interval.
Verifying Successful Load Balancing Configuration
The following verifications should be performed to confirm successful load balancing configuration.
[pic]
To verify LDAP/DNS traffic
To confirm correct LDAP/DNS configuration, perform the following LDAP/DNS verifications from each Communicator Web Access server behind the load balancer.
▪ Verify that a ping of the domain controller and global catalog server by IP address results in a successful reply from each.
▪ Verify that a ping -a of the domain controller and global catalog server by IP address results in a successful reply from each, with correct DNS name resolution.
▪ Verify that using Ldp.exe with both the domain controller and global catalog server results in a successful connection.
When every Communicator Web Access server passes the above verifications, perform the client HTTP/HTTPS traffic and server SIP traffic verifications.
You must first prepare an environment for the verifications.
[pic]
To prepare the verification environment
1. Set up two client computers, Client A and Client B, and enable two users, User A and User B, for the array being tested. The Communicator Web Access array being tested should consist of only two servers.
2. On each of the two Communicator Web Access servers in the pool being tested, open the Performance Monitor snap-in. Click Start, point to All Programs, point to Administrative Tools, and then click Performance.
3. In the Performance console tree, expand Performance Logs and Alerts.
4. Right-click Counter Logs, and then click New Log Settings. In the New Log Settings dialog box, under Name, type a name for the log. In the properties sheet, on the General tab, click Add Counters. In the Add Counters dialog box, under Performance Object, click CWA - 03 - User session Service. In the list of counters, click CWA - 002 - Sessions, click Add, and then click Close. Click OK.
5. Open the Internet Explorer browser on Client A and Client B, and then enter the Communicator Web Access URI for the two-server pool.
6. Sign in to Client A as User A, and then sign in to Client B as User B.
[pic]
To verify the configuration
To confirm that the Client HTTP/HTTPS and Live Communications Server SIP configuration with the Communicator Web Access server are correct, perform the following verifications.
1. If you are using a load balancing method that prevents the two clients from connecting to the same server (for example, the "round-robin" or "least connections" method), verify that the CWA – 002 Sessions performance counter for each server shows one connection each.
2. Verify that User B, signed in to Client B, can search for User A and can add User A to User B’s Contacts list.
3. Verify that User A, signed in to Client A, can search for User B and can add User B to User A’s Contacts list.
4. Verify that the following functions work as expected:
▪ IM exchange
▪ Presence change
▪ Block and unblock of each contact from each client
▪ Contact deletion on each client
5. Verify that when you unplug the network cable from the load balancer to one of the Communicator Web Access servers, the client connected to that server is signed out within a few minutes.
6. Verify that when clicking the Sign In button on the client that was signed out in the previous step, the user is successfully connected to the remaining connected Communicator Web Access server.
7. Verify that the CWA – 002 Sessions performance counter for the remaining server shows two connections.
Disaster Recovery Planning
Before you deploy Communicator Web Access in a production environment, it is important that you have well-defined and well-rehearsed disaster recovery strategies in place. These strategies will allow you to quickly recovery from any loss of messaging services to your users that is caused by a disaster.
Although backups are normally included in a disaster recovery plan to help mitigate disk crashes and site failures, user information for Communicator Web Access is stored within Active Directory and Live Communications Server, so there is no Communicator Web Access server-specific user information that needs to be backed up; however, it is a good practice to ensure that you have a backup of your server configuration and standby server hardware that you can install in case of failure.
You can back up Communicator Web Access server-specific configuration information from Communicator Web Access Manager. You can use the Import/Export feature within Communicator Web Access Manager to backup the server configuration in XML format. This XML can be used to restore a new server to the state that is represented by the XML, as described in the next section.
Standby Recovery Server
If your budget allows it, you should hold extra computers in reserve for use as a recovery server in the event of a disaster. Most enterprises are moving to a model of just-in-time inventories for their IT organizations. Enterprises contract with hardware vendors and suppliers, and the contract specifies an SLA (service level agreement) of a few hours for delivery of certain pieces of hardware in the event of a catastrophe. The advantage of this method is that multiple spare servers are not sitting in inventory unused.
The following are the requirements for a standby server:
▪ The server must contain a clean installation of Windows Server 2003 and nothing else.
▪ You must have the configuration files from each Communicator Web Access server that have been previously exported and are accessible.
Transitioning Service from a Failed Server to a Standby Server
If a Communicator Web Access server fails, you must manually transition service to the backup server.
[pic]
To transition service from a failed server to a standby server
1. Add the standby server to the domain.
2. Install IIS 6.0 on the standby server.
3. Install .NET Framework version 2.0 on the standby server.
4. Obtain the appropriate SSL and MTLS certificates for the standby server.
5. Install Communicator Web Access on the standby server.
6. Activate the server, but do not create a virtual server.
7. Use Communicator Web Access Manager to import the configuration files that were previously exported from the working Communicator Web Access virtual servers into the backup server.
8. Use Communicator Web Access Manager to configure the SSL certificate for the virtual servers.
If the failed server is part of a pool of Communicator Web Access servers behind a load balancer, you can either reuse the IP address of the failed server or configure the load balancer to point to the new IP address of the standby server.
If the failed server is not part of a pool, you should configure the DNS server to point the FQDN to the new IP address. If you do not have a DNS server, you can reuse the IP address of the failed server as that of the standby server.
Deployment
This section contains procedures for setting up Communicator Web Access, and includes the following:
▪ Overview
▪ Prepare the server
▪ Install Communicator Web Access
▪ Configuration Procedures
▪ SSL Publishing using ISA Server 2004 Procedures, as an example
▪ Server Management
▪ Monitoring and Performance
Communicator Web Access Setup Overview
Communicator Web Access can be deployed to your existing infrastructure if it meets the requirements described in “Communicator Web Access Requirements” earlier in this guide.
Deploying Communicator Web Access on a server involves preparation, installation, activation, and configuration procedures. Table 6 provides an overview of the required steps. Detailed instructions are provided following the table.
Table 6. Communicator Web Access Setup Overview
|Phase |Steps |
|Preparation |Install Windows Server 2003 and apply the latest service pack and updates. |
| |Add the server to an Active Directory domain. |
| |Install IIS 6.0. |
| |Install .NET Framework 2.0. |
| |Request and install the following certificates in the certificate store for the local |
| |computer: |
| |A computer certificate for MTLS that specifies the FQDN of the Communicator Web Access |
| |server as the common name. |
| |A Web Server certificate for HTTPS. |
| |If necessary, install the CA’s certificate chain in the Trusted Root Certification |
| |Authorities node in the certificate store for the local computer. |
|Installing Communicator Web |Log on to the server with an account that is a member of the Administrators, DomainAdmins,|
|Access |and RTCDomainServerAdmins groups. |
| |Open the Microsoft Office Communicator Web Access Deployment tool, and then perform the |
| |following steps: |
| |Install Communicator Web Access. |
| |Activate Communicator Web Access. In the wizard, select the MTLS computer certificate that|
| |you installed above. |
| |Create a Virtual Server. In the wizard, select the Web server HTTPS certificate that you |
| |installed during preparation. |
| |Create additional virtual servers, as necessary. |
|Preparing Clients and Signing |In Active Directory, configure user accounts by enabling them for Live Communications, |
|Into Communicator Web Access |entering SIP names, and enabling remote user access. |
| |Sign in to Communicator Web Access using the URI https:// |
Preparation
This section describes how to prepare the server for Communicator Web Access installation and request the required certificates.
Preparing the Server for Installation
Your environment must meet the requirements described in “Communicator Web Access Requirements” earlier in this guide. To prepare the server for Communicator Web Access server, you must perform the following steps before running the Deployment Tool.
[pic]
To prepare the server for Communicator Web Access installation
1. Install Windows Server 2003 on the Communicator Web Access server. Install Windows Server 2003 Service Pack 1 (SP1) and the latest updates.
2. Add the server to an Active Directory domain. You must add the server to the same Active Directory forest and domain as Live Communications Server 2005 with SP1.
3. Install IIS 6.0 on the Communicator Web Access server.
4. Install NET Framework 2.0 on the Communicator Web Access server.
5. Configure a static IP address (optional) and name resolution on the Communicator Web Access server.
6. Request and install the following certificates in the certificate store of the local computer:
▪ A computer certificate for MTLS that specifies the FQDN of the Communicator Web Access server as the common name.
▪ A Web Server certificate for HTTPS. Requirements for this certificate depend on whether you are running the Standard Edition or Enterprise Edition of Live Communications Server. For details, see “Planning Certificates” earlier in this document.
7. If necessary, install the certificate chain for the CA in the Trusted Root Certification Authorities node in the certificate store of the local computer.
Preparing Certificates for Communicator Web Access
The Communicator Web Access server requires a certificate for MTLS and HTTPS. These certificates must be installed on the server before you begin Communicator Web Access setup. For detailed information about the required certificate configuration, see “Planning Certificates” earlier in this document.
[pic]
Important
The MTLS connection will succeed only if the subject name for the MTLS certificate is the FQDN (fully qualified domain name) of the Communicator Web Access server.
The steps below describe how to download and trust the certificate chain from the Windows Server 2003 Enterprise Root CA and request the certificate with the FQDN of the Communicator Web Access server. You will be asked to choose this certificate during the Communicator Web Access setup process.
Downloading and Trusting the Certificate Chain from the Certification Authority
If you are using Microsoft Windows Server 2003 public key infrastructure (PKI) and have set up automatic enrollment, users who are authenticated in Active Directory can be automatically enrolled in a certificate through the use of a Group Policy. For information about PKI best practices, see “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” at .
If you are using another PKI infrastructure or you have not implemented automatic enrollment, use the following steps to download a certificate chain and to request a certificate on the computer.
We recommend that you not use the Web enrollment component for computers that are not in your protected internal network. The following procedure assumes that the server and the user can access the internal certification authority by using the physical network and Certificate Services Web enrollment.
[pic]
To download the certification authority certification path
1. Log on to the server as a member of the Administrators group.
2. Click Start, and then click Run. In the Open box, type , and then click OK. If the CA uses a port other than the default (port 80), type http://[:]/certsrv instead.
3. Under Select a task, click Download a CA certificate, certificate chain, or CRL.
4. Under Download a CA Certificate, Certificate Chain, or CRL, click Download CA certificate chain.
5. In the File Download dialog box, click Save.
6. Save the file to the hard disk on your server. This file has an extension of .p7b. If you open this .p7b file, the chain will have the following two certificates:
▪ certificate
▪ certificate
[pic]
To install the CA certification path
1. Click Start, and then click Run. In the Open box, type mmc, and then click OK.
2. On the File menu, click Add/Remove Snap-in.
3. In the Add/Remove Snap-in dialog box, click Add.
4. In the list of Available Standalone Snap-ins, select Certificates.
5. Click Add.
6. Select Computer account, and then click Next.
7. In the Select Computer dialog box, ensure Local computer (the computer this console is running on) is selected, and then click Finish.
8. Click Close, and then click OK.
9. In the left pane of the Certificates console, expand Certificates (Local Computer).
10. Expand Trusted Root Certification Authorities.
11. Right-click Certificates, point to All Tasks, and then click Import.
12. In the Import Wizard, click Next.
13. Click Browse and navigate to where you saved the certificate chain. Select the p7b file, and then click Open.
14. Click Next.
15. Leave the default value Place all certificates in the following store. Under Certificate store, ensure Trusted Root Certification Authorities appears.
16. Click Next.
17. Click Finish.
[pic]
To request the certificate
1. Open a Web browser, type the URL , and then press ENTER.
2. Click Request a Certificate.
3. Click Advanced certificate request.
4. Click Create and submit a request to this CA.
5. In Certificate Template, select Web Server.
6. In Identifying Information for Offline Template, type the FQDN of the Communicator Web Access server.
7. In Key Options, click the Store certificate in the local computer certificate store check box.
8. Click Submit.
9. In the potential scripting violation dialog box, click Yes.
[pic]
To install the certificate on the server
1. Click Install this certificate. In the Potential Scripting Violation dialog box, click Yes.
2. Click Start, and then click Run. In the Open box, type mmc, and then click OK.
3. On the File menu, click Add/Remove Snap-in.
4. In the Add/Remove Snap-in dialog box, click Add.
5. In the list of Available Standalone Snap-ins, select Certificates.
6. Click Add.
7. Select Computer account, and then click Next.
8. In the Select Computer dialog box, ensure Local computer (the computer this console is running on) is selected, and then click Finish.
9. Click Close, and then click OK.
10. In the left pane of the Certificates console, expand Certificates (Local Computer), expand Trusted Root Certification Authorities, and then click Certificates.
11. Confirm that the certificate that you requested for the Communicator Web Access server with its FQDN is listed. If not, copy it from the Personal\Certificates folder to the Trusted Root Certification Authorities\Certificates folder.
Installing Communicator Web Access
This section provides the procedures to install the Communicator Web Access server and client. To perform the procedures that are described in this section, you must be logged on as a member of the Administrators and the DomainAdmins groups.
The Communicator Web Access setup procedure consists of using the Communicator Web Access server deployment tool to perform the following steps:
1. Install Communicator Web Access. Install the files that are needed to activate and deploy Communicator Web Access.
2. Activate Communicator Web Access. Create a service account in Active Directory (named CWAService by default). You must install Communicator Web Access before you can activate the server.
3. Create a virtual server. Create the first Communicator Web Access virtual server in IIS 6.0. You can create additional virtual servers later by using Communicator Web Access Manager.
4. (Optional) Install Communicator Web Access administrative snap-in. By default, Communicator Web Access Manager is installed on the computer in the first step. You can use this option later to add Communicator Web Access Manager to other computers.
These steps are described in detail in the following sections.
Instead of using the deployment tools to install Communicator Web Access as described below, you can use the command line method and invoke logging. On the Communicator Web Access server, copy the installation files to disk. Open a command prompt to the ..\i386\MSI directory of the installation files and run either of the following commands to create a log for each step:
▪ Msiexec.exe /i CWA.msi [/lv .txt]
▪ Runts.exe /user: "Msiexec.exe /I "
[pic]
Note
If you want to install Communicator Web Access on a computer on which Communicator Web Access Manager is already installed, you must first remove Communicator Web Access Manager.
Installing Communicator Web Access by Using the Deployment Tools
To install Microsoft Office Communicator Web Access on a server, you must have deployed Live Communications Server 2005 with SP1. During installation of Communicator Web Access, you will be asked to select the Communicator Web Access IIS and MTLS certificate.
[pic]
To open the deployment tools
1. Log on to the server as a member of the Administrators and the DomainAdmins groups.
2. In the Communicator Web Access download folder, run Setup.exe to open the Deploy Microsoft Office Communicator Web Access page.
Figure 6: Deployment Tools page
[pic]
[pic]
To Install Communicator Web Access
1. On the deployment tools page, next to Step 1: Install Communicator Web Access, click Install.
2. On the Welcome page, click Next.
3. On the License Agreement page, select I accept the terms in the license agreement, and then click Next.
4. On the Customer Information page, next to User Name and Organization, type your user name and organization name, and then click Next.
5. On the Ready to install page, accept the default location or click Change to select an alternate location, and then click Next.
6. On the Ready to install page, click Install.
7. On the Setup Complete page, click Finish.
[pic]
To Activate Communicator Web Access
1. On the deployment tools page, next to Step 2: Activate Communicator Web Access, click Activate.
2. On the Welcome page, click Next.
3. On the Select domain service account page, do one of the following:
▪ Select Create an account. In the Account name box, either accept the default account name or type a new domain and account name. In the Password box, type a password for the account. In the Confirm Password box, retype the password exactly as before, and then click Next.
▪ Select Use an existing account, and then in the Account name box enter a new domain and account name. In the Password box, type a password for the account. In the Confirm Password box, retype the password exactly as before, and then click Next.
4. On the Select Server Certificate page, click Select Certificate.
Figure 7: Select Server Certificate page
[pic]
5. In the Select Certificate dialog box, under Issued to, select the certificate with the FQDN of the Communicator Web Access server, and then click OK.
[pic]
Note
Because the Live Communications Server uses this certificate to authenticate the Communicator Web Access server, the FQDN on this certificate must be the FQDN of the Communicator Web Access server.
Figure 8: Select Certificate dialog box
[pic]
6. On the Select Server Certificate page, verify that the correct certificate has been selected, and then click Next.
7. On the Ready to activate Communicator Web Access page, verify that the Use Server Certificate: Issued to: box contains the FQDN of the Communicator Web Access server. If it does, click Next.
8. On the Success page, click Finish.
[pic]
To Create the Communicator Web Access IIS Virtual Server
1. On the Deployment Tools page, next to Step 3: Create a Virtual Server, click Create.
2. On the Welcome page, click Next.
3. On the Select Virtual Server Type page, click one of the following:
▪ Internal for users within the corporate network
▪ External for users outside the corporate network
4. Click Next.
5. On the Select authentication method page, select the appropriate authentication method for the virtual server type, and then click Next:
▪ If the virtual server is an internal site, select the Forms Based Authentication check box, the Integrated (NTLM/Kerberos) Authentication check box, or both.
▪ If the virtual server is an external site, the Forms Based Authentication check box is selected by default. Integrated (NTLM/Kerberos) Authentication is not available for external sites.
6. On the Select Browser Connection Type page, select HTTPS (recommended) or HTTP. If you select HTTPS (recommended), click the Select Certificate button. On the Select Certificate page, click the certificate with the FQDN of the Communicator Web Access server, and then click OK.
Figure 9: Select HTTPS and Certificate
[pic]
7. On the Select Browser Connection Type page, if you selected HTTPS, verify that the correct certificate has been selected. Click Next.
8. On the Select IP address and port setting page, select the IP address, or leave the setting at the default setting (All Unassigned). If you want to change the listening port for this virtual server, in Port, type a port number. Click Next.
Figure 10: Select IP Address and Port Setting
[pic]
9. On the Name the Virtual Server page, enter a name to distinguish the virtual server, and then click Next.
10. On the Automatically Start Virtual Server page, if you want the virtual server to start after the wizard finishes, select Start this virtual server after the Create Virtual Server Wizard finishes. Click Next.
11. On the Review virtual server settings page, review the settings. The Certificate: Issued to setting should be the FQDN of the Communicator Web Access server. Click Next.
12. On the Success page, click Finish.
Manually Installing Communicator Web Access Manager (Optional)
Communicator Web Access Manager is automatically installed on the server when you install Communicator Web Access. If you are installing Communicator Web Access on a server, you do not need to run the optional last step, Install Communicator Web Access Administrative Snap-in.
However, you can also manually install Communicator Web Access Manager on a remote computer, from which you can manage the Communicator Web Access server. For information about installing Communicator Web Access Manager on a remote computer, see “Managing the Communicator Web Access Server” later in this document.
[pic]
Note
If you install Communicator Web Access Manager on a computer and then later want to install Communicator Web Access on the same computer, you must first remove Communicator Web Access Manager.
Creating Additional Virtual Servers
All Communicator Web Access virtual servers except the initial virtual server that was created during setup are created by using Communicator Web Access Manager.
[pic]
To create an additional virtual server
1. Start Communicator Web Access Manager: On the Start menu, click All Programs, point to Administrative Tools, and then click Communicator Web Access Manager.
2. Right-click Microsoft Office Communicator Web Access Manager, and then click Connect.
3. In the Computer Name box, type the server name, IP address, or FQDN (fully qualified domain name) of the Communicator Web Access server. Click OK.
4. Right-click the physical server node, and then click Create Web Access Server. The Create Virtual Web Access Server wizard opens.
5. On the Welcome page, click Next.
6. On the Select Virtual Server Type page, select one of the following:
▪ Internal for users within the corporate network
▪ External for users outside the corporate network
7. Click Next.
8. On the Select authentication method page, select the appropriate authentication method for the virtual server type, and click Next:
▪ If the virtual server is an internal site, select the Forms Based Authentication check box, the Integrated (NTLM/Kerberos) Authentication check box, or both.
▪ If the virtual server is an external site, the Forms Based Authentication check box is selected by default. Integrated (NTLM/Kerberos) Authentication is not available for external sites.
9. On the Select Browser Connection Type, select HTTPS (recommended) or HTTP. If you select HTTPS (recommended), click Select Certificate. On the Select Certificate page, select the certificate with the FQDN of the Communicator Web Access server, and then click OK.
10. On the Select Browser Connection Type page, if you selected HTTPS, verify that the correct certificate is selected. Click Next.
11. On the Select IP address and port setting page, select the IP address, or leave the setting at the default (All Unassigned). If you want to change the listening port for this virtual server, in Port, type the port number. Click Next.
[pic]
Important
If you assign a port number that is already being used by an existing virtual server and then you activate the new server, the existing server will be stopped automatically in order to avoid a port conflict.
12. On the Name the Virtual Server page, enter a name to identify the virtual server, and then click Next.
13. On the Automatically Start Virtual Server page, if you want the virtual server to start after the wizard finishes, select the Start this virtual server after the Create Virtual Server Wizard finishes check box. Click Next.
14. On the Review virtual server settings page, review the settings. The Certificate: Issued to setting should be the FQDN of the Communicator Web Access server. Click Next.
15. On the Success page, click Finish.
Enabling the AJAX Service for Communicator Web Access
Developers can create custom programs by using the Communicator Web Access AJAX service. For example, an organization may want to create a solution for wireless devices that allows users to manage and share presence information, manage contacts and groups, send and receive instant messages, and search for users within the organization. For information about using the Communicator Web Access AJAX service to develop custom programs, see the Communicator Web Access AJAX Service Software Development Kit (SDK) 1.0, available at .
You make the AJAX service available to programs by creating an additional virtual server and enabling the AJAX extension on the new virtual server.
[pic]
To create a virtual server and enable the AJAX Service
1. Follow the procedure in the previous section, “Creating Additional Virtual Servers,” to create a virtual server for the AJAX service.
2. After you create the new virtual server, start IIS Manager: On the Start menu, click All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
3. In the console tree, expand the server node, and then click Web Service Extensions.
4. In the details pane, click Add a new Web service extension.
5. In the New Web Service Extension dialog box, under Extension name, type a name for the Web extension.
6. Under Required files, click Add. Click Browse, and then select the following file:
:\Program Files\Microsoft Office Communicator Web Access\ajax\ajax.dll
7. Click OK.
8. Select the Set extension status to Allowed check box, and then click OK.
9. In the IIS Manager console tree, expand Web Sites, and then click the new virtual server node. On the Action menu, click Properties.
10. In the new virtual server Properties dialog box, click the ISAPI Filters tab, and then click Add.
11. In the Add/Edit Filter Properties dialog box, in Filter name, type a filter name. Click Browse, and then select the following file:
12. :\Program Files\Microsoft Office Communicator Web Access\ajax\ajax.dll
13. Click OK, and then click OK again to close the new virtual server properties.
14. In the IIS Manager console tree, expand the new virtual server node, and the click the cwa node. On the Action menu, click Properties.
15. In the cwa Properties dialog box, on the Virtual Directory tab, click Configuration. Under Wildcard Application Maps, click Insert.
16. In the Add/Edit Application Extension Mapping dialog box, click Browse, and then select the following file:
17. :\Program Files\Microsoft Office Communicator Web Access\ajax\ajax.dll
18. Click OK to close the Add/Edit Application Extension Mapping dialog box.
19. Click OK, and then click OK again to close the cwa Properties dialog box
Installing Communicator Web Access by Using the Command Line
The Communicator Web Access program files can be installed on a server by running the following Microsoft Installer files (.msi) at a command prompt:
▪ CWAmain.msi. Installs the Communicator Web Access program files on the server.
▪ CWAActivateServer.msi. Opens the Activation Wizard, which you can use to create the necessary Active Directory objects, activate the domain service account, and specify an MTLS certificate.
▪ CWACreateVirtualServer.msi. Opens the Create Virtual Server wizard, so that you can create virtual directories in IIS, specify an HTTPS certificate, and create the Communicator Web Access virtual server.
▪ InstallMMC.msi. Installs Communicator Web Access Manager. This installation is not necessary if you have already installed the Communicator Web Access program files on the server.
[pic]
Note
Communicator Web Access does not support silent installation.
[pic]
To install Communicator Web Access at a command prompt
1. Open a command prompt window: Click Start, and then click Run. In the Open box, type cmd, and then click OK.
2. At the command prompt, type the following, and then press ENTER:
\i386\MSI
3. To install the program files, at the command prompt, type the following, and then press ENTER. If you want to create a log file, include the optional /lv switch.
Msiexec.exe /i CWA.msi [/lv .txt]
Preparing Clients and Signing in to Communicator Web Access
This section provides the procedures for configuring users for Communicator Web Access in Active Directory and signing into Communicator Web Access.
[pic]
To prepare a Communicator Web Access client
1. On the client computer, install a supported operating system. Supported operating systems are listed in “Supported Client Operating Systems” earlier in this guide.
2. Install a supported browser Support browsers are listed in “Supported Client Browsers” earlier in this guide.
3. In Active Directory, configure users of the client as Live Communications Server users as described in the following procedure.
[pic]
To enable a user for Communicator Web Access
1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console tree, expand the Organization Node, and then expand Users. Right-click Users, point to New, and then click User.
3. In the First name and Last name boxes, type the user’s first name and last name. In the User logon name box, type the user’s network logon name. Click Next.
4. Select one of the password policy check boxes.
5. In the Password box, type a password. In the Confirm Password box, type the same password. Click Next, and then click Finish.
6. In the Active Directory Users and Computers console tree, under Users, right click the user’s name, and then click Properties.
7. In the Properties dialog box, click the Live Communications tab. Select the Enable Live Communications for this user check box. In the SIP URI box, type a SIP address, for example, in the form sip:@.com.
8. In Server or pool, select ..com.
9. Click Advanced Settings.
10. Select the Enable remote user access check box.
11. If federation is enabled in Live Communications Server, select the Enable public IM connectivity check box.
12. Click OK.
13. Click Apply, and then click OK.
Signing in to Communicator Web Access
This section explains how to test the ability of a client computer to connect to Communicator Web Access.
[pic]
To Connect to the Communicator Web Access Client
1. Log on to the client computer.
2. Open a supported browser. If a pop-up blocker is installed, either disable it completely or disable it only for the Communicator Web Access Web site.
3. Enter https:// in the browser address field. The URI to the Communicator Web Access server must match the common name in the HTTPS certificate. For example, if the common name of the certificate is im., the URL should be: .
4. In the Security Alert dialog box, click Yes.
5. If the client computer is configured to trust the same CA that Communicator Web Access trusts, you can install a certificate on the client so that users do not have to respond to the security alert. This procedure may not work in all situations.
[pic]
To install a certificate for Communicator Web Access on the client computer
1. In the address bar of the client browser, type , and then press ENTER.
2. Click Download a CA certificate, certificate chain, or CRL .
3. Click Download CA certificate chain.
4. In the File Download dialog box, click Open.
5. Expand all the nodes in the certmgr management console.
6. Double click the certificate that you have downloaded.
7. On the certificate, click Install Certificate.
8. Install the certificate with the default settings. When the security warning appears, click Yes.
The sign-in page for an internal user running Internet Explorer on a Windows operating system is shown in the Figure 11.
Figure 11: Integrated Windows Authentication
[pic]
The forms-based authentication sign-in page for a remote user who is running Internet Explorer on a Windows operating system is shown in Figure 12.
Figure 12: Forms-based authentication
[pic]
After the user signs in to Communicator Web Access, the main Communicator Web Access page appears.
Figure 13: Communicator Web Access Main Page
[pic]
Java Script Signing for Mozilla and Firefox Browsers
For clients that are running Mozilla and Firefox browsers, the JavaScript code for notifications (including incoming instant message desktop alerts and the flashing Communicator Web Access item in the taskbar) must be signed. By default, the JavaScript code is signed by using a Microsoft certificate. The first time that a user signs in to Communicator Web Access, a dialog box will appear asking whether the signed code should be allowed to run. The user’s selection determines how these notification features will function:
▪ If the user allows the request, Communicator Web Access notifications and task bar features will function correctly.
▪ If the user also selects the check box to remember the decision, the dialog box will not appear again; otherwise, it will appear each time the JavaScript code attempts to run.
▪ If the user denies the request, desktop alerts will open on the desktop in the background, and the taskbar item will not flash when new notifications or messages appear.
Re-sign the JavaScript Code Signing Certificate
You can re-sign the Microsoft certificate that is used to sign the JavaScript code either with a certificate that is provided by a trusted third-party certification authority (CA) or with a private certificate. If you obtain the JavaScript signing certificate from a trusted third-party CA, no additional client-side configuration is required. If you obtain the signing certificate from a private or self-hosted CA, then clients may need to be updated to trust the CA that issued the certificate.
Setup for Communicator Web Access installs a Java Archive (.jar) file in the following path, where client version is the version of the build:
\Server\cwa\client\
When you re-sign the JavaScript code, you create a new Java Archive (.jar) file that contains the script file and related signing information to replace the default Java Archive (.jar) file.
If you are using a private or self-hosted CA, the certificate should use the "Code signing" certificate template.
The following steps outline one method for re-signing the JavaScript by using JavaScript certificate signing tools provided by the Netscape Browser.
[pic]
To re-sign the JavaScript
1. Log on to the Communicator Web Access server as a member of the Administrators group.
2. Obtain the following certificate signing tools, available at :
▪ Certutil.exe – Used to manage certificates and private keys. You can use Certutil to create a certificate database, create a private key database, and add a certificate to the certificate database.
▪ Pk12util.exe – Used to import a certificate and private key pair file (also called a personal information exchange file) into the database that was created by Certutil.exe.
▪ Signtool.exe – Used to sign an HTML page with a certificate and private key in the database.
3. Create a folder (referred to in the following steps as ), which will store database files that are created by commands in subsequent steps.
4. Open a Command Prompt window: Click Start, and then click Run. In the Open box, type cmd, and then click OK.
5. Run Certutil.exe to create a certificate database. At the command prompt, type the following, and then press ENTER.
certutil.exe -N -d
6. When you are prompted for a password, type a password you want to use for the certificate database.
7. Apply for a certificate and private key pair file from a trusted third party CA or a private or self-hosted CA. For details about applying for a certificate, contact the certification authority. If the certificate that you receive is saved in the local computer’s certificate store, export the certificate and private key into a .pfx file.
8. Run Pk12util.exe to import the certificate and private key file into the database that you created. At the command prompt, type the following, and then press ENTER:
pk12util.exe -i -d
9. Obtain the CA certificate.
10. Run Certutil.exe to add the CA certificate to the database. You must specify a nickname for the CA certificate. At the command prompt, type the following, all on one line, and then press ENTER:
certutil.exe -A -n -i -t "C,C,C"
-d
11. Run Certutil.exe to list all certificates in the database. From this list, you will obtain the name of the certificate that will be used in the next step. At the command prompt, type the following, and then press ENTER:
certutil.exe -L -d
12. Run Signtool.exe to sign the JavaScript code by using the certificate. At the command prompt, type the following, ,all on one line, and then press ENTER:
Signtool -k -Z \Server\cwa\client\\SignedCode.jar -p -d \cwa\client\clientversion\SignedCode
After running this command, the new Java Archive (.jar) file that includes the script file and related signing information replaces the default Java Archive (.jar) file.
13. If you use a private or self-hosted CA, ensure that the clients’ browsers import the certificate chain so that the signed JavaScript code will be trusted. On a large scale, this process can be easier if the CA provides a Web site that allows users to sign on and request updated certificates.
For more information about JavaScript security and signing, see .
Configuring Search
Users can search for contacts by specifying one or more search criteria in the Find text box. By default, the search criteria are display name and e-mail address. The user can override the default search criteria by selecting a different preference from the list next to the Find button. Options include:
▪ Contact’s first name
▪ Contact’s last name
▪ Contact’s display name
▪ Contact’s e-mail address
▪ Contact’s last name and display name
▪ Contact’s last name and e-mail address
As a system administrator, you can specify the default criteria to be used in a search by modifying the DefaultSearchField and DefaultSearchQuery settings in Windows Management Instrumentation (WMI). You can also specify the maximum number of search results that are to be returned. Table 7 lists the search-related WMI settings that can be changed.
Table 7. WMI Search Settings
|WMI Setting Name |Type |Default |Accepted Values |
| | |Value | |
|DefaultSearchField |uint32 |12 |Values in binary (decimal), with definitions: |
| | | |0001 (1): First name |
| | | |0010 (2): Last name |
| | | |0011 (3): First name; last name |
| | | |0100 (4): Display name |
| | | |0110 (6): Last name; display name |
| | | |1000 (8): E-mail address |
| | | |1010 (10): Last name; e-mail address |
| | | |1100 (12) : Display name; e-mail address |
|DefaultSearchQuery |string |OR |AND, OR |
|SearchMaxServerResults |uint32 |200 |1 to 1000 |
|SearchMaxClientResults |uint32 |10 |1 to 300 |
|MaxQueuedSearches |uint32 |80 |1 to 500 |
The default search criteria, which you can change and the user can override, are:
▪ Contact’s first name
▪ Contact’s last name
▪ Contact’s display name
▪ Contact’s e-mail address
Search Results
In the search results, only those attributes of the returned Active Directory User objects that exist in the global catalog server are displayed to the user. An attribute exists in the global catalog server only if it is marked for replication to the global catalog server. By default, the following Active Directory attributes are marked for global catalog server replication:
▪ Name
▪ E-mail
▪ SIP URI
By default, the following attributes are not marked for global catalog server replication:
▪ Company
▪ Title
As an administrator, you can change the default replication behavior as explained in the next section.
After the search is completed and the attributes in the global catalog server are returned, Communicator Web Access searches the user’s local Contacts list for the following attributes:
▪ SIP Information:
▪ Phone 1
▪ Phone 2
▪ Phone 3
▪ Phone 4
▪ SubscribeToPresence
▪ IsSmartCamp
▪ NotificationSetting
These attributes are displayed in the search results along with the marked attributes described previously.
[pic]
Notes
Some search results on the client may not include Title and Company. even though these attributes are marked for replication to the global catalog server. This is because the client displays some search results from the local Contacts list. The local Contacts list does not include the Job Title and Company attributes, whether they are replicated to the global catalog server or not.
Users may receive different search results when performing the same search in Communicator Web Access and Communicator. Both clients query both the user’s local Contacts list and Active Directory; however, Communicator also queries the Live Communications Server Address Book, if one is configured. Communicator Web Access does not query the Address Book.
Manually Configuring Attribute Replication to the Global Catalog Server
As explained in the previous section, some user attributes in Active Directory are, by default, replicated to the global catalog server, and others, by default, are not. You can manually change the default replication behavior so that the attributes that are displayed in the search results are the ones that you want.
You can use the Active Directory Schema snap-in (Schmmgmt.msc) to manually configure an attribute for replication to the Global Catalog server. The Active Directory Schema snap-in is included in the i386 directory of Windows Server 2003 Service Pack 1 (SP1). The Windows Server 2003 Administration Tools Pack is not installed by default. You must install the Administration Tools Pack, and you must manually register the schmmgmt.dll when installation is complete.
Note: If you plan to manually configure global catalog server attribute replication on the domain controller for Communicator Web Access, you must install the version of the Adminpak.msi that is included in Windows Server 2003 SP1.
[pic]
To manually configure global catalog server attribute replication
1. On the Communicator Web Access domain controller, in the root Windows system32 directory, double-click the Windows Server 2003 SP1 Administration Tools Pack installation program (Adminpak.msi). Follow the instructions in the setup wizard to install the Windows Server 2003 Service Pack 1 Administration Tools Pack.
2. Register schmmgmt.dll: Click Start, and then click Run. In the Open box, type cmd, and then click OK.
3. At the command prompt, type regsvr32 schmmgmt.dll, and then press ENTER.
4. At the command prompt, type MMC /a, and then press ENTER.
5. In the console window, on the File menu, click Add/Remove Snap-in, and then click Add.
6. On the Add Standalone Snap-in, click Active Directory Schema, and then click Add. Click Close, and then click OK.
7. In the console tree, expand the Active Directory Schema [] node, and then click the Attributes node.
8. In the details pane, right-click the attribute whose replication behavior you want to change, and then click Properties.
9. In the Properties sheet, on the General tab, select or clear the Replicate this attribute to the Global Catalog check box, as appropriate, and then click OK. The next figure shows the default mail Properties screen.
Figure 14: Properties dialog box
[pic]
The next time that attributes are replicated to the global catalog server, the newly marked attribute using the above method, replicates to the global catalog server.
Configuring ISA Server 2004
Although any firewall or reverse proxy server can be used with Communicator Web Access, this section explains how to configure Microsoft Internet Security and Acceleration (ISA) Server 2004 for Communicator Web Access. ISA Server 2004 can be used as an alternative to, or in conjunction with, a VPN in your deployment of Live Communications Server 2005 with SP1 and Communicator Web Access. You can use ISA Server to provide perimeter network and internal network boundaries. You can also use ISA Server publish one or more Communicator Web Access servers using ISA Server 2004.
The Communicator Web Access solution described in this guide uses ISA Server 2004 Standard Edition to help securely connect remote users to the Communicator Web Access server on the internal network. The combination of Communicator Web Access and ISA Server 2004 provides connectivity to enabled users with only an Internet connection and a supported browser that is running on a supported operating system. Figure 15 shows an example showing the position of ISA Server in the deployment.
Figure 15: Publishing Communicator Web Access Using ISA 2004
[pic]
ISA server 2004 will publish the Communicator Web Access server so that remote users can access the corporate Communicator Web Access server by public address instead of internal FQDN. In the example shown in Figure 15, the user enters the URI (for example, ) in the browser. This URI resolves to the external network IP address (for example, 10.10.10.10). On the ISA server, the external network adapter is configured with the IP address (10.10.10.10), and the Web listener is configured to listen for HTTPS requests on the default port (443). ISA server receives the request and maps it to the IP address or FQDN of the Communicator Web Access external virtual server. If the Communicator Web Access external virtual server is configured to listen on a different port (for example, 444), ISA Server must also map to that port number.
[pic]
Note
When configuring ISA Server, you can choose between mapping the external IP address to the IP address of Communicator Web Access or mapping the host name (for example, im.) to the FQDN of the Communicator Web Access server (for example, imserver.). If you choose the second option, the FQDN must be able to resolve to the IP address of the Communicator Web Access server.
Prerequisites
The following are required on the ISA 2004 computer:
▪ Two network adapters on the ISA Server computer, one for the external network and one for the internal network.
▪ Windows Server 2003 SP1
▪ ISA Server 2004, Standard Edition or Enterprise Edition
We recommended that no other software be installed on the ISA Server.
You can get the free, 120 day trial, ISA Server 2004 software at
Configure Static IP Addresses for ISA Network Adapters
It is helpful to think of the ISA Server as having two interfaces, or edges. The internal network adapter connects the internal edge of the ISA Server to the internal network, and the external network adapter connects the external edge of the ISA Server to the external network. Each network adapter on the ISA Server has a static IP address. The address and subnet of each adapter depends on the network (router) to which it is connected.
[pic]
To configure the internal network adapter with a static IP address
1. Click Start, point to All Programs, point to Control Panel, and then double-click Network Connections.
2. Right-click the internal network adapter connection, and then click Properties.
3. On the Properties page, select Internet Protocol (TCP/IP), and then click Properties.
4. On the Internet Protocol (TCP/IP) Properties page, click Use the following IP address.
5. In the IP address box, enter an IP address on the internal subnet.
6. In the Subnet mask field, enter the internal subnet.
7. Click Use the following DNS server addresses.
8. In the Preferred DNS server box, enter the DNS IP address.
9. Click OK twice.
[pic]
To configure the external network adapter with a static IP address
1. Click Start, point to All Programs, point to Control Panel, and then double-click Network Connections.
2. Right-click the external network adapter connection, and then click Properties.
3. On the Properties page, select Internet Protocol (TCP/IP), and then click Properties.
4. On the Internet Protocol (TCP/IP) Properties page, click Use the following IP address.
5. In the IP address box, enter an IP address for the external network.
6. In Subnet mask, enter the external subnet.
7. Click Use the following DNS server addresses.
8. Leave the Preferred DNS server box empty.
9. Click OK twice.
[pic]
To set the interface order
1. Click Start, point to All Programs, point to Control Panel, and then double-click Network Connections.
2. In the Network Connections window, on the Advanced menu, click Advanced Settings.
3. In the Advanced Settings dialog box, click the Adapters and Bindings tab. Under Connections, select Internal.
4. Click the up arrow to move the Internal to the top of the list.
5. Click OK. Close the Network Connections window.
[pic]
To add the internal IP address of the ISA Server to the DNS Server
1. Log on to the DNS Server.
2. Click Start, point to All Programs, point to Administrative Tools, and then double-click DNS.
3. In the console tree, expand Forward Lookup Zones.
4. Right-click the DNS server node, and then click Properties.
5. On Properties, select the Named Servers tab, and then click Add.
6. In the New Resource Record dialog box, in the Server FQDN box, type the FQDN of the ISA Server.
7. In the IP address box, type the IP address of the internal network adapter of the ISA Server. Click Add, and then click OK.
8. In the console tree, expand Reverse Lookup Zones.
9. Right-click the .in-addr.arpa node, and then click Properties.
10. In the Properties dialog box, click the Named Servers tab, and then click Add.
11. In the New Resource Record dialog box, in the Server FQDN box, type the FQDN of the ISA server.
12. In the IP address box, type the IP address of the internal network adapter on the ISA Server. Click Add, and then click OK. Click Apply.
13. Click OK.
14. Close the DNS console.
Install ISA Server 2004
Install ISA Server 2004 on a server.
[pic]
To install ISA Server 2004, Standard Edition
1. On the ISA Server 2004 installation folder or CD, run Setup.exe to start the Setup Wizard.
2. Follow the Setup Wizard prompts, the ISA Server 2004 setup documentation, and accept all defaults with the exception of the following settings, which are specific to Communicator Web Access.
3. On the Internal Network page, click Add.
4. Do one of the following:
▪ On the address ranges selection page, in the From and To boxes, specify the range of addresses to include in the internal network, and then click Add.
▪ Click Select Network Adapter. On the Select Network Adapter page, select the Add address ranges based on the Windows Routing Table check box. Under Network Adapter, select the Internal check box. Click OK.
5. Click OK.
6. On the Internal Network page, click Next.
7. Click Next and complete the wizard, accepting all defaults.
For more information and resources about ISA Server visit the following Web sites:
▪ ISA Server home page:
▪ Knowledge Base articles about ISA and SSL Web publishing:
▪ Publishing guidance articles:
Configure Certificates on the ISA Server Firewall
An SSL certificate must be requested, and the CA certificate chain must be downloaded to the ISA Server Trusted Root Certification Authorities, Certificates folder for the local computer. The SSL certificate will be bound to the Listener for the external edge network adapter on the ISA Server 2004 computer. For details on certificate requirements and procedures, see “Digital Certificates for ISA Server 2004” at
Create the External Communicator Web Access Virtual Server
You must deploy A Communicator Web Access virtual server that will handle traffic from clients on external, untrusted networks. This virtual server is the site that will be published by ISA Server 2004. Remote users must enter the exact URL for the external Communicator Web Access site in order to access the Communicator Web Access sign-in page. The user then must enter domain credentials to complete the forms-based authentication process. The external Communicator Web Access virtual server uses port 444, and the internal virtual server uses port 443. These ports can be configured to meet the specific needs of your deployment.
To create the external virtual server, see “Creating Additional Virtual Servers” earlier in this guide. Specify the port number as 444.
Configure the ISA Server
To configure ISA server to help provide a secure connection, you must create a firewall policy on the ISA server. You then use SSL Web Publishing to publish the external Communicator Web Access virtual server that is available to enabled users over the Internet.
[pic]
To configure internal network properties
1. Click Start, point to Programs, point to Microsoft ISA Server, and then click ISA Server Management.
2. Expand all nodes in the console tree, and then select the Networks node.
3. In the details pane, right-click Internal, and then click Properties.
4. In the Internal Properties dialog box, click the Domains tab. Click Add. In the box, type the FQDN of the domain, and then click OK.
5. In the Internal Properties dialog box, click the Web Browser tab. Select all check boxes, click Direct Access, and then click Add.
Figure 16: Web Browser tab
[pic]
6. In the Add Server dialog box, click Domain or computer. Enter the FQDN of the Communicator Web Access server, and then click OK.
Figure 17: Add the domain
[pic]
7. In the Internal Properties dialog box, click the Web Proxy tab. Ensure that the Enable Web Proxy clients and Enable SSL check boxes are both selected and that the Enable HTTP check box is cleared. In the SSL port box, type 8444, and then click Authentication.
8. In the Authentication dialog box, select the Integrated check box, and then click OK.
9. In the Internal Properties dialog box, click the Firewall Client tab. Ensure that all check boxes are selected. In each of the ISA Server name or IP address text boxes, type the FQDN of the ISA server. Click Apply.
Figure 18: Firewall Client tab
[pic]
10. Click the Auto Discovery tab. Select the Publish automatic discovery information check box. In the box, type 80, and then click OK.
11. Click Apply to commit all changes. Do not close the console.
Now you will publish the Communicator Web Access server to the external network so that authenticated and authorized clients can connect to Communicator Web Access.
The Listener that you configure as part of the following procedure will listen for requests from the external network (Internet) on port 443. ISA will redirect the external traffic on port 443 to port 444 on the internal network. Traffic from the ISA Server to the Communicator Web Access server and from the Communicator Web Access server to ISA Server (all internal) is on port 444. Traffic for remote users that originates from the Communicator Web Access server on port 444 is redirected by ISA to port 443.
There are two discrete connections. The connection from the remote user to the ISA Server on port 443 terminates at the ISA server. If the remote user is successfully authenticated, the message in the original connection is inspected, reconstructed, and sent to the Communicator Web Access over a new connection between the ISA Server and the Communicator Web Access server. Traffic destined for the remote user from the Communicator Web Access is terminated at the ISA Server, reconstructed, and sent to the remote user over a new connection established by ISA Server.
There is no direct connection in either direction between the remote user and the Communicator Web Access server, which is published by ISA Server 2004 Standard Edition using SSL Web Publishing, exists in either direction: ISA Server acts as a proxy server.
[pic]
To configure ISA Server 2004 Standard Edition to publish Communicator Web Access
1. In the ISA Server Management console tree, click Firewall Policy.
2. On the Tasks tab, click Publish a Secure Web Server.
3. On the Welcome page of the wizard, in SSL Web publishing rule name, type a name for the rule.
4. On the Publishing Mode page, click SSL Bridging.
5. In the Select Rule Action page, click Allow, and then click Next.
6. On the Bridging Mode page, click Secure connection to client and Web server, and then click Next.
7. On the Define Website to Publish page, you can use either the FQDN or the IP address of the Communicator Web Access Server. In the Computer name or IP address box, type the FQDN of the Communicator Web Access server. Ensure that the Forward the original host header instead of the actual one (specified above) check box is cleared. Ensure that the Path box is empty, and then click Next.
[pic]
Note
If you use the FQDN to define the Communicator Web Access server, ensure that the FQDN can be resolved to the server’s IP address.
8. On the Public Name Details page, in the Accept requests for box, select This domain name (type below). In the Public Name box, type the name that remote clients will use to access the Communicator Web Access server. Ensure that the Path box is empty. Click Next.
[pic]
Note
The path you type in Public Name must be a root Web directory. Communicator Web Access does not support publishing the Communicator Web Access Web site as a subdirectory of another Web site.
9. On the Select Web Listener page, click New.
10. On the Welcome page of the Create New Web Listener Wizard, in the Web listener name box, type the name that remote clients will use to access the Communicator Web Access server, and then click Next.
11. On the IP Addresses page, select the check box in front of External and ensure that all other check boxes are cleared so that the Web listener will listen only to the traffic coming from the external network. Click Address.
12. Under Listen for requests on, click Specified IP addresses on the ISA Server computer in the selected network. Under Available IP Addresses, click the IP address for the ISA External network adapter. Click Add, click OK, and then click Next.
13. On the Port Specification page, clear the Enable HTTP check box, select the Enable SSL check box, and make ensure that the number in the SSL port box is 443. Click Select.
14. On the Select Certificate page, select the SSL certificate. The common name on the certificate must match the public name. This name is the URL that remote users will use to connect to the published Communicator Web Access server on the internal network. Click OK.
[pic]
Note
We recommend that you not use the same URL for external and internal connections in a production environment.
15. On the Port Specification page, click Next.
16. On the Completing the New Web Listener Wizard, click Finish.
17. On the Select Web Listener page, verify the Web listener properties, and then click Next.
18. On the User Sets page, click Next to accept the default of All Users.
19. On the Completing the New SSL Web Publishing Rule Wizard, click Finish.
20. On the main ISA management console, click Apply to commit the changes you made.
21. On the Apply New Configuration confirmation box, click OK.
22. In the main ISA management console, the Firewall Policy tab should contain rule 1 named imserver. and the Last Default Rule.
At this point, you have two virtual servers, Communicator Web Access_Internal and Communicator Web Access_External. Communicator Web Access_External is SSL Web Published by ISA Server 2004. Communicator Web Access_Internal is accessible from SSL port 443,and Communicator Web Access_External is accessible from SSL port 444. On a computer on the internal network with permission to access both virtual servers, port 444 must be specified to access the external site. Port 443 is the default, and it does not need to be specified to access the internal site.
You will now configure ISA to automatically redirect the remote user traffic from the public URL to the external virtual server on port 444 so that the user does not have to specify port 444. This step is necessary so that ISA Server will direct requests to port 443, which by default is used by the internal virtual server. For security reasons, it is important to isolate the internal servers from external traffic.
After you automatically redirect remote user traffic, internal and remote users can connect to Communicator Web Access server by using the same URL. Communicator Web Access will always direct a given user to the appropriate virtual server on the correct port.
[pic]
To configure ISA to redirect external requests to port 444 internally
1. Click Start, point to Prog4rams, point to Microsoft ISA Server, and then click ISA Server Management.
2. In the ISA Server Management console tree, click the Firewall Policy node.
3. In the details pane, right-click the firewall policy corresponding to the Communicator Web Access server, and then click Properties.
4. On the Properties page, click the Bridging tab.
5. On the Bridging tab, click Web server, clear the Redirect requests to HTTP port check box, select the Redirect requests to SSL port check box, and type 444 in the box to the right. You do not need to select a certificate on this page.
6. Click OK.
7. In the ISA Server Management console, click Apply to commit the changes you have made.
8. On the Apply New Configuration confirmation box, click OK.
Use a remote client to test the configuration. On the client, enter the URI https:// in the browser. In the Security Alert dialog box, click Yes. You should see the Forms-based Communicator Web Access sign-in page.
Figure 19: Forms-based Communicator Web Access Login
[pic]
After signing in to Communicator Web Access, the main Communicator Web Access client window should appear.
Management and Operations
This section describes options for managing, configuring, and monitoring Communicator Web Access.
Managing the Communicator Web Access Server
This section explains how to use Communicator Web Access Manager to manage one or more Communicator Web Access servers from a Communicator Web Access server or from a remote computer. When you connect to a physical Communicator Web Access server, information about the server, including the number of virtual servers that it contains, is displayed in the details pane of Communicator Web Access Manager. You can use Communicator Web Access Manager to configure the properties of both physical servers and virtual servers.
From Communicator Web Access Manager, you can do any of the following:
▪ Connect to a physical server.
▪ Disconnect a server.
▪ Deactivate a server before removing it from service.
▪ Create a new Web access server (virtual server).
You can also take the following actions on virtual servers:
▪ Start, stop, and restart a virtual server.
▪ Import or export a configuration file of the virtual server’s settings.
▪ Refresh the virtual server.
▪ Delete the virtual server.
You can also configure authentication and connectivity properties.
During Communicator Web Access setup, Communicator Web Access Manager is automatically installed on the server. You can also install the manager on a remote computer by opening the deployment tools and selecting the last option, Install Communicator Web Access Manager. For details about the deployment tools, see “Installing Communicator Web Access by Using the Deployment Tools” earlier in this guide.
Communicator Web Access Manager will run on any of the following operating systems:
▪ Windows XP Professional Edition
▪ Windows Server 2003, Standard Edition
▪ Windows Server 2003, Enterprise Edition
Communicator Web Access Manager is not supported on any version of Windows 2000.
A Communicator Web Access snap-in for the Microsoft Management Console is also installed during Communicator Web Access installation. If your organization has a large number of administrators, you can create a console that contains the snap-in and redistribute the .msc file to administrators with read-only access.
[pic]
Important
You must install IIS Manager on a remote computer before you can install Communicator Web Access Manager. Only the management components are required; you do not need to install IIS on the computer. You can use Control Panel to install the Internet Information Services Snap-in (Windows XP) or Internet Information Services Manager (Windows Server 2003), or you can download the Internet Information Services (IIS) 6.0 Manager for Windows XP.
[pic]
To install Communicator Web Access Manager on a remote computer
1. Log on to the server as a member of the Administrators and the DomainAdmins groups.
2. In the Communicator Web Access installation folder, run Setup.exe to open the Deploy Microsoft Office Communicator Web Access page.
3. On the deployment page, click Step 4: Install Communicator Web Access Administrative Snap-in.
4. On the Welcome page, click Next.
5. On the License Agreement page, click I accept the terms in the license agreement, and then click Next.
6. On the Ready to Install page, accept the default location, or click Change to select an alternate location, and then click Next.
7. On the Ready to Install page, click Install.
8. On the Setup Complete page, click Finish.
[pic]
To connect to the Communicator Web Access server
1. On the Start menu, click All Programs, click Administrative Tools, and then click Communicator Web Access Manager.
2. Right-click Microsoft Office Communicator Web Access Manager, and then click Connect.
In the Computer Name box, type the server name, IP address, or FQDN (fully qualified domain name) of the Communicator Web Access server, and then click OK. After your logon has been authenticated and authorized, Communicator Web Access Manager appears.
[pic]
Note
If your user account is not authorized to log on to the Communicator Web Access server, you can connect as another user by selecting the Connect As check box, entering credentials for that user, and then clicking OK.
Figure 20: Communicator Web Access Manager
[pic]
[pic]
To Deactivate the Communicator Web Access server
1. In Communicator Web Access Manager, connect to the Communicator Web Access server with an account that a member of the Administrators and RTCDomainServerAdmins groups.
2. Right-click the physical server node, and then click Deactivate.
3. On the Welcome to the De-activate Wizard page, click Next.
4. On the Review before De-Activation page, click Next.
5. On the De-activation Wizard has been completed successfully page, click Finish.
Managing Virtual Servers
During installation of Communicator Web Access, a Communicator Web Access virtual server (Web site) is created in IIS with the appropriate virtual directories, content, and default Web site settings. The default IIS settings are listed in “Default Communicator Web Access IIS 6.0 Settings” earlier in this document. To change any of these settings on the Communicator Web Access Web site, use IIS Manager. For details about IIS Manager, see the IIS Manager documentation.
The Communicator Web Access deployment tools will create only the first Communicator Web Access virtual server. In order to create additional virtual servers, for example, for remote user access, you must use Communicator Web Access Manager.
After Communicator Web Access is installed, you can add virtual servers to the same Communicator Web Access server. For example, you can create multiple Communicator Web Access virtual servers to take advantage of server isolation, provided by IIS 6.0, to logically separate external and internal users even if all traffic is routed through the same physical server.
[pic]
To Import a Configuration file
1. In Communicator Web Access Manager, connect to the Communicator Web Access server with an account that a member of the Administrators and RTCDomainServerAdmins groups.
2. Expand the tree view, right-click the server FQDN node and click Import Configuration file.
3. On the Welcome to the Import Wizard page, click Next.
4. On the Select Configuration File to Import page, enter the file name including path, or click the Browse button to enter the file name and path. If you click the Browse button, on the Open page, locate the .XML file to import, and then click Open.
5. On the Select Configuration File to Import page, click Next.
6. On the Import Wizard was successfully completed page, click Finish.
7. In Communicator Web Access manager, right-click the virtual server node, and then click Properties. Click the Connectivity tab. Under Server certificate, if HTTPS (recommended) is selected, click Select Certificate, and then select the Web Server certificate to use for HTTPS.
[pic]
To Export a Configuration file
1. In Communicator Web Access Manager, connect to the Communicator Web Access server with an account that a member of the Administrators and RTCDomainServerAdmins groups.
2. Expand the tree view, right-click the Web Access Server node, and then click Export Configuration File.
3. On the Welcome to the Export Wizard page, click Next.
4. On the Select Configuration File to Import page, enter the file name including path, or click the Browse button to enter the file name and path. If you click the Browse button, on the Open page, locate the .XML file to import, and then click Open.
5. On the Choose Destination Folder page, click Next.
6. On the Export Wizard was successfully completed page, click Finish.
Virtual server properties
When you right-click the Microsoft Office Communicator Web Access server node in the tree view pane, Communicator Web Access Manager displays a property sheet with three configuration tabs:
▪ General
▪ Authentication
▪ Connectivity
Figure 21: General Tab
[pic]
On the General tab, the Live Communications Server box displays the FQDN of the Live Communications Server that should receive traffic from Communicator Web Access users. If you leave the box blank (the recommended setting for most deployments), Communicator Web Access will determine each user’s Live Communications Server home server and route traffic accordingly.
If you want to route user traffic through a specified Live Communications Server, type the FQDN (fully qualified domain name) of the Live Communications Server in the box. For example, you may want to archive traffic from remote users only. In that case, you would deploy a Live Communications Server Director for external traffic and enable archiving. When you configure the Communicator Web Access external virtual server, you would use this box to specify the FQDN of the Director.
Figure 22: Authentication Tab
[pic]
On the Authentication tab, you can set public and private timeouts for the external site. For security reasons, you might want to configure your external site timeouts to be shorter than the default internal site timeouts. Reducing the timeout can help reduce the risk of an unauthenticated user finding an unattended, authenticated session. An unattended, authenticated session can result from a user walking away from an authenticated session on an external, public computer.
Only forms-based authentication can be used by remote users. For internal sites, you can specify the authentication method. Timeout settings are disabled for internal sites.
If the Allow user specific URI check box is selected, users can include a contact’s SIP address in the server URI. For example, a user could enter the following URI in the browser:
If the Allow user specific URI without any supplied domain check box is selected, users can include a contact’s SIP address in the server URI, but the domain portion of the SIP address is optional. For example, a user could enter the following URI in the browser:
If both check boxes are cleared, the user must identify the contact as a separate step. For example, a user could enter only the following URI in the browser:
The user must then supply the SIP address of the contact in the form that appears on the home page of the server.
Monitoring
This section discusses options for monitoring Communicator Web Access.
The Microsoft Office Communicator Web Access Management Pack for Microsoft Operations Manager (MOM) 2005 adds the following Communicator Web Access-related information to MOM 2005 SP1:
▪ Computer Group
▪ Admins Notification Group
▪ Event Rules
▪ Performance Rules
▪ Alert Rules:
By using these features, MOM administrators can monitor Communicator Web Access servers and receive automatic e-mail notifications of critical events. Some examples of critical events include the following:
▪ The CWA service unexpectedly terminates.
▪ A huge backlog of users is trying to log on to the system.
▪ Communicator Web Access cannot connect to Active Directory, so it cannot authenticate users or search for contacts.
The management pack helps keep you aware of issues that need attention. It also provides additional information for responding to critical issues beyond the information provided by the standard event logs and performance counters that are included with Windows and Windows Server.
The following components are not provided in the Communicator Web Access management pack; however, you can add these components by using the MOM Pack authoring features:
▪ State Views
▪ Custom Tasks
▪ Scripts for automated responses
▪ Reporting
System Requirements
The Communicator Web Access management pack requires the following software:
▪ Microsoft Operations Manager 2005 SP1
▪ Live Communications Server 2005 with SP1 Management Pack (optional, but highly recommended)
[pic]
To install the Communicator Web Access management pack
1. On a computer with the MOM Administrator Console installed, download the management pack from the Management Pack and Product Connector Catalog at .
2. Run the Microsoft Windows Installer to install the management pack files in a local, temporary folder.
3. Click Start, point to Programs, and then click Microsoft Operations Manager 2005. From Microsoft Operations Manager 2005, click Administrator console.
4. In the management pack tree in the console, select Import/Export Management Pack.
5. On the Select Management Packs page, select the management packs that you want to import, and then select an import option.
Using the MOM Pack
Microsoft Operations Manager collects events and performance data from the monitored systems. Administrators can view the results in the MOM operator console. The following views display Communicator Web Access data:
▪ Alerts View
▪ Events View
▪ Performance View
[pic]
Important
To ensure that notifications work properly, manually add an Operator object for each network administrator to MOM and configure its e-mail settings (and pager settings, if desired). Then add the Operator object to the Live Communications Server administrators notification group. After you perform these steps, when an error-level alert (or higher severity) occurs, Live Communications Server the operator should be notified by e-mail (and by pager, if configured).
In the MOM 2005 administrator console, the Microsoft Office Communicator Web Access node appears under the Microsoft Office Live Communications Server 2005 node. The Microsoft Office Communicator Web Access node contains the following rule groups:
▪ Authentication
▪ Performance
▪ Policy
▪ Session Service
▪ User Search
Each rule group may contain event rules, performance rules, and an alert rule. The alert rules are configured to send e-mail to the Live Communications Server administrators notification group whenever MOM receives an event or performance counter with a severity of Error or higher.
The following alert levels are also available in MOM:
▪ Service Unavailable
▪ Security Issue
▪ Critical Error
▪ Error
▪ Warning
▪ Information
▪ Success
The Communicator Web Access management pack also installs the necessary event and performance counter providers and the Communicator Web Access computer group so that MOM can automatically find Communicator Web Access servers and collect the appropriate information.
Customizing the Management Pack
Depending on their needs, organizations can customize the Communicator Web Access management pack by making the following modifications:
▪ Modify rules – You can suppress events that are appearing too frequently or disable unnecessary events. You can also configure pager data to notify network administrators by their pagers when alerts occur.
▪ Customize tracking – You can use performance rules and some of the information event rules to track service performance, manage service levels (for example, identify peak usage periods and periods of increased latency), and track service uptime.
▪ Expand functionality – You can add your own rules, tasks, and automated responses.
Additional MOM Resources
For additional information about MOM 2005, please see the following resources:
MOM Security Guide.
MOM Catalog.
MOM Resource Kit.
Removing Communicator Web Access
This section describes how to remove Communicator Web Access from a server. You must first deactivate the Communicator Web Access server to remove its corresponding entry from Active Directory.
[pic]
Note
If Live Communications Server and Communicator Web Access are colocated on the same server, deactivating Communicator Web Access will also deactivate Live Communications Server. Because Active Directory contains a single entry for the physical server, deactivating one of the server roles removes the physical server entry in Active Directory, and consequently, both server roles become unavailable.
[pic]
To deactivate the Communicator Web Access server
1. Click Start, point to All Programs, point to Administrative Tools, and then click Communicator Web Access Manager. In the Communicator Web Access Manager console tree, right-click the physical server node, and click Deactivate.
2. Follow the steps in the wizard to deactivate the server.
[pic]
To remove the Communicator Web Access server
1. Click Start, click Control Panel, and then click Add or Remove Programs.
2. Click Change or Remove Programs.
3. From the Currently installed programs list, click Microsoft Office Communicator Web Access server.
4. Click Remove.
5. Click Yes.
Appendixes
Appendix 1: Accounts
This section describes the accounts required for Communicator Web Access.
Accounts Created by Communicator Web Access Setup
The following account is created by the Communicator Web Access setup program.
Table 8: Account Created by Setup
|Account Name |Member Of |
|CWAService |RTCHSDomainServices |
Administrator Groups
The following administrator group changes are required for Communicator Web Access.
Table 9: Administrator Group Changes
|Account Name |Changes |
|RTCDomainServerAdmins |The RTCDomainServerAdmins group is created by Live Communications|
| |Server. During setup, Communicator Web Access adds |
| |RTCDomainServerAdmins to the local Administrators group. |
Appendix 2: Enabling Activation Without Using Domain Admins Credentials
To activate the Communicator Web Access server, you must be logged on as a member of the DomainAdmins group or a group with equivalent user rights. If you do not want to add an administrator to the DomainAdmins group, you can still allow the administrator to activate the server by creating a new security group, granting the security group only the rights and permissions that are required to run the Communicator Web Access Activation Wizard, and adding the administrator to the new security group.
The following permissions are required to run the Communicator Web Access Activation Wizard:
▪ Rights equivalent to membership in the Administrators group on the local computer.
▪ Permissions on the Live Communications Server global container RTC Service, to create and delete global settings.
▪ Permissions on the container that contains the RTCDomainServerAdmins group and the RTCHSDomainServices group to create and delete accounts.
▪ Read and Write permissions on the service account that is specified during activation.
[pic]
To grant a user these permissions, you can perform the following tasks:
1. Create a service account for Communicator Web Access in the same the container that contains the RTCDomainServerAdmins group and the RTCHSDomainServices group. This service account will be specified during activation.
2. Create a global security group and give it a name, for example, CWAServerAdmins.
3. Grant the new security group the permissions necessary to create and delete global settings. The group must have the following permissions on the RTC Service object: Read, Create All Child Objects, and Delete All Child Objects.
4. Grant the new security group the permissions necessary to create and delete accounts. The account must have the following permissions on the Users container (or the container that contains the RTCDomainServerAdmins group and the RTCHSDomainServices group): Read, Create All Child Objects, and Delete All Child Objects.
5. Grant the new security group Read and Write permissions on the service account that will be specified during activation.
6. Add the administrator’s user account to the new security group, so that the administrator can run the Communicator Web Access Activation Wizard without membership in the DomainAdmins group.
The following procedures describe these steps in detail.
[pic]
To create a service account that will be specified during activation
1. Log on to a computer as a member of the DomainAdmins group for the domain where you will deploy Communicator Web Access.
2. Open Active Directory Users and Computers: Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers.
3. In the console tree, expand the domain node, right-click Users Create a service account for Communicator Web Access in the same the container that contains the RTCDomainServerAdmins group and the RTCHSDomainServices group. This service account will be specified during activation, click New, and then click User.
4. In First name, type the account name (for example CWAServiceAccount). In User logon name, type the same account name. Click Next.
5. In Password, type a password. In Confirm password, type the same password.
6. Clear the User must change password at next logon check box. Click Next, and then click Finish.
7. In the details pane, right click RTCHSDomainServices, and then click Properties. Click the Security tab.
8. Click Add. Under Enter the object names to select, type the service account name, and then click OK.
[pic]
To create a security group
1. Log on to a computer as a member of the DomainAdmins group for the domain where you will deploy Communicator Web Access.
2. Open Active Directory Users and Computers: Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers.
3. In the Active Directory Users and Computers console tree, right-click Users, click New, and then click Group.
4. In Group name, type the group name (for example CWAServerAdmins). Under Group Scope, accept the default Global. Under Group type, accept the default Security. Click OK.
[pic]
To grant the required global permissions to the security group
1. Log on to a computer as a member of the DomainAdmins group for the domain where you will deploy Communicator Web Access.
2. Open Active Directory Users and Computers: Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers.
3. On the View menu, click Advanced Features.
4. In the console tree, expand the root domain node, expand System, expand Microsoft, and then expand RTC Service.
5. Right-click Global Settings, and then click Properties.
6. Click the Security tab, and then click Add.
7. In the Enter the object names to select box, type the name of the global security group (for example, CWAServerAdmins), and then click OK.
8. Next to the following permissions, click Allow:
▪ Read
▪ Create All Child Objects
▪ Delete all Child Objects
9. Click OK.
[pic]
To grant permissions required to create and delete accounts to the security group
1. Log on to a computer as a member of the DomainAdmins group for the domain where you will deploy Communicator Web Access.
2. Open Active Directory Users and Computers: Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers.
3. In the Active Directory Users and Computers console tree, expand the node of the domain where Communicator Web Access will be installed. Right-click Users (or the container that contains the RTCDomainServerAdmins group and the RTCHSDomainServices group), and then click Properties.
4. Click the Security tab, and then click Add.
5. In the Enter the object names to select box, type the name of the global security group (for example, CWAServerAdmins), and then click OK.
6. Next to the following permissions, click Allow:
▪ Read
▪ Create All Child Objects
▪ Delete all Child Objects
7. Click OK.
[pic]
To grant permissions on the service account to the security group
1. Log on to a computer as a member of the DomainAdmins group for the domain where you will deploy Communicator Web Access.
2. Open Active Directory Users and Computers: Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers.
3. In the Active Directory Users and Computers console tree, click Users. In the details pane, right-click the service account you created (for example CWAServiceAccount), and then click Properties.
4. Click the Security tab, and then click Add.
5. Under Enter the object names to select, type the name of the global security group (for example, CWAServerAdmins), and then click OK.
6. Next to the following permissions, click Allow:
▪ Read
▪ Write
7. Click OK.
[pic]
To add a user to the security group
1. In the Active Directory Users and Computers details pane, right-click the name of the global security group (for example, CWAServerAdmins), and then click Properties. Click the Members tab.
2. Click Add. Under Enter the object names to select, type the user account name, and then click OK twice.
The user now has the rights permissions necessary to run the Communicator Web Access Activation Wizard.
Appendix 3: WMI Settings
The following table lists the default Communicator Web Access server WMI settings for an internal and an external virtual server instance. The WMI properties that can be changed directly, without using Communicator Web Access Manager, are identified in the Can be Changed? column. Any changes made directly to WMI properties take effect immediately without restarting the virtual server.
Table 10: WMI Settings
|Can be changed? |Name |Type |Value |
|MSFT_CWASupportedLanguage |
|No |Enabled |boolean |true |
|No |FriendlyName |string |English |
|No |LanguageID |uint32 |1033 |
|No |LanguageTag |string |EN |
|MSFT_CWASiteSetting |
|Yes |AllowDomainlessUri |boolean |false |
|Yes |AllowFormAuth |boolean |true |
|Yes |AllowIwaAuth |boolean |true (false for external) |
|Yes |AllowSingleSignon |boolean |true |
|Yes |BackendLCS |string | |
|No |ConnectivityType |string |HTTPS |
|Yes |DefaultLanguageID |uint32 |1033 (English) |
|Yes |DefaultSearchField |uint32 |12 |
| | | |Accepted values: |
| | | |0000 (0) |
| | | |0001 (1) |
| | | |0010 (2) |
| | | |0011 (3) |
| | | |0100 (4) |
| | | |0101 (5) |
| | | |0110 (6) |
| | | |1000 (8) |
| | | |1001 (9) |
| | | |1010 (10) |
| | | |1100 (12) |
|Yes |DefaultSearchQuery |string |OR |
| | | |Accepted values: AND, OR |
|No |Description |string | |
|Yes |FormPrivateTimeoutMin |uint32 |240 |
|Yes |FormPublicTimeoutMin |uint32 |15 |
|No |FQDN |string | |
|No |IP |string |[blank] |
|Yes |MaxQueuedSearches |uint32 |80 |
| | | |Accepted values: 1 to 80 |
|No |Name |string |W3SVC/########## |
|No |Port |uint32 |443 |
|Yes |SearchMaxClientResults |uint32 |10 |
| | | |Accepted values: 1 to 300 |
|Yes |SearchMaxServerResults |uint32 |200 |
| | | |Accepted values: 1 to 1000 |
|Yes |ServerType |string |Internal (external for external) |
|Yes |UserNotice |string |[Blank] |
|MSFT_CWAServerSetting |
|No |Activated |boolean |true |
|No |Name |string |Server FQDN |
|No |TLSCertIssuer |array of unit8 | |
|No |TLSCertSN |array of unit8 | |
Appendix 4: Configuring IIS 6.0
This section describes the changes that Communicator Web Access makes in IIS 6.0 and discusses configuration considerations.
The Communicator Web Access Setup Wizard makes a number of changes in IIS 6.0, as shown in the next figure.
Figure 23: IIS 6.0 MMC
[pic]
Application Pools
The Communicator Web Access, Create Virtual Server Wizard creates two application pools for the first virtual server created:
▪ Communicator Web Access
▪ W3SVC
The Communicator Web Access, Create Virtual Server Wizard creates one application pool for each virtual server that is created after the first virtual server:
▪ W3SVC
Web Service Extensions
The Communicator Web Access, Create Virtual Server wizard creates a Web service extension for the first virtual server that is created. The cwaauth attribute must be set to Allowed in the IIS 6.0 Manager.
Creation of subsequent virtual servers does not result in additional Web service extensions.
[pic]
Important
Do not use the recycling options in the application pool properties. The recycling application pool settings are specified on the Recycling tab of an application pool’s Properties dialog box. Because some Communicator Web Access processes are stateful, using any of these recycling options can result in failures.
For additional information see “Web Application Services Operations” in the Windows Server System Reference Architecture (WSSRA) at:
Default Communicator Web Access IIS 6.0 Settings
During Communicator Web Access setup, several IIS settings are configured automatically. The default settings configured by setup are listed in Table 11.
Table 11: Default IIS 6.0 MMC, Communicator Web Access web site settings
|Setting Name |Type |Setting Value |
|Web Site Tab |
|Description |text box |Communicator Web Access |
|IP Address |drop down list box |(All Unassigned) |
|TCP Port |text box |80 |
|SSL Port |text box |443 |
|Connection Timeout |text box |120 |
|Enable HTTP Keep-Alives |check box |selected |
|Enable logging |check box |selected |
|Active log format |drop down list box |W3C Extended Log File Format |
|Advanced Web Site Identification-Multiple identities for this Web Site |
|IP Address |text box |Default |
|TCP Port |text box |80 |
|Host Header Value |text box | |
|Advanced Web Site Identification-Multiple SSL identities for this Web Site |
|IP Address |text box |Default |
|SSL Port |text box |443 |
|Logging Properties - General Tab |
|New log schedule |radio buttons |Daily radio button selected |
|Use local time for file naming |check box |unselected |
|and rollover | | |
|Log file directory |text box |%windir%\system32\LogFiles |
|Logging Properties - Advanced Tab |
|Extended logging options |lots of check boxes | |
| |unselected |Server Name (s-computername) |
| | |Bytes Sent (sc-bytes) |
| | |Bytes Received (cs-bytes) |
| | |Time Taken (time-taken) |
| | |Protocol Version (cs-version) |
| | |Host (cs-host) |
| | |Cookie (cs(Cookie)) |
| | |Referer (cs(Referer)) |
| |selected |All remaining check boxes |
|Performance Tab |
|Bandwidth Throttling |check box |unselected |
|Web site connections |radio buttons (2) |Unlimited radio button selected |
|ISAPI Filters Tab |
|Setting Name |Type |Setting Value |
|Filter Name |text box |cwaauth |
|Priority |text box |Low |
Configuring for Performance
To maintain peak performance of your Communicator Web Access servers, you can configure the following IIS property settings:
▪ Web Site Connections – Web site connections are set to unlimited by default. Connection limits restrict the number of simultaneous client connections to your Web sites and your Web server. Limiting connections conserves memory and protects against malicious attempts to overload your Web server with thousands of client requests.
▪ Bandwidth throttling – By default, bandwidth throttling is disabled. If the network or Internet connection that is used by the Communicator Web Access server is also used by other services such as e-mail or news, you may want to limit the bandwidth that is used by each service. If your Web server hosts more than one Web site, you can individually throttle the bandwidth that is used by each site.
▪ IIS Logging – IIS logging is enabled by default. When IIS logging is enabled, the IIS log files could use up the free disk space on the server over a period of time. For example, in a deployment that supports 1,000 or more users, free disk space could be depleted within a few days. To keep Communicator Web Access server running properly, you should enable IIS logging only for debugging purposes, or you should regularly delete obsolete files.
For information about tuning IIS 6.0 settings, see “Performance Tuning (IIS 6.0)” at .
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- microsoft office 2010 free download and install
- office 365 web access email
- outlook web access veterans affairs
- comcast outlook web access mail
- outlook web access baltimore city
- microsoft office free web apps
- download and install microsoft office 2019
- outlook web access logon
- how to get microsoft office for teachers and students
- microsoft office for teachers and students
- microsoft office home and student 2016
- microsoft office home and business 2016 sale