I been working with a customer and helped them with a split of their Skype for Business environment during a company split. About 2500 users of the 30000 users was moving to a new Skype environment and they were going to keep the current SIP domain. The majority of users where going to need a new domain for their SIP address (also mail and UPN). The larger company (Fabrikam) was going to keep the infrastructure and the other smaller company (Contoso), that were keeping the company name, needed new Skype servers.
The split was going to be done as a big bang during a weekend were we removed the Contoso users from Fabrikam environment and change all Fabrikam users to SIP address @fabrikam.com. At the same time Contoso started to use their new Skype platform with contoso.com SIP address.
The process started with adding fabrikam.com as a secondary domain in topology. Some pilot users started to work the new domain. We later, before the cutover, changed so that fabrikam.com was the primary SIP domain.
After the removing the old SIP domain (contoso.com) from the Fabrikam Skype we could not federate between the companies. We checked that DNS queries for was correct and pointed to the new Contoso Skype servers and we where able to get connected on TCP-5061 between Contoso and Fabrikam public Edge Access IP. We also checked the topology for Fabrikam to see that contoso.com really was removed everywhere. Federation with all other companies worked without any problem for both Contoso and Fabrikam.
Test-CsFederatedPartner gave us the error 404, Not Found.
Test-CsFederatedPartner -TargetFqdn edgepool.addomain.net -Domain contoso.com Target Fqdn : Result : Failure Latency : 00:00:00 Error Message : 404, Not Found Diagnosis : ErrorCode=1003,Source=sfbaccess.fabrikam.com,Reason=User does not exist,destination=Options_User@contoso.com Microsoft.Rtc.Signaling.DiagnosticHeader
Running SIP tracing on edge servers gave us some more hints, “The request URI domain is hosted locally and cannot be routed to a federated partner”. So Fabrikam servers still think that contoso.com is a locally hosted SIP domain even if it’s not to be found in topology.
( 1024351871 )( 00000003CC629238 ) Request-Uri is internal or automatically discerned split-domain traffic points back to us, sending 404 Returned 0xC3E93D74(SIPPROXY_E_EPROUTING_MSG_INTERNALDOMAIN_NOTALLOWED) TL_WARN(TF_DIAG) [edgepool\edgeserver01]153C.2A40::06/18/2017-08:41:22.364.000CB298 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(830))  $$begin_record Severity: warning Text: The request URI domain is hosted locally and cannot be routed to a federated partner Result-Code: 0xc3e93d74 SIPPROXY_E_EPROUTING_MSG_INTERNALDOMAIN_NOTALLOWED SIP-Start-Line: OPTIONS sip:Options_User@contoso.com SIP/2.0 SIP-Call-ID: c49ff774ee0944a58ab39bc41c9d5149 SIP-CSeq: 1 OPTIONS Source: sfbfepool01.addomain.net:64751;ms-fe=sfbfeserver01.addomain.net Data: domain="contoso.com" $$end_record
After some digging we found that we never updated the public certificate on the Edge servers due to some problem with the provider. Since we been using both fabrikam.com and contoso.com as SIP domain for a couple of weeks, sip.contoso.com was still in the public certificate. After renewing the public Edge certificate and removing sip.contoso.com from it Edge servers started to think that contoso.com is an external domain and federation started to work.
Conclusion is that even if we removed the domain from topology we had to remove the domain from the certificates.