Ls Migrate Ocs2007 r2

Migrating from Microsoft Office Communications Server 2007 R2 to Microsoft Lync Server 2010

Microsoft Lync Server 2010Published: March 2012

This document is provided “as-is”. Information and views expressed in this document, including

URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real

association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any

Microsoft product. You may copy and use this document for your internal, reference purposes.

Copyright © 2012 Microsoft Corporation. All rights reserved.

Contents

Migration from Office Communications Server 2007 R2 to Lync Server 2010.............................1

Before You Begin the Migration................................................................................................2

Migration Process.................................................................................................................2

Migration Phases.................................................................................................................. 3

Summary of Migration Phases and Steps.........................................................................4

Planning for Client Migration...............................................................................................14

Client Planning Steps during Migration............................................................................14

Migration Considerations for Meetings............................................................................16

Client Version Check.......................................................................................................20

Migrating User Settings to Lync Server 2010..................................................................22

Client Interoperability.......................................................................................................35

Phase 1: Plan Your Migration from Office Communications Server 2007 R2.........................39

User Migration.................................................................................................................... 40

Migrating Archiving and Monitoring Servers........................................................................40

Administering Servers after Migration.................................................................................41

Migrating Multiple Sites and Pools......................................................................................41

Phase 2: Prepare for Migration..............................................................................................42

Apply Office Communications Server 2007 R2 Updates.....................................................42

Run Best Practices Analyzer...............................................................................................43

Back Up Systems and Data................................................................................................43

Configure Clients for Migration...........................................................................................44

Phase 3: Deploy Lync Server 2010 Pilot Pool........................................................................44

Lync Server 2010 Pilot Pool Architecture............................................................................45

Deploy Lync Server 2010 Pilot Pool....................................................................................46

Verify Pilot Pool Coexistence with Legacy Pool..................................................................50

Phase 4: Merge Topologies....................................................................................................53

Install WMI Backward Compatibility Package.....................................................................53

Merge Using Topology Builder Merge Wizard.....................................................................54

Import Policies and Settings...............................................................................................60

Verify Topology Information.................................................................................................62

Phase 5: Configure the Pilot Pool..........................................................................................65

Connect Pilot Pool to Legacy Edge Servers.......................................................................65

Authorize Connection to Office Communications Server 2007 R2 Edge Server.................68

Connect Pilot Pool to Legacy Mediation Server..................................................................68

Move Legacy User to Pilot Pool..........................................................................................70

Move Multiple Users...........................................................................................................74

Verify User Replication has Completed..............................................................................77

Phase 6: Verify Your Pilot Migration.......................................................................................78

Verify Configuration Settings...............................................................................................78

Running Functional Tests Against Workloads (optional).....................................................83

Phase 7: Add Lync Server 2010 Edge Server and Director to Pilot Pool................................87

Deploy Pilot Director and Edge Servers.............................................................................87

Phase 8: Move from Pilot Deployment into Production.........................................................93

Configure Federation Routes and Media Traffic.................................................................94

Verify Federation and Remote Access for External Users................................................103

Move Remaining Users to Lync Server 2010 (Office Communications Server 2007 R2

Migration)...................................................................................................................... 104

Move Multiple Users.........................................................................................................109

Migrate Response Groups................................................................................................112

Run Functional Tests for Response Groups......................................................................114

Move Exchange Unified Messaging Contact Objects........................................................115

Verify that all Exchange UM Contact Objects are Removed from the Legacy Pool..........116

Phase 9: Complete Post-Migration Tasks.............................................................................116

Migrate Dial-in Access Numbers.......................................................................................117

Enable Exchange 2010 SP1 Outlook Web App and IM Integration...................................119

Migrate Address Book.......................................................................................................121

Enable Remote Call Control.............................................................................................123

Remove an Authorized Host Entry................................................................................124

Remove Legacy Archiving and Monitoring Servers..........................................................124

Migrate Mediation Server..................................................................................................125

Configure Mediation Server...........................................................................................127

Change Voice Routes to use the new Lync Server 2010 Mediation Server...................128

Transition a collocated Mediation Server to a Stand-Alone Mediation Server (optional)

................................................................................................................................... 129

Migrate Applications Built on Microsoft Unified Communications Managed API (UCMA) 2.0

Core SDK...................................................................................................................... 130

Configure Trusted application servers..............................................................................130

Configure the Meeting Join Page......................................................................................132

Deploy Lync Server 2010 Clients......................................................................................134

Phase 10: Decommission Legacy Site.................................................................................134

Move Conference Directories...........................................................................................135

Decommissioning Servers and Pools...............................................................................136

Remove BackCompatSite.................................................................................................136

Phase 11: Migrate Communicator Web Access (2007 R2 Release) (Optional)....................138

Redeploy Communicator Web Access (2007 R2 Release) for IM and Presence..............141

Migrate Using Lync Server Management Shell (optional)....................................................142

Define Edge Server Input File...........................................................................................143

Create a Custom Edge Server Input File..........................................................................144

Run Migration Cmdlets.....................................................................................................148

Migration from Office Communications Server 2007 R2 to Lync Server 2010The topics in this section guide you through the process of migrating from Microsoft Office

Communications Server 2007 R2 to Microsoft Lync Server 2010. If you intend for your Office

Communications Server 2007 R2 deployment to coexist with a Lync Server 2010 deployment, this

guide also includes some essential information for operating in this mixed environment.

Important:

This document describes the steps generally required to accomplish each phase of

migration. It does not address every possible legacy deployment topology or every

possible migration scenario. Therefore, you may not need to perform every step

described, or you may need to perform additional steps, depending on your deployment.

This document also provides examples of verification steps. These verification steps are

provided to help you understand what you need to look for to ensure that each phase

completes successfully as you progress through your migration. Tailor these verification

steps to your specific migration process.

Tip:

Before you begin, watch the short video at http://go.microsoft.com/fwlink/?LinkId=206444

for an overview of the steps required to migrate from Microsoft Office Communicator

2007 R2 to Microsoft Lync Server 2010.

This guide provides information specific to upgrading your existing deployment. It does not

explain how to change your existing topology. This guide does not cover the implementation of

new features. When a detailed procedure is documented elsewhere, this guide directs you to the

appropriate document or document section.

Note:

This document does not address configuration specific to Enterprise Voice. The Lync

Server Response Group service and Dial-in conferencing are covered.

This document defines terms as specified in the following list.

migration

Moving your production deployment from a previous version of Office Communications

Server to Lync Server 2010.

upgrade

Installing a newer version of software on a server or client computer.

coexistence

The temporary environment that exists during migration when some functionality has

been migrated to Lync Server 2010 and other functionality still remains on a prior

version of Office Communications Server.

1

http://go.microsoft.com/fwlink/?LinkId=206444

interoperability

The ability of your deployment to operate successfully during the period of coexistence.

In This Section Before You Begin the Migration

Phase 1: Plan Your Migration from Office Communications Server 2007 R2

Phase 2: Prepare for Migration

Phase 3: Deploy Lync Server 2010 Pilot Pool

Phase 4: Merge Topologies

Phase 5: Configure the Pilot Pool

Phase 6: Verify Your Pilot Migration

Phase 7: Add Lync Server 2010 Edge Server and Director to Pilot Pool

Phase 8: Move from Pilot Deployment into Production

Phase 9: Complete Post-Migration Tasks

Phase 10: Decommission Legacy Site

Phase 11: Migrate Communicator Web Access (2007 R2 Release) (Optional)

Migrate Using Lync Server Management Shell (optional)

Before You Begin the MigrationBefore you begin, we recommend that you read this document and the guides listed below to

familiarize yourself with deploying various Lync Server 2010 roles.

Deploying Lync Server 2010 Enterprise Edition

Deploying Lync Server 2010 Standard Edition

Deploying Edge Servers

Planning for Clients and Devices in Lync Server 2010

In This Section

Migration Process

Migration Phases

Migration Process

The recommended and supported migration procedure for Microsoft Lync Server 2010 is the side-

by-side migration procedure. This topic describes why you should use side-by-side migration and

includes information about coexistence and an alternate migration method.

2


Side-By-Side Migration

In nearly every migration, you should use the side-by-side migration path. In a side-by-side

migration, you deploy a new server with Lync Server 2010 alongside a corresponding server that

is running Office Communications Server 2007 R2, and then you transfer operations to the new

server. If it becomes necessary to roll back to Office Communications Server 2007 R2, you have

only to shift operations back to the original servers. Be aware that in this situation any new

meetings scheduled with upgraded clients will not work, and the clients would also need to be

downgraded.

Coexistence Testing

After you have deployed Lync Server 2010 in parallel with Office Communications Server 2007

R2, the topology represents a coexistence testing state of the two deployments. Before migrating

to Lync Server 2010, it is important to test both deployments and ensure services are started;

each site can be administered, and clients can communicate with current and legacy users. Prior

to migrating all users in Phase 8: Move from Pilot Deployment into Production, it is very

important that you understand the state of each deployment and ensure that each deployment is

functional and working properly. Typically, this coexistence testing phase exists throughout the

pilot testing of Lync Server 2010. Legacy users are moved to Lync Server 2010 for a period of

time to ensure that application compatibility and features and functions are working properly. After

pilot testing, users and applications are moved to the production version of Lync Server 2010, and

the legacy pools and applications of Office Communications Server 2007 R2 are retired.

Migrate by using Lync Server Management Shell

The recommended method for migrating to Lync Server 2010 is described in Phase 4: Merge

Topologies. This method uses the Topology Builder merge wizard feature. An alternate method,

described in Migrate Using Lync Server Management Shell (optional), uses a command-line

approach to migrating. This method requires creating an input file with Edge Server information,

and running a series of Lync Server Management Shell commands. While this method replaces

the Topology Builder Merge wizard procedure described in Phase 4: Merge Topologies, the

recommended process is to use Topology Builder and follow the guidelines in Phase 4. However,

if you do plan to use this command-line based approach, read the topic thoroughly.

Migration Phases

In Microsoft Lync Server 2010, you define sites on your network that contain Lync Server 2010

components. A site is a set of computers that are well-connected by a high-speed, low-latency

network, such as a single local area network (LAN) or two networks connected by a high-speed

fiber optic network.

A Front End pool is a set of Front End Servers configured identically, that work together to provide

services for a common group of users. A pool provides scalability and failover capability to your

users. Each server in a pool must run an identical server role or roles. A Standard Edition server,

designed for small organizations, also defines a pool and runs on a single server. This enables

you to have Lync Server functionality for a lesser cost, but does not provide a true high-availability

solution.

3


The following phases describe the process of a pool migration from Office Communications

Server 2007 R2 to Lync Server 2010. For multiple sites containing multiple pools, each individual

pool should follow this phased approach.







Phase 7: Add Lync Server 2010 Edge Server and Director to Pilot Pool

Phase 8: Move from Pilot Deployment into Production


Phase 10: Decommission Legacy Site

Important:

This sequence is designed to minimize coexistence and interoperability issues during

migration. Implementing Lync Server 2010 in a different sequence is not supported.

See Also

Summary of Migration Phases and Steps

Summary of Migration Phases and Steps

This topic summarizes all of the phases and steps for migrating from Microsoft Office

Communicator 2007 R2 to Microsoft Lync Server 2010.


Before you begin the migration process, you need to be aware of and plan for special

considerations involved with several aspects of migration.

Phase 1 Migration Steps

Step Description Documentation

Prepare for user migration Consider identifying a few

users to be test users and a

group of users to be in the pilot

pool.

User Migration

Plan for migrating Archiving

and Monitoring Servers

Lync Server 2010 Archiving

and Monitoring Servers cannot

collect data from the legacy

deployment, and legacy

Archiving and Monitoring

Servers cannot collect data

Migrating Archiving and

Monitoring Servers

4



from the Lync Server 2010

deployment. If you want

archiving and monitoring

functionality during the

coexistence phase of

migration, you need to consider

several issues.

Plan for administering servers

after migration

During the coexistence phase

of migration, you need to use

the administrative tools that

correspond to the server

version you want to manage.

Administering Servers after

Migration

Plan for migrating multiple

pools and sites

Lync Server 2010 supports

multi-site and multi-pool

deployments. Migrating

multiple pools from the legacy

deployment requires some

special considerations.

Migrating Multiple Sites and

Pools


Before you begin migration, you must perform several preparatory tasks to ready your

environment for migration.



Apply Office Communicator

2007 R2 updates

Apply the Office

Communicator 2007 R2

updates that are required for

migration to Lync Server 2010.

Apply Office Communications

Server 2007 R2 Updates

Run Best Practices Analyzer Run the Best Practices

Analyzer to determine whether

your legacy deployment is

configured according to

Microsoft best practices.

Run Best Practices Analyzer

Back up systems and data Perform a full system backup

and document your existing

system, including an inventory

of user accounts.

Back Up Systems and Data

Configure clients for migration Configure clients on the Configure Clients for Migration

5



existing system in preparation

for migration.


Deploy a pilot pool that reflects your Lync Server architecture plans. You will merge topology

information and configuration settings from your existing deployment into this pilot pool.



Determine the pilot pool

architecture

Review the reference topology

that is used for this document.

The steps described in this

document are based on the

reference topology. Your steps

may vary depending on your

Lync Server deployment.

Lync Server 2010 Pilot Pool

Architecture

Deploy the pilot pool Deploy a pilot pool that

includes the same features

and workloads that are in your

legacy deployment. If you

want to continue archiving and

monitoring throughout

migration, include these

features in the pilot

deployment.

Deploy Lync Server 2010 Pilot

Pool

Verify pool coexistence After you deploy the pilot pool

and before you begin to

migrate to Lync Server, view

pool information to verify that

the legacy pool and pilot pool

coexist.

Verify Pilot Pool Coexistence

with Legacy Pool


You merge your legacy pool with your Lync Server 2010 pilot pool by first merging topology

information and then importing legacy policies and configuration settings.



Install Windows Install the WMI Backward Install WMI Backward

6



Management Instrumentation

(WMI) Backward

Compatibility Package

Compatibility Package as a

prerequisite to running the

Topology Builder Merge wizard.

Compatibility Package

Merge topologies by using

Topology Builder

Run the Topology Builder Merge

wizard to merge your legacy

topology information with your

Lync Server topology.

Merge Using Topology

Builder Merge Wizard

Import policies and settings Run the Import-

CsLegacyConfiguration cmdlet

to import policies, voice routes, dial

plans, Communicator Web Access

URLs, and dial-in access numbers

to Lync Server, and then verify that

all the policies were imported.

Import Policies and Settings

Verify topology information View the topology in Topology

Builder to verify that the merge

was successful. Run the Get-

CsConferenceDirectory cmdlet to

verify that conference directory

information was imported.

Verify Topology Information


Configure the pilot pool so that users can communicate between the legacy pool and pilot pool,

and move some users to the pilot pool.



Connect pilot pool to legacy

Edge Server

Configure Lync Server to use

the federated route that is used

by the legacy pool.

Connect Pilot Pool to Legacy

Edge Servers

Authorize connection to

legacy Edge Server

Add the Lync Server Front End

Server or Standard Edition

server and Director in your pilot

pool to the list of servers that

are authorized to connect to the

legacy Edge Server. This step

is required for audio/visual

(A/V) conferencing to work for

users who join by using the

Authorize Connection to Office

Communications Server 2007

R2 Edge Server

7



legacy Edge Server.

Connect pilot pool to legacy

Mediation Server

Configure Lync Server to use

the Mediation Server that is

used by the legacy pool.

Connect Pilot Pool to Legacy

Mediation Server

Move some users to pilot

pool

Use Lync Server 2010 Control

Panel or Lync Server

Management Shell to move a

few users to the pilot pool as

test users. Before using the

Move-CsLegacyUser cmdlet,

verify that user replication has

successfully completed.

Verify User Replication has

Completed

Move Legacy User to Pilot

Pool

Move multiple users to pilot

pool

You can move groups of users

to the Lync Server 2010 pilot

pool. Before using the Move-

CsLegacyUser cmdlet, verify

that user replication has

successfully completed.


Completed

Move Multiple Users


After merging information and configuring the pilot pool, verify that configuration settings imported

correctly and that the pilot pool functions as expected before continuing the migration process.



Verify configuration settings Verify that the policies and

settings in your legacy pool

were imported to Lync Server.

Verify Configuration Settings

Test pilot pool functionality Run some functional tests

with pilot users to ensure that

the pilot pool functions as

expected.

Running Functional Tests

Against Workloads (optional)

Phase 7: Add Edge Server and Director

Add an Edge Server and a Director to the pilot pool.

8




Deploy pilot Director and

Edge Servers

Define a Director pool and an

Edge Server pool. Install the

files on the Director and Edge

Servers, configure certificates,

and start services, and then

verify that the pilot pool and

legacy pool are running

correctly and that you can

administer them.

Deploy Pilot Director and Edge

Servers

Phase 8: Move from Pilot Deployment to Production

Finalize route configuration, move users, and migrate response groups and Exchange Unified

Messaging (UM) contacts to the pilot pool.



Configure federation routes

and media traffic

Transition the federation route

and media traffic route from the

legacy deployment to the Lync

Server Edge Server and

Director:

1. Remove the legacy

federation association from

the Lync Server site.

2. Configure the legacy Edge

Server as a non-federating

Edge Server.

3. Configure certificates on

the Lync Server Edge

Server.

4. Change the legacy

federation route to use the

Lync Server Edge Server.

5. Update the Lync

Server Edge Server

federation next hop server.

6. Configure the Lync

Server Edge Server

outbound media path.

Configure Federation Routes

and Media Traffic

9



7. Enable Lync Server Edge

Server federation, publish

the configuration changes,

and then configure the

Lync Server Edge Server.

Verify federation and remote

access for external users

Run functional tests to verify

that federation performs as

expected, testing with each

type of external user supported

by your organization.

Verify Federation and Remote

Access for External Users

Move remaining users Move the remaining users from

the legacy pool to the pilot pool

and verify their assigned

conference policy. Before using

the Move-CsLegacyUser

cmdlet, verify that user

replication has successfully

completed.


Completed

Move Remaining Users to Lync

Server 2010 (Office

Communications Server 2007

R2 Migration)

Move Multiple Users

Migrate response groups Ensure that the Response

Group application is installed in

your pilot pool, and then move

Response Group settings from

the legacy pool to the Lync

Server pool. Verify that all

agent groups, queues, and

workflows were imported to

Lync Server.

Migrate Response Groups

Test response groups Run some functional tests to

verify that the imported

response groups function as

expected.

Run Functional Tests for

Response Groups

Move Exchange Unified

Messaging (UM) contact

objects

Migrate Auto Attendant and

Subscriber Access contact

objects to the Lync Server pool,

and then run a script on the

server running Microsoft

Exchange to add them to the

Exchange UM IP gateways and

hunt groups.

Move Exchange Unified

Messaging (UM) Contact

Objects

10



Verify that Exchange UM

contact objects are removed

from the legacy pool

On the legacy pool, verify that

no Exchange UM contact

objects remain.

Verify that all Exchange UM

Contact Objects are Removed

from the Legacy Pool


Migrate and configure additional features, remove legacy Archiving and Monitoring Servers,

configure Mediation Server, and deploy Lync Server clients.



Migrate dial-in access

numbers

Move the contact objects for

dial-in access numbers to Lync

Server.

Migrate Dial-in Access

Numbers

Enable Microsoft Exchange

2010 SP1 Outlook Web App

and IM integration

Create a trusted application

pool, and add the Exchange

2010 SP1 Client Access

Server (CAS) as a trusted

application server.

Enable Exchange 2010 SP1

Outlook Web App and IM

Integration

Migrate Address Book If you customized your legacy

deployment for Address Book

by grouping Address Book

entries by organizational unit

(OU) or by customizing

Address Book normalization

rules, configure Lync Server for

these customizations. If you

did not customize Address

Book, Address Book is

migrated to Lync Server along

with the rest of your topology

and no other configuration is

required.

Migrate Address Book

Enable remote call control Configure Lync Server for

routing CSTA requests and

configure Lync Server users for

remote call control. (Installing a

SIP/CSTA gateway for remote

call control is a prerequisite to

migration.)

Enable Remote Call Control

11



Remove legacy Archiving and

Monitoring Servers

After all users are removed

from all legacy pools, Archiving

and Monitoring Servers can be

removed from the legacy

deployment.

Remove Legacy Archiving and

Monitoring Servers

Migrate Mediation Server After all users are moved to

Lync Server, configure the

Lync Server Mediation Server.

You must upgrade or replace

legacy gateways, configure the

Lync Server Mediation Server,

and change voice routes to

use the new Mediation Server.

Migrate Mediation Server

Use applications built on

Microsoft Unified

Communications Managed API

(UCMA) 2.0 Core SDK

Lync Server 2010 works with

Microsoft Unified


(UCMA) 3.0 Core SDK, but

you can enable users homed

on a Lync Server pool to use a

UCMA 2.0 application homed

on a legacy pool during the

coexistence phase.

Migrate Applications Built on

Microsoft Unified


(UCMA) 2.0 Core SDK

Configure trusted application

servers

If you create a new trusted

application server after you

merge the legacy topology with

the Lync Server topology, set

the next hop pool as a Lync

Server pool.

Configure Trusted application

servers

Configure the Meeting Join

page


page for the Lync Server

clients that can be used to join

a scheduled meeting.


Page

Deploy clients Configure policies for users

and clients, and deploy Lync

Server 2010 clients.

Deploy Lync Server 2010

Clients

Phase 10: Decommission the Legacy Site

When everything is moved from the legacy pool, decommission the pool and servers.

12




Move conference

directories

Move conference directories to Lync

Server. The Import-

CsLegacyConferenceDirectory

cmdlet run during the merge imports

only information to support

interoperability. Conference

directories must be moved to the Lync

Server pool before the legacy pool is

decommissioned or dial-in

conferences will no longer work.

Move Conference

Directories

Decommission legacy

servers and pools

Decommission legacy pools and

remove legacy servers and server

roles.

Decommissioning Servers

and Pools

Remove BackCompat site

in Topology Builder

After all the pools are deactivated,

remove the BackCompat site.

Remove BackCompatSite

Phase 11: Migrate Communicator Web Access (2007 R2 Release) Functionality (Optional)

Lync Web App does not support instant messaging (IM) and presence. If you need browser-

based IM and presence, you need to maintain a server running Communicator Web Access. If

you do not need IM and presence for browser scenarios, you can omit this phase.



Redeploy Communicator Web

Access

Decommission Communicator

Web Access when you

decommission your legacy

pools. Then redeploy

Communicator Web Access. In

the Deployment Wizard, select

a Lync Server 2010 pool as the

next hop server to support

anonymous users. After

redeploying Communicator

Web Access, use Topology

Builder to merge and publish

your topology.

Redeploy Communicator Web

Access (2007 R2 Release) for

IM and Presence

13


Planning for Client Migration

This section outlines client-related considerations when planning a migration to Microsoft Lync

Server 2010. It discusses the user impact of migrating meetings and the type of information that

is migrated. Because a migration process often requires a period of time during which various

client versions coexist, this section also provides information about planning for client

compatibility and interoperability.

In This Section

Client Planning Steps during Migration

Migration Considerations for Meetings

Client Version Check

Migrating User Settings to Lync Server 2010

Client Interoperability

Client Planning Steps during Migration

This topic discusses important planning considerations for migration and outlines the

recommended client-related steps during the migration process. To facilitate a smooth migration

to Microsoft Lync Server 2010, you should consider how users will be affected during the period

of coexistence, deploy the appropriate clients to maximize productivity, and ensure that user

settings are properly migrated or configured in the new environment.

Client Considerations for Migration

To help minimize the impact of migration on user productivity, include the following client-related

considerations during the migration planning phases.

In Lync Server 2010, most of the Group Policy settings used in previous Office

Communications Server releases are now controlled by in-band provisioning client policies

that are server-based. You can manage these settings by using the Lync Server Control

Panel, the Windows PowerShell command-line interface, or both. To understand how Group

Policy settings in your existing deployment map to Lync Server 2010 settings, see Migrating

User Settings to Lync Server 2010.

Office Communicator 2007 R2 client bootstrapping policies are also used by Lync Server

2010. It is only necessary to configure these policies if you want to change existing policies or

if you want to set new policies. If you do not plan to configure client bootstrapping policies, or

you want legacy client bootstrapping policies to remain in effect, no action is necessary. For

details, see Migrating User Settings to Lync Server 2010.

Determine how Lync Server 2010 clients will interact with previous client versions. For details,

see Client Interoperability.

For manager/delegate support, both managers and delegates must be migrated to Lync 2010

at the same time.

If you are deploying conferencing, understand how meetings have changed in Lync Server

2010 and determine how migration will affect new and existing meetings. For details, see

Migration Considerations for Meetings.

14


Decide how users who do not have Lync 2010 installed will participate in Lync Server 2010

meetings and configure the meeting join page accordingly. For example, in addition to Lync

Web App, you can allow users to join meetings by using Microsoft Lync 2010 Attendee or a

previous version of Communicator. For details, see Configure the Meeting Join Page.

Verify that the Enhanced Presence bit is set to True on Office Communications Server before

you run the Move-CsLegacyUser cmdlet to migrate users. If this bit is not set to True, an

error occurs during the user migration. When you set Enhanced Presence to true and rerun

the cmdlet, users lose their blocked Contacts lists.

Tip:

You can verify the Enhanced Presence bit by using the Snooper tool that is available

