CWA PlanDeploy

Microsoft Office
Communicator Web
Access
(2007 release, Public
Beta)
Planning and
Deployment Guide
Published: March 2007
This document supports a preliminary release of a software product that may be changed substantially prior to final commercial release.
This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document.
Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of
the use or the results from the use of this document remains with the user. 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.
© 2007 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Mobile, Windows Server, Windows Vista, Active Directory, ActiveX, Internet Explorer, MSN,
and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.

CONTENTS
CONTENTS........................................................... .............................3
Introduction..................................................................................... .......1
Overview.................................................................................. .........1
Communicator Web Access Features....................................... .....2
Comparing Communicator Web Access and Office Communicator
2007.................................................................................. ......3
Reference Architecture........................................................ .........6
Communicator Web Access Deployment Components............8
Planning........................................................................... ......................9
Planning for Deployment............................................................... ....9
Planning Active Directory...................................... .....................10
Selecting a Supported Topology.................................................10
Reference Topology........................................... ....................11
Single Forest Topologies.................................... ....................11
Multiple-Domain Topologies.............................................. .....12
Multiple Forest Topologies.....................................................12
Using Physical Separation or Application Isolation................13
Branch Office Topologies................................... ....................15
Federation............................................................ .................15
Custom Authentication, Including SSO..................................16
IM Archiving............................................ ..............................16
Communicator Web Access Requirements.................................16
Supported Server Operating Systems...................................18
Supported Clients ......................................................... ........19
Client Interoperability...................................................... ......20
Server Requirements....................................................... ......21
Server Hardware Requirements......................................... ....22
Additional Infrastructure Information.................................... .23
Planning for Required Certificates..............................................23
Planning for Communicator Web Access Certificates............. 23
Planning for Office Communications Server 2007 Certificates27
Planning for Hardware Load Balancing Certificates...............27
Planning for Remote User Certificates ..................................27
Understanding Authentication and Authorization.......................27
Authorization.................................................................. .......28
Authentication................................................................ .......28
Allowing Pop-up Blockers..................................................... ..29
Accepting Cookies................................................... ..............30
Understanding Custom Authentication, Including Single Sign-on 30
Planning for Capacity Requirements.......................................... .30
Increasing Capacity................................................... ............30
Planning for Performance Requirements...............................32
Using Typical Performance Metrics for Planning....................32
Planning for High Availability............................................... .......33
Understanding Failover......................................................... .34
Planning for Disaster Recovery................................................. ..40
Planning for a Standby Recovery Server...............................40
Deploying Communicator Web Access.................................................41
Deploying Servers for Internal Users..................................... ..........41
Communicator Web Access Setup Overview .............................41
Preparation............................................................................. ....42
Preparing the Server for Installation............................... .......43
Preparing Certificates for Communicator Web Access...........43
Download the CA certificate chain........................................45
Request and install the MTLS Certificate...............................46
Request and install the HTTPS Certificate.............................47
Installing Communicator Web Access ........................................47
Installing Communicator Web Access by Using the Deployment Tools
.............................................................................................. .....48
Install and Configure Communicator Web Access .................48
Performing Post-Installation Configuration............................53
Creating Additional Virtual Servers......................................... ....54
Deploying Servers for Remote User Access.....................................60
Web Publishing the Remote Virtual Server.................................60
Using ISA Server 2006...................................................... .....60
Using ISA Server 2004 SP1 to Web Publish - Without SSO Enabled
......................................................................................... .....61
Using ISA Server 2006 to Web Publish - Without SSO Enabled61
ISA Server 2006 Prerequisites ..............................................62
Deploying ISA Server 2006 .................................................... ....63
Test the Deployment.................................... .........................81
PIC........................................................................................ ......83
Configuring for Capacity and Availability....................................... ..83
Increasing Capacity by Adding a Server.....................................83
Deploying a Hardware Load Balancer....................................83
Deploying the Additional Server................................. ...........84
Deploying High Availability Solutions.........................................84
Recovering from a Server Failure................................................ 86
Deploying a Backup Server...................................................86
Switching to the Backup Server........................................... ..86
Management and Operations.............................................. ............87
Managing Communicator Web Access Servers...........................87
Managing Virtual Servers......................................................90
Tracing................................................... ...............................94
Configuring Search........................................................... ..........94
MOM Pack .............................................................................. ....96
Customizing and Branding........................................ ......................98
Customizing the User Interface..................................................99
Custom Tabs................................................................. .........99
Custom Presence States................................................... .....99
Creating Corporate Branding.................................................. ....99
Enterprise Voice ............................................. .........................100
Call Forwarding..................................... ..............................100
Web UI Controls................................................................. .......101
SDK................................................................... .......................101
AJAX API..................................................... ..............................101
Security Considerations................................... .............................102
Providing a Single URL for both Internal and Remote Access . .102
Denial of Service Because of Failed Sign-In Attempts...............102
Service Account........................................................................ 103
Port Allocation........................................................ ..................103
Authentication Module................................. ............................103
Directory Permissions...................................................... .........103
Removing Communicator Web Access..........................................103
Configuring Clients................................................................. ............103
Preparing Clients to Sign in to Communicator Web Access .104
Configuring Users for Remote Access..................................108
Performing User Tasks........................................... ...................111
Managing User Options................................. ......................111
Managing Call Forwarding............................... ....................111
Upgrading and Interoperability........................................................ ...113
Planning for Migration and Coexistence...................................114
Understanding Interoperability Scenarios...........................115
Supported Collocation Topologies.................................. ......118
MMC Interoperability...................................... .....................119
Performing a Migration............................................... ..............119
Migrating to the 2007 release from the 2005 release..........119
Configuring Legacy Redirect............................................. ...124
Appendixes........................................................ ................................124
Appendix 1: Ports Used By Communicator Web Access ......124
Appendix 2: Accounts.................................................... ......125
Appendix 3: Enabling Activation Without Using DomainAdmins
Credentials............................................................ ..............125
Appendix 4: WMI Settings ..................................................129
Appendix 5: Configuring IIS 6.0 ..........................................131
Introduction
Microsoft® Office Communicator Web Access (2007 release) is a server that provides browser-
based client access to Microsoft Office Communications Server 2007. Office Communications
Server 2007 and Office Communicator Web Access (2007 release) build upon the foundation
established by Live Communications Server 2005 with SP1 and Communicator Web Access
(2005 release).
This guide helps you plan and deploy Communicator Web Access (2007 release) for your
organization. This 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, configuring the server, and preparing the
clients.
• Management and operations options, including monitoring.
• Migration and coexistence in the Upgrading and Interoperability section
Except where noted, this guide applies to Communicator Web Access (2007 release). See the
Upgrading and Interoperability section for environments in which the 2005 and 2007 releases are
deployed.
Overview
Presence awareness is the ability to detect another user’s availability on one or more devices. By
using Office Communications Server 2007, 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 Available, 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 Office Communications Server 2007 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 (2007 release) and compares the two Office
Communications Server 2007 clients, Communicator Web Access and Microsoft Office
Communicator 2007. It also presents reference architecture for supporting Communicator Web
Access in an existing deployment of Office Communications Server 2007.
2 Communicator Web Access (2007 release) Planning & Deployment Guide
Communicator Web Access Features

Microsoft Office Communicator Web Access (2007 release) enables users to access the instant
messaging and presence features in Office Communications Server 2007 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.contoso.com, in a supported Web browser. For a list of supported browsers, see the
Supported Clients section in this guide.
Communicator Web Access (2007 release) offers the following features:
• Web access – Users can access the IM and presence features in Office Communications
Server 2007 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.
• Enhanced 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 Communications Server 2007,
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 – A user with a supported browser,
whether or not the browser is based on the Microsoft Windows® operating system, 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 Office Communications Server 2007 can be
secured with SSL (secure socket layer).
• User search – The Communicator Web Access server connects to the Microsoft Active
Directory® Domain Services. 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 Office Communications Server 2007 Address
Book.
Communicator Web Access (2007 release) Planning & Deployment Guide 3
• Inbound Call Routing/Forwarding Inbound call routing is an option that enables the user
from within Communicator Web Access to specify how incoming calls are handled. The user
can forward calls to a single number, to a single contact, to two numbers simultaneously, or
to both a contact and a number simultaneously.
Let’s look at how Communicator Web Access (2007 release) has been improved from the 2005
release.
Communicator Web Access Improvements
Communicator Web Access (2007 release) includes the following improvements:
• Enhanced presence
• Automatic Discovery of servers in the MMC
• Inbound Call Routing
• Office Communicator 2007 User Interface
• Custom authentication, including single sign-on enablement
• Conferencing
• New AJAX Service API - provides rapid application development and integration providing
RTC features including a single sign-on experience
Comparing Communicator Web Access and Office Communicator

2007
Communicator Web Access (2007 release) provides browser-based access to the instant
messaging and presence features of Office Communications Server 2007. Communicator Web
Access shares some of the essential features and configuration settings of Office Communicator
2007. Table 1 compares the features available in each client, which are seen in figures following
the table.
Table 1: Client Feature Comparison
Feature Communicat Communicat
or 2007 or Web
Access (2007
release)
Instant Messaging with one or more ü ü
contacts
Application sharing ü
Whiteboard sessions ü
File or photo transfer ü
Audio communication ü
Video communication ü
Communication with the MSN® network of ü ü
Internet services, AOL® and Yahoo! ®
users, if supported by your organization’s
Office Communications Server 2007 (Beta

3) deployment (separate license required)
Communication with organizations that are ü ü
federated through Office Communications
Server 2007
Free and busy calendar information in ü ü1
status (Communicator Web Access read
and display, only)
Incoming IM pop-up notification ü ü
Personal note ü ü2
Automatic "Inactive" status after a period ü ü3
of inactivity
Access for users outside of the corporate ü ü
network without connecting through a VPN
Zero client installation ü
Support for other operations systems and ü
browsers
1
Information from a user’s (Bob’s) Outlook calendar is available in Communicator
Web Access only if Bob is signed in to Office Communicator 2007 before users in
Communicator Web Access try to access Bob’s calendar information.
2
As long as the user runs both Office Communicator 2007 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 "Inactive" after a
user-configurable period of time, by default 15 minutes.
The next figures compare Communicator Web Access and Office Communicator 2007, with the
main interface seen first.
Figure 1: Main Page
The next figures compare the instant message alerts for each client.
Figure 2: Instant Message Alerts
The next figures show the conversation page for each client.
Figure 3: Conversation Page
You can also customize the Communicator Web Access UI to provide corporate name recognition
and branding. See the Corporate Branding section in this guide.
Figure 4: Corporate Branding
Reference Architecture
Communicator Web Access (2007 release) is an extension of your existing Office
Communications Server 2007 deployment. You install Communicator Web Access server
software on servers inside your corporate network and configure them for internal user access or
remote user access, or both as seen in the next figure.
Figure 5: Communicator Web Access Topology
The preceding figure shows the reference Communicator Web Access topology. In this figure,
internal user and remote user traffic is physically separated by deploying separate Communicator
Web Access servers for each type of user. Both internal and external users connect by entering a
URI, for example https://<server_name>.contoso.com in their web browser. The firewall shown
in the figure routes incoming, external-user traffic to the Communicator Web Access server or
array of servers handling external users. The Communicator Web Access server performs
authentication and authorization before forwarding the traffic to Office Communications Server
2007 to provide presence and instant messaging.
Communicator Web Access (2007 release) servers can be deployed as an array of servers behind
a load balancer. However, the server array can be replaced with a single server for more modest
deployments. Internal users can and should be physically separated from remote users by
deploying both an internal and external pool to handle internal and external requests,
respectively.
Remote users can access the external pool by the Web Published Communicator Web Access
external site on the reverse proxy server using SSL. 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 a perimeter network, including the Microsoft
Internet Security and Acceleration Server (ISA Server) 2000, ISA Server 2004, ISA Server 2006,
and other firewall and reverse proxy solutions. However, if SSO is enabled for a Communicator
Web Access (2007 release) virtual server, then ISA Server 2006 with SSO enabled on the Web
listener must be deployed. See the following link for additional information about ISA Server.
• ISA Server: http://www.microsoft.com/isaserver/default.mspx
Communicator Web Access Deployment Components

In addition to Communicator Web Access, the reference architecture consists of the components
described in the following sections.
Office Communications Server 2007
Office Communications Server 2007 manages client connections, presence, and other real-time
communication features like instant messaging.
Active Directory
The Communicator Web Access and the Office Communications Server 2007 environment both
have a strong dependency on Active Directory. The minimum Active Directory requirements are
the same for both. Active Directory is used for authenticating, authorizing, provisioning, and
configuring Office Communications Server 2007. In Communicator Web Access, Active
Directory supplies the enterprise address list to facilitate search-based lookups.
Firewalls
Firewalls can help to protect your network against Internet attackers when your computers are
connected to the Internet. By using a firewall application such as ISA Server, you can more
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
When deploying load balanced Communicator Web Access (2007 release) servers, a hardware
load balancer must be used. Network load balancing is not supported. A hardware load balancer
to distribute user traffic is required in the following cases:
• Multiple Communicator Web Access (2007 release) servers
• Multiple Office Communications Server 2007, Enterprise Edition Servers forming a pool
• Multiple Office Communications Server 2007, Directors
• Multiple Office Communications Server 2007, Edge Access Servers
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 2.0

