Anatomy of a SIP Domain Change

Overview

Mergers, acquisitions, and branding initiatives usually necessitate a significant but poorly understood change to a Lync Server deployment: a change to the domain name used in the Lync user SIP address (the right-hand-side of the @ sign).

Making this change in a way that minimizes user disruption is a challenge. This blog post aims to provide additional insight and guidance on the user impact, the process to follow, and what changes are required to your infrastructure.

It was written for Lync Server 2010, but all of it should be applicable to Lync Server 2013 (as far as I know).

This post focuses on changing the SIP domain portion of the SIP address. Changing the left-hand side of a SIP address has several different implications and is covered in my blog post Anatomy of a SIP Address Change – Part #2.

The rest of this article looks at:

User Impact & Communication

High Level Process

Required Infrastructure Changes

User Impact & Communication

This section covers the major impact to end-users during a SIP domain change.

Existing Lync Meetings

Any existing Lync Meetings a Lync user had scheduled before the SIP change will not work after the SIP change. Users will have to be notified that after the new SIP address comes into affect they will need to recreate any previously scheduled meetings.

Any attempts to use the previous Lync online meeting URL after the change will produce the following error in the Lync client:

Tip: if the Lync users’ SIP address is reverted back, any previously scheduled meetings will still work.

Lync Client

The following details the user experience in the Lync client during a change to the SIP address:

Active Lync Client Sessions are Signed-Out: when a Lync administrator changes the SIP address any connected Lync clients will be signed-out from their active session.

Users will be Prompted for Credentials on Sign-in After the Change: if the new SIP address (with the new domain) does not match the users UserPrincipleName (UPN) in Active Directory, they will be prompted for credentials on sign-in, and they must use the DOMAIN\username format (i.e. not the sipUser@domain.com format).

The UserPrincipleName (UPN) is the Internet-style login name for a user stored in AD. In the AD Users and Computers it is the “User logon name” attribute. The DOMAIN\UserName is also referred to as the Down-Level Logon Name format for a user name and the DOMAIN portion is the NetBIOS format (unqualified).

The credential prompt in the client will look like this:

Lync User Contact Lists

After a SIP address change, a Lync users contact list will be retained. After they sign-in with the new SIP address, their contact list should be the same as before, and their contact lists will be updated to reflect the new SIP domain.

The Lync backend used resource ID’s and not SIP addresses, so it is able to quickly reflect changes to the SIP address (when the domain portion changes).

Federated & Public IM Contacts

After the SIP change, external contacts will still appear in the internal user Lync client, and internal users will be able to attempt to initiate communication with them.

However, federated contacts will still have the old SIP address in their address book and there is no automated method of updating the address books of all federated contacts to reflect the SIP domain change, so the internal Lync users will have to manually contact their external contacts and have them update their address books.In my experience this is the most significant impact to end users in the SIP domain change process as it exists today.

After the SIP change, if the federated partner is properly federated with the new SIP domain, when a Lync user initiates communication to an external federated contact, they will get a pop-up showing that user@domain.com is initiating a session (see the screen shot below) and they will have the opportunity to add the Lync user as a new contact with the new SIP address. This helps minimizes the end-user impact.

If you do not have open Lync federation, you need to make sure that you reach out to federated partners before the cut-over to the new SIP domain, and have them federate with your new SIP domain beforehand or communication will break (see below for more information).

The holds true for any public providers contacts (e.g. Skype, Yahoo!) – Lync users will need to have any of their Public IM contacts re-add them with their new SIP address.

Outlook Profile Change

The well known rule of thumb for integration between the Lync and Outlook clients is that the primary SMTP address used in the Outlook profile should match the SIP address used to sign-in to the Lync client.

Depending on how you plan to roll the SIP address change out for Exchange (i.e. if the email address is also part of the SIP domain change), you may need to instruct users to update their default Outlook profile. Outlook can be capable of leveraging the Exchange autodiscover service to auto-update the primary email address however I have heard of problems in the field where this does not work.

Here is a screenshot of where the email address will need to be updated in the Outlook profile:

Mobile Clients

After a Lync users SIP address has been changed, Lync users will have to manually change their sign-in address on their mobile clients the next time they attempt to login after their SIP address was changed.