in the Office Communications Server 2007 R2 Resource Kit. Run Snooper on a

computer running Office Communications Server 2007 R2. Click Reports, click

Conferencing and Presence Reports, type the user information, and then click

Generate Report. In the results, verify that RichMode is set to True.

Users who use Office Communicator 2007 or Office Communicator 2007 R2 (rich presence

clients) need to log on to Office Communications Server at least once before you migrate

users. If a user has not logged on to Office Communications Server before you migrate users,

the user will lose the blocked Contacts list.

Overview of Client-Related Tasks during the Migration Process

Phases 2 and 9 of the migration process include specific steps for migrating clients, which are

summarized in this topic. For details, see the steps for these phases in the migration process.

In Phase 2: Prepare for Migration, use client version rules on your existing server to allow only

clients with the most current updates to sign in, and to block Lync Server 2010 clients from

signing in.

In Phase 9: Complete Post-Migration Tasks, after users have been migrated to Lync Server

2010, do the following:

1. Use client version rules on your new Lync Server 2010 server to allow only clients with the

most current updates installed to sign in.

2. If necessary, configure the Group Policy settings that are required for client bootstrapping.

For details, see Key Client Policies and Settings. Configuration of these settings is only

necessary if you want to change existing client bootstrapping policies or if you want to set

new client bootstrapping policies. If you do not plan to configure client bootstrapping policies,

or you want legacy client bootstrapping policies to remain in effect, no action is necessary.

3. Configure other user and client policies for specific users or groups of users by using

Microsoft Lync Server 2010 Control Panel, Windows PowerShell command-line interface, or

both.

4. Deploy the latest version of Lync Server 2010 along with the latest cumulative updates.

5. (Optional) If your organization requires Lync 2010 enhanced presence privacy mode, after

migration is complete, define a Client Version Policy Rule to prevent earlier client versions

from signing in. Then, enable enhanced presence privacy mode. For details, see Configuring

Enhanced Presence Privacy Mode in the Deployment documentation.

15


Important:

Do not enable Lync 2010 enhanced presence privacy mode until every user on a

given server pool has the most current client versions installed. Lync 2010 privacy

settings are not honored by earlier client versions. If earlier clients are allowed to sign

in, a Lync 2010 user’s availability, contact information, or photo could be viewed by

someone who has not been authorized to do so. Additionally, a Lync 2010 user’s

privacy management options are reset if that user subsequently logs on with an

earlier version of the client.

6. (Optional) If you use remote call control, create a group policy to set the Enable integration

with your phone system option in the Phone integration section in Lync 2010.

Migration Considerations for Meetings

The following topics are discussed in this section:

Changes to meetings in Microsoft Lync Server 2010

Migrating users based on their conferencing needs

Migrating existing meetings and meeting content

User experience during migration

Microsoft Lync 2010 compatibility with meetings on earlier server versions

Configuring the meeting join page

Changes to Meetings in Lync Server 2010

In earlier versions of Office Communications Server, there are two types of meetings:

Conference calls (Lync 2010 client, conf:// URL prefix)

Web conferences (Live Meeting client, meet:// URL prefix)

In Microsoft Lync Server 2010, all newly-scheduled meetings use Lync 2010 as the primary client,

and have a URL prefix of https://.

During migration, Lync Server 2010 fully supports the earlier meeting types:

Previously scheduled conference calls and Live Meeting web conferences are moved to the

Lync Server 2010 server.

For users who have been migrated to the Lync Server 2010 server but do not have Lync 2010

installed, previous meeting types can still be modified or created.

For details, see the “User Experience During Migration” section later in this topic.

Default Lync Server 2010 Meeting Options

In earlier versions of Office Communications Server, scheduled meetings allowed anonymous

users to attend meetings by default. In Lync Server 2010, meeting access for scheduled meetings

is set to “My company” by default. Anonymous users and participants who use dial-in

conferencing but for whom authentication fails are transferred to the lobby. Presenters can admit

these users to the meeting.

16


However, for unscheduled Lync Server meetings, including Meet Now meetings, participant

access is set to Everyone, including people outside my company by default, so anonymous

users can join without waiting in the lobby.

Lync Server 2010 Meeting Clients

You can use the following clients to join meetings scheduled through the Online Meeting Add-in

for Microsoft Lync 2010:

Lync 2010

Microsoft Lync 2010 Attendant

Microsoft Lync Web App

Microsoft Lync 2010 Attendee

Microsoft Office Communicator 2007 and Microsoft Office Communicator 2007 R2 (that is,

only if the administrator has enabled them. For details, see the “Configuring the Meeting Join

Page” section later in this topic.)

You cannot use the following clients to join meetings scheduled through the Online Meeting Add-

in for Lync 2010:

Communicator Web Access

Microsoft Office Live Meeting 2007

The Lync Web App or Lync 2010 Attendee are the recommended alternatives for users who do

not have Lync 2010 or Lync 2010 Attendant installed.

Migrating Users Based on Their Conferencing Needs

Consider migrating frequent meeting organizers early in the process so that they can take

advantage of the new sharing, collaboration, and lobby management features of Lync Server

2010.

For users who need web conferencing features specific to Live Meeting—particularly support for

large meetings and break-out rooms—you have the following options:

Advise organizers to use the Live Meeting service, if available in your organization.

Leave the organizers homed on the earlier version of Office Communications Server, so they

can continue to schedule server-based Live Meeting web conferences.

Migrating Existing Meetings and Meeting Content

When a user account is moved from Microsoft Office Communications Server 2007 R2 to a Lync

Server 2010 server, the following information moves along with the user account:

Meetings already scheduled by the user. This includes Communicator conference calls

(conf:// URL prefix) and Live Meeting conferences (meet:// URL prefix).

The user’s personal identification number (PIN). The user’s current PIN continues to

work until it expires or the user requests a new PIN.

The following information does not move to the new server:

Meeting content. You should advise meeting organizers to reload content into their

scheduled meetings after migration.

17


Notes:

When the Online Meeting Add-in for Lync 2010 is first used to schedule new meetings, a new

default conference identifier is created. The default conference identifier is the http address and

conference ID that is ordinarily reused for all scheduled meetings.

This should only be an issue for organizers who memorize their conference identifier and give it

out to others. Most meeting attendees will join by clicking the join link in the new meeting

invitation, and previously scheduled Office Communications Server 2007 R2 meetings will

continue to work.

User Experience During Migration

This section discusses the conferencing experience of users migrated to Lync Server 2010 both

before and after Lync 2010 is installed.

Before Lync 2010 Is Installed

After a user is migrated to the Lync Server 2010 server, but before new clients are installed, the

following Office Communications Server 2007 R2 client functionality continues to work on the

new server:

All scheduling functionality in the Conferencing Add-in for Microsoft Office Outlook

All meeting links in previously sent meeting invitations

Meet Now conferences in Office Communicator 2007 R2

Escalation to Live Meeting (Share Information Using Live Meeting) from Office Communicator

2007 R2

Dial-in conferencing numbers

Note:

Existing dial-in conferencing numbers work whether the meeting is hosted on Office

Communicator 2007 R2 server or a Lync Server 2010 server. However, the latest

Office Communicator 2007 R2 cumulative update is required on the Office

Communicator 2007 R2 server pools.

After Lync 2010 Is Installed

When a migrated user installs Lync 2010, the Online Meeting Add-in for Lync 2010 is installed

too. This has the following effects:

All subsequently scheduled meetings use the new meeting format, which uses an https://

address instead of the legacy meet:// Live Meeting address.

For an existing meeting that is migrated to Lync Server 2010, the organizer can modify most

meeting details as usual. However, if the organizer wants to change the meeting end date,

end time, participant list, or the meeting subject, the organizer must reschedule the meeting

in the new Lync 2010 meeting format. When the organizer changes any of these details, the

add-in will prompt the organizer to manually reschedule the meeting and send an updated

meeting invitation to all participants.

In an IT-managed deployment of Lync 2010, the administrator has the option of uninstalling

the Conferencing Add-in for Microsoft Office Outlook, which is used to schedule Live Meeting

18


server and service-based meetings. However, you may have users who need to continue to

schedule Live Meeting service meetings. In this case, you can allow both add-ins to coexist.

The following meeting functionality continues to work for users who have installed Lync 2010:

All meeting links in previously sent meeting invitations, including Communicator conference

calls (conf:// URL prefix) and Live Meeting conferences (meet:// URL prefix).

Audio conferencing information in previously sent meeting invitations, including meeting IDs.

Sharing functionality in Office Communicator 2007 R2 meetings.

Sharing functionality in peer-to-peer conversations or conferences that include Office

Communicator 2007 R2 users.

Note:

In previous versions of Office Communications Server, all users could initiate desktop

sharing in meetings. In Lync Server 2010 only meeting presenters can initiate

desktop sharing. In recurring meetings that are migrated to Lync Server 2010,

attendees can no longer initiate desktop sharing. If they need to do so, they must

have a meeting presenter promote them to presenter so that they can initiate desktop

sharing.

Meetings with Federated Organizations that Use Previous Clients

Users in federated organizations who are using Microsoft Office Communicator 2007 or Microsoft

Office Communicator 2005 clients cannot join Lync Server 2010 meetings in your organization if

those meetings are locked by the organizer. You need to reschedule these meetings in Lync

Server 2010 so that when federated participants join the meeting by using the new https://

meeting URL, they have the option of using either Lync 2010 Attendee or Lync Web App.

Lync 2010 Compatibility with Meetings on Earlier Versions of Office Communications Server

Users who have Lync 2010 installed can attend meetings hosted on earlier versions of Office

Communications Server, but the following considerations apply:

For Communicator meetings, new Lync 2010 features are not available

For Live Meeting web conferences, Lync 2010 users must also have the Live Meeting client

installed in order to attend. The email invitation contains instructions for installing the Live

Meeting client.

Configuring the Meeting Join Page

You can control the clients that are available for joining scheduled Lync Server 2010 meetings by

configuring the meeting join page. When a user clicks a meeting link, the meeting join page

detects whether a client is already installed on the user’s computer. If a client is already installed,

the default client opens and joins the meeting. If a client is not installed, the meeting join page

displays options for joining the meeting with alternate clients.

The meeting join page always contains the option to use Microsoft Lync Web App. In addition to

this option, you can decide whether to show links for Microsoft Lync 2010 Attendee or a previous

version of Communicator. The scenarios are as follows:

19


If Lync 2010 or Microsoft Lync 2010 Attendant is installed, the client starts and joins the

meeting..

If neither Lync 2010 nor Lync 2010 Attendant is installed and Lync 2010 Attendee is installed,

Lync 2010 Attendee starts..

If no Lync Server 2010 client is installed, the meeting join page appears and gives the user

the following options:

Use Lync Web App

Download Lync 2010 Attendee (this link is hidden by default)

Use a previous version of Communicator (this link is hidden by default)

For the scenario in which neither Lync 2010 nor Lync 2010 Attendee is installed, you can

configure the meeting join page in Microsoft Lync Server 2010 Control Panel (that is, under the

Security, Web Service settings). You can also configure these same settings by using the New-

CsWebServiceConfiguration or Set-CsWebServiceConfiguration Windows PowerShell

cmdlets with the ShowDownloadCommunicatorAttendeeLink and

ShowJoinUsingLegacyClientLink parameters.

Client Version Check

The Client Version Check application provides you with a way to define a set of rules that specify

the version of clients that are supported in your Microsoft Lync Server 2010 environment. When

two clients of differing versions interact, the features that are available to either client can be

limited by the capabilities of the other released client. To make the greatest use of features

included in Lync Server 2010 and to improve the overall user experience, you can use the Client

Version Check to restrict the client versions that are used in your Lync Server environment.

Using Client Version Policy to Specify Supported and Restricted Versions

You can create client version policies to explicitly support or restrict client versions. When a

supported client logs on or is invited to a session, the client version policy checks the SIP User

Agent header to determine the client version. Depending on the version of the client, and the

rules that you have configured, the client version policy does one of the following:

Allows the client to log on to the pool (that is, the Allow option).

Allows Lync 2010 clients to log on and receive updates from Windows Server Update Service

or Microsoft Update (that is, the Allow and Upgrade option). This action is available only for

Microsoft Lync 2010 (where User Agent is OC).

Note:

Selecting this action causes a notification to appear the next time a user signs in to

Lync 2010. The notification states that an update is available, even if updates have

not yet been released to Windows Server Update Service or Microsoft Update. To

avoid confusion, you should choose this action only after updates become available.

Allows the client to log on and presents the user with a message that indicates the user can

upgrade their client. The message comes with the URL that you specify, and the user can

click that URL to go to the page represented (that is, the Allow with URL option) and

upgrade their client.

20


Prevents the client from logging on to the pool (that is, the Block option).

Prevents Lync 2010 clients from logging on and allows the client to receive updates from

Windows Server Update Service or Microsoft Update (that is, the Block and Upgrade

option). This action is available only for Microsoft Lync 2010 (where User Agent is OC).

Prevents the client from logging on and presents the user with a message that indicates the

user is using a client that is not supported. The message comes with the URL that you

specify, and the user can click that URL to go to the page represented (that is, the Block with

URL option).

Each pool maintains a client version control list that you configure. This list contains rules that

specify the client versions you want to filter and the appropriate action for each client version. The

Client Version Check can act according to a specific client version number. It can also act

according to a client version that is less than or equal to or greater than or equal to the version

number that you specify. The Client Version Check also includes a configuration option that

specifies the default action for clients that are not included in the client version control list.

When you configure the Client Version Check, you specify the way in which clients are handled

during logon. The Client Version Check provides options for configuring the following:

User Agent header. This is the name of the agent for the client version.

Identity. This is the scope that the rule should be applied to. If multiple rules with different

levels of scope are triggered, the scope with the lowest level of granularity is applied. For

example, if a service level rules states that the client should be blocked, but a user level rule

also states that the client should be allowed, the client will be allowed as a user level rule is

the most granular.

Note:

Because anonymous users are not associated with a user, site, or service,

anonymous users are affected by global-level policies only.

Client version number. This includes the major version number, the minor version number,

the build number, and the number that corresponds to the updated release of the client. The

number is presented in the following format: <major version>.<minor version>.<build

number>.<update number>.

Matching rules. These specify the comparison operations to perform to identify the specific

version or range of versions of the client to which the filtering action is to apply.

Action to take based on client version. Available values are Allow, Block, Allow with

URL, Block with URL, Allow and Upgrade, and Block and Upgrade.

Client download URL. This is used only for the Block with URL and Allow with URL

options.

A default list of rules is installed when you install Lync Server 2010. To customize the set up rules

for your deployment, you can edit an existing rule, or you can create a new rule. If you do not

want to block earlier version of the client, you will need to modify this list.

21


Note:

The default list of rules automatically blocks earlier versions of Microsoft Office

Communicator and Microsoft Office Communicator Phone Edition that try to connect to

Lync Server 2010. If you would like to change this behavior, you can create a new rule to

allow earlier clients to connect to the Lync Server 2010 server and then add this to the

top of the list. Although you can also edit the default rules to allow earlier clients to

connect, we do not recommend this approach.

Important:

The rules are listed in their order of precedence. For example, if you have a rule that

allows Communicator clients with a version 1.5 or later to connect, followed by a rule

blocking clients earlier than version 2.0, the first rule will match and thus takes

precedence. As a result, Communicator 1.5 clients can connect.

Client version checks in the version control list act on specific criteria. However, you also need to

configure a default rule to apply to clients that do not match any other client version rule,

specifying one of the following: Allow, Block, or Block with URL.

Migrating User Settings to Lync Server 2010

This topic provides the information you need to successfully migrate user and client settings from

Microsoft Office Communications Server 2007 R2 to Lync Server 2010.

In Microsoft Lync Server 2010, most of the group policy settings used in previous versions of

Office Communications Server are now controlled by server-based, or in-band provisioning, client

policies. In addition, certain Group Policy settings are used for client bootstrapping.

This topic contains information about the following settings:

Group Policy settings required for client bootstrapping

Obsolete or superseded Office Communicator 2007 R2 group policies

Lync Server 2010 in-band provisioning setting and Windows PowerShell command-line

interface cmdlet equivalents for Office Communicator 2007 R2 Group Policy settings

Selected new Lync Server 2010 user and client settings

Group Policy Settings for Client Bootstrapping

Because Office Communicator 2007 R2 client bootstrapping policies are also used by Lync 2010,

it is only necessary to configure them if you want to change existing policies or if you want to set

new policies. If you do not plan to configure client bootstrapping policies, or you want legacy

client bootstrapping policies to remain in effect, no action is necessary.

22


Group Policies Needed for Client Bootstrapping

Group Policy setting Description

ConfigurationMode Specify how Microsoft Lync 2010 identifies the

transport and server to use during sign-in. If

you enable this policy setting, you must specify

ServerAddressInternal, ServerAddressExternal,

and Transport.

ConfigurationMode\ServerAddressExternal If you enable ConfigurationMode, you must

configure this setting, which specifies the

server name used by clients and federated

contacts when connecting from outside the

external firewall.

ConfigurationMode\ServerAddressInternal If you enable ConfigurationMode, you must

configure this setting, which specifies the

server name used when clients connect from

inside the organization’s firewall.

ConfigurationMode\Transport If you enable ConfigurationMode, you must

specify Transport Layer Security (TLS).

Transmission Control Protocol (TCP) is no

longer supported.

ConfiguredServerCheckValues Specifies a list of server version names

separated by semi-colons that Microsoft Lync

Server 2010 will log on to, in addition to the

server versions that are supported by default.

DisableHttpConnect During sign-in, Lync Server 2010 attempts to

connect to the server using TLS. If the attempt

is not successful, Lync tries to connect using

HTTP. Use this policy to disable the fallback

HTTP connection attempt.

DisableNTCredentials Requires the user to provide logon credentials

for Lync rather than automatically using the

Windows credentials during sign-in to a

Session Initiation Protocol (SIP) server.

DisableServerCheck By default, Lync checks the server name and

version before signing in. Set this policy to 1 in

order to bypass the server version check.

EnableBitsForGalDownload This policy allows Lync 2010 to use

Background Intelligent Transfer Service (BITS)

to download the Address Book Services files.

23


Group Policy setting Description

EnableSIPHighSecurityMode Enables Lync to send and receive instant

messages more securely. This policy has no

effect on Windows .NET or Microsoft Exchange

Server services.

If you do not configure this policy setting, Lync

can use any transport. But if it does not use

TLS and if the server authenticates users, Lync

must use either NTLM or Kerberos

authentication.

EnableStrictDNSNaming When set to False, allows Lync to automatically

detect and more securely communicate with

SIP servers that have non-standard fully

qualified domain names (FQDNs).

EnableTracing Turn on tracing for Lync, primarily for use to

assist customer problem solving.

FirstRunLaunchMode This policy defines the behavior of the Lync

First Run user experience. This setting

determines whether the First Run is enabled,

and whether it runs automatically.

HelpMenuText Specifies the text to display to the user in the

Help menu for the Help website.

HelpMenuURL Specifies which website to open when the user

selects the Help menu text item in the Help

menu. Both HelpMenuText and HelpMenuURL

need to be specified in order for the Help menu

item to appear in Lync.

PreventRun Prevents users from running Lync. You can

configure this policy setting under both

Computer Configuration and User

Configuration, but the policy setting under

Computer Configuration takes precedence.

SavePassword Enables Lync to store passwords.

SipCompression Defines when to turn on SIP compression. By

default, SIP compression is enabled based on

adapter speed. Note that setting this policy

might cause an increase in sign-in time.

Obsolete Group Policies

24


The following table lists the Office Communicator 2007 R2 Group Policy settings that are either

obsolete or superseded in Lync Server 2010.

Obsolete Group Policies

Obsolete Group Policy Lync Server 2010 in-band

provisioning setting

Windows PowerShell cmdlet

AbsUseFallback None

DisablePC2PCVideo EnableP2PVideo Set-CsConferencingPolicy

DisableRCCForwarding AllowCallForwarding Set-CsVoicePolicy

EnableUPNP ucEnableSipSecurityMode

MaxAudioVideoBitRate AudioBitRate

VideoBitRate

ucMaxVideoRateAllowed

Set-CsConferencingPolicy

Set-CsMediaConfiguration

Configuring Clients by Using Windows PowerShell

In Lync Server 2010, client policies, except for those required for bootstrapping are configured by

using Windows PowerShell cmdlets or the Lync Server Control Panel. This section summarizes

the Windows PowerShell cmdlets and parameters which correspond to Office Communications

Server 2007 R2 Group Policy settings.

CsClientPolicy

The majority of Group Policy settings from previous versions of Office Communications Server

can be configured by using the Windows PowerShell cmdlets New-CsClientPolicy or Set-

CsClientPolicy. For details, see the Lync Server Management Shell documentation.

Most CsClientPolicy parameters have the same name as the equivalent Office Communications

Server 2007 R2 Group Policy. This overview section summarizes the renamed, unchanged, and

new policies that can be set by using CsClientPolicy.

Policies Renamed in Lync Server 2010

Office Communications Server 2007

R2 Group Policy

Lync Server 2010 in-band

provisioning setting /

CsClientPolicy parameter

Description

AllowUnencryptedFileTransfer EnableUnencryptedFileTransfer When set to True, users

will be allowed to

exchange files with

external users whose

instant messaging

software does not

support encrypted file

25



R2 Group Policy




Description

transfers. When set to

False, users will only be

able to exchange files

with external users who

have software that

supports encrypted file

transfers.

CallLogAutoArchivingPolicy EnableCallLogAutoArchiving Enables/disables

automatic archiving of

call logs to Microsoft

Outlook mailbox.

DGRefreshPeriod DGRefreshInterval Indicates the amount of

time Lync 2010 waits

before automatically

refreshing the

membership list of any

distribution group that

has been "expanded" in

the Contacts list.

(Expanding a

distribution group

means displaying all the

members in that group.)

DGRefreshInterval can

be set to any integer

value between 30

seconds and 28,800

seconds (8 hours),

inclusive. The default

value is 28,800

seconds.

EnableFullScreenVideoPreviewDis

abled

EnableFullScreenVideo When set to True, this

parameter does two

things: 1) enables full

screen video (with the

correct aspect ratio) for

Lync 2010 calls; and, 2)

disables video preview

for Lync 2010 calls.

26



R2 Group Policy




Description

When set to False then

full screen video is not

available in Lync 2010,

but video preview is

available.

IMAutoArchivingPolicy EnableIMAutoArchiving Enables/disables

automatic archiving of

IM conversations to

Outlook mailbox.

MusicOnHoldAudioFile MusicOnHoldAudioFile Enables/disables ability

for the user to specify

the Music On Hold file.

MusicOnHoldDisabled EnableClientMusicOnHold Enables/disables Music

On Hold. Note that the

corresponding Group

Policy setting is

DisableClientMusicOnH

old. These settings also

apply to Microsoft Lync

2010 Attendant.

NotificationsForNewSubscribers EnableNotificationForNewSubscr

ibers

When set to True, any

time you are added to

someone’s Contacts list

you will receive

notification that you

have been added to the

list. In addition, the

notification dialog box

will provide options for

you to add this person

to your Contacts list, or

to block them from

viewing your presence

information. When set

to False, you will not be

notified if you are added

to someone’s Contacts

list.

27



R2 Group Policy




Description

PC2PCASEncryption P2PAppSharingEncryption Enables or disables

application sharing

encryption in peer-to-

peer (two users)

conversations.

PlayAbbrDialTone PlayAbbreviatedDialTone When set to True, a 3-

second dial tone will be

played any time a Lync

2010-compatible

handset is taken off the

hook. (A Lync 2010

handset looks like a

standard telephone, but

plugs into a USB port

on your computer and is

used to make Lync

2010 calls rather than

"regular" phone calls.)

When set to True, a 30-

second dial tone is

played any time a Lync

2010-compatible

handset is taken off the

hook.

SafeTransfer AttendantSafeTransfer Attendant - Safe

Transfer

The following table summarizes the unchanged policies that can be set by using CsClientPolicy.

Unchanged Client Policy Names

Lync Server 2010 in-band provisioning setting /


Description

AutoDiscoveryRetryInterval After a failed connection attempt, specifies the

amount of time Lync 2010 waits before trying

again to connect to Lync Server. The

AutoDiscoveryRetryInterval can be set to any

integer value between 1 second and 60

minutes, inclusive. The default value is 30

28




Description

minutes.

BlockConversationFromFederatedContacts Blocks conversation from federated contacts.

CalendarStatePublicationInterval Sets time interval to publish calendar data to

presence.

CustomStateURL Sets custom presence states URL.

DisableCalendarPresence Disables calendar presence.

DisableEmailComparisonCheck Disables email comparison check for Outlook

public IM connectivity integration.

DisableEmoticons Disables emoticons in instant messages.

DisableFederatedPromptDisplayName Prevents showing the display name of

federated contacts in the notification dialog

(does not include contact who use public IM

connectivity).

DisableFreeBusyInfo Disables publishing free/busy information.

DisableHandsetOnLockedMachine Configures handset use on locked computer.

DisableHTMLIM Prevents HTML text in instant messages.

DisableInkIM Prevents Ink in instant messages.

DisableMeetingSubjectAndLocation Disables publishing meeting subject and

location information.

DisableOneNote12Integration Disables Microsoft OneNote integration.

DisableOnlineContextualSearch Disables online contextual search.

DisablePhonePresence Disables call presence.

DisablePICPromptDisplayName Prevents showing the display name of public

IM connectivity contacts in the notification

dialog box.

DisablePresenceNote Disables presence note.

DisableRTFIM Prevents rich text in instant messages.

DisableSavingIM Prevents users from saving instant messages.

EnableAppearOffline Enables the state Appear Offline.

EnableEventLogging Turns on event logging for Lync 2010.

EnableSQMData Specifies instrumentation.

29




Description

EnableTracing Turns on tracing for Lync 2010.

EnableURL Allows hyperlinks in instant messages.

MAPIPollInterval Specifies how often Lync 2010 retrieves MAPI

data from the Exchange public folders.

MAPIPollInterval can be set to any integer

value between 5 minutes and 480 minutes (8

hours); inclusive. The default value is 30

minutes.

MaximumNumberOfContacts Indicates the maximum number of contacts a

user is allowed to have. The maximum contacts

can be set to any integer value between 0 and

1000, inclusive. When set to 0, that prevents

the user from having any contacts.

WebServicePollInterval For users of Microsoft Exchange Server 2007

or Microsoft Exchange Server 2010,

WebServicePollInterval specifies how often

Lync 2010 retrieves data from Exchange Web

Services. WebServicePollInterval can be set to

any integer value between 5 minutes and 480

minutes (8 hours); inclusive. The default value

is 30 minutes.

The following table summarizes the new policies that can be set by using CsClientPolicy.

New Lync Server 2010 Client Policies



Description

AbsUsage (in-band) / AddressBookAvailability

(Windows PowerShell)

Can be set to download the Address Book only,

use Address Book web search only, or use

both.

ConferenceIMIdleTimeout Indicates the number of minutes that a user can

remain in an instant messaging session without

either sending or receiving an instant message.

CustomizedHelpURL Replaces the default Lync 2010 Help link with

the location of your organization-specific Help.

Use in conjunction with

EnableEnterpriseCustomizedHelp.

30




Description

CustomLinkInErrorMessages URL for a website that can be added to error

messages in Lync 2010.

DisableContactCardOrganizationTab Enables or disables the contact card

organization tab.

DisableFeedsTab Enables or disables the activity feeds tab.

DisablePoorDeviceWarnings Disables device warnings that appear

whenever a faulty or obsolete device is

detected.

DisablePoorNetworkWarnings Disables network quality warnings that may

appear during a conversation.

DisplayPhoto Determines whether or not photos (of both the

user and his or her contacts) are displayed.

DisplayPublishedPhotoDefault Sets the default for display of other contacts’

published photos. Can be overridden by users.

EnableDelegation Enables the call delegation. See also

EnableExchangeDelegationSync in this table.

EnableDiagnosticsLogsCollection Enables or disables the Collect Logs button,

which is used to collect logs for the

investigation of audio, video, or connectivity

issues. This feature allows the user to capture

the necessary logs and metrics and compress

them into a .cab file. The user then manually

uploads logs per the administrator’s

instructions, who sends the logs to Microsoft for

troubleshooting purposes.

EnableEnterpriseCustomizedHelp Allows you to replace the default Lync 2010

Help link with the location of your organization-

specific Help. Use in conjunction with

CustomizedHelpURL.

EnableExchangeContactSync When enabled, Lync 2010 creates a

corresponding personal contact in Microsoft

Outlook for each person on a user’s Contacts

list.

EnableExchangeDelegateSync When enabled, the client retrieves the

Exchange calendar delegates (users who have

authoring and editing rights on the manager’s

31




Description

calendar) and uses these settings to update

delegates in Lync Server 2010. Use this setting

in conjunction with the EnableDelegation

setting, which is configurable in the

CsVoicePolicy cmdlets or in Lync Server

Control Panel.

EnableHotdesking When enabled, a user can log on to a Lync

2010 Phone Edition phone in a shared

workspace using his or her Lync Server 2010

account.

EnableVOIPCallDefault When enabled, a Lync 2010 call is placed any

time a user employs the click-to-call feature.

ExcludedContactFolders Indicates which Microsoft Outlook contact

folders (if any) should not be searched any time

Lync 2010 searches for new contacts.

HotdeskingTimeout Timeout interval for a user logged on to a "hot

desk" phone.

MaximumDGsAllowedInContactList Indicates the maximum number of distribution

groups that a user can configure as a contact.

MaxPhotoSizeKB Set this policy to 0 to remove photos from Lync

2010 and disable the photo user interface.

Default: 10.

PhotoUsage Enables or disables display of photos.

PolicyEntry Provides a way to add settings not covered by

the default parameters.

SearchPrefixFlags Represents the Address Book attributes that

should be searched any time a user searches

for a new contact.

ShowManagePrivacyRelationships Enables or disables the Manage Privacy

Relationships option in the View by menu.

ShowRecentContacts Shows or hides the Recent Contacts option in

the Display Options menu.

ShowSharepointPhotoEditLink Controls whether users see the Edit in Mysite

selection in their My Picture options. Edit in

Mysite allows users to show a picture from

32




Description

Microsoft SharePoint MySite.

SPSearchCenterExternalURL External URL for the SharePoint site used for

keyword searches (also known as expert

searches). This URL will appear at the bottom

any of keyword search results that appear in

Lync 2010. If the user clicks this URL, his or her

web browser will open up to the SharePoint

site, giving the user the opportunity to conduct

searches using SharePoint’s search

capabilities.

SPSearchCenterInternalURL Internal URL for the SharePoint site used for


searches). This URL will appear at the bottom

any of keyword search results that appear in

Lync 2010. If the user clicks this URL, his or her

web browser will open up to the SharePoint

site, giving the user the opportunity to conduct

searches using SharePoint’s search

capabilities.

SPSearchExternalURL Internal URL for the SharePoint site used for


searches). Lync 2010 will use the SharePoint

