In a recent deployment, my Apple mobility push notifications were not working. The mobile client itself worked, but when the client was moved to the background, the push notifications from the Lync FE pool were not working – in this case, the iPad and iPhone clients never got notified.
Scenario
Greenfield install of Lync 2013 with an Edge (duh). No O365, only dial-in conferencing for a PBX touch. Only one SIP domain, split-DNS, all required SRV and A records are in place. Remote logins are normal, full workloads across the edge and reverse proxy are fully functional. All internal workloads are normal. Just the mobility push via sipfed.online.lync.com were failing. The actual iOS clients were able to send and receive IM (along with AB and contacts lists were good). Just that when the client was not foreground the notifications did not work.
Troubleshooting
To start, I did a review of “how to” setup push notifications and how to test. Needless to say, I ran around this process about 12 times to no avail.
I had missed doing the allowed federation domain of push.lync.com (I had a typo – ooops!) – fixed that. Nada.
The SIP Federated Providers tab already had a hosted provider of LyncOnline with edge server of sipfed.online.lync.com listed. I enabled that, no joy.
Things I verified:
Resolution of _sipfederationtls._tcp.push.lync.com to A record of sipfed.online.lync.com.
> set type=srv
> _sipfederationtls._tcp.push.lync.com
Server: wingdc301.wingspan.local
Address: 10.1.1.21Non-authoritative answer:
_sipfederationtls._tcp.push.lync.com SRV service location:
priority = 1
weight = 100
port = 5061
svr hostname = sipfed.online.lync.comsipfed.online.lync.com internet address = 132.245.113.21
Test-CSFederatedPartner –targetfqdn internalfqdnofedgepool.domain.com –domain push.lync.com
Test-CSMCXPushNotification –AccessEdgeFQDN internalfqdnofedgepool.domain.com – this failed with “Work flow failed validation” – I will observe that this message was less than helpful. University of Google/Bing gave me nothing useful on this.
The Fix
So I went back through the entire mess again. Followed the instructions line by line. Still failing. OK. On to OCSLogger (I know, I should have used Centralized Logging) and Snooper on the edge. I picked the edge because the federatedPartner test was good (see above). My reasoning was that if the first step of the testing process was good, something between me and sipfed.online.lync.com was wrong still wrong, and that connection was the edge, so look there first. What I got was this:
Lovely, eh wot? Again, U of G/B did not help. So I started casting about for those off-topic solutions that are so wonderful to stumble across. I found this. Not quite the exact problem and not quite the exact answer, but still, a nice clue. What I got out of this was to recreate the CSHostingProvider “LyncOnline”
Why? Because that provider was already deployed out of the box. I did not need it; yet there is was, disabled. I had enabled it earlier (following instructions, remember?) – now I went through this KB and removed it entirely and remade it.
And not being to patient, while I was at it, I threw February 2013 Cumulative Update into the FE layer and the Edge layer. Rebooted the entire mess.
Success! My problem, of course, is I don’t know if recreating the CSHostingProvider LyncOnline or the CU1 that actually solved the issue; but I do know that I did both, and now the situation is resolved.
YMMV.
No comments:
Post a Comment