High Level Process

No well documented process exists for changing the domain-portion of the Lync user SIP address, but the high level approach in this section has successfully been used, and it should provide a good start.

The basic approach aims to add support for the new SIP domain in the Lync deployment and associated infrastructure and then have the users cut-over and use it.

The basic process goes like this:

DNS: Add support of new SIP domain in DNS.

CERTIFICATES: Regenerate and assign new Lync server Certificates.

FEDERATION:

FEDERATION ROUTES: notify direct federation partners of change

Public IM Enablement

LYNC SERVER CONFIGURATION: Add the new SIP domain as a support SIP domain in Lync + Simple URLs

EXCHANGE CONFIGURATION: Ensure any changes required for integration with Exchange are made.

THIRD-PARTY APPLICATIONS: Ensure any third-party applications dependent on the SIP domains are updated.

TEST: Test the Lync features with new Lync SIP domain and with different clients and versions.

END-USER COMMUNICATION: Know the end-user impact and communicate what they have to do.

CUT-OVER: Change the SIP address of your users.

DECOMMISSION OLD SIP DOMAIN: More than one SIP domain can exist at a time, so there is not urgency, but it is recommended you decommission the old domain once it is no longer being used. Review your certificate Subject Names if you are configuring the new SIP address as the primary SIP address in Lync.

More information on each step is included in the section below (Required Infrastructure Changes).

Required Infrastructure Changes

Lync Server Configuration

Add the new SIP domain as an additional supported SIP domain. This is an easy topology change. Lync server can support multiple SIP domains, but only one can be the default.

If you are keeping the default SIP domain and the Lync server infrastructure that goes with it, you will not need to change the Simple URLs. If you are completely switching the Lync infrastructure over to the new SIP domain and not keeping the old domain, you will also need to add additional Simple URLs that include the new SIP Domain such as:

Note: the Lync deployment can fully support all of the Lync functionality with the new SIP domain added as an additional domain in the Lync topology; rather than the default SIP domain. I recommended getting all the the Lync functionality working with the new SIP domain being added as an additional SIP domain before considering changing the default SIP domain.

DNS Changes

Lync will require a number of new DNS records – none of which will impact your existing records. Therefore the DNS records for the new SIP domain can be added in parallel with the old records before the user SIP addresses are changed.

The DNS records required for specific Lync functionality are well documented:

Here is a summary of records that needed to be added in a recent SIP change project of Lync Server 2010 (for example purposes the new SIP domain will be called NewDomain.com).

Internal DNS Records

FQDN

TYPE

PORT

NOTES

_sipinternaltls._tcp.NewDomain.com

SRV

5061

Automatic sign-in for Lync clients

sip.NewDomain.com

A

Automatic sign-in for Lync clients

pool.NewDomain.corp

A

Front-End server pool A record

lyncdiscoverinternal.NewDomain.com

A

Internal mobility URL

dialin.NewDomain.com

A

Internal dial-in conferencing

meet.NewDomain.com

A

Internal conferences

External DNS Records

FQDN

TYPE

PORT

NOTES

_sip._tls.NewDomain.com

SRV

44

External automatic sign-in for Lync clients

sip.NewDomain.com

A

Fallback for external automatic sign-in for some clients

_sipfederationtls._tcp.NewDomain.com

SRV

5061

Auto-discovery of federated partners

webcon.NewDomain.com

A

External Web Conferencing

av.NewDomain.com

A

External Audio / Video

dialin.NewDomain.com

A

External dial-in conferencing

lyncdiscover.NewDomain.com

External mobility autodiscover

lyncwebsvc.NewDomain.com

External facing web services

meet.NewDomain.com

A

External facing conferences

Certificate Changes

Much like the DNS changes, the certificate changes for the new SIP domain can be made before the user SIP address cut-over. Adding the appropriate Subject Alternative Name (SAN) records of the new SIP domain on the certificates – in addition to the old SIP domain – allow both Lync SIP domains to be used at the same time, and makes the cut-over much easier because the Lync infrastructure can prepare for the new SIP domain while the Lync users are unaffected and use the old SIP domain (not unlike a side-by-side migration).

The certificate requirements for Lync Server 2013 are documented here: http://technet.microsoft.com/en-us/library/gg398066.aspx but as a general rule of thumb you will want to add a corresponding SAN entry for each existing SAN entry. The only factors to consider here are cost and any limits on the number of SAN entries.

For example, an internal certificate on a Front-End Enterprise Server, might have the following SANs for existing SIP domain OldDomain.com:

Essentially a new SAN entry should be added for all of the existing SAN entries on the certificate.

The most common method of updating the certificates is to issue a Certificate Service Request (CSR) with the new Subject Alternative Names that have the new SIP domain.

For Public Certificates you will need to submit the certificate request to the Certificate Authority. If the new SIP domain is a new root level domain, you will need to be listed as Authoritative for that domain – usually determined through a WhoIs query – to be able to request a certificate for that root domain.

After a new certificate has been issued, the Lync services should be restarted to use the new certificate.

Note: you do not have to be concerned with switching the Subject Name (SN) if the Lync infrastructure is configured to use it, and it is still configured as the default SIP domain in Lync Server Topology. As mentioned earlier, your Lync users will have full functionality with the proper configuration of the new SIP domain being an additionally supported SIP domain.

Possible Certificate Warnings & Lync Trust Model Change on the Client

Lync is sensitive to domain changes, and if the names on the Lync certificates and the Lync DNS records don’t match, errors and warnings will be displayed.

The Lync client uses Exchange Web Services (EWS) for integration with Exchange on the client-side, and one issue that can arise is this:

