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 peter.pan@neverland.com, your SIP Domain should be neverland.com and therefore your SIP address would be the same as the email address, peter.pan@neverland.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?

1. 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. 
2. 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 user@domain.local 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

• 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)