Step-by-step Microsoft Lync 2010 Lync Mobility (MCX) Installation Guide

December 9th, 2011 | Tags: , ,

So the waiting (as of writing) is almost over and the server-side bits for shiny new Lync Mobility Service (MCX) have been released!

The client-side bits are likely to be released next week and in the meantime there is nothing stopping you from prepping your Lync Servers. All clients have been released and can be downloaded via your Smartphone’s respective AppStore/Marketplace etc…

For those that are keen to get this up and running quickly, I have put together a short step-by-step guide, for official Microsoft documentation head here. I will however caveat one minor thing at this early stage, with the clients still unreleased this guide is still very much in beta! 😀 With all clients RTW’d this guide is officially v.1.0 🙂

Configuration of Lync Mobility Autodiscover Records

First up you’ll need to create the internal (lyncdiscoverinternal.<SIPFQDN>) and external (lyncdiscover.<SIPFQDN>) MCX discovery records, mine can be seen below:

As this is being configured within a test lab environment my internal discovery DNS is pointed at my Lync Standard Edition Server, for a larger deployment this is likely to be your Front End Pool or Director.

I have also configured the external discovery record, which can be verified using NSLOOKUP (see below). This is pointed toward the external listener address of my TMG reverse proxy.

Next we need to ensure that the November Lync Cumulative Update  (CU4) is installed – see more on this here, once this is complete we need to open up some internal MCX ports via the Lync management shell.

First the internal listening port: (my Lync Front End is lyncserver.jacobs.local, you will need to substitute this for your own front end/pool/director name)

Set-CsWebServer –Identity lyncserver.jacobs.local -McxSipPrimaryListeningPort 5086

Second the external listening port: (as stated in the prior step, my Lync Front End is lyncserver.jacobs.local, you will need to substitute this for your own front end/pool/director name)

Set-CsWebServer –Identity lyncserver.jacobs.local -McxSipExternalListeningPort 5087

Finally you will need to enable the topology, within the same shell type:

Enable-CsTopology –verbose

MCX Service Installation

Now we’re ready to install the MCX server components, this can be downloaded here. Before you can run the installation a few changes need to be made to IIS.

Within the Lync management shell run, ensure shell is run as admin if UAC is enabled (Windows Server 2008 R2):

Import-Module ServerManager
Add-WindowsFeature Web-Server, Web-Dyn-Compression

Or the following within the Windows command line, ensure command is run as admin if UAC is enabled (for Windows Server 2008):

ServerManagerCMD.exe –Install Web-Dyn-Compression

One complete you will be presented with the following

If you are running Window Server 2008 (IIS7.0) then you need to make a minor ASP.Net change (follow Microsoft procedure included below) – I’m running Windows Server 2008 R2 (IIS7.5) so I skipped this.

To change ASP.NET settings in IIS 7.0

1.   Log on to the server as a local administrator.2.   Use a text editor such as Notepad to open the applicationHost.config file, located at C:\Windows\System32\inetsrv\config\applicationHost.config.3.   Search for the following:<Add name=”CSExtMcxAppPool”4.   At the end of the line, before the ending angle bracket (>), type the following:CLRConfigFile=”C:\Program Files\Microsoft Lync Server 2010\Web Components\Mcx\Ext\Aspnet_mcx.config”5.   Search for the following:<Add name=”CSIntMcxAppPool”6.   At the end of the line, before the ending angle bracket (>), type the following:CLRConfigFile=”C:\Program Files\Microsoft Lync Server 2010\Web Components\Mcx\Int\Aspnet_mcx.config”

Now we’re ready to run the MCXStandalone.msi

First you’ll need to copy the McxStandalone.msi to C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup, then execute C:\Program Files\Microsoft Lync Server
2010\Deployment\Bootstrapper.exe

During the installation you will be presented with “Installing MCXStandalone…” (see below)

Certificate Update

Now we need to update our internal SAN certificate, this needs to include the newly created lyncdiscoverinternal
record our internal certificates and first up we have to find the correct certificate identifier or thumbprint for this to be completed successfully. To display all certificates type the following within the Lync Management Shell:

Get-CsCertificate

This will return all certificates and their corresponding thumbprints, in my case all certificates are the same, so I can run the following command to update the cert for all uses.

Set-CsCertificate –Type Default,WebServicesInternal,WebServicesExternal –Thumbprint <Certificate Thumbprint>

During this process I was presented with a warning, upon further investigation neither Lync Discovery addresses were within my internal or external SAN certificates. To re-generate, I ran the following command within the Lync Management Shell

The easiest method for re-generating certificates is by re-running the Lync Deployment Wizard, going to Install or Update Lync Server System and executing Step 3 Request, Install or Assign Certificates

For more information on this the Microsoft MCX deployment guide details alternate certificate scenarios i.e. where you have a unique cert per usage type, refer to the section – Modifying Certificates for Mobility

 

Forefront TMG Configuration for Lync Mobility

