Dec 10, 2011

Posted by in Tech Tips | 26 Comments

Configuring Lync Mobility – Part 4

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 “” –VerificationLevel UseSourceVerification

Next allow federation to the push service:

New-CsAllowedDomain –Identity “”


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 –ProxyFqdn


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


Set-CSAccessEdgeConfiguration -AllowFederatedUsers $True

Note there is a typo in the documentation they missed out the “CS” part of the command



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


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


  2. 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…


  3. Thomas Starup says:

    I get this when testing – pls help:
    PS C:\Users\admin> Test-CsMcxP2PIM -TargetFqdn -SenderSipAd
    dress -SenderCredential ten@dom . dk -ReceiverSipAddress sip:powert
    est@ -ReceiverCredential powertest@dom . dk -v
    VERBOSE: Workflow Instance Id b54d172f-da2f-49e3-87ba-b9f0e44fcc78, started.

    TargetUri :
    TargetFqdn :
    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
    at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner,
    IAsyncResult result)
    at Microsoft.Rtc.Collaboration.LocalEndpoint.EndEstablish(IAsyncResult
    e(ActivityExecutionContext executionContext)
    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)
    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


  4. 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)?


  5. 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.”

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


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


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

  9. It might be because of the certificate your using for edge? Have a look here

    Are you able to federate with any other orgs?

  10. 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:



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

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

    I too am using 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

    I’ll keep you posted on what happens

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


  14. 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!!!!

  15. 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?


  16. 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 with a weight/priority of 1.

    We’re at a loss on this one.

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

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

  19. Here was our problem:

    PS C:\Users\xxxxxxx> Get-CsAllowedDomain

    Identity :
    Domain :
    ProxyFqdn :
    Comment :
    MarkForMonitoring : False

    ProxyFQDN should be empty (null).


    PS C:\Users\xxxxxxx> Set-CsAllowedDomain -Identity -proxyfqdn $null
    PS C:\Users\xxxxxxx> Get-CsAllowedDomain

    Identity :
    Domain :
    ProxyFqdn :
    Comment :
    MarkForMonitoring : False

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

  21. UC_Newbie says:

    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

  22. Alex Medina says:

    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.

  23. 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?


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


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


  26. 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?

Leave a Reply

Your email address will not be published. Required fields are marked *