Communicator Web Access (2007 release) was developed using the Microsoft .NET Framework
2.0.
MMC
Microsoft Management Console (MMC) 2.0 and 3.0 are both supported.
ASP.NET 2.0
Microsoft ASP.NET 2.0, part of the .NET Framework 2.0, provides both developers and Web site
administrators with new and improved features. Communicator Web Access (2007 release) is
built upon ASP.NET 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 ASP.NET 2.0 is a Web interface that enables you to more securely, and more 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 ports that Communicator Web Access (2007 release) 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 Office Communications Server 2007
(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 Office Communications Server 2007 server or pool
For additional port information, see Appendix 1: Ports.
Planning
This section discusses planning your Communicator Web Access (2007 release) deployment.
Planning for Deployment

This section discusses considerations for planning your Communicator Web Access (2007
release) deployment. It covers the following topics:
• Planning Active Directory
• Selecting a Supported Topology
• Communicator Web Access Requirements

• Planning Certificates
• Understanding Authentication and Authorization
• Planning for Capacity Requirements
• Planning for High Availability
• Planning for Disaster Recovery
These sections cover a Communicator Web Access (2007 release) only environment. For a
discussion of migration and coexistence, see the Upgrading and Interoperability section.
Planning Active Directory

Communicator Web Access does not impose any additional requirements on your Active
Directory design. If you have already deployed Office Communications Server 2007, 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 Office Communications Server 2007 are deployed in the same Active
Directory forest and domain.
For information about Active Directory planning for Office Communications Server 2007, see
the Office Communications Server 2007 Active Directory Preparation document in the
Deployment Resources.
Selecting a Supported Topology

Overall topology support is dictated by Office Communications Server 2007. Communicator
Web Access servers must be deployed in the internal network. Deployment in the perimeter
network is not supported.
Supported topologies for Communicator Web Access include:
• Reference topology
• Single forest
• Multiple domains
• Multiple forests
• Using Physical Separation or Application Isolation
• Branch offices
• Federation
• Custom Authentication, Including SSO
• IM Archiving
Reference Topology
The reference topology is shown in Figure 5 earlier in this guide. In the reference topology, an
array of Communicator Web Access (2007 release) 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 or Forms-based authentication; remote users must use Forms-based
authentication. Internal and external 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 Office
Communications Server 2007 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.
Communicator Web Access deployed outside the internal network, including the perimeter
network, is not supported.
Single Forest Topologies

Two types of Single Forest topologies are supported.
Single tree
Single forest topologies are supported and small and medium organizations typically deploy a
single forest, single domain Active Directory topology.
Multi-tree
A multi-tree, single forest is a forest with two or more domains, for example contoso.com
containing sales.contoso.com and support.contoso.com.
Multiple-Domain Topologies
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 Office Communications Server 2007.
Requirements and support for multiple domain topologies are dictated by Office
Communications Server 2007, and Communicator Web Access imposes no additional
requirements on your Active Directory deployment. For details about deploying Active Directory
for Office Communications Server 2007, see the Office Communications Server 2007 Active
Directory Preparation Guide.
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 Office Communications Server 2007. 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 Office Communications Server 2007 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 Office Communications
Server 2007 Resource Kit. See “Deploying in a Multiple Forest Environment” in the LCSSync
folder.
Cross Forest Topology The cross forest topology is a multiple forest topology that
consists of multiple forests with synched home servers or pools between each of the forests.
Resource Forest Topology The resource forest topology is a multiforest configuration
used by Microsoft Exchange Server. This topology dictates that one of the forests in the
organization is dedicated for server applications only (for example, Exchange Server). Users
from other forests are represented as disabled user accounts in the resource forest. These disabled
user accounts are then enabled for a mailbox on the Exchange servers. Office Communications
Server can take advantage of the investment in this particular topology. In the same way that
disabled user accounts in the resource forest are enabled for Exchange, they can also be enabled
for Office Communications Server. This provides the benefit of only extending the Active
Directory schema in a single forest (the resource forest) and leveraging the existing Active
Directory infrastructure. In this topology, GALsync (global address list synchronization) is
required to synchronize information across forests.
Central Forest Topology The central forest topology is an improved variation of the
resource forest. Instead of using disabled user accounts to represent external users from other
forests, Active Directory Contact objects represent external users. MIIS (Microsoft Identity
Integration Server) is required to synchronize users as Contact objects in the central forest. In
addition to the advantages that the resource forest provides, the use of MIIS automates the life-
cycle management of users within the organization when new employees are hired or other
employees leave. Additionally, the use of Active Directory Contact objects is more lightweight
than Active Directory User objects. Finally, users within the central forest are not restricted from
being enabled for Office Communications Server.
Using Physical Separation or Application Isolation

To reduce deployment costs, you can host both internal and remote users on a single
Communicator Web Access (2007 release) server. However, the more secure and recommended
solution is to use physical separation by deploying separate servers for internal and external
users.
Application Isolation
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 physical 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 (2007 release).
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 (2007
release) 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 affect 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.
The next figure shows an example of a single Communicator Web Access server that is used for
both internal and external access (not recommended), using application isolation.
Figure 6: Same Server (Supported, but not recommended)
See http://technet2.microsoft.com/WindowsServer/en/library/25a310b6-c18f-4a7a-84f5-
115e5de2260c1033.mspx?mfr=true for details. However, the recommended deployment using
physical separation is discussed and shown in the next section.
The preceding figure showing application isolation is a way to configure a deployment 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.
Physical Separation
In the next figure, the internal and remote user traffic is physically separated by deploying a
dedicated server or array for each type of user.
Figure 7: Separate Servers (Recommended)
The internal virtual server uses port 443, and the external virtual server uses port 443 as well. The
firewall/reverse proxy server is configured to redirect incoming SSL traffic bound for port 443 to
port 443 on the Communicator Web Access server for external users.
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 https://im.contoso.com:444.
You can change an internal virtual server to an external virtual server, or an external virtual
server to an internal virtual server. You must do this in WMI. You cannot do this in the
Communicator Web Access Manager (2007 release) snap-in. The WMI setting is
• root\DEFAULT\rtccwa_repository\MSFT_CWASiteSetting\ServerType
Change the value to one of:
• Internal
• External
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 (2007
release), 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 Office Communications Server 2007
deployments, see the Office Communications Server 2007 Planning Guide, which is available
from the Office Communications Server 2007 Deployment Resources page at
http://office.microsoft.com/en-us/FX011450741033.aspx.
Federation
When federation is enabled in Microsoft Office Communications Server 2007, Communicator
Web Access users can view presence and send instant messages to users of the MSN® network of
Internet services, AOL®, Yahoo!®, 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 Office Communications Server 2007
deployments, see the Office Communications Server 2007 Access Proxy and Director Guide,
which is available from the Office Communications Server 2007 Deployment Resources page at
Custom Authentication, Including SSO
See the Communicator Web Access (2007 release) Authentication Guide.
IM Archiving
See the archiving topic in the Office Communications Server 2007 documentation.
Communicator Web Access Requirements

This section describes the hardware and software that are required to install Communicator Web
Access (2007 release).
Table 2: Requirements for installing Communicator Web Access (2007
release)
Computer Component Required For
Active Microsoft Windows® 2000 Operating system
Directory Server SP4
Domain Windows Server 2003
Controller
Active Directory Directory service
DNS Name resolution
Office Microsoft Office Schema
Communicatio Communications Server 2007
ns Server
2007
File System NTFS partition Communicator Web Access (2007
release)

PKI Windows Server 2003 SP1 PKI Infrastructure
Enterprise certification
authority (CA) (recommended)
or a trusted third-party
certification authority
infrastructure
IIS 6.0 Certificate services Web
enrollment support only
Communicat NTFS File system
or Web
Windows Server 2003 SP1 Operating system
Access (2007
release, Beta .NET Framework 2.0 Communicator Web Access /
3) server ASP.NET
Windows Installer 3.0 (installed Communicator Web Access
as part of Windows Server /ASP.NET
2003 SP1)
IIS 6.0 Communicator Web Access (2007
release)
ASP.NET 2.0 Communicator Web Access (2007
release)
Office Communications Server Communicator Web Access (2007
2007(Beta 3), Standard Edition release)
or Enterprise Edition
KB 915066 Communicator Web Access (2005
http://support.microsoft.com/kb release)
/915066
QFEs KB913297 Communicator Web Access (2005
/913297 Communicator Web Access (2007
release)
release)
release)

Client See Supported Client Operating System
Operating Systems
See Supported Client Browsers Browser/Client
Remote Communicator Web Access Remote management
Computer (2007 release) Manager
IIS 6.0 Manager
The remote computer and the
Communicator Web Access
(2007 release) server should
be located in the same Active
Directory domain.
Table 3: Communicator Web Access (2007 release) required permissions

Computer Action Required Permissions
Communicato Install Communicator Web User must be a member of local
r Web Access Access (2007 release) Administrators group.
(2007
Activate Communicator Web User must be member of the
release)
Access (2007 release) DomainAdmins group and the
server
RTCUniversalServerAdmins
group.
Create a virtual server User must be a member of local

Administrators group.
Remote Install Communicator Web User must be a member of local
Computer Access (2007 release) Manager Administrators group of the
on a remote computer remote computer.
*Communicator Web Access (2007 release) will not connect to previous versions of
Live Communications Server. Your organization may contain previous versions, but
Communicator Web Access (2007 release) users must be homed on servers that are
running Office Communications Server 2007.
Supported Server Operating Systems

The Communicator Web Access (2007 release) server is supported on Windows Server 2003
Service Pack 1. The following Windows Server 2003 SP1 editions are supported:
• Standard Edition
• Enterprise Edition
• Datacenter Edition
Important
The server must be a member of the same domain as a server
that is running Office Communications Server 2007. Installing
Communicator Web Access (2007 release) on a workgroup
computer is not supported and will result in an error during
setup.
Supported Communicator Web Access (2007 release) Manager

Operating Systems
You can use the Communicator Web Access Manager (2007 release) snap-in to manage one or
more Communicator Web Access (2007 release) servers from a remote computer. The following
operating systems are supported for remote Communicator Web Access (2007 release)
management:
• Windows XP Professional Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
Note
Communicator Web Access (2007 release) Manager is not
supported on any version of Windows 2000.
Important
Before installing the Communicator Web Access Manager
(2007 release) 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 Clients
Supported Communicator Web Access (2007 release) clients are:
Table 4: Supported Browsers
Operating Browser Authentication

System Mechanism
Windows 2000 Microsoft Internet Forms-based
SP4 Explorer® 6 SP1 NTLM
Custom
Windows XP SP2 Internet Explorer Forms-based
6 SP2 NTLM
Windows Internet Kerberos
Explorer 7
Custom
Firefox 2.0.latest
Windows Vista Internet Explorer Forms-based

7 NTLM
Firefox 2.0.latest Kerberos
Custom
Mac OS X 10.3.9 Safari 1.3.2 Forms-based
Kerberos
Custom
Firefox 2.0.latest Forms-based
NTLM
Kerberos
Custom
Mac OS X 10.4.8 Safari 2.0.latest Forms-based
Kerberos
Custom
Firefox 2.0.latest Forms-based
NTLM
Kerberos
Custom
Note
Install the Microsoft Internet Explorer® 6.0 SP1 Internet
browser in order to avoid issues with the title display in
desktop alerts, options dialog boxes, and permissions dialog
boxes.
Client Interoperability
This section describes interoperability with various clients.
Office Communicator 2005 and Office Communicator 2007
The user can run Office Communicator 2005 or Office Communicator 2007 and Communicator
Web Access (2007 release) client 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 Office Communicator 2007 and Communicator Web Access (2007 release) have a
mechanism that changes the user’s status after there has been a period of inactivity. In Office
Communicator 2007, 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 Inactive, but the user may still be actively
using his or her computer. For more information about Office Communicator 2007, see the
Microsoft Office Communicator 2007(Planning and Deployment Guide, which is available from
the Microsoft Office Communicator 2007 deployment resources page at
http://office.microsoft.com/en-us/assistance/HA011992481033.aspx.
Server Requirements
This section describes the requirements for deploying the Communicator Web Access (2007
release) server.
Infrastructure Requirements
The following infrastructure must be in place before you deploy Communicator Web Access
(2007 release):
• Active Directory is deployed.
• Domain controllers are running Microsoft Windows 2000 Server SP4 or Windows
Server 2003.
• Global catalog servers are running Windows 2000 Server 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
http://www.microsoft.com/downloads/details.aspx?FamilyId=779DEDAA-2687-4452-901E-
719CE6EC4E5A&displaylang=en.
• DNS is deployed and configured correctly.
• Office Communications Server 2007 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 (2007 release) 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 (2007 release)
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 Office Communications Server 2007.
Note
Installing Communicator Web Access on a workgroup
computer is not supported and will cause an error during
setup.
• Office Communications Server 2007 schema updates as specified in the Office

Communications Server 2007 Active Directory Preparation Guide.
• DNS.
• IIS 6.0.
• Windows Installer 3 (included in Windows Server SP1)
• .NET Framework 2.0 with ASP.NET 2.0 installed and registered.
• You must be logged on as a member of the DomainAdmins and RTCUniversalServerAdmins
groups to activate Communicator Web Access (2007 release).
• 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
Table 5: Minimum Group Membership
Group Minimum Requirement
Administrators (local) The user installing Communicator Web Access
(2007 release) server must be logged on as a
member of the local Administrators group.
Domain Admins The user activating the Communicator Web
Access (2007 release) server must be logged
on as a member of the DomainAdmins group
CWAService (default) The service account under which
Communicator Web Access (2007 release) runs
is added to the RTCHSUniversalServices group
created by Office Communications Server 2007.
RTCUniversalServerAdmins The user activating the Communicator Web
(created by Office Access (2007 release) server must be logged
Communications Server 2007) on as a member of the
RTCUniversalServerAdmins group.
Server Hardware Requirements

This section discusses the hardware requirements for Communicator Web Access (2007 release).
Communicator Web Access server Hardware Requirements
The recommended minimum hardware requirements for the Communicator Web Access (2007
release) server are:
• Dual 3.20 GHz CPU
• 4 GB DDR (double data rate)
• 1 × 36 GB NTFS-formatted Hard Drives
• 1 Gigabit Ethernet network adapter
Additional Infrastructure Information

This section provides links to infrastructure requirement documents. For information on Office
Communications Server 2007, see the Office Communications Server 2007 Deployment
Resources page.
Office Communications Server 2005
• 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
• Office Communications Server 2007 Active Directory Preparation at
DNS
• http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/featured/dn
s/default.mspx
PKI and Certificates
• Office Communications Server 2007 Configuring Certificates at
Planning for Required Certificates

Communicator Web Access (2007 release) and Office Communications Server 2007 both require
certificates that are issued from the same certification authority (CA). The CA can be either a
Windows Server 2003 SP1 Enterprise CA (recommended) or a trusted third-party (public)
certification authority. If a hardware load balancer is deployed in front of a Communicator Web
Access array, the hardware load balancer also requires a certificate from the same CA that issued
the Communicator Web Access and Office Communicator Server 2007 certificates. 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 as well. 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
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pki
bp.mspx.
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 Office
Communications 2007 server, or in the case of Legacy Redirection, the Live
Communications Server 2005 with SP1 server. The MTLS certificates in all cases must be
issued by the same trusted certification authority.
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. This certificate must be issued by the same trusted certification
authority that issued the MTLS certificate.
Both the MTLS and HTTPS certificates should be installed on the Communicator Web Access
server before you run Communicator Web Access setup. These certificates must be issued by the
same CA, and the certification authority must confirm the identity of each computer or user in the
authentication transaction.
When you deploy a supported configuration of Communicator Web Access (2007 release) you
will have one of the following scenarios:
• A single, separate Communicator Web Access server, with or without a legacy configuration
• Two or more Communicator Web Access servers behind a load balancer, with or without a
legacy configuration
The above Communicator Web Access (2007 release) configurations are connected to one of the
following Office Communications Server 2007 configurations:
• A single Office Communications Server 2007, Standard Edition with or without a legacy
configuration
• Two or more servers that are running Office Communications Server 2007, Enterprise
Edition behind a load balancer, with or without a legacy configuration
The above scenarios have additional or modified certificate requirements, to those already
discussed, when:
• Load balancing is introduced
• The Communicator Web Access virtual server is enabled for custom authentication and an
ISA Server 2006 with an SSO-enabled Web listener is deployed
• SSL Web publishing is introduced
When and if deployed, certificates are also required for:
• A Load balancer
• ISA Server 2006 configured to Web publish a Communicator Web Access (2007 release)
virtual server using SSL, with or without custom authentication enabled on the virtual server
In all of the above cases, if you are migrating from Live Communications Server 2005 SP1 and
Communicator Web Access (2005 release), you could have one or more legacy Live
Communications Server 2005 SP1 servers and one or more legacy Communicator Web Access
(2005 release) servers. No changes to the legacy certificates already configured on the legacy
components are required by migration.
Planning for MTLS Certificates
The MTLS certificate is used to identify the Communicator Web Access server to the Office
Communications Server 2007 server (either EE pool or SE), or in the case of Legacy Redirection,
the Live Communications Server 2005 SP1 server. The Communicator Web Access certificate
FQDN, configured in the Manager (MMC) is always the Communicator Web Access server
machine FQDN. If a load balancer is deployed, which has a VIP, the certificate on the load
balancer has an FQDN of the VIP FQDN, and must be issued by the CA that issued all the other
RTC certificates.
Table 6: MTLS Certificate
Version V3
Template Duplicated Web Server
EKU Server Authentication (1.3.6.1.5.5.7.3.1)
Private Key Enabled for Export
Key Usage Digital Signature, Key Encipherment (a0)
Planning for HTTPS Certificates

The HTTPS certificate is used to authenticate users accessing the Communicator Web Access
virtual server by a specific URL, which the user enters in the browser. The URL that the user
enters can be affected by:
• The Communicator Web Access virtual server machine FQDN
• Load balancing two or more Communicator Web Access virtual server machines
• Web publishing the virtual server, enabled for custom authentication, using ISA Server 2006
or any other reverse proxy using SSL.
Table 7: HTTPS Certificate
Version V3
Template Duplicated Web Server
EKU Server Authentication (1.3.6.1.5.5.7.3.1)
Private Key Enabled for Export
Key Usage Digital Signature, Key Encipherment (a0)
The following table summarizes the FQDN of the HTTPS certificate in each case:
Table 8: Certificate Requirements

Scenario Certificate FQDN
1 Single Communicator FQDN: machine1.contoso.com
Web Access virtual User enters: https://machine1.contoso.com
server on a
machine named:
machine1.contoso.co
m
No SSO or SSL Web
publishing
No load balancing
with a VIP
2 Two or more Each Communicator Web Access machine behind
Communicator Web the load balancer has an HTTPS cert with an
Access servers behind FQDN of cwaVIP.contoso.com regardless of the
a load balancer with a machine name
VIP of: User enters https://cwaVIP.contoso.com
cwaVIP.contoso.com
No SSO or SSL Web
publishing
VIP of: The reverse proxy external network listener
cwaVIP.contoso.com certificate is configured with an FQDN of:
The VIP is SSL Web cwaPub.contoso.com
published with a User enters https://cwaPub.contoso.com
reverse proxy using
the URL of:
cwaPub.contoso.com
VIP of: The reverse proxy external network listener
cwaVIP.contoso.com certificate is configured with an FQDN of:
The VIP is SSL Web cwaPub.contoso.com
published with a User enters https://cwaPub.contoso.com
reverse proxy using
the URL of:
cwaPub.contoso.com
For information about setting a Subject Alternative Name, see Microsoft Office Communications
Server 2007 Certificate Configuration at:
719CE6EC4E5A&displaylang=en
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:
http://support.microsoft.com/default.aspx?scid=kb;en-us;887490.
Planning for Office Communications Server 2007 Certificates

Microsoft Office Communications Server 2007, which is required for Communicator Web Access
(2007 release), requires certificates. For more information about Office Communications Server
2007 certificates, see the Office Communications Server 2007 Certificate Configuration at
Planning for Hardware Load Balancing Certificates

For information about certificate requirements for your load balancer hardware, contact the
manufacturer.
Planning for Remote User Certificates

You can configure ISA Server 2006:
• As a reverse proxy to Web publish the virtual server using SSL.
• As a Firewall
In all of the above cases, certificates are required on the ISA Server 2006 computer.
You can publish the Communicator Web Access (2007 release) virtual server by using ISA Server
2006 to provide remote users with access to Communicator Web Access. The recommended and
only supported ISA configuration has at least two network adapters, one at the internal edge and
one at the external edge. This is an Office Communications Server requirement, not an ISA
requirement. 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 Web listener for the external edge network
adapter on the ISA Server 2006 computer. For details about certificate requirements and
procedures, see “Digital Certificates for ISA Server 2004” at
http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/digitalcertificates.mspx.
Note
ISA is not required. You can use any reverse proxy.
Understanding 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 Office Communications Server 2007.
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 Office Communications Server
2007. If the user is outside the corporate network, Communicator Web Access also confirms that
the user has been granted remote access to Office Communications Server 2007.
Authorization
Authorization checks the enhanced presence (EP) flag in the ninth bit of ms-RTCOptionFlags in
the User object in the Active Directory. It is either enabled or disabled. If EP is disabled, two
possible scenarios exist; the legacy URL has been set or it hasn’t. If the legacy URL has been set,
the client is notified of the redirect URL, and the client manually forms a logon request to
Communicator Web Access (2005 release), and the client logs on successfully. Otherwise, if the
legacy URL is not set, the client returns the following error:
• Your user account is not yet enabled for Communicator Web Access (2007 release) and there
is no Communicator Web Access (2005 release) server configured.
Authentication
Communicator Web Access (2007 release) requires that internal clients be authenticated by one
of the following methods:
• Forms-based authentication
• Integrated Windows (NTLM/Kerberos) Authentication
• Custom authentication, including SSO
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 (2007 release) 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 is available only to
internal users. Except for remote users, Kerberos is used by default, but you can configure the
server to use only Kerberos. NTLM is used when computers are not domain members, or when
Kerberos is not available.
Custom Authentication, Including SSO
See the Office Communicator Web Access (2007 release) Authentication Guide.
Note
If Internet Explorer users are challenged for their credentials
when signing in to Communicator Web Access (2007 release)
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 (2007 release) site (for example,
im.contoso.com).
Quick Sign-In Using a Single URL

When using Integrated Windows authentication, Communicator Web Access users can
authenticate using Quick Sign-in. For example, with Quick Sign-in, a user can enter the
following URI to access Communicator Web Access:
• https://server.contoso.com/quicksignin
The following two settings in the Internet Explorer browser are required:
• The Automatic logon only in Intranet zone radio button must be selected on the Security
Settings – Local Intranet Zone page
• The Communicator Web Access server URL must be added to the Local Intranet zone.
The domain user account that the user is logged on to the local computer is the account that is
used for Quick Sign-In.
When the user is already authenticated through Integrated Windows authentication,
Communicator Web Access will open immediately with no further authentication requests. This
is beneficial to frequent users that bookmark Communicator Web Access as
https://server.contoso.com/quicksignin. Selecting the bookmark enables the user to sign-in
without providing credentials, thereby providing a better user experience.
For remote users, and supported browsers that don’t support Integrated Windows authentication,
the forms-based authentication window will appear.
Quick Sign-in does not work with forms-based authentication.
Note
Using these URIs to code quick sign-in from other Web
applications is not a supported scenario and may result in
unexpected behavior.
Allowing Pop-up Blockers

The Communicator Web Access (2007 release) 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.
Accepting Cookies
Cookies are issued to the client by the Communicator Web Access (2007 release) 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.
Understanding Custom Authentication, Including Single Sign-on

See the Office Communicator Web Access (2007 release) Authentication Guide.
Planning for Capacity Requirements

Load balancing two or more Communicator Web Access (2007 release) servers can be used to
increase capacity. Using this method, you can add additional Communicator Web Access servers
to an existing deployment without interrupting service to users. You can also remove
Communicator Web Access servers from an existing deployment without interrupting service to
users. 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, growth, and consolidation.
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 the Load Balancing section in this document. Also
see the Load Balancing section in the Office Communications Server 2007 Planning and
Deployment Guide.
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 (2007 release) 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 2005 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 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
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/2a4d9385-
8cf8-4482-83d8-fa0adb8ffd96.mspx.
• Adjusting the IIS 6.0 user limit – By default, IIS 6.0 has a limit of 8,000 connections. This
setting is configurable in the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
To increase the limit, create a DWORD entry named "MaxConnections" in this location and
set an appropriate limit, allowing for a reasonable tolerance for peak periods. For example, if
you want to allow 10,000 connections, you would probably set the value at double this
number (20,000).
Important
Do not set this registry key to an unusually large number. The
connection queue is maintained in the system kernel, which
could run out of kernel memory if the queue becomes too
large.
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 (2007 release) 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 (2007 release) is
handled by Office Communications Server 2007. Static data, such as contact lists and ACLs
(access control lists), are stored as persistent data on the Office Communications Server
2007 Back-End Database. To increase the back-end storage capacity, follow the guidelines
and procedures for Office Communications Server 2007. For more information, see the
Microsoft Office Communications Server 2007 Enterprise Edition Deployment Guide, which
is available from the Live Communications Server Deployment Resources page at
Planning for Performance Requirements

This section discusses ways in which you can improve the performance and reliability of a
Communicator Web Access (2007 release) deployment.
Planning for Network Performance Requirements
Communicator Web Access performance depends upon network performance. Network
performance 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.
Using Typical Performance Metrics for Planning

The next table lists capacity performance numbers.
Table 9: Performance Metrics
Criteria Minimum
No. of endpoints per server 6000
No. of contacts per user 50
Hours logged on per user per day 12
Presence updates per user per day 80
IM conversations per user per day 24

No. of messages per session 10
No. of contacts per user within the same pool 100%
Percentage mix of LCS clients 0%
Logins in 8 hours 2
IM sessions per hour 2
Average duration of IMs session 5 min
No. of INFOs per session (is-typing) 10
Percentage of sessions that are Multiparty 10%
No. of participants in a multiparty session 2
No. of watchers per user (same as no. of contacts) 30
User search per day 6
User search results requiring GetPresence 2
memory % used 36%
System processor % used 6.62%
w3wp.exe CPU % used 40%
Planning for High Availability

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 (2007
release) deployment, including failover mechanisms and load balancing. To plan a highly
available network, you must consider more than just Communicator Web Access (2007 release).
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,
Office Communications Server 2007, and common language runtime 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
http://technet2.microsoft.com/windowsserver/en/library//45b2d082-234c-466b-9a41-
7862f72a22881033.mspx
Understanding Failover
This section describes some of the failover mechanisms in Communicator Web Access (2007
release) 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
Communicator Web Access (2007 release) 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.
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 Communicator Web Access (2007 release) 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 Office Communications Server 2007 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
• Office Communications Server 2007 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 (2007 release) 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, a cold restart of the Communicator Web Access is required. This restart, which is
independent of the order in which other components start, provides a stable and predictable
initialization of the Communicator Web Access server or array.
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.
Planning for 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. The following figure shows the reference Load Balancing architecture.
Figure 8: Load Balancing Topology
Load balancing can be required for the following reasons:

• Size of deployment: If the deployment requires more capacity than one Communicator Web
Access (2007 release) 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 (2007 release) is mission-critical for your
organization, the loss of Communicator 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
Office Communications Server 2007 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 (2007 release) requires affinity.
Communicator Web Access supports any load balancer that provides HTTP or HTTPS client
affinity. Communicator Web Access (2007 release) 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 (2007 release) server
pool and users are disconnected.
HTTPS and HTTP traffic between client and Communicator Web Access server is routed through
the load balancer, as is SIP traffic between the Office Communications Server 2007 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.
Note
You can deploy Communicator Web Access (2007 release) on
either side of your hardware load balancer. Connections
between Communicator Web Access (2007 release) and Office
Communications Server 2007 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
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/fd23047
b-2b5a-42b3-aa14-2b7c1cd4be81.mspx
• The TCP/IP Technical Reference at
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/58511c
7c-fb5c-4186-aa69-6f598d59a973.mspx
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.
Note
Multihomed network adapters or multiple network adapters,
each with a different IP address, are not supported for load
balancing in Communicator Web Access (2007 release).
The next table describes supported load balancing configurations for Communicator Web Access
(2007 release):
Table 10: 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
• One arm and one IP subnet
Direct Server Return • One arm and one IP subnet
• Two arms and one IP subnet
Unsupported Load Balancing Configurations

The following load balancing configurations are not supported for Communicator Web Access
(2007 release):
• 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 (2007 release) 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 (2007 release) 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 (2007 release) servers must have Active Directory access.
• The administrative computer must be able to connect directly to each Communicator Web
Access (2007 release) server behind the load balancer without going through the load
balancer.
• Each Communicator Web Access (2007 release) server behind the Load Balancer must be
able to connect with the Office Communications Server 2007 (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 (2007 release) 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.
Planning for Disaster Recovery

Before you deploy Communicator Web Access (2007 release) 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 Office Communications Server 2007, 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 (2007 release). You can use the Import/Export feature
within Communicator Web Access Manager (2007 release) 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.
Planning for a 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.
Deploying Communicator
Web Access
Communicator Web Access (2007 release) can be deployed in two authentication modes:
• Built-in authentication
• Custom authentication
For the public beta, this Planning and Deployment Guide describes deploying Communicator
Web Access using built-in authentication. For a discussion of custom authentication, see the
Communicator Web Access (2007 release, Public Beta) Authentication Guide.
Deploying Servers for Internal Users

The Communicator Web Access (2007 release) deployment process can be organized into the
following categories:
• Overview
• Prepare the server
• Install Communicator Web Access (2007 release)
• Post-Installation Configuration
Communicator Web Access Setup Overview

Communicator Web Access (2007 release) can be deployed to your existing infrastructure if it
meets the requirements described in the Communicator Web Access (2007 release) Requirements
section in this guide.
Deploying Communicator Web Access on a server involves preparation, installation, and post-
installation configuration procedures. The next table provides an overview of the required steps.
Detailed instructions are provided following the table.
Table 11: Communicator Web Access (2007 release) Setup Overview

Phase Steps
Preparation 1. Install Windows Server 2003 SP1 and apply the latest
service pack and updates.
2. Add the server to an Active Directory domain.
3. Install IIS 6.0.
4. Install .NET Framework 2.0.
5. 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.
6. If necessary, install the CA’s certificate chain in the
Trusted Root Certification Authorities node in the
certificate store for the local computer.
Installing 1. Log on to the server with an account that is a member of
Communicator Web the Administrators, DomainAdmins, and
Access (2007 RTCUniversalServerAdmins groups.
release) 2. Open the 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.
3. Create additional virtual servers, as necessary.
Post-Installation 1. In Active Directory, configure user accounts by enabling
Configuration of them for Live Communications, entering SIP names, and
Clients to Sign-In to enabling remote user access.
Communicator Web 2. Sign in to Communicator Web Access using the URI
Access (2007 https://<server_ FQDN>
release)
Preparation
This section describes how to prepare the server for Communicator Web Access (2007 release)
installation and request the required certificates.
Preparing the Server for Installation

Your environment must meet the requirements described in the Communicator Web Access (2007
release) Requirements section in this guide. To prepare the server for Communicator Web server,
you must perform the following steps before running the Deployment Tool.
To prepare the server for Communicator Web Access installation
1. Install Windows Server 2003 on the Communicator Web Access (2007 release) 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 Office Communications Server 2007.
3. Install NET Framework 2.0 on the Communicator Web Access (2007 release) server.
4. Install IIS 6.0 on the Communicator Web Access (2007 release) server
5. Configure a static IP address (optional) and name resolution on the Communicator Web
Access (2007 release) server.
6. Request and install the following certificates in the certificate store of the local computer:
a. An MTLS certificate that specifies the FQDN of the Communicator Web Access (2007 release)
server as the common name.
b. A Web Server certificate for HTTPS. For details, see Planning Certificates in this document.
7. 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 (2007 release) 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 the
Planning Certificates section in this document.
The steps below describe how to download and trust the certificate chain from the Windows
Server 2003 SP1 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.
Download and Trust the Certificate Chain from the Certification
Authority
If you are using Microsoft Windows Server 2003 SP1 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
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pki
bp.mspx.
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.
It is recommended 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.
Configure a Windows Server 2003 SP1 Enterprise Root CA
Install certificate services and configure the server as an Enterprise Root Certification Authority.
To install certificate services and configure the server as an Enterprise
root CA
1. Click Start, point to Settings, click Control Panel, and then click Add or Remove
Programs.
2. Click Add or Remove Windows Components.
3. In the Windows Components Wizard, click Certificate Services.
4. On the Microsoft Certificate Services page, click Yes, and then click Next.
5. On the CA Type page, click Enterprise root CA, and then click Next.
6. On the CA Identifying Information page, in the Common name for this CA box, type
<server_name>, and then click Next.
7. On the Certificate Database Settings page, click Next.
8. If prompted, type the full path to the Windows Server 2003 installation folder or CD, and
then click Continue.
9. In the Microsoft Certificate Services message, click Yes to allow IIS to be temporarily
stopped.
10. In the Microsoft Certificate Services message, click Yes to enable ASP and IIS.
After you have installed Microsoft Certificate Services, prepare the CA for issuing certificates by
duplicating the Web server certificate template. During this procedure, you must grant Enroll and
Auto enroll permissions for the following groups in all domains: AuthenticatedUsers,
DomainAdmins, DomainComputers, and EnterpriseAdmins. You must also enable the Mark keys
as exportable during the Web server template duplication. See the Office Communications Server
2007, Standard Edition Quick Start for the procedure how to do this.
Caution
The certificates for both Office Communications Server 2007
Standard Edition and Communicator Web Access (2007
release) must be issued from the same certification authority
(CA) and must use a duplicated Web server template in which
the Mark keys as exportable option has been enabled.
When using ISA Server 2006 as a reverse proxy, the
certificates required for the ISA Server must also be issued
from the same CA.
Download the CA certificate chain

If you have set up a Windows Server 2003 SP1 CA and have enabled autoenrollment, member
servers will receive the enterprise CA certificate chain when the computer is added to the
domain.
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 http://<CA_server_name>/certsrv,
and then click OK. If the CA uses a port other than the default (port 80), type
http://<computer_name>[:<port_number>]/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:
• <name of enterprise root CA> certificate
• <name of enterprise subordinate CA> certificate
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.
Request and install the MTLS Certificate

This section describes requesting and installing the MTLS certificate.
To request the MTLS certificate
1. On the Communicator Web Access server, open a Web browser. In the Address box, type
http://<CA_FQDN>/certsrv, 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 the Certificate Template list, select the name of the duplicated Web Server template that
you duplicated for the Office Communications Server 2007 certificates.
6. In the Identifying Information for Offline Template box, type the FQDN.
7. The Mark keys as exportable check box must be checked, which is the default for the
duplicated Web Server template. Do not proceed unless this check box is selected. If the
check box is cleared and is unavailable, you have not duplicated the web server template.
You must do this before continuing.
8. In the Key Options area, select the Store certificate in the local computer certificate store
check box.
9. Click Submit.
10. If a potential scripting violation warning appears, and you understand and accept the
implications, click Yes.
Now that you have requested the certificate, you can install it.
To install the certificate on the computer
1. Click Install this certificate. If a potential scripting violation warning appears, and you
understand and accept the implications, click Yes.
2. Click Start, click Run, 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, click Certificates.
6. Click Add.
7. Click Computer account, and then click Next.
8. In the Select Computer dialog box, ensure that the Local computer: (the computer this
console is running on) check box 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 just requested and installed is located in this folder. If it
is not, copy it from the Certificates folder under the Personal folder node, just above.
Request and install the HTTPS Certificate

Repeat the procedure for the MTLS certificate, substituting the FQDN for the HTTPS certificate
if it is different than the MTLS certificate. They might or might not be the same, depending upon
your deployment configuration.
Installing Communicator Web Access

This section provides the procedures to install the Communicator Web Access (2007 release)
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
(2007 release). Creating the first virtual server from the MMC Create Web Access Server
wizard, it is recommended that you create the first virtual server using the Deployment Tools
Step 3: Create a Virtual Server.
4. (Optional) Install Communicator Web Access Manager (2007 release) administrative
snap-in. By default, Communicator Web Access Manager (2007 release) is installed on the
computer in the first step. You can use this option later to add Communicator Web Access
Manager (2007 release) 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 Cwamain.msi [/lv <log_file_name>.txt]
• Runas.exe /user:<domain\admin> "Msiexec.exe /I <full path to .msi>"
Note
If you want to install Communicator Web Access (2007
release) on a computer on which Communicator Web Access
Manager (2007 release) is already installed, you must first
remove Communicator Web Access Manager (2007 release).
Installing Communicator Web Access by Using the

Deployment Tools
To install Microsoft Office Communicator Web Access on a server, you must have deployed
Office Communications Server 2007. During installation of Communicator Web Access, you will
be asked to select the Communicator Web Access IIS and MTLS certificates.
Install and Configure Communicator Web Access

Installing and configuring Communicator Web Access involves the following procedures:
1. Install Communicator Web Access (2007 release).
2. Activate the Communicator Web Access server.
3. Create the Communicator Web Access IIS virtual server.
To install Communicator Web Access on webserver3.contoso.com

1. Log on to webserver3.contoso.com as a member of the Administrators group.
2. From the Office Communications Server 2007 installation media, double-click SetupSE.exe
or SetupEE.exe
3. On the Office Communications Server 2007 Deployment page, either Standard Edition or
Enterprise Edition, click Deploy Other Server Roles.
4. On the Deploy Other Server Roles page, click Deploy Communicator Web Access
Server.
5. On the Deploy Microsoft Office Communicator Web Access page, under Step 1: Install
Communicator Web Access, click Install.
6. On the Welcome page, click Next.

7. On the License Agreement page, click I accept, and then click Next.
8. On the Customer Information page, in User Name and Organization, type a name and
organization, and then click Next.
9. On the Ready to install page, accept the default location, and then click Next.
10. On the Ready to install page, click Install.
11. On the Setup complete page, click Finish.
Do not close the window. Continue directly with the next procedure.
To Activate the Communicator Web Access Server
Note
Activating the server creates the account CWAService in
Active Directory.
1. Under Step 2: Activate Communicator Web Access, click Activate.

3. On the Select domain service account page, accept the default Account name, in the
Password box and the Confirm password box, create and type identically, a strong
password to be used for the account, and then click Next.
4. On the Select Server Certificate page, click Select Certificate.
5. On the Select Certificate page, in the Issued to column, click webserver3.contoso.com.
6. On the Select Server Certificate page, click Next. Verify that the Issued to box contains
CN=<FQDN>.
7. On the Ready to activate Communicator Web Access page, click Next.
8. On the Success page, click Finish.
Do not close the window. Continue directly with the next procedure.
To create the Communicator Web Access IIS virtual server
Note
The first virtual server is created during this step. You can
create additional virtual server in Communicator Web Access
Manager (2007 release).
1. Under Step 3: Create a Virtual Server, click Create.

3. On the Select Virtual Server Type page, click Internal, and then click Next.
4. On the Select Authentication Type page, accept Use built-in authentication and click
Next.
5. On the Select authentication method page, click Next.
6. On the Select Browser Connection Type, accept the default of HTTPS (recommended),
and then click Select Certificate.
7. On the Select Certificate page, click the certificate with the FQDN of
webserver3.contoso.com, and then click OK.
8. On the Select Browser Connection Type page, click Next.
9. On the Select IP address and port setting page, accept all defaults, and then click Next.
10. On the Name the Virtual Server page, accept the default name Communicator Web Access
and then click Next.
11. On the Automatically Start Virtual Server page, accept the default and then click Next.
12. On the Review Settings … page, click Next.
Performing Post-Installation Configuration

This section describes post-installation configuration tasks.
Manually Installing Communicator Web Access Manager (2007
release) (Optional)
Communicator Web Access Manager (2007 release) is automatically installed on the server when
you install Communicator Web Access (2007 release). If you are installing the Communicator
Web Access server components, 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 (2007 release) on a
remote computer, from which you can manage the Communicator Web Access server. For
information about installing Communicator Web Access Manager (2007 release) on a remote
computer, see the Managing the Communicator Web Access Server section in this document. You
can install the 2007 release Manager snap-in on the same computer as the 2005 release Manager
snap-in, but the operating system must meet the 2007 release minimum requirements.
Note
If you install Communicator Web Access Manager (2007
release) on a computer and then later want to install
Communicator Web Access (2007 release) on the same
computer, you must first remove Communicator Web Access
Manager (2007 release).
Creating Additional Virtual Servers

Additional Communicator Web Access (2007 release) virtual servers after the initial virtual
server that was created during setup are created using a wizard launched from the Communicator
Web Access Manager (2007 release). While it is possible to create the initial virtual server from
the MMC instead of from the Deployment tool, it is not recommended. The next procedure is
given for adding and Web publishing an additional external virtual server. A reverse proxy must
be deployed, and this procedure describes deploying ISA Server 2006 as the reverse proxy. A
Web listener handles all traffic before reaching the Communicator Web Access virtual server.
Users must enter the exact URL configured in ISA Server 2006 to be routed to the Communicator
Web Access (2007 release) virtual server. The user then must enter domain credentials to access
the site.
To create an additional Communicator Web Access (2007 release)
external virtual server
1. Click Start, point to All Programs, point to Administrative Tools, and then click Office
Communications Server 2007 Public Beta, Communicator Web Access Manager.
2. In the scope pane, right-click the server FQDN node, and then click Create Web Access
Server.
4. On the Select Virtual Server Type page, click External, and then click Next.
5. On Select Authentication Type, select Use built-in authentication, and click Next.
6. On the Select Authentication Type page, click Next.

7. On the Select Connection Type page, click HTTPS (recommended), and then click Select
Certificate.
8. On the Select Certificate page, select the certificate, and then click OK.
9. On the Select Connection Type page, click Next.

10. On the Select IP Address and Port Settings page, in Port for this Communicator Web
Access Virtual Server, type 444. This port number must be different from the port number
(443) used for any other applications; otherwise, an IP address conflict will occur. Click
Next.
11. On the Server Description page, type cwaExternal, and then click Next.
12. On the Start Server Option page, click Next.
13. On the Review Settings before Virtual Server Creation page, click Next.

15. In the scope pane of the Microsoft Office Communicator Web Access Manager (2007
release), the cwaExternal node has been added
Installing Communicator Web Access by Using the Command

Line
The Communicator Web Access (2007 release) 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.
• Cwammc.msi. Installs Communicator Web Access Manager (2007 release). This installation
is not necessary if you have already installed the Communicator Web Access program files
on the server.
Note
Communicator Web Access (2007 release) does not support
silent installation.
To install Communicator Web Access at a command prompt

1. Open a command prompt window: Click Start, and then click Run.
2. In the Open box, type cmd, and then click OK.
3. At the command prompt, type the following, and then press ENTER:
cd <setup path>\i386\MSI
4. 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 cwamain.msi [/lv <log_file_name>.txt]
Deploying Servers for Remote User

Access
Remote users should access Communicator Web Access (2007 release) using a virtual server for
which External has been selected on the Select Virtual Server Type page of the Create Virtual
Server Wizard. External virtual servers using built-in authentication must use forms-based
authentication, and the configurable time-outs for private and public computers are enabled.
While making the external virtual server directly accessible to remote users is supported, it is
strongly recommended that a reverse proxy, such as ISA Server be used to Web publish the
external virtual server using SSL. Any reverse proxy can be used, including both ISA Server
2004 SP1 and ISA Server 2006 (recommended).
If you enable single sign-on for the ISA Server 2006 Web listener, you must use Custom
authentication for the Communicator Web Access virtual server authentication type. Regardless
of your choice of reverse proxy, it is recommended that the reverse proxy be a workgroup
member, and not a member server of the internal, trusted domain. However, both configurations
are supported.
Web Publishing the Remote Virtual Server

This section discusses using a reverse proxy to publish the external virtual server.
Using ISA Server 2006

ISA Server 2006 is supported for Web publishing the Communicator Web Access (2007 release)
virtual server, using SSL (secure socket layer). Only ISA Server 2006 is supported for providing
SSO when the virtual server being published uses custom authentication.
Caution
ISA Server 2006 with SSO enabled on the ISA Server 2006
Web listener, and publishing a virtual server enabled for
custom authentication is the only supported SSO
configuration. Additionally, ISA Server 2006 must be
configured for SSL on the external site. HTTP is not supported.
Using ISA Server 2004 SP1 to Web Publish - Without SSO

Enabled
ISA Server 2004 with SP1 is also supported for Web publishing the Communicator Web Access
(2007 release) virtual server using SSL when SSO is not required. Any reverse proxy server can
be used to Web publish a Communicator Web Access (2007 release) virtual server using SSL, for
when SSO is not required.
For the procedure to Web publish a Communicator Web Access (2007 release) virtual server
using ISA Server 2004 SP1, see the Communicator Web Access (2005 release) Quick Start at:
http://office.microsoft.com/en-us/assistance/HA100240791033.aspx
Using ISA Server 2006 to Web Publish - Without SSO Enabled

This section explains how to configure Microsoft Internet Security and Acceleration (ISA) Server
2006 to Web publish a Communicator Web Access (2007 release) virtual server using SSL.
Regardless of your choice of reverse proxy, the only supported configuration is using SSL on the
reverse proxy to publish the external site using HTTPS. HTTP is not supported for the external
site.
Figure 9: Web Publishing Communicator Web Access Using ISA Server
2006
ISA Server 2006 can be used as an alternative to, or in conjunction with, a VPN in your
deployment of Office Communications Server 2007 and Communicator Web Access (2007
release). You can use ISA Server to provide perimeter network and internal network boundaries.
You can also use ISA Server to publish one or more Communicator Web Access (2007 release)
servers using ISA Server 2006. ISA Server 2006 Standard Edition and Enterprise Edition are both
supported.
Note
When publishing a Web site, you can either reference the
internal Web server with an FQDN, host name, or IP address. If
the ISA Server will communicate with the internal Web server
over HTTPS, then you need to use the FQDN that matches the
common name in the certificate installed on the internal
server, or the connection will fail. If the ISA Server cannot
resolve the FQDN, then the IP address or host name must be
specified when configuring ISA Server to publish the Web site.
ISA Server 2006 Prerequisites

The following are required on the ISA 2006 computer:
• Two network adapters on the ISA Server computer, one for the external network and one for
the internal network. This is a Communicator Web Access requirement, not ISA requirement.
• Windows Server 2003 SP1
• ISA Server 2006, Standard Edition or Enterprise Edition
It is recommended that no other software be installed on the ISA Server.
Table 12: ISA Server 2006 Requirements
Component Requirement
Operating System Windows Server 2003 SP1
Reverse proxy ISA Server 2006 Standard Edition
software
Hardware
Processor http://www.microsoft.com/technet/isa/2006/installatio
n_se/afdf7384-040e-4813-8e9a-aa05ddb7d4b6.mspx
Networking
Memory
Disk Space
Permissions
To install ISA Membership in Local Administrators
Server 2006
You can get the free, 120 day trial, ISA Server 2006 software at:
http://www.microsoft.com/isaserver/2006/trial-software.mspx
You can get the free, 120 day trial, ISA Server 2004 software at:
http://www.microsoft.com/isaserver/evaluation/trial/default.asp
Deploying ISA Server 2006

This section provides a procedure for using ISA Server 2006 to Web publishing a virtual server in
the following example environment, and assumes all other computers are already deployed
correctly. For details on Web publishing using SSL in a production environment, see:
• https://www.microsoft.com/technet/isa/2006/secure_web_publishing.mspx
Figure 10: Example
Table 13: Example Name Resolution
Name IP Address Subnet Mask

client1.contoso.co 192.168.1.6 255.255.255.0
m
cwa.contoso.com 192.168.1.5 255.255.255.0
“Internet” DNS 192.168.1.x 255.255.255.0
remote.contoso.co N/A N/A
m
isa2006.contoso.c 10.10.10.55 255.255.255.0
om
webserver3.conto 10.10.10.35 255.255.255.0

so.com
contosodc.contoso 10.10.10.1 255.255.255.0
.com
client2.contoso.co 10.10.10.5 255.255.255.0
m
Setting up isa2006.contoso.com and webserver3.contoso.com

For this lab, isa2006.contoso.com will publish the Communicator Web Access (2007 release)
virtual server. To configure isa2006.contoso.com for this role, do the following:
1. Install Windows Server 2003 SP1 on a server with two network adapters, even though ISA
Server 2006 supports a dual-homed, single NIC.
2. Configure a static IP address for each network adapter.
3. Set the interface order.
4. Add each IP address to the respective DNS server.
5. Install ISA Server 2006 Standard Edition.
6. Keep isa2006 in the Workgroup, but set the DNS Suffix and NetBIOS Computer Name to
contoso.com.
7. Configure Certificates for isa2006.contoso.com.
8. Create the external Communicator Web Access (2007 release) virtual server.
9. Configure ISA Server 2006 to publish the virtual server.
10. Specify the LDAP server.
11. Create a Web listener on isa2006.contoso.com.
12. Publish the Communicator Web Access (2007 release) virtual server.
13. Redirect the external traffic to port 444 on the internal network.
14. Prepare the Client to test the deployment.
15. Perform the lab exercises.
The following table summarizes the naming.
Table 14: Naming
Name Description
ISA Server 2006 The reverse proxy that is Web publishing the
Communicator Web Access (2007 release) virtual
server.
cwa.contoso.com The FQDN of the ISA Server external interface
isa2006.contoso.com The FQDN of the ISA Server internal interface
internal The SSO/ISA internal interface
external The SSO/ISA external interface

CWA The internal Communicator Web Access (2007
release) virtual server
cwaExternal The external Communicator Web Access (2007
release) virtual server
isaListener Web listener on ISA Server 2006
externalCWA The Web Publishing Rule on ISA Server 2006 for the
cwaExternal virtual server.
external The LDAP Validation Server Set name
The following sections explain these steps in detail.
Install Windows Server 2003 SP1 on a server with two network adapters
See the Windows Server 2003 SP1 documentation.

Configure Static IP Addresses for isa2006 Network Adapters To distinguish
the two interfaces, this document refers to the two ISA Server 2006 network adapters as the
“internal” network adapter and the “external” network adapter. Connect the internal adapter to
Hub 1, and then connect the external adapter to Hub 2. Configure each adapter with a static IP
address.
To configure the internal network adapter on isa2006 with a static IP
address
1. Click Start, point to Settings, and click Network Connections.
2. Right-click the internal network adapter connection and then click Properties.
3. Click Internet Protocol (TCP/IP), and then click Properties.
4. In the Internet Protocol (TCP/IP) Properties dialog box, click Use the following IP
address:
5. In the IP address box, type 10.10.10.55.
6. In the Subnet mask box, type 255.255.255.0.
7. Click Use the following DNS server addresses.
8. In the Preferred DNS server box, type 10.10.10.1.
9. Click OK twice.
To configure the external network adapter on isa2006 with a static IP
address
2. Right-click the external network adapter connection and then click Properties.
3. Click Internet Protocol (TCP/IP), and then click Properties.
4. In the Internet Protocol (TCP/IP) Properties dialog box, click Use the following IP
address.
5. In the IP address box, type 192.168.1.5.
6. In the Subnet mask box, type 255.255.255.0.
7. Click Use the following DNS server addresses.
8. Enter 192.168.1.x in the Preferred DNS server box.
9. Click OK twice.
Set the isa2006 Interface Order Now set the interface order. Listing the ISA
Server 2006 internal interface first in the list of network connections can improve name
resolution performance. Any failure to resolve names will prevent the Web site from being
published successfully.
To set the interface order
2. On the Advanced menu, click Advanced Settings.
3. Under Connections, click Internal.
4. Click the up arrow to move the internal interface to the top of the list.
5. Click OK.
Add isa2006 Internal IP address to the contosodc.contoso.com DNS Server
Now add the internal interface IP address to the DNS server.

To add the internal IP address to the DNS Server
1. On contosodc.contoso.com, click Start, point to All Programs, point to Administrative
Tools, and then double-click DNS.
2. In the console tree, expand Forward Lookup Zones.
3. Right-click the contosodc.contoso.com node, and then click Properties.
4. In the contosodc.contoso.com Properties dialog box, select the Named Servers tab, and
then click Add.
5. In the New Resource Record dialog box, in the Server FQDN box, type
isa2006.contoso.com.
6. In the IP address box, type 10.10.10.55. Click Add, and then click OK.
7. In the console tree, expand Reverse Lookup Zones.
8. Right-click the 10.10.10.in-addr.arpa node and then click Properties.
9. In the 10.10.10.in-addr.arpa Properties dialog box, click the Named Servers tab, and then
click Add.
10. In the New Resource Record dialog box, in the Server FQDN box, type
isa2006.contoso.com.
11. In the IP address box, type 10.10.10.55. Click Add, click OK, and then click Apply.
12. Click OK.
13. Close the DNS console.
Add isa2006 external IP address to the “Internet” DNS Server Now add the
ISA Server 2006 external interface IP address to the “Internet” DNS server.
To add the external IP address to the “Internet” DNS Server
1. On the Internet DNS Server, click Start, point to All Programs, point to Administrative
Tools, and then click DNS.
2. In the console tree, expand Forward Lookup Zones.
3. Right-click the remote.contoso.com node and then click Properties.
4. In the remote.contoso.com Properties dialog box, select the Named Servers tab, and then
click Add.
5. In the New Resource Record dialog box, in the Server FQDN box, type cwa.contoso.com.
This will be the URL used by external users to access the Web published Communicator
Web Access (2007 release) external virtual server.
6. In the IP address box, type 192.168.1.5. Click Add, and then click OK.
7. In the console tree, expand Reverse Lookup Zones.
8. Right-click the 1.168.192.in-addr.arpa node, and then click Properties.
9. In the 1.168.192.in-addr.arpa Properties dialog box, click the Named Servers tab, and
then click Add.
10. In the New Resource Record dialog box, in the Server FQDN box, type cwa.contoso.com.
11. In the IP address box, type 192.168.1.5. Click Add, click OK, and then click Apply.
12. Click OK.
13. Close the DNS console.
Install ISA Server 2006 Standard Edition Install ISA Server 2006 Standard
Edition. You can get a free 180 day trial of ISA Server 2006 from:
http://www.microsoft.com/isaserver/2006/trial-software.mspx.
To install ISA Server 2006 for this lab
1. Double-click Isaautorun.exe.
2. On the splash screen, click Install ISA Server 2006
3. On the Welcome page, click Next
4. On the License Agreement page, select I accept, and then click Next.
5. On the Customer Information page, enter User Name, Organization, and Product Serial
Number, and click Next.
6. On the Setup Type page, select Typical, and click Next.
7. On the Internal Network page, click Add.

8. On the Addresses page, click Add Adapter.
9. On the Select Network Adapters page, select the adapter connected to the trusted network
hub, click OK twice, and then click Next back on the Internal Network page.
10. On the Firewall Client Connections page, accept the default, and then click Next.
11. On the Services Warning page, click Next.
12. On the Ready to Install the Program page, click Install.
13. On the Installation Wizard Completed page click Finish.
Keep isa2006 in the Workgroup Keep isa2006 in the Workgroup. However, even
though isa2006 is not a member server of contoso.com, the IP address of both network interface
cards must have the connection-specific DNS suffix of contoso.com. You do this from the
Properties page of each network interface and from the DNS Suffix and NetBIOS computer
name page of My Computer.
Configure Certificates on the ISA Server You must request an SSL certificate and
download the CA certificate chain to the Trusted Root Certification Authorities, Certificates
folder for the external ISA Server 2006 server interface. This interface (the cwaExternal
interface) certificate for this lab example should have an FQDN of cwa.contoso.com.
When creating the Web listener in ISA Server 2006, you will assign an IP address on which the
Web listener will listen for traffic. You will also bind an SSL certificate to the Web listener for the
virtual server accessed by that Web publishing rule. Using a certificate issued from a public CA is
recommended for binding to the Web listener. If you use a certificate issued from a private CA,
you will need to install the Root CA certificate for the private CA on the ISA Server.
Important
The certificates must be issued from the same CA as the
certificates used for the Communicator Web Access (2007
release) server and the Office Communications Server 2007
server, and must use a duplicated Web server template. A
certificate issued from a public CA is recommended.
For details about certificate requirements and procedures, see “Digital Certificates for ISA Server
2004” at: http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/digitalcertificates.mspx
Create the Communicator Web Access external Virtual Server Now create
the virtual server, cwaExternal that will handle external user traffic. This is the Communicator
Web Access (2007 release) virtual server that will be Web published by ISA Server 2006. See the
Creating Additional Virtual Servers procedure in this guide.
Figure 11: cwaExternal Virtual Server
Configure the ISA Server 2006 server to publish the external virtual server
You must now configure ISA Server 2006 to Web publish the Communicator Web Access virtual
server.
First, specify the LDAP verification server. Then, configure the Web listener on ISA Server 2006.
Finally, publish the Communicator Web Access virtual server.
Specify the LDAP Verification Server You must specify the set of LDAP servers
that ISA will use to validate users. You can do this prior to creating the Web listener (the next
step) or you can do it during the step to create the Web listener. Regardless of when you specify
the LDAP servers, the process includes creating a User Set to which you can add only the users
and groups to the LDAP User Set that require authentication by the LDAP validation Server.
For example, you could create a group in Active Directory called remoteCWAusers, and then add
this group to the LDAP User Set that you create. To the remoteCWAusers group, add only users
that require external access to the published Communicator Web Access Web site, and which are
the only users authenticated on the LDAP validation server. When users no longer have the need,
remove them from the remoteCWAusers in Active Directory.
Prior to creating the Web listener, you can specify the LDAP server or servers that will validate
users from the General node in the scope pane of the ISA Server 2006 Management console, seen
in the next figure. Click the Specify RADIUS and LDAP Servers in the result pane to display the
RADIUS and LDAP Server configuration tabs.
Figure 12: Specify RADIUS and LDAP Servers on General Tab
If you choose to specify the LDAP server during the Web listener creation step, which is the next
step, you will get a wizard page on which you can do this. In either case, for details on how to
specify the LDAP server, see the Secure Application Publishing paper at:
https://www.microsoft.com/technet/isa/2006/secure_web_publishing.mspx.
Create the Web Listener Now let’s create the Web listener that listens on the external
network interface card, and name it isaListener.
To create the Web listener
1. On isa2006.contoso.com, open the ISA Server snap-in by clicking Start and pointing to
Programs, pointing to Microsoft ISA Server, and clicking ISA Server Management.
2. On the Firewall Policy (default) result pane, on the Toolbox tab on the right side of the
result pane, select Network Objects, click New, and click Web Listener.
3. On the Welcome page, enter isaListener in the Web listener name text box, and click Next.
4. On the Client Connection Security page, accept the default Require SSL and click Next.
5. On the Web Listener IP Addresses page, select External in the list box, and click Next.
6. On the External Network Listener IP Selection page, select Specified IP addresses on the
ISA Server computer in the selected network.
7. Select the item in the Available IP Addresses box.
8. Click Add, and then click OK.
9. On the Web Listener IP Addresses, click Next.

10. On the Listener SSL Certificates page, click Select Certificate.
11. On the Select Certificate page, select the certificate you created for the isaListener Web
Listener. This certificate should have the FQDN of the URL used to access the isaListener
Web listener; in this case, cwa.contoso.com. Click Select.
12. On the Listener SSL Certificates page, click Next.

13. On the Authentication Settings page, select HTML Form Authentication, select LDAP
(Active Directory), and click Next. You will configure the validation server in another task.
14. On the Single Sign On Settings page, clear the Enable SSO check box and click Next.
15. If you have not configured the LDAP Verification server before creating the Web listener,
you will get the LDAP Verification server configuration page now. If you have already
configured the LDAP Verification server, you will get the Completing the New Web
Listener Wizard page, on which you should click Finish.
16. In the ISA MMC Firewall Policy result pane, click Apply.
17. On the Saving Configuration Changes page click OK.
18. In the ISA Server snap-in, in the scope pane, right-click the Server node, and then click
Refresh.
Publish the Communicator Web Access cwaExternal virtual server Use the
following procedure to create an SSL (Secure Sockets Layer) Web publishing rule for the
Communicator Web Access cwaExternal virtual server, and then attach the listener to that
publishing rule.
To publish the Communicator Web Access cwaExternal site

1. Click the Firewall Policy node in the scope pane of the ISA snap-in. Click the Tasks tab,
and then click Publish Web Sites.
2. On the Welcome page in the Web publishing rule name text box, type externalCWA, and
then click Next.
3. On the Select Rule Action page, click Allow, and then click Next.
4. On the Publishing Type page, accept the single web site default, and then click Next.
5. On the Server Connection Security page, select the Use SSL to connect to the published
web server or server farm check box, and then click Next.
6. On the Internal Publishing Details page, in the Internal site name box, type the name of
the internal site (webserver3.contoso.com). If needed, specify the Computer name or IP
address box by checking the box and typing webserver3.contoso.com, and click Next.
7. On the next page, also titled Internal Publishing Details, click Next.
8. On the Public Name Details page, in the Public name box, type cwa.contoso.com, and
then click Next.
9. On the Select Web Listener page, in the Web listener list, click isaListener, and then click
Next.
10. On the Authentication Delegation page, click Basic authentication in the list, and then
click Next.
11. On the User Sets page, click Next.

12. On the Completing the New Web Publishing Rule Wizard page, click Finish.
13. Click Apply, click OK, and then refresh the ISA server node in the snap-in. To refresh the
ISA server node, right-click the server node in the scope pane, and then click Refresh.
Configure ISA Server to redirect external traffic to internal port 444 Now
configure ISA Server to redirect external traffic, which by ISA default is bound for 443, to the
Communicator Web Access, cwaExternal virtual server that is running on port 444 on
webserver3.contoso.com.
To configure ISA to redirect https://cwa.contoso.com requests to port
444
1. In the ISA Server Management console tree, click the Firewall Policy node.
2. In the details pane, right-click the externalCWA Web Publishing rule, and then click
Properties.
3. On the externalCWA Properties page, click the Bridging tab.
4. On the Bridging tab, click Web server. Clear the Redirect requests to HTTP port check
box. Click Redirect requests to SSL port, and type 444 in box next to it. You do not need to
select a certificate on this page.
5. Click Apply, and then click OK.
6. On the main ISA management console, click Apply to commit the changes.
7. On the Apply New Configuration confirmation box, click OK.
Test the Deployment

Now let’s test the deployment.
To test the Web published virtual server
1. On client1.contoso.com, enter https://cwa.contoso.com in a supported browser.
2. On the ISA default form, enter credentials for a user enabled for remote Communicator Web
Access.
3. The Communicator Web Access main page displays.
4. Enter the user’s credentials, and then click Sign In.

5. The Communicator Web Access main page appears.
PIC
Complete content for this topic is not yet available.
A PIC user cannot initiate a multiparty conference with an enhanced (Office Communications
Server 2007) user.
Configuring for Capacity and

Availability
This section discusses capacity and high availability.
Increasing Capacity by Adding a Server

You must use a hardware load balancer when two or more Communicator Web Access (2007
release) servers are deployed.
Deploying a Hardware Load Balancer

Content for this topic is not yet available.
Deploying the Additional Server

This section describes deploying an additional server.
To add a Communicator Web Access server
1. Prepare the server hardware.
2. Install the required software.
3. Install Communicator Web Access (2007 release). The snap-in with two servers will look
like the next figure. Keep in mind it is the virtual servers that are being load balanced and
not the physical servers. It is entirely possible and supported that one of the physical servers
might have a virtual server that is not participating in the load balancing. Two internal virtual
servers, each on a different physical server, might be load balanced. But, because of not
much external user access, only one external virtual server is required to handle the external
user traffic. Therefore, load balancing of the external virtual server is not necessary. If one of
the computers hosting one of the load balanced, internal servers has the resources to also
host the external server, then that is also a supported configuration.
4. Configure the virtual IP (VIP) on the load balancer.

5. Test the configuration.
6. Roll out the deployment to production.
Deploying High Availability Solutions

See the Planning for High Availability section earlier in this guide for requirements.
Verifying Successful Load Balancing Configuration The following verifications

should be performed to confirm successful load balancing configuration.
To verify LDAP/DNS traffic
1. Confirm correct LDAP/DNS configuration by performing the following LDAP/DNS
verifications from each Communicator Web Access (2007 release) server behind the load
balancer.
2. Verify that a ping of the domain controller and global catalog server by IP address results in
a successful reply from each.
3. 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.
4. 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.
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.
To verify the configuration
To confirm that the Client HTTP/HTTPS and Office Communications Server 2007 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.
Recovering from a Server Failure

Deploying a Backup Server

Switching to the Backup Server

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.
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 2.0 on the standby server.
4. Obtain the appropriate SSL and MTLS certificates for the standby server.
5. Install Communicator Web Access (2007 release) on the standby server.
6. Activate the server, but do not create a virtual server.
7. Use Communicator Web Access Manager (2007 release) 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 (2007 release) 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.
Management and Operations

This section describes options for managing, configuring, and monitoring Communicator Web
Managing Communicator Web Access Servers

This section explains how to use Communicator Web Access Manager (2007 release) to manage
one or more Communicator Web Access (2007 release) servers from a Communicator Web
Access server or from a remote computer. Connecting to a physical Communicator Web Access
(2007 release) server, displays information about the server, including the number of virtual
servers that it contains, in the details pane of Communicator Web Access Manager (2007 release).
You can use Communicator Web Access Manager (2007 release) to configure the properties of
both physical servers and virtual servers.
From Communicator Web Access Manager (2007 release), 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 (2007 release) setup, Communicator Web Access Manager
(2007 release) 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 Administrative Snap-in. For details about the deployment tools,
see “Installing Communicator Web Access by Using the Deployment Tools” earlier in this guide.
Communicator Web Access Manager (2007 release) will run on any of the following operating
systems:
• Windows XP Professional Edition with Service Pack 2
• Windows Server 2003 SP1, Standard Edition
• Windows Server 2003 SP1, Enterprise Edition
Communicator Web Access Manager (2007 release) 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.
Important
You must install IIS Manager on a remote computer before you
can install Communicator Web Access Manager (2007
release). Only the management components are required; you
do not need to install IIS on the computer. You can use the
Control Panel to install the Internet Information Services Snap-
in (Windows XP) or Internet Information Services Manager
(Windows Server 2003 SP1), or you can download the Internet
Information Services (IIS) 6.0 Manager for Windows XP.
Additionally, the Communicator Web Access server must have
ASP.NET 2.0 installed and registered to be supported for
remote virtual server creation.
To install Communicator Web Access Manager (2007 release) on a

remote computer
1. Log on to the server as a member of the Administrators and the DomainAdmins groups.
2. From the Office Communications Server 2007 installation media, double-click SetupSE.exe
or SetupEE.exe.
3. On the Office Communications Server 2007 Deployment page, either Standard Edition or
Enterprise Edition, click Deploy Other Server Roles.
4. On the Deploy Other Server Roles page, click Deploy Communicator Web Access
Server.
5. On the Deploy Microsoft Office Communicator Web Access page, under Optional:
Install Communicator Web Access Administrative Snap-in, click Install.
7. On the License Agreement page, click I accept the terms in the license agreement, and then
click Next.
8. On the Ready to Install page, accept the default location, or click Change to select an
alternate location, and then click Next.
9. On the Ready to Install page, click Install.
10. On the Setup Complete page, click Finish.
To connect to the Communicator Web Access server
• On the Start menu, point to Programs, click Administrative Tools, and then click Office
Communications Server 2007 Public Beta, Communicator Web Access Manager.
Auto Discovery of Servers
The Communicator Web Access (2007 release) snap-in automatically discovers the
Communicator Web Access (2007 release) servers in the current Active Directory Forest.
The Communicator Web Access Manager (2007 release) snap-in cannot connect to and manage
Communicator Web Access (2005 release) servers.
Scope Pane
The scope pane is the leftmost pane in the last figure.
Result Pane
Each node in the scope pane has its own result pane.
The physical server FQDN node result pane has two tabs:
• Status tab
• Performance tab
Table 15 describes the performance counters.
Table 15: Perf Counters
Perf Counter Description
PERF_AUTH_NUM_SUCCESSFUL_FORMS_L Content for this topic is not yet available.
OGONS_SEC
PERF_AUTH_NUM_SUCCESSFUL_IWA_LOG
ONS_SEC
PERF_SECURITY_NUM_TICKET_CHECK_FAI
LURES_SEC
PERF_AUTH_NUM_THROTTLED_
LOGONS_SEC
PERF_SERVICE_MESSAGE_SENT_FAILURE_
SEC
PERF_SERVICE_MESSAGE_RECEIVED_ SEC
The virtual server node, of which there can be 0 or more of, has one Status tab, and displays the
information seen in the next figure.
Figure 13: Status
Deactivating the Communicator Web Access server Removing Communicator

Web Access (2007 release) by using the Add/Remove Programs in the Control Panel
automatically deactivates the Communicator Web Access (2007 release) server. You can also
deactivate the server prior to installing it.
To Deactivate the Communicator Web Access server
1. Right-click the physical server FQDN node in the scope pane.
2. Select Deactivate.
3. Follow the wizard steps.
Managing Virtual Servers

During installation of Communicator Web Access (2007 release), a Communicator Web Access
(2007 release) 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 the Default
Communicator Web Access IIS 6.0 Settings section of this guide. 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 (2007 release).
Exporting a Configuration File
You can export the settings of a virtual server that you want to duplicate on another server, to a
configuration file saved in XML format. You then import the xml file on the server that will be a
duplicate.
To Export a Configuration file

1. In Communicator Web Access Manager (2007 release), connect to the Communicator Web
Access server with an account that a member of the Administrators and
RTCUniversalServerAdmins 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.
Importing a Configuration File
After Communicator Web Access is installed on the server, you can add virtual servers to the
same Communicator Web Access server by importing the settings from a configuration file of an
existing virtual 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.
To Import a Configuration file
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 (2007 release), 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.
Managing Virtual server properties
When you right-click the Microsoft Office Communicator Web Access server node in the tree
view pane, Communicator Web Access Manager (2007 release) displays a property sheet with
three configuration tabs:
• General
• Authentication
• Connectivity
On the General tab, shown in the figure in step 3 of the next procedure, the Communicator
Web Access (2005 release) URL text box is where the admin specifies the Communicator Web
Access (2005 release) server for Legacy Redirect.
Specifying a Legacy Redirect URL
You can specify a legacy redirect URL from the virtual server Properties page, General tab.
To specify a legacy redirect URL
2. Expand the tree view, right-click the virtual server node and select Properties.
3. On the General tab of the virtual server Properties page, enter the URL in the URL text box,
click Apply, and then click OK.
Changing Authentication Settings

You can change authentication settings from the virtual server Properties page, Authentication
tab. You use the authentication tab to 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. On the Connectivity
tab, when using application isolation, you can configure internal and external users served by two
virtual servers on the same physical server, to use different ports.
To change Authentication settings

2. Expand the tree view, right-click the virtual server node, and then select Properties.
3. On the Properties page, select the Authentication tab.
4. On the Authentication tab of the virtual server Properties page, make authentication
settings changes, click Apply, and then click OK.
Specifying a Sign-Out URL

For custom authentication solutions you can use the Sign-Out URL field to specify an optional
sign-out URL. The authentication token provided by the SSO server is stored on the client
machine in the form of a cookie. If the Communicator Web Access client is browser based,
closing the browser will delete the cookie. Otherwise, the expiration time value of the cookie will
enforce its invalidation. It is strongly suggested that at the time a user has logged off
Communicator Web Access, they visit the URL designated as the sign-out page by the SSO
server. A visit to this page will result in the clearing of any authentication cookies stored on the
client. This step is particularly important when the Communicator Web Access client is not
browser based. The desktop based Communicator Web Access client application is responsible
for clearing the authentication cookie with a visit to the sign-out page.
Specifying Connectivity settings
You can specify connectivity settings from the virtual server Properties page, Connectivity tab.
To specify connectivity settings
2. Expand the tree view, right-click the virtual server node, and then select Properties.
3. On the Properties page, select the Connectivity tab.

4. On the Connectivity tab, make connectivity settings.
Tracing
To turn on and off “stack trace”, create the following registry key and set it to 1 or 0,
respectively:
HKLM\Software\Microsoft\Communicator Web Access\Tracing\EnableErrorStackTrace
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 16 lists the search-related WMI settings that can be changed.
Table 16: WMI Search Settings

WMI Setting Name Type Defa Accepted Values
ult
Value
DefaultSearchField uint3 12 Values in binary (decimal), with
2 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
DefaultSearchQue string OR AND, OR
ry
SearchMaxServerR uint3 200 1 to 1000
esults 2
SearchMaxClientR uint3 10 1 to 300
esults 2
MaxQueuedSearch uint3 80 1 to 500
es 2
The default search criteria, which you can change and the user can override, are:
• Contact’s first name (given 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.
After the search is completed and the attributes in the global catalog server are returned,
Communicator Web Access (2007 release) 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 attributes described previously.
MOM Pack
This section discusses options for monitoring Communicator Web Access (2007 release).
The Microsoft Office Communicator Web Access (2007 release) Management Pack for Microsoft
Operations Manager (MOM) 2005 and MOM 2007 adds the following Communicator Web
Access (2007 release)-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 Communicator Web Access service unexpectedly terminates.
• A large 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.
The following components are not provided in the Communicator Web Access (2007 release)
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 (2007 release) management
pack requires the following minimum software:
• Microsoft Operations Manager 2005 SP1

• Office Communications Server 2007 Management Pack
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
http://www.microsoft.com/management/mma/catalog.aspx.
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
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 Office Communications
Server 2007 administrator’s notification group. After you
perform these steps, when an error-level alert (or higher
severity) occurs, 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 Communications Server 2007 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 Office Communications Server 2007 administrator’s 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 (2007 release) 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:
http://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/3e039637-4639-
46f7-9f5f-518e0c04795e.mspx?mfr=true
• MOM Catalog: http://www.microsoft.com/management/mma/catalog.aspx
• MOM Resource Kit: http://www.microsoft.com/mom/downloads/2005/reskit/default.mspx
Customizing and Branding

This section discusses customizing the UI.
Customizing the User Interface

See the Corporate Branding section in this guide for information on customizing the UI for
Corporate Branding.
Custom Tabs
Custom tabs are not supported in Communicator Web Access (2007 release).
Custom Presence States

Custom Presence States, set in Office Communicator 2007 are displayed for contacts in
Communicator Web Access (2007 release). However, custom presence states can not be set and
are not options in the presence menu from within Communicator Web Access (2007 release).
Creating Corporate Branding

You can customize the Communicator Web Access (2007 release) UI to provide corporate name
recognition and branding. For illustration only, the general process is as follows:
1. Decide on a corporate customization of the logon page and other pages that you want your
corporate branding to appear on.
2. Make sure that changes comply with copyright, trademark, legal requirements, and so on.
3. On the server, create a ..\Program Files\Office Communications Server
2007\Communicator Web Access\Server\cwa\Client\custom folder.
4. Add your art, for example file_name.jpg to the custom folder created in the last step.
5. On the server, open the logon.aspx file, found in the ..\Program Files\Office
Communications Server 2007\Communicator Web Access\Server\logon\ directory.
6. The logon.aspx file is commented with location references. For example, find the following
comment, which is on line 99 in the Microsoft Visual Studio® 2005 integrated development
environment:

7. For this example, under the preceding comment, find the following XML:

<td valign=’top’>
<table cellpadding=’0’ …<snip>
<snip>
</table>
</td>
8. Just above the </table> closing tag in the preceding XML, add references to your company
and logo art using the following syntax:

<tr>
<td>
Contoso, LTD
</td>
<tr>
<script language=”javascript”>
var imgsrc = GetImgHTML(“<%=ServerPath%>cwa/client/custom/file_name.jpg”);
document.write(“<td valign=’top’ style=’padding-bottom:0px;padding-
top:10px;padding-left:19px;padding-right:30’>” + imgsrc + “</td>”);
</script>
</tr>

9. Make sure that the replacements fit within the UI bounds of the original art and strings.
10. Do an iisreset /restart on the server that is serving the new content.
11. Make sure that users clear the temporary files on their browser so that old content cached on
their computer, if any, doesn’t get used instead of the new content.
12. An example of adding a corporate name and logo in the lower left corner of the Integrated
Windows Authentication logon page, using the above script, is seen in the next figure.
Enterprise Voice
Communicator Web Access (2007 release) has no Enterprise Voice features, or any Enterprise
Voice-dependent features. All Enterprise Voice features are enabled by Office Communications
Server 2007, Office Communicator 2007 and Microsoft Exchange Server 2007. For details, see
the Microsoft Office Communications Server 2007 Unified Communications Enterprise Voice
Planning and Deployment Guide.
Call Forwarding
When Enterprise Voice is enabled within the Office Communications Server 2007 deployment in
which Communicator Web Access (2007 release) is deployed, Communicator Web Access users
can configure call forwarding. How the user can forward calls is dependent upon if the user is
enabled for Unified Messaging (UM) and Unified Communications (UC). The following table
summarizes this.
Table 17: Call Forwarding
Enabled for UC Disabled for UC

Enabled for UM Can receive call from Can receive call from
Office Communicator Office Communicator
2007 and the PSTN 2007
Can reply with instant Can reply with instant
message, or can message
deflect to PSTN number Cannot configure call
or voice mail forwarding
Can configure call
forwarding to PSTN
number, SIP URI, or
voice mail
Disabled for UM Can receive call from
Office Communicator
2007 and the PSTN
Can reply with instant
message, or can
deflect to PSTN number
Can configure call
forwarding to PSTN
number or SIP URI
Communicator Web Access (2007 release, Public Beta) does not support remote call control.
Web UI Controls
See the Communicator Web Access (2007 release) SDK.
SDK
AJAX API
Security Considerations
This section covers security considerations for Communicator Web Access (2007 release) until
the Communicator Web Access (2007 release) Security Guide can be updated and released.
Providing a Single URL for both Internal and

Remote Access
Providing the same URL for internal and remote access allows the user to enter the same server
address in the browser regardless of the user’s location.
To provide a single URL for internal and remote users
1. Create internal virtual server on port 443 with URL of https://cwa.contoso.com.
2. Create remote virtual server on port 444 with URL of https://cwa.contoso.com:444.
3. Use ISA (2004 or 2006) to Web publish the remote virtual server using SSL with internal
URL of https://cwa.contoso.com:444 and with the external URL of https://cwa.contoso.com
(no :444 appended on the external URL) on port 443 for the ISA server and then redirect the
traffic to port 444 internally.
4. User can type https://cwa.contoso.com/alice@contoso.com to sign in on an internal deployed
CWA server without needing to type any additional info or click any button. To enable this
mechanism, make sure that:
a. AllowQuickLogon is true in MSFT_CWASiteSetting in WMI.
b. The correct Internet Explorer setting is enabled.
If the user is challenged by Internet Explorer internally when using Integrated Windows
Authentication, there is a configuration problem.
Denial of Service Because of Failed Sign-In

Attempts
Communicator Web Access adheres to the user lockout policy defined in Active Directory. This is
a security Best Practice to have this policy. However, this policy provides the opportunity for a
malicious user to purposely trigger a user lockout and wage a denial of service (DOS) attack.
Mitigations to this attack are:
• Monitoring events for abnormal numbers of failed sign-in attempts
• Restricting users from signing in to local account when signing in to external servers
• Preventing sign-in to external servers using local accounts, and rejecting the connection
before sign-in
Service Account
The following table describes accounts that are created by the setup program.
Table 18: Accounts
Account
CWAService Content for this topic is not yet available.
Port Allocation
Authentication Module
Directory Permissions
For Active Directory permissions see the Office Communications Server 2007 Active Directory
Guide.
Removing Communicator Web

Access
This section describes how to remove Communicator Web Access (2007 release) from a server.
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 Office Communications Server 2007
Public Beta, Communicator Web Access.
4. Click Remove.
5. Click Yes.
Configuring Clients
This section discusses tasks to configure clients.
Preparing Clients to Sign in to Communicator Web Access

This section provides the procedures for configuring users for Communicator Web Access (2007
release) in Active Directory and signing into Communicator Web Access. In a migration scenario,
it is possible to add both legacy presence and enhanced presence users.
To add a new Communicator Web Access client
1. On the client computer, install a supported operating system. Supported operating systems
are listed in the Supported Client Operating Systems section in this guide.
2. Install a supported browser Support browsers are listed in the Supported Client Browsers
section in this guide.
3. In Active Directory, configure users of the client as Office Communications Server 2007
users as described in the following procedure.
To enable a new 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 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:<user_name>@<org_name>.com.
8. In Server or pool, select <server_name>.<org_name>.com.

9. Click Configure.
10. Select the Enable remote user access check box.
11. If federation is enabled in Office Communications Server 2007, 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 (2007 release).
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://<server_FQDN> 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.contoso.com, the URL should be:
https://im.contoso.com.
4. In the Security Alert dialog box, if you understand and accept the security implications,
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.
The sign-in page for Integrated Windows Authentication on Internet Explorer and a Windows
operating system is shown in the next Figure.
Figure 14: Integrated Windows Authentication
To install a certificate on the client computer

1. In the address bar of the client browser, type http://<CA_server_name>/certsrv, 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 Forms-based Authentication on Internet Explorer and a Windows operating
system is shown in the Figure 15.
Figure 15: Forms-based authentication
Signing in to Communicator Web Access displays the main Communicator Web Access page.
Configuring Users for Remote Access

You configure users for remote access on the Communications tab of the user Properties page in
the Active Directory Users and Computers snap-in.
To enable remote access for a user
1. Open the Active Directory Users and Computers snap-in.
2. In the scope pane of the Active Directory Users and Computers snap-in, right-click the user
for which you want to enable remote access, and select Properties.
3. On the User Properties page, click the Communications tab and click Configure.
4. On the User Options page, select Enable remote user access, and click OK.
Note
If Windows Firewall is enabled on the Communicator Web
Access (2007 release) Server, the client cannot successfully
publish presence at sign in time and two-party IM cannot be
started successfully.
Configuring clients for external Access

Clients should have the root certificate and CA chain of the CA that issued the certificate to
which the client is connecting, downloaded and trusted on the client local computer.
JavaScript 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:
<installation path>\Server\cwa\client\<client version>
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.
To resign 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
http://www.mozilla.org/projects/security/pki/nss/tools:
• 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 <database_directory>), 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 <database_directory>
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 <cert/key file> -d <database_directory >
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 <certificate nickname> -i <CA certificate> -t "C,C,C"
-d <database_directory >
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 <database_directory >
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 <certificate name> -Z <installation path>\Server\cwa\client\<client
version>\SignedCode.jar -p <database password> -d <database directory> <installation
path>\Server\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
http://www.mozilla.org/projects/security/components/jssec.html.
Performing User Tasks

This section describes performing user tasks.
Managing User Options

You manage user options from one of four tabs on the options page.
To manage user options
1. From the main page, click Options on the Main menu.
2. On the Options page, select the tab containing the setting that you want to make.
3. Click OK.
Managing Call Forwarding

You manage standard call forwarding options from the Incoming Calls page.
Figure 16: Call Forwarding
You manage advanced call forwarding settings from the Advanced Call Settings page seen in the
next figure.
Figure 17: Advanced Call Settings
Specifying Phone Numbers

When you enter a phone number, enter the number using the International Number Format. Enter
a "plus" sign (+), followed by the country code, and then followed by the local number. Phone
numbers should contain only the plus sign, followed by digits +0123456789. Do not include the
international dialing prefix - for example 011 (in the USA) and 00 (Europe, South America). The
following table gives a few examples of how to convert a local number into an International
Format number.
Table 19: International Number Format
Country/Regio Country Code Local Number International

n Number
China 86 (10) 55555555 +861055555555
France 33 06 87 71 23 45 +330687712345
United Kingdom 44 07700 954 321 +440770095432
1
United States 1 (555) 555-5555 +15555555555
Venezuela 58 (0295) 416, 72, +580295416721
16 6
Upgrading and
Interoperability
This section describes upgrading the 2005 release to the public beta release of Communicator
Web Access (2007 release). Upgrading the 2005 release to the Beta 3 version of the 2007 release
is not supported. A side-by-side upgrade of the 2005 release to the public beta of the 2007 release
is the only supported upgrade path.
With the introduction of the 2007 release, the concepts of legacy and enhanced conferencing,
legacy and enhanced clients, and legacy and enhanced presence are also introduced. The
introduction of these new concepts is due to the change in conferencing model between the 2005
release and the 2007 release.
In such environments, there are two types of user:
• Legacy presence user
• Enhanced presence user
In this environment, there are two conferencing models working together:
• MIM - The Multi-Party IM based conference (MIM-based conference) is the legacy model
where each endpoint in a conference distributes messages to all other endpoints in the
conference.
• Focus- The Focus-based conference is the enhanced model in which all endpoints send
messages to a centralized Instant Messaging MCU (the Focus). The Focus acts as the
manager of the conference, ensuring that messages get to their required and intended
destination. The Focus also ensures that messages are not unnecessarily sent to endpoints
that do not need to receive the message. The Focus is the SIP conference host and is the
central point of control of each party in a multiparty, SIP-signaling conference.
With the Focus-based model, there are enhancements provided over the legacy MIM-based
model:
• Ability to lock and unlock a conference
• Ability to promote participants
• Ability to eject participants
Legacy redirection is a feature provided in Communicator Web Access (2007 release) that
enables the administrator to configure redirection of legacy traffic without intervention from the
user. Legacy redirection when enabled occurs in two cases:
• Legacy code
• The legacy presence user is not flagged for enhanced presence upgrade
Whether or not a user is flagged for enhanced presence upgrade is controlled by bit 9,
EnableForEnhancedPresence, of the msRTCSIP-OptionsFlags user attribute in Active
Directory. Redirect occurs when the value of bit 9 is false.
The following figure shows a combined enhanced presence and legacy presence environment, in
which Legacy Redirection may or may not be configured by the administrator.
Figure 18: Coexistence
Planning for Migration and Coexistence

New implementations of the 2007 release in which the 2005 release is not implemented do not
have to worry about coexistence of both conferencing models. While you could, theoretically
deploy a coexistence environment from the ground up for testing purposes, coexistence in a
production environment is typically the result of migrating from an existing Communicator Web
Access (2005 release) deployment.
For existing legacy environments that are being upgraded to enhanced environments, there are
coexistence considerations that you must plan for because of the two conferencing models. Two
conferencing models existing together in the same deployment raises the possibility for scenarios
that might seem like inconsistent behavior.
The supported migration path typically results in a combined, legacy presence enhanced presence
environment. A legacy presence user becomes an enhanced presence user when all three of the
following are met:
1. Office Communications Server 2007 is deployed, including the schema upgrade.
2. The user is homed on the Office Communications Server 2007 Front End.
3. The user is enabled for enhanced presence on the User Options page, accessible from the
Communications tab of the User Properties page in Active Directory Users and
Computers console.
A side-by-side migration from Live Communications Server 2005 with SP1 and with
Communicator Web Access (2005 release) deployed to Office Communications Server 2007 and
with Communicator Web Access (2007 release) deployed is the only supported migration path for
the public beta.
The only public beta-supported topologies for coexistence of Communicator Web Access (2005
release) and Communicator Web Access (2007 release) are:
• Communicator Web Access (2005 release) with legacy presence users homed on Live
Communications Server 2005 with SP1
• Communicator Web Access (2007 release) with enhanced presence users homed on Office
Communications Server 2007
Conferences in which both models are involved work differently than conferences in which there
is just one model involved.
Understanding Interoperability Scenarios

Up until the administrator marks the user as enabled for enhanced presence, either by individual
user or by using the Live Server Move User Wizard, you can take advantage of the Legacy
Redirection ability in Communicator Web Access (2007 release), which routes users based on
presence enablement to the correct server. The following are true of all coexistence scenarios:
• Presence is user-specific (one user can have Enhanced presence and another user can have
Legacy presence at the same time within the same org)
• A user will never get legacy presence on one computer or for one client, and enhanced
presence on another computer or for another client (all-or-none)
For example:
• Alice and Bob both have a desktop computer and a laptop computer. They are both initially
homed on the Live Communications Server 2005 SP1 Front End server. Both are enabled for
remote access using Communicator Web Access (2005 release).
• Office Communications Server 2007 and Communicator Web Access (2007 release) are
added (side-by-side) to the contoso.com organization.
• The administrator for contoso.com, from the Active Directory Users and Computers console
on a computer with the Live Communications Server 2005 with SP1administrative tools
installed, changes the Front End server for both Alice and Bob to the new Office
Communications Server 2007 Front End. Enhanced presence is enabled for both users on the
User Options page. This can be done for a user individually, or for multiple users with the
Live Server Move User Wizard.
• Alice upgrades her desktop computer from Office Communicator 2005 to Office
Communicator 2007 but she does not perform a Logon to Office Communications Server
2007 using either Office Communicator 2007 or Communicator Web Access (2007 release).
• Bob upgrades his desktop computer from Office Communicator 2005 to Office
Communicator 2007 but he does perform a Logon to Office Communications Server 2007
using either Office Communicator 2007 or Communicator Web Access (2007 release). It
does not matter which.
• Using her laptop, Alice Logs on to:
• (1) Communicator Web Access (2005 release), by entering https://legacy.contoso.com in
her browser.
• (2) Communicator Web Access (2007 release), by entering https://cwa2k7.contoso.com
in her browser.
• (3) Office Communicator 2005.
Doing so, Alice has the following user experience:
• (1) Alice gets an error. She must access the 2007 release server.
• (2) Alice logs in to the 2007 release server after successfully entering her credentials.
• (3) Alice gets an error. She must start using Office Communicator 2007.
• (4) Alice logs in after successfully entering her credentials.
• Using his laptop, Bob Logs on to:
• (1) Communicator Web Access (2005 release), by entering https://legacy.contoso.com in
his browser.
• (2) Communicator Web Access (2007 release), by entering
https://webserver3.contoso.com in his browser.
Doing so, Bob has the following user experience:
• (1) Bob gets an error. He must access the enhanced platform.
• (2) He gets enhanced presence.
• (3) Bob gets an error. He must access the enhanced platform.
• (4) Bob logs in after successfully entering his credentials.
The next sections discuss specific interoperability scenarios.
Understanding Instant Messaging Interoperability
• Scenario 1: When a legacy presence user (Bob) and an enhanced presence user (Alice) are in
a 2-party conference, Bob can invite neither another legacy presence user nor Alice to join
the conference.
• Scenario 2: When a legacy presence user (Bob) and an enhanced presence user (Alice) are in
a 2-party conference, and when Alice invites another participant, Bob, who is already in the
meeting, receives another meeting pop-up chat window.
• Scenario 3: Bob, a legacy presence user, is in a Focus-based conference can only be a

participant, not a leader. This is also true when Bob is the leader of a MIM-based conference
that is changed to a focus-based meeting by an enhanced presence user, Alice. Only Alice or
another enhanced presence participant in a MIM-based meeting can change the meeting to
Focus-based conference, and as soon as that user makes the change, he or she is the new
leader and Bob becomes a participant, instead of the leader.
• Scenario 4: Two enhanced presence users, Alice and Carol sign in to Communicator Web
Access (2007 release) using a supported Safari browser. Carol sends an instant message to
Alice. Alice positions her mouse cursor over the alert that displays, and then very quickly,
moves the mouse cursor away from the alert. The expected result is that the alert will
disappear and the conversation page for Carol’s message will appear. What does happen is
that the alert remains displayed and the conversation page does not appear. The two ways to
avoid this behavior is to move the mouse cursor more slowly, or always click the alert to
display the conversation page.
• Scenario 5: A Focus-based conference will remain active when one participant leaves the
conference leaving only one participant left. In a MIM-based conference, the conference is
terminated when only one participant remains.
Understanding Presence Interoperability
• Scenario 1: When an enhanced presence user (Alice) searches for a legacy presence user
(Bob) or when adding Bob to her contact list, Bob will appear offline to Alice until Bob
accepts Alice’s request to add him.
• Scenario 2: When one legacy presence user (Bob) adds another legacy presence user (Ted)
to his contact list, and Ted is marked for enhanced upgrade prior to him accepting Bob’s
request, Ted does not get notification of Bob’s offer once Ted logs in after being upgraded to
enhanced presence.
• Scenario 3: One legacy presence user (Bob) adds to his contact list another legacy user
(Ted) who is initially logged off. Bob then logs off, and Ted subsequently logs on, but Ted
does not receive the notification that Bob wants to add him to her contact list.
• Scenario 4: Bob, a legacy presence user, is homed on bobsPool and is signed in, and Alice,
an enhanced presence user, is homed on alicesPool but not signed in. The administrator takes
alicesPool down for maintenance, after which Bob adds Alice to his contact list. The
administrator then brings alicesPool back up and Alice signs in. Alice does not get
notification that Bob wants to add her to his contact list.
• Scenario 5: Alice and Carol are two enhanced presence users in a conference with each
other. Alice invites Bob, who is a legacy presence user to the conference. Both Alice and
Carol can see that Bob has been invited to the conference, but Bob sees only Alice, the
enhanced presence user that invited him. Bob does not see Carol, the other enhanced
presence user. When Carol sends a message to both Alice and Bob, Bob receives an
unexpected message, while Alice receives the expected message.
• Scenario 6: Alice and Bob are enhanced and legacy users, respectively, and are using
Communicator Web Access (2007 release) and Communicator Web Access (2005 release),
respectively as their clients. Alice adds Bob to her contact list. When Alice’s status “Do not
Disturb” Bob sees Alice’s status represented by a “Busy” icon but text that says “Offline”.
Supported Collocation Topologies

Installing Microsoft Office Communicator Web Access Manager (2007 release) on the same
management computer as Communicator Web Access Manager (2005 release) is supported.
Neither version of the server running on this management computer is supported.
Installing Microsoft Office Communicator Web Access (2007 release) server on the same server
as Office Communications Server 2007 is not supported.
as Office Communications Server 2007 is not supported.
as Live Communications Server 2005 with SP1 is not supported.
CWA v1.0 (Budapest) is supported with OCS 2007 configured as the Front End and with no LCS
2005 with SP1 configured in the deployment.
Table 20: Collocation Matrix
Role 1 Role 2 Supported?
Communicator Web Access Communicator Web Access Yes
Manager (2007 release) Manager (2005 release) Neither
server
Office Communications Server No
2007
server
Communicator Web Access (2007 Communicator Web Access No

release) server Manager (2005 release)
Communicator Web Access Yes
Manager (2007 release)
Communicator Web Access Communicator Web Access Yes

Manager (2005 release) Manager (2007 release) Neither
server
Live Communications Server Yes
2005 with SP1 server
Communicator Web Access No
(2007 release) server
Communicator Web Access (2005 Live Communications Server Yes

release) 2005 with SP1 server
server Office Communications Server No
2007
server
MMC Interoperability
The Communicator Web Access Manager (2007 release) and Communicator Web Access
Manager (2005 release) Managers can be installed on the same computer. The requirements for
that computer are dictated by the Communicator Web Access Manager (2007 release) snap-in.
Performing a Migration
Side by side migration from Communicator Web Access (2005 release) to Communicator Web
Access (2007 release) is supported. Side by side migration of Live Communications Server 2005
with SP1 to Office Communications Server 2007 must be completed prior to migrating
Communicator Web Access. For the procedure for migrating Live Communications Server 2005
with SP1 to Office Communications Server 2007, see the Office Communications Server 2007
deployment documentation.
Migrating to the 2007 release from the 2005 release

In-place upgrade of Communicator Web Access (2005 release) to the Communicator Web Access
(2007 release) is not supported. A side-by-side migration is the only supported migration path to
Communicator Web Access (2007 release). The administrator has two options to accomplish this:
• No Legacy Redirection: Create a new URL for the 2007 release and educate the user to use
the new enhanced presence URL. For example https://legacy.contoso.com for legacy
presence users and https://webserver3.contoso.com for enhanced presence users.
• Use Legacy Redirection: Use the same URL for legacy and enhanced presence users after
configuring the Legacy Redirection feature built-in to Communicator Web Access (2007
release). Communicator Web Access (2007 release) manages the URL for the user without
any intervention from the user or even the perception that anything is being managed.
A single Active Directory forest can contain users enabled for enhanced presence and users that
are not enabled for enhanced presence, i.e. using legacy presence. Users enabled for legacy
presence cannot sign into Communicator Web Access (2007 release). Only users enabled for
enhanced presence can sign into Communicator Web Access (2007 release). Users enabled for
legacy presence are redirected to the legacy Communicator Web Access (2005 release) server.
Coexistence of the two Communicator Web Access versions within the same Active Directory
forest is supported and is dependent upon compatibility and supportability of the underlying
Office Communications Server version. Since Live Communications Server 2005 with SP1 and
Office Communications Server 2007 can coexist in the same forest, both versions of
Communicator Web Access can coexist in the same forest. Coexistence on the same physical
server is not supported.
Multiple-tree forest topology is supported for both releases.

To migrate from the 2005 release to the 2007 release
1. Deploy Office Communications Server 2007.
2. Prepare the Communicator Web Access (2007 release) server hardware.
3. Install the required Communicator Web Access (2007 release) software.
4. Install Communicator Web Access (2007 release).
5. Migrate users to the Office Communications Server 2007 pool.
6. Configure legacy redirection (optional).
7. User logs on with Office Communicator 2007 to complete migration.
Steps 1-4 are the same for deployments with or without the 2005 release.
Marking Legacy Presence Users for Upgrade to Enhanced
Presence
Before existing users can get enhanced presence in Communicator Web Access (2007 release),
when migrating from Live Communications Server 2005 with SP1 to Office Communications
Server 2007, you will need to move users from the Live Communications Server 2005 with SP1
server to the Office Communications Server 2007 server, and mark them for enhanced presence
upgrade. Then, the user will need to upgrade Office Communicator 2005 to Office
Communicator 2007 (Public Beta). When the user signs in to Office Communicator 2007 for the
first time, the user is upgraded to enhanced presence. Any new users added after the migration
will typically be added directly to the enhanced platform, and not have to be migrated. However,
it is possible to add a new user to the legacy presence platform.
Users getting legacy presence must be managed from the Active Directory Users and Computers
snap-in on a computer with the Live Communications Server 2005 with SP1 Administrative tools
installed. If you try and manage a legacy user from the Active Directory Users and Computers
snap-in on a computer with the Office Communications Server 2007 Administrative Tools
installed, you will get the information seen in the next figure.
Figure 19: Information
After you upgrade the user to Office Communications Server 2007 and enhanced presence, then
you can access the user from the Active Directory Users and Computers snap-in on a computer
with the Office Communications Server 2007 Administrative Tools installed. The before and after
for a legacy presence user, John Evans upgraded to enhanced presence is seen in the next two
figures.
Figure 20: Before Upgrade Figure 21: After Upgrade
Notice that the Communications tab only offers the enhanced home server and the Live
Communications tab offers both. The Live Communications tab is present and accessible for
both legacy and enhanced users from management computers with the appropriate management
tools installed. The Communications tab is present for both legacy and enhanced users, but only
accessible for enhanced users from management computers with the appropriate management
tools installed.
If the user is not using Office Communicator and is using only Communicator Web Access, once
the user is switched over to the Office Communications Server 2007 Home Server, and is enabled
for enhanced presence, the user will get enhanced presence when the URL that the user enters in
the browser, is a URL that points to the 2007 release server. If the user enters a URL that points
to a 2005 release Communicator Web Access server, the user will get an error.
Prior to being enabled for enhanced presence by the administrator in Active Directory, the legacy
user can only connect to the legacy server using a legacy client. However, you can configure
Communicator Web Access (2007 release) to redirect the legacy user traffic to the legacy server
when the legacy user enters the 2007 release URL in his or her browser.
You can use two methods to migrate legacy users by marking them for enhanced presence
upgrade:
• Multiple users simultaneously using the Live Server Move User Wizard
• Individual users manually, one at a time
For information on the Live Server Move User Wizard, see the Office Communications Server
2007 documentation. The following procedure describes the manual method.
To manually mark a single legacy presence user for enhanced
presence upgrade
1. From a management computer with the Live Communications Server 2005 with SP1
administrative tools snap-in and the Active Directory Users and Computers snap-in installed,
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.
user’s name that you want to convert, and then click Properties.
4. In the Properties dialog box, click the Live Communications tab. In the Server or pool
box, select the 2007 release server, click Apply, and then click OK.
5. From a management computer with the Office Communications Server 2007 administrative
tools snap-in and the Active Directory Users and Computers snap-in installed, click Start,
point to Programs, point to Administrative Tools, and then click Active Directory Users
and Computers.
6. In the console tree, expand the Organization Node, and then expand Users.
same user’s name for which you changed the server, and then click Properties.
8. In the Properties dialog box, click the Communications tab.
9. On the Communications tab, click Configure.

10. On the User Options page, click the Enable enhanced presence check box, which is
cleared and enabled only for legacy presence users.
11. On the Warning dialog box, click Yes.

12. Click OK, click Apply, and then click OK.

13. The user just marked for upgrade can now log in with an enhanced client, either Office
Communicator 2007 or Communicator Web Access (2007 release) to complete the process.
Once the user does this, he or she will get enhanced presence, and will not be able to access
the legacy server.
Configuring Legacy Redirect

You configure the Communicator Web Access (2005 release) URL on the General tab of the
Virtual Server Properties page. The URL box is disabled for virtual servers that are using SSO
authentication.
Taking advantage of legacy redirection, included in Communicator Web Access (2007 release)
allows the administrator to configure the same URL for both users enabled for legacy presence
and users enabled for enhanced presence. This has the following benefits:
• The user does not have to take any action
• The URL is the same for both users
• Migration of users can be done in a progressive manner rather than all at once
The legacy redirection process is:
1. The authentication module references an “Upgrade” flag to determine Enhanced presence or
Legacy Presence status.
2. If not “flagged” for enhanced presence upgrade, a WMI setting containing the
Communicator Web Access (2005 release) server, is accessed by the authentication module
to determine where to redirect traffic for the user.
3. Traffic is redirected to legacy handler based on the WMI setting.
In a combined Live Communications Server 2005 with SP1 and Office Communications Server
2007 environment, two flags are used by the legacy redirect mechanism:
• msRTCSIP-OptionsFlag (Active Directory)
• LegacyCWAServer (WMI)
Appendixes
Appendix 1: Ports Used By Communicator Web Access
Firewalls can block ports needed by Office Communicator Web Access (2007 release). Table 21
shows the ports used by Communicator Web Access (2007 release).
Table 21: Ports used by Communicator Web Access (2007 release)

Port Purpose
88 (Kerberos) Content for this topic is not yet available.
137 (netbios)
138
139
445
1025 - 65,535
5060
5061
Appendix 2: Accounts
This section describes the accounts required for Communicator Web Access (2007 release).
Accounts Created by Communicator Web Access (2007 release)
Setup
The following account is created by the Communicator Web Access setup program.
Table 22: Account Created by Setup
Account Name Member Of
CWAService RTCHSUniversalServices
Administrator Groups
The following administrator group changes are required for Communicator Web Access.
Table 23: Administrator Group Changes
Account Name Changes
RTCUniversalServerAdmins Grant the following:
• Member of Administrators (local
machine)
• Read/Write ACEs on Communicator Web
Access WMI
• Read/Write IIS Settings
• No Active Directory ACEs required
Appendix 3: Enabling Activation Without Using DomainAdmins

Credentials
To activate the Communicator Web Access (2007 release) 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 Office Communications Server 2007 global container RTC Service, to
create and delete global settings.
• Permissions on the container that contains the RTCUniversalServerAdmins group and the
RTCHSUniversalServices group to create and delete accounts.
• Read and Write permissions on the service account that is specified during activation.
To grant a user these permissions, you can perform the following
tasks:
1. Create a service account for Communicator Web Access that will be specified during
activation, and add this account to the RTCHSUniversalServices security group.
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 RTCUniversalServerAdmins group and the RTCHSUniversalServices
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.
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, 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 RTCHSUniversalServices, 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.
To create a security group
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.
To grant the required global permissions to the security group
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.
To grant permissions required to create and delete accounts to the
security group
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 RTCUniversalServerAdmins group and the RTCHSUniversalServices
group), and then click Properties.
5. In the Enter the object names to select box, type the name of the global security group (for
• Read
• Create All Child Objects
• Delete all Child Objects
7. Click OK.
To grant permissions on the service account to the security group
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.
5. Under Enter the object names to select, type the name of the global security group (for
• Read
• Write
7. Click OK.
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 necessary to run the Communicator Web Access Activation Wizard.
Appendix 4: WMI Settings

Communicator Web Access (2007 release) server WMI settings are stored in the
root\DEFAULT\rtccwa_repository namespace. The WMI properties that can be changed
directly, without using Communicator Web Access Manager (2007 release), are identified in the
Can be Changed? column. Any changes made directly to WMI properties take effect
immediately without restarting the virtual server.
Table 24: WMI Settings
Can be Name Type Default Value
changed?
MSFT_CWASupportedLanguage
No Enabled Boolean true
No FriendlyName string English
No LanguageID uint32 9
No LanguageTag string EN
MSFT_CWASiteSetting
Yes AllowFormAuth Boolean true
Yes AllowIWAAuth Boolean true (internal; can be
false)
false (external; can’t be
true)
false (sso; can’t be true)
Yes BackendLCS string <empty>
No ConnectivityType string HTTPS
Yes DefaultLanguageID uint32 9

changed?
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 DefaultSearchQuer string OR
y Accepted values: AND,
OR
No Description string <Instance_Name>
EnabledAuthMode Uint32 Normal
EnabledSSOType Uint32 6 (internal and external in
5887)
Accepted values: 1-7
(used to be 6)
Yes FormPrivateTimeou uint32 240 (internal and external
tMin in 5887)
Yes FormPublicTimeout uint32 15 (internal and external
Min in 5887)
No IP string <CWA_server IP>
Yes LegacyCWAServer string <2005 release server
URL>
Yes MaxQueuedSearch uint32 80
es Accepted values: 1 to 80
No Name string W3SVC/##########
No Port uint32 <###>
Yes SearchMaxClientRe uint32 10
sults Accepted values: 1 to 300

changed?
Yes SearchMaxServerR uint32 200
esults Accepted values: 1 to
1000
Yes ServerType string Internal ( or External)
TLSCertIssuer uint 8 Array[69] with index
array beginning at 1
TLSCertSN uint 8 Array[10] with index
array beginning at 1
Yes UserNotice string [Blank] (internal and
external in 5887)
MSFT_CWAServerSetting
No Activated boolean true
No Name string Server FQDN
No TLSCertIssuer array of Array[69] with index
unit8 beginning at 1
No TLSCertSN array of Array[10] with index
unit8 beginning at 1
Appendix 5: Configuring IIS 6.0

The Communicator Web Access Setup Wizard makes a number of changes in IIS 6.0, as shown in
the next figure. This section describes those changes.
Figure 22: IIS 6.0 MMC
Application Pools The Communicator Web Access Create Virtual Server Wizard creates
two application pools for the first virtual server created:
• Communicator Web Access

• W3SVC<Web site identifier>
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 site identifier>
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.
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:
http://www.microsoft.com/technet/itsolutions/wssra/raguide/WebApplicationServices/igwaog_2.
mspx
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 25. As you monitor your Communicator Web Access
servers over time, you can tune these settings to meet the needs of your organization.
Table 25: 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- check box selected
Alives
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 <empty>
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 check box unselected
naming and rollover
Log file directory text box %windir%\system32\LogFiles
Logging Properties - Advanced Tab
Extended logging lots of check
options 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
Status text box Green up-pointing arrow
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
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/71490aae-f444-
443c-8b2a-520c2961408e.mspx.

CWA PlanDeploy

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CWA PlanDeploy

Încărcat de

Drepturi de autor:

Formate disponibile

Microsoft Office

© 2007 Microsoft Corporation. All rights reserved.

All other trademarks are property of their respective owners.

Communicator Web Access Features

Comparing Communicator Web Access and Office Communicator

Office Communications Server 2007 (Beta

Figure 1: Main Page

Figure 3: Conversation Page

Figure 5: Communicator Web Access Topology

Communicator Web Access Deployment Components

.NET Framework 2.0

Planning for Deployment

• Communicator Web Access Requirements

Planning Active Directory

Selecting a Supported Topology

Single Forest Topologies

Multiple Forest Topologies

Using Physical Separation or Application Isolation

Figure 6: Same Server (Supported, but not recommended)

Communicator Web Access Requirements

Computer Component Required For

Computer Component Required For

Table 3: Communicator Web Access (2007 release) required permissions

Create a virtual server User must be a member of local

Supported Server Operating Systems

Supported Communicator Web Access (2007 release) Manager

Operating Browser Authentication

Windows Vista Internet Explorer Forms-based

• Office Communications Server 2007 schema updates as specified in the Office

Server Hardware Requirements

Additional Infrastructure Information

Planning for Required Certificates

Planning for Communicator Web Access Certificates

Planning for HTTPS Certificates

Table 8: Certificate Requirements

Planning for Office Communications Server 2007 Certificates

Planning for Hardware Load Balancing Certificates

Planning for Remote User Certificates

Understanding Authentication and Authorization

Quick Sign-In Using a Single URL

Allowing Pop-up Blockers

Understanding Custom Authentication, Including Single Sign-on

Planning for Capacity Requirements

Planning for Performance Requirements

Using Typical Performance Metrics for Planning

IM conversations per user per day 24

Planning for High Availability

Load balancing can be required for the following reasons:

Configuring Load Balancing Topologies

Unsupported Load Balancing Configurations

• Network load balancing

Load Balancer Configuration Recommendations

Planning for Disaster Recovery

Planning for a Standby Recovery Server

Deploying Servers for Internal Users

Communicator Web Access Setup Overview

Table 11: Communicator Web Access (2007 release) Setup Overview

Preparing the Server for Installation

Preparing Certificates for Communicator Web Access

Download the CA certificate chain

Request and install the MTLS Certificate

Request and install the HTTPS Certificate

Installing Communicator Web Access