The Lync client queries the Exchange Autodiscover service (e.g. at https://autodiscover.NewDomain.com/autodiscover/autodiscover.xml).

The Certificate on the Exchange Autodiscover Service has a Subject Name different from the new SIP domain (e.g. OldDomain.com).

Because the domain name on the certificate does not match the new SIP domain, the Lync client falls-back to an internal ‘Trust Check’ (which compares the new SIP domain to a list of trusted domain names in a client-side registry key).

When the internal trust check fails, the Lync client generates the following certificate warning and security prompt to the Lync user shortly after sign-in with the Lync client:

One method to fix this is to add the new SIP domain to the trusted domain names used by the Lync client.

This amounts to adding a client-side registry key (HKEY_CURRENT_USER\Software\Microsoft\Communicator\TrustModelData) that satisfies the Lync client’s internal trust check: http://support.microsoft.com/kb/2531068. I bolded “adding” in the last sentence because it is a good idea to add the new SIP domain to this list rather than deleting any other entries that already exist there.

Another option might be to update the Exchange Client Access Server (CAS) autodiscover website certificates if Exchange email address changes are being planned at the same time. Special thanks to Steve Gover for providing these details.

Federation

If existing federation partners are using direct federation, it is a good idea to notify your partners and have them add support for the new SIP domain well before the cut-over.

Public IM Enablement

If the existing Lync environment has Public IM enabled for a one or more Public IM providers (e.g. Skype, Yahoo! or AOL) you’ll need to update your federation record so that the Public IM system can communicate with the new SIP domain.

Microsoft has a portal to configure the federation routes and to establish the necessary licensing at: Microsoft Lync Server Public IM Connectivity Provisioning. This portal requires that you sign-in a Windows Live account – use the account associated with your customer-id used to configure the original Public IM federation. With this portal you can check the status of your licensing (i.e. whether it is included as part of a volume license or whether you will need to submit a new purchase order).

This portal provides some links to information about the Public IM functionality and process:

Exchange Configuration

It is a good idea to review any Lync and Exchange integration such as Unified Messaging and Outlook Web App integration. I am not aware of any significant issues that arise, but Exchange integration can be dependent on the environment it is deployed in, and you should review it for any dependencies on the former SIP address domain.

Third-Party Applications

It is a good idea to give thought to any third-part applications that are deployed either in the organization or client-side:

On the server-side Reporting and Monitoring applications might need to be updated. Keep in mind that reporting data might be skewed after a SIP domain change (i.e. for reports that were depending on a SIP address).

Testing

Testing – who needs testing? Everything always goes flawlessly! But if you do want to test, and you should, once the new SIP domain is added in the Lync infrastructure it is best to have a few test accounts or closely monitored guinea pigs, and make the SIP change with them first and observe the experience of all the Lync functionality.

Be sure to test different client types (e.g. the Lync Web App, the Outlook Web App integration if it is configured).

Also be sure to watch-out for certificate errors on the Lync client side. If the Lync certificates and DNS records were not updated properly, there will be certificate warnings and errors presented to the user.

End-User Communication

The end-user impact after a SIP domain change was detailed above in the ‘User Impact & Communication’ section.

Users will need to know before the change that:

Users will be Signed-Out of an Active Lync Client Session when the SIP Change is made.

Users will need to Sign-In with their new SIP Address.

Users will need to enter their associated AD Credentials in the ‘DOMAIN\UserName’ Format.

Users will need to Recreate any Previously Scheduled Lync Meetings (e.g. scheduled before the SIP change).

Users will need to reach-out to any Federated and Public IM Contacts and Request that their Address is Updated.

Users might have to update the Primary Email address in their Outlook client to match their new SIP address if an email change is part of the change and no automated method exists to update it.

It is also a good idea to reassure users that their corporate credentials (e.g. username and password) are not changing (if that is indeed the case).

Tip: in case you were wondering – changing the SIP address in the Lync Management PowerShell with the cmdlet Set-CsUser (e.g. with the –SipAddress parameter) does change the Active Directory attribute msRTCSIP-PrimaryUserAddress. It does not change the UserPrincipleName (shows up as User Logon Name in ADUC).

And that is about it. Please provide any comments and feedback on your experiences with SIP domain changes!

13 comments to Anatomy of a SIP Domain Change

Excellent article Curtis, thank you.
I have performed this primary SIP domain change in a lab and preparing to do it for a production network, I discovered another issue.
After the domain change, when you change the SIP domain for one of your existing Lync users, they have to sign in again as you describe, but – Outlook keeps sending Lync meeting invites using the old SimpleURL!
The only way I found to change this is to delete the mail account from Outlook and add it again. A very painful procedure. What are your thoughts?
Thanks
Michael

When an existing user that has a @testdomain.local SIP address has his SIP address changed to @publicdomain.com, the meeting invitations he sends still belong to the testdomain.local. The only way to start sending invitations to meet.publicdomain.com is to remove his outlook account and reconfigure it from scratch!

Weird – I’ve done this change several times in Lync 2010 and the the meeting invites use the new meeting URL. I just checked one recent system and it is good. FYI, in this environment Outlook/Office 2010 is used.

Has the corresponding email address for the user(s) changed in their Outlook profiles?

I’ve just tested this and the first time a user logs in to Lync the sign-in address is “magically” populated and the user just signs in. They don’t have to enter their SIP address manually. I am talking about domain joined machines only.

Given this is the case, why isn’t the changed SIP address also populated for them? If it can be populated initially then a mechanism must exist to look it up. I wonder if there is a way to trigger this in the Lync client so that the user isn’t forced to change their sign-in address manually after the SIP domain change?

Yes, depending on how the Lync client was rolled out, the sign-in address might be populated on the first run of the client.

One of those ways is through a GPO which sets a registry key on the client computer with the user SIP address. In the Lync 2010 client this was the ServerSipUri registered value at HKEY_CURRENT_USER\Software\Microsoft\Shared\UcClient; I believe it has changed for the Lync 2013 client).

And you could use this mechanism to avoid having the the user manually changing their SIP address provided #1] you change that registry key on the client computer, and #2] instruct users to * re-start * the Lync client (or you somehow force a restart after the SIP address change). It might be easier to just ask users to enter their new SIP address .

In the Outlook presence front, how long before and are there any steps to be taken before the change is updated? For example, nathan@domain.com is converted to nathan@uk.domain. Lets assume the change is made to sync the standard email format to the sip format (SIP:nathan@uk.domain = SMTP:nathan@uk.com). Changes in Lync presence work right away, but is there a delay in the Presence for others’ Outlook clients?

[...] Change – Part #2 By Curtis Johnstone, on July 31st, 2013 TweetMy previous blog entry “Anatomy of a SIP Domain Change” looked at the user impact and process of changing the domain portion (right-hand-side) of a Lync [...]

Legal

The posts and information on this blog are provided "as is" with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer or anyone else for that matter. All trademarks acknowledged. Copyright 2013 Curtis Johnstone.