cwa plandeploy

Published: March 2007

Microsoft Office Communicator Web Access(2007 release, Public Beta)Planning and Deployment Guide

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............7

Planning...................................................................................................8

Planning for Deployment...................................................................9

Planning Active Directory.............................................................9

Selecting a Supported Topology...................................................9

Reference Topology..............................................................10

Single Forest Topologies.......................................................10

Multiple-Domain Topologies..................................................11

Multiple Forest Topologies....................................................11

Using Physical Separation or Application Isolation................12

Branch Office Topologies......................................................14

Federation.............................................................................14

Custom Authentication, Including SSO..................................15

IM Archiving..........................................................................15

Communicator Web Access Requirements.................................15

Supported Server Operating Systems...................................17

Supported Clients..................................................................18

Client Interoperability...........................................................19

Server Requirements............................................................19

Server Hardware Requirements............................................21

Additional Infrastructure Information....................................21

Planning for Required Certificates..............................................22

Planning for Communicator Web Access Certificates............22

Planning for Office Communications Server 2007 Certificates25

Planning for Hardware Load Balancing Certificates...............25

Planning for Remote User Certificates...................................25

Understanding Authentication and Authorization.......................26

Authorization.........................................................................26

Authentication.......................................................................26

Allowing Pop-up Blockers......................................................28

Accepting Cookies.................................................................28

Understanding Custom Authentication, Including Single Sign-on..............................................................................................28

Planning for Capacity Requirements..........................................28

Increasing Capacity...............................................................29

Planning for Performance Requirements...............................30

Using Typical Performance Metrics for Planning....................30

Planning for High Availability.....................................................31

Understanding Failover.........................................................32

Planning for Disaster Recovery..................................................38

Planning for a Standby Recovery Server...............................38

Deploying Communicator Web Access...................................................40

Deploying Servers for Internal Users...............................................40

Communicator Web Access Setup Overview..............................40

Preparation................................................................................41

Preparing the Server for Installation.....................................41

Preparing Certificates for Communicator Web Access..........42

Download the CA certificate chain........................................43

Request and install the MTLS Certificate...............................44

Request and install the HTTPS Certificate.............................45

Installing Communicator Web Access........................................46

Installing Communicator Web Access by Using the Deployment Tools...................................................................................................47

Install and Configure Communicator Web Access.................47

Performing Post-Installation Configuration............................51

Creating Additional Virtual Servers............................................52

Deploying Servers for Remote User Access.....................................58

Web Publishing the Remote Virtual Server.................................58

Using ISA Server 2006...........................................................58

Using ISA Server 2004 SP1 to Web Publish - Without SSO Enabled..............................................................................................58

Using ISA Server 2006 to Web Publish - Without SSO Enabled59

ISA Server 2006 Prerequisites...............................................60

Deploying ISA Server 2006.........................................................60

Test the Deployment.............................................................78

PIC..............................................................................................80

Configuring for Capacity and Availability........................................80

Increasing Capacity by Adding a Server.....................................80

Deploying a Hardware Load Balancer...................................80

Deploying the Additional Server............................................81

Deploying High Availability Solutions.........................................81

Recovering from a Server Failure...............................................83

Deploying a Backup Server...................................................83

Switching to the Backup Server............................................83

Management and Operations..........................................................84

Managing Communicator Web Access Servers...........................84

Managing Virtual Servers......................................................87

Tracing..................................................................................91

Configuring Search.....................................................................91

MOM Pack..................................................................................93

Customizing and Branding..............................................................95

Customizing the User Interface..................................................96

Custom Tabs.........................................................................96

Custom Presence States.......................................................96

Creating Corporate Branding.....................................................96

Enterprise Voice.........................................................................97

Call Forwarding.....................................................................97

Web UI Controls.........................................................................98

SDK............................................................................................98

AJAX API.....................................................................................98

Security Considerations..................................................................98

Providing a Single URL for both Internal and Remote Access.....99

Denial of Service Because of Failed Sign-In Attempts................99

Service Account.........................................................................99

Port Allocation..........................................................................100

Authentication Module.............................................................100

Directory Permissions..............................................................100