site located at this URL any time an external

user (that is, a user who has access the system

from outside the organization’s firewall)

conducts a keyword search.

SPSearchInternalURL Lync 2010 will use the SharePoint site located

at this URL any time an internal user (that is, a

user who has logged on from inside the

organization’s firewall) conducts a keyword

search.

For details, see the following topics:

Set-CsClientPolicy in the Lync Server Management Shell documentation

Overview of Client Policies and Settings

Lync 2010 New Features

Additional Client Policies

33


The following table lists the Lync Server 2010 in-band provisioning settings and Windows

PowerShell cmdlets that are either not configurable through Windows PowerShell or configured

by using a Windows PowerShell cmdlet other than New-CsClientPolicy or Set-CsClientPolicy.

Many of these settings correspond to Communications Server 2007 R2 Group Policy settings and

have been renamed in Lync Server 2010.

Communications Server 2007 R2 Group Policy Equivalents

Office Communications

Server 2007 R2 Group

Policy setting

Lync Server 2010

in-band

provisioning

setting

Windows PowerShell

cmdlet

Cmdlet parameters

AbsInsideURL AbsInternalServer

Url

None None

AbsOutsideURL AbsExternalServe

rUrl

None None

Portrange\

MaxMediaPort

ucMaxMediaPort CsConferencingConfig

uration

ClientMediaPortRange

(indicates the total

number of ports available

for client media; default is

40)

Portrange\

MinMediaPort

ucMinMediaPort CsConferencingConfig

uration

ClientMediaPort

(represents the starting

port number to use for

client media)

Portrange\Enabled ucPortRangeEna

bled

CsConferencingConfig

uration

ClientMediaPortRangeEn

abled

DisableApplicationSha

ringControl

AllowParticipantC

ontrol

CsConferencingPolicy AllowExternalUserControl

DisableDataConferenc

ing

EnableDataCollab

oration

CsConferencingPolicy EnableDataCollaboration

DisableAVConferencin

g

AllowIPAudio,

AllowIPVideo

CsConferencingPolicy

; CsUser

AllowIPAudio,

AllowIPVideo;

AudioVideoDisabled

DisableFileTransfer AllowFileTransfer CsFileTransferFilterCo

nfiguration (Lync

2010)CsConferencing

Policy (Web

conferencing)

--

IMWarning IMWarning CsIMFilterConfiguratio WarnMessage

34



Server 2007 R2 Group

Policy setting

Lync Server 2010

in-band

provisioning

setting

Windows PowerShell

cmdlet

Cmdlet parameters

n

MRASServerURI mrasURI None None

PC2PCAVEncryption ucPC2PCAVEncr

yption

CsMediaConfiguration EncryptionLevel

msRTCLine line CsUser LineURI

TelephonyMode TelephonyMode CsUser EnterpriseVoiceEnabled,

RemoteCallControlTeleph

onyEnabled

ExUMEnabled ExUMEnabled CsUser MCSVoiceMail

DisableSimultaneousR

inging

AllowSimultaneou

sRinging

CsVoicePolicy AllowSimulRing

VoicemailURI VoicemailURI None None

Client Interoperability

This topic discusses the ability of Microsoft Lync Server 2010 clients to coexist and interact with

clients from earlier versions of Microsoft Office Communications Server.

Note:

Lync Server 2010 can coexist with components of either a Microsoft Office

Communications Server 2007 deployment or a Microsoft Office Communications Server

2007 R2 deployment. Concurrent deployment of Lync Server 2010 with both Office

Communications Server 2007 and Office Communications Server 2007 R2 (concurrent

deployment of all three versions) is not supported. For details, see Supported Server

Migration Paths and Coexistence Scenarios.

There are two types of client compatibility:

Multiple points of presence (MPOP) The ability of a single user to sign in to a server with

multiple clients and multiple client versions.

Interoperability The ability to interact with another user who is signed in using a different

client type, or an earlier version of the same client.

Planning for Compatibility

Important:

In order to fully test the new Lync Server 2010 features during migration, you must

ensure that previous client versions have the most recent updates, or hotfixes, installed.

For details, see Planning for Client Migration.

35


Lync Server 2010 fully supports interoperability among Lync Server 2010 clients.

Most instant messaging (IM), presence, and voice features are also supported when interacting

with Communications Server 2007 R2 and Communications Server 2007 clients. For details, see

the "Lync Server 2010 Interoperability with Previous Client Versions" section later in this topic.

For best results with meetings, see Migration Considerations for Meetings.

Compatibility among Lync Server 2010 Clients

All Lync Server 2010 clients can interoperate with other Lync Server 2010 clients.

With the exception of Microsoft Lync 2010 Attendant, Lync Server 2010 clients also support the

multiple points of presence scenario—that is, a single user can be signed in at multiple locations.

Multiple Points of Presence (MPOP) with Previous Client Versions

The following table describes the client versions that are supported when a single user is signed

in to Lync Server 2010 at multiple locations.

Note:

Lync Server 2010 clients cannot sign in to previous server versions.

Client Versions Supported for Sign-in from Multiple Locations

Current client version Client version MPOP support (with required

updates)

Microsoft Lync 2010

Microsoft Lync 2010 Attendee

Microsoft Office Communications Server 2007

R2

Microsoft Office Communications Server 2007

Microsoft Office Communicator Web Access

(2007 R2 release)

Microsoft Office Communicator Web Access

(2007 release)

Phones running Microsoft Office Communicator

2007 R2 Phone Edition

Phones running Microsoft Office Communicator

2007 Phone Edition

Microsoft Communicator for Mac 2011

Phones running Lync 2010 Phone Edition Microsoft Office Communicator 2007 R2

Microsoft Office Communicator 2007


2007 R2 release of Microsoft Office

Communicator Mobile

Microsoft Office Communicator 2007 R2

Microsoft Office Communicator 2007

Microsoft Office Communicator 2007 R2 Phone

Edition

Microsoft Office Communicator 2007 Phone

36


Current client version Client version MPOP support (with required

updates)

Edition


Lync Server 2010 Interoperability with Previous Client Versions

This section discusses Lync Server 2010 interoperability support for clients that shipped with

Communications Server 2007 R2 and Communications Server 2007.

Note:

Communicator Web Access and Microsoft Office Live Meeting 2007 cannot be used to

join new meetings scheduled on Lync Server 2010. Lync 2010, Microsoft Lync 2010

Attendee, and Microsoft Lync Web App are the recommended alternatives. For details,

see Migration Considerations for Meetings.

IM, Presence, Voice, and Video Interoperability

The following table describes the availability of these features during migration.

IM, Presence, and Voice Interoperability with Previous Client Versions

Lync Server 2010

clients


Server 2007 R2 clients


Server 2007 clients

Lync Server 2010

Clients

IM, presence, voice,

and video supported

IM, presence, voice, and

video supported

IM, presence, and video

supported; some voice

feature limitations (see

the following section in

this topic)

Interaction with Microsoft Office Communicator 2005 clients (basic presence and IM) is

supported only if the Office Communicator 2005 user is on a federated network.

Voice Interoperability Considerations

Voice interoperability issues to be aware of are as follows:

Office Communicator 2007 does not support voice features added in Communicator 2007 R2

and Lync 2010, such as call park, Team Call, and Lync Server Response Group service.

Call park issues you should be aware of during migration are as follows:

A call parked by a Lync 2010 user cannot be unparked by clients or devices signed in to

an earlier version of Office Communications Server.

You cannot park a call to a Communications Server 2007 client or device.

Conferencing Interoperability Considerations

When a user account is moved from Communications Server 2007 R2 to a Lync Server 2010

server, the following information moves along with the user account:

Meetings already scheduled by the user.

37


The user’s personal identification number (PIN) (there is no need for new PIN assignment).

The following information does not move to the new server:

Meeting content. You should advise meeting organizers to reload content into their scheduled

meetings after migration.

The following tables describe two conferencing interoperability scenarios:

Previous client version interoperability with Lync Server 2010 meetings

Lync 2010 interoperability with meetings hosted or scheduled on previous server versions

Previous Client Versions and Lync Server 2010 Meetings


and Communicator

2007 interoperability

Schedule Lync Server

2010 Meetings

Join Lync Server 2010

Meetings

Behavior in Lync

Server 2010 Meetings

Before user is moved

to Lync Server 2010

Not supported. Supported if enabled.

For details, see

Migration

Considerations for

Meetings.

No access to new

collaboration features

unless meeting is

escalated to use Lync

Web App.

No access to new

lobby management

features.

After user is moved to

Lync Server 2010, but

before new clients are

installed

Continue using the

Conferencing Add-in

for Microsoft Office

Outlook to schedule

conference calls and

Live Meeting web

conferences.

Supported if enabled.

For details, see

Migration

Considerations for

Meetings.

No access to new

collaboration features

unless meeting is

escalated to use Lync

Server 2010.

No access to new

lobby management

features.

For details, see Migration Considerations for Meetings.

Lync 2010 Interoperability With Communicator Meetings Hosted or Scheduled on Previous Versions of Office Communications Server

Lync 2010 interoperability with Communicator

meetings on previous versions of Office

Communications Server

Lync 2010 user experience

Scheduling Lync 2010 users cannot schedule meetings on

earlier server versions.

When modifying the end date, subject, or

attendee list of meetings migrated from

previous server versions to Lync Server 2010,

38


Lync 2010 interoperability with Communicator

meetings on previous versions of Office

Communications Server

Lync 2010 user experience

users are prompted to convert the meeting to

Lync Server 2010.

Joining No issues.

In meeting New Lync 2010 features are unavailable.

Manager/Delegate Interoperability

For the manager/delegate scenario, both manager and delegate must be using Lync 2010.

Interoperability with Existing Custom Applications

For the purposes of this discussion an existing custom application is defined as follows:

The application uses the Microsoft Office Communicator Automation API or the Microsoft

Unified Communications Client API.

The application runs in a migration environment, on a machine where either Communicator

2007 R2 or Communicator 2007 is connected to a server running Lync Server 2010.

Existing custom applications can sign in to a Lync Server 2010 server and interact with Lync

Server 2010 clients. However, the following limitations apply:

Existing custom applications do not have access to Lync 2010 features.

Running a Unified Communications Client API custom application on the same computer as

Lync 2010 is not recommended.

If your organization plans to enable enhanced presence privacy mode, Unified

Communications Client API custom applications may need to be rewritten. For details, see

Planning for Clients, Lync 2010 New Features in the Getting Started documentation, and the

Microsoft Lync 2010 SDK.

See Also

Planning for Clients

New Client Features

Phase 1: Plan Your Migration from Office Communications Server 2007 R2This section covers planning topics for migrating from Microsoft Office Communications Server

2007 R2 to Microsoft Lync Server 2010.

In This Section

User Migration

Migrating Archiving and Monitoring Servers

Administering Servers after Migration

39


Migrating Multiple Sites and Pools

User Migration

A generally accepted best practice for migrations is to create several test users and use them to

conduct systems tests. After you have successfully moved and tested those accounts, you should

identify a group of pilot production users and move their accounts and conduct validation tests on

them. When you get satisfactory results, you can move the rest of your users to the new

deployment.

Migrating Archiving and Monitoring Servers

If you deployed Archiving Server and Monitoring Server in your Microsoft Office Communications

Server 2007 R2 environment, you can deploy these servers in your Microsoft Lync Server 2010

environment after you migrate your Front End pools. If archiving and monitoring functionality are

critical to your organization, however, you should add Archiving Server and Monitoring Server to

your pilot pool before you migrate so that the functionality is available during the migration

process.

If you want archiving and monitoring functionality during the migration and coexistence phase,

keep the following considerations in mind:

Archiving data and monitoring data are not moved to the Lync Server 2010 deployment. The

data you back up prior to decommissioning the legacy environment will be your history of

activity in the Office Communications Server 2007 R2 environment.

The Office Communications Server 2007 R2 version of Archiving Server and Monitoring

Server can be associated only with a Communications Server 2007 R2 Front End pool. The

Lync Server 2010 version of Archiving Server and Monitoring Server can be associated only

with a Lync Server Front End pool.

If you use Microsoft System Center Operations Manager (formerly Microsoft Operations

Manager) to monitor call reliability and media quality, you must use the System Center

Operations Manager 2007 R2 management pack to monitor Communications Server 2007

and the Lync Server 2010 Monitoring Management Pack for System Center Operations

Manager 2007 R2 to monitor Lync Server.

Note:

For details about the Lync Server 2010 Monitoring Management Pack for System

Center Operations Manager 2007 R2, see http://go.microsoft.com/fwlink/?

LinkId=214711.

During the time that your legacy and Lync Server 2010 deployments coexist, the Office

Communications Server 2007 R2 version of Archiving Server and Monitoring Server gather

data for users homed on Communications Server 2007 R2 pools. The Lync Server 2010

version of Archiving Server and Monitoring Server gather data for users homed on Lync

Server pools.

40




Note:

During the phase of migration when you are still using your legacy edge with the new

Lync Server pilot pool, the Office Communications Server 2007 R2 version of

Archiving Server continues to gather data for users homed on Communications

Server 2007 R2 pools and the Lync Server 2010 version of Archiving Server gathers

data for users homed on Lync Server pools.

When you run the Import-CsLegacyConfiguration cmdlet during the migration process, the

legacy archiving and monitoring policies are imported to the Lync Server Central

Management store.

When you use the Move-CsLegacyUser cmdlet to move a Communications Server 2007 R2

user to a Lync Server pool, the cmdlet assigns the Lync Server policy that is equivalent to the

legacy policy.

If you use a third-party archiving and monitoring solution in conjunction with Archiving Server

and Monitoring Server, talk to your vendor about when and how you need to integrate the

third-party solution with Lync Server 2010.

Administering Servers after Migration

In general, you must use the administrative tools that corresponds to the server version that you

want to manage.

Use the Office Communications Server 2007 R2 snap-in as follows:

To manage Office Communications Server 2007 R2 users and servers.

To access the Active Directory Users and Computers snap-in on Office Communications

Server 2007 R2 or on a computer with the Office Communications Server 2007 R2

administrative tools installed.

Use the Lync Server 2010 Control Panel as follows:

To move legacy Office Communications Server 2007 R2 users to Lync Server 2010.

To manage users on Lync Server 2010 after moving them from Office Communications

Server 2007 R2.

Important:

Only the Lync Server 2010 Control Panel should be used to move users to and from

Lync Server 2010.

To manage servers running Lync Server 2010 and Lync Server services.

You cannot install the Office Communications Server 2007 R2 administrative tools and the Lync

Server 2010 Control Panel on the same computer. Also, the Lync Server 2010 Control Panel is

not installed automatically on each server. You must manually choose on which workstation or

server you want to install the tools. To install the Lync Server 2010 Control Panel, follow the

procedure inside the topic Install Lync Server Administrative Tools in the Deployment

documentation.

41


Migrating Multiple Sites and Pools

Microsoft Lync Server 2010 supports multi-site and multi-pool deployments. The process of

migrating multiple pools from Microsoft Office Communications Server 2007 R2 to Lync Server

2010 requires the following considerations:

1. After deploying a Lync Server pilot pool and importing the Office Communications Server

2007 R2 pool configuration to the Lync Server pool, you need to define a subset of pilot users

that will be moved to the Lync Server pool, and a methodology for validating the functionality

of the users.

2. After deploying an Edge Server in the pilot pool, you need to validate that external users can

communicate with the Lync Server pool.

3. After transitioning the federated routes from Communications Server 2007 R2 Edge Servers

to the pilot Lync Server Edge Servers, you need to validate that federated users can

communicate with the Lync Server pool.

4. After moving all the users and non-user contact objects, you need to validate that the

Communications Server 2007 R2 pool is empty.

5. After verifying that the Communications Server 2007 R2 pool is empty, you can then

deactivate the pool.

6. After verifying that all pools are deactivated, and all Communications Server 2007 R2 Edge

Servers have been uninstalled, use the Topology Builder Merge wizard to remove the legacy

topology from the site. Finally, use Topology Builder to delete the BackCompatSite.

For details about how to deactivate the legacy Office Communications Server 2007 R2 pool

and servers, see Phase 10: Decommission Legacy Site.

Phase 2: Prepare for MigrationBefore you begin to migrate to Microsoft Lync Server 2010 from Microsoft Office Communications

Server 2007 R2, follow the steps described in this section.

In This Section

Apply Office Communications Server 2007 R2 Updates



Configure Clients for Migration

Apply Office Communications Server 2007 R2 Updates

Before you migrate to Microsoft Lync Server 2010, updates must be applied to your Microsoft

Office Communications Server 2007 R2 environment. The updates required are listed in the

following table.

For the most up-to-date information about Office Communications Server 2007 R2 updates, see

Updates Resource Center for Office Communications Server 2007 R2 and Clients at

http://go.microsoft.com/fwlink/?LinkId=199488.

42



On the computer running Office Communications Server 2007 R2, check Programs and

Features in Control Panel to determine whether these updates have been applied.

Office Communications Server 2007 R2 Required Updates

Application Update URL

Microsoft Office


July 2010 Update

package


Microsoft Office Live

Meeting 2007

July 2010 Update

package


Microsoft Office Live

Meeting Conferencing

Add-In

July 2010 Update

package



Server 2007 R2

September 2010

Update package


Microsoft Office


Phone Edition

July 2010 Update

package



The Microsoft Office Communications Server 2007 R2 Best Practices Analyzer tool gathers

configuration information from an Office Communications Server 2007 R2 deployment and

determines whether the configuration is set according to Microsoft best practices. You can install

the tool on a client computer that runs Microsoft .NET Framework 2.0, or directly on the server

that runs Office Communications Server. We recommend that you install and run this tool on a

client computer. The Office Communications Server 2007 R2 Administrative Tools should also be

installed locally on the client computer so that the Best Practices Analyzer can collect a full set of

data.

For details about installing the Office Communications Server 2007 R2 Administrative Tools on a

32-bit client computer, see "32-Bit Tools: Office Communications Server 2007 R2 Deployment

and Management" at http://go.microsoft.com/fwlink/?LinkId=199486.

You can download the Office Communications Server 2007 R2 Best Practices Analyzer from the

Microsoft Download Center at http://go.microsoft.com/fwlink/?linkid=144315.


Before you begin the migration to Microsoft Lync Server 2010, we strongly recommend that you

perform a full system backup and document your existing system, including an inventory of user

accounts that are homed on each pool, so that you can roll back to Microsoft Office

Communications Server 2007 R2 if it becomes necessary.

43

http://go.microsoft.com/fwlink/?linkid=144315








Multiple tools and programs are available for backing up and restoring data, settings, and

systems. For details and procedures, see the Office Communications Server 2007 R2 Backup

and Restoration Guide at http://go.microsoft.com/fwlink/?LinkId=168162. The Backup and

Restoration Guide focuses on the use of tools and programs that are provided with Office

Communications Server 2007 R2 and on components that are available in Microsoft SQL Server

2008 and Microsoft SQL Server 2005.

Configure Clients for Migration

This topic contains the recommended client deployment steps you should take prior to migrating

to Microsoft Lync Server 2010. These configuration changes should be made on Office

Communications Server 2007 R2. It is very important that you perform these steps prior to

migrating. For details, see Planning for Client Migration.

To configure clients prior to migration

1. Deploy the most recent server, client, and device updates (hotfixes) for Microsoft Office

Communications Server 2007 R2 as listed in Apply Office Communications Server 2007

R2 Updates.

2. On Office Communications Server 2007 R2, use Client Version Filtering to allow only

clients with the most current updates installed, as listed in Apply Office Communications

Server 2007 R2 Updates to sign in.

3. On Office Communications Server 2007 R2, use Client Version Filtering to block Lync

Server 2010 clients from signing in. Follow the steps described in Configuring Client

