更改LYNC SIP地址

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 �C Part #2.

The rest of this article looks at:

1. User Impact & Communication

2. High Level Process

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

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

2. 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 [email protected] 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 [email protected] 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!) �C 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:

1. DNS: Add support of new SIP domain in DNS.

2. CERTIFICATES: Regenerate and assign new Lync server Certificates.

3. FEDERATION:

   • FEDERATION ROUTES: notify direct federation partners of change

   • Public IM Enablement

   
   

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

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

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

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

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

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

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

• https://dialin.domain.com

• https://meet.domain.com

A good article already exists on how to make this change on the ‘Lync Freak’ blog:http://blog.lyncfreak.com/2011/10/04/adding-new-sip-domains-to-lync/.

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 �C 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:

1. Microsoft Lync Server 2013 Domain Name System (DNS) Requirements

2. The Lync 2013 Protocol Poster

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 �C in addition to the old SIP domain �C 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:

DNS Name=Pool.OldDomain.corp
DNS Name=LyncWebSvc.OldDomain.corp
DNS Name=sip.OldDomain.com
DNS Name=LyncServer01.OldDomain.corp
DNS Name=meetings.OldDomain.corp
DNS Name=dialin.OldDomain.com
DNS Name=meet.OldDomain.com
DNS Name=LyncdiscoverInternal.OldDomain.com
DNS Name=lyncdiscover.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 �C usually determined through a WhoIs query �C 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:

1. The Lync user SIP address changes to [email protected]

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

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

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

5. 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 �C 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:

1. Frequently Asked Questions about Provisioning your Lync Server Deployment for Public IM Connectivity

2. Public Instant Messaging Connectivity

3. Public IM Connectivity Provisioning Guide for Microsoft Lync Server, Office Communications Server, and Live Communications Server

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:

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

2. On client-side, Lync client add-on’s (e.g. from Avaya, Cisco) might require an update.

3. Software that enables Lync communication (e.g. Communication-Enabled-Business-Processes (CEBP)) might also require an update.

Testing

Testing �C 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:

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

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

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

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

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

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

Cut-Over the Users to the new SIP Domain

The heart of the cut-over is updating the user SIP addresses to reflect the new SIP domain. This Microsoft TechNet blog article (Modify the SIP Address of an Enabled Lync Server User) has some good information on how to do that in the Lync Management PowerShell.

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