Deploying Lync mobility over the silly season came with a fair amount of frustration. Having come across a few speed bumbs I thought it best to document these as I will probably forget the solutions and have to spend valuable hours retracing my steps.

Now I do have to state that this is not a deployment how-to but rather additional to the deployment guide.

Firstly, determine if the organisation actually allows mobile device connectivity via Wi-Fi internally. This is often flagged as a security risk and thus mobile devices may only connect to a guest AP that has no access to the LAN. So in my case I only deployed the external connectivity.

List of issues I came across and the solutions 😉

Issue #1

I ran the bootstrap installer but still no MCX site.


One of the installation steps is to set the Primary listening port for MCX. This is done with the Lync Powershell command

Set-CsWebServer -Identity -McxSipPrimaryListeningPort 5087

* You have to specify the Primary Listening Port or MCX wont install!

NOTE: This command has to be run on the Server housing the CMS or it will fail!Got an error that the *msi was missing (as well as a message that all the IIS pre-req’s were missing…added the entire IIS role components to remedy that)

Downloaded the mcxstandalone.msi from link below, copied to appropriate directory:-

C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup

then ran the msi directly, that sorted the install and then I finally saw an MCS page in IIS
Use the PosweShell command below to see the MCX ports and Url’s

Get-CsService -WebServer

You can check the install by looking at IIS on the FE, there needs to be an MCX site for both internal and external.

Issue #2

Getting error 500 – Internal Server Error when attempting to connect to the autodiscover URL


As I was waiting on the Autodiscover DNS record in the public realm I decided to test with the manual setting. The problem was on my part, I didn’t notice how the internal and external URL’s were different.

https://lyncdiscover./Autodiscover/autodiscoverservice.svc/Root for external access

https://lyncdiscover./AutoDiscover/AutoDiscover.svc/Root for internal access

Emphasis on autodiscoverservice.svc (*externally) and autodiscover.svc (*internally)
I had deployed MCX for external connectivity only but was using the URL for autodiscover.svc and not autodiscoverservice.svc. Had I set the *exposed URL (seen from Get-CsMcxConfiguration) to Internal I may have hit the page…

Issue #3

Getting Error 500 or 403 When testing the site from IIS


This as I now know is normal, it may be different if my Lync admin account actually was enabled as a Lync user

though 🙂

Issue #4

WM7 client signs in but ios sits on the sign-in page for ages and then fails with “Can’t connect to the server. It may be busy or temporarily unavailable…” error. Two solutions were required for this one…

Solution A

Change the security method, by default it is set to NTLM. Change this to negotiate in the lync control panel -> security – Web Service -> change windows authentication to “Negotiate”

Solution B

I turned on logging and sent the file to myself, I then found the following line in the log file
noticed in your log the following line


.cpp/161:Credential information: credType (1) signInName ( domain () username () password.empty() (0) compatibleServiceIds(1)

So suspicious of the missing credential I started to fiddle with my phone and found the answer. Once I had populated the user name field the phone logged on and at last there was victory!

iPhone and Windows Mobile 7 – go to More Details – and add Domain\username for user name then both these field become populated.

Android – go to More – Options adding the domain\username for the user name field.

Although I do still get a lot of these lines without the domain and username, I also occasionally see the details for Domain and username populated, go figure.