Removing Communicator Web Access..........................................100

Configuring Clients...............................................................................100

Preparing Clients to Sign in to Communicator Web Access. 100

Configuring Users for Remote Access.................................104

Performing User Tasks.............................................................107

Managing User Options.......................................................107

Managing Call Forwarding...................................................107

Upgrading and Interoperability............................................................109

Planning for Migration and Coexistence...................................110

Understanding Interoperability Scenarios...........................111

Supported Collocation Topologies.......................................114

MMC Interoperability...........................................................115

Performing a Migration.............................................................115

Migrating to the 2007 release from the 2005 release.........115

Configuring Legacy Redirect...............................................120

Appendixes..........................................................................................121

Appendix 1: Ports Used By Communicator Web Access......121

Appendix 2: Accounts.........................................................121

Appendix 3: Enabling Activation Without Using DomainAdmins Credentials..........................................................................122

Appendix 4: WMI Settings...................................................125

Appendix 5: Configuring IIS 6.0...........................................127

IntroductionMicrosoft® 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.

OverviewPresence 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.

Communicator Web Access FeaturesMicrosoft 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 Communicator 2007

Communicator 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! ®

ü ü

4 Communicator Web Access (2007 release) Planning & Deployment Guide

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 status (Communicator Web Access read and display, only)

ü ü1

Incoming IM pop-up notification ü ü

Personal note ü ü2

Automatic "Inactive" status after a period of inactivity

ü ü3

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 ArchitectureCommunicator 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 ComponentsIn 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.

FirewallsFirewalls 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 BalancerWhen 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.0Internet 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.

http://www.microsoft.com/isaserver/default.mspx


.NET Framework 2.0 Communicator Web Access (2007 release) was developed using the Microsoft .NET Framework 2.0.

MMCMicrosoft Management Console (MMC) 2.0 and 3.0 are both supported.

ASP.NET 2.0Microsoft 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.

PlanningThis section discusses planning your Communicator Web Access (2007 release) deployment.

Planning for DeploymentThis 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 Recover y

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 DirectoryCommunicator 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 TopologyOverall 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 TopologyThe 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 TopologiesTwo types of Single Forest topologies are supported.

Single treeSingle forest topologies are supported and small and medium organizations typically deploy a single forest, single domain Active Directory topology.

Multi-treeA 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 TopologiesIn 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 TopologiesIn 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.

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.

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.

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

Cross Forest TopologyResource Forest TopologyCentral Forest Topology


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 IsolationTo 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 IsolationBy 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).

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.

NoteAlthough 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.


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 SeparationIn the next figure, the internal and remote user traffic is physically separated by deploying a dedicated server or array for each type of user.

http://technet2.microsoft.com/WindowsServer/en/library/25a310b6-c18f-4a7a-84f5-115e5de2260c1033.mspx?mfr=true

http://technet2.microsoft.com/WindowsServer/en/library/25a310b6-c18f-4a7a-84f5-115e5de2260c1033.mspx?mfr=true


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 TopologiesMany 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.

FederationWhen 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 http://office.microsoft.com/en-us/FX011450741033.aspx.

Custom Authentication, Including SSOSee the Communicator Web Access (2007 release) Authentication Guide.

IM ArchivingSee the archiving topic in the Office Communications Server 2007 documentation.

Communicator Web Access RequirementsThis section describes the hardware and software that are required to install Communicator Web Access (2007 release).

http://office.microsoft.com/en-us/FX011450741033.aspx



Table 2: Requirements for installing Communicator Web Access (2007 release)

Computer Component Required For

Active Directory Domain Controller

Microsoft Windows® 2000 Server SP4

Windows Server 2003

Operating system

Active Directory Directory service

DNS Name resolution

Office Communications Server 2007

Microsoft Office Communications Server 2007

Schema

File System NTFS partition Communicator Web Access (2007 release)

PKI Windows Server 2003 SP1 Enterprise certification authority (CA) (recommended) or a trusted third-party certification authority infrastructure

PKI Infrastructure

IIS 6.0 Certificate services Web enrollment support only

Communicator Web Access (2007 release, Beta 3) server

NTFS File system

