Configure push notification support

Push notification is supported for Apple devices and Windows Phone 7. Rather than your edge server directly sending notifications to either Apple or the WP7 notification services Microsoft have implemented quite a clever solution.

You need to setup a connection to Microsoft’s hosted Lync platform & then allow federation with Microsoft’s push notification service which then sends out the notifications to the Apple and WP7 services on your behalf.

Setting this up is a two stage process. If you haven’t setup federation with Lync online before running the following command from a Lync management shell:

When you run the command you’ll get two windows authentication boxes in which you can enter your sets of credentials

If you scroll the window back up a bit just before all the yellow text you should hopefully see a successful result & no reported errors!

*Phew* that was a long set of things to post but I hope that was useful to a few of you Lync folk out there. If you’ve got any comments or questions please drop me a note in the box below. It might look complex but its not that bad really! Honest..

26 Comments

For me it is a bit hassle to re-do certificate as I need approval from domain registrators every time.

Thanks!

Ben Lee
on December 12, 2011 at 10:48 am

Hello Alex,
Thanks for the comment, yes I believe you can get away without re-issuing your certificates. The new domain – Lyncdiscover & Lyncsdiscoverinternal are used only as pointers to find the rest of the lync information. The client will then re-connect to the proper lync reverse proxy URL to carry out the conversation. Try using a CNAME for your discover records that then resolves to the lyncRP name.

Also have a look at page 7 from the official LS_Mobility document (Linked from post 1), its not perfectly clear but checkout page 30 as well for how to setup the HTTP publishing rule on your RP.

If you have any other sticking points with it let me know and I could try and lab it out or help…

Is the FQDN of your pool definitely correct? Also is it right that you Active Directory FQDN is the public name (i.e same as your sip addresses)?

Ben

Mike
on December 13, 2011 at 2:20 am

Have you seen any troubleshooting information online yet? I’m getting an error code that so far I can’t find anything online about yet.

After following your guide and testing with the “Test-CsFederatedPartner” command and received the error below. I also get a similar error running the “Test-CsMcxPushNotification” command.

I know my edge server is running (I’m connected through it and chatting with coworkers with the full and mobile client) so I think I’ll try a restart of services at some point also while I scour the Google machine.

“Test-CsFederatedPartner : A 504 (Server time-out) response was received from the network and the operation failed. See the exception details for more information.”

Warren
on December 16, 2011 at 10:10 pm

Hi Mike, I’m getting exactly the same problem. Did you ever find a resolution?

Could anyone explain what the data flow would be with Push Notifications? I’m wondering if I have an issue with firewalls / hardening / DNS etc, but I’m not sure how to proceed with troubleshooting.
Any other suggestions for assisting with this issue would be most appreciated.

Warren

Ben Lee
on December 17, 2011 at 7:48 am

Hello,
Are you able to federate with any external organisations?
The traffic flow for push is treated like a federated organisation (hence the first bit of config – thats what we’re setting up) so the traffic is 5061 outbound from your edge server. The MS servers then deal with creating the push notifications either via Apple or the WP7 service.

If you want to test federation I can provide you with my SIP address & we can do some live troubleshooting?

Ben

Mike
on December 20, 2011 at 1:41 am

In my case I have verified that the 5061 is not being blocked outbound. So far I haven’t found a solution.

I had checked my Edge server for 36882 errors and do not have any of these errors in the event log.
I’ve never tried to set up and federation before, so I’m not sure if there are some pre-requisites that I may have needed before attempting this.

I’ve raised an online assistance request with MS on this as well, so I’ll be sure to update this thread if I find the root cause of my issue. Link to the MS thread is here:

Hi warren i had read your ms case post, cause i’ve the same issue.
One things make me afraid what is the ‘acces.contoso.com’ on CN name for public certificate?! My CN is equal to my sip.contoso.com in my certificate. It’s can be my problem? or it’s only a best practise, cause never the lync assistant generate an ‘acces.contoso.com’, alway in ‘sip.contoso.com’. It’s my first federation test too 🙁

Warren
on December 23, 2011 at 12:05 pm

Hi Yan, yes, my set up is the same by the sound of things.

I too am using sip.kainos.com as my external FQDN name for SIP access.

If I remember correctly this was defined during the topology builder configuration stage right at the start of installing Lync, and at no time was there any mention that the SIP access FQDN could NOT be sip.domain.com.

I’ll keep you posted on what happens