There are two approaches here, one uses SSL for setup the other does not. The main reason for allowing a re-direction from port 80 (http) to 443 (https) is to avoid the need of replacing your existing SAN.

The recommended approach is to only permit the Lync mobility client to communicate on port 443, so I replaced the certificate within my existing Lync web listener within Forefront TMG – so we’re going to run you through this setup below (you could also add the additional public name “lyncdiscover.SIPFQDN” to an existing Lync website rule, but I’m going to run through this as an independent rule).

First we need to create the new web publishing rule (see below)

Give it a name (see below)

Select Allow (see below)

Select Publish to a single Web site or load balancer (see below)

Select Use SSL to connect to the published web server or server farm (see below)

Specify your internal site name, this will be the name of your Front End Pool (see below)

Path should be “/*” and select the check box for Forwarding the original host header (see below)

Add the public lyncdiscover address (see below)

Select your existing Lync web listener, with the new SAN certificate that now includes the lyncdiscover address. Select No delegation, but client may authenticate directly (see below)

Finally allow requests from All Users and Finish

You will now need to go into your newly created web publishing rule and go to the to tab, in the section Proxy requests to published site, ensure that Requests appear to come from Forefront is checked for a single Front End server or Standard Edition server. Alternatively select Requests come from the original client if you have a Front End Pool (see below) This statement is incorrect, and unlike the single Front End server scenario was not tested directly and was taken directly from the official documentation – in both scenarios requests should appear to come from TMG.

Finally go to the Bridging tab and change the default ports from 80 -> 8080 and 443 -> 4443 (this is the external web site on your Lync Front End). Once complete ensure you apply the new rules.

Your TMG rule is complete!

Push Notifications Configuration

Push notifications are handled by Microsoft Office 365 or Lync Online, so you need to have federation deployed and run the Set-CsPushNotificationConfiguration cmd-let

First let’s enable push notifications within the Lync Management Shell by running:

Set-CsPushNotificationConfiguration

Next we should enable federation with Office 365 (if not completed already), within the Lync Management Shell type: (this will add a new Hosted Provider)

New-CsHostingProvider –Identity "LyncOnline" –Enabled $True –ProxyFqdn "sipfed.online.lync.com" –VerificationLevel UseSourceVerification

Then add the Lync Push federated domain type:

New-CsAllowedDomain –Identity "push.lync.com"

That’s it!

  1. Anonymous
    December 9th, 2011 at 23:08
    Reply | Quote | #1

    Requests appear to come from should always be from TMG so you only have to open the firewall from the TMG Server to the Front End Server. If it appeared to come from the client, the firewall would have to be opened to allow all client IPs.

    Also, what you should be doing is Cookie Persistence on the HLB for web services so Cookie Persistence would take care of it going to the correct FE for each session.

  2. Adam [I’m a UC Blog]
    December 9th, 2011 at 23:25
    Reply | Quote | #2

    Hi Anonymous,

    In the past I have always set TMG to requests appear to come from TMG, but the MS documentation documents the other scenario for FE pools.

    – Adam

  3. Stephan
    December 10th, 2011 at 01:57
    Reply | Quote | #3

    I ran it against the internal FQDN, and now I get the following error:

    Test-CsMcxPushNotification : A 500 (The server encountered an unexpected intern
    al error) response was received from the network and the operation failed. See
    the exception details for more information.
    At line:1 char:27
    + Test-CsMcxPushNotification <<<< -AccessEdgeFqdn hqlyncedge.mydomain.com -v
    erbose
    + CategoryInfo : OperationStopped: (:) [Test-CsMcxPushNotificatio
    n], FailureResponseException
    + FullyQualifiedErrorId : WorkflowNotCompleted,Microsoft.Rtc.Management.Sy
    ntheticTransactions.TestMcxPushNotificationCmdle

  4. Adam [I’m a UC Blog]
    December 10th, 2011 at 10:31
    Reply | Quote | #4

    Hi Stephan,

    This has not yet been enabled, I skipped the testing steps for this reason. 🙂

    – Adam

  5. Jeff
    December 12th, 2011 at 12:11
    Reply | Quote | #5

    Hi Adam,

    tried to run this as a single command with UAC enabled and it failed.
    2 things to do to resolve,
    1. run PS as admin if UAC is on
    2. Break this into 2 commands Import-Module ServerManager Add-WindowsFeature Web-Server, Web-Dyn-Compression
    a. Import-Module ServerManager
    b. Add-WindowsFeature Web-Server, Web-Dyn-Compression

    Thanks again for your awesome work!.
    Jeff

  6. Adam [I’m a UC Blog]
    December 12th, 2011 at 13:00
    Reply | Quote | #6

    Thanks for the feedback Jeff, good find too. I have updated accordingly.

    – Adam

  7. Stephan
    December 12th, 2011 at 23:41
    Reply | Quote | #7

    Aparantly the 500 error I get is something others get as well, and push notifications do not work. See this post:

    http://social.technet.microsoft.com/Forums/ta/ocsmobility/thread/be46c2b6-6318-41ea-8ae6-780e621a9efe

  8. justin
    December 19th, 2011 at 07:21
    Reply | Quote | #8

    hi, thanks for the great guide. i am just starting out with networks and domains…etc. but perhaps someone can provide some clarity for me? is forefront supposed to be on the lync server; cause i ran into a whole host of problems with that?

    thanks.

  9. Adam [I’m a UC Blog]
    December 19th, 2011 at 08:38
    Reply | Quote | #9

    Hi Justin,

    Forefront is run on a separate server, typically placed on the perimeter of your network as it proxies traffic from the web to your internal network.

    – Adam

  10. Volesprit
    December 19th, 2011 at 16:23

    Hi!! Thanks for the topic i’ve followed all the steps but i’ve not tested the solution for the moment.

    Is it possible to only add lyncdiscover.mydomain.com on the lyncweb listener tab? Or i must create another listener?? And why?

    Thanks a lot!

  11. justin
    December 19th, 2011 at 17:06

    Adam [I’m a UC Blog] :Hi Justin,
    Forefront is run on a separate server, typically placed on the perimeter of your network as it proxies traffic from the web to your internal network.
    – Adam

    thanks Adam!

  12. Adam [I’m a UC Blog]
    December 19th, 2011 at 21:21

    Hi Volespirit

    My understanding is that you can use an existing HTTPS-to-Lync web services listener, although I am yet to test this. The documentation states an additional rule is required, this should only be needed for HTTP connections. i.e. No a necessity where your existing SAN cert is replaced with a new certificate that includes the lyncdiscover Autodiscover URL.

    I hope this helps?

    – Adam

  13. nbctcp
    December 22nd, 2011 at 01:09

    INFO:
    -Lync FE hostname: lync-01
    dns name: lync-01.domain.local
    -Lync EDGE hostname: im
    dns name: im.domain.com
    -TMG
    publishing for meeting, dialin and address book= meet.domain.com
    publishing for AV= im.domain.com

    thanks
    STATUS:
    -currently I can do video call, chat from lync client from both internal and internet

    PROBLEM:
    1. IOS and Android phone can’t login from internal or internet
    From result below, what I need to change so that I can access mobility service using https://meet.domain.com from internal and internet. How?

    # Get-CsService -PoolFqdn “lync-01.domain.local” -WebServer
    Identity : WebServer:lync-01.domain.local
    FileStore : FileStore:lync-01.domain.local
    UserServer : UserServer:lync-01.domain.local
    PrimaryHttpPort : 80
    PrimaryHttpsPort : 443
    ExternalHttpPort : 8080
    ExternalHttpsPort : 4443
    PublishedPrimaryHttpPort : 80
    PublishedPrimaryHttpsPort : 443
    PublishedExternalHttpPort : 80
    PublishedExternalHttpsPort : 443
    ReachPrimaryPsomServerPort : 8060
    ReachExternalPsomServerPort : 8061
    AppSharingPortStart : 49152
    AppSharingPortCount : 16383
    McxSipPrimaryListeningPort : 5086
    McxSipExternalListeningPort : 5087
    LIServiceInternalUri : https://lync-01.domain.local/locationinformation/liservice.svc
    ABHandlerInternalUri : https://lync-01.domain.local/abs/handler
    ABHandlerExternalUri : https://lync-01.domain.local/abs/handler
    DLExpansionInternalUri : https://lync-01.domain.local/groupexpansion/service.svc
    DLExpansionExternalUri : https://lync-01.domain.local/groupexpansion/service.svc
    CAHandlerInternalUri : https://lync-01.domain.local/CertProv/CertProvisioningService.svc
    CAHandlerInternalAnonUri : http://lync-01.domain.local/CertProv/CertProvisioningService.svc
    CollabContentInternalUri : https://lync-01.domain.local/CollabContent
    CollabContentExternalUri : https://lync-01.domain.local/CollabContent
    CAHandlerExternalUri : https://lync-01.domain.local/CertProv/CertProvisioningService.svc
    DeviceUpdateDownloadInternalUri : https://lync-01.domain.local/RequestHandler/ucdevice.upx
    DeviceUpdateDownloadExternalUri : https://lync-01.domain.local/RequestHandlerExt/ucdevice.upx
    DeviceUpdateStoreInternalUri : http://lync-01.domain.local/RequestHandler/Files
    DeviceUpdateStoreExternalUri : https://lync-01.domain.local/RequestHandlerExt/Files
    RgsAgentServiceInternalUri : https://lync-01.domain.local/RgsClients/AgentService.svc
    RgsAgentServiceExternalUri : https://lync-01.domain.local/RgsClients/AgentService.svc
    MeetExternalUri : https://lync-01.domain.local/Meet
    DialinExternalUri : https://lync-01.domain.local/Dialin
    CscpInternalUri : https://lync-01.domain.local/Cscp
    ReachExternalUri : https://lync-01.domain.local/Reach
    ReachInternalUri : https://lync-01.domain.local/Reach
    WebTicketExternalUri : https://lync-01.domain.local/WebTicket/WebTicketService.svc
    WebTicketInternalUri : https://lync-01.domain.local/WebTicket/WebTicketService.svc
    McxServiceExternalUri : https://lync-01.domain.local/Mcx/McxService.svc
    McxServiceInternalUri : https://lync-01.domain.local/Mcx/McxService.svc
    AutodiscoverServiceExternalUri : https://lync-01.domain.local/Autodiscover/AutodiscoverService.svc/root
    AutodiscoverServiceInternalUri : https://lync-01.domain.local/Autodiscover/AutodiscoverService.svc/root
    ExternalFqdn : lync-01.domain.local
    InternalFqdn :
    DependentServiceList : {ConferencingServer:lync-01.domain.local, Registrar:lync-01.domain.local}
    ServiceId : 1-WebServices-1
    SiteId : Site:Site0
    PoolFqdn : lync-01.domain.local
    Version : 5
    Role : WebServer

    thanks

  14. Adam [I’m a UC Blog]
    December 22nd, 2011 at 19:10

    Have you created both lyncdiscover and lyncdiscover A records within your SIP DNS zone? You public names within the TMG rule will also need to be updated to include this new URL

    – Adam

  15. nbctcp
    December 23rd, 2011 at 09:13

    My friend solved my problem.
    I need to install my self-signed cert using this apple utility
    http://support.apple.com/kb/DL1466
    Later I’ll test from internet

    thanks

  16. Adam [I’m a UC Blog]
    December 23rd, 2011 at 09:40

    Are you using a public cert? In my experience you can use a certificate provision via an Enterprise CA, provided that your root authority installed on your mobile device. This can be achieved by downloading the certificate and e-mailing directly to the device then executing.

    I hope this helps.

    – Adam

  17. nbctcp
    December 24th, 2011 at 05:58

    Adam,
    Just quick question.
    Currently I can’t login using iphone from internet.
    I didn’t check “Redirect requests to http port 8080”.

    QUESTIONS:
    1. should I check “Redirect requests to http port 8080”
    2. what TMG version are you using. Is it latest SP2

    thanks

  18. Adam [I’m a UC Blog]
    December 24th, 2011 at 09:56

    A1. You only need HTTP for un-encrypted setup i.e. where your SAN on your TMG listener does not include lyncdiscover.SIPFQDN
    A2. Latest version

    One other thing, if your SIP domain and logon domain don’t match then change your username within the iOS client to reflect this i.e. DOMAIN\Username

    Good luck!

    – Adam

  19. Joe
    December 29th, 2011 at 11:05

    Hi Adam.

    I encounter some problem when I try to publish new Lync_Discovery rule from TMG.

    My TMG is using single NIC configuration and is used to publish Exchange services now.

    When I try to create a new web listener for Lync, there is an error staying that: “A web listener specifying the same port and similar IP Addresses already used by the rule “Publish_OWA to External”. The port and IP addresses specified in a Web Listener cannot overlap with the IP addresses specified web listener already used in a different rule”

    Any idea how to overcome this?

    Thanks.

  20. Adam [I’m a UC Blog]
    December 29th, 2011 at 15:46

    Hi Joe,

    Yes there is a way around this (although I’m not sure if it is supported or not) – but from personal experience it works a treat!

    Create a single listener for both Lync and Exchange Web Services and assign a SAN certificate that incorporate both Lync and Exchange URLs.

    I’m thinking of writing a guide on this, anyone interested?

    – Adam

  21. Drew
    December 30th, 2011 at 13:24

    Does anyone know of a tool that you can run that will check in the Lync topology and then match it up with what is in your internal and external DNS? My DNS as far as Lync is concerned is a total mess. Or can someone tell me how to figure out what all I need to have in my DNS servers for Lync?

    I’m just running a Standard edition server and currently on Windows clients if I tell it to auto detect the server it fails but if I enter the FQDN of my lync server it connects for IM.

  22. Doug
    December 30th, 2011 at 14:41

    Hello,
    Thanks for this guide but I’m still pretty lost as to why I can’t get Lync to sign in on a mobile device (testing with Win Phone 7 and iPhone). I’ve made my DNS records and followed the steps in this guide too, still no luck. Why is this so complicated?

  23. Adam [I’m a UC Blog]
    December 30th, 2011 at 19:29

    Hi Drew,

    For external DNS validation the “Remote Connectivity Analyzer” should suffice. Internally you will need lyncdiscoverinternal.sipfqdn (for mobile) and dialin/meet/admin URLs (for existing Lync web services). If you need more assistance you will need to provide more background info 🙂

    – Adam

  24. Adam [I’m a UC Blog]
    January 1st, 2012 at 12:40

    Hi Doug,

    Don’t give up! 🙂 Start on internal access first, can you ping the lyncdiscoverinternal A record? Does it resolve to your Lync FE? Has your certificate been updated t include this new URL? Does your SIP sign-in name match you AD username? (if not then update the “username field” with DOMAIN\Username

    Let me know how you get on?

    – Adam

  25. January 9th, 2012 at 06:06

    Hi there I have followed through with all the instructions to install the mobility updates, created DNS records – our setup is a single FE server a singe Edge Server and a ForeFront proxy. When I run the

    $passwd1 = ConvertTo-SecureString “#####” -AsPlainText -Force
    $tuc1 = New-Object Management.Automation.PSCredential(“#####”, $passwd1)
    $passwd2 = ConvertTo-SecureString “#####” -AsPlainText -Force
    $tuc2 = New-Object Management.Automation.PSCredential(“#####”, $passwd2)
    Test-CsMcxP2PIM -TargetFqdn ##### -SenderSipAddress sip:#####-SenderCredential $tuc1 -ReceiverSipAddress sip:##### -ReceiverCredential $tuc2 -v

    Test commands on the FE server I get the following error:

    Result: Failure
    Error: ERROR – No response received for Web-Ticket service. Inner Exception: The HTTP request is unauthorised with client authentication scheme ‘Ntlm’. The authentication header received from the server was ‘NTLM’. Inner Exception: The remote server returned an error: Unauthorized.

    Then there is a fairly long log trail with the most usefull piece being after completing the STAActivity activity completed – then it goes to “Trying to get a web ticket”. Using NTLM\Kerb auth – could not get a web ticket.

    No response received for Web-Ticket service – occurred during workflow.

  26. Adam [I’m a UC Blog]
    January 9th, 2012 at 20:53

    Hi Steve,

    Have you tried logging in via the mobile client – if it fails the logs provide a good source for troubleshooting.

    Let me know how you get on?

    – Adam

  27. Jackseth
    January 10th, 2012 at 17:55

    With respect to CU4 server patches be sure to download the December version. Microsoft released an updated CU4 on December 13 which includes additonal hotfixes. If you have already applied the November version, reapply the newer release.

  28. Adam [I’m a UC Blog]
    January 10th, 2012 at 19:36

    So far as I am aware this is only an update to the UcmaWorkflowRuntime.msp – which does not impact upon MCX. Unless you know something I don’t? 🙂

    – Adam

  29. January 11th, 2012 at 05:23

    Hi Adam – I resolved the issue with the test script in the meantime (one of the user accounts I was using had insufficient permissions). We can now connect internally with IOS and Android clients – autodiscovery is working here. On the outside – autodiscover urls are working (tested with browser) – but when I attempt to connect with the Android phone from the outside of our network – I get the message “an unknown error occurred”.. which is rather annoying. I have turned on diagnostics – but don’t know how to get the log from the android app..Will try this with the iphone version..

  30. Adam [I’m a UC Blog]
    January 11th, 2012 at 19:31

    Hi Steve,

    Glad to hear you are making some progress. I have not tried the Android client (only iOS and WP7). On the iPhone client enable logging and then choose the option to send logs via e-mail. I have seen issues when the iOS client worked, yet not WP7 – this is usually due to a difference in device DNS caching behaviour. Chances are you still have an underlying issue, let me know how you get on.

    – Adam

  31. January 11th, 2012 at 23:23

    Thanks Adam – I reviewed the log file from the IOS client and realised that one of services was not published correctly on the outside i.e. the MCX service is working internally but not externally. I have now changed the DNS record – but have to wait for it to propagate around the net for the phone to pick up the corrected DNS record to be able to reach the MCX service. I am hopeful that this is the last remaining issue to get the external phones connected. Thanks for helping – much obliged.

  32. January 12th, 2012 at 02:08

    Hi Adam again – the DNS change has propagated and we now have internal and external mobile clients up and running. When a client connects externally only chat works – calling does not – which I assume has something to do with the policy..? Can you point me in the right direction as to what needs to be changed to fix this..?

    thanks

    Steve

  33. January 12th, 2012 at 05:41

    We can get android devices online internally (attached to our own Wifi), but iOS devices required having the cert installed. No useful error, just the same one that says check your username and password… not the one that says the server can’t be found (these are the only two errors I’ve seen thus far). We resolved that for iOS devices by mailing ourselves our (self issued) cert and installing it on the iOS device, then trying to reconnect and it let us right in.

    I’m still fumbling around with external access tonight, will be going over this page with a fine tooth comb against our configuration tomorrow a.m. and will report back with any success/fail.

  34. Adam [I’m a UC Blog]
    January 12th, 2012 at 19:53

    Hi Steve,

    Call-via-work requires:

    – iPhone or WP7 Clients
    – Users enabled for Enterprise Voice
    – Enabled within mobility policy (it is enabled by default) to re-enable type the following within the Lync Shell “Set-CsMobilityPolicy –EnableMobility $True” –EnableOutsideVoice $True – be aware this is a global command.

    I hope this helps!

    – Adam

  35. Adam [I’m a UC Blog]
    January 12th, 2012 at 19:54

    Sure, also check your device logs – they are a massive help! 🙂

    – Adam

  36. January 13th, 2012 at 13:39

    can you please explain how to create DNS records for Microsoft Lync mobility? Microsoft document is confusing me..

  37. Adam [I’m a UC Blog]
    January 13th, 2012 at 13:57

    Hi Santosh,

    I’d like to be of assistance, perhaps it would be best if we start by you running me through your assumptions? I’d be happy to give you some pointers…

    – Adam

  38. Arbelac
    January 16th, 2012 at 08:44

    Hi Adam,

    When I attempt to test the rule which was created Lync Mobility Service on TMG,I’m receiving the following the error.

    Time reported by the Microsoft Forefront TMG Firewall Service: 6,717 seconds
    Testing https://meet.xxxx.com:4443/
    Category: General error
    Error details: An unexpected response was received from the server. HTTP response: 500 Internal Server Error
    Action: Verify that the intended server is published and that virtual directories exist. Ensure that you can browse the published site directly from an internal client computer.

    Cheers,

  39. Adam [I’m a UC Blog]
    January 16th, 2012 at 19:03

    Tried iisreset on you Lync Front End?

    – Adam

  40. Mike
    January 16th, 2012 at 23:27

    Adam,

    Fantastic walk-through; I always enjoy your publications. Similar to Steve’s issue, I’m stuck with a Android device giving me only the “Unknown Error” when trying to log in. Only in this case it’s an internal client on the local Wi-Fi. Autodiscovery / redirection is pointing it to the right server. The phone has the Enterprise CA cert installed, though that didn’t fix the issue. Diagnostic logging is turned on, but nothing in particular other than Lync UI setup/teardown posts to the Android logs. Nothing on the server application logs, either. Any hints?

    Thanks in advance,

    Mike

  41. Adam [I’m a UC Blog]
    January 17th, 2012 at 19:11

    Cheers Mike! One area worth checking is whether or not the address for your external MCX service is hairpinning or not – does the address resolve to an external address and can you connect within a browser i.e. https://lyncdiscoverinternal.?

    – Adam

  42. January 18th, 2012 at 11:33

    Hi Adam,

    is it required to open http/https port on TMG for front end pool for external users??.. in your case lyncserver.jacobs.local..

  43. January 18th, 2012 at 11:36

    santosh :Hi Adam,
    is it required to open http/https port on TMG for front end pool for external users??.. in your case lyncserver.jacobs.local..

    In my case I am able to test Lync mobility connectivity internally using Test-CsMcxP2PIM command… from externally it wo’nt work.. I am able to aceess https://lyncdiscover.xxx.com & its pointing to right Lync external web services server.. also i m able to access meet,dilain URL’s externally & edge server works perfectly..

  44. Adam [I’m a UC Blog]
    January 18th, 2012 at 18:45

    Yes, in fact only HTTPS if you have updated your SAN to support the new lyncdiscover URLs.

    – Adam

  45. Adam [I’m a UC Blog]
    January 18th, 2012 at 18:48

    Have you retricted MCX access to Internal only? (default is internal and external). If you are set to both or the default then in either scenario the mobile client is directed external via the reverse proxy. Did you follow the TMG steps within the guide?

    – Adam

  46. January 19th, 2012 at 09:15

    Hi Adam,

    MCX access is opened for internal & external users. As per TMG logs all traffic passes without any issue.

    I think my issue is I have not exposed my front end pool for external users.. My front end pool name is my-lnc-01.corp.mytricks.local.. and lyncdiscover.mytricks.in dialin.mytricks.in etc.. I think I need to reconfigure my Lync toppology to expose my my-lnc-01.corp.mytricks.local..

  47. Adam [I’m a UC Blog]
    January 19th, 2012 at 13:13

    Define “exposing for external users”. Can your TMG Server connect to your FE web services? Try opening a browser on your TMG Server to test.

    – Adam

  48. Tim
    January 23rd, 2012 at 18:23

    I am currently trying to test a small lync deployment. I have a single consolidated standard edition server and have lync mobility installed and seemingly working internally. I am trying to wrap my head around what i need to make lync and the mobility features available for external access. I don’t have a TMG Forefront server…only a pix firewall between my server and the internet.

    My environement:

    Internet –> pix firewall –> Lync2010 Standard Consolidated server (on internal network)

    Is testing external lync access even possible in my environment without a forefront server?

  49. Adam [I’m a UC Blog]
    January 23rd, 2012 at 19:10

    Hi Tim,

    TMG is the easiest/supported route, but you can use an alternate reverse proxy. From my understanding of Cisco PIX, it does not support any form of reverse proxying – therefore an alternate mechanism is required. TMG might be the simplest way to go?

    – Adam

  50. Tim
    January 23rd, 2012 at 20:20

    Thanks Adam. Since this is for testing purposes, could I throw another nic in my lync server and run TMG on the same box?

  51. Adam [I’m a UC Blog]
    January 24th, 2012 at 13:35

    Unfortunately not, but you could spin-up a VM with Windows 2008 Server (single nic) and deploy TMG. This is great for test and used within my lab environment.

  52. Muthu
    January 25th, 2012 at 07:47

    I have deployed Lync single server infrastructure in my office. Now i tried to deploy Lync mobility. Is there any other option to deploy mobility without TMG (can we use fortigate firewall? if so how do achive?). kindly help me.

    Without reverse proxy my android phones Lync clients are able to connect my server using internal WiFi. But apple iPhone & iPad not connecting.

  53. Adam [I’m a UC Blog]
    January 25th, 2012 at 18:35

    Hi Muthu,

    You can make it work with most web reverse proxies.

    – Adam

  54. Phil
    January 30th, 2012 at 16:41

    After going through the configuration step by step when trying to connect from a phone externally I get an error “Cant connect to the server. It may be busy or temporarily unavailable”

    Any thoughts on what might be going on?

  55. Adam [I’m a UC Blog]
    January 30th, 2012 at 17:00

    Hi Phil,

    Enable logging with the Lync Mobile Client. Does it work internally? Are you making an HTTPS connectivity request? (does you certificate support the SIP FQDN being used externally) Has the certificate been provisioned by a public certificate authority? (if not have you loaded the CA root cert on the device?)

    I hope this helps?

    – Adam

  56. Sonny
    February 2nd, 2012 at 21:56

    Hi, nice clear article thanks!
    I however have been having issues with the 504 error thats popping up all over the forums. We did not require Federation when we first deployed and therefore did not need the DNS entries. Now it seems we will need them for PUSH. I have entered the _sipfederationtls._tcp.mydomain.com and pointed to our edge server external address, set the default sipdomain to the external domain, checked the setting, followed this and the MS setup guides, but I still cant get the PUSH notifications to work.

    The autodiscover is working, and logins are successful. I setup our TMG however to use port 80 and not ssl for now. Would that matter?

    Whats my best course to troubleshoot this from here?

    -Sonny

  57. Sonny
    February 3rd, 2012 at 16:31

    My issue was the URL filtering. I disabled it completly and found the PUSH notifications started going out.

    I also rebooted the entire environment. (Never Hurts) 🙂

    -Sonny

  58. Adam [I’m a UC Blog]
    February 3rd, 2012 at 17:13

    Thanks for following up Sonny, glad you have things up and running.

    Adam

  59. Jeff
    February 3rd, 2012 at 20:29

    Adam, struggling here with Mobility Service for the past couple of days. Everything works internally here but outside does not work at all. We have a reverse proxy setup (TMG 2010) and meetings works externally. We are self signed on all certificates thus far (testing). Internally i have a STD Edition Server “lync01” and we have a DMZ with the “TMG01” and Edge “edge01”. Each DMZ box has an internal NIC for routing. Problem is that i see the request come into the reverse proxy successfully to the autodiscover but the root file does not seem fully populated when i access it externally. Is there some part of setup I missed? When I run Get-CSAutoDiscoverConfiguration it comes up blank. Have tried reinstalling Mobility Service and everything on the FE. Very frustrated! Thanks!

  60. Adam [I’m a UC Blog]
    February 4th, 2012 at 14:39

    Hi Jeff,

    Thanks for your comprehensive summary, one thing – have you created an external lyncdiscover record?

    – Adam

  61. Jabagi Kok
    February 14th, 2012 at 12:16

    Hello.
    We are trying to publish Lync Mobility with ISA 2006 and add LockoutGuard as a security precaution. In order for LockoutGuard to work authentications must be done through ISA itself. I saw in your documentation that you pass thru the authentications to the frontend servers with TMG. Is it possible to perform the authentication operations on the ISA or TMG itself?
    Or is there a mechanism similar to Lync Security Filter for mobility connections?

  62. Adam [I’m a UC Blog]
    February 14th, 2012 at 20:51

    Hi Jabagi,

    Great question, however the answer is no. This is because Lync Web Services do not work with form-based authentication (unlike Exchange OWA). I’m not aware of any other 3rd party solutions, but if you come across anything let me know!

    – Adam

  63. Joe
    March 12th, 2012 at 09:21

    @Adam [I’m a UC Blog]

    Yes I’m very interested in this topic!You are a life saver!

  64. Tim
    April 12th, 2012 at 15:40

    Adam [I’m a UC Blog] :Hi Joe,
    Yes there is a way around this (although I’m not sure if it is supported or not) – but from personal experience it works a treat!
    Create a single listener for both Lync and Exchange Web Services and assign a SAN certificate that incorporate both Lync and Exchange URLs.
    I’m thinking of writing a guide on this, anyone interested?
    – Adam

    hi Adam,do you have any update regarding this topic?I’ve been trying to generate the certificate from Exchange server by including Lync’s URL but it is not working…

    Would appreciate your help on this!

    Thanks.

  65. Adam [I’m a UC Blog]
    April 12th, 2012 at 18:05

    It’s on my to-do list!

    Hopefully I’ll get to it soon (forgive me I just started a new job) 🙂

    – Adam

  66. Dave
    April 17th, 2012 at 16:06

    Hey Adam. Just curious if you’ve run into this one: I get “An unknown error occurred. Please retry.” on the Android and on iOS I get “Can’t sign in. Please check your account information and try again. Both log files point to autodiscovery failure. I turn the autodiscover off and put in https://external.domain.com/autodiscover/autodiscover.svc/root for both internal and external (we don’t have internal access), I get Cannot connect to server. Please try again later. When I put the above link into a web browser off our network. I get a 500 Internal Server error. Is it possible there’s something messed up with the external.domain.com website. BTW, I can’t do a https://external.domain.com/abc lookup either. That one I get Page cannot be displayed Error code: 403 Forbidden.

    Great post btw, these posts help keep me sane.

  67. Adam [I’m a UC Blog]
    April 21st, 2012 at 11:56

    Hi Dave,

    Have you tried to test this internally first? If it works then I’d examine your reverse proxy configuration in more detail – do you have conferencing web services delployed externally?

    – Adam

  68. Ken
    April 26th, 2012 at 22:49

    Hi Adam,

    Great site. We just installed Lync 2010 STD with TMG trying to get mobility working with some issues. Android phones are able to connect up with a minor issue but I can not get IOS phones to connect it keeps giving me an untrusted cert error but the cert issued from go daddy. We have reissued the external cert twice to make sure we had all the SAN included; the server name, rp, meeet, dialin, and lyncdiscover. Not sure what else to look at, I did see someone earlier talking about manually importing the cert to the IPhone but I have over 200 iphones so thats not an option. Any help or insite would be greatly helpful.

    – Ken

  69. Tim
    April 27th, 2012 at 09:16

    @Adam [I’m a UC Blog]

    Adam,I’ve been struggled for quite some time on this…lync mobile cannot sign in internally & externally.

    Since the TMG is using single NIC and publishing Exchange services in the same time (I’ve re-issue Exchange certificate with Lync’s requires SAN – lyncdiscoverinternal.domain.com , lyncdiscover.domain.com and etc) but still without success to publish lync..

    Since Lync & Exchange is sharing 1 web listener, I noticed that Exchange uses “HTML form authentication” where Lync should use “No authentication”, what should I do about this?

    I only left 5 days to resolve this issue else I’ll be out of job… 🙁

  70. Adam [I’m a UC Blog]
    April 28th, 2012 at 09:45

    Hi Ken,

    Try importing the root certificate authority, if this resolves the issue you have three options:

    1) Import on all phones (to your point, not nice!)
    2) Set mobility URL to HTTP, are you using Go Daddy for other Lync Web Services?
    3) Buy an alternate cert

    – Adam

  71. Adam [I’m a UC Blog]
    April 28th, 2012 at 09:48

    Hi Tim,

    Create a single listener, but define multiple web publishing rules. They can all same the same listener/certificate

    Hope this helps,

    – Adam

  72. Tim
    May 3rd, 2012 at 05:28

    @Adam [I’m a UC Blog]

    hi Adam:

    But the Exchange’s listener is using “HTML Form authentication” where Lync should use “No Authentication”, Can they both co-exist with 1 listener when the authentication method is different?

    Tim

  73. Adam [I’m a UC Blog]
    May 3rd, 2012 at 08:46

    Set to No Authentication, it works perfectly.

    A

  74. Trevor
    August 23rd, 2012 at 19:46

    I’m sorry, but in my mind the final screenshot where you set the redirected ports for HTTP and SSL looks wrong. Given the rule is meant to publish lyncdiscovery., shouldn’t you be publishing port 5087?

    The mobility url is the one that should be connecting to ports 8080/4443, isn’t it?

  75. Adam [I’m a UC Blog]
    August 25th, 2012 at 09:31

    Hi Trevor,

    Sign-in is performed via the Lync external website on 4443. The other ports are for internal/external SIP processes.

    – Adam

  76. Trevor
    September 6th, 2012 at 18:30

    @Trevor I figured out my issue. 1) The Web Publishing rule for the Mobility URL must also be bridged to port 4443 and 2) In my case the junky Lync client for iPad was not properly trying to reconnect until I rebooted the iPad.

    Blackberry Enterprise Messenger FTW!!!

  77. Rick
    January 3rd, 2013 at 16:31

    Hi Adam

    Good post as always. I’ve added a Lync 2013 Standard Server to my Lync 2010 environment. I can only connect mobile clients for users that are on one server or the other. I have added a TMG Rev Rule for Lync 2013 using the same public IP as 2010. If I put 2013 highest, those users connect, if 2010 highest, those can. Do I need an additional public IP address for the Lync 2013 server?

  78. Adam [I’m a UC Blog]
    January 3rd, 2013 at 18:24

    Hi Rick,

    You’ll have to pick one or the other, you could test the new server before making the switch (and after migrating users) by manually pointing the mobile client (turning off auto-detect server).

    A