Windows Server 2003 SP1 Operating system

.NET Framework 2.0 Communicator Web Access / ASP.NET

Windows Installer 3.0 (installed as part of Windows Server 2003 SP1)

Communicator Web Access /ASP.NET

IIS 6.0 Communicator Web Access (2007 release)

ASP.NET 2.0 Communicator Web Access (2007 release)

Office Communications Server 2007(Beta 3), Standard Edition or Enterprise Edition

Communicator Web Access (2007 release)

QFEsKB 915066

http://support.microsoft.com/kb/915066





Computer Component Required For

KB913297 http://support.microsoft.com/kb/913297



KB 917283 http://support.microsoft.com/kb/917283



KB 922770 http://support.microsoft.com/kb/922770



Client See Supported Client Operating Systems

Operating System

See Supported Client Browsers Browser/Client

Remote Computer

Communicator Web Access (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.

Remote management

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

Computer Action Required Permissions

Communicator Web Access (2007 release) server

Install Communicator Web Access (2007 release)

User must be a member of local Administrators group.

Activate Communicator Web Access (2007 release)

User must be member of the DomainAdmins group and the RTCUniversalServerAdmins group.

Create a virtual server User must be a member of local Administrators group.

Remote Computer

Install Communicator Web Access (2007 release) Manager on a remote computer

User must be a member of local Administrators group of the 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 SystemsThe 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

Supported Communicator Web Access (2007 release) Manager Operating SystemsYou 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

ImportantThe 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 Clients Supported Communicator Web Access (2007 release) clients are:

Table 4: Supported Browsers

Operating System

Browser Authentication Mechanism

Windows 2000 SP4

Microsoft Internet Explorer® 6 SP1

Forms-based

NTLM

Custom

NoteCommunicator Web Access (2007 release) Manager is not supported on any version of Windows 2000.

ImportantBefore 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.


Windows XP SP2 Internet Explorer 6 SP2

Windows Internet Explorer 7

Firefox 2.0.latest

Forms-based

NTLM

Kerberos

Custom

Windows Vista Internet Explorer 7

Firefox 2.0.latest

Forms-based

NTLM

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

NoteInstall 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 InteroperabilityThis section describes interoperability with various clients.

Office Communicator 2005 and Office Communicator 2007The 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 RequirementsThis section describes the requirements for deploying the Communicator Web Access (2007 release) server.

Infrastructure RequirementsThe 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 RequirementsThis 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.

http://www.microsoft.com/downloads/details.aspx?FamilyId=779DEDAA-2687-4452-901E-719CE6EC4E5A&displaylang=en


http://office.microsoft.com/en-us/assistance/HA011992481033.aspx


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.

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 RequirementsThe following table lists the minimum group membership requirements for Communicator Web Access (2007 release).

NoteInstalling Communicator Web Access on a workgroup computer is not supported and will cause an error during setup.


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 (created by Office Communications Server 2007)

The user activating the Communicator Web Access (2007 release) server must be logged on as a member of the RTCUniversalServerAdmins group.

Server Hardware RequirementsThis section discusses the hardware requirements for Communicator Web Access (2007 release).

Communicator Web Access server Hardware RequirementsThe 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 InformationThis 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

http://office.microsoft.com/en-us/FX011526591033.aspx.

Live Communications Server 2005 Standard Edition Deployment Guide at http://office.microsoft.com/en-us/FX011526591033.aspx.

Live Communications Server 2005 Enterprise Edition Deployment Guide at http://office.microsoft.com/en-us/FX011526591033.aspx.





Active Directory Office Communications Server 2007 Active Directory Preparation at

http://office.microsoft.com/en-us/FX011526591033.aspx.

DNS http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/

featured/dns/default.mspx

PKI and Certificates Office Communications Server 2007 Configuring Certificates at

http://www.microsoft.com/downloads/details.aspx?FamilyId=779DEDAA-2687-4452-901E-719CE6EC4E5A&displaylang=en.

Planning for Required CertificatesCommunicator 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/ws3pkibp.mspx.

Planning for Communicator Web Access CertificatesCommunicator 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.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx




http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/featured/dns/default.mspx

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/featured/dns/default.mspx



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

ImportantThe 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.


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 Web Access virtual server on a

machine named:

machine1.contoso.com

No SSO or SSL Web publishing

No load balancing with a VIP

FQDN: machine1.contoso.com

User enters: https://machine1.contoso.com

2 Two or more Communicator Web Access servers behind a load balancer with a VIP of: cwaVIP.contoso.com

No SSO or SSL Web publishing

Each Communicator Web Access machine behind the load balancer has an HTTPS cert with an FQDN of cwaVIP.contoso.com regardless of the machine name

User enters https://cwaVIP.contoso.com

3 Two or more Communicator Web Access servers behind a load balancer with a VIP of: cwaVIP.contoso.com

The VIP is SSL Web published with a reverse proxy using the URL of: cwaPub.contoso.com

Each Communicator Web Access machine behind the load balancer has an HTTPS cert with an FQDN of cwaVIP.contoso.com regardless of the machine name

The reverse proxy external network listener certificate is configured with an FQDN of: cwaPub.contoso.com

User enters https://cwaPub.contoso.com

4 Two or more Communicator Web Access servers behind a load

Each Communicator Web Access machine behind the load balancer has an HTTPS cert with an FQDN of cwaVIP.contoso.com regardless of

https://cwaVIP.contoso.com/


https://machine1.contoso.com/


balancer with a VIP of: cwaVIP.contoso.com

The VIP is SSL Web published with a reverse proxy using the URL of: cwaPub.contoso.com

the machine name

The reverse proxy external network listener certificate is configured with an FQDN of: cwaPub.contoso.com

User enters https://cwaPub.contoso.com

For information about setting a Subject Alternative Name, see Microsoft Office Communications Server 2007 Certificate Configuration at:


Both NetBIOS names and FQDNs are supported as the subject name of a certificate when you request a certificate from a Certification Authority. For more information on how to configure certificates by using the NetBIOS name, see: http://support.microsoft.com/default.aspx?scid=kb;en-us;887490.

Planning for Office Communications Server 2007 CertificatesMicrosoft 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 http://www.microsoft.com/downloads/details.aspx?FamilyId=779DEDAA-2687-4452-901E-719CE6EC4E5A&displaylang=en.

Planning for Hardware Load Balancing CertificatesFor 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



http://support.microsoft.com/default.aspx?scid=kb;en-us;887490

http://support.microsoft.com/default.aspx?scid=kb;en-us;887490





procedures, see “Digital Certificates for ISA Server 2004” at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/digitalcertificates.mspx.

Understanding Authentication and AuthorizationThe 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.

AuthorizationAuthorization 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.

AuthenticationCommunicator 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

NoteISA is not required. You can use any reverse proxy.

http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/digitalcertificates.mspx


Forms-Based AuthenticationForms-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) AuthenticationIntegrated 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 SSOSee the Office Communicator Web Access (2007 release) Authentication Guide.

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