Warren
on January 7, 2012 at 11:46 pm

Hi everyone, figured out what was causing the issue with my push notifications.
As I had not intended on using federation I hadn’t bothered to set up any federation related DNS. Turns out that the external _sipfederationtls._tcp.domain.com SRV record is required for federation and also therefore push notifications.

I had also made another change, which I’m unsure whether or not is necessary. Within Topology builder, under the properties of your site you will find a site federation route assignment. I have set this to my Edge pool.

I hope that this information my be useful for others.

Thank you all for your help with this investigation.

Warren

Troy
on January 26, 2012 at 8:57 pm

We are getting the following error:

Test-CsFederatedPartner : A 504 (Server time-out) response was received from the network and the operation failed. See the exception details for more information.

Our phones can connect, our certificates are valid, and all external edge applications appear to work perfectly. DNS is not an issue (we’ve setup ALL possible DNS records required by Lync). The only name missing from our SAN certificate is the INTERNAL name of our edge server/pool, is this our issue? We are also using an internal CA certificate for “Edge Internal”.

Any help would be greatly appreciated!!!!

Ben Lee
on January 27, 2012 at 12:40 pm

Hello,
The SAN cert wont need the internal name so that doesn’t sound like your issue. Have you been able to federate with any other organisations at all before?

Ben

Troy
on January 27, 2012 at 2:58 pm

Hey Ben,

Thanks for the reply. We went ahead and put a cheap single name certificate on the internal interface just to try something out, but it did not solve our issues.

We are not federated with any other organisations. At the moment, _sipfederationtls points to sip.ourdomain.com:5061 with a weight/priority of 1.

We’re at a loss on this one.

Warren
on January 27, 2012 at 4:57 pm

I’d suggest installing a packet sniffer on to your edge box (I used Microsoft Network Monitor 3.4 as this step was recommended to be through Microsoft support).

Run a packet scan while executing your Test-CsFederatedPartner cmdlet and then trawl through the logs.

The problem that I had with the lack of SRV stuck out like a sore thumb, and although yours is obviously something different, hopefully your problem will become clear too.

Troy
on January 27, 2012 at 5:44 pm

We’ve made some head way, but our issue continues.

While running wireshark, the Test-CsFederatedPartner command successfully made a TLS handshake with Microsoft, and beyond that I couldn’t see any of the data (obviously). Then our command fails, and our push notifications still don’t work.

Perhaps we’re to the point of calling MS, as I seem to have exhausted Google lol.

I had the same problem. It was caused by a firewall problem -not letting outbound 5061 traffic.

UC_Newbie
on March 7, 2012 at 2:46 pm

Hi Ben,

I have got mobility working perfectly following your guide!!… all except push notification 🙁

I am getting the 504 error.

If I provide you with my federation details can we do some tests?

thanks in advance

Alex Medina
on October 2, 2012 at 2:31 pm

Hello Ben,

I’m having the same problem that Thomas had with the same Error
(0x80131500) Did you help Thomas resolve this problem? I didnt see any additional references to this. Please let me know if you can help.

Ben Lee
on October 2, 2012 at 10:21 pm

Hi Alex,
Drop me your SIP URI via the “about” page email address assuming you have federated Lync setup? I could spend some time having a look through it with you?

Ben

Ross
on November 7, 2012 at 11:22 am

Hey, I have finally (after lot’s of issues) got Lync working on all IOS and Android devices, federation to push.lync.com finally works but the test push command comes back with push notification was rejected 30008, I have had this successful once before. Any idea?

Thanks
Ross

Ross
on November 7, 2012 at 11:49 am

I have resolved. Strange issue… as stated above was receiving 3008 on testing push notifications. The last step to get them to work was opening the Lync Topology, highlighting the very top site and going to edit, enable Federation route assignment and publish topology.

This still failed on testing push notifications in powershell but then worked (once) on the mobile app. It then signed me out of Lync and wouldn’t sign back in!

Browsing from external to https:///mcx/mcxservice.svc/mex showed an expection error, I had to rerun the Define the “Internal ports” used for mobile clients section, browsed again to the above link and the XML showed as it should.

After all that I can now successfully log in to Lync and receive notifications everytime. Test-CsMcxPushNotification –AccessEdgeFqdn however still returns an error.

Thanks
Ross

enod
on June 25, 2013 at 2:56 pm

When I run Test-csMcxP2PIM command,

result: failure
error mesage: The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (test/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly.