Microsoft Lync Server 2010 – Mobility Services – LyncDiscover – External Configuration

Implementing Microsoft Lync Server 2010 Mobility Services for mobile devices is not that hard, but just to make it easy I have made this short checklist. This primary purpose of this article is to clearify how to use multiple SIP domains.

You only need domainB through domainD in this guide, if you have multiple SIP domains for users in the Lync Environment – typically if you use the same SIP address as the users primary e-mail address (companyA companyB and so on).

Steps:

  1. Download the Microsoft Lync Server 2010 Mobility Guide
  2. Read the complete document, and follow the instructions
  3. Plan your mobility implementation – and document it before implementing
  4. Verify that you have the correct DNS records set up (see note below)
  5. When publishing the LyncDiscover (page 28 in the Microsoft guide), remember to:
    Add LyncDiscover.domainA.com, LyncDiscover.domainB.com, LyncDiscover.domainC.com on the Public Name tab of the Web Publishing rule

    Use port 80/8080 for LyncDiscover

DNS Records:

If using more than one SIP domain, it is important that all external DNS domains contains the nessary SRV records, all SRV records should point to the “first” SIP domain (domainA.com), this reduces the amount of DNS names in the SAN certificates.

DNS records for each additional SIP domain:

  • (SRV) _sip._tls.domainB.com -> sip.domainA.com (like port 443)
  • (SRV) _sip._tls.domainC.com -> sip.domainA.com (like port 443)
  • (SRV) _sip._tls.domainD.com -> sip.domainA.com (like port 443)
  • (SRV) _sipfederationtls._tcp.domainB.com -> sip.domainA.com (like port 5061)
  • (SRV) _sipfederationtls._tcp.domainC.com -> sip.domainA.com (like port 5061)
  • (SRV) _sipfederationtls._tcp.domainD.com -> sip.domainA.com (like port 5061)
  • (Alias/C-Name) LyncDiscover.domainB.com -> LyncDiscover.domainA.com
  • (Alias/C-Name) LyncDiscover.domainC.com -> LyncDiscover.domainA.com
  • (Alias/C-Name) LyncDiscover.domainD.com -> LyncDiscover.domainA.com

Verify that LyncDiscover.domainA.com is present in the SAN certificate for the TMG server (not in the certificate for the Edge server, which should contain SIP records).

If you have followed the Microsoft Lync Server 2010 Mobility Guide and the few pointers above you should be able to connect your mobile device using only:

  • SIP signin (user@sipdomainA.com, user@sipdomainB.com, user@sipdomainC.com)
  • UPN singin (if different from SIP address)
  • Password

You will be prompted for accepting the certificate for LyncDiscover.domainA.com, the very first time you sign in, just accept and you are ready to go. This is not at security prompt but a result of redirecting LyncDiscover.domainX.com to LyncDiscover.domainA.com.

You might want to read this too: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/

When working with SAN certificates I have found that GoDaddy.com is a cheap and easy way to get certificates.
Remember that you can sign certificates with the StarFish root instead of GoDaddy, looks nicer to me.
Advertisements

Why (not to) maintain the old PBX, when implementing Microsoft Lync Server 2010? (part 1)

When a decision has been made to implement Microsoft Lync Server with Enterprise Voice, most companies consider how to connect Lync Server to the old PBX, thereby introducing a more complex environment; it might not be the right decision.

Microsoft Lync Server supports SIP trunks (TCP/IP connection for VoIP data), from both “certified” SIP providers and “standard” SIP providers – for the customers this opens an entirely new world. A SIP trunk is a TCP/IP connection to a SIP provider, no hardware is needed, and multiple Lync Mediation Servers can use the same SIP Trunk. Most SIP trunk providers sell minutes way cheaper than existing PSTN/ISDN lines.

The Mediation server role in Lync Server, contains the features for configuring connection to a SIP trunk. In fact this turns the Lync server environment into a full blown PBX, leaving no real reason to route all calls through an existing PBX.

Reasons for connecting the existing PBX to the Lync environment can be:

  • Phased migration – all users are not moved to Lync in a single phase
  • Complex dial plans cannot be migrated yet
  • Voice mail is part of the existing PBX[1]

Microsoft Lync Server can handle multiple SIP trunks, for different purposes or locations. An example could be, you have multiple old PBXs and 3 different locations in the world, each location can have a SIP Trunk to a local SIP provider[2], and each location can have a SIP trunk for the old PBX, throughout the phased migration. Dialing plans are used to control the flow of the voice call[3].

But please consider the complexity in the example above, in most cases the PBX can be phased out in one step, moving the phone numbers from the PSTN/ISDN to the SIP provider – this greatly simplifies the migration, but must be carefully planned, since all dial plans, normalization rules and call routing must be in place.


[1] Seriously consider using Microsoft Exchange 2010 UM instead

[2] Allowing for the cheapest dialing rates

Why (not to) maintain the old PBX, when implementing Microsoft Lync Server 2010? (part 2)

The “only” requirements for implementing an external SIP trunk in a Microsoft Lync 2010 environment are:

  • Configuration is done using the Lync Server 2010 Topology Builder[1] and not the Lync Control Panel
  • Firewall rules must be created to allow for the VoIP traffic from the servers running the Mediation role to the SIP provider
  • The Mediation Server must have a public IP address for external SIP communication.
  • The users who are supposed to use the external voice features, must be enabled for Enterprise Voice in Lync Control Panel[2]

Features you might consider when implementing SIP trunks:

  • Multiple Mediation servers, in the same Mediation pool – allows for automatic failover. Each Mediation server can be placed in a different location and be “load balanced” using DNS. If one server fails, another Mediation server will be used to route new calls to and from the Lync server environment. Remember that active calls will be lost, if the currently active Mediation server fails[3].
  • Please consider using encryption (TLS) – if the internet is used as a transport for VoIP data.
  • Analog lines are supported, using 3rd party gateways like AudioCodes MediaPack 1xx – a number is assigned to each analog port in a gateway, devices like fax machines, door phones and so on is connected directly to the gateway[4]. This allows for voice calls between an analog device and the Lync environment[5].

[5] WARNING: Do not connect analog lines for alarms, elevator intercoms and other critical utility lines – please use local PSTN/ISDN lines for the special features.