Planning to Move Users to Enterprise Voice in Office Communications Server

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

The process of moving users from an existing telephony infrastructure to Enterprise Voice consists of the following steps:

  1. Designate primary phone numbers.

  2. Enable users for Enterprise Voice.

  3. Enable users for PBX integration.

  4. Plan user voice policies.

  5. Configure PBX to reroute calls for users enabled for Enterprise Voice.

  6. Move users to Exchange Unified Messaging.

This topic describes the planning that is necessary for each of these steps.

Step 1 Designate primary phone numbers

Enterprise Voice integrates voice with other messaging media, such that when an incoming call arrives at the server, the server maps the number to the users SIP-URI and then forks the call to all the client endpoints associated with that SIP-URI. This process, known as reverse number lookup, requires that each user be associated with a primary phone number.

A Primary Phone Number must be:

  • Globally unique or, in the case of internal extensions, unique in the enterprise.

  • Owned by and routable in the enterprise. Personal numbers should not be used.

Enterprise users may have two or more telephone numbers listed for them in Active Directory. All the telephone numbers associated with a particular user can be viewed or changed on the property sheet for that user in the Active Directory Users and Computers snap-in.

  • The Telephone number text box on the General tab of the User Properties dialog should contain the users main work number. This number will usually be designated as the users Primary Phone Number.

Certain users may have exceptional requirements (for example, an executive who wants all incoming calls routed through an administrative assistant), but such exceptions should be limited only to those where the need is clear and critical.

Once a primary number is chosen, it must be:

  • Normalized to E.164 format, wherever possible.

  • Copied to the Active Directory msRTCSIP-line attribute


    Coexisting with Remote Call Control
    Remote call control is the ability to use Office Communicator to monitor and control a desktop PBX phone. Control is routed through the server, which acts as a gateway to the PBX. Remote call control first became available with Live Communications Server 2005 with SP1 and Communicator 1.0. Communications Server 2007 and Communicator 2007 together continue to provide remote call control to users who are not enabled for Enterprise Voice.
    If you have enabled remote call control in your organization, you know that remote call control also uses the msRTCSIP-line attribute to designate the primary phone number for users. If your organization will have some users enabled for Enterprise Voice and others, perhaps most, still connected to a PBX, you may be concerned about whether Enterprise Voice and remote call control can coexist.

There are two methods for populating the msRTCSIP-line attribute:

  • Advanced settings in the Office Communications Server snap-in for the Active Directory Users and Computers management console.

  • MIIS (Microsoft Identity Integration Server) or WMI (Windows Management Instrumentation) scripts. MIIS is recommended for this purpose.

Where many phone numbers must be processed, a script is the obvious choice. Depending on how your organization represents telephone numbers in Active Directory, the script may have to normalize primary phone numbers to E.164 format before copying them to the msRTCSIP-line attribute.

  • If your organization maintains all telephone numbers in Active Directory in a single format, and if that format is E.164, then your script only needs to write each Primary Telephone Number to the msRTCSIP-line attribute.

  • If your organization maintains all telephone numbers in Active Directory in a single format, but that format is not E.164, then your script should define an appropriate normalization rule to convert Primary Telephone Numbers from their existing format to E.164 before writing them to the msRTCSIP-line attribute.

  • If your organization does not enforce a standard format for telephone numbers in Active Directory, then your script should define appropriate normalization rules to convert Primary Phone Numbers from their various formats to E.164 compliance before writing the Primary Telephone Numbers to the msRTCSIP-line attribute. For assistance in translating Active Directory user phone attributes into valid telephone URIs, see "Configure Telephone URI Script" in the Readme for the Office Communications Server 2007 Resource Kit.

Your script will also have to insert the prefix Tel: before each primary number before writing it to the msRTCSIP-line attribute.

The expected format of the number specified in this attribute is:

  • Tel:+14255550100;ext=50100.

  • Tel:+14255550101;ext=12345 (for private numbers within the enterprise)


The normalization performed by ABS does not replace or otherwise eliminate the need to normalize each user's primary phone number in Active Directory because ABS does not have access to Active Directory and therefore cannot copy primary numbers to the msRTCSIP-line attribute.

Step 2 Enable users for Enterprise Voice

Other than identifying which users are to be enabled, no special planning is required to complete this step. For step-by-step instructions for enabling users for Enterprise Voice, see Step 8. Enable Users for Enterprise Voice.

Step 3 Enable users for PBX integration (optional)

Users who are enabled for Enterprise Voice can also be enabled for PBX integration. If you have elected to deploy Office Communications Server using the PBX integration option, then you must enable users for PBX integration for the option to work. If you do not have a PBX enabled for Office Communications Server, enabling users for PBX integration will have no effect. Office Communications Server will continue forking calls to all endpoints, but the PBX will be unable to fork incoming calls to a user's SIP endpoints.

For information about deploying Office Communications Server with PBX integration, see Office Communications Server-PBX Coexistence, in Select a Deployment Option in Office Communications Server. For step-by-step instructions for enabling users for PBX integration, see Step 9. Enable Users for PBX Integration (Optional).

Step 4 Plan user voice policies

User class-of service settings on a legacy PBX, such as the right to make long-distance or international calls from company phones, must be reconfigured as VoIP policies for users moved to Enterprise Voice. For more information on planning and creating policies for Enterprise Voice, see Voice Policies and Step 6. Configure Call Authorization.

Step 5 Configure PBX to reroute calls for Enterprise Voice users

Users who formerly were hosted on a traditional PBX retain their phone numbers after the move. The only requirement is that after the move, the PBX must be reconfigured to route incoming calls for Enterprise Voice users to the media gateway that connects to the Office Communications Server 2007 infrastructure. Contact your PBX vendor for details on how to configure dual forking.

Step 6 Move users to Exchange Unified Messaging (optional)

Moving users to Exchange Unified Messaging consists of the following tasks:

Configuring Exchange UM and Office Communications Server to work together (see Plan for Exchange Server 2007 SP1 Unified Messaging in Office Communications Server).

Enable users for Exchange UM call answering and Outlook Voice Access. This task is performed on the Exchange UM server using Exchange Server 2007 product documentation, which is available at