Change Default SIP Domain in Lync
First I need to inform you that changing the Default SIP Domain will have huge and undefined serious issue in you deployment.
Consider your doings and don't ignore the warnings. I give you an overview about what some customers were planning.
Example:
During you setup you had chosen MYCLOUD.AG and now you want to delete this SIP domain and change it to NEWSIP.COM
Effect:
Sure your uses can have a new SIP domain assigned. Well, they will than need to log out and in once it has change, so also their buddy list gets updated.
Well, Federated contact are never updated...
BUT/ WARNING:
There are several RtcApplications, Conferencing, Auto Test Service, Group Chat Server and much more (RSG, CAA,...). Those applications have also SIP addresses assigned. They are written to the Lync Active Directory Configuration and are also present in the Lync SQL databases.
If you change the SIP Domain via the Topology Builder, there is even a serious warning:
Get-CsApplicationEndpoint also reflect those application contacts
If you have a look into the AD, you see those contact defined here:
Configuration Partition\ Services\ RTS Service\ Application Contact\ CN={GUID}
Ok, another way how you can change your SIP Domain configuration is with:
Set-CsSipDomain
Reference: http://technet.microsoft.com/en-us/library/gg412949.aspx
Now additionally, we have look into the SQL database:
The users database is queried by the Lync Frontend Servers based on the Active Directory information's and build locally on the FEs. The database name is: RTCDYN. The Frontend SQL Instance is, the RTCLOCAL.
As you can understand from the naming, this is a dynamic database:
So, whats inside now?
The RTCDYN database contains, e.g. information about the actual logged in users, so as well the RtcApplication contact.
Therefore it is understandable, that those users are registered with the "old/ deleted" SIP domain (MYCLOUD.AG).
Since we had a look into the Warning during the topology changes, we see now some impacts. But this is not all.
I personally was leading a 3rd level support call at one of our customers. There I started the OCSLogger and analyzed with SNOOPER.
I was quite surprised when I saw this trace:
Instance-Id: 3ED7F
Direction: outgoing;source="local";destination="internal edge"
Peer: Dirpool.ad.int.int:56477
Message-Type: response
SIP/2.0 404 Not Found
Start-Line: SIP/2.0 404 Not Found
From: "Audio Test Service"<sip:RtcApplication-e907e499-ef29-44ff-9a19-5ecdb5fe98b3@SIP.customer.com>;epid=8270A5F05F;tag=0289aef0
To: <sip:RtcApplication-e907e499-ef29-44ff-9a19-5ecdb5fe98b3@SIP.customer.com>;tag=B2DDC23B7CCB0728A6543E03B9BABAD4
CALL-ID: 55fa1a16b0be4694a9dc45d6f170fe96
CSEQ: 37021 REGISTER
Via: SIP/2.0/TLS 10.20.20.110:56477;branch=z9hG4bKEEA56A6E.20C9655229CF5DDC;branched=FALSE;ms-received-port=56477;ms-received-cid=765100
Via: SIP/2.0/TLS 10.20.20.126:60793;branch=z9hG4bK5FAE95C5.1EA0D29CC6B43DDC;branched=FALSE;ms-received-port=60793;ms-received-cid=32C00
Via: SIP/2.0/TLS 10.20.20.126:54050;branch=z9hG4bK10b39d6f;ms-received-port=54050;ms-received-cid=20DB400
Content-Length: 0
ms-diagnostics: 1008;reason="Unable to resolve DNS SRV record";domain="sip.customer.com";source="sip.customer.com"
$$end_record
The customers SIP domain was: customer.com, so why the Audio Test Service popped up at their Edge interfaces with sip.customer.com?
Well, they did a change of there SIP domain during their deployment. The DNS zone was also deleted.
So I suggested at least changing the DNS zone and add the missing part in again. Well therefore it was working. But I was not allowed figuring out the entire impact to their deployment.
The RtcApplication can still login with the "wrong/ old" SIP domain, even when the DNS zone was not existing.
Which leads to, the contacts must register with in the normal Lync processes locally.
My concern is here:
What will be happen if the will migrate to another Lync version, even less, to another Lync Pool.
In this case, please DO NOT change the default SIP domain after you deployed the topology. There are more application contact depending on this initial SIP domain and here you may, especially with pChat and RGS encounter more weird things and depending behaviors.
Until now I also didn't got a clear statement from our Microsoft Lync team what will be happen and how to change the RtcApplication contacts.
-------------------------------------------------------------------------------------------
New-CsSipDomain -Identity newsip.com -IsDefault $true
Remove-CsSipDomain -Identity mycloud.ag
As we are able to see and verify, the Lync service are undergoing an update and reconfiguration process.
BUT NOW:
If i quickly checked the result and if I would now be able to delete this mycloud.ag SIP Domain, we got the same result as we got if we are using the Topology Builder.
This is because, the Topology Builder also executes the PowerShell commands in the background.
-------------------------------------
Additional SIP Domains can be change at anytime without any risk, if you consider all user related impacts and changes.
Consider your doings and don't ignore the warnings. I give you an overview about what some customers were planning.
Example:
During you setup you had chosen MYCLOUD.AG and now you want to delete this SIP domain and change it to NEWSIP.COM
Effect:
Sure your uses can have a new SIP domain assigned. Well, they will than need to log out and in once it has change, so also their buddy list gets updated.
Well, Federated contact are never updated...
BUT/ WARNING:
There are several RtcApplications, Conferencing, Auto Test Service, Group Chat Server and much more (RSG, CAA,...). Those applications have also SIP addresses assigned. They are written to the Lync Active Directory Configuration and are also present in the Lync SQL databases.
If you change the SIP Domain via the Topology Builder, there is even a serious warning:
Get-CsApplicationEndpoint also reflect those application contacts
If you have a look into the AD, you see those contact defined here:
Configuration Partition\ Services\ RTS Service\ Application Contact\ CN={GUID}
Ok, another way how you can change your SIP Domain configuration is with:
Set-CsSipDomain
Reference: http://technet.microsoft.com/en-us/library/gg412949.aspx
Now additionally, we have look into the SQL database:
The users database is queried by the Lync Frontend Servers based on the Active Directory information's and build locally on the FEs. The database name is: RTCDYN. The Frontend SQL Instance is, the RTCLOCAL.
As you can understand from the naming, this is a dynamic database:
So, whats inside now?
The RTCDYN database contains, e.g. information about the actual logged in users, so as well the RtcApplication contact.
Therefore it is understandable, that those users are registered with the "old/ deleted" SIP domain (MYCLOUD.AG).
Since we had a look into the Warning during the topology changes, we see now some impacts. But this is not all.
I personally was leading a 3rd level support call at one of our customers. There I started the OCSLogger and analyzed with SNOOPER.
I was quite surprised when I saw this trace:
Instance-Id: 3ED7F
Direction: outgoing;source="local";destination="internal edge"
Peer: Dirpool.ad.int.int:56477
Message-Type: response
SIP/2.0 404 Not Found
Start-Line: SIP/2.0 404 Not Found
From: "Audio Test Service"<sip:RtcApplication-e907e499-ef29-44ff-9a19-5ecdb5fe98b3@SIP.customer.com>;epid=8270A5F05F;tag=0289aef0
To: <sip:RtcApplication-e907e499-ef29-44ff-9a19-5ecdb5fe98b3@SIP.customer.com>;tag=B2DDC23B7CCB0728A6543E03B9BABAD4
CALL-ID: 55fa1a16b0be4694a9dc45d6f170fe96
CSEQ: 37021 REGISTER
Via: SIP/2.0/TLS 10.20.20.110:56477;branch=z9hG4bKEEA56A6E.20C9655229CF5DDC;branched=FALSE;ms-received-port=56477;ms-received-cid=765100
Via: SIP/2.0/TLS 10.20.20.126:60793;branch=z9hG4bK5FAE95C5.1EA0D29CC6B43DDC;branched=FALSE;ms-received-port=60793;ms-received-cid=32C00
Via: SIP/2.0/TLS 10.20.20.126:54050;branch=z9hG4bK10b39d6f;ms-received-port=54050;ms-received-cid=20DB400
Content-Length: 0
ms-diagnostics: 1008;reason="Unable to resolve DNS SRV record";domain="sip.customer.com";source="sip.customer.com"
$$end_record
The customers SIP domain was: customer.com, so why the Audio Test Service popped up at their Edge interfaces with sip.customer.com?
Well, they did a change of there SIP domain during their deployment. The DNS zone was also deleted.
So I suggested at least changing the DNS zone and add the missing part in again. Well therefore it was working. But I was not allowed figuring out the entire impact to their deployment.
The RtcApplication can still login with the "wrong/ old" SIP domain, even when the DNS zone was not existing.
Which leads to, the contacts must register with in the normal Lync processes locally.
My concern is here:
What will be happen if the will migrate to another Lync version, even less, to another Lync Pool.
In this case, please DO NOT change the default SIP domain after you deployed the topology. There are more application contact depending on this initial SIP domain and here you may, especially with pChat and RGS encounter more weird things and depending behaviors.
Until now I also didn't got a clear statement from our Microsoft Lync team what will be happen and how to change the RtcApplication contacts.
-------------------------------------------------------------------------------------------
Today I made some additional tests:
As described at top, I changed the mycloud.ag again a new default SIP Domain newsip.com. But this time I used the PowerShell to do so:New-CsSipDomain -Identity newsip.com -IsDefault $true
Remove-CsSipDomain -Identity mycloud.ag
BUT NOW:
If i quickly checked the result and if I would now be able to delete this mycloud.ag SIP Domain, we got the same result as we got if we are using the Topology Builder.
This is because, the Topology Builder also executes the PowerShell commands in the background.
-------------------------------------
Summary:
KEEP YOUR FINGERS of those changes, it has a reason why the topology build warns you.Additional SIP Domains can be change at anytime without any risk, if you consider all user related impacts and changes.
Comments
Post a Comment