NoteIf 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).


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.

Allowing Pop-up BlockersThe 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 CookiesCookies 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.

NoteUsing these URIs to code quick sign-in from other Web applications is not a supported scenario and may result in unexpected behavior.

https://server.contoso.com/quicksignin


Planning for Capacity RequirementsLoad 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 CapacityOver 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

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/2a4d9385-8cf8-4482-83d8-fa0adb8ffd96.mspx

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/2a4d9385-8cf8-4482-83d8-fa0adb8ffd96.mspx


you want to allow 10,000 connections, you would probably set the value at double this number (20,000).

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 http://office.microsoft.com/en-us/FX011450741033.aspx.

Planning for Performance RequirementsThis section discusses ways in which you can improve the performance and reliability of a Communicator Web Access (2007 release) deployment.

Planning for Network Performance RequirementsCommunicator 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.

ImportantDo 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.



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 PlanningThe 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 AvailabilityConfiguring 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 FailoverThis 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 MechanismCommunicator 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:

http://technet2.microsoft.com/windowsserver/en/library//45b2d082-234c-466b-9a41-7862f72a22881033.mspx

http://technet2.microsoft.com/windowsserver/en/library//45b2d082-234c-466b-9a41-7862f72a22881033.mspx


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 MechanismThe 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 FaultsThe 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 FailureIn 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 OverloadThe 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 InitializationDuring 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 BalancingThis 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.

