About Me

My Photo
TsooRad is a blog for John Weber. John is a Lync Server MVP (2010-2014). My day job is titled "Principal Consulting Engineer" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.

2013/03/01

Lync 2013 Mobility Push Notifications Failing

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.21

Non-authoritative answer:
_sipfederationtls._tcp.push.lync.com    SRV service location:
          priority       = 1
          weight         = 100
          port           = 5061
          svr hostname   = sipfed.online.lync.com

sipfed.online.lync.com  internet address = 132.245.113.21

Test-CSFederatedPartner –targetfqdn internalfqdnofedgepool.domain.com –domain push.lync.com

image

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:

image

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: