After completing a Lync Server 2013 install I got some feedback that federation with Office 365/Lync Online users wasn’t working properly. On the other hand, federation with other Lync-enabled organisations was ok. Some of the symptoms, that I also verified using my own Lync Online account, were:
- On-premise users could see Lync Online users’ presence, and initiate IM
- Lync Online users could NOT see on-premise users’ presence, NOR could they initiate IM (message would time out with error message)
- Once IM was initiated from on-premise user to Online user, all modalities would work (although presence would take some time to update)
The only references I came across searching for an answer, were all related to federation problems FROM on-premise TO the Online users. Also, since I did have one-way Federation, it would appear that the External Access setup including Hosting Provider setup for Lync Online and Edge configuration to allow such federation was in place.
Troubleshooting the issue by logging the on-premise environment turned out empty, with no reference to a possible solution. Logging from the other end is not possible, so the only thing I was left with was client-side log from the user on the Lync Online account. Looking for something to point me in the right direction, I notice the following log entry:
ms-diagnostics: 1046;reason="Failed to connect to a federated peer server";
fqdn="sip.contoso.com:5061";ip-address="[2001:XXXX:XXXX:XXXX::93:216]";
peer-type="FederatedPartner";winsock-code="10060";
winsock-info="The peer did not respond to the connection attempt";source="sipfed0E.online.lync.com"
Seems like the Lync Online solution was actually trying to get the federation traffic going on IPv6. This is probably something Microsoft have prepared for in the event of a future Lync Server 2013 Online service (??), and a feature that is not shared by other Lync Server 2010 on-premise or hosted – and which is why that federation would still work. The IPv6 reference on the on-premise server was something originally designed and implemented, but later disabled in both Lync and server OS due to various problems I was facing during the install (example: registry IPv6 disable):
The end to this story was to remove all AAAA records in external DNS, since some providers will actually try and route traffic via IPv6, whenever possible.
After the IPv6 records were gone, federation with Lync Online users works from both ends.
Rune's blog about things I see and UC 
Rune’s blog: Lync Server 2013 one-way federation with Lync Online « Lync News
Februar Blog artikler fra Atea konsulenter – LyncAtea.no
Hello. Great article.
But I have one question:
After doing this, we are able to communicate with Lync Online users, but only from our default domain!
We have hundreds of domains, that are constantly changing, so, managing all of them with certificates is out of the question.
This way, we use a single common Edge Server with all the DNS entries needed for it to work. And it is working with everybody (skype included) except LyncOnline users.
All the remote Lync Administrators needs to specify is our “Edge Server” and “Lync Domain”.
I have never seen LyncOnline, so I’m asking You if it supports manually adding a domain with a different Edge Server, as we do it on an On-Premises Lync Server?
Thanks in Advance
Rui Araújo
Hi Rui.
Looks like you are running a Lync Hosting provider service by the sound of it. The Company I work With also offers this, although I am not the one running that operation I am quite familiar With how it Works.
Like you say; when hosting several SIP domains, for which you do not have a valid SSL certificate, the federation partners can still enable the trust that Lync requires by
1) Trusting ALL the domains hosted by the same provider, through the New-CsHostingProvider cmdlet (or using Control Panel)
2) Trusting each separate domain, through the New-CsAllowedDomain cmdlet (or using Control Panel)
Lync Online Works the same way, and since they do not (obviously) have a certificate for each domain they are hosting is the reason you have to define Lync Online as a Hosting Provider and trust all the domain residing behind their proxy.
Unfortunately Lync Online does not have the same kind of flexibility when it comes to trusting Hosted domains, and only offers a simple GUI that will either let you federate- or not (With the possibility of white- or blacklisting domains).
Hopefully they will allow for more flexibility and configuration, and even Remote Powershell configuration.
Best regards,
Rune
Hi again, Rui.
I just had a chat With my colleague who runs the Hosting environment, and he told me that With Lync Server 2013 it is now possible to have Microsoft set the Lync Online service up so that domains using the cloud service can actually trust all domains in Our (or Your) end – how cool is that? 🙂
Contact Microsoft for details about how to enable this.
Brgds,
Rune
Hello, Rune.
Thank you very much for your time. It’s really great news.
I’m just afraid that your colleagues are referring to Lync Multitenant Pack, which require extra licensing.
Although our needs are similar to a Hosting provider, we’re not one, because we don’t make a business out of it. Our Business Group owns, buys and sells lots of small companies which require their own SIP Domain, but the total number of users never reaches 200. So, we’ll never get a budget for this from our board.
I’m really hoping that it’s some other new feature.
I’m contacting Microsoft soon.
I’ll post back 🙂
Again, thank you for your help,
Rui Araújo