Configuring Load Balancing TopologiesLoad 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.

NoteYou 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.


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/fd23047b-2b5a-42b3-aa14-2b7c1cd4be81.mspx

The TCP/IP Technical Reference at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/58511c7c-fb5c-4186-aa69-6f598d59a973.mspx

Supported Load Balancing ConfigurationsThis 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.

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


NoteMultihomed network adapters or multiple network adapters, each with a different IP address, are not supported for load balancing in Communicator Web Access (2007 release).

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/58511c7c-fb5c-4186-aa69-6f598d59a973.mspx

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/58511c7c-fb5c-4186-aa69-6f598d59a973.mspx

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/fd23047b-2b5a-42b3-aa14-2b7c1cd4be81.mspx

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/fd23047b-2b5a-42b3-aa14-2b7c1cd4be81.mspx


Type of NAT Supported Configurations

Direct Server Return One arm and one IP subnet


Two arms and one IP subnet


Unsupported Load Balancing ConfigurationsThe 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 AcceleratorsA 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 RequirementsThe 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 RequirementsThe 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 RecommendationsThe 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 RecoveryBefore 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 ServerIf 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 UsersThe 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 Communicator Web Access (2007 release)

1. Log on to the server with an account that is a member of the Administrators, DomainAdmins, and RTCUniversalServerAdmins groups.

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 Configuration of Clients to Sign-In to Communicator Web Access (2007 release)

1. In Active Directory, configure user accounts by enabling them for Live Communications, entering SIP names, and enabling remote user access.

2. Sign in to Communicator Web Access using the URI https://<server_ FQDN>

PreparationThis section describes how to prepare the server for Communicator Web Access (2007 release) installation and request the required certificates.


Preparing the Server for InstallationYour 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 installation1. 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 AccessThe 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 AuthorityIf 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/ws3pkibp.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 CAInstall certificate services and configure the server as an Enterprise Root Certification Authority.

To install certificate services and configure the server as an Enterprise root CA1. 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.


Download the CA certificate chainIf 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.

CautionThe 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.


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 CertificateThis 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 computer1. 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 CertificateRepeat 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>"

NoteIf 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

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

NoteActivating the server creates the account CWAService in Active Directory.


1. Under Step 3: Create a Virtual Server, click Create.


3. On the Select Virtual Server Type page, click Internal, and then click Next.

NoteThe first virtual server is created during this step. You can create additional virtual server in Communicator Web Access Manager (2007 release).


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 ConfigurationThis 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.


Creating Additional Virtual ServersAdditional 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 server1. 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.

NoteIf 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).



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.

To install Communicator Web Access at a command prompt1. 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:

NoteCommunicator Web Access (2007 release) does not support silent installation.


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 ServerThis section discusses using a reverse proxy to publish the external virtual server.

Using ISA Server 2006ISA 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.


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 EnabledThis 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.

CautionISA 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.

http://office.microsoft.com/en-us/assistance/HA100240791033.aspx


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.


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 software

ISA Server 2006 Standard Edition

Hardware

Processor http://www.microsoft.com/technet/isa/2006/installation_se/afdf7384-040e-4813-8e9a-aa05ddb7d4b6.mspxNetworking

Memory

Disk Space

Permissions

NoteWhen 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.

http://www.microsoft.com/technet/isa/2006/installation_se/afdf7384-040e-4813-8e9a-aa05ddb7d4b6.mspx




To install ISA Server 2006

Membership in Local Administrators

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.com

192.168.1.6 255.255.255.0


http://www.microsoft.com/isaserver/evaluation/trial/default.asp

http://www.microsoft.com/isaserver/2006/trial-software.mspx


cwa.contoso.com 192.168.1.5 255.255.255.0

“Internet” DNS 192.168.1.x 255.255.255.0

remote.contoso.com

N/A N/A

isa2006.contoso.com

10.10.10.55 255.255.255.0

webserver3.contoso.com

10.10.10.35 255.255.255.0