Version Filtering at http://go.microsoft.com/fwlink/?LinkId=202488 to add the version

filters listed in the following table. For each version filter, assign the action Block.

Client User agent header Version

Lync 2010 OC 4.*.*.*

Lync Web App CWA 4.*.*.*

Lync 2010 Phone Edition OCPhone 4.*.*.*

Phase 3: Deploy Lync Server 2010 Pilot PoolThis section describes the reference topology covered in this document. It also covers the steps

required to deploy a pilot deployment of Lync Server 2010, and a few key validation steps to

ensure the two pools are coexisting.

In This Section

Lync Server 2010 Pilot Pool Architecture

Deploy Lync Server 2010 Pilot Pool

44




Verify Pilot Pool Coexistence with Legacy Pool

Lync Server 2010 Pilot Pool Architecture

The following figure shows the pilot pool reference topology used in this document. Lync Server

2010 is installed side by side with an existing Office Communications Server 2007 R2 installation.

After merging the topologies, a few test users will be homed on Lync Server 2010 and then

communicate with users who are homed on Office Communications Server 2007 R2 servers. This

will show interoperability between users who are homed in different pools can continue to

communicate and use the existing workloads and perimeter network infrastructure.

Initially a Lync Server 2010 pool is deployed in parallel with Office Communications Server 2007

R2. External traffic and federation is done through the legacy Edge Server environment. In Phase

7: Add Lync Server 2010 Edge Server and Director to Pilot Pool, the Director and Edge Server

are added to the deployment.

The following table lists the fully qualified domain names (FQDNs) for the various server roles

used in this topology. It is supplied solely for reference purposes.

Server Role Office Communications Server 2007

R2 FQDN

Lync Server 2010 FQDN

Standard Edition Server SE-R2.CONTOSO.NET LYNC-SE.CONTOSO.NET

Edge Server EDGE-R2.CONTOSO.NET LYNC-EDGE.CONTOSO.NET

Director DIR-R2.CONTOSO.NET LYNC-DIR.CONTOSO.NET

45


Server Role Office Communications Server 2007

R2 FQDN

Lync Server 2010 FQDN

Mediation Server MEDSVR01.CONTOSO.NET Collocated on LYNC-

SE.CONTOSO.NET

Important

We recommend deploying Lync Server 2010 Enterprise Edition for deployments that require a

true high-availability solution.

Important:

We recommend collocating the Lync Server Mediation Server with a Lync Server Front

End pool or Standard Edition server when merging an Office Communications Server

2007 R2 stand-alone Mediation Server.

Deploy Lync Server 2010 Pilot Pool

One of the first steps in a phased rollout is to deploy a Lync Server 2010 pilot pool. You will merge

topology information and configuration settings from an existing Office Communications Server

2007 R2 pool to this pilot pool. The pilot pool is where you test coexistence of Lync Server 2010

with your Office Communications Server 2007 R2 deployment. Coexistence is a temporary state

that lasts until you have moved all users and pools to Lync Server 2010.

You should deploy the same features and workloads in your pilot pool that you have in your Office

Communications Server 2007 R2 pool. If you deployed Archiving Server, Monitoring Server, or

System Center Operations Manager for archiving or monitoring your Office Communications

Server 2007 R2 environment and you want to continue archiving or monitoring throughout the

migration, you need to also deploy these features in your pilot environment. The version you

deployed to archive or monitor your Office Communications Server 2007 R2 environment will not

capture data in your Lync Server 2010 environment. For details about how Archiving Server,

Monitoring Server, and System Center Operations Manager versions work during migration, see

Migrating Archiving and Monitoring Servers.

For detailed steps about deploying Standard Edition in your pilot environment, see Deploying

Lync Server 2010 Standard Edition in the Deployment documentation. For detailed steps about

deploying Enterprise Edition in your pilot environment, see Deploying Lync Server 2010

Enterprise Edition in the Deployment documentation.

Important:

Before you deploy your pilot pool, you need to decide whether you will deploy one Lync

Server 2010 pool for each existing Office Communications Server 2007 R2 pool. Some

configuration settings, such as Response Group, migrate for an entire pool with a single

cmdlet. Therefore, if you plan to consolidate pools or split pools into smaller pools during

your migration and deployment, you need to plan which Office Communications Server

46


2007 R2 pools map to which Lync Server 2010 pools and adjust your migration

accordingly.

Note:

When creating a new topology using Topology Builder, ensure that the primary SIP

domain (and any additional SIP domains) are named exactly as the legacy Office

Communications Server 2007 R2 SIP domains. If not, the Topology Builder Merge wizard

procedure in Phase 4: Merge Topologies will fail to create a topology. To find your legacy

Office Communications Server 2007 R2 SIP domains, open the Office Communications

Server 2007 R2 Administrative Tools snap-in. Right click the forest node, select Global

Properties, and then under the General node note the list of SIP domains in the

Domains list box. The checked domain is the primary or default domain.

When you deploy a pilot pool, you use the Define New Front End Pool wizard. The following list

of key steps discusses features and settings you should consider as part of your overall pilot pool

deployment process. This section only highlights key points you should consider as part of your

pilot pool deployment. For detailed steps, refer to the Deployment guides mentioned earlier. The

following procedures match the pilot pool reference architecture listed in Lync Server 2010 Pilot

Pool Architecture. Adapt these settings to match your deployment.

Key steps for deploying a pilot pool

1. Log on to the computer where Topology Builder is installed as a member of the Domain

Admins group and the RTCUniversalServerAdmins group.

2. When you define your pilot pool, you can choose to deploy an Enterprise Edition Front

End pool or a Standard Edition server. Lync Server 2010 does not require that your pilot

pool match what was deployed in your legacy pool.

Caution:

The pool or server fully qualified domain name (FQDN) that you define for the

pilot must be unique. It cannot match the name of the currently deployed Office

Communications Server 2007 R2 pool, or any other servers currently deployed.

47


3. On the Select collocated server roles page, we recommend you collocate the

Mediation Server in Lync Server 2010. When merging a legacy topology with Lync Server

2010, we require that you first collocate the Lync Server 2010 Mediation Server. After

merging the topologies and configuring the Lync Server 2010 Mediation Server, you can

decide to keep the collocated Mediation Server or change it to a stand-alone server in

your Lync Server 2010 deployment.

Important:

Note that Lync Server 2010 Standard Edition server pools can only be served by

the collocated A/V Conferencing service installed. Thus, the check box is

unavailable on this page but would be available on Lync Server 2010 Enterprise

Edition server.

Note:

We highly recommend that you collocate the Mediation Server on a Front End

Server or Standard Edition server. However, if you do decide to move a

collocated Lync Server 2010 Mediation Server to a stand-alone Mediation Server,

see Transition a collocated Mediation Server to a Stand-Alone Mediation Server

(optional).

48


4. On the Associate server roles with this Front End pool page, you can choose to

enable archiving and monitoring if you want those server roles deployed as part of your

pilot pool.

Important:

During pilot pool deployment, do not choose the Enable an Edge pool to be

used by the media component of this Front End pool option. This is a feature

you will enable and bring online in a later phase of migration. Keep this setting

cleared for now.

49


5. Continue completing the Define New Front End Pool wizard, and then click Finish when

completed.

6. To publish your topology, right-click the Lync Server 2010 node, and then click Publish

Topology.

7. When the publish process has completed, click Finish.

8. To install a local copy of the configuration database and start the required services, see

Setting Up Front End Servers and Front End Pools or Setting Up Standard Edition Server

in the Deployment documentation.

Verify Pilot Pool Coexistence with Legacy Pool

After you deploy the pilot pool and before you begin to migrate from Microsoft Office

Communications Server 2007 R2, verify the coexistence of the two pools by using the

administrative tools to view the pool information. For the Office Communications Server 2007 R2

pool, use the Office Communications Server 2007 R2 administrative tool. For the Microsoft Lync

Server 2010 pool, use Lync Server 2010 Control Panel.

50


Verify the Pool in Office Communications Server 2007 R2 Administrative Tool

1. Log on to the computer with an account that is a member of the

RTCUniversalServerAdmins group.

2. Open the Office Communications Server 2007 R2 administrative tool.

3. Expand the Forest node, expand the Standard Edition Servers or Enterprise pools

node, and then expand the pool or server name.

4. Ensure that the services are running on the Standard Edition server or Enterprise pool.

Verify the Pilot Pool in Lync Server Control Panel



2. Open a browser window, and then enter the Admin URL to open the Lync Server Control

Panel. For details about the different methods you can use to start Lync Server Control

Panel, see Open Lync Server Administrative Tools.

3. Click Topology.

4. Verify that the servers you deployed are present in your pilot pool.

51


Verify Lync Server services have started



2. From the Standard Edition server or Front End Server, open the Services applet from the

Administrative Tools group.

3. Verify that the services listed match the list in the following figure.

52


Phase 4: Merge TopologiesThe following topics outline the steps needed to merge your Microsoft Office Communications

Server 2007 R2 pools to Microsoft Lync Server 2010 pools. First, you use the Topology Builder

Merge wizard to merge topology information. This tool collects information about your Office

Communications Server 2007 R2 environment, including Edge Server information, and publishes

that information to a database shared with Lync Server 2010. After you publish the merged

topology, Topology Builder is used to view the Office Communications Server 2007 R2 topology

information and information about the newly deployed Lync Server 2010 topology. Finally, you

use Lync Server Management Shell cmdlets to import policies and configuration settings.

In This Section

Install WMI Backward Compatibility Package

Merge Using Topology Builder Merge Wizard



Install WMI Backward Compatibility Package

You must install the Windows Management Instrumentation (WMI) Backward Compatibility

Package as a prerequisite before running the Topology Builder Merge wizard. Lync Server 2010

stores its configuration information in a Central Management store hosted on SQL Server 2008

with Service Pack 1 (SP1) (required) or latest service pack (recommended), SQL Server 2008

R2, or SQL Server 2005 with Service Pack 3 (SP3) (required) or latest service pack

(recommended). Microsoft Office Communications Server 2007 R2 used the Windows

Management Instrumentation (WMI) framework. The WMI Backward Compatibility Package

provides Lync Server 2010 the ability to merge WMI information from Office Communications

Server 2007 R2 into the new format in Lync Server 2010.

If you attempt to run the Topology Builder Merge wizard without installing the WMI Backward

Compatibility package, you will see the following error:

If you attempt to run the Merge-CsLegacytopology cmdlet without installing the WMI Backward

Compatibility package, you will see the following error:

53


To install the WMI Backward Compatibility Package

1. On the Standard Edition server or Front End Server, log on to the computer with an

account that is a member of the Administrators group.

2. From your installation media, navigate to \SETUP\AMD64\SETUP\OCSWMIBC.MSI.

3. Install OCSWMIBC.MSI.

Important:

OCSWMIBC.msi must be installed on the computer where the Topology Builder

Merge wizard is run.

Important:

OCSWMIBC.msi can be installed on any computer in the domain that has the

Lync Server 2010 Core Components and Lync Server Management Shell

installed, and has access to the Office Communications Server 2007 R2 topology

(WMI provider to Active Directory Domain Services (AD DS) and SQL Server).

Merge Using Topology Builder Merge Wizard

Topology Builder is a new tool introduced in Microsoft Lync Server 2010. With Topology Builder

you can create, edit, and publish a Lync Server 2010 deployment topology. Additionally, the

Merge feature allows you to import information from your previous Office Communications Server

environments, and integrate it into a consolidated view alongside your Lync Server 2010

deployment.

This section describes how to use Topology Builder to merge your legacy topology information

with your Lync Server 2010 topology. After you run the Merge wizard, you publish the newly

merged topology. During the publishing process, Topology Builder runs the Import-

CsLegacyConferenceDirectory cmdlet to import conference directory information from the

legacy deployment to Lync Server 2010 to provide interoperability between Office

Communications Server 2007 R2 and Lync Server 2010 during your migration process. Before

you decommission your legacy deployment, you need to run another cmdlet to move the

conference directories to Lync Server 2010. For details, see Move Conference Directories.

54


Note:

Conference directories support dial-in conferencing.

Important:

The merge process does not move archiving data or monitoring data. The data you back

up prior to decommissioning the legacy environment will be your history of activity in the

Office Communications Server 2007 R2 environment.

Tip:

For details about an alternative method to using Topology Builder, see Migrate Using

Lync Server Management Shell (optional).

To merge topology information



2. From the Standard Edition server or Front End Server, click Start, click All Programs,

click Microsoft Lync Server 2010, and then click Lync Server Topology Builder.

3. Select the option to Download topology from existing deployment, and then click OK.

4. In the Save Topology As dialog box, select the Topology Builder file you want to use,

and then click Save.

5. In the Actions pane, click Merge 2007 or 2007 R2 Topology.

6. Click Next.

7. In Specify Edge Setup, click Add.

55


8. In Specify Edge Version, select Office Communications Server 2007 R2 Edge

Server, and then click Next.

9. In Specify Edge Type, enter the type of Edge Server configuration, and then click Next.

This example uses the Single Edge Server option.

Important:

Expanded Edge is not a supported configuration. An Expanded Edge must first

be converted to a Single Edge Server or a Load-balanced consolidated Edge

Server.

Important

If you use a Load-balanced consolidated Edge configuration, and you want to change the

membership of that configuration by creating a new Edge Server pool that uses one of the

legacy Communications Server 2007 R2 Edge Servers, you must first remove the legacy

Edge Server from the existing Communications Server 2007 R2 Edge array, and then publish

the topology. Using the Topology Builder Merge wizard, you then create a new Edge Server

pool, add the legacy Edge Server to this pool, and then publish the topology again. In this last

step, you also have the option of adding another Edge Server to the legacy Edge Server pool

if required. After any additions or deletions to Edge Server pools, you must publish the

topology.

10. In Specify Internal Edge Settings Information, enter the relevant information for your

56


Edge pool’s internal FQDN and ports as needed, and then click Next.

11. In Specify External Edge, enter the web conferencing FQDN information for your Edge

Server.

Important:

Before you click Next, do the next step in this procedure. It is important that you

don’t miss step 11.

12. Check the This Edge pool is used for federation and public IM connectivity check

box if you plan to use this Edge Server for federation. If you have multiple Edge Servers

deployed, only one of them will be enabled for federation. If you do not check this box

and you decide later that you want to enable federation, you must run the Topology

Builder Merge wizard again, and then publish your topology again.

57


13. In Specify Next Hop, enter the fully qualified domain name (FQDN) of the next hop

location in your environment. In the following figure, the legacy Director from the Office

Communications Server 2007 R2 deployment is shown. Click Finish.

58


14. In Specify Edge Setup, if all your Communications Server 2007 R2 Edge Servers have

been added, click Next. If you have more Communications Server 2007 R2 Edge Servers

to add, repeat steps 6 through 12.

15. In Specify Internal SIP port setting, select the default setting (that is, if you did not

modify the default SIP port). Change as appropriate if you are not using a default port of

5061, and then click Next.

16. In Summary, click Next to begin merging the topologies.

17. The wizard page verifies that the merging of the topologies was successful.

18. In the Status column, verify that the value is Success, and then click Finish.

19. In the left pane of Topology Builder, you should now see the BackCompatSite, which

indicates that your Office Communications Server 2007 R2 environment has been

merged with Lync Server 2010.

59


20. From the Actions pane, click Publish Topology, and then click Next.

21. When the Publishing wizard completes, click Finish.

Note:

It’s important that you complete the next topic, Import Policies and Settings, to

ensure that the legacy policy settings are imported into Lync Server 2010.


After you merge your Microsoft Office Communications Server 2007 R2 topology information with

your Microsoft Lync Server 2010 pilot pool, you need to run a Lync Server Management Shell

cmdlet to migrate your Office Communications Server 2007 R2 policies and configuration settings

to your Lync Server 2010 pilot pool.

The Import-CsLegacyConfiguration cmdlet imports policies, voice routes, dial plans,

Communicator Web Access URLs, and dial-in access numbers to Lync Server 2010.

In Lync Server 2010, client policies replace the Group Policy settings used in previous versions of

the product. The Import-CsLegacyConfiguration cmdlet imports Group Policy settings to client

60


policies in the Central Management store. When you move users to Lync Server, they are

assigned the Lync Server policy that is equivalent to the legacy policy. For details about how

client policies in Lync Server compare to legacy Group Policy settings, see Migrating User

Settings to Lync Server 2010.

In previous versions of Office Communications Server, you could define policies with a global or

per-user scope. In Lync Server 2010, you can define policies on a global, site, or user scope.

Policies are imported with a global or user scope, based on the legacy policy. If you want your

policies to have a site scope, you need to define the policy by using Lync Server Control Panel or

Lync Server Management Shell after migration. Policies with a site scope take precedence over

policies with a global scope, and policies with a user scope take precedence over policies with a

site scope.

Note:

Dial-in access numbers require an additional step to complete the migration to Lync

Server 2010. During this period of coexistence, the dial-in access numbers that you

imported exist both in your Office Communications Server 2007 R2 pool and in your Lync

Server 2010 pool, but they cannot be modified in Lync Server 2010. They can be

modified in Office Communications Server 2007 R2, and then imported into Lync Server

2010 by running Import-CsLegacyConfiguration. In addition, you cannot view Office

Communications Server 2007 R2 dial-in conferencing access numbers by using the Get-

CsDialInConferencingAccessNumber cmdlet. You can view only Lync Server 2010

dial-in access numbers by using this cmdlet. For details about how dial-in access

numbers behave during coexistence, see Migrate Dial-in Access Numbers.

To migrate policies and settings

1. Log on to the computer where Lync Server Management Shell is installed as a member

of the RTCUniversalServerAdmins group or with the necessary user rights as described

in Delegate Setup Permissions.

2. Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft

Lync Server 2010, and then click Lync Server Management Shell..

3. Run:

Import-CsLegacyConfiguration

Important:

It is good practice to run this cmdlet whenever you run the Topology Builder

Merge wizard. For details, see Merge Using Topology Builder Merge Wizard.

Note:

The Import-CsLegacyConfiguration cmdlet does not migrate personal

identification number (PIN) policy for dial-in conferencing. If you do not want to

use the default PIN policy on Lync Server 2010, you need to modify the policy

manually in your Lync Server 2010 pool. For details about how to modify PIN

policy, see Modify the Default Dial-in Conferencing PIN Settings in the

Deployment documentation.

61


Note:

If the Anonymous Participants setting for Meetings is set to Enforce per user

in your Office Communications Server 2007 R2 conferencing policy, two

conferencing policies are created during migration: one with

AllowAnonymousParticipantsInMeetings set to True and one with

AllowAnonymousParticipantsInMeetings set to False.

After the policies are imported, use the procedure that follows to see the imported

policies in the Lync Server 2010 Control Panel.

To view imported policies


RTCUniversalServerAdmins group or that is a member of the CsViewOnlyAdministrator

role.




3. Click Voice Routing and view the imported policies.

4. Click Conferencing and view the imported policies.

5. Click External User Access and view the imported policies.

6. Click Monitoring and Archiving and view the imported policies.

See Also

(Optional) Verify PIN Policy Settings


The first step in verifying the merge completed successfully is to view the Microsoft Office

Communications Server 2007 R2 topology information that you merged with Microsoft Lync

Server 2010. In Topology Builder, the BackCompatSite node displays the fully qualified domain

name (FQDN) of each Office Communications Server 2007 R2 pool and server that you merged.

Note:

If you have scaled Edge Servers, only the pool-level FQDN is displayed, not the FQDN of

each server within the pool.

The following illustration is an example of a BackCompatSite node after merging an Office

Communications Server 2007 R2 Standard Edition server, a Director, an Edge Server, and a

stand-alone Mediation Server. You cannot edit any properties for these components. Use the

BackCompatSite node to verify that all the Office Communications Server 2007 R2 pools and

servers merged successfully.

To view BackCompatSite in Topology Builder


62



2. In your Office Communications Server 2007 R2 environment, open the Office

Communications Server 2007 R2 administrative tool and note the FQDNs for the pools

and servers that you want to merge.

3. In your Lync Server 2010 environment, open Topology Builder, and then expand the

BackCompatSite node.

4. Verify that the FQDNs for the pools and servers that you merge are displayed.

Note:

You do not see any information in BackCompatSite for server roles that are

collocated on a Front End Server or Standard Edition server. Only server roles

that are required for interoperability between Office Communications Server 2007

R2 and Lync Server 2010 are merged.

You can also use Microsoft Lync Server 2010 Control Panel to view your merged topology. In

Lync Server Control Panel, you can see each server FQDN, pool FQDN, and site name for your

merged topology. Merged servers have a Site name of BackCompatSite.

63


To view the merged topology in Lync Server Control Panel




2. On the Select URL page, select the Standard Edition server or Front End pool that

corresponds to your pilot stack deployment.

3. Click Topology.

4. On the Status tab, verify that servers and pools you merged appear by looking for

BackCompatSite in the Site column.

To see more detail about a merged pool, use the Get-CsPool cmdlet. In addition to the

information that is available in Topology Builder and Lync Server Control Panel, this cmdlet

displays the services that run on the pool.

Note:

When you publish the topology after running the Merge wizard in Topology Builder,

conference directories are merged to Lync Server 2010. Conference directories can be

verified by running the Get-CsConferenceDirectory cmdlet.

To view services on a merged pool


64


Lync Server 2010, and then click Lync Server Management Shell.

2. Run:

Get-CsPool [-Identity <FQDN of the pool>]

For example:

Get-CsPool –Identity lync-se.contoso.net

To verify conference directories merged

1. In your Lync Server 2010 environment, open Lync Server Management Shell.

2. Run:

Get-CsConferenceDirectory

3. Verify that all the conference directories for the pool or server you are merging are now in

Lync Server 2010.

Note:

Each conference directory hosted on a pool is listed in the output of the Get-

CsConferenceDirectory cmdlet. The FQDN of the pool that hosts the

Conference Directory is displayed in ServiceId. ServiceId contains the type of

service and FQDN of the pool. For example,

UserServer:OCS2007R2.contoso.com

Phase 5: Configure the Pilot PoolNow that the pilot pool has been created and legacy deployment information has been merged

with Lync Server 2010, this section identifies a few configurations that must be made to the pilot

pool.

In This Section

Connect Pilot Pool to Legacy Edge Servers

Authorize Connection to Office Communications Server 2007 R2 Edge Server

Connect Pilot Pool to Legacy Mediation Server

Move Legacy User to Pilot Pool

Move Multiple Users

Verify User Replication has Completed

Connect Pilot Pool to Legacy Edge Servers

After deploying Lync Server 2010, a federation route for this site is not configured. In order to use

the federated route that is being used by Office Communications Server 2007 R2, Lync Server

2010 must be configured to use this route.

65


To enable the Lync Server 2010 site to use the Director and Edge Server of the BackCompatSite,

use Topology Builder to associate the legacy Edge Server pool.

To successfully publish, enable, or disable a topology when adding or removing a server role, you

should be logged in as a user who is a member of the RTCUniversalServerAdmins and Domain

Admins groups. It is also possible to delegate the proper administrator rights and permissions.

For details, see Delegate Setup Permissions in the Deployment documentation. For other

configuration changes, only membership in the RTCUniversalServerAdmins group is required.

To associate the legacy Edge pool by using Topology Builder



2. Start Topology Builder: Click Start, click All Programs, click Microsoft Lync Server

2010, and then click Lync Server Topology Builder.

3. Select your Lync Server 2010 site.

4. On the Actions menu, click Edit Properties.

5. Under Site federation route assignment, select Enable, and then select the Office

Communications Server 2007 R2 Director listed.

66


Note:

If you are not able to edit the Site federation route assignment setting, it

means that an Edge Server was not selected when the Topology Builder Merge

wizard was run. For details about enabling this setting, see step 11 in Merge

Using Topology Builder Merge Wizard.

6. Click OK to close the Edit Properties page.

7. In Topology Builder, navigate to the Standard Edition server or Front End pool, right-

click the pool, and then click Edit Properties.

8. Under Associations, select the check box next to Associate Edge pool (for media

components).

9. From the list, select the Edge Server for the BackCompatSite.


11. In Topology Builder, select the top-most node, Lync Server 2010.



67



For each Lync Server 2010 Front End Server or Standard Edition server and each Director in

your pilot pool, you must update the list of internal servers that are authorized to connect to the

Office Communications Server 2007 R2 Edge Server. Without these updates, external

audio/visual (A/V) conferencing for users joining by using the legacy Edge Server will not work.

This topic explains how to add the Lync Server 2010 Front End Server or Standard Edition server

and Director in your pilot pool to the list of servers that are authorized to connect to the Office

Communications Server 2007 R2 Edge Server.


1. Log on to the Office Communications Server 2007 R2 Edge Server with an account that

is a member of the RTCLocalServerAdmins group.

2. From the Office Communications Server 2007 R2 Edge Server, from the Administrative

Tools group, open the Computer Management snap-in.

3. In the console tree, expand Services and Applications.

4. Right-click Office Communications Server 2007 R2, and then click Properties.

5. Click the Internal tab.

6. Under Add Server, click Add.

7. In the Add Office Communications Server dialog box, enter the appropriate

information:

Specify the fully qualified domain name (FQDN) of each Lync Server 2010 Front End

Server or Standard Edition server.

Important:

If the Lync Server Front End Server is part of a Lync Server 2010 pool,

additionally specify the pool FQDN.

Specify the FQDN of the Lync Server 2010 Director if you configured a static route on

