Continuing my set of instructions for installing Lync Mobility. Here we cover setting up our servers. My previous post covers certificates & the reverse proxy, Part 2 (how to update your servers) and Part 1 (configuring DNS)
Overview of changes
- Add two new DNS records – one internal, one external
- Either A records or C-Names
- Patch everything to Lync RTM CU4
- Define the “Internal ports” used for mobile clients
- Install mobility bits on Front-Ends & Directors
- Enable Dynamic compression in IIS
- Re-request certificates to support new mobile DNS names
- Configure your reverse proxy
- Configure push notifications
- Test! (Kinda)
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:
New-CsHostingProvider –Identity “LyncOnline” –Enabled $True –ProxyFqdn “sipfed.online.lync.com” –VerificationLevel UseSourceVerification
Next allow federation to the push service:
New-CsAllowedDomain –Identity “push.lync.com”
After allowing the change time to reach the edge server you can verify both settings by running the following:
Test-CsFederatedPartner –TargetFqdn <edge FQDN> –Domain push.lync.com –ProxyFqdn sipfed.online.lync.com
And
Test-CsMcxPushNotification –AccessEdgeFqdn <edgeFQDN>
(push notifications at MS’s end weren’t running yet! Hence my error)
Enable push notifications for users buy running the following commands
Set-CsPushNotificationConfiguration –EnableApplePushNotificationService $True –EnableMicrosoftPushNotificationService $True
And
Set-CSAccessEdgeConfiguration -AllowFederatedUsers $True
Note there is a typo in the documentation they missed out the “CS” part of the command
Testing
Until the mobile Lync clients get released you need to satisfy yourself by doing synthetic tests, luckily Microsoft provided a PowerShell command that lets you do this!
From a Lync management shell run the following:
Test-CsMcxP2PIM -TargetFqdn <FQDN of Front End pool> -SenderSipAddress sip:<SIP address of test user 1> -SenderCredential <test user 1 username> -ReceiverSipAddress sip:<SIP address of test user 2> -ReceiverCredential <test user 2 username> –v
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..
Ben.
Great instructions, thanks!
I did parts 1 & 2 and will be completing parts 3 & 4 today.
Is there any way to avoid adding new SAN names to SSL certificate?
For me it is a bit hassle to re-do certificate as I need approval from domain registrators every time.
Thanks!
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…
Thanks,
Ben.
Hi,
I get this when testing – pls help:
PS C:\Users\admin> Test-CsMcxP2PIM -TargetFqdn lyncedgepool1.dom.dk -SenderSipAd
dress sip:ten@hef.dk -SenderCredential ten@dom . dk -ReceiverSipAddress sip:powert
est@ dom.dk -ReceiverCredential powertest@dom . dk -v
VERBOSE: Workflow Instance Id b54d172f-da2f-49e3-87ba-b9f0e44fcc78, started.
TargetUri :
TargetFqdn : lyncedgepool1.dom.dk
Result : Failure
Latency : 00:00:00
Error : Unknown error (0x80131500)
Inner Exception:Peer disconnected while outbound capabilities nego
tiation was in progress
Inner Exception:An existing connection was forcibly closed by the
remote host
Diagnosis :
VERBOSE: ‘STActivity’ activity started.
Starting STS Uri Discovery…
ERROR getting STS Uri.
‘STActivity’ activity started.
Starting STS Uri Discovery…
ERROR getting STS Uri.
An exception ‘Unknown error (0x80131500)’ occurred during Workflow
Microsoft.Rtc.SyntheticTransactions.Workflows.STMcxP2PImWorkflow execution.
Exception Call Stack: at
Microsoft.Rtc.Signaling.SipAsyncResult`1.ThrowIfFailed()
at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner,
IAsyncResult result)
at Microsoft.Rtc.Collaboration.LocalEndpoint.EndEstablish(IAsyncResult
result)
at
Microsoft.Rtc.SyntheticTransactions.Activities.GetSTSUriActivity.InternalExecut
e(ActivityExecutionContext executionContext)
at
Microsoft.Rtc.SyntheticTransactions.Activities.STActivity.Execute(ActivityExecu
tionContext executionContext)
at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity,
ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.CompositeActivityExecutor`1.Execute(T
activity, ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(Activity
activity, ActivityExecutionContext executionContext)
at
System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRunti
me workflowCoreRuntime)
at System.Workflow.Runtime.Scheduler.Run()
‘McxTermiateSession’ activity started.
‘McxTermiateSession’ activity completed in ‘1,4E-06’ secs.
VERBOSE: Workflow Instance Id b54d172f-da2f-49e3-87ba-b9f0e44fcc78, completed.
VERBOSE: Workflow Execution Time (sec): 0.1021956
Thomas
Hi Thomas,
I’ve sanitized your comment slightly to remove references to your domain & to stop the email addresses becoming mail links.
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
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.”
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
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
In my case I have verified that the 5061 is not being blocked outbound. So far I haven’t found a solution.
It might be because of the certificate your using for edge? Have a look here http://social.technet.microsoft.com/Forums/en-US/ocsmobility/thread/d26a244b-83b4-449e-a17e-c2f1def5ae23
Are you able to federate with any other orgs?
Ben.
Hi Ben, Thanks for your feedback.
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:
http://social.microsoft.com/Forums/en-US/partnermsglcs/thread/90b318cf-fb90-4908-a587-8d0734228249
Cheers
Warren
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 🙁
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
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
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!!!!
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
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.
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.
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.
Here was our problem:
PS C:\Users\xxxxxxx> Get-CsAllowedDomain
Identity : push.lync.com
Domain : push.lync.com
ProxyFqdn : lyncedge.xxxxxx.com
Comment :
MarkForMonitoring : False
ProxyFQDN should be empty (null).
Solution:
PS C:\Users\xxxxxxx> Set-CsAllowedDomain -Identity push.lync.com -proxyfqdn $null
PS C:\Users\xxxxxxx> Get-CsAllowedDomain
Identity : push.lync.com
Domain : push.lync.com
ProxyFqdn :
Comment :
MarkForMonitoring : False
I had the same problem. It was caused by a firewall problem -not letting outbound 5061 traffic.
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
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.
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
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
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
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.
What should I do?