contosodc.contoso.com

10.10.10.1 255.255.255.0

client2.contoso.com

10.10.10.5 255.255.255.0

Setting up isa2006.contoso.com and webserver3.contoso.comFor 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.

See the Windows Server 2003 SP1 documentation.

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 address1. 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.

Install Windows Server 2003 SP1 on a server with two network adaptersConfigure Static IP Addresses for isa2006 Network Adapters


To configure the external network adapter on isa2006 with a static IP address1. Click Start, point to Settings, and click Network Connections.

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.

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 order1. Click Start, point to Settings, and click Network Connections.

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.

Now add the internal interface IP address to the DNS server.

To add the internal IP address to the DNS Server1. 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.

Set the isa2006 Interface Order Add isa2006 Internal IP address to the contosodc.contoso.com DNS Server


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.

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 Server1. 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. 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 lab1. 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.

Add isa2006 external IP address to the “Internet” DNS ServerInstall ISA Server 2006 Standard Edition

http://www.microsoft.com/isaserver/2006/trial-software.mspx


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. 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.

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.

Keep isa2006 in the WorkgroupConfigure Certificates on the ISA Server


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

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.

ImportantThe 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.

Create the Communicator Web Access external Virtual Server

http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/digitalcertificates.mspx


Figure 11: cwaExternal 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.

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.

Configure the ISA Server 2006 server to publish the external virtual serverSpecify the LDAP Verification Server


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.

Now let’s create the Web listener that listens on the external network interface card, and name it isaListener.

To create the Web listener1. 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.

Create the Web Listener



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.

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 site1. Click the Firewall Policy node in the scope pane of the ISA snap-in. Click the Tasks tab,

and then click Publish Web Sites.

Publish the Communicator Web Access cwaExternal virtual server


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.

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 4441. 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 DeploymentNow let’s test the deployment.

To test the Web published virtual server1. On client1.contoso.com, enter https://cwa.contoso.com in a supported browser.

Configure ISA Server to redirect external traffic to internal port 444

https://cwa.contoso.com/


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.

PICComplete 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 ServerYou must use a hardware load balancer when two or more Communicator Web Access (2007 release) servers are deployed.


Deploying a Hardware Load BalancerContent for this topic is not yet available.

Deploying the Additional ServerThis section describes deploying an additional server.

To add a Communicator Web Access server1. 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 SolutionsSee the Planning for High Availability section earlier in this guide for requirements.

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 environment1. 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 configurationTo 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.

Verifying Successful Load Balancing Configuration


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 FailureContent for this topic is not yet available.

Deploying a Backup ServerContent for this topic is not yet available.

Switching to the Backup ServerContent for this topic is not yet available.

Transitioning Service from a Failed Server to a Standby ServerIf 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 server1. 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 OperationsThis section describes options for managing, configuring, and monitoring Communicator Web Access (2007 release).

Managing Communicator Web Access ServersThis 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.

ImportantYou 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 ServersThe 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 PaneThe scope pane is the leftmost pane in the last figure.

Result PaneEach 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_LOGONS_SEC

Content for this topic is not yet available.

PERF_AUTH_NUM_SUCCESSFUL_IWA_LOGONS_SEC

PERF_SECURITY_NUM_TICKET_CHECK_FAILURES_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

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 server1. Right-click the physical server FQDN node in the scope pane.

2. Select Deactivate.

3. Follow the wizard steps.

Managing Virtual ServersDuring 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 FileYou 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.

Deactivating the Communicator Web Access server


To Export a Configuration file1. 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 FileAfter 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 file1. In Communicator Web Access Manager (2007 release), connect to the Communicator


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 propertiesWhen 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 URLYou can specify a legacy redirect URL from the virtual server Properties page, General tab.

To specify a legacy redirect URL1. In Communicator Web Access Manager (2007 release), connect to the Communicator


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 SettingsYou 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 settings1. In Communicator Web Access Manager (2007 release), connect to the Communicator


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 URLFor 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 settingsYou can specify connectivity settings from the virtual server Properties page, Connectivity tab.

To specify connectivity settings


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 virtual server node, and then select Properties.