the pool that specifies the next hop computer by its FQDN.

8. After you have added an entry for each Lync Server 2010 Front End Server or Standard

Edition server and Director, click OK to close the Properties page.

Connect Pilot Pool to Legacy Mediation Server

After deploying Microsoft Lync Server 2010, a Mediation Server for this site is not configured. In

order to use the Mediation Server being used by Microsoft Office Communications Server 2007

R2, Lync Server 2010 must be configured to use this server.

If a Voice Route and Voice Policy existed in the legacy pool, after you merge Office

Communications Server 2007 R2 with Lync Server 2010 and run the Import-

68


CsLegacyConfiguration cmdlet, the Lync Server 2010 pilot pool now has all the necessary

configuration information to

Route outbound calls through the legacy Office Communications Server 2007 R2 Mediation

Server

Route inbound calls from the legacy pool to the Lync Server 2010 pool

Note:

Lync Server 2010 Mediation Server features will not be functional until all Mediation

Server components are configured, which occurs later in this document. For details about

configuring Lync Server 2010 Mediation Server, see Migrate Mediation Server.

Note:

For details about finding qualified public switched telephone network (PSTN) gateways,

IP-PBXs and SIP trunking services that work with Lync Server 2010, see "Microsoft

Unified Communications Open Interoperability Program" at

http://go.microsoft.com/fwlink/?LinkId=206015.

To enable the Lync Server 2010 pilot pool to use the legacy Mediation Server, you must have a

Voice Route and Voice policy configured that point to the legacy Mediation Server. If you do not

have a legacy Voice Route or Voice Policy, use the following the procedure to configure these

settings using Lync Server 2010 Control Panel or by using the Lync Server Management Shell.

To create a voice route to the legacy Mediation Server by using Lync Server Control Panel


RTCUniversalServerAdmins group or is assigned to the CsVoiceAdministrator

administrative role.




3. Click Voice Routing, and then click the Route tab.

4. Click New to create a New Voice Route.

5. Fill in the following fields:

Name: enter a descriptive name of the voice route. For this document we will use

W13PSTNRoute.

Description: enter a short description of the voice route.

6. Skip all remaining sections until you reach Associated gateways, and then click Add.

Select the default gateway listed, and then click OK.

7. Under Associated PSTN Usages, click Select.

8. From the Select PSTN Usage Record page, select the legacy Mediation Server fully

qualified domain name (FQDN), and then click OK.

69



9. From the New Voice Route page, click OK to create the Voice Route.

10. From the Voice Routing page, select Route.

11. Move the newly created route to the top of the list, and then click Commit.

To create a voice route to the legacy Mediation Server by using Lync Server Management Shell


RTCUniversalServerAdmins group or is assigned to the CsVoiceAdministrator




3. Get the FQDN of the legacy Mediation Server by running the following command:

Get-CsService –MediationServer

The Identity parameter will contain the name of the legacy Mediation Server. In this

example, the value is this: MediationServer:medsvr01.contoso.net

4. Next, verify that a voice policy exists for the legacy Mediation Server by running the

following command:

Get-CsVoicePolicy

The PSTNUsages parameter should not be empty, but return a value of {Local} or the

name of any customer PSTNUsage created on the legacy Mediation Server.

5. Now that we have verified that a legacy Mediation Server exists and it has a voice policy,

we create a route in the Lync Server 2010 pool that points to this legacy Mediation

Server.

The following code defines a generic voice route that routes any outbound calls from the

Lync Server 2010 pool to the legacy Mediation Server.

New-CsVoiceRoute -Name W13PSTNRoute -NumberPattern ".*" -

PstnUsages Local -PstnGatewayList

@{Add="MediationServer:medsvr01.contoso.net "}

6. Finally, run the following command to set the default voice route for this pool.

Set-CsVoiceRoute -Identity W13PSTNRoute -Priority 0

7. Run the Get-CsVoiceRoute cmdlet to verify the voice route settings.

For our example, the Identity parameter should be set to W13PSTNRoute. The

PSTNUsages should be set to {Local} and the PSTNGatewayList should point to the

FQDN of the legacy Mediation Server, Mediation:medsvr01.contoso.net.

Move Legacy User to Pilot Pool

You can move a pilot user to the new Microsoft Lync Server 2010 deployment using the following

two methods: Microsoft Lync Server 2010 Control Panel and Lync Server Management Shell.

70


There are requirements that must be met to ensure a smooth transition to Lync Server 2010. For

details before completing the procedures in this topic, see Configure Clients for Migration.

Important:

You cannot use the Active Directory Users and Computers snap-in or the Microsoft Office

Communications Server 2007 R2 administrative tools to move users from your legacy

environment to Lync Server 2010.

Important:

The Move-CsLegacyUser cmdlet requires that user names are properly formed and do

not have leading or trailing spaces. You cannot move a user account using the Move-

CsLegacyUser cmdlet if it contains leading or trailing spaces.

When you move a user to a Lync Server 2010 pool, the data for the user is moved to the back-

end database that is associated with the new pool.

Important:

This data includes the active meetings created by the legacy user. For example, if a

legacy user has configured a my meeting conference, that conference will still be

available in the new Lync Server 2010 pool after the user has been moved. The details to

access that meeting will still be the same conference URL and conference ID. The only

difference is that the conference is now hosted in the Lync Server 2010 pool, and not in

the Office Communications Server 2007 R2 pool.

Note:

Homing users on Lync Server 2010 does not require that you deploy upgraded clients at

the same time. New functionality will be available to users only when they have upgraded

to the new client software.

The following figure shows users enabled for Office Communications Server 2007 R2 in the

Office Communications Server 2007 R2 administrative tool. These users will be moved to Lync

Server 2010 using the Lync Server 2010 Control Panel or the Lync Server Management Shell.

71


The following figure provides a view of these same users in Lync Server 2010 Control Panel. The

Registrar pool column entry for each user is set to Legacy, which indicates that these users are

still homed on Office Communications Server 2007 R2 and have not been moved to Lync Server

2010.

To move a user by using the Lync Server 2010 Control Panel

1. Log on to a Standard Edition server or Front End Server with an account that is a

member of the RTCUniversalServerAdmins group or a member of the CsAdministrator or

CsUserAdministrator administrative role.

2. Click Start, then All Programs, then Microsoft Lync Server 2010, then Lync Server

Control Panel.

3. Click Users, click Add Filter, build the following query Legacy user Equal to True, and

then click Find.

4. In the search results, select a user.

Note:

Notice that the Registrar Pool column shows <Legacy>. This means that the

user you have selected is homed on Office Communications Server 2007 R2.

5. Click Action and then click Move selected users to pool.

72


Important:

If Move selected users to pool is not available, ensure the account is a member

of the CsAdministrator or CsUserAdministrator group.

6. In Move Users, select the Destination registrar pool, which is your Lync Server 2010

pool, and then click OK.

7. Verify that the Registrar pool column for the user now contains the Lync Server 2010

pool, which indicates that the user has been successfully moved.

To move a user by using the Lync Server Management Shell


RTCUniversalServerAdmins group or a member of the CsAdministrator or




3. At the command line, type the following:

Get-CsUser –OnOfficeCommunicationServer

Using a legacy user’s sip address as a parameter, run the Move-CsLegacyUser cmdlet.

Move-CsLegacyUser –Identity "sip address" –Target "pool_FQDN"

73


For example, to move one of the legacy users to the Lync Server 2010 pilot pool, run:

Move-CsLegacyUser –Identity "sip:[email protected]" –Target "lync-

se.contoso.net"


Get-CsUser "sip address"

The RegistrarPool identity now points to the pool you specified as “pool_name” in the

previous step. The presence of this identity confirms that the user has been successfully

moved.

For details about the Get-CsUser cmdlet described in this section, run: Get-Help Get-CsUser -Detailed

5. By using the Lync Server Control Panel, you can also verify that these users have been

moved by viewing the Registrar pool column.

Important

To return a user to a legacy Office Communications Server 2007 R2 pool, or to move a user

between Lync Server 2010 pools, see Move-CsUser in the Lync Server Management Shell

documentation. For details about the Move-CsUser cmdlet, run:

Get-Help Move-CsUser

Important

The Move-CsLegacyUser cmdlet may fail with the following error:

Move-CsLegacyUser : SetMoveResourceData failed because the user is not provisioned. At line:1 char:18 + Move-CsLegacyUser <<<< -Identity "[email protected]" -Target "lync-se.contoso.net" + CategoryInfo : InvalidOperation: (CN=Jeff Ander...contoso,DC=net:OCSADUser) [Move-CsLegacyUser], MoveUserException + FullyQualifiedErrorId : MoveLegacyUserError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsLegacyUserCmdlet

If you experience this error, see Verify User Replication has Completed for resolution.

Move Multiple Users

You can move groups of users to the new Microsoft Lync Server 2010 deployment using the

following two methods: Lync Server Control Panel and Lync Server Management Shell. There are

requirements that must be met to ensure a smooth transition to Lync Server 2010. For details

before completing the procedures in this topic, see Configure Clients for Migration.

74


Important:




Important:






Important:



available in the new Lync Server 2010 pool, after the user has been moved. The details

to access that meeting will still be the same conference URL and conference ID. The

only difference is that the conference is now hosted in the Lync Server 2010 pool, and not

in Office Communications Server 2007 R2 pool.

Note:




To move multiple users by using the Lync Server Control Panel


RTCUniversalUserAdmins group or minimally a member of the CsUserAdministrator





3. Click Users, click Add Filter, build the query Legacy user Equal to True, and then click

Find.

4. In the search results, select at least two users.

5. Click Action ,and then click Move selected users to pool.

Important:


of the RTCUniversalUserAdmins group or a member of the CsAdministrator or


6. In Move Users, select the Destination Registrar pool, which is your Lync Server 2010

75





For details about the cmdlets described in this section, run:

Get-Help <cmdlet name> -Detailed

To move multiple users by using the Lync Server Management Shell






3. At the command line, type the following and replace User1 and User2 with specific user

names you want to move and replace pool_FQDN with the name of the destination pool:

Get-CsUser –Filter {DisplayName –eq “User1” –or DisplayName – eq

“User2”} | Move-CsLegacyUser –Target “pool_FQDN”

4. At the command line, type the following

Get-CsUser “User1”

The Registrar Pool identity should now point to the pool you specified as “pool_FQDN”

in the previous step. The presence of this identity confirms that the user has been

successfully moved.

76


To move all users at the same time by using the Lync Server Management Shell







Get-CsUser –OnOfficeCommunicationServer | Move-CsLegacyUser –

Target “pool_FQDN”


Get-CsUser “user name”

where user name is the name of a legacy user.

The Registrar Pool identity now points to the pool you specified as “pool_FQDN” in the


moved.

Important


Move-CsLegacyUser : SetMoveResourceData failed because the user is not provisioned. At line:1 char:18 + Move-CsLegacyUser <<<< -Identity "[email protected]” -Target "lync-se.contoso.net" + CategoryInfo : InvalidOperation: (CN=Jeff Ander...contoso,DC=net:OCSADUser) [Move-CsLegacyUser], MoveUserException + FullyQualifiedErrorId : MoveLegacyUserError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsLegacyUserCmdlet

If you experience this error, see the topic Verify User Replication has Completed for

resolution.

Verify User Replication has Completed

When running the Move-CsUser and Move-CsLegacyUser cmdlets, you may experience a

failure due to user information between Active Directory Domain Services (AD DS) and the Lync

Server 2010 databases being out of sync because the initial replication is incomplete. The time it

takes for the successful completion of the Lync Server 2010 User Replicator service's initial

synchronization depends on the number of domain controllers that are hosted in the Active

Directory forest that hosts the Lync Server 2010 pool. The Lync Server 2010 User Replicator

77


service initial synchronization process occurs when the Lync Server 2010 Front End Server is

started for the first time. After that, the synchronization is then based on the User Replicator

interval. Complete the following steps to verify user replication has completed before running the

Move-CsUser and Move-CsLegacyUser cmdlets.

To verify user replication has completed



2. Click the Start menu, and then click Run.

3. Enter eventvwr.exe and then click OK.

4. In Event Viewer, click Applications and Services logs to expand it, and then select

Lync Server.

5. In the Actions pane click Filter Current Log.

6. From the Event sources list, click LS User Replicator.

7. In <All Event IDs> enter 30024 and then click OK.

8. In the filtered events list, on the General tab, look for an entry that states user replication

has completed successfully.

Phase 6: Verify Your Pilot MigrationVerify that the migration completed successfully by following the steps described in this section.

Verifying your migration encompasses two general areas:

Verifying the policies and configuration settings that you imported from an earlier version of

Office Communications Server by using the Import-CsLegacyConfiguration cmdlet.

Running functional tests against each Microsoft Lync Server 2010 workload. This step is

optional.

In This Section


Running Functional Tests Against Workloads (optional)


After you merge the topology and run the Import-CsLegacyConfiguration cmdlet, verify that

your Microsoft Office Communications Server 2007 R2 policies and settings were imported to

Microsoft Lync Server 2010. The following table lists the policies and settings that you should

verify.

78


Policies and Settings to Verify after Migration

If you use this workload: Verify these policies and settings:

Instant messaging (IM) and conferencing Presence policy

Conferencing policy

Dial-in conferencing Dial-in access numbers

Dial plans

Enterprise Voice Voice policy

Voice routes

Dial plans

PSTN usage settings

Communicator Web Access Simple URLs

External users External access policies

Archiving Archiving policy

For most of these policies and settings you can use either Microsoft Lync Server 2010 Control

Panel or Lync Server Management Shell cmdlets. For the presence policy, however, you must

use a cmdlet.

Note:

To verify policies, you can compare the policy names that you have in your Office

Communications Server 2007 R2 deployment to the names that are now in Lync Server

2010 to ensure that all the policies were imported. It is not necessary to compare all the

settings within a policy.

Note:

For Mediation Server, legacy configuration settings like server ports and protocols are not

merged to Lync Server 2010. The administrator can configure these settings using the

Topology Builder. Additionally, the default encryption level for Lync Server 2010 Mediation

Server is RequireEncryption. Ensure that your legacy Office Communications Server

2007 R2 pool matches this default encryption level setting.

To verify policies and settings

1. In your Office Communicator 2007 R2 environment, make note of the names of dial plans

(formerly known as location profiles), dial-in access numbers (Conferencing Attendant

access phone numbers and regions), voice routes, and the policies listed in the

preceding table, in addition to the URLs used for Communicator Web Access.


RTCUniversalUserAdmins or RTCUniversalServerAdmins group or minimally is a

member of the CsViewOnlyAdministrator administrative role.

79





4. To verify imported conferencing policies, click Conferencing, click Conferencing Policy,

and then verify that all the conferencing policies in your Office Communicator 2007 R2

environment are included in the list.

Note:

The Meeting policy from previous versions of Office Communications Server is

now known as the conferencing policy in Lync Server. Additionally, the

Anonymous Particpants setting from previous versions of Office

Communications Server is now a setting in the Lync Server conferencing policy.

Note:

In Office Communications Server 2007 R2, if the conferencing policy is not set to

use per user, only global policy settings are imported. No other conference

policies are imported in this situation.

Note:

If Anonymous Participants is set to Enforce per user in your Office

Communications Server 2007 R2 conferencing policy, two conferencing policies

are created during migration: one with

AllowAnonymousParticipantsInMeetings set to True and one with

AllowAnonymousParticipantsInMeetings set to False.

5. To verify imported dial plans, click Voice Routing, click Dial Plan, and then verify that all

the dial plans in your Office Communicator 2007 R2 environment are included in the list.

Note:

In Lync Server 2010, location profiles are now referred to as dial-plans.

6. To verify imported voice policies, click Voice Routing, click Voice Policy, and then verify

that all the voice policies in your Office Communicator 2007 R2 environment are included

in the list.

Note:

If voice policy is not set to use per user in your Office Communications Server

2007 R2 environment, only global policy settings are imported. No other voice

policies are imported in this situation.

7. To verify imported voice routes, click Voice Routing, click Route, and then verify that all

the voice routes in your Office Communicator 2007 R2 environment are included in the

list.

8. To verify imported PSTN usage settings, click Voice Routing, click PSTN Usage, and

then verify that the PSTN Usage settings from your Office Communicator 2007 R2


9. To verify imported external access policies, click External User Access, click External

80


Access Policy, and then verify that all the external access policies in your Office

Communicator 2007 R2 environment are included in the list.

10. To verify archiving policies, click Monitoring and Archiving, click Archiving Policy, and

then verify that all the archiving policies in your Office Communications Server 2007 R2




12. To verify presence policies, run:

Get-CsPresencePolicy

By looking at the name in the Identity parameter, verify that all the presence policies in

your Office Communications Server 2007 R2 environment were imported.

To verify policies and settings by using cmdlets


RTCUniversalUserAdmins or RTCUniversalServerAdmins group or minimally is a

member of the CsViewOnlyAdministrator administrative role.



3. Run the cmdlets in the following table to verify policies and settings.

The syntax of these cmdlets is like the following example:

Get-CsConferencingPolicy

For details about these cmdlets, run:


Cmdlets to Verify Configuration Settings

For this policy or

setting:

Use this cmdlet:

Presence policy Get-CsPresencePolicy

Conferencing policy Get-CsConferencingPolicy

Note:

If conferencing policy is not set to use per user

in your Office Communications Server 2007 R2

environment, only global policy settings are

imported. No other conferencing policies are

imported in this situation.

Note:

If AnonymousParticipants is set to Enforce

per user in your Office Communications Server

81


For this policy or

setting:

Use this cmdlet:

2007 R2 conferencing policy, two conferencing

policies are created during migration: one with

AllowAnonymousParticipantsInMeetings set

to True and one with

AllowAnonymousParticipantsInMeetings set

to False.

Note:

To enable federated users from your legacy

Office Communications Server 2007 R2

deployment to join meetings scheduled by Lync

Server 2010 users, the meeting policy assigned

to the Lync Server 2010 user must allow

anonymous scheduling. To configure

anonymous scheduling, from the Lync Server

Management Shell run Get-CsConferencingpolicy , then run Set-CsConferencingPolicy –Identity <ConferencingPolicyName> -AllowAnonymousParticipantsInMeetings $True

Dial-in access numbers Get-CsDialInConferencingAccessNumber

Note:

This cmdlet returns only Lync Server 2010 dial-

in access numbers. It does not return any Office

Communications Server 2007 R2 dial-in access

numbers.

Dial plans Get-CsDialPlan

Voice policy Get-CsVoicePolicy

Note:

If voice policy is not set to use per user in your

Office Communications Server 2007 R2

environment, only global policy settings are

imported. No other voice policies are imported in

this situation.

Voice routes Get-CsVoiceRoute

PSTN Usage Get-CsPstnUsage

82


For this policy or

setting:

Use this cmdlet:

URLs Get-CsSimpleUrlConfiguration

External access policies Get-CsExternalAccessPolicy

Archiving policy Get-CsArchivingPolicy

Running Functional Tests Against Workloads (optional)

After verifying that topology information and configuration settings were merged correctly, you

should perform some functional tests to verify that the various workloads perform as expected.

Run tests for each workload that you are deploying, starting with peer-to-peer sessions and then

expanding to meetings of three or more participants. Include remote users and federated users to

verify that external access works as expected.

Note:

These functional tests are provided as representative examples. Tailor these examples to

your organization and test only the workloads that you deployed.

Note:

Although you perform these functional tests before the client rollout, you should deploy

Microsoft Lync 2010 to a few trial users homed on Microsoft Lync Server 2010 to use in

these tests.

The following section describes some example scenarios.

Functional Test Scenarios

Remote Office Communications Server 2007 R2 User and Internal Lync Server 2010 User

Users

Remote user who is homed on Office Communications Server 2007 R2

Internal user who is homed on Lync Server 2010

Scenarios

1. The remote user calls the internal user and uses instant messaging (IM), desktop sharing,

and audio/video.

2. The internal user calls the remote user and uses IM, desktop sharing, and audio/video.

3. The remote user adds a third user, who is homed on Lync Server 2010, to a current IM

session. They use desktop sharing, and audio/video.

4. The internal user adds a third user, who is homed on Office Communications Server 2007

R2, to a current IM session. They use desktop sharing, and audio/video.

Remote Office Communications Server 2007 R2 User and Remote Lync Server 2010 User

83


Users


Remote user who is homed on Lync Server 2010

Scenarios

1. The remote Office Communications Server 2007 R2 user calls the remote Lync Server 2010

user and uses instant messaging (IM), desktop sharing and audio/video.

2. The remote Lync Server 2010 user calls the remote Office Communications Server 2007 R2

user and uses IM, desktop sharing and audio/video.

3. The remote Lync Server 2010 user adds a third user, who is homed on Lync Server 2010 to a

current IM session. They use desktop sharing and audio/video.

4. The remote Lync Server 2010 user adds a third user, who is homed on Office

Communications Server 2007 R2 to a current IM session. They use desktop sharing and

audio/video.

5. The remote Office Communications Server 2007 R2 user adds a third user, who is homed on

Lync Server 2010 to a current IM session. They use desktop sharing and audio/video.

6. The remote Office Communications Server 2007 R2 user adds a third user, who is homed on

Office Communications Server 2007 R2 to a current IM session. They use desktop sharing

and audio/video.

Remote Lync Server 2010 User and Internal Office Communications Server 2007 R2 User

Users


Internal user who is homed on Office Communications Server 2007 R2

Scenarios

1. The remote user calls the internal user and uses IM, desktop sharing, and audio/video.

2. The internal user calls the remote user and uses IM, desktop sharing, and audio/video.

3. The remote user adds a third user, who is homed on Office Communications Server 2007 R2,

to a current IM session. They use desktop sharing, and audio/video.

4. The internal user adds a third user, who is homed on Lync Server 2010, to a current IM

session. They use desktop sharing, and audio/video.

Unscheduled Conferencing

Users



Scenarios

1. A user homed on Office Communications Server 2007 R2 sets up an unscheduled (Meet

Now) A/V conference and invites a user homed on Lync Server 2010 and a user homed on

Office Communications Server 2007 R2.

84


2. A user homed on Lync Server 2010 sets up an unscheduled (Meet Now) A/V conference and

invites a user homed on Lync Server 2010 and a user homed on Office Communications

Server 2007 R2.

3. A user homed on Office Communications Server 2007 R2 shares the desktop during a

conference.

4. A user homed on Lync Server 2010 shares the desktop during a conference.

5. A user homed on Lync Server 2010 shares a PowerPoint presentation during a conference.

Dial-in Conference Hosted on Office Communications Server 2007 R2

Users





Scenarios

An internal Office Communications Server 2007 R2 user organizes a dial-in meeting

(scheduled or unscheduled) that is hosted on Office Communications Server 2007 R2. A

remote Office Communications Server 2007 R2 user, a remote Lync Server 2010 user, and

an internal Lync Server 2010 user join the meeting.

A remote Office Communications Server 2007 R2 user and a remote Lync Server 2010 user

dial in to the conference.

Dial-in Conference Hosted on Lync Server 2010

Users





Scenarios

An internal Lync Server 2010 user organizes a dial-in meeting (scheduled or unscheduled)

that is hosted on Lync Server 2010. A remote Office Communications Server 2007 R2 user, a

remote Lync Server 2010 user, and an internal Office Communications Server 2007 R2 user

join the meeting.

A remote Office Communications Server 2007 R2 user and a remote Lync Server 2010 user

dial in to the conference.

Conference Hosted on Office Communications Server 2007 R2 with Application Sharing Modality

Users




85



Federated user

Scenarios

An Office Communications Server 2007 R2 internal user organizes a conference with

application sharing modality. The conference is hosted on Office Communications Server

2007 R2.

A remote Office Communications Server 2007 R2 user, a remote Lync Server 2010 user, an

internal Lync Server 2010 user, and a federated user join the meeting.

All users can view the shared desktop or application of the Office Communications Server

2007 R2 internal user.

All other users in the meeting can start sharing in the same conference.

Conference Hosted on Lync Server 2010 with Application Sharing Modality

Users





Federated user

Scenarios

A Lync Server 2010 internal user organizes a conference that is hosted on Lync Server 2010

and adds the application sharing modality to the conference.

A remote Office Communications Server 2007 R2 user, a remote Lync Server 2010 user, an

internal Office Communications Server 2007 R2 user, and a federated user join the meeting.

All users can view the shared desktop or application of the Lync Server 2010 internal user.

All other users in the meeting can start sharing in the same conference.

Person-to-Person Federation

Users

A user who is homed on Lync Server 2010

A federated user

Scenarios

A Lync Server 2010 user calls a federated user. They use IM, audio/video, and desktop

sharing.

A federated user calls a Lync Server 2010 user. They use IM, audio/video, and desktop

sharing.

Voice

Users



86




Scenarios:

A Lync Server 2010 user (internal or remote) calls a Office Communications Server 2007 R2

user (internal or remote), puts the call on hold, and then resumes the call. One of the calling

