Arguably one of the most common Lync deployment mistakes is assuming that the SIP Domain is also the AD domain. I suppose the mention of the word domain here may be the misleading culprit. Perhaps the idea was to keep the SIP addresses identical to the logon names to comply with UPN (User Principal Names)
Traditionally (prior to Lync anyway) most SIP Servers would speak of a SIP Realm. This SIP Realm is now what is being referred to as the SIP Domain.
So what should you call your Lync SIP Domain then?
Microsoft do recommend that you match your SIP naming convention to your email address naming convention. So if your email address is for example firstname.lastname@example.org, your SIP Domain should be neverland.com and therefore your SIP address would be the same as the email address, email@example.com
Why is using a domain.local not a good idea?
Firstly if you EVER want to extend your Lync deployment to include access from externally (be that mobility or federation) then you will have some rather major road blocks. Why?
- DNS – These methods use DNS to find the services on offer, basically you cant add a domain.local name to the public DNS. This means that none of the automated, built-in discovery mechanisms are going to work.
- Certificates – Most of the Lync related traffic is TLS\MTLS. The dependency on certificates is unavoidable (as it should be). If you want the authentication to work seamlessly with especially mobile devices and also federated partners (neither of these would naturally trust your internal Certificate Authority) then making use of a public certificate is really a must. Usually the Lync Public certificates are UC SAN Certificates, the SAN’s (as of early 2013) can not be domain.local – they must be publicly recognized names
Won’t changing the SIP Domain break SSO (Single Sign On) if the SIP address doesn’t match the UPN?
Nope. In AD the SIP Address is known and associated to the users AD sign in profile, if the credentials are valid in AD and the associated SIP address is active then SSO works out the box…with one exception 🙂
Of course, the exception is when the user has already signed in to Lync using a firstname.lastname@example.org SIP address. In this event the Lync Sign in details would have been saved in the registry, this will need to be removed to avoid user interruption during automatic sign in.
Whats the risk in changing the SIP Domain?
Generally I find that organizations come across the SIP Domain issue before deploying Enterprise Voice. Hopefully early in the roll out or adoption as the more users on Lync using the various features the more users may be affected.
With that in mind, consider the impact:-
- You need to own the Public DNS names space for the SIP Domain as you will need to add some A and SRV records.
- Internally the DNS names also need to be valid (usually Split Brain DNS is best) for auto sign in of the clients – perhaps you reason that you will push out manual SIP Server\Pool FQDN’s to the clients to circumvent this – you may regret this later should you want to include Pool fail over as this leverages auto discover.
- If you already have a Public Certificate it will need to change significantly, the assumption is that most haven’t quite got to the public certificate yet and would have had trouble proceeding with a domain.local addresses in the SAN anyway.
- The internal certificates will need to be renewed to include the new SIP Domain naming
- You DO NOT need to change any of the internal Lync Server FQDN’s.
- You DO NOT need to change the OAuth Token Issuer Certificate
- *Exchange Unified Messaging has not yet been deployed, this is also usually the case as voice mail and other UM features are associated with Enterprise Voice
- **No Response Groups Exist at this time, again these are deployed after enabling Enterprise Voice
- *** The Meet, Dialin, GAL and Addressbook URL’s will need to change and thus the Reverse Proxy rules will need changing as well
- And of course the users will need to have the local Lync sign in registry key removed prior to changing their SIP address to the new domain.com address format.
- Common Area Phones will have their SIP Addresses changed as well and so will have to be signed in manually since their cached sign in details will have changed. Again, its uncommon to find Common Area Phones when there is no Enterprise Voice deployed
- All Lync Meeting URL’s will change and thus none of the previous meeting URL’s will work post SIP address change – Do make sure the users understand this
- The users will NOT loose their contacts when their SIP address changes
* The UM Auto Attendant and Subscriber Access SIP Addresses will need to be changed to domain.com as well.
** If Response Groups are already deployed then the SIP Address assigned to each workflow will be assigned to a domain.local address and thus will have to be corrected prior to removing the domain.local SIP Domain.
** If you change the SIP Address of any Enterprise Voice users that are assigned as Agents to a Response Group you will have caused an issue with the Workflow. Rather remove the user as an agent thn make the SIP Address change, followed by re-adding the user to the Group
*** WARNING – Any recurring meetings will become invalid if the previous Meet URL is removed. Of course this is
I didn’t say it was going to be a small piece of work..
How do I move my Lync SIP Domain from a domain.local to a domain.com?
Follow these steps:-
- Add the new SIP Domain to the existing Topology from Topology Builder
- Define the URL’s
- Create the DNS Records for the new SIP Domain (internal and external)
- Request new Certificates to support Auto configuration and simple URLs (both internal and external)
- Enable-CsComputer for each Pool Member (and Director)
- Change the SIP Address for the users
- Get the users to sign in with the new address (preferably automatically)
- Change the Default SIP Domain to domain.com
1. Adding the new SIP Domain
Assuming that my current domain is neverland.local and I want to move to neverland.com
Fire up the Topology Builder and edit the deployment properties. Add the additional SIP Domain (domain.com)
2. Defining the new URL’s
You will notice that the new meeting URL has been added automagically. The new SIP Domain can leverage the existing Dialin URL however in this case it will be dialin.neverland.local which wont do as its not accessible from external.
So now we have meet and dialin setup for neverland.com
Next change the external URL (this is the URL that hosts the ABS, GAL and a few other services.
Go ahead and publish this.
3. Create the DNS Records for the new SIP domain (internal and external)
Add the following DNS records:-
- (external and internal)
- lyncdiscover.domain.com (external)
- lyncdiscoverinternal.doamin.com (internal)
- (external and internal)
- SRV 5061-> (internal)
- SRV 443-> (external)
- SRV 5061-> (external)
- Using the deployment wizard, Step 3, Request new default Certificates for all Front End Server\s (internal)
- If using a load balancer with SSL offloading this needs to be updated as well
- The Edge Server Certificate (external) will need to be updated. Use the deployment wizard Step 3 from the Edge Server to generate the certificate request
- Update the Reverse Proxy Certificate (external)
Basically this Powershell Command is run from each Lync server running IIS. It adds the IIS sites required by the new name spaces
6. Change the SIP Address for the users with the following Powershell command
get-csuser -DomainController $DomainController | Enable-csuser -Registrarpool -SipAddressType EmailAddress
7. Get the users to sign in with the new address automatically.
Simple is best so I use the following as a cmd and get the team to add it to the log-in script until everyone is over to the new SIP Domain
ECHO Closing Lync 2013
ECHO Removing old signin address
Reg delete HKCU\Software\Microsoft\Office\15.0\Lync /f
ECHO Starting Lync 2013
call “C:\Program Files\Microsoft Office\Office15\lync.exe”
8. Change the Default SIP Domain to domain.com
Moving forward we want users to be assigned to the neverland.com sip domain by default. So Back to the Topology builder to change the default SIP Domain
Removing the Old SIP Domain entirely is not recommended as there are several RtcApplications including Conferencing, Audio Test Service, RGS, CAA etc. which have SIP addresses assigned to them at the time of the initial configuration. These addresses are associated with the default SIP domain at the time. Changing the default SIP Domain in the Topology builder (or Powershell) does not update these Lync Objects.
For this reason it may be safest to add the old SIP Domain as an Additionally Supported SIP Domain.