3. On the Properties page, select the Connectivity tab.

4. On the Connectivity tab, make connectivity settings.

TracingTo 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 SearchUsers 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 Default

Value

Accepted Values

DefaultSearchField uint32

12 Values in binary (decimal), with definitions:

0001 (1): First name

0010 (2): Last name

0011 (3): First name; last name

0100 (4): Display name

0110 (6): Last name; display name

1000 (8): E-mail address

1010 (10): Last name; e-mail address

1100 (12) : Display name; e-mail address

DefaultSearchQuery

string OR AND, OR

SearchMaxServerResults

uint32

200 1 to 1000

SearchMaxClientResults

uint32

10 1 to 300

MaxQueuedSearches

uint32

80 1 to 500

The default search criteria, which you can change and the user can override, are:

Contact’s first name (given name)

Contact’s last name

Contact’s display name

Contact’s e-mail address

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:

Search Results


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

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.

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

System RequirementsUsing the MOM Pack

http://www.microsoft.com/management/mma/catalog.aspx


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

ImportantTo 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).


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.

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.

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 BrandingThis section discusses customizing the UI.

Customizing the User InterfaceSee the Corporate Branding section in this guide for information on customizing the UI for Corporate Branding.

Custom TabsCustom tabs are not supported in Communicator Web Access (2007 release).

Custom Presence StatesCustom 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).

Customizing the Management PackAdditional MOM Resources

http://www.microsoft.com/mom/downloads/2005/reskit/default.mspx

http://www.microsoft.com/management/mma/catalog.aspx

http://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/3e039637-4639-46f7-9f5f-518e0c04795e.mspx?mfr=true

http://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/3e039637-4639-46f7-9f5f-518e0c04795e.mspx?mfr=true

Creating Corporate BrandingYou 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 ForwardingWhen 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 Office Communicator 2007 and the PSTN

Can reply with instant message, or can deflect to PSTN number

Can receive call from Office Communicator 2007

Can reply with instant message


or voice mail

Can configure call forwarding to PSTN number, SIP URI, or voice mail

Cannot configure call forwarding

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 ControlsSee the Communicator Web Access (2007 release) SDK.

See the Communicator Web Access (2007 release) Authentication Guide.

SDKSee the Communicator Web Access (2007 release) SDK.


AJAX APISee the Communicator Web Access (2007 release) SDK.


Security ConsiderationsThis 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 users1. 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/[email protected] 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 AccountThe 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 AllocationContent for this topic is not yet available.


Authentication ModuleContent for this topic is not yet available.

Directory PermissionsFor 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 server1. 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 ClientsThis 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 client1. 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 Client1. 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 computer1. 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 AccessYou 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 user1. 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.


Configuring clients for external AccessClients 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 BrowsersFor 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.

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:

NoteIf 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.

Re-sign the JavaScript Code Signing Certificate


<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 JavaScript1. 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.

http://www.mozilla.org/projects/security/pki/nss/tools


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 TasksThis section describes performing user tasks.

Managing User OptionsYou manage user options from one of four tabs on the options page.

To manage user options1. From the main page, click Options on the Main menu.

http://www.mozilla.org/projects/security/components/jssec.html


2. On the Options page, select the tab containing the setting that you want to make.

3. Click OK.

Managing Call ForwardingYou 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 NumbersWhen 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/Region

Country Code Local Number International Number

China 86 (10) 55555555 +861055555555

France 33 06 87 71 23 45 +330687712345

United Kingdom 44 07700 954 321 +4407700954321

United States 1 (555) 555-5555 +15555555555

Venezuela 58 (0295) 416, 72, 16

+5802954167216


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 CoexistenceNew 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 ScenariosUp 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.

https://webserver3.contoso.com/

https://legacy.contoso.com/




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 TopologiesInstalling 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.

Installing Microsoft Office Communicator Web Access (2005 release) server on the same server as Office Communications Server 2007 is not supported.

Installing Microsoft Office Communicator Web Access (2007 release) server on the same server 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 Manager (2007 release)


Yes

Neither server


server

No



No


Yes




Yes

Neither server

Live Communications Server 2005 with SP1 server

Yes


No


server

Live Communications Server 2005 with SP1 server

Yes


server

No

MMC InteroperabilityThe 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 MigrationSide 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 releaseIn-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 release1. 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 PresenceBefore 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 upgrade1. 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.

3. In the Active Directory Users and Computers console tree, under Users, right-click the 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.

7. In the Active Directory Users and Computers console tree, under Users, right-click the 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 RedirectYou 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)


AppendixesAppendix 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: AccountsThis section describes the accounts required for Communicator Web Access (2007 release).

Accounts Created by Communicator Web Access (2007 release) SetupThe following account is created by the Communicator Web Access setup program.

Table 22: Account Created by Setup

Account Name Member Of

CWAService RTCHSUniversalServices

Administrator GroupsThe 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 group1. Log on to a computer as a member of the DomainAdmins group for the domain

where you will deploy Communicator Web Access.


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 group1. Log on to a computer as a member of the DomainAdmins group for the domain



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 group1. Log on to a computer as a member of the DomainAdmins group for the domain



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 example, CWAServerAdmins), and then click OK.


Read

Create All Child Objects

Delete all Child Objects

7. Click OK.

To grant permissions on the service account to the security group1. Log on to a computer as a member of the DomainAdmins group for the domain



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 example, CWAServerAdmins), and then click OK.


Read


Write

7. Click OK.

To add a user to the security group1. 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 changed?

Name Type Default Value

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


Can be 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 DefaultSearchQuery

string OR

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 FormPrivateTimeoutMin

uint32 240 (internal and external in 5887)

Yes FormPublicTimeoutMin

uint32 15 (internal and external in 5887)

No IP string <CWA_server IP>

Yes LegacyCWAServer string <2005 release server URL>

Yes MaxQueuedSearches

uint32 80

Accepted values: 1 to 80

No Name string W3SVC/##########

No Port uint32 <###>

Yes SearchMaxClientResults

uint32 10



Can be changed?


Yes SearchMaxServerResults

uint32 200


Yes ServerType string Internal ( or External)

TLSCertIssuer uint 8 array

Array[69] with index beginning at 1

TLSCertSN uint 8 array


Yes UserNotice string [Blank] (internal and external in 5887)

MSFT_CWAServerSetting

No Activated boolean true

No Name string Server FQDN

No TLSCertIssuer array of unit8


No TLSCertSN array of unit8


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

The Communicator Web Access Create Virtual Server Wizard creates two application pools for the first virtual server created:

Application Pools


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>

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.

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

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

Web Service ExtensionsImportantDo 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.

Default Communicator Web Access IIS 6.0 Settings

http://www.microsoft.com/technet/itsolutions/wssra/raguide/WebApplicationServices/igwaog_2.mspx

http://www.microsoft.com/technet/itsolutions/wssra/raguide/WebApplicationServices/igwaog_2.mspx


IP Address drop down list box (All Unassigned)

TCP Port text box 80

SSL Port text box 443

Connection Timeout text box 120

Enable HTTP Keep-Alives

check box selected

Enable logging check box selected

Active log format drop down list box W3C Extended Log File Format

Advanced Web Site Identification-Multiple identities for this Web Site

IP Address text box Default

TCP Port text box 80

Host Header Value text box <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 naming and rollover

check box unselected

Log file directory text box %windir%\system32\LogFiles

Logging Properties - Advanced Tab

Extended logging options

lots of check boxes

unselected Server Name (s-computername)

Bytes Sent (sc-bytes)

Bytes Received (cs-bytes)

Time Taken (time-taken)

Protocol Version (cs-version)

Host (cs-host)

Cookie (cs(Cookie))

Referer (cs(Referer))

selected All remaining check boxes

Performance Tab

Bandwidth Throttling check box unselected


Web site connections radio buttons (2) Unlimited radio button selected

ISAPI Filters Tab

Status text box Green up-pointing arrow

Filter Name text box cwaauth

Priority text box Low

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.

Configuring for Performance

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/71490aae-f444-443c-8b2a-520c2961408e.mspx

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/71490aae-f444-443c-8b2a-520c2961408e.mspx

cwa plandeploy

Documents