parties transfers the call to another user (Lync Server 2010 or Office Communications Server

2007 R2 (internal or remote).

An Office Communications Server 2007 R2 user (internal or remote) calls a Lync Server 2010

user (internal or remote). One of the parties transfers the call to a public switched telephone

number (PSTN).

A PSTN caller calls a Lync Server 2010 user. The Lync Server 2010 user transfers the call to

a Office Communications Server 2007 R2 user.

A Lync Server 2010 user calls a PSTN and then transfers the call to an Office

Communications Server 2007 R2 user.

A Lync Server 2010 user sets a call forwarding rule with the call forwarding destination as a

Office Communications Server 2007 R2 user. The number is forwarded to the correct

destination.

A PSTN caller calls a Lync Server 2010 user. The Lync Server 2010 user parks the call, and

another Lync Server 2010 user retrieves the call.

Phase 7: Add Lync Server 2010 Edge Server and Director to Pilot PoolThe topics in this section explain how to add a Lync Server 2010 Director and an Edge Server to

the pilot pool deployment. The topics provide configuration and verification guidance when

running the Deploy Director pool and the Deploy New Edge pool wizards.

In This Section

Deploy Pilot Director and Edge Servers

Deploy Pilot Director and Edge Servers

This topic highlights configuration settings you should be aware of prior to deploying your Lync

Server 2010 Edge Server and Director. The deployment and configuration processes for Lync

Server 2010 are much different from previous releases because Lync Server 2010 provides new

tools for installation and administration that change the way that you work with Lync Server

components. This section only highlights key points you should consider as part of your pilot pool

deployment. For detailed steps, see Deploying Edge Servers in the Deployment documentation,

which describes the deployment process and also gives configuration information for external

user access.



87


Admins groups. It is also possible to delegate the proper administrator rights and permissions for

adding server roles. For details, see Delegate Setup Permissions in the Standard Edition server

or Enterprise Edition server deployment documentation. For other configuration changes, only

membership in the RTCUniversalServerAdmins group is required.

Define a Director Pool





3. On the welcome page, click Download Topology from Existing Deployment, and then

save a local copy to a file.

4. In the left pane, expand the tree view, right-click Director pools, and then select New

Director Pool.

5. On the Define the Director pool FQDN page, specify the computer fully qualified

domain name (FQDN) (lync-dir.contoso.net for our example), select the Single

computer pool option, and then click Next.

6. On the Define the file share page, select Use a previously defined file share or

Define a new file share, and then click Next.

Note:

The file share assigned to a Director is not actually used, so you can assign the

file share of any pool in the organization.

7. On the Specify the Web Services URL page, specify the FQDN for the Director’s

External Base URL, and then click Finish. The name must be resolvable from Internet

DNS servers and point to the public IP address of the reverse proxy, which listens for

HTTP/HTTPS requests to that URL and proxies them to the External Web Services

virtual directory on that Director.

As you navigate through the Define New Edge Pool wizard, review the key configuration settings

shown in the following steps. Note that only a few pages of the Define New Edge Pool wizard

are shown.

Define an Edge Pool



2. From Topology Builder, right-click Edge pools, and then select New Edge pool.

88


3. An Edge pool can be a Multiple computer pool or Single computer pool.

89


4. On the Select features page, do not enable federation. Federation is currently routed

through the legacy Office Communications Server 2007 R2 Edge Server. For details

about changing the federation route to Lync Server 2010 Edge Servers, see Configure

Federation Routes and Media Traffic. This setting will be configured in a later phase of

migration.

90


5. Next, continue completing the following wizard pages: External FQDNs, Define the

intenral IP address, and Define the external IP address.

6. On the Define the next hop page, select the Director for the next hop of the Lync Server

2010 Edge Server pool.

91


7. On the Associate Front End pools page, do not associate a pool with this Edge Server

pool at this time. External media traffic is currently routed through the legacy Office

Communications Server 2007 R2 Edge Server. This setting will be configured in a later

phase of migration.

92


8. Click Finish and then Publish the topology.

9. Follow the steps in Setting Up the Director in the Deployment documentation to install the

files on the new Director, configure certificates, and start the services.

10. Follow the steps in Install Edge Servers in the Deployment documentation to install the

files on the new Edge Server, configure certificates, and start the services.

It’s very important that you follow the guidelines in the topics Deploying Edge Servers and Setting

Up the Director in the Deployment documentation. This section merely provided some guidance

on configuration settings when installing these server roles.

You should now have a legacy Office Communications Server 2007 R2 deployed in parallel with a

Lync Server 2010 deployment. Each deployment includes an Edge Server, a Director, a Mediation

Server, and a Standard Edition server. The Mediation Server is collocated on the Standard

Edition server in Lync Server 2010. It is configured as stand-alone server in Office

Communications Server 2007 R2. Federation for each deployment is through the legacy Office


Verify that both deployments are running properly, services are started, and you can administer

each deployment prior to moving to the next phase.

Phase 8: Move from Pilot Deployment into ProductionThe topics in this section describe tasks you must complete prior to moving your deployment of

Lync 2010 from a pilot deployment to a production-level deployment.

93


In This Section

Configure Federation Routes and Media Traffic

Verify Federation and Remote Access for External Users


Migration)

Move Multiple Users


Run Functional Tests for Response Groups

Move Exchange Unified Messaging Contact Objects

Verify that all Exchange UM Contact Objects are Removed from the Legacy Pool

Configure Federation Routes and Media Traffic

Federation is a trust relationship between two or more SIP domains that permits users in

separate organizations to communicate across network boundaries. After you migrate to your

Lync Server 2010 pilot pool, you need to transition from the federation route of your Microsoft

Office Communications Server 2007 R2 Edge Servers to the federation route of your Microsoft

Lync Server 2010 Edge Servers.

Use the procedures that follow to transition the federation route and the media traffic route from

your Office Communications Server 2007 R2 Edge Server and Director to your Lync Server 2010

Edge Server and Director, for a single-site deployment.

Important:

Changing the federation route and media traffic route requires that you schedule

maintenance downtime for the Lync Server 2010 and Office Communications Server

2007 R2 Edge Servers. This entire transition process also means that federated access

will be unavailable for the duration of the outage. You should schedule the downtime for a

time when you expect minimal user activity. You should also provide sufficient notification

to your end users. Plan accordingly for this outage and set appropriate expectations

within your organization.

Important

If your legacy Office Communications Server 2007 R2 Edge Server is configured to use the same

FQDN for the Access Edge service, Web Conferencing Edge service, and the A/V Edge service,

the procedures in this section to transition the federation setting to a Lync Server 2010 Edge

Server are not supported. If the legacy Edge services are configured to use the same FQDN, you

must first migrate all your users from Office Communications Server 2007 R2 to Lync Server

2010, then decommission the Office Communications Server 2007 R2 Edge Server before

enabling federation on the Lync Server 2010 Edge Server. For details, see the following topics:

Move Remaining Users to Lync Server 2010 (Office Communications Server 2007 R2 Migration)

"Remove Servers and Server Roles" at http://go.microsoft.com/fwlink/?LinkId=205887

94





Admins groups. It is also possible to delegate the proper user rights and permissions for adding

server roles. For details, see Delegate Setup Permissions in the Standard Edition server or

Enterprise Edition server Deployment documentation. For other configuration changes, only


To remove the legacy federation association from Lync Server 2010 sites






4. In the left pane, navigate to the site node.

5. Right-click the site, and then click Edit Properties.

6. Select Federation route in the left pane.

7. Under Site federation route assignment, select Disable to disable the federation route

through the BackCompatSite.

95



9. From Topology Builder, select the top node Lync Server 2010.

10. From the Actions pane, click Publish Topology and complete the wizard.

To configure the legacy Edge Server as a non-federating Edge Server

1. From Topology Builder, in the Actions pane. click Merge 2007 or 2007 R2 Topology.

2. Click Next to continue.

3. On the Specify Edge Setup, select the Edge Server Internal FQDN that is currently

configured for federation, and then click Change.

4. Click Next and accept the default settings until you get to the Specify External Edge

page:

96


5. In Specify External Edge, clear the This Edge pool is used for federation and public

IM connectivity check box. This will remove the federation association with the

BackCompatSite.

Important:

This step is important. You must clear this option to remove the legacy federation

association.

6. Click Next and accept the default settings of the remaining pages of the wizard.


Note:

You may see the following message: WARNING : No Office Communications

Server 2007 / Office Communications Server 2007 R2 Edge has been

enabled for federation. This warning is expected and can be ignored.

8. In the Status column, verify that the value is Success, and then click Finish to close the

wizard.

9. From the Actions pane, select Publish Topology, and then click Next.

10. When the Publishing wizard completes, click Finish to close the wizard.

97


As shown in the previous figure, the Site federation route assignment is set to

Disabled.

To configure certificates on the Lync Server 2010 Edge Server

1. Export the external Access Proxy certificate, with the private key, from the legacy Office


2. On the Lync Server 2010 Edge Server, import the Access Proxy external certificate from

the previous step.

3. Assign the Access Proxy external certificate to the Lync Server 2010 external interface of

the Edge Server.

4. The internal interface certificate of the Lync Server 2010 Edge Server should not be

changed.

To change Office Communications Server 2007 R2 federation route to use Lync Server 2010 Edge Server

1. On the Office Communications Server 2007 R2 Standard Edition server or Front End

Server, log on with an account that is a member of the RTCUniversalServerAdmins

group.

2. On the Office Communications Server 2007 R2 Standard Edition server or Front End

Server, click Start, click Administrative Tools, and then click Office Communications

98


Server 2007 R2.

3. In the left pane, expand the top node, and then right-click the Forest node. Select

Properties, and then click Global Properties.

4. Click the Federation tab.

5. Select the check box to enable federation and Public IM connectivity.

6. Enter the FQDN of the Lync Server 2010 Edge Server, and then click OK.

To update Lync Server 2010 Edge Server federation next hop

1. Returning to your Lync Server 2010 Standard Edition server or Front End Server, log on

to the computer with an account that is a member of the RTCUniversalServerAdmins

group.



3. Select the option to Download topology from existing deployment and then click OK.

4. In the left pane, navigate to the Edge pools node.

5. Expand the node, right-click the Edge Server listed, and then click Edit Properties.

6. On the General page, under Next hop selection, select from the drop-down list the Lync

Server 2010 Edge Server or Director, if a Lync Server 2010 Director was configured.


99



9. From the Actions pane, click Publish Topology and complete the wizard.

To configure Lync Server 2010 Edge Server outbound media path

1. From Topology Builder, navigate to the pool below Standard Edition Front End

Servers or Enterprise Edition Front End pools.

2. Right-click the pool, and then click Edit Properties.

3. In the Associations section, select the Associate Edge pool (for media components)

check box.

4. From the drop down box, select the Lync Server 2010 Edge Server.


To turn on Lync Server 2010 Edge Server federation

1. From Topology Builder, in the left pane, navigate to the Edge pools node.

2. Expand the node, right-click the Edge Server listed, and then click Edit Properties.

100


Note:

Federation can only be enabled for a single Edge Server pool. If you have

multiple Edge pools, select one to use as the federating Edge Server pool.

3. On the General page, select the Enable federation for this Edge pool (Port 5061)

check box.


5. Next, navigate to the site node.

6. Right-click the site, and then click Edit Properties.

7. In the left pane, click Federation route.

8. Under Site federation route assignment, select Enable, and then from the list select the

Lync Server 2010 Edge Server or Director listed.


For multi-site deployments, complete this procedure at each site.

To publish Edge Server configuration changes


101


2. From the Actions pane, select Publish Topology and complete the wizard.

3. Wait for Active Directory replication to occur to all pools in the deployment.

Notes:

You may see the following message:

Warning: The topology contains more than one Federated Edge Server. This can occur

during migration to a more recent version of the product. In that case, only one Edge

Server would be actively used for federation. Verify that the external DNS SRV record

points to the correct Edge Server. If you want to deploy multiple federation Edge

Server to be active concurrently (that is, not a migration scenario), verify that all

federated partners are using Office Communications Server 2007 R2 or Lync Server.

Verify that the external DNS SRV record lists all federation enabled Edge Servers.

This warning is expected and can be safely ignored.

To configure Lync Server 2010 Edge Server

1. Bring all of the Lync Server 2010 Edge Servers online.

2. Update the external firewall routing rules or the hardware load balancer settings to send

SIP traffic for external access (usually port 443) and federation (usually port 5061) to the

Lync Server 2010 Edge Server, instead of the legacy Edge Server.

3. Next, stop the Office Communications Server Access Edge from each Edge Server

computer.

4. From each legacy Edge Server computer, open the Services applet from the

Administrative Tools.

5. In the services list, find Office Communications Server Access Edge.

6. Right-click the services name, and then select Stop to stop the service.

7. Set the Startup type to Disabled.

8. In the services list, find Office Communications Server Access Edge.

9. Right-click the services name, and then click Properties.

10. From the drop-down list, select Disabled.

11. Click OK to close the Properties window.

Verify Federation and Remote Access for External Users

After transitioning the federation route to the Lync Server 2010 Edge Server and Director, you

should perform some functional tests to verify that federation performs as expected. Tests for

external user access should include each type of external user that your organization supports,

including any or all of the following.

102


Test Connectivity of External Users and External access

Users from at least one federated domain, an internal user on Lync Server 2010, and a

user on Office Communications Server 2007 R2. Test instant messaging (IM), presence,

audio/video (A/V), and desktop sharing.

Users of each public IM service provider that your organization supports (and for which

provisioning has been completed) communicating with a user on Lync Server 2010 and a

user on Office Communications Server 2007 R2.

Verify anonymous users are able to join conferences.

A user hosted on Office Communications Server 2007 R2 using remote user access

(logging into Office Communications Server 2007 R2 from outside the intranet but without

VPN) with a user on Lync Server 2010, and a user on Office Communications Server

2007 R2. Test IM, presence, A/V, and desktop sharing.

A user hosted on Lync Server 2010 using remote user access (logging into Lync Server

2010 from outside the intranet but without VPN) with a user on Lync Server 2010, and a

user on Office Communications Server 2007 R2. Test IM, presence, A/V, and desktop

sharing.

Move Remaining Users to Lync Server 2010 (Office Communications Server 2007 R2 Migration)

You can move users to the new Microsoft Lync Server 2010 deployment by using either Lync

Server Control Panel or Lync Server Management Shell. You must meet some requirements to

ensure a smooth transition to Lync Server 2010. For details about prerequisites to completing the

procedures in this topic, see Configure Clients for Migration.

Important:




Important:






Important:

This includes the active meetings created by the legacy user. For example, if a legacy

user has configured a my meeting conference, that conference will still be available in

the new Lync Server 2010 pool, after the user has been moved. The details to access

103


that meeting will still be the same conference URL and conference ID. The only

difference is that the conference is now hosted in the Lync Server 2010 pool, and not in

Office Communications Server 2007 R2 pool.

Note:




Post Migration Task

After you move users, verify the conferencing policy that is assigned to them. To ensure that

meetings organized by users homed on Lync Server 2010 work seamlessly with federated users

who are homed on Office Communications Server 2007 R2, the conferencing policy assigned to

the migrated users should allow anonymous participants. Conferencing policies that allow

anonymous participants have Allow participants to invite anonymous users selected in Lync

Server 2010 Control Panel and have AllowAnonymousParticipantsInMeetings set to True in

the output from the Get-CsConferencingPolicy cmdlet in the Lync Server Management Shell.

For details about configuring conferencing policy by using Lync Server Management Shell, see

Set-CsConferencingPolicy in the Lync Server Management Shell documentation.

Example of Users Before Migration

The following figure shows users enabled for Office Communications Server 2007 R2 in the

Office Communications Server 2007 R2 administrative tools. These users will be moved to Lync

Server 2010 using the Lync Server Control Panel or Lync Server Management Shell.

The following figure provides a view of these same users in Lync Server Control Panel. The

Registrar pool column entry for each user is set to Legacy, which indicates that these users are

still homed on Office Communications Server 2007 R2 and have not been moved to Lync Server

2010.

104


To move users by using the Lync Server 2010 Control Panel


RTCUniversalUserAdmins group or a member of the CsUserAdministrators





3. Click Users, click Add Filter, build the following query Legacy user Equal to True, and

then click Find.

4. In the search results, select a user. Here, we’ve selected Chen Yang.

105


Note:

Notice that the Registrar pool column shows <Legacy>. This means that the

user you have selected is homed on Office Communications Server 2007 R2.

5. Click Action and then click Move selected users to pool.

Important:


of the CSAdministrator or CSUserAdministrator group.

6. In Move Users, select the Destination registrar pool, which is your Lync Server 2010




To move users by using the Lync Server Management Shell


RTCUniversalUserAdmins group or a member of the CsUserAdministrators




106



Move-CsLegacyUser –Identity “user name” –Target “pool_name”

For example:

Move-CsLegacyUser –Identity “Kate Jordan” –Target “lync-

se.contoso.net”



The RegistrarPool identity in the following figure now points to the pool you specified as

“pool_name” in the previous step. The presence of this identity confirms that the user has

been successfully moved.

Important


Move-CsLegacyUser : SetMoveResourceData failed because the user is not provisioned. At line:1 char:18 + Move-CsLegacyUser <<<< -Identity "[email protected]” -Target "lync-se.contoso.net" + CategoryInfo : InvalidOperation: (CN=Jeff Ander...contoso,DC=net:OCSADUser) [Move-CsLegacyUser],

107


MoveUserException + FullyQualifiedErrorId : MoveLegacyUserError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsLegacyUserCmdlet


resolution.

For details about other errors that may occur when you move users and how to resolve

them, see http://go.microsoft.com/fwlink/?linked=3052&kbid=2441886.

Move Multiple Users

You can move groups of users to the new Microsoft Lync Server 2010 deployment using the

following two methods: Lync Server Control Panel and Lync Server Management Shell. There are

requirements that must be met to ensure a smooth transition to Lync Server 2010. For details

before completing the procedures in this topic, see Configure Clients for Migration.

Important:




Important:






Important:



available in the new Lync Server 2010 pool, after the user has been moved. The details

to access that meeting will still be the same conference URL and conference ID. The

only difference is that the conference is now hosted in the Lync Server 2010 pool, and not

in Office Communications Server 2007 R2 pool.

Note:




To move multiple users by using the Lync Server Control Panel


108

http://go.microsoft.com/fwlink/?linked=3052&kbid=2441886







3. Click Users, click Add Filter, build the query Legacy user Equal to True, and then click

Find.

4. In the search results, select at least two users.

5. Click Action ,and then click Move selected users to pool.

Important:


of the RTCUniversalUserAdmins group or a member of the CsAdministrator or


6. In Move Users, select the Destination Registrar pool, which is your Lync Server 2010




For details about the cmdlets described in this section, run:


To move multiple users by using the Lync Server Management Shell






109


3. At the command line, type the following and replace User1 and User2 with specific user

names you want to move and replace pool_FQDN with the name of the destination pool:

Get-CsUser –Filter {DisplayName –eq “User1” –or DisplayName – eq

“User2”} | Move-CsLegacyUser –Target “pool_FQDN”

4. At the command line, type the following

Get-CsUser “User1”

The Registrar Pool identity should now point to the pool you specified as “pool_FQDN”

in the previous step. The presence of this identity confirms that the user has been

successfully moved.

To move all users at the same time by using the Lync Server Management Shell







Get-CsUser –OnOfficeCommunicationServer | Move-CsLegacyUser –

Target “pool_FQDN”



where user name is the name of a legacy user.

The Registrar Pool identity now points to the pool you specified as “pool_FQDN” in the


moved.

Important


Move-CsLegacyUser : SetMoveResourceData failed because the user is not provisioned. At line:1 char:18 + Move-CsLegacyUser <<<< -Identity "[email protected]” -Target "lync-se.contoso.net" + CategoryInfo : InvalidOperation: (CN=Jeff

110


Ander...contoso,DC=net:OCSADUser) [Move-CsLegacyUser], MoveUserException + FullyQualifiedErrorId : MoveLegacyUserError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsLegacyUserCmdlet


resolution.


You can migrate response group settings (agent groups, queues, and workflows) that you created

on Microsoft Office Communications Server 2007 R2 to Microsoft Lync Server 2010. When you

migrate Response Group settings, all the configuration settings, audio files, and contact objects

are moved from the Office Communications Server 2007 R2 pool to the Lync Server 2010 pool,

and all calls to migrated response group phone numbers are handled by Lync Server 2010. Calls

to migrated response groups will no longer be handled by Communications Server 2007 R2.

To migrate Response Group settings from Office Communications Server 2007 R2 to Lync Server

2010, you need to run a migration cmdlet and then update the URL that users need to sign into

and out of their response groups. If the Back End server in your Microsoft Office Communications

Server 2007 R2 environment runs on SQL Server 2005, you first need to install the SQL Server

2005 Native Client on the Lync Server 2010 computer where you plan to run the Response Group

migration cmdlet.

Note:

The Response Group migration cmdlet requires that the Response Group application is

installed in your Lync Server 2010 pilot pool. You can ensure that Response Group is

installed by running the Get-CsService –ApplicationServer command.

Important:

The Response Group migration cmdlet moves settings for the entire pool. You cannot

select specific groups, queues, or workflows to migrate.

Note:

The following procedure for migrating Response Group settings assumes that you have a

one-to-one relationship between Office Communications Server 2007 R2 and Lync

Server 2010 pools. If you plan to consolidate or split up pools during your migration and

deployment, you need to plan which Office Communications Server 2007 R2 pool maps

to which Lync Server 2010 pool.

Note:

After you run the Response Group migration cmdlet, the settings are still present, but

unused, in your Office Communications Server 2007 R2 pool to allow for a potential

rollback.

After you migrate Response Group, use Lync Server Control Panel or Lync Server Management

Shell cmdlets to verify that all agent groups, queues, and workflows moved successfully.

111


To migrate Response Group settings

1. If the Back End Server in your Office Communications Server 2007 R2 pool runs on SQL

Server 2005, download the Feature Pack for Microsoft SQL Server 2005 - December

2008 (SQLNCLI.MSI package) from the Microsoft Download Center at

http://go.microsoft.com/fwlink/?LinkId=204105, and then install it on the computer where

you plan to run the Response Group migration cmdlet.


RTCUniversalServerAdmins group or has equivalent administrator rights and

permissions.



4. Run:

Move-CsRgsConfiguration –Source <source pool FQDN> -Destination

<destination pool FQDN>

For example:

Move-CsRgsConfiguration –Source se-r2.contoso.net –Destination

lync-se.contoso.net

5. If you deployed the Response Group tab for Microsoft Office Communicator 2007 R2 in

your Office Communications Server 2007 R2 environment, remove the tab from the

Office Communicator 2007 R2 tabs.xml file.

Note:

Formal agents used the Response Group tab to sign in to their response groups

before they could receive calls. If you deployed the Response Group tab, you

chose the location for the Office Communicator 2007 R2 tabs.xml file when you

deployed it.

6. Provide users with the updated URL that agents need to sign into and out of their

response groups.

Note:

The URL is typically https://webpoolFQDN/RgsClients/Tab.aspx, where

webpoolFQDN is the fully qualified domain name (FQDN) of the web pool that is

associated with the pool that you just migrated to Lync Server 2010.

Note:

This step is not required after users upgrade to Microsoft Lync 2010 because the

URL is available from the Tools menu in Lync 2010.

To verify Response Group migration by using Lync Server Control Panel

1. Log on to the computer with an account that is a member of

RTCUniversalReadOnlyAdmins group or is minimally a member of the

CsViewOnlyAdministrator role.

112






3. In the left navigation pane, click Response Groups.

4. On the Workflow tab, verify that all the workflows in your Office Communications Server

2007 R2 environment are included in the list.

5. Click the Queue tab, and verify that all the queues in your Office Communications Server

2007 R2 environment are included in the list.

6. Click the Group tab, and verify that all the agent groups in your Office Communications

Server 2007 R2 environment are included in the list.

To verify Response Group migration by using cmdlets

1. Log on to the computer with an account that is a member of

RTCUniversalReadOnlyAdmins group or is minimally a member of the

CsViewOnlyAdministrator role.



For details about the following cmdlets, run:


3. Run:

Get-CsRgsAgentGroup

4. Verify that all the agent groups in your Office Communications Server 2007 R2


5. Run:

Get-CsRgsQueue

6. Verify that all the queues in your Office Communications Server 2007 R2 environment

are included in the list.

7. Run:

Get-CsRgsWorkflow

8. Verify that all the workflows in your Office Communications Server 2007 R2 environment

are included in the list.

Run Functional Tests for Response Groups

After you migrate your agent groups, queues, and workflows, run some functional tests to verify

that your response groups function as expected. This section describes some example scenarios.

Users:

User who is homed on Office Communications Server 2007 R2

113


User who is homed on Lync Server 2010

External user

An agent who is homed on Office Communications Server 2007 R2

An agent who is homed on Lync Server 2010

Scenarios:

A Office Communications Server 2007 R2 user calls the response group on Lync Server

2010.

A Lync Server 2010 user calls the response group.

An external user calls the response group.

A user calls the response group while the agent is on another call and goes to the queue.

Move Exchange Unified Messaging Contact Objects

To migrate Auto Attendant (AA) and Subscriber Access (SA) contact objects to the new Microsoft

Lync Server 2010 deployment, you first move the objects from the legacy Office Communications

Server 2007 R2 deployment to the new the Lync Server deployment using the Get-

CsExUmContact and Move-CsExUmContact cmdlets. On the Exchange Server, you then run

the ExchUCUtil Windows PowerShell script to do the following on the newly deployed Lync pool:

Add it to the Unified Messaging IP gateways

Add it to the Unified Messaging hunt groups.

Note:

In order to use the Get-CsExUmContact and Move-CsExUmContact cmdlets, you must

be a member of the RTCUniversalUserAdmins group and have organizational unit (OU)

permission to the OU where the contacts objects are stored. OU permission can be

granted using the Grant-OUPermission cmdlet.

To move contact objects by using the Lync Server Management Shell


RTCUniversalUserAdmins group or a member of the CsUserAdministrator administrative

role.



3. For each pool registered with Exchange UM (where pool1.contoso.net is a pool from the

Office Communications Server 2007 R2 deployment and pool2.contoso.net is the pool

from the Lync Server deployment) at the command line, type the following:

Get-CsExUmContact -Filter {RegistrarPool –eq "pool1.contoso.net"} | Move-

CsExUmContact -Target pool2.contoso.net

To verify that the contact objects are moved, run the Get-CsExumContact cmdlet and

confirm that RegisrtarPool is now pointing to the new pool.

114


To run the ExchUCUtil Windows PowerShell script

1. Log on to the Exchange UM Server as a user with Exchange Organization Administrator

privileges.

2. Navigate to the ExchUCUtil Windows PowerShell script.

In Exchange 2007, ExchUCUtil.ps1 is located at: %Program Files%\Microsoft\

Exchange Server\Scripts\ExchUCUtil.ps1

In Exchange 2010, ExchUCUtil.ps1 is located at: %Program Files%\Microsoft\

Exchange Server\V14\Scripts\ExchUCUtil.ps1

3. If Exchange is deployed in a single forest, type:

exchucutil.ps1

Or, if Exchange is deployed in multiple forests, type:

exchucutil.ps1 -Forest:" <forest FQDN>"

where forest FQDN specifies the forest in which Lync Server is deployed.

Important:

Be sure to restart the Lync Server Front-End service (rtcsrv.exe) after you run

exchucutil.ps1. Otherwise, Lync Server will not detect Unified Messaging in the

topology.

Verify that all Exchange UM Contact Objects are Removed from the Legacy Pool

Use either the OCSUmUtil tool or the Get-CsExumContact cmdlet to verify that Exchange UM

contact objects have been removed from the legacy Office Communications Server 2007 R2

pool. OCSUmUtil is located in the following folder:

%Program Files%\Common Files\Lync Server 2010\Support\OcsUMUtil.exe

OCSUmUtil must be run from a user account that has:

Membership in the RTCUniversalServerAdmins and RTCUniversalUserAdmins group (which

includes rights to read Exchange Server Unified Messaging settings)

Domain rights to create contact objects in the specified organizational unit (OU) container

For details about using the Get-CsExumContact cmdlet, see Get-CsExUmContact in the Lync

Server Management Shell documentation.

Phase 9: Complete Post-Migration TasksThe topics in this section describe tasks that you will need to perform after you have completed

your migration to Microsoft Lync Server 2010.

115


In This Section

Migrate Dial-in Access Numbers

Enable Exchange 2010 SP1 Outlook Web App and IM Integration



Remove Legacy Archiving and Monitoring Servers


Migrate Applications Built on Microsoft Unified Communications Managed API (UCMA) 2.0

Core SDK

Configure Trusted application servers

Configure the Meeting Join Page

Deploy Lync Server 2010 Clients

Migrate Dial-in Access Numbers

Migrating dial-in access numbers requires two steps: running the Import-

CsLegacyConfiguration cmdlet (completed earlier in Import Policies and Settings) to migrate

dial plans and other dial-in access number settings, and running the Move-

CsApplicationEndpoint cmdlet to migrate the contact objects. After you run the Import-

CsLegacyConfiguration cmdlet, the migrated dial-in access numbers exist both in your

Microsoft Office Communications Server 2007 R2 pool and in your Microsoft Lync Server 2010

pool. During this coexistence period, dial-in access numbers that you created in Office

Communications Server 2007 R2 behave differently from dial-in access numbers that you create

in Lync Server 2010, as described in this section.

After you run Import-CsLegacyConfiguration but before you run Move-

CsApplicationEndpoint

Dial-in access numbers that you created in Office Communications Server 2007 R2 have the

following characteristics:

Appear on Office Communications Server 2007 R2 meeting invitations and the dial-in access

number page.

Appear on Lync Server 2010 meeting invitations and the dial-in access number page.

Can be viewed and modified in the Office Communications Server 2007 R2 administrative

tool.

Important:

If you make changes to dial-in access numbers in your Office Communications

Server 2007 R2 pool, you will need to rerun the Import-CsLegacyConfiguration

cmdlet with the ReplaceExisting parameter to apply the same changes to your Lync

Server 2010 pool. Re-importing with the ReplaceExisting parameter can overlay

other changes you made in your Lync Server 2010 pool.

116


Cannot be viewed in Lync Server Control Panel, but can be viewed in Lync Server

Management Shell (if you use the Get-CsDialinConferencingAccessNumber cmdlet with

the Region parameter).

Cannot be modified in Lync Server Control Panel or in Lync Server Management Shell.

Cannot be re-sequenced within the region by using the Set-

CsDialInConferencingAccessNumber cmdlet with the –Priority parameter.

After you run Move-CsApplicationEndpoint

Dial-in access numbers that you created in Office Communications Server 2007 R2 but moved to

Lync Server 2010 have the following characteristics:

Appear on Office Communications Server 2007 R2 meeting invitations and the dial-in access

number page.


Can be viewed in the Office Communications Server 2007 R2 administrative tool.

Cannot be modified in the Office Communications Server 2007 R2 administrative tool.

Can be viewed and modified in Lync Server Control Panel and in Lync Server Management

Shell.

Can be re-sequenced within the region by using the Set-

CsDialinConferencingAccessNumber cmdlet with the Priority parameter.

Dial-in access numbers that you create in Lync Server 2010

Dial-in access numbers that you create in Lync Server 2010 before, during, or after migration

have the following characteristics:

Do not appear on Office Communications Server 2007 R2 meeting invitations and the dial-in

access number page.


Cannot be viewed or modified in the Office Communications Server 2007 R2 administrative

tool.

Can be viewed and modified in Lync Server Control Panel and in Lync Server Management

Shell.

Can be re-sequenced within the region by using the Set-

CsDialinConferencingAccessNumber cmdlet with the Priority parameter.

You must finish migrating dial-in access numbers that point to an Office Communications Server

2007 R2 pool before you decommission the Office Communications Server 2007 R2 pool. If you

do not complete dial-in access number migration as described in the following procedure,

incoming calls to the access numbers will fail.

Important:

You must perform this procedure prior to decommissioning the Office Communications

Server 2007 R2 pool.

117


Note:

We recommend that you move dial-in access numbers when network usage is low, in

case there is a short period of service outage.

To identify and move dial-in access numbers


RTCUniversalServerAdmins group and open the Office Communications Server 2007 R2

administrative tool.

2. In the console tree, right-click the forest node, click Properties, and then click

Conferencing Attendant Properties.

3. On the Access Phone Numbers tab, click Serviced by Pool to sort the access phone

numbers by their associated pool, and identify all the access numbers for the pool from

which you are migrating.

4. To identify the SIP URI for each access number, double-click the access number to open

the Edit Conferencing Attendant Number dialog box, and look under SIP URI.



6. To move each dial-in access number to a pool hosted on Lync Server 2010, run:

Move-CsApplicationEndpoint -Identity <SIP URI of the access number

to be moved> -Target <FQDN of the pool to which the access number

is moving>

7. In the Office Communications Server 2007 R2 Administrative tool, on the Access Phone

Numbers tab, verify that no dial-in access numbers remain for the Communications

Server 2007 R2 pool from which you are migrating.

Note:

When no more dial-in access numbers point to the Office Communications

Server 2007 R2 pool, you can decommission the Office Communications Server

2007 R2 pool.

Enable Exchange 2010 SP1 Outlook Web App and IM Integration

To enable Exchange 2010 SP1 Outlook Web Access (OWA) and instant messaging (IM)

integration with Microsoft Lync Server 2010, you must add the Exchange 2010 SP1 Client Access

Server (CAS) server to the Lync Server 2010 topology as a trusted application server.

Important

There are additional configuration requirements that depend on how your Exchange 2010 SP1

server roles are configured:

If your CAS server is not collocated on the same server that is running Exchange 2010 SP1

Unified Messaging (UM), in addition to creating a trusted application pool you must create a

118


trusted application, which can only be done by using Lync Server Management Shell. The trusted

application must be assigned a port number on which the application will run. The port must be

unique within the trusted application pool. In other words, no other applications that use this port

can be defined in the specified pool. This port will not be used, but it must be assigned as

described in the “Create a trusted application for the Exchange 2010 SP1 CAS server” procedure

later in this topic.

If your CAS server is collocated on the same server that is running Exchange 2010 SP1 UM, and

the UM server is servicing a SIP dial plan that is integrated with Lync Server 2010, you only need

to create a trusted application pool. It is not necessary to create a trusted application.

To create a trusted application pool


RTCUniversalServerAdmins group or has the equivalent administrator rights and

permissions.



3. Run the following cmdlet:

Get-CsSite

This returns the siteID for the siteName in which you are creating the pool. For details,

see Get-CsSite in the Lync Server Management Shell documentation.


New-CsTrustedApplicationPool -Identity <E14 CAS FQDN> –

ThrottleAsServer $true –TreatAsAuthenticated $true –ComputerFQDN

<E14 CAS FQDN> -Site <Site> -Registrar <Pool FQDN in the site> -

RequiresReplication $false

For details, see New-CsTrustedApplicationPool in the Lync Server Management Shell

documentation.

Important:

If your CAS server is not collocated on the same server that is running Exchange

2010 SP1 Unified Messaging (UM), skip the remaining steps in this procedure

and perform the “Create a trusted application for the Exchange 2010 SP1 CAS

server” procedure later in this topic. If your CAS server is collocated on the same

server that is running Exchange 2010 SP1 Unified Messaging (UM), complete

the steps in this procedure and do not perform the “Create a trusted application

for the Exchange 2010 SP1 CAS server” procedure later in this topic.

5. Run Enable-CsTopology.



7. Select the option to Download Topology from existing deployment.


119


and click Save.

9. In the left pane, expand the tree until you reach Trusted application servers.

10. Expand the Trusted application servers node.

11. You should now see the Exchange 2010 SP1 CAS server listed as a trusted application

server.

Create a trusted application for the Exchange 2010 SP1 CAS server



permissions.



3. If your CAS server is not collocated on the same server that is running Exchange 2010

SP1 Unified Messaging (UM), run the following cmdlet:

New-CsTrustedApplication -ApplicationId <AppID String> -

TrustedApplicationPoolFqdn <E14 CAS FQDN> -Port <available port

number>

For details, see the topic New-CsTrustedApplication in the Lync Server Management

Shell documentation.

4. Run Enable-CsTopology.



6. Select the option to Download Topology from existing deployment.


and click Save.

8. In the left pane, expand the tree until you reach Trusted application servers.

9. Expand the Trusted application servers node.

10. You should now see the Exchange 2010 SP1 CAS server listed as a trusted application

server.


In general, Address Book is migrated along with the rest of your topology. However, you might

need to perform some post-migration steps if you customized the following in your Microsoft

Office Communications Server 2007 R2 environment:

Set the PartitionbyOU WMI property to group Address Book entries by organizational unit

(OU).

Customized the Address Book normalization rules.

Grouped Address Book Entries

120


If you set the PartitionbyOU WMI property to True to create address books for each OU, you

need to set the msRTCSIP-GroupingId Active Directory attribute on users and contacts if you

want to continue grouping address book entries. You might want to group address book entries to

limit the scope of Address Book searches. To use the msRTCSIP-GroupingId attribute, write a

script to populate the attribute, assigning the same value for all of the users that you want to

group together. For example, assign a single value for all the users in an OU.

Address Book Normalization Rules

If you customized Address Book normalization rules in your Office Communications Server 2007

R2 environment, you must migrate the customized rules to your pilot pool. If you did not

customize Address Book normalization rules, you have nothing to migrate for Address Book

service. The default normalization rules for Lync Server 2010 are the same as the default rules for

Office Communications Server 2007 R2.

Note:

If your organization uses remote call control and you customized Address Book

normalization rules, you must perform the procedure in this topic before you can use

remote call control. The procedure requires membership in the

RTCUniversalServerAdmins group or equivalent rights.

To migrate Address Book customized normalization rules

1. Find the Company_Phone_Number_Normalization_Rules.txt file in the root of the

Address Book shared folder, and copy it to the root of the Address Book shared folder in

your Lync Server 2010 pilot pool.

2. Use a text editor, such as Notepad, to open the

Company_Phone_Number_Normalization_Rules.txt file.

3. Certain types of entries will not work correctly in Lync Server 2010. Look through the file

for the types of entries described in this step, edit them as necessary, and save the

changes to the Address Book shared folder in your pilot pool.

Strings that include required whitespace or punctuation cause normalization rules to fail

because these characters are stripped out of the string that is input to the normalization

rules. If you have strings that include required whitespace or punctuation, you need to

modify the strings. For example, the following string would cause the normalization rule to

fail:

\s*$\s*\d\d\d\s*$\s*\-\s*\d\d\d\s*\-\s*\d\d\d\d

The following string would not cause the normalization rule to fail:

\s*$?\s*\d\d\d\s*$?\s*\-?\s*\d\d\d\s*\-?\s*\d\d\d\d

121



Remote call control enables users to control their desktop private branch exchange (PBX) phones

by using Microsoft Lync 2010. If you deployed remote call control in your legacy environment and

want to migrate it Microsoft Lync Server 2010, you need to perform the following tasks:

1. Install a SIP/CSTA gateway and configure it to communicate with your PBX. You need to do

this step when you deploy your Lync Server 2010 pilot pool. For details about SIP/CSTA

gateways, see Deployment Tasks for Remote Call Control in the Planning documentation.

Note:

This step is a prerequisite to migration.

2. After you merge your topology and migrate your policies and settings, configure Lync Server

2010 to route CSTA requests to the SIP/CSTA gateway. This step is a manual step that

follows the automated migration. To configure routing for CSTA requests, do the following:

Remove legacy authorized host entries (known as trusted server entries in Lync Server

2010). If you are migrating users from your legacy deployment, ensure that you remove

all existing authorized host entries that you created for the SIP/CSTA gateway before you

configure new trusted application entries on the Lync Server 2010 pilot pool. For details

about how to remove legacy authorized host entries, see Remove an Authorized Host

Entry in this section.

Configure a static route for remote call control. You can configure a static route for

individual pools that you want to support remote call control, or you can configure a

global static route so that each pool that is not configured with a pool-level static route

uses the global static route. For details about how to configure the static route, see

Configure a Static Route for Remote Call Control in the Deployment documentation.

Configure a trusted application entry for remote call control on each pool for which you

want to support remote call control. For details about how to configure a trusted

application entry, see Configure a Trusted Application Entry for Remote Call Control in

the Deployment documentation.

3. If you deployed a SIP/CSTA gateway that uses Transmission Control Protocol (TCP) to

connect to Lync Server, define the IP address of the gateway in Topology Builder. For details

about defining the IP address, see Define a SIP/CSTA Gateway IP Address in the


4. Configure Lync 2010 users for remote call control by enabling remote call control and

assigning a line server Uniform Resource Identifier (URI) and a line URI. When you migrate

users from your legacy deployment to Lync Server, the remote call control settings are

migrated along with the other user settings.

For details about migrating users, see Move Multiple Users. For details about configuring

users for remote call control, see Enable Lync Users for Remote Call Control in the


5. If you customized Address Book phone number normalization rules in your legacy

deployment, you need to perform some manual tasks after the automated migration of

policies and settings is complete to migrate the customized normalization rules. If you did not

122


customize normalization rules, Address Book is migrated along with the rest of your topology.

For details about manually migrating customized normalization rules, see Migrate Address

Book.

Remove an Authorized Host Entry

This topic describes how to remove a legacy authorized host entry (known as a trusted

application entry in Lync Server 2010). You must remove existing authorized host entries for any

SIP/CSTA gateways in your Office Communications Server 2007 R2 deployment when you

migrate remote call control to a Lync Server 2010 deployment. You must use the administrative

tools included with Office Communications Server 2007 R2 to remove the existing authorized

host entries.

To remove an authorized host entry in an Office Communications Server 2007 R2 deployment



2. Open the Office Communications Server 2007 R2 administrative console.

3. Expand the tree and right-click the pool where the authorized host was created.

4. Click Properties, and then click Front End Properties.

5. Click the Host Authorization tab.

6. Select a server, and then click Remove.

7. In Properties, click OK.

Remove Legacy Archiving and Monitoring Servers

If your Office Communications Server 2007 R2 deployment contained an Archiving Server or a

Monitoring Server, after migrating to Lync Server 2010, those servers can be removed from the

legacy environment provided all users have been removed from any remaining Office

Communications Server 2007 R2 pools. You can remove the Archiving Server or Monitoring

Server in any sequence. The key requirement is that all users have been removed from any

remaining Office Communications Server 2007 R2 pools.

You can move users from Office Communications Server 2007 R2 to Lync Server 2010 by

following the procedures outlined in the following topics:


Migration)

Move Multiple Users

After you have confirmed that all users have been removed from any remaining pools, follow the

procedure in "Removing Servers and Server Roles" at http://go.microsoft.com/fwlink/?

LinkId=205887.

123





Your Mediation Server is merged into your Lync Server 2010 pilot topology when you run the

Merge wizard. You configure the Lync Server 2010 Mediation Server, however, after all users are

migrated because an Office Communications Server 2007 R2 pool cannot communicate with a

Lync Server 2010 Mediation Server.

During the side-by-side migration, the Lync Server 2010 pool communicates with the Office

Communications Server 2007 R2 Mediation Server, as illustrated in the following figure.

124


Traffic flow during migraton coexistence phase

Users homed on the Office Communications Server 2007 R2 pool use the Office Communications

Server 2007 R2 Mediation Server and PSTN gateway for outbound calls.

You can switch off the Office Communications Server 2007 R2 routes and Mediation Servers

when all users are migrated and there are no more outbound calls from users homed on the

Office Communications Server 2007 R2 pool.

125


When you configure your Lync Server 2010 Mediation Server, you must also upgrade or replace

your Office Communications Server 2007 R2 gateways. Office Communications Server 2007 R2

gateways do not support Lync Server 2010 Mediation Server. You need to deploy gateways that

are certified for Lync Server 2010 and associate them with the Lync Server 2010 Mediation

Server. For details about deploying gateways, see Define a Peer of the Mediation Server for a

Site in the Deployment documentation. This step is required before you can completely

decommission your Office Communications Server 2007 R2 deployment.

The topics in this section describe configuration tasks that you need to perform after you have

completed your migration of Lync Server 2010 Mediation Server. Transitioning the

collocated Mediation Server to a stand-alone Mediation Server is an optional task.

Configure Mediation Server

Change Voice Routes to use the new Lync Server 2010 Mediation Server


Configure Mediation Server

This procedure details the steps to configure the Lync Server 2010 pool to use the Lync Server

2010 Mediation Server, instead of the legacy Office Communications Server 2007 R2 Mediation

Server.





or Enterprise Edition server Deployment documentation. For other configuration changes, only


Note:

For the latest information on finding qualified PSTN gateways, IP-PBXs, and SIP trunking

services that work with Lync Server 2010, see "Microsoft Unified Communications Open

Interoperability Program" at http://go.microsoft.com/fwlink/?LinkId=206015.

To configure Mediation Server by using Topology Builder



permissions.






5. In the left pane, navigate to PSTN gateways.

6. Right-click PSTN gateways, and then click New IP/PSTN Gateway.

7. Complete the Define New IP/PSTN Gateway page with the following information:

126



Enter the gateway FQDN or IP address. The FQDN of the gateway is required if the

gateway uses the TLS protocol.

Accept the default value of the Listening port for IP/PSTN gateway or enter the

new listening port if it was modified.

Set the Sip Transport Protocol.

8. In the left pane, navigate to the Enterprise Edition Front End pool or the Standard

Edition Server.

9. Right-click the pool, and then click Edit Properties.

10. Under Mediation Server, set the Listening ports.

11. Next, associate the newly created PSTN gateway by selecting it and clicking Add.

12. Associate the PSTN gateway to the Lync Server 2010 Mediation Server by selecting it

and clicking Make Default.

13. In Topology Builder, select the top-most node Lync Server 2010.

14. From the Actions pane, select Publish Topology and then click Next.


Note:

It is important that you complete the next topic, Change Voice Routes to use the new

Lync Server 2010 Mediation Server to ensure that the voice routes are pointing to the

correct Mediation Server.

Change Voice Routes to use the new Lync Server 2010 Mediation Server

This procedure changes the voice routes to use the Lync Server 2010 Mediation Server, instead

of the legacy Office Communications Server 2007 R2 Mediation Server.







To change voice routes to use the new Mediation Server


RTCUniversalServerAdmins group or a minimally member of the CsVoiceAdministrator





3. In the left pane, select Voice Routing and then Route.

4. Click New to create a New Voice Route.

127


5. Fill in the following fields:

Name: Type a descriptive name of the voice route. For this document we will use

W14PSTNRoute.

Description: Type a short description of the voice route.

6. Skip all remaining sections until you reach Associated gateways. Click Add. Select the

new default gateway and click OK.

7. Under Associated PSTN Usages, click Select.

8. From the Select PSTN Usage Record page, select a record name and then click OK.

9. From the New Voice Route page, click OK to create the Voice Route.

10. From the Voice Routing page, select Route.

11. Move the newly created route to the top of the list and then select Commit.





Use the procedure that follows to transition your Mediation Server, collocated on your Standard

Edition server or Front End pool, to a stand-alone Mediation Server for a single-site deployment.







To transition a collocated Mediation Server to a stand-alone Mediation Server



permissions.





and click Save.

5. In the left pane, navigate to Mediation pools.

6. Right-click Mediation pools and select New Mediation Server.

7. On the Define New Mediation Pool page, provide the FQDN of the new Mediation

Server pool. Also, select whether this pool will be a single-server or multiple-server pool,

128


and then click Next.

8. Select the next hop pool to which the new Mediation Server will route inbound calls, and

then click Next.

9. Select the Edge pool to be used by the Mediation Server and then click Next.

10. On the Specify PSTN gateways page, associate the previous PSTN gateway with the

Mediation Server. Select the gateway and then click Add.

11. Click Finish to close the Define New Mediation Pool wizard.



14. Follow the steps in Install the Files for Mediation Server in the Deployment

documentation to install the files on the new Mediation Server.

15. After the files are installed on the Mediation Server, return to Topology Builder, and in the

left pane navigate to the pool.

16. Right-click the pool and select Edit Properties.

17. Under Mediation Server, clear the check box Collocated Mediation Server enabled

and then click OK.



Migrate Applications Built on Microsoft Unified Communications Managed API (UCMA) 2.0 Core SDK

Microsoft Lync Server 2010 works with Microsoft Unified Communications Managed API (UCMA)

3.0 Core SDK. If you have external applications built on UCMA 2.0 (which shipped with Office

Communications Server), you can run these applications in an environment that includes servers

running Lync Server 2010.

If you run a UCMA 2.0 application, homed on an Office Communications Server pool, you can

enable users homed on a Lync Server 2010 pool to call into the application.

The trusted server entries are merged from the legacy Office Communications Server deployment

to Lync Server 2010 when the Topology Builder Merge wizard is run. After the merge, the trusted

service entries exist on both the Office Communications Server pool and the Lync Server 2010

pool, and no further steps are needed for coexistence. Be sure to note that this copies only the

trusted service entries and route-related settings.

Configure Trusted application servers

In a mixed environment, if you create a new trusted application server after merging the legacy

Office Communications Server topology with Lync Server 2010, and you define a new trusted

application server using Topology Builder, you must set the next hop pool to be a Lync Server

2010 pool. In a merged environment, both the legacy Office Communications Server pool and the

Lync Server 2010 pool appear in the drop down list. Selecting the legacy pool is not supported.

129





adding server roles. For details, see Delegate Setup Permissions in the Lync Server 2010

Standard Edition server or Enterprise Edition server Deployment documentation. For other

configuration changes, only membership in the RTCUniversalServerAdmins group is required.

Select Lync Server 2010 as next hop when creating a Trusted application server



permissions.





and click Save.

5. In the right pane, right click Trusted application servers and click New Trusted

Application Pool.

6. Enter the Pool FQDN of the trusted application pool and select whether it will be a single-

server or multiple-server.

7. Click Next.

8. On the Select the next hop page, from the list, select the Lync Server 2010 Front End

pool. lync-se.contoso.net in our example.

130


9. Click Finish.

10. Select the top node Lync Server 2010 and from the Actions pane, select Publish.

The Trusted Application Pool should have been created successfully and is associated

with the correct Front End pool.

Configure the Meeting Join Page

You can control the Microsoft Lync Server 2010 clients that are available for joining scheduled

Lync Server 2010 meetings by configuring the meeting join page. When a user clicks a meeting

link in a meeting request, the meeting join page detects whether a Lync Server client is already

installed on the user’s computer. If a client is already installed, the default client opens and joins

the meeting. If a client is not installed, the meeting join page displays options for joining the

meeting with alternate clients.

The meeting join page always contains the option to use Microsoft Lync Web App. In addition to

this option, you can decide whether to show links for downloading Microsoft Lync 2010 Attendee

or using a previous version of Microsoft Office Communicator (Microsoft Office Communicator

2007 R2 or Microsoft Office Communicator 2007).

The meeting join scenarios are as follows:

131


If Microsoft Lync 2010 or Microsoft Lync 2010 Attendant is installed, the client starts and joins

the meeting.

If neither Lync 2010 nor Lync 2010 Attendant is installed and Lync 2010 Attendee is installed,

Lync 2010 Attendee starts and joins the meeting.

If no Lync Server client is installed, the meeting join page opens and gives the user the

following options:

Use Lync Web App.

Download Lync 2010 Attendee. (This link is hidden by default.)

Use a previous version of Office Communicator. (This link is hidden by default.)

For the scenario in which no client is installed, you can configure the meeting join page by using

the Microsoft Lync Server 2010 Control Panel (the Web Service page in the Security group). You

can also configure the same settings by using the New-CsWebServiceConfiguration or Set-

CsWebServiceConfiguration Lync Server Management Shell cmdlets with the

ShowDownloadCommunicatorAttendeeLink and ShowJoinUsingLegacyClientLink parameters.

To configure the meeting join page by using the Lync Server 2010 Control Panel




2. In the left navigation bar, click Security.

3. Click Web Service.

4. Select or clear the Show Lync Attendee download link check box, depending on

whether you want to give users the option to download and join meetings by using Lync

2010 Attendee.

5. Select or clear the Show the link for user to join meeting using legacy client check

box, depending on whether you want users to be able to join meetings by using a

previous version of Communicator.

To configure the meeting join page by using Lync Server Management Shell




Get-CsWebServiceConfiguration

This cmdlet returns the web service configuration settings.

3. Run the following command, with the ShowDownloadCommunicatorAttendeeLink and

ShowJoinUsingLegacyClientLink parameters set to True or False, depending on your

preference (for details about the parameters for this cmdlet, see the Lync Server

Management Shell documentation):

Set-CsWebServiceConfiguration -Identity global -

ShowDownloadCommunicatorAttendeeLink $True -

132


ShowJoinUsingLegacyClientLink $True

Deploy Lync Server 2010 Clients

After you migrate users to Microsoft Lync Server 2010, do the following:

1. Use the Client Version Filter on the new Lync Server 2010 server to allow only clients with the

most current updates installed to sign in.

2. If necessary, configure the Group Policy settings that are required for client bootstrapping.

For details, see Key Client Policies and Settings in the Planning documentation.

Configuration of these settings is only necessary if you want to change existing client

bootstrapping policies or if you want to set new client bootstrapping policies. If you do not

plan to configure client bootstrapping policies, or you want legacy client bootstrapping policies

to remain in effect, no action is necessary.

3. Configure other user and client policies for specific users or groups of users by using Lync

Server Control Panel, Lync Server Management Shell, or both. For details, see Key Client

Policies and Settings and Migrating User Settings to Lync Server 2010 in the Planning

documentation.

4. Deploy the latest version of Lync Server 2010 clients along with the latest cumulative

updates. For details, see Deploying Clients and Devices in the Deployment documentation.

5. (Optional) If your organization requires Microsoft Lync 2010 enhanced presence privacy

mode, after migration is complete, define a Client Version Policy Rule to prevent earlier client

versions from signing in. Then, enable enhanced presence privacy mode.

Important:

Do not enable Lync 2010 enhanced presence privacy mode until every user on a

given server pool has the most current client versions installed.

6. (Optional) If you use remote call control, create a group policy to set the Enable integration

with your phone system option in the Phone integration section in Microsoft Lync 2010.

Phase 10: Decommission Legacy SiteThe following topics provide guidance in decommissioning pools, and deactivating and removing

servers and pools from a legacy deployment of Office Communications Server 2007 R2. Not all of

the procedures listed in this section are required. Read the information in each of these topics to

determine which decommissioning procedure to use.

Caution:

If you imported conference directories for dial-in conferencing to Lync Server 2010, it is

important to transition conference directory ownership to Lync Server 2010 before you

begin to decommission your pools. If you decommission a pool without first transitioning

conference directory ownership, the dial-in feature for all migrated meetings will no longer

work. You must perform the step to transition ownership once for each conference

directory in your legacy pool.

133


In This Section

Move Conference Directories

Decommissioning Servers and Pools


Move Conference Directories

If your Office Communications Server 2007 R2 deployment supports dial-in conferencing, you

must perform the procedure described in this section to move your conference directories to Lync

Server 2010 before beginning to decommission your legacy pools. If you decommission a pool

without first moving the conference directories to Lync Server 2010, the dial-in feature for all

migrated meetings will no longer work. The following procedure describes how to move a

conference directory from one pool to another pool.

Important:

If you decommission your legacy pools before you move the conference directories, you

must either restore the conference directories from a backup, or users must manually

reschedule their meetings to restore dial-in functionality. If you used Dbimpexp.exe to

export the legacy conference directories, you can create new conference directories on

Lync Server 2010 by using the same numeric identifiers that existed in your legacy pool,

and then use Dbimpexp.exe to import the data to Lync Server 2010. If you do not have a

backup created with Dbimpexp.exe, users must reschedule all of their dial-in meetings,

and you can use the Remove-CsConferenceDirectory cmdlet with the Force parameter

to clean up any leftover entries in Lync Server.

Before decommissioning a pool, you need to perform the following procedure for each conference

directory in your Office Communications Server 2007 R2 pool.

To move a conference directory to Lync Server 2010

1. Log on to the computer where Lync Server Management Shell is installed as a member

of the RTCUniversalServerAdmins group or with the necessary user rights as described

in Delegate Setup Permissions.



3. To obtain the identity of the conference directories in your organization, run the following:

Get-CsConferenceDirectory

Because this cmdlet returns all the conference directories in your organization, you may

want to limit the results to only the pool you want to decommission. For example, if you

want to decommission a pool with the fully qualified domain name (FQDN)

pool01.contoso.net:

Get-CsConferenceDirectory | Where-Object {$_.ServiceID -match

"pool01.contoso.net"}

134


This cmdlet returns all the conference directories where service ID contains the FQDN

pool01.contoso.net.

4. To move conference directories, run the following for each conference directory in the

pool:

Move-CsConferenceDirectory -Identity <Numeric identity of

conference directory> -TargetPool <FQDN of pool where ownership is

to be transitioned>

For example:

Move-CsConferenceDirectory -Identity 3 -TargetPool lync-

pool01.contoso.net

Decommissioning Servers and Pools

The following webpages contain details about decommissioning Communications Server 2007 R2

Standard Edition or Enterprise Edition servers and pools.

Decommissioning Standard Edition at http://go.microsoft.com/fwlink/?LinkId=205889

Removing Servers and Server Roles at http://go.microsoft.com/fwlink/?LinkId=205887

Removing an Enterprise Pool at http://go.microsoft.com/fwlink/?LinkId=205888

Important:

Lync Web App does not support instant messaging (IM) and presence. If you plan to

reinstall Office Communicator Web Access (2007 R2 release) to support IM and

presence, it is important that you do not run the Unprep step during decommissioning to

remove objects and attributes from Active Directory Domain Services (AD DS). Active

Directory schema for Office Communicator 2007 R2 is a prerequisite for deploying Office

Communicator Web Access (2007 R2 release).


After all pools are deactivated and all Edge Servers have been uninstalled, run the Topology

Builder Merge wizard to remove the BackCompatSite.







To remove BackCompat site from Topology Builder



135







and click Save.


5. Click Next to continue.

6. On the Specify Legacy Edge page, ensure that list of Edge Servers is empty. If the list

is not empty, use the Remove button to remove all the legacy Edge Servers, and then

click Next.

7. On the Specify Internal SIP port setting page, click Next.

8. On the Summary page, click Next to begin merging the topologies to remove the legacy

site.

Notes:

On the Invoke Merge page you may see the following warning:

Total number of warnings is 1

Check for errors, warnings, and details in the log file at the following location: “%temp%\

TopologyBuilder\[DATE-TIME]\MergeTopologyInvoke.log”

No Office Communications Server 2007 / Office Communications Server 2007 R2 Edge has

been enabled for federation

136


Succeeded

Finished

9. Ignore the warning above and then click Finish.

10. In the Status column, verify that the value is Success and then click Finish to close the

wizard.

11. In the left pane of Topology Builder, expand the BackCompatSite and ensure no servers

are listed.

12. Right-click the BackCompatSite, and then click Delete.




Phase 11: Migrate Communicator Web Access (2007 R2 Release) (Optional)Microsoft Lync Server 2010 has replaced Communicator Web Access with a new Microsoft

Silverlight-based client called Microsoft Lync Web App. Lync Web App does not support instant

messaging (IM) and presence. Depending on the requirements of your organization, you have the

following options for migrating browser-based functionality to Lync Server 2010:

IM and presence are not required for browser-based scenarios

In this scenario, only Lync Server 2010 is deployed. You do not need to perform any

additional migration steps.

IM and presence are required for browser-based scenarios

If browser-based IM and presence are required for your organization, you must also maintain

a deployed instance of the previous version of Communicator Web Access in your

environment. Because Communicator Web Access can point to a Lync Server pool, you do

not need to maintain a separate Office Communications Server pool.

During the coexistence phase of migration, the user experience varies depending on where the

user is homed and on whether the user uses Communicator Web Access or Lync Web App.

Note:

When Communicator Web Access is deployed, all users who sign in through

Communicator Web Access have support for IM and presence. It does not matter if they

are homed in the Office Communications Server pool or the Lync Server pool.

If you decide to use the previous version of Communicator Web Access to support browser-based

IM and presence in your Lync Server environment, you need to first decommission your Office

Communications Server pool, including Communicator Web Access, and then reinstall

Communicator Web Access. For details, see Redeploy Communicator Web Access (2007 R2

Release) for IM and Presence.

137


Deployment Scenarios

If a deployment contains a Communicator Web Access server, all users can access IM and

presence functionality regardless of the following conditions:

Whether users are homed in an Office Communications Server pool or Lync Server pool

Whether the Communicator Web Access server points to Office Communications Server or

Lync Server

The following table describes the behavior for the various deployment scenarios and end user

experience.

138


Scenario Behavior

All users are homed in the Lync Server pool

Communicator Web Access points to the

Lync Server pool

Note:

This scenario applies when your

migration to Lync Server is complete

and you deployed the legacy version of

Communicator Web Access to support

IM and presence.

All users have support for IM and presence

through Communicator Web Access and for

meetings through Lync Web App.

All users are homed in the Lync Server pool


Office Communications Server pool

Note:

This scenario applies after you migrate

all users to Lync Server but before you

decommission your legacy pools.

All users have support for IM and presence

through Communicator Web Access and for

meetings through Lync Web App.

Users are split between the Lync Server

and the Office Communications Server

pools


Office Communications Server pool.

Note:

This scenario applies during the

migration coexistence phase.

Lync Server homed users have browser-based

IM and presence through Communicator Web

Access and meeting access through Lync Web

App.

Office Communications Server homed users

have browser-based IM and presence, in

addition to meeting access, through

Communicator Web Access.

If a user has migrated and joins or creates a

new conference using Meet Now (Join

Launcher link), the user joins the meeting using

Lync Web App. If the conference has not yet

migrated, but the user has migrated, the user

joins the meeting through Communicator Web

Access.

If a user has not yet migrated, the new

conference is created on the Office

Communications Server 2007 R2 pool, and the

user uses Communicator Web Access to join

the conference. The user should also be able to

join a conference created on Lync Server 2010

by using the Lync Web App Join Launcher link.

139


Scenario Behavior

If using Communicator Web Access to join a

conference, a user has IM and presence

available. If using Lync Web App to join a

conference, a user does not have IM and

presence available.

In This Section

Redeploy Communicator Web Access (2007 R2 Release) for IM and Presence

Redeploy Communicator Web Access (2007 R2 Release) for IM and Presence

If your organization needs to support browser-based instant messaging (IM) and presence, you

need to do the following:

Decommission your legacy deployment, including Communicator Web Access, and then

redeploy Office Communicator Web Access (2007 R2 release).

Use Topology Builder to merge and publish your topology.

Test the deployment by starting Communicator Web Access, and then trying to use the

internal URL.

To decommission and redeploy Communicator Web Access

1. When you decommission your Office Communications Server 2007 R2 pools, also

decommission Communicator Web Access. For details, see "Removing Servers and

Server Roles" at http://go.microsoft.com/fwlink/?LinkId=205887.

Important:

During decommissioning, it is important that you do not run the Active Directory

Domain Services (AD DS) Unprep step to remove Office Communications

Server 2007 R2 schema. Active Directory schema for Office Communications

Server 2007 R2 is a prerequisite for deploying Office Communicator Web Access

(2007 R2 release).

2. Redeploy Office Communicator Web Access (2007 R2 release). In the Office

Communications Server 2007 R2 Create Virtual Server Wizard, on the Select a Pool and

Port page, select a Lync Server 2010 pool and the listening port of the pool to support

anonymous users. For details about deploying Office Communicator Web Access (2007

R2 release), see http://go.microsoft.com/fwlink/?LinkId=218967.

Note:

When a user participates in a conference, messages need to be passed between

the Communicator Web Access server and the user’s home server. The Lync

Server 2010 pool you specify when you create the virtual server acts as a home

140




server for anonymous users, who would otherwise not have a home server for

relaying the messages.

To merge and publish the topology



2. From the Standard Edition server or Front End Server, click Start, click All Programs,

click Microsoft Lync Server 2010, and then click Lync Server Topology Builder.


4. In Save Topology As, select the Topology Builder file you want to use, and then click

Save.


6. Click Next.

7. In Specify Edge Setup, click Next to bypass Edge setup.

8. In Specify Internal SIP port setting, select the default setting, and then click Next.


10. In Invoke Merge, click Next.

11. In Import Office Communications Server 2007 or 2007 R2 Topology, you can view

the logs. You will see a warning because you did not enable a legacy Edge for federation.

Click Finish to complete the wizard.

Note:

In the left pane of Topology Builder, you can see the Communicator Web Access

server under BackCompatSite in the Trusted application servers node.



Migrate Using Lync Server Management Shell (optional)The following topics outline the steps needed to merge your Office Communications Server 2007

R2 pools to Lync Server 2010 pools using the Lync Server Management Shell, and the

associated migration cmdlets. The topic Create a Custom Edge Server Input File defines an

example Edge Server input file, and then describes in detail the various parameters of that file

and also the necessary cmdlets that must be run to complete the migration. This section is

optional and replaces running the Topology Builder Merge wizard procedure, described in Phase

4: Merge Topologies.

In This Section

Define Edge Server Input File

141


Create a Custom Edge Server Input File

Run Migration Cmdlets


In Microsoft Office Communications Server 2007 R2, Edge Server information is not stored in

WMI. As a result, the Merge-CsLegacyTopology cmdlet cannot retrieve information about your

Edge Servers. If you have Office Communications Server 2007 R2 Edge Servers that need to be

migrated, then you must create a custom XML file that contains your legacy Edge Server

information. To do so, we recommend that you copy the code in the attached sample and modify

the relevant parameters to match your deployment. A copy of this code (input.xml) is included in

the Migration folder. For a detailed explanation of the parameters and details about authoring an

Edge Server Input File, see Create a Custom Edge Server Input File.

<?xml version="1.0" encoding="utf-8"?>

<TopologyInput xmlns =

"urn:schema:Microsoft.Rtc.Management.Deploy.LegacyUserInput.2008"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<EdgeClusters>

<EdgeCluster AP="true" MR="true" DP="true" Version="OCS2007R2"

FederationEnabled=”true”>

<LoadBalancer InternalFqdn="edgeint.fqdn"

ExternalDPFqdn="externalDP.fqdn" />

<Machines>

<Machine InternalFqdn = "node1.fqdn"/>

<Machine InternalFqdn = "anothernode1.fqdn"/>

</Machines>

<Ports InternalAPPort="5061" InternalDPPort="8057"

ExternalDPPort="443" />

<DirectorOrEdgeNextHop Fqdn="director.fqdn.com" IsDirector="true" />

</EdgeCluster>

</EdgeClusters>

<RegistrarClusterPort EnableAutoDiscoveryOfPorts = "false"

Port="5061" />

</TopologyInput>

For a Consolidated Edge Server

Edit the input.xml file mentioned in the previous section and make the following list of changes:

142


Replace edgeint.fqdn with the Office Communications Server 2007 R2 Edge Server

internal FQDN.

Replace externalDP.fqdn with the Office Communications Server 2007 R2 Edge Server

external Data Proxy FQDN.

Replace node1.fqdn with the Office Communications Server 2007 R2 Edge Server internal

FQDN.

Replace anothernode1.fqdn with the additional Office Communications Server 2007 R2

Edge Server internal FQDN.

Replace director.fqdn.com with the Director or pool that is the next hop from the Office


Set AP="true", MR="true", DP="true".

Set FederationEnabled=”false” if you do not plan to use the legacy Edge Server for

federation.


The previous topic, Define Edge Server Input File, defined the building blocks for the input file

required to merge the legacy topology using the Lync Server Management Shell. This topic dives

deeper into the layout and purpose of the input.xml file. This topic explains the various

parameters you need to set when authoring the Edge Server input.xml file.

The input.xml file, which can be created using any text editor, should look something like this:


<TopologyInput

xmlns="urn:schema:Microsoft.Rtc.Management.Deploy.LegacyUserInput.2008"


<EdgeClusters>

<EdgeCluster AP="true" MR="true" DP="true" Version="OCS2007R2">

<LoadBalancer InternalFqdn="edgeint.fqdn”

ExternalDPFqdn="ExternalDP.Fqdn " />

<Machines>



</Machines>


ExternalDPPort="443"/>

<DirectorOrEdgeNextHop Fqdn="director.fqdn.com " />

</EdgeCluster>

</EdgeClusters>

143


<RegistrarClusterPort EnableAutoDiscoveryOfPorts = "false" Port =

"5065" />

</TopologyInput>

So what does all that mean? Well, to begin with, your XML file should start with the following XML

declaration: <?xml version="1.0" encoding="utf-8"?>

Note:

Although it is optional, the XML declaration helps avoid any confusion regarding the

version or encoding type used in the file.

After the XML declaration you should then insert the <TopologyInput> element, like so:

<TopologyInput



This element is very important: if <TopologyInput> is not present then schema validation will not

take place. In turn, that could cause Merge-CsLegacyTopology to try and merge a poorly-

formed XML file. Because this is an XML file, it is important that this be a well-formed XML file. As

a result, you also need to add a closing tag for the <TopologyInput> element:

</TopologyInput>

That means that your XML file should now look like this:


<TopologyInput



</TopologyInput>

With the basic file structure in place, you are now ready to identify the Edge Server components

deployed in Office Communications Server. That is something you do inside the <EdgeClusters>

element. With that in mind, your next step is to add opening and closing tags for the

<EdgeClusters> element to the XML file:


<TopologyInput



<EdgeClusters>

</EdgeClusters>

144


</TopologyInput>

Inside the <EdgeClusters> element you then add as many as five child elements:

<EdgeCluster> The <EdgeCluster> element is where you define the different Edge Server

roles in your existing Office Communications Server topology. There are three roles you need

to concern yourself with:

Lync Access Edge Server Previously known as the Access Proxy server, the Access

Edge Server is responsible for handling all SIP traffic that crosses your organization’s

firewall. If your topology includes an Access Edge Server, you need to add this attribute

to the <EdgeCluster> element: AP="true"

Web Conferencing Edge Server The web Conferencing Edge Server (also known as

the Data Proxy server) relays traffic between the A/V Conferencing Server and external

clients. If your topology includes a web Conferencing Edge Server, you need to add this

attribute to the <EdgeCluster> element: DP="true"

A/V Edge Server The A/V Edge Server (also known as the Media Relay server)

provides a single connection point that enables incoming and outgoing media traffic to

help firewalls and network address translation (NAT) devices. If your topology includes an

A/V Edge Server then you need to add this attribute to the <EdgeCluster> element:

MR="true"

Next, specify the version of Office Communications Server running in your legacy

domain. For Office Communications Server 2007 R2, use this attribute and attribute

value: Version="OCS2007R2"

Finally, if you have enabled federation in Office Communications Server you should add

FederationEnabled attribute to the <EdgeCluster> element:

FederationEnabled="true"

A completed <EdgeCluster> element will look something like this:


<LoadBalancer> The <LoadBalancer> element contains the fully qualified domain names

(FQDNS) for both your internal Edge Server load balancer and your external Edge Server

load balancers. Note that for external load balancers, you must specify all your load

balancers, including the Access Edge (AP), web Conferencing (DP), and A/V Edge (MR) load

balancers. A complete <LoadBalancer> tag should look something like this:

<LoadBalancer InternalFqdn="edgeint.fqdn "

ExternalDPFqdn="ExternalDP.Fqdn” />

If you do not use Edge Server load balancers then this element can be omitted.

<Machine> The <Machine> element contains the (FQDN) of your Edge Server (note that

this should be the server’s internal name). For example: <Machine InternalFqdn="node1.fqdn " />

<Ports> Use the <Ports> element to indicate the ports used by your Edge Servers. An

APPort indicates an Access Edge Server, a DPPort indicates a web Conferencing Edge

Server, and an MRPort indicates a Media Relay Server. Be sure and distinguish between

145


internal ports and external ports. The following example defines the ports InternalAPPort,

InternalDPPort, and ExternalDPPort:



<DirectorOrEdgeNextHop> The <DirectorOrEdgeNextHop> element contains the FQDN of

your Edge Server’s next hop server: <DirectorOrEdgeNextHop Fqdn="director.fqdn.com " /> If the next hop server is a Director, you must add the

attribute IsDirector="true":

<DirectorOrEdgeNextHop Fqdn=" director.fqdn.com "

IsDirector="true" />

If the IsDirector attribute is not set to "True," Lync Server 2010 will not be able to use the

Office Communications Server 2007 R2 Director for federation.

Upon completion, the element should look similar to the following:

<EdgeClusters>



ExternalDPFqdn="ExternalDP.Fqdn />

<Machines>



</Machines>




</EdgeCluster>

</EdgeClusters>

All that’s left now is to add the <RegistrarClusterPort> element; this is the section of the XML file

where you define the port and the transport type for your Registrar cluster. A completed

<RegistrarClusterPort> element, one that defines port 5065 and transport type MTLS, will look

like the following:

<RegistrarClusterPort EnableAutoDiscoveryOfPorts = "false" Port = "5065"

/>

The following conditions apply to the EnableAutoDiscoveryOfPorts parameter:

EnableAutoDiscoveryOfPorts is a required parameter but Port is an optional parameter.

If EnableAutoDiscoveryOfPorts is true and Port is provided, then the value of Port is ignored.

If EnableAutoDiscoveryOfPorts is false and Port is provided, then value of Port is used.

If EnableAutoDiscoveryOfPorts is false and Port is not provided, an error is logged as this is

an unsupported configuration.

146


So finally, that gives us an XML file that can be used with the Merge-CsLegacyTopology cmdlet:


<TopologyInput



<EdgeClusters>

<EdgeCluster AP="true" MR="true" DP="true" Version="OCS2007R2"

FederationEnabled="true">


ExternalDPFqdn="ExternalDP.Fqdn " />

<Machines>



</Machines>




</EdgeCluster>

</EdgeClusters>

<RegistrarClusterPort EnableAutoDiscoveryOfPorts = "false" Port =

"5065" />

</TopologyInput>

Run Migration Cmdlets

The migration process is carried out by a series of Lync Server Management Shell cmdlets.

The Merge-CsLegacyTopology cmdlet is used to migrate trusted service entries and

configuration settings from Microsoft Office Communications Server 2007 R2 to Microsoft Lync

Server 2010. This cmdlet creates an output file that contains the merged information from Office

Communications Server 2007 R2. This file is then used to publish information to the Lync Server

2010 Central Management store. Additionally, the Merge-CsLegacyTopology cmdlet allows you

to input an XML file that contains Edge Server information. If you do not plan to import Edge

Server information, remove the -UserInputFileName D:\input.xml parameter from Step 2 in the

following procedure.

Important:

Before running any of the migration cmdlets, be sure the account used is a member of

the RTCUniversalServerAdmins group.

The steps to migrate are:

147




2. Run:

Merge-CsLegacyTopology -TopologyXmlFileName D:\output.xml -

UserInputFileName D:\input.xml

Where D:\output.xml is the path where Merge-CsLegacyTopology will write its output file.

D:\input.xml is the path where Merge-CsLegacytopology expects to find the Edge Server

input.xml file, defined earlier. Change the paths to match your environment accordingly.

3. Run:

Publish-CsTopology -FileName D:\output.xml

4. Run:

Enable-CsTopology

Note:

To verify that this step completed successfully, see Verify Topology Information.

5. Run:

Import-CsLegacyConfiguration

Note:

You might see a warning, similar to the following, indicating a legacy policy setting

name includes characters that are being replaced with an underscore. You can safely

ignore this warning. This policy setting name is a default policy that was included with

Office Communications Server 2007 R2. Lync Server 2010 will import this policy but

replace the offending characters with an underscore.

6. Run:

Import-CsLegacyConferenceDirectory

7. Connect the pilot pool to the legacy Edge Servers by following the procedure in Connect Pilot

Pool to Legacy Edge Servers.

Now that the merge has completed you can use Topology Builder and Lync Server Control Panel

to administer the pool and view the overall side-by-side topology. For additional steps that you

should run after migration has completed, see Phase 6: Verify Your Pilot Migration.

See Also

148




149

Ls Migrate Ocs2007 r2

Documents

Transcript of Ls Migrate Ocs2007 r2