Now that the Lync 2010 Mobility Service has been out for a week there has been ample time, relatively speaking, to dissect the documentation, run through multiple installation attempts, and perform some initial discovery work on exactly what this new service is and how it appears to function. Understanding these concepts can greatly increase the odds of a successful deployment, and this article addresses some of the more complicated or potentially confusing aspects of the overall solution.
(A special thanks goes out to Dave Howe at Microsoft for yet again fielding numerous questions related to how the new Mobility service operates in the undocumented areas.)
Prerequisites
Before beginning the configuration and deployment steps in this article first make sure that each of the following packages has been downloaded; it is also recommended to review the official deployment guide.
- Microsoft Lync Server 2010 Mobility Guide
- Lync Server 2010 Hotfix KB 2493736 (Cumulative Update 4)
- Microsoft Lync Server 2010 Mobility Service and Microsoft Lync Server 2010 Autodiscover Service
An important requirement is that the Mobility service is not supported on a Front End server with a collocated Mediation Server role that has two separate network interfaces which are configured separately as a primary interface for Lync server/client communications and a PSTN interface. A traditional single-homed collocated Front End server is supported and works fine, it is only the multiple NIC scenario that is not.
Environment Preparation
The example environment used in this article include a single Enterprise Edition Front End Server, Director Server, Edge Server, and Forefront TMG server for a reverse proxy. All servers are running Windows Server 2008 R2 and Lync 2010 Server CU3 version software. Steps which are different when a Director role is or is not deployed are specifically identified and explained in detail.
Configure Internal DNS
The first step is to define a new DNS record in the same internal forward lookup zone for each defined SIP domain in the Lync topology. As the example environment has a single primary SIP domain defined as mslync.net then the internal and external Autodiscover records are created in this same namespace.
Both Alias (CNAME) or Host (A) records are supported, but the simpler approach of using CNAME records will be used for the internal record as this approach works better with a pool since additional server nodes would require additional autodiscover A records. By using an alias record then the single pool FQDN will always be used as the resolution target.
- Create a new internal DNS Alias (CNAME) record with an Alias Name of lyncdiscoverinternal for the new internal autodiscover FQDN and set the target host as the Director FQDN (e.g. lyncdir.schertz.local) or Front End pool/server FQDN if no Director is deployed.
Install Cumulative Update 4
Before installation of the Mobility service each Lync Server must first be upgraded to Cumulative Update 4.
- Download the LyncServerUpdateInstaller.exe package from the Microsoft Download Center and save locally on the Lync Server.
- Using the Lync Server Management Shell stop all Lync services with the Stop-CsWindowsService cmdlet.
Stop-CsWindowsService
- Then stop IIS World Wide Web Publishing Service using the command net stop w3svc in the same shell window.
net stop w3svc
- Launch the LyncServerUpdateInstaller.exe hotfix package on the server and select Install Updates to automatically deploy on line the required update packages on the server. Verify that the latest installed version is checked in green before exiting the installer.
- Restart the server if prompted, otherwise re-issue the Stop-CsWindowsService cmdlet to once again stop the Lync services.
- If the server was not rebooted then restart IIS using the net start w3svc command.
Perform the installation steps above for each Lync server to insure that the entire environment is running the same version of software on all like components.
This next step is only performed once per pool and should be run from only one Front End server per pool for each instance of Back End databases.
- Using the Lync Server Management Shell use re-issue the Stop-CsWindowsService cmdlet to once again stop the Lync services on the Front end server.
- The Install-CsDatabase cmdlet is used to update the Back End SQL databases. Specify the FQDN of the SQL Server hosting the pool’s databases. If there are no collocated databases in the same instance for any other Lync Server roles (e.g. Monitoring or Archiving) then omit the -ExcludeCollocatedStores parameter from the command.
Install-CsDatabase –Update –ConfiguredDatabases –SqlServerFqdn sql.schertz.local –ExcludeCollocatedStores
- Restart all Lync services by using the Start-CsWindowsService cmdlet.
Configure Listening Ports
Prior to installing the Mobility service on a Front End server the Lync Topology must have the specific Web service internal and external listening ports defined. These steps should be performed on each Front End server in the environment.
- Using the Lync Server Management Shell issue the following two cmdlets to define both the internal and external listening ports.
Set-CsWebServer -Identity lync.schertz.local -McxSipPrimaryListeningPort 5086
Set-CsWebServer -Identity lync.schertz.local -McxSipExternalListeningPort 5087
- Publish the changes to the Lync Topology by issuing the Enable-CsTopology cmdlet.
Enable-CsTopology
Server Installation
Although the same installation package must be deployed on all Front End and Director servers it will only install the services which are appropriate to that role. Each Front End server will have both the Autodiscover and Mobility services installed whereas a Director will only receive the Autodiscover components.
Install IIS Prerequisites
The Mobility service utilizes the Dynamic Content Compression component of IIS which was previously not a prerequisite component for Lync Server, so it must be installed only on Front End Servers (not on Directors).
- For Windows Server 2008 R2 use the Lync Server Management Shell to execute the following cmdlets. A reboot should not be required after installation of the additional IIS component. (For Windows Server 2008 consult the official documentation for an alternative cmdlet, or just use the Add Features wizard in Windows.)
Import-Module ServerManager
Add-WindowsFeature Web-Server, Web-Dyn-Compression
Note: Although the official documentation states that the additional web component is not required on a Director server, it appears that the McxStandalone.msi installation process does not correctly ignore this prerequisite check when it is run on a Director Server. Currently any attempt to install the package on a Director without this component fails with an error status code of 1603 which states that the “Mobility Service installation requires that IIS Dynamic Content Compression is already installed.”
Until either the documentation is updated or the installation package is fixed then this step will need to be performed on Director Servers as well.
Install Mobility and Autodiscover Services
The new services are not installed by simply running an installation package like the hotfixes. Instead the MSI file must be saved into a particular directory on the Lync Server and then the Lync Bootstrapper application is manually kicked-off. This app will notice the existence of the new installation package and automatically perform the installation of the required services based on the specific server role it detects.
- Download the McxStandalone.msi installation package and save it into the following existing directory on each Lync server where it will be installed.
C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup\
- Using the Lync Server Management Shell change to the Deployment directory and run the Bootstrapper application using the following commands.
cd “C:\Program Files\Microsoft Lync Server 2010\Deployment”
.\Bootstrapper.exe
Notice that once the process completes the prerequisite check on a Front End Server then it will install both the Feature_WebComponent_Autodiscover and Feature_WebComponent_Mcx components.
Alternatively the deployment on a Director server will only report the installation of the Autodiscover component.
If the mobility services are to be restricted to internal mobile clients only (e.g. phones connected to internal WiFi access points which have direct access to the internal Lync servers) then use Set-CsMcxConfiguration cmdlet to disable external mobile client access. (Do not run this cmdlet if external mobile client access is desired and the reverse proxy configuration will be implemented.)
Set-CsMcxConfiguration –ExposedWebUrl Internal
What this cmdlet actually does is enforce which Mcx URL is passed to the connecting mobile client via the autodiscover process. By default the External Mcx URL is always passed to all clients, regardless of whether they are directed to the internal or external Autodiscover site. By running the cmdlet above and setting the parameter to Internal then all clients will receive only the internal Mcx URL back. Thus in an internal-only test environment the clients will always connect to the internal Mcx web site, but in a full deployment with external access then all clients will be passed to the External Mcx URL regardless of the mobile client’s network location. This concept is discussed in more detail later in the article.
To validate the component installation launch Internet Information Services (IIS) Manager and expand the Internal and External web sites to look for the new Autodiscover and/or Mcx services. Again, a Front End server should contains both applications in both sites, while a Director will only have the Autodiscover application.
Also notice that two new Application Pools have ben created on the Front End server: CSExtMcxAppPool and CSIntMcxAppPool. These will not exist on Director Servers since the Mobility service is not installed on them.
Update Internal Certificates
Starting with the Front End Server(s) and then moving to any Director servers each Lync certificate must be updated to include the new autodiscover FQDN. Note that in this scenario each Lync server uses a single certificate per server which is assigned to all installed roles and the certificates were all issued by an internal Windows Enterprise Certificate Authority. In environments were public certificates are used or multiple certificates are assigned to servers for different roles (SIP, internal, or external web services) then additional or different steps may be required, so consult the official deployment documentation in those cases.
Note: This is a section that is very confusing in the official Mobility Guide and required about 10 re-reads to understand what it was trying to convey. Assuming that probably 100% of deployments will not already have a “lyncdiscover” FQDN on the existing certificate then the first steps in the document seem out of place, which are just a convoluted way of identifying that the existing certificate does not already have the new name assigned to it. Additionally the instructions in step 6 are poor as following those steps would produce two separate certificate requests for ‘WebServicesInternal’ and ‘WebServicesExternal’ usages leaving the original certificate assigned to the ‘Default. This would result in converting a server previously using a single certificate to using three separate certificates.
That being said it is recommended to ignore that section of the official documentation for the most part and simply use the Lync Certificate Wizard to issue a new certificate request to a CA of choice. If multiple SIP domains are defined in the Lync environment then still read through that section of the official documentation as a reference since there are additional steps outlined for making sure that each SIP domain will include its associated autodiscover FQDN in the certificate request.
The completed installation of the mobility package and the previous listening port configuration has provided Lync server with the components required to know that the WebServicesInternal and WebServicesExternal usages now require the lyncdiscover.<sipdomain> FQDN to be defined in the certificate FQDN. Thus simply requesting a new certificate will automatically add that new FQDN to the Subject Alternative Name field in the new request.
Note: This does not actually work correctly for a Director server (a pattern is starting to emerge here). The certificate request on a Director fails to automatically include the autodiscover FQDNs so they must be manually added in to the request which is covered in a later step in this section.
- Launch the Lync Server Deployment Wizard on the desired Lync Front End or Director Server and browse to Install or Update Lync Server System > Request, Install, or Assign Certificates and click Run Again.
- Expand the Default Certificate and verify if the same certificate is applied to all three server usages or if different certificates are assigned to different ones. In this example a single certificate is assigned to all usages.
- Make sure that all three usages are checked and then click Request to launch the Certificate Request wizard.
- Verify that the first window states that it will “Request a certificate for the Default certificate (Server default, web service internal, web services external) Lync server usages.”
- Choose to either send the request immediately to an internal Certificate Authority, or if this is a public certificate or a private certificate assigned by an offline or locked-down CA, then select the option to prepare the request now but send it later. This will save the request to a text file which can be manually sent or submitted to the offline CA. Since this example environment utilizes an online Enterprise Windows CA then the Send immediately to an online certification authority option is selected.
- Select the desired online Certificate Authority to submit the request to. Any Windows Enterprise CAs will automatically be listed, but Standalone CAs can be targeted by specifying the actual path to the CA in the second option.
- Specify alternative credentials to submit the online request if the current user account does not already have those level of rights on the CA.
- Do not specify an alternative certificate template unless for some reason the internal CA does not have the default Web Server template enabled. In that case make sure that the custom template used is compatible with the Lync Server certificate requirements.
- Enter a Friendly Name and then enable the Mark the certificate’s private key as exportable setting. The Friendly Name has no bearing on the certificate functionality and can even been changed after the assigned certificate is received, it is purely a descriptive label and can be anything. Do not change the bit length from the default 2048 value unless there is some company requirement to do so, although lowering the value is not recommended due to reduced protection offered by a weaker encryption level.
- Populate the Organization and Geographical Information with the pertinent data for the environment.
When requesting a new Front End certificate the Subject Name / Subject Alternate Names window should show the new lyncdiscover.<sipdomain> and lyncdiscoverinternal.<sipdomain> FQDNs. (The certificate wizard on a Director server will not correctly add these entries and thus they must manually be defined in a later step.)
- Include any additional SIP domains in the current certificate in this request as well to insure that Automatic Configuration or any other client capability is not adversely impacted. In this environment the sip.mslync.net FQDN is actually pointed to the Director server so that FQDN is not included on the Front End server certificate but instead on the Director certificate request (not pictured).
- On the Configure Additional Subject Alternative Names window if the request is for a Director server then manually enter the missing lyncdiscover.<sipdomain> and lyncdiscoverinternal<sipdomain> FQDNs for each SIP domain defined in the Lync topology. This step is not currently documented in the official deployment guide but it is required that these names are also located in Director certificates in addition to Front End certificates.
- Verify the selected values and execute the new Request process. In a single process this action will submit the request to the CA, which should accept the request and immediately return an issued certificate which the Lync server will automatically import into the Computer store and then attach the associated private key to it.
> Request Certificate
Request-CSCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -CA "DC.schertz.local\RootCA" -Country US -State "IL" -City "Chicago" -FriendlyName "Lync Front End Certificate" -KeySize 2048 -PrivateKeyExportable $True -Organization "Home Lab" -OU "Home" -AllSipDomain -Verbose -Report "C:\Users\administrator\AppData\Local\Temp\Request-CSCertificate-[2011_12_10][10_18_21].html"
Creating new log file "C:\Users\administrator\AppData\Local\Temp\Request-CSCertificate-68e83735-805d-49c5-a277-8d6b087941a9.xml".
Create a certificate request based on Lync Server configuration for this computer.
Issued thumbprint "E46942E812746BF3146D78B14257C325547E6167" for use "Default,WebServicesInternal,WebServicesExternal" by "DC.schertz.local\Schertz-RootCA".
No changes were made to the Central Management Store.
Creating new log file "C:\Users\administrator\AppData\Local\Temp\Request-CSCertificate-[2011_12_10][10_18_21].html".
"Request-CSCertificate" processing has completed successfully.
- Once that step has completed successfully then select Assign this certificate to Lync Server certificate usages to immediately assign and enable the new certificate to the Lync services.
View the new certificate to validate that the Subject Alternative Name field correctly displays the new internal autodiscover FQDN in additional to all of the previous web service and Simple URL FQDNs.
- Complete the Assign Certificate task to finish the process and close the wizard.
> Assign Certificate
Set-CSCertificate -Type Default,WebServicesInternal,WebServicesExternal -Thumbprint E46942E812746BF4136D78B14257C325547E6167 -Verbose -Confirm:$false -Report "C:\Users\administrator\AppData\Local\Temp\Set-CSCertificate-[2011_12_10][10_25_49].html"
Creating new log file "C:\Users\administrator\AppData\Local\Temp\Set-CSCertificate-453d98f9-da39-45ab-b3be-00204d1b2d95.xml".
Assign the certificate to the Central Management Store.
The following certificate was assigned for the type "Default":
Default: E46942E812746BF3146D78B14257C325547E6167 lync.schertz.local 12/09/2013 CN=Schertz-RootCA, DC=schertz, DC=local 702419ED00000000001E
The following certificate was assigned for the type "WebServicesInternal":
WebServicesInternal: E46942E812746BF4136D78B14257C325547E6167 lync.schertz.local 12/09/2013 CN=Schertz-RootCA, DC=schertz, DC=local 702419ED00000000001E
The following certificate was assigned for the type "WebServicesExternal":
WebServicesExternal: E46942E812746BF4136D78B14257C325547E6167 lync.schertz.local 12/09/2013 CN=Schertz-RootCA, DC=schertz, DC=local 702419ED00000000001E
Creating new log file "C:\Users\administrator\AppData\Local\Temp\Set-CSCertificate-[2011_12_10][10_25_49].html".
"Set-CSCertificate" processing has completed successfully.
At this point the internal server deployment is completed and it is recommended to issue a server reboot as is general practice anytime a server certificate is replaced. Repeat the steps in this section for any other Front End servers and then move on to any Director Servers. The steps are basically the same for Directors except for where specifically called-out.
External Access Configuration
To complete the infrastructure configuration it is important to understand from the official mobility deployment guide that when external access is deployed then all mobile client connections are routed through to the published external Mcx web site. Even internally connected mobile client will be redirected out the firewall and back into the same reverse proxy rule that external clients are directed to. This method of ‘hairpinning’ client communications insures that all mobile client web server requests to the Mobility service follow the same path to the same published external web service. This approach prevents different clients, or sometimes the same client after moving between networks (e.g. WiFi to 3G) from connecting to both the external or internal Mcx web sites. For proper operation all clients must be directed to either one or the other. So in a full deployment with external access the internal Mcx web site is never reachable and is not used to handle any client traffic.
HTTP vs. HTTPS
An important concept to cover is that the Lync Autodiscover process has the capability to be initiated over either HTTP (80) or HTTPS (443). Either approach offers an inherent advantage and disadvantage. Primarily most deployments will utilize HTTPS as this is more secure and matches the rest of the current Lync published web service configuration, but requires that the certificate on the reverse proxy web listener is updated to include the new lyncdiscover.<sipdomain> FQDN.
Alternatively the initial autodiscover step can be performed over HTTP instead and as soon as the client receives a redirection to the external web service FQDN for connection to the mobility service then the communications will switch to secure HTTPS. So the advantage here is that no certificate change is required since the client connection to the new autodiscover FQDN is not over HTTPs, but mostly likely port 80 will need to be opened from the firewall as this was not previously a requirement for Lync. So depending on change control process and security policies one approach may be easier than the other, or the less-secure HTTP route may not be allowed at all. (The data that actually is passed in clear text is minor and will be highlighted later in the article).
Reverse Proxy Configuration
Here is another section were the official documentation seems to be over-complicated, as it suggests creating an entirely new Web Publishing rule, yet it uses the same exact settings as the existing rule for that internal Lync Server. Thus the following simplified directions will leverage the current TMG configuration so that only a certificate update and a single parameter change is required to support Lync Autodiscover over HTTPS.
The following steps will cover only the more secure HTTPS approach and are specific to Forefront Threat Management Gateway (TMG) but are nearly identical in ISA Server as well. The same concepts apply to any other reverse proxy solution which might currently be in use to publish Lync web services.
Current Environment
As stated this environment contains both a Front End pool and a Director. In this scenario the Lync Autodiscover service is published in the same manner that the SimpleURLs are published. There are currently two separate web publishing rules, one for the Front end Server and one for the Director.
The Director rule is configured to listen on the (bogus) public IP of 11.22.33.44 and contains both the external web services FQDN and the SimpleURL FQDNs.
Configure External DNS
- Create a new public DNS Host (A) record with a Name of lyncdiscover and set the IP address to the external IP address which is already assigned to the Reverse Proxy listener of the published Lync external web services FQDN.
Update Public Certificate
This step can vary greatly depending on which third party certificate authority is used for the existing certificate, so for simplicity’s sake the directions are basically to request a new certificate from the CA which includes a new SAN entry for lyncdiscover.<sipdomain> and then import the new certificate into the reverse proxy server.
Update Reverse Proxy Configuration
Now that the new certificate is imported into the reverse proxy server there are only two simple steps to
- Edit the Director’s web listener (or the Front End Server’s web listener if no there is no Director Server) and assign the new certificate using the Select Certificate button on the Certificates tab.
- Edit the Director’s web publishing rule (or Front End if no Director) and add the new autodiscover FQDN (e.g. lyncdiscover.mslync.net) to the list on the Public Name tab.
- Apply the changes to TMG to complete the configuration.
Supporting Push Notification
The new Push Notification Clearing House (PNCH) solution is used for Windows and iOS mobile clients which do not support traditional application backgrounding like the Android client does. Federation services between an on-premises Lync deployment and Office 365’s Lync Online are used as the conduit between Lync and the online Push Notification services for Microsoft.
Configuration
The first step is to define a new Hosting Provider relationship between Lync and Lync Online, if one does not already exist. (Some environments may already have been configured with this to support federated communications with other companies currently using Office 365 Lync Online.)
- Using the Lync Server Management Shell enter the following New-CsHostingProvider cmdlet to create the new identity in the Lync topology.
New-CsHostingProvider –Identity "LyncOnline" –Enabled $true –ProxyFqdn "sipfed.online.lync.com" –VerificationLevel UseSourceVerification
- Even if the previous step was already completed the push.lync.com domain is new and will need to be defined using the New-CsAllowedDomain cmdlet; the comment parameter is optional.
New-CsAllowedDomain –Identity push.lync.com –Comment “Mobile Push Notifications”
By default the push notification are not enabled after deploying the mobility services so both service types must be manually enabled if either devices are to be supported in the environment.
- Using the Set-CsPushNotificationConfiguration cmdlet enable either one or both of the two services.
Set-CsPushNotificationConfiguration –EnableApplePushNotificationService $true –EnableMicrosoftPushNotificationService $true
It is assumed that federation services are already enabled in the Lync environment, but if for some reason it has not been then the following cmdlet can be used to turn on the capability (which requires a properly deployed and configured Edge Server).
Set-CsAccessEdgeConfiguration -AllowFederatedUsers $true
- To verify that federation is working correctly between the two Lync organizations use the Test-CsFederatedPartner cmdlet with the internal Edge FQDN of the on-premises Lync deployment. In order for this cmdlet to work properly the Lync Server Management Shell must be launched with the Run As Administrator option.
Test-CsFederatedPartner –TargetFqdn edge.schertz.local –Domain push.lync.com –ProxyFqdn sipfed.online.lync.com
Firewall Considerations
The Mobility documentation discusses a requirement to allow traffic over TCP 5223 for push notifications, but depending on the which document, section, or diagram is referenced then it may be a bit difficult to understand exactly what traffic this impacts.
Traffic over TCP 5233 is identified on Apple’s Well Known TCP and UDP Ports document as “XMPP over SSL, Apple Push Notification Service’” and also discussed in the troubleshooting section of this article.
Apple mobile device which are connected to an internal corporate network need to be able to initiate outbound TCP connections through any corporate firewalls to the Apple Push Notification Service (APNS) over port 5223. The device initiates this connection to the APNS so that it can receive any pending push notifications. It is common for internal corporate WiFi networks to be configured with more restrictive policies then wired networks and may not allow outbound traffic across all ports. In these scenarios any network where a mobile device could be internally connected will need to be allowed to send outbound traffic to the Internet over TCP 5223, otherwise push notifications will not work with those iOS devices.
Mobility Policies
Initially all Lync users will be allowed to sign-in to a mobile client as a new global Mobility Policy was created during the installation that is enabled by default.
- To verify the new policy execute the Get-CsMobilityPolicy to view the parameter settings.
PS C:\> Get-CsMobilityPolicy
Identity : Global
Description :
EnableOutsideVoice : True
EnableMobility : True
Additionally Site and User level mobility policies can be defined for a more granular level of control of which accounts can use mobile clients and/or Outside Voice features.
Client Connectivity
To verify that an external client can successfully reach the published autodiscover web site and retrieve the redirection information a web browser from an external PC can be used.
- From any web browser go to the autodiscover FQDN over HTTPS and accept the request to download the file.
https://lyncdiscover.mslync.net
- Open the file with Notepad to see the contents of the redirection file.
{"AccessLocation":"External","Root":{"Links":[{"href":"https:\/\/lyncdirweb.mslync.net\/Autodiscover\/AutodiscoverService.svc\/root\
/domain","token":"Domain"},{"href":"https:\/\/lyncdirweb.mslync.net\/Autodiscover\/AutodiscoverService.svc\/root\
/user","token":"User"}]}}
This information is used to redirect the client to the autodiscover web site but using the existing external Web service FQDN for the Lync server itself (e.g. lyncdirweb.mslync.net). In the event that HTTP is used for Autodiscover this is the only information that is passed across the wire in clear text, as the follow-up connection to the provided URL will utilize HTTPS from then on.
To test an actual mobile client the recently released Android Lync Mobile application was installed on a Samsung Galaxy Tab and using only the Sign-In Address and Password the new autodiscover name was resolved based on the supplied SIP URI’s domain to locate the correct Lync server automatically and sign-in to Lync.
Additionally if the SIP URI and User Principal Name are not identical (as is the case in this example environment) then the initial sign-in will fail. Unlike the Windows Lync client the mobile clients will not automatically prompt for credentials when this fails, it simply says to check the credentials and try again.
For Android clients open the Options menu from the Sign-In screen and populate the User Name field with the proper AD username in either UPN format (e.g. jeff@schertz.local) or NetBIOS format (e.g. SCHERTZ\jeff). Meanwhile iOS users simply need to tap the More Details button to display the username field.
Great article, much more clear than the TechNet instructions.
FYI- Where you have “Set-AccessEdgeConfiguration -AllowFederatedUsers $true”, I believe the actual command is “Set-CsAccessEdgeConfiguration -AllowFederatedUsers $true”
You are correct. Typo fixed; thanks for the heads-up.
Hi Jeff, this was really well written and more straightforward than the Lync Mobility guide. I went through these steps but am having an issue…the client wont sign in. I tried going to https://lyncdiscover.pennoni.com and I get an error but if I go to just http://lyncdiscover.pennoni.com I am able to download the file however it seems like its showing the internal pool name instead of our external web services url. Would it be ok if posted the log from the windows mobile phone to see if you see an outstanding issue?
Which approach did you use to publish autodiscover, HTTP or HTTPS? I did not cover the HTTP method in detail so make sure you have port redirection configured on the publishing rule for 80<>8080 if you are not using HTTPS for the initial connection.
Hi Jeff, we used https.
We're having the exact same problem but I'm only trying to connect internally. I even ran the command to have it allow publish internally as well and made no difference. If I access the url with the https, it errors, but if I use just http I can download the file fine. It also looks like a few entries are missing. Any help would be greatly appreciated! Below is what's in our file.. changing the domain to something generic of course 🙂
{"Root":{"Links":[{"href":"https://<FQDN of FE Server>/Autodiscover/AutodiscoverService.svc/root?sipuri=","token":"Redirect"}]}}
When I implemented this, I have the exact same scenario. If I am trying to resolve internally, I can only resolve via HTTP and not HTTPs. I can also only resolve internally at http://lyncdiscover.fqdn.com and no resolution at at all to lyncdiscoverinternal.fqdn.com on either http or https.
I would like to get a better understanding of how to resolve this. I set this up in my personal lab to debug and run through this before I have to implement it for a major customer later this week.
You need to bind your certificate to your https in your IIS for the https to work.
hope this work.
Lync already does that for you when you use the Lync Deployment Certificate Wizard.
I had the same problem with my deployment but it worked when I bind the certificate to https in the IIS. may be i didn't do something right in the beginning but that is how I resolved it.
My own challenge is that internal web is showing in the external domain and I have tried what you gave in some other responses on this but it is still the same
I have done this exact same setup only using A records for my DNS entries. Auto discover on my Windows Phone will simply not work. If I cheat and enter in the full directory I can login both externally and internally, however autodiscover does not work at all. I am stumped!
This sounds like a DNS configuration issue then if the URL works manually. Maybe try using a CNAME record instead of an A record to see if that make any difference (it shouldn't!).
Hi Jeff,
The last step, signing-in to Mobile Lync with the SIP address and [domain account] password. How is that possible without supplying domainusername? Is this info derived from the SIP address or obtained from the autodiscover process anonymously?
In my environment the user's SIP URI (jeff@mslync.net) is identical to it's User Principal Name (jeff@mslync.net). For the sharp-eyed reader, yes the domain's NetBIOS name is simply SCHERTZ and the DNS name is schertz.local but I've added mslync.net is a secondary UPN suffix and then manually set that account's UPN suffix to "mslync.net". This approach simplifies user authentication and takes the internal namespace out the loop for end-users, but is the same best practice I typically use in deployments.
Thanks for your recommended !!
Thanks for the concise write up and especially the testing commands to make sure Autodiscover is working correctly. After going through the Microsoft documentation the first time around I think I found my mistake, I did a native installation of the mobile .MSI file and then went back and ran the BootStrapper.exe. The Autodiscover and MCX sites got created, but Lync would give you a 403 "Access Denied" error message. I uninstalled the Lync mobile components from Programs & Features and reinstalled by using the BootStrapper and I was able to get a response from the web servers at that point.
Hi Matt,_I made the same mistake on my first site. I cannot get my mobile to sign in. What exactly did you uninstall?
Hi Matthew,
Can you please tell what exactly to uninstall? The only thing that came in my mind was Lync Mobility Components,. but that did not solve the problem and I continue to get 403 Access Denied 🙁
Thanks
Looks like there's also a typo in the section above:
cd “C:Program FilesMicrosoft Lync Server 2010Deployment”
.Bootstrapper.exe
Somehow all the backslashes got removed so it should be:
cd "C:Program FilesMicrosoft Lync Server 2010Deployment"
.Bootstrapper.exe
To match the screenshot.
Thanks for pointing this out, I've since fixed it. Sometimes the backslashes in block-quote sections will vanish when the posts are published and I have to go back in a fix them. I'm not sure if this is a WordPress issue or Windows Live Writer is to blame.
I have tried to get the autodiscover service to work over port 80 without success. I have my lab system working fine for https though. Have you been able to get it to work with port 80?
I'm interested in that solution so that there is not a need for SAN entries for every SIP domain.
I have not yet tested HTTP, but make sure that you update your web publishing rule to redirect traffic from 80 to 8080 on the Front End or Director server.
Great article! Question…Do we really need the certificate to contain the SAN names lyncdiscoverinternal, as well as lyncdiscover? I see the purpose for the latter, but not the former. I have 10 SIP domains, so adding these two names to each brings 20 additional SAN names on my certificate (ouch). I don't see anywhere, other than creating the DNS in the very beginning, where lyncdiscoverinternal is actually used. But, when I run the Assign Certificates wizard, it automatically populates both names, for each SIP domain. Thoughts?
Internal servers require both FQDNs because (1) initial connections to the internal autodiscover service from internal devices will use the <a>lyncdiscoverinternal FQDN over HTTPS and (2) web publishing rules for external clients are configured to forward the original host header so the connection attempt sent to the internal server will include the lyncdiscover FQDN. In either case the FQDN used must match an FQDN in the internal server's certificate. Wildcard certificates are supported for Mobility if they are already in use on the Lync certificates, but read this previous article to understand what else does or doesn't work with wildcard certs.
Thanks. Wildcard isn't really an option in our environment, as our multiple SIP domains are all different. I've been trying to avoid it, but it looks like I need to about 16 new SAN names to my certificate. 🙁
So in an environment with dual edge servers – Would it be better to create a CNAME for LyncDiscover.domain.com or to create two A records pointing to the different edge server web IPs (round robin) ?
The Lync autodiscover FQDNs point to your reverse proxy server, not the Edge server(s) so whether an Edge pool is used or not is irrelevant.
I'm having exactly the same issue as Dustin and I've spent 2 days on it and havent worked it out yet. When i manually go to https://lyncdiscover.domain.com i get an error Service, Endpoint not found. I have looked all over the place online and am stumped. It seems to be a problem on the Front End though, as it gives the same message internal or external.
Anyone have any ideas?
Craig, have you found a solution yet ? I'm having the same problem.
Same issue here. Have followed both Microsoft documentation and this blog's guidance (which is awesome) to a tee with no success. Installed CU4 updates and still no luck. I can access the file with the full URL, but the root URL of http or https ://lyncdiscover.company.com takes me to a page that states Service as the title and Endpoint not found. as a one line text.
Dear,
a query in my company but I have installed are 2 servers Lync that of reporteria and Lync of administration where all users are, but we have activated mobile mobility, internal use only but says it can not install service autodiscover in the management server.
Install IIS Prerequisites
The Mobility Service uses the Dynamic Content Compression component of IIS Which was not a prerequisite Previously component for Lync Server, It Must Be installed so only on Front End Servers (not on Directors).
thank you very much ..
Do you have a write up on the steps to follow when you have a Lync 2010 edge server in the toplogy? As our DNS records for lyncdiscover.domain.com point at our edge server.
You cannot point the Lync autodiscover records at an Edge server, they must point to your reverse proxy server.
Jeff, Thanks for a great write up… Always appricate your help digesting the confusing MS whitepaper… Have you heard any word if The Call-via-work feature will come to Android? Real bummer finding out that wasn't in the Android app.. Kinda makes the android app just another IM client..
I have no information on when additional features or updated clients will be released. I would make an assumption based on the time it took just to get these out that the specific clients will remain this way for a some time. It is reasonable to think that updated clients may come within the same quarterly cumulative update schedule as the other Lync clients, but these typically incorporate bug fixes and not many feature additions.
[…] Jeff Schertz has an excellent blog post on deploying the server-side pieces: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/. […]
I dont want lync autodiscovery.What ul i can us for manual configuration??i have web-ext published using tmg.same can be used for login to mobile client??
Deploying the Autodiscover FQDNs are not a requirement, so you can manually point the clients to the Autodiscover URL using the existing external web FQDN, e.g. "https://webdirext.contoso.com/autodiscover/autodiscoverservice.svc/root"
[…] can reference the following technet blog for resources on preparing the Lync servers for mobility: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/ This entry was posted in Lync. Bookmark the permalink. ← Handling Calls from Outlook […]
[…] can reference the following technet blog for resources on preparing the Lync servers for mobility: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/ This entry was posted in Lync. Bookmark the permalink. ← Handling Calls from Outlook […]
[…] Jeff Schertz’ Blog: Deploying Lync 2010 Mobility […]
[…] Second, you need to install and configure the mobility and autodiscover service, which will also entail getting a new SAN for your Lync public certificate and external DNS changes for outside access. Jeff Schertz has a very comprehensive and easy to follow installation guide here. […]
[…] Second, you need to install and configure the mobility and autodiscover service, which will also entail getting a new SAN for your Lync public certificate and external DNS changes for outside access. Jeff Schertz has a very comprehensive and easy to follow installation guide here. […]
Another great post Jeff, I hope MS already started to send you monthly paychecks, as you are doing much better job than the document team in Redmond.
[…] So anyways thanks to Matthew C. Evans from the comments on this excellent post on how to install Mobile Service: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/ […]
Now we are able to login but messaging is getting failed.cannot deliver error we are getting
Hi Jeff,
We have OCS 2007 R2 Enterprise, and we have (daughter company) GUI clients connecting on non-domain laptops (FE and Edge server settings are set by regkey) through our edge server. We are about to deploy a new Lync 2010 pool (we use video calling, but not Lync as our PBX) and I would like to know why its necessary to have the mobility deployed if we want to use Lync from an iphone. Shouldn't the client be able to authenticate through edge, much like the remote employee setup I mentioned above.
To support any mobile clients all of the steps in this article are required. The Edge server alone is not enough to support connections from the official mobile clients.
Thanks Jeff. I plan on performing your steps. Is it possible to have mobility work without the autodiscover portions. I notice that in my ios client, I can turn 'Auto-Detect Server' off, much like a desktop client. If I wanted it so that our users have to manually enter the server names, would this work. I ask, because we have two Lync central sites. One for NA, and one for Europe branch on our domain. They each have their own FE,Director,Archive,Edge, and RP. We use the same SIP domain as for both groups(central sites), as the SIP domain matches our primary smtp in both cases. For this reason, we use (separate) GPO controlled server configuration for our respective users, rather than automatic client sign-in. I'm trying to acheive the same or similar type of logon for mobility. The app makes me think it's possible, but I've seen no information on how to do it this way.
Great write-up. However: installation and operation of the Mobility service works smoothly on a multi-homed Lync server. I have a Lync server Standard Edition with collocated Mediation server and 3 NICs: 1 NIC LAN <-> Reverse Proxy (TMG), and two NICs Lync <-> SBC (SIP-Trunks) on different subnets. The SIP-Trunk NICs are obviously not registered in DNS. No error during or after installation whatsoever; in fact, how can a web service that only runs between LAN and TMG be affected by irrelevant traffic on other subnets? Maybe the multi-homing problems refer to registering a second IP address on the LAN interface? Anyway, Mobility Service works great on a multihomed Lync server.
It is my understanding that not all multi-homed servers will be impacted by the known issue, but due to the possibilty then the statement is valid in terms of what Microsoft will support. I believe this issue is being addressed for future support.
I have this working beautifully for both Android and iPhoneiPad. Thanks for the guide.
One issue we are having with the iPhone and iPad users is that the 'Meetings' is not working. They get a message about not being able to reach the Exchange Web Service please try later. I tried using the Lync credentials as well as turning that off and signing the user in. They are using the Active Sync for email etc.
Any ideas?
We are having that issue as well. I saw something about needing another DNS record in that case, but no luck there. Still stumped.
Can't help, but we are having exactly the same issue. This really could do with a write up
****coughs***
Jeff anychance?
Having the same issue, can't find a fix anywhere. Anyone get this resolved?
To get the Meetings information Lync uses EWS, which is not available unless Outlook Anywhere is enabled externally. We also use Active Sync and Outlook Calendar meetings show up with the native iPhone Calendar app.
Awesome as always. The one suggestion I have is that when stopping the services, use
Stop-CsWindowsService -graceful
Good tip, a graceful shutdown can be less risky at times (although there is typically not much inherent risk in shutting down services).
Jeff, great guide compared with the technet mess…
We've followed each step in detail but seem to be stuck on certificates. The iPhone client states "can't verify the certificate from the server.." The cert is generated from our internal CA on SBS. Do we need a public cert to work with iPhones? (This is just internal for now, with a single server setup).
James, you will need to load your private root CA certificate into the iPhone, which can be accomplished using this process: http://support.citrix.com/article/CTX125655
Hi Jeff,
I have a question,
On my production enviorement there are no reverse proxy(I know it is not reccomended), and I configured simple URL port redirection from my firewall to the Front-End server. for example;
lync.domain.com/meet 80 443 redirected to my front-end 8080 and 4443 ports though by Firewall. everything is ok and working. But now,
When i use same Public IP address for lyncautodiscover.domain.com , it will be redirect to 4443 port because of Firewall Rule.
Does it work about this scenerio, does front-end listen this port for autodiscover?
May be i can use different Public IP for lyncautodiscover.domain.com, is it supported?
Thank you.
Whether or not a reverse proxy server is used the same port redirection must be configured, so you should follow the same general configuration guidelines as the external requests must be routed to the correct internal web services (external web site, not internal web site).
Jeff, great article. How do you solve the problem using an internal CA en using WiFi on the mobile devices. They have to trust your internal CA and put the root CA on your internal CA.
My suggestion would to point the A record for Lync Internal to the internal IP of the reverse proxy and select the internal network on the listener of the reverse proxy.
You will need to load your private root CA certificate into the iPhone, which can be accomplished using this process: http://support.citrix.com/article/CTX125655. Routing to the internal listener of the RP is a trick I've used in the past for multiple OWA Exchange configurations but I've not tested that with the Mobility service yet so I can't really say if that is an advisable approach. Give it a shot and see what you get 🙂
[…] Deploying the Lync 2010 Mobility Service: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/ […]
Jeff great write-up as always! I have one environment, where I cant get the iPhonesiPads to connect…. Android and WP7 connect without issue. I can see the connections hit the TMG server but never connect. Any thoughts?
I am using Mikrotik Router for lync mobility service. and here is no TMG server is it possible for lync client.
Jeff, thanks for the Great article. but i got one issue when trying upgrade DB server, i was trying to upgrade the DB server from FE server as per your article. but getting this issue Error: Pool "a.db01.x.com" not found in topology.
i am using this command : Install-CsDatabase -Update -ConfiguredDatabases -SqlServe
rFqdn a-db01.x.com -ExcludeCollocatedStores
DB instance name is : Lyncsqldb
we have FE and two DB servers in cluster. in this scenario how do i update the DB server ..? please advise.
Try adding the -SqlInstanceName switch to the command, otherwise you might need to use a different FQDN when dealing with a SQL cluster.
I have a simple Lync installation where everything is internal on the Lync Front End server. We are in manufacturing where it is common for people to be about with their Ipads. I have followed all of the instruction, and still cannot get the app to work. I followed the excellent instructions in the blog, as well as reading everything Microsoft has put out. What do people put for the server? The FQDN of the front end server, or the lyncdiscover.domain.com? If I use that, I get a certificate error.(even though my certificate has the right addresses) If I use the Lync server name, there is no error, but it just sits there and never logs in.
You shouldn't have to put anything in for the server name if you have Autodiscover properly configured, but if you do populate either server field manually you need to enter the enter URL (http://<poolFQDN>.domain.com/Autodiscover/Autodiscover.svc/Root). Also the certificate error is most likely a trust issue and not a name mismatch, assuming that you have private CA certificates on the internal Lync server that the phones do not trust by default.
Thanks for responding.I have entered the correct servername in the field, and the proper SANs are in the certificate. The autodiscover test does not work as described. I have added a CNAME record for lyncdiscoverinternal with a target FQDN of my Lync Front End server. and have followed your instructions to a tee. I am still getting Cannot connect to server. It has got to be something simple, but it escapes me.
Try using an A record to see if it's any different; either should work but it's worth a shot.
Tried that, no luck. The certificate has the correct SANs, not sure what else to check. Is there a way to undo all of this without interrupting Lync users on site? Then I can re-do it. Another thing. Is there a Lync Best Practice Analyzer like the Exchange one?
David, the Lync BPA can be downloaded from here: http://www.microsoft.com/download/en/details.aspx…
Same issue here….I updated and installed Lync Mobility, Android and WP7 connects with no issue, but i cant make iphone/ipads to connect…the screen stays on signing in….and nothing happens….i tried installing certificates on the devices with no louck
[…] can prove to be more difficult then it needs to be. And with the recent release of the new Lync Mobility service and mobile clients there will be a lot of new certificate requests performed in order to add the […]
[…] Jeff shertz has a great blow post you can use: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/ […]
Hi Jeff
I don't have the full path to add the mcxstandalone.msi too.
C:ProgramDataMicrosoftLync ServerDeploymentcache4.0.7577.0setup
I only have the following path:
C:Program FilesMicrosoft Lync Server 2010Deployment
When I run the deployment wizard I get this error "…File not found trying to install installing C:ProgramDataMicrosoftLync ServerDeploymentcache4.0.7577.0setupMcxStandalone.msi(Feature_WebComponent_Autodiscover)"
I've tried to manualy create the folder structure to no avail. Any ideas?
No, I have not seen an instance where the cache4.0.7577.0setup folder is missing from the Deployment directory. Something doens't sound right with that server in general as it should be there.
I'm looking at exactly the same issue – assumed I had to make my own sub-directory as it certainly wasn;t there, but was able to run the msi correctly – didn't actually get Mobility working, though – web URIs still giving a 403 type error…
I had the same issue. It looks like it was due to Microsoft's download page not actually listing the MSI file. It is listing a MSP file instead. Luckily, I had already downloaded the MSI before when I was doing some testing in the lab so I used it instead and, hey presto!
[…] MVP Jeff Schertz’s blog: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/ Lync Server Mobility Troubleshooting Tips: […]
Hi Jeff, I'm just looking over all the documentation and comments before rolling mobility out to our org and I'm not getting the push notification piece with Lync Online. If we don't have Office 365 can we still point to sipfed.online.lync.com?
Great info here, thx!
Yes, you don't need to have an Office 365 account or domain, it's simply another Lync deployment that you are federating with just like any other Lync environment.
Hi Jeff,
I made the same error as Matthew and did a native installation of the mobile .MSI file. I uninstalled the Lync mobile component from Programs & Features and reinstalled by using the BootStrapper and I was able to get a response but not the intended one, It tries to download a file and then errors out with unable to download / from lincdiscover.publicdomain.com. What am I missing here, do I need to reapply all the steps following the msi bootstrapper installation?
Thanks
I've seen in the forums a few instances where people have removed and reinstalled the components 3 or 4 times before it finally worked. It's worth a shot.
Hi Jeff,
If we only need to do a test using internal network, can we just do it w/ one std edition Lync server? You did mention that if the external autodiscover service is enabled, the traffic will be redirected to external, i.e. through edge.
If I don't have edge, does it mean I need to remove the external link?
Thanks!
For an internal-only deployment all you need to do it run the Set-CsMcxConfiguration cmdlet as described in the article and then only deploy the internal Autodiscover DNS record. You don't need an Edge server or Reverse Proxy.
i have android galaxy s 2. and i got "You must update Lync before you can sign in." did i miss something ??
i followed the tutorial above and i had reinstall the lync client in my android.
I have not seen that error but it sounds like maybe CU4 is not correctly deployed on all servers in the organization.
Damn good article Jeff!
Hi Jeff, we deployed this no problem in our environment, and the Windows Phone 7 clients sign in just fine, but the iPhone and Android clients just sit at the 'signing in' screen forever. They never time out, or present any errors, they just sit at that screen forever. Verified same user account on WP7 and iPhone so it's not an account issue.
Worked a treat, thanks.
Great article!! Do you know if it would be possible to use IIS redirects rather than CNAME? Purpose is to have HTTPS all the way through the auto discover process.
That should already be the normal behavior as you typically wouldn't have port 80 open on the web listener. I have not tested enabling BOTH 80 and 443 for Lyncdiscover as I assume that only one approach would be used by the client as it's hardcoded to attempt one before the other.
Hi,
I skip certificate option, and DNS entry i do my local and external dns, like "lyncdiscover.abc.com" the win 7 mobile client connect successfully and IM chat working mean mobile lync client to desktop lync client chat working fine. But mobile lync client to desktop lync client and desktop lync to mobile lync client voice call not working. Where i am wrong????
Lync peer to peer voice (or video) calling is not supported by the mobile client, calls are only handled by the mobile device's voice carrier network.
Hi Jeff,
Nice Post..
anyway, i have Head office pool (the first pool) and DRC pool, FE Enterprise Edition. Can i install the CU4 on the DRC first? I'm not sure to install CU4 at HO pool, so I decide to install at DRC pool for testing purpose and monitor for several day and sure no error..
And for the Lync Mobility service. on the TMG, I publish meet.domain.com and dialin.domain.com to FE pool, not Director..for Lyncdiscover.domain.com, can I also mapping to FE pool directly?
Thanks
You should deploy any Cumulative Updates across all servers in the environment, so I don't know what odd behavior might arise in terms of mobility if all servers are not running CU4.
Hi Jeff,
A good helpful post. We have installed everything as above and for external clients everything works as intended but external clients will not logon.
We have a Lync STD front end, Lync Edge & TMG for reverse proxy. FE cert is internally issued, TMG has a 3rd party cert (go-daddy) both of which have been updated with the autodiscover details.
Any internal clients ie connected to our office wifi get the following message at sign in: "Can't connect to the server. It may be busy or temporarily unavailable. Please try again" and the only error I can see is on the TMG where traffic is being blocked due to: "A packet was dropped because Forefront TMG determined that the source IP address is spoofed"
I am not in any way an expert with TMG (We only have it for the reverse proxy functionality) but this seems to be the issue and I wondered if you have seen this before and point me in the right direction to fix.
Many Thanks,
Richard.
Is traffic from the internal mobile devices routed to the external or internal interface of the TMG server? If the traffic is correctly routed out the firewall and back in so that it looks like any other mobile connection directly from the Internet than TMG should not treat those connections any differently. If truly external devices are working then I'd think it has something to do with how the traffic routed out and back into your network.
Hi,
I have standard eidtion server ( front end and backend only) and enabled mobilty for internal access but users on ipad are not notified on new messages in case the access lync application. how can i enable push notification for internal access only.
Most likely TCP 5223 traffic is not allowed out and back in your corporate firewalls. You can test this by seeing if push notifications work for Apple devices when they are connected outside the network like a home office or public WiFi network.
Hi Jeff,
I have a problem regarding with command.My question is:When I attempt to run the following command Front end server,I'm receiving an error.
Install-CsDatabase –Update –ConfiguredDatabases –SqlServerFqdn sql.schertz.local –ExcludeCollocatedStores
Error –>>WARNING: No databases were discovered at the specified installation location.
Specify a valid location and then try again.
WARNING: "Install-CsDatabase" processing has completed with warnings. "1"
warnings were recorded during this run.
Thanks,
Make sure that use YOUR server's FQDN in the cmdlet and not the sample FQDN from my example.
Great article! I originally followed another article…lets just say I struck out using that one. I was able to get our test infrastructure up and running using this article. I can now login using my Iphone. IM works…but calls do not. Any suggestions out there would be greatly appreciated. I will continue to search as well. Thanks again for posting this! Huge help.
Hi Jeff,
I did a native installation of the mobile .MSI file and uninstalled the Lync mobile components from Programs & Features and reinstalled by using the BootStrapper. The Autodiscover and MCX sites got created, but Lync would give you a 403 "Access Denied" error message. I tried this more than once. The same thing happens on Internal and external url with http and https. Using Server 2008 R2 SP1 fully updated.
Any help will be immensely appreciated please.
I have not run into this, I suggest checking the TechNet forums as I've seen this topic come a few times already.
Great article Jeff. In the section for Supporting Push you say that if Federation services are not configured in Lync (our situation) that the Set-CsAccessEdgeConfiguration cmdlet can be used as long as the Edge server is properly deployed and configured (it is).
My question is whether the external DNS SRV record for _sipfederationtls._tcp.domain.com is also required to allow notifications with the PNCH to work. Thanks!
I would make the assumption that is it required since functional federation is needed for the PNCH, but I haven't tested without that SRV record in place already.
You're right! I wound up testing this since the DNS changes went in last. The Test-CsFederatedPartner failed with a return code of 504 before the Federation SRV was added. Our topology was also updated to Enable Federation on port 5061 on the Edge server and assign the Site Federation Route to the Edge server.
The Push works along with the rest of Mobility we installed. Thanks!
Thanks Jeff, that cleared a few things up and it now works nicely……almost. Users can now log in but are getting "Can't connect to Exchange Web Server. You can try later" messages. Have you ever come across this and do you have any pointers on how to get this working?
I haven't myself, but I've seen some posts in the TechNet forums about it.
Hi Jeff,
This is actually the first time in my career I post a help request on someone's blog, but I'm hoping you'll have at least a faint idea of where to look.
I've installed the mobility service about two weeks ago, and everything seem to be setup fine. All the checks and troubleshooting I've done give the expected result. The problem is that some mobile clients can't seem to login, including on my own iPhone. Other iPhones, with exactly the same iOS and client versions, can successfully login (including a virgin iPhone I used as a test). I've also one other employee on android with the same issue. We get the standard "can't connect to server" message and the client logs don't show anything obvious. When it doesn't work on a device, it doesn't work for any account and the reverse is also true, as I can login with my account on an working iPhone.
This seem to affect only the external access, as when logged to the internal wi-fi it's working. The thing is, I'm using the exact same public certificate for inside and outside. To save money it has both SANs for lyncdiscover.company.com and lyncdiscoverinternal.company.com. *And* it works for most people. Trying to troubleshoot this is driving me crazy, I've spent over 20 hours on this. Do you have any idea what the problem could be?
If the issue is only impacting some but not all devices of the same type then it's hard to make a guess. Are the working devices and failing devices on different carriers (e.g. iPhone on AT&T versus Verizon)? As maybe there is some network routing issue related to where the external traffic is coming from.
Perhaps the APN's on the mobiles are different – check that you are set to use public IP APN rather than NAT'd
Hi Jeff,
Thanks for the excellent blog. I have a question. Can the Push notification service be setup to work only through corporate wifi. The reason is our company wants to deploy mobility service internally ( corporate wifi). Is this cofiguration possible ?
The clients will prioritize Push Notifications through their cellular data network when on multiple networks in the event that the device cannot reach the PNCH servers over the WiFi. So even for an internal-only deployment the clients can still receive Push messages without an Edge Server.
Hi Jeff,
Again great article. I'm using your blog to configure lot of stuff with MS Lync.
I've configured my LAB environment according it step by step, it went smoothly. But my client – I've tried iPhone and WIN Mobile both can't sign in.
I have only Frond end server and I'm using only internal connection (configured Set-CsMcxConfiguration –ExposedWebUrl Internal).
If I try to check services from WEB browser I get this:
https://lyncdiscoverinternal.home.local
{"AccessLocation":"Internal","Root":{"Links":[{"href":"https://lynclab.home.local/Autodiscover/AutodiscoverService.svc/root/domain","token":"Domain"},{"href":"https://lynclab.home.local/Autodiscover/AutodiscoverService.svc/root/user","token":"User"}]}}
https://lynclab.home.local/Autodiscover/Autodisco…
{"AccessLocation":"Internal","Root":{"Links":[{"href":"https://lynclab.home.local/Autodiscover/AutodiscoverService.svc/root/domain","token":"Domain"},{"href":"https://lynclab.home.local/Autodiscover/AutodiscoverService.svc/root/user","token":"User"}]}}
https://lyncdiscoverinternal.home.local/mcx/mcxse…
Server Error
403 – Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
https://lyncdiscoverinternal.home.local/autodisco…
Server Error
401 – Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.
– I have configured – lync control panel -> security – Web Service -> windows authentication to "Negotiate"
– I've tried everything what I found in posts above, but unfortunately it don't work.
Could you give me some advice, what else I should check?
Thank you
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.
Is testing external lync access even possible in my environment without a forefront server?
It's possible, but just not documented well anywhere I'm aware of. You basically need to port forward external requests for 443 to 4443 on the Front end server so that the External Web Services are utilized.
Have you seen any gateway connectivity issues after installing CU4/Mobility? We had a perfectly working system and then after the install, we lost some of our gateway connectivity. At first I thought is was a firewall/NAT issue, but turned out not to be that, and is seems to be something related to codecs I think.Calls some in, but only select gateways work for outgoing calls. Any ideas?
I have seen something somewhat related in one environment but I'm pretty sure that it was working even after I deployed CU4 so I think that may be a coincidence. Other than that, no.
Having trouble signing in via Android & iPhone.
We do not have a TMG server, instead we are performing port translation from 443 to 4443. This works fine for Lync desktop so I can't see why it wouldn't work for mobile.
Error message on android "Can't sign in. Please check your account information and try again."
All the patches have been installed via Windows Update, MCX components installed via MSI then removed and re-installed using the bootstrapper.
Domain self signed certs updated, DNS entries added and MCX ports configured, plus server reboot.
Server 2008 R2, so no manual editing of IIS files required.
On the FE Lync Server Security Logs it is showing a failed logon, despite trying multiple accounts with correct passwords.
Any ideas?
Luke, I have not attempted a deployment without ISA/TMG so far so I can't say what your issue might be. I agree that technically it should probably work, but the more I learn about the Mobility client-server communication the more unique I see it is when compared to the other Lync clients.
For some reason I thought we were using the same domain for authentication as our SIP domain… So once we typed in the username@internaldomain in the username field it works fine.
We also added a 2nd IP to the front end server and assigned it to the external IIS interface on port 443. This works great for external and internal (wifi) mobility clients.
Thanks for the awesome guide worked great the first time both Android and iPhone clients working as well.
hello sir.
thanks for such excellent walk through but my questions i have one lync (has 1 NIC) and one edge (2NIC) server, is it OK if i implement this in my lync server directly
thank you jeff, im new with lync server actually can you tell me how to deploy CU4 somehow. thank in adv
and one more thing after deployment of CU4 then is it ok if install and configure the Mobility services in directly in lync server as per my above environment?
is there anything i should be worry about at all
thanks
Hi Jeff,
Great article. Lync works for us, both internally and Externally but only with the actual Lync client. Not the iOS one. The iOS clients CAN connect internally over teh corporate WiFi or using a VPN.
When I naviage to the https://lyncdiscover.mslync.net url (substituting my domain.com) I get the file, however, when I look at the contents….where you have lyncdirweb.mslync.net, I get lyncpool.mydomain.LOCAL which is the fqdn of the pool but obviously not routable…..is that where my issue lies? If so, how do I fix that?
Rich, you can't modify what URLs are passed to the client. When an internal client is pointed to the internal autodiscover web service the following HTTPS connection for initial authentication must be to the internal server. Only AFTER authentication is the client then redirected to the external web services FQDN to access the MCX service. In your scenario I suggest that you remove the lyncdiscoverinternal.domain.local record and only have the lyncdiscover.domain.com record which will point directly to the external IP address on the proxy. This will force ALL internal mobile client connections to the outside and is recommended so you don't have to either (a) install a public cert on your internal server or (b) configure the private CA cert trust on all mobile devices.
if not using tmg and using autodiscover is it possible to change the ports that autodiscover redirects to .
i have owa using 443 and would like to open ports for lync however lync server is seperate box to the main sbs 2008 box. this is a test rig
hope that makes sense
You cannot alter the behavior of the clients as they can only connect over either 80 or 443 for the initial Autodiscover requests. You'll need to use a proxy or other solution to redirect the requests between the client and server.
Hi Jeff,
thank you for that great explanation.
I (1 lync frontend with edge and reverse proxy ,all 2008R2) have a problem updating the sql database:
this command:
PS C:Usersadmin> Install-CsDatabase -Update -ConfiguredDatabases -SqlServe
rFqdn serverfqdn -ExcludeCollocatedStores
gives me the following warning/error:
WARNING: No databases were discovered at the specified installation location.
Specify a valid location and then try again.
WARNING: "Install-CsDatabase" processing has completed with warnings. "1"
warnings were recorded during this run.
WARNING: Detailed results can be found at
"C:UsersadminAppDataLocalTempInstall-CsDatabase-e6f53bef-6974-4285-b0
9b-492507711ef3.html".
The HTML File shows these entries (amongst others, concerning permissions)
Connection: Data Source=serverfqdnrtc;Initial Catalog=xds;Integrated Security=True 2/2/2012 9:05:39 PM
Forest state: LC_FORESTSETTINGS_STATE_READY 2/2/2012 9:05:40 PM
Warning: No databases were discovered at the specified installation location. Specify a valid location and then try again.2/2/2012 9:05:40 PM
As I have no clue – do you have an Idea?
Best regards,
Markus
Just a guess:
the database has already been done – therefore there is no update to install?
and again, me…
it worked without the "excludecollocatedstore" switch.
Sorry for the stupid question.
Thanks Jeff, another great post!!
Just want to share something I learned – user still can test the Lync mobility service even without Internet connection, office wifi. Just use this tool named 'Virtualrouter' (http://virtualrouter.codeplex.com/) to turn your laptop into an ad-hoc for iPhone. I tested it in my sandbox environment, it is awesome!
[…] Internet connection or wireless LAN. I thought I won’t be able to test the Lync Mobility service (How to deploy Lync Mobility Serivce) until I found ‘Virtual Router […]
Thank you for writing this article. Is it not true that most UPN's are not going to match the SIP URI? Most internal domain FQDN's end with .local or some other non-routable suffix which is different from their public email domain (.com, .ca, .org) and I understood it as a best practice in doing so (as opposed to Split-Brain DNS). Is there not a away around this or have I missed something?
hi jeff,
i did every step of yours but i can not connect via mobile phone..i can reach https://edge.domain.com from outside and download root file ..file says :
{"AccessLocation":"External","Root":{"Links":[{"href":"https://pool.domain.loc/Autodiscover/AutodiscoverService.svc/root/domain","token":"Domain"},{"href":"https://pool.domain.loc/Autodiscover/AutodiscoverService.svc/root/user","token":"User"}]}}
where did i go wrong? i've stuck with this for two days ..
Best regards..
It appears that your internal web service FQDN is being passed to external clients (assuming that the 'pool.domain.loc' example is internal) which is incorrect. Also the 'edge.domain.com/ FQDN is confusing since autodiscover has nothing to do with the Edge Server, but is routed through a reverse proxy of some sort.
Do you have any idea how can i troubleshoot this internal name problem ? i made a mistake its not https://edge.domain.com its https://lyncdiscover.domain.com..
When i try to connect with wp 7 i get certificate notification which i accept and after that nothing, singin in without any result..
Thanks alot for your reply..
Jameel, that depends on the specific deployment. Previous Active Directory best practices used to recommend separate namespaces with a non-routable internal namespace (e.g.. .local) but over time that changed to include real domain names (e.g. .com, .net, etc). This also includes split-brain DNS deployments that use the same namespace for internal servers as well as external domains (like SMTP and SIP). Honestly every environment I've seen has been different, with a pretty even 50/50 split between matching/unique name-spaces. This is one of those 'best practices' that really depends on the overall environment and what systems may be in it.
But regardless of the internal namespaces used administrators can always define secondary UPN suffixes in AD so even in non-split-brain DNS deployments all user accounts can have their UPN defined to the same string as the SIP address. This simplifies user login, but alternatively does not obfuscate the user name, so you need to decide between ease-of-use or security-by-obscurity (which I personally think is a waste of time as it's not really any level of real security).
Is there a way to change the autodiscover address. For some reason, mine is showing up as lync.domain.xxx and not lyncdiscover.domain.xxx? I found on an ipad, the autodiscover/root file keeps directing mobile clients to the incorrect URL and they're never able to sign in. In exchange you can change the autodiscover URL. Can you do this with Lync? I can't find a command to do it.
[…] client on my lab but haven't been successful establishing a connection. I followed this article:Deploying the Lync 2010 Mobility Service : Jeff Schertz's Blog but am still getting a certificate errors. Anyone has it working? Reply With Quote […]
Jeff,
After following you guide, I have ran into a little snag. I have a single FE standard edition. When I try to go to the Lync Server Control Panel I get the following error:
Server Error in Application "LYNC SERVER INTERNAL WEB SITE/CSCP" IIS 7.5
Error Summary
HTTP Error 500.52 – URL Rewrite Module Error.
The page cannot be displayed because an internal server error has occurred.
Detailed Error InformationModule RewriteModule
Notification SendResponse
Handler StaticFile
Error Code 0x800700b7
Config Error Cannot add duplicate collection entry of type 'rule' with unique key attribute 'name' set to 'CSCP Combined Rule'
Config File \?C:Program FilesMicrosoft Lync Server 2010Web ComponentsAdminUIweb.config
Requested URL https://uglsfe1.ug.unifiedgov.org:443/Cscp
Physical Path C:Program FilesMicrosoft Lync Server 2010Web ComponentsAdminUI
Logon Method Not yet determined
Logon User Not yet determined
Config Source
88: <rules>
89: <rule name="CSCP Combined Rule" stopProcessing="true">
90: <match url="(.*)" />
Any ideas?
Quick question/comment, in the Configure Listening ports section you mention the ports need configured on each front end. The Set-CSWebServer command states that it publishes to the topology so I believe the only required command on each front end would be the Enable-CSTopology.
Is this correct? I'm just making sure I understand it all correctly, even though I can't emagine it would hurt running each command on every front end server.
The Set-CsWebServer cmdlet would be issued for each Front End server in the topology (not Directors since they do not host the Mcx service).
Does anyone know how to get Call Via Work feature working? We just get an error on both iPhone and Android "couldn't connect to xxxxx".
Have tried dialling extensions, external numbers (mobile and landline) and even using the full E.164 number with a +.
We can dial outside numbers from Lync Desktop Clients without issue, both local and remotely connected.
Hi Jeff,
Thanks for the great post. Everything went great for me except when setting up push notification. After running the commands, I ran the command Test-CsFederatedPartner, and got a error saying that a "504 <Server time-out> response was received from the network and the operation failed"
Any Ideas why this error might happen?
Try looking at these other articles for 504 errors with PNCH: http://ocsguy.com/2012/02/13/push-notification-fa… & http://blog.ucmadeeasy.com/2012/02/03/lync-push-n…
Hi Jeff
great article. but then i ran cd "C:Program FilesMicrosoft Lync Server 2010Deployment"
.Bootstrapper.exe" everything seems ok and but iis idont see any autodiscoverry `? iisreset is done reboot server to.
any ideas?
regards
/tommy
Good day
Could you possibly assist. I am no longer able to install Lync on my Samsung Galaxy Tab 10.1. Android market gives a message that my device is incompatible with the app ( Lync). Are you perhaps aware of any issues.
Regard
Leonard
Microsoft never intended the Android app to be supported for tablets yet, only phones. Apparently the application was not originally blocked from tablets but was removed from the market sometime afterward for tablets.
on android tablets its possible to install lync2010 (and 2013) manually, if you can find the .apk app file somewhere… (I've managed it on a Nexus 7, just need to get mobilty setup on my lync server now)
Yes, but this is not supported.
Hi jeff,
My lync server local FQDN is lyncsrv.domain.local. And i configured Lync server external URL As lync.domain.lk.
I configred lync mobility service and i tested from the external PC And got the Redirection file. but this file contain the local FQDN (lyncerv.domail.local) behalf of lync.domain.lk.
please help me to slove this issue
I have seen reports of this behavior but have not nailed down a root cause yet as to why the ExternalMcx URL would contain an internal FQDN.
Hi Jeff,
Excellent article. I have a case where the customer has the Mcx directory visible on the Director server which shouldn’t be the case.
Could you let us know if i have to uninstall mobility using add/remove programs and reinstall on the director or is there any other way to do this?
I've never seen that before, Mcx should not have installed itself on the Director. I'd attempt a uninstall/reinstall through the normal process.
Hi all,
Sorry to dig up such an 'old' post, but it seems Google removed support for the GalaxyTab 10.1, or atleast the version without 3G (P7510) since "the app requires dial hardware to function".
Does anyone got this working (recently) on a 10.1 P7510 with some workaround/hack?
Or can someone persuasive hit up the Android Market team to explain you only need WiFi for this app the work?
Microsoft never intended the Android app to be supported for tablets yet, only phones. Apparently the application was not originally blocked from tablets but was removed from the market sometime afterward for tablets.
Just wanted to chime in an say thank you for this great article. Followed it step-by-step and it "just works".
[…] has been out for a few months now. Jeff Schertz has a great writeup on Lync Mobility on his blog here. What I wanted to go into is some more detail on deploying Lync Mobility on your corporate wifi […]
Hi Jeff,
is it possible to run LyncMobility without a reverse proxy. Only in a testlab with wifi connect.
Yes, just use the "Set-CsMcxConfiguration –ExposedWebUrl Internal" cmdlet to force all clients to use the Internal MCX URLs.
Hi Jeff,
i configured lync mobility service as you mentioned in above article. and i can download the redirection files (from internal network as well as outside the organization). But i have a problem with the content of the file. In your example file contain External FQDN of server. In redirection file i'm getting the local FQDN of the server (XXXX.domain.local)
Do you already have external clients accessing the web services successfully or is the mobility client the first thing you are publishing Lync externally for? One potential issue could be if a SE Lync server was deployed and the external web services were never originally defined.
I am have this issue as well did you find a fix?
This is not a mobility question, but perhaps someone can direct me. How can I get the Lync desktop client for machines without Office Professional Plus? Not the eval client.
It's available from the standard Microsoft software distribution sites for customers and partners, but which one applies to you depends on the type of customer. Contact Microsoft directly for this information.
Yes you can skip the autodiscover process and manually point the mobile clients directly to a Lync server or reverse proxy. But when you enter the servername in the client it must be populated as the entire Autodiscover URL, not just a FQDN. For example you'll need to enter "https://lyncweb.domain.com/Autodiscover/AutodiscoverService.svc/Root" where the server FQDN portion is either the internal or external we services FQDN.
Is there anyway that I could have the user enter a shorter alias, and then have the server recognize that this alias should point to the Autodiscover/AutodiscoverService.svc/Root?
The client requires the entire URL to be entered into the field or it will not work. I suppose it's possible to configure a redirection like you've described but I've never tried it. Give it a shot and report back with your findings.
Jeff, first off, awesome blog. Seriously incredible. Question, What if you are using a SonicWall service as your Reverse Proxy. Do you know if there are any additional requirements needed there? Also, after deploying the Lync Mobility service we are now experiencing Federation problems that we did not experience before where users are showing as Presence Unknown in contact lists until you begin an IM session in which their presence is then updated. Strange stuff.
Joe, thanks for the comment. I'm not aware of anything different when using SonicWall as a RP (although I have seen some quirks related to Edge traffic through one before). As I'm a bit behind in replying to comments you may have already resolved this issue by now.
[…] You might want to read this too: http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/ […]
Great article. I noticed you created lyncdiscoverinternal DNS record with an alias to director or lyncpool, however when looking at technet it shows them pointing it to the VIP. Since access to this lyncdiscoverinternal url will be https it wouldnt benefit from DNS load balancing correct? Technet link: http://technet.microsoft.com/en-us/library/gg3982…
My article doesn't address Load Balancer configuration, so yes if you have an HLB for web traffic then the records should point to the VIP.
Hello Jeff,
thanks for your article. I have question. i am testing mobility services, but it's not work.
In the internal network (via WiFi), it's OK for android client and Symbian Belle.
But, from external access (my mobile provider), i have some problem. When i try to connect, i see message on the TMG in log (https 4443 Allowed Connection):
Log type: Web Proxy (Reverse)
Status: 401 Unauthorized
Source: External ( my public IP address)
Destination: "right server in internal network", port 4443
Request: POST http://<external web service FQDN>/WebTicket/WebTicketService.svc
Protocol:https
User: anonymous – i think, there is the problem
do you have any idea, where is the problem? i think, i have some mistake in settings on reverse proxy…
if i am runing connectivity test on https://www.testocsconnectivity.com/ all it's OK
…external access is working on another lisener.
but i must create a new lisener, because i don't have new certificate for lyncdiscover.<mydomain.com>
i use another *.<mydomain.com> certificat. there is one problem, because i have another domain for external web access FQDN and another sip domain for users, for example *.<sip-mydomain.com>
You'd only need to create a separate listener if you cannot or do not have all of the required FQDNs on the same certificate. If you are using separate certificates for web services and lyncdiscover FQDNs then you'll need to setup separate listeners.
Hi Jeff,
now it's all working. I red bad your manual… I had set "Set-CsMcxConfiguration –ExposedWebUrl Internal". 🙁
Hey Jeff-
I have a small Lync deployment with a FE/Mediation collocated, Edge Server, and Conferencing server and we are looking to add mobility. I am bringing up a server for TMG Reverse proxy and I was wondering if the Reverse Proxy should be located internally or externally on our DMZ. We already have firewalls in place so we do not need TMG for that, just the proxy. I read what you said about hairpinning but it mentioned having a reverse proxy already in place, nothing about an Edge server. Will the Edge server function the same way with the hairpinning?
Thanks!
The mobility clients have no SIP stack in them and thus do not interact with the Edge server at all, all communications are handled through the Reverse Proxy. TMG would typically be placed in a perimeter network (DMZ) on a non-domain joined server.
Thanks for the quick reply Jeff!
I am now working on bringing up a TMG Reverse Proxy for mobility. I am following this article: http://www.darylhunter.me/blog/2011/11/lync-2010-…
In the article I need to set up a Web Listener which requires installing a Cert that Lync uses. The article mentions a 'public cert used on the Front End' but I do not have a public cert for the Front End, I do have one for my Edge server, though. I have installed/imported both my Public Edge cert and my private Front End cert onto my TMG server, but no certs show up in TMG on the window where I set up the Web Listener. Why is this? Both are installed in "Trust Root Certificate Authority" is that wrong?
Any ideas?
You don't need a public certificate on the Front End server. And if a certificate is not appearing in the import list in TMG this is because the certificate is not valid for use on a listener, which typically means that the private key is not included in that certificate. When you export them from the other servers make sure that you include the private key in the exported file (typically a password-protected .pfx file).
Hey Jeff-
I am now facing certificate issues with my mobility deployment. I am trying to put the correct certificate on my TMG reverse proxy. Is it my Front End private cert or my Edge's external public cert? Whenever I import a cert in my local/personal store, it says I am unable to use that cert in TMG because it does not have a private key. The only time I've gotten this to work was from exporting my Edge's public cert and choosing to export the private key.
I have added the discover SANs into my public cert but the new cert will not show up when I try to add it to the Edge server. It says I completed the import but I cannot switch to it. Even when I removed the cert and put the new one in, it went back to the old cert (confirmed by checking SANs).
What do I do? I feel this is the only thing holding me back from getting mobility to work.
The internal certificate assigned to the Front End server does not go on the reverse proxy. Only the internal root CA's certificate (if not already applied to establish the chain of trust) and a new certificate issued directly to the reverse proxy are needed on the TMG server. If the certificate is not available to select in the wizard then this indicates a configuration issue with the certificate (e.g. missing private key).
Great Posting. There's a small typo in "Push Notification Cleaning House (PNCH)" where there's an "n" instead of an "r" for Clearing. Since a number of people read this blog, it would be nice to suggest microsoft update their planning tool to include the mobility and autodiscover service, in particular for the firewall rules. I noticed you mentioned the ports however what are your implementation steps for opening ports between the internal and DMZ firewalls. Publishing the rules would be a nice addition here.
Thanks Brandon, I've fixed the typo. In response to the firewall rules I'll leave that for someone else to blog on as there are so many different possibilities for network configurations and firewall appliances that it make an already long article a bit too complicated.
Hi Jeff,
I enabled Lync mobility following your excellent guide. All is working fine except the push notifications.
From a network capture I can see that the microsoft federation (sipfed.online.lync.com) proxy is resetting the connection during TLS negotiation. We use certificates from our private CA, do you know if a certificate from a public CA is required to successfully support push notifications?
Thank you.
Yes, the other side of the federation must trust the certificate issued to your Access Edge service and this is not possible with a private certificate. You need a public certificate to federate with Lync Online.
Hi Jeff.
For the port enabling step, I ran the following from my Front End server:
Set-CsWebServer -Identity lync.internaldomain.local -McxSipPrimaryListeningPort 5086
Set-CsWebServer -Identity lync.internaldomain.local -McxSipExternalListeningPort 5087
where lync.internaldomain.local is the internal FQDN of my Lync 2010 FE Pool
-Should I have instead used the name of the actual FE server that I was installing on, lync-01-v.internaldomain.local
i.e.:
Set-CsWebServer -Identity lync-01-v.internaldomain.local -McxSipPrimaryListeningPort 5086
Set-CsWebServer -Identity lync-01-v.internaldomain.local -McxSipExternalListeningPort 5087
-You note to run this on every FE, but since our director is the first hop in our environment, do I also run it on the director, and would I use the director pool name?
i.e.
Set-CsWebServer -Identity director.internaldomain.local -McxSipPrimaryListeningPort 5086
Set-CsWebServer -Identity director.internaldomain.local -McxSipExternalListeningPort 5087
where director.internaldomain.local is the internal FQDN of my Lync 2010 Director Pool
The pool name is used for port configuration, not any of the web services names. Also these commands are not run on Director servers as Directors do not contain the Mcx service, only the autodiscover portion.
this needs to be more clear in your instructions – I've used my FE server address in the Set-CSWebServer commands, and realised the possible mistake before enabling the topology change.
What needs to be more clear?
dear Jeff,
two week back i was installed MS lync 2010 server , only for internal access , everything is working fine in internaly , now i have to conect one IPad internaly through WIFI , kindly get any procedure , i saw your blog in there mentioned out side also thats way am confusing , for internaly whatare the cmdlt want be run ?
thanks
Shahim
Hi Jeff
there are 2 ports we configured on article
how to make sure that these ports are open
where i can telnet?
i try to telnet to
telnet lyncdiscover.domain.com 5087
and its not work
These ports are not open for standard telnet connections, so that is not a valid test of their functionality. When clients connect via the web services then connections are allocated to those ports in real-time.
Thanks for the article Jeff.
I am having a problem with external access. If I go to https://lyncdiscover.externalurl.com, I download the file and view it. It shows: {"AccessLocation":"Internal","Root":{"Links":[{"href":"https://frontend.internalurl.local/Autodiscover/AutodiscoverService.svc etc.
Even though it is set with ExposedWebUrl External. It will not pass out the external URL. It always says Internal as the AccessLocation.
It works fine internally if I set it to Internal.
Any thoughts?
If the internal/external parameter has been modified make sure to run Enable-CsComputer a few times on each machine in the Autodiscover path to verify that the configuration information is up to date.
below is what I get browsing to https://lyncdiscover.ediltd.com. Please advise how I get this to display external
{"AccessLocation":"Internal","Root":{"Links":[{"href":"https:\/\/lync12-fe.ediltd.local\/Autodiscover\/AutodiscoverService.svc\/root\/domain","token":"Domain"},{"href":"https:\/\/lync12-fe.ediltd.local\/Autodiscover\/AutodiscoverService.svc\/root\/user","token":"User"}]}}
Hi Jeff,
Will the Push notification services for WP and iPhone also work when using OCS R2 Edge servers. We are still migrating and have not replaced our Edge infrastructure yet, so all Federation still flows across the OCS R2 Edge. Mobility works an all platforms, but no Push on WP and iPhone.
thanks
Richard
Jeff,
After enabling the ports 5086 and 6087, should the Lync FE be listening on these ports ? After enabling them I can't seem when I view the open ports on the machine and my reverse proxy seems to show the request from my mobile but it's not going anywhere! and when I view the link https://lyncdiscover.mydomain.com I get the file exactly as you have specified it above. but unable to connect. Any advise where to look for ?
Thanks
These ports are not listening for just any inbound connection so using telnet to verify them is not a valid test. This is normal behavior for those ports.
It’s exhausting to search out educated folks on this matter, but you sound like you understand what you’re speaking about! Thanks
Wow! This can be one particular of the most helpful blogs We’ve ever arrive across on this subject. Actually Wonderful. I’m also an expert in this topic so I can understand your effort.
Hi Jeff-
I have been working on deploying Mobility for quite some time now, its tough! Everything -seems- to be set up correctly now, and autodiscover tests on https://www.testocsconnectivity.com/ pass successfully. However, my clients still can not log in and I am getting an error when I run Test-CSMCXP2PIM.
The error says:
ERROR – No response received for Web-Ticket service.
Inner Exception:The HTTP request is unauthorized with client authe
ntication scheme 'Ntlm'. The authentication header received from t
he server was 'Negotiate,NTLM'.
Inner Exception:The remote server returned an error: (401) Unautho
rized.
Any idea what I can do? I do already have Security->Web Services set to 'Negotiate'
Hey Jeff
there are a problem on mobiles when i connect it takes so much time and it is not connected when i see the log it seems that mobile tro to locate http with port 80 not https
there is a one mobile we connected manually then it connected and when we changet to automatic by autodiscover also it was connected
but it is the only mobile that connected
please can u help me
[…] With the recent release of the Lync Mobile client for Windows Phone 7, Android, and iPhone, I’ve seen numerous companies thrilled about the opportunity to extend Lync further within the enterprise! For companies interested in deploying Lync Mobility, the Lync Server Cumulative Update 4 is required. For deployment steps, I highly recommend reading the Microsoft Lync Server 2010 Mobility Guide and Jeff Schertz’s blog. […]
Hi Jeff,
I have Configured same thing As per your Post. Now We have all the Client are running Internal and External but Problem with IPhone and Ipad are not working in Internal Network.(Can't connect the Server). Certificate are ok Lyncdiscoverinternal are ok. DNS Recards are ok then what i should check?
Waiting for your reply.
Thanks:
Amit Sharma
Thanks for everything, Jeff. I have mobility working finally. I have one question, though. Mobility clients typically use 3G or 4G, but additionally use the internal Wifi to access secured data. However, in order to sign in to Lync, they must turn Wifi off. I need for the clients to be able to sign in to Lync while remaining on the local wifi. I know that the communication hairpins out and back in. But there must be some way to allow a mobile user to remain connected to the internal network and use mobility. Can you help, or direct me to some article?
Thanks.
The devices can connect internally first and then be redirected to hairpin but for mobile clients it is best to push them out to the external listener right away due to certificate trust issues between the front end server and unmanaged mobile devices. Either way you should be able to do this over the internal WiFi connection, so you need to make sure your auto-discover DNS records are configured correctly.
Thanks for this guide, having a problem. During initial configuration, I did not enable federation. Currently I have sip traffic going over 5061 web conf over 444 and A/V over 443. If I enable federation for my edge pool, it goes over port 5061 this is going to cause conflict isn't it? Do I need to change my sip port from 5061 to something else? Any recommendations? My "Site federation route assignment" is currently grayed out, I'm assuming once I enable it on my edge pool this will appear and I can publish my topology.
That is fine, both external user access and federation can share the same listening port (5061). The port assignment you have is the recommended configuration for single-external-IP Edge Server configurations.
Jeff, if we choose not to update our SAN entries on the external edge interface to include new SIP domains and use HTTP, will PUSH work? It doesn't seem to work for domains not included on the SAN entries…can anyone confirm this is the case? Perhaps MS Cloud servers don't trust the communication and don't sent the notifications?
I have not tested this but the results you are seeing seem to indicate that is the case.
Configuration of lync on android?…
You need to have your IT team deploy “MCX” (mobility services) on the Lync Front Ends (back end infrastructure, if you are an end user). This is supported as of CU4 and later but is a separate download with separate configuration and will likely need…
This is a great blog post and has been really helpful for setting up Lync 2010 mobility.
I had some problems when connecting to lyncdiscover.companyname.com it would not download the configuration file. It would just show a 403 forbidden message, what I found is that everything was setup correctly but when connecting to lyncdiscover.companyname.com it was not redirecting to lyncdiscover.companyname.com/autodiscover/autodiscoverservice.svc/root as it should. This meant auto-config on the mobile devices did not work. The URL rewrite rule was configured and syntax correct as well.
The fix was ridicously simple and noted in my blog below.
http://www.teamas.co.uk/2012/10/lync-2010-mobilit…
it may help others troubleshooting!
Hi, do we need reverse proxy. or we can depend on the edge @ DMZ premises.
A reverse proxy (or some other publishing solution) is required. You cannot use the Edge Server as it is only for SIP clients; the mobility clients are HTTP/S clients, not SIP clients.
Hi Jeff,
One question. How come the internal CA not being a trusted CA on the Droid/iPhone doesn't cause issues when logging in internally? I would expect a SSL error, etc until the root cert is installed, but instead my clients can sign in just fine over internal wifi.
Thanks!
Hard to say, either the traffic is being redirected to an external server with a public cert or a public cert is in use on the internal server. Without a valid certificate trust established there is no way this can work.
I am making a call from my android client. I make a call and I receive the callback but it does not make the 2nd leg of the call. Have you seen this before
I used MS Forefront TMG 2010 for reverse proxy, and it works fine. The server is in a perimeter network as a non-domain joined server. I need to publish an internal web site for outside users using TMG. How do I get the certificate from the internal CA? The Certificate Rnrollment Policy does not have the Active Directory Enrollment Policy listed, however, I can ping the CA. If I try to add one, I get a 12045 error the certificate authority is invalid or incorrect.
I know this is not a Lync question, but I figured youwould know about TMG and getting certificates with this configuration.
Thanks for your help.
I am runing Lync 2010 Mobility services with two SIP domains. I have been able to test push notifications for the default domain, but users registered with the other domain do not receive push notifications.
How would one go about fixing this?
I have two SRV Federation records for each domain
_sipfederationtls._tcp.domain1.com on port 5061 to access.domain1.com
_sipfederationtls._tcp.domain2.com on port 5061 to access.domain1.com (lower priority)
I am able to sign in to mobile devices using multiple SIP domains.
I am able to sent receive messages on mobile devices.
All of my certs should be accurate, its seems silly that it wouldn't work.
You should not mix domain names in the SRV and A records. Although some clients will allow you to ignore the strict DNS naming failure in this configuration, not all Lync clients will work with that configuration. It is best practice to point an SRV record to an A record in the same domain namespace, not in a different domain.
Hello Baywack,
unfortunately, Mobility Services for Lync 2010 cannot be found anymore. I’m desperately looking for “McxStandalone.msi” – do you still have this setup and could share it with me?
Thank you so much in advance,
Claudius
[…] for Lync 2010, which is now embedded in Lync 2013, can also utilize HTTP. Previous articles Deploying the Lync 2010 Mobility Service and Lync 2013 Client Autodiscover already discuss this topic in detail, but the key point is that […]
[…] for Lync 2010, which is now embedded in Lync 2013, can also utilize HTTP. Previous articles Deploying the Lync 2010 Mobility Service and Lync 2013 Client Autodiscover already discuss this topic in detail, but the key point is that […]
Hi jeff
Can you explain, why do we need to have in internal dns CNAME (or A record) for lyncdiscover and lyncdiscoverinternal pointing Front End Pool /Director if Mobile client will be hairpinned to external access.
[…] We also used 2 additional reference URLs: Mobility for Lync 2013 – Lync Server 2013 TechNet Forums Deploying the Lync 2010 Mobility Service – Jeff Schertz’s Blog […]
[…] explains the certificate error that can appear if your environment is incorrectly configured. Use this article by Lync MVP Jeff Schertz if you haven’t configured your Lync environment for mobility […]
Hi I am also having sign issue with mobility on iPad. It is stuck in the 'Lync is signing in' screen. When i go to https://lyncdiscoverinternal.lync2013.com/ I was asked to download a file that looks different than what I have seen so far online. It is missing the token and also include the https for external web address:
Please help, i'm running out of options and dont know how to fix it
{"_links":{"self":{"href":"https://fe1-lync2013.lync2013.cisco.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=lync2013.cisco.com"},"user":{"href":"https://web-lync2013.lync2013.cisco.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=lync2013.cisco.com"},"xframe":{"href":"https://web-lync2013.lync2013.cisco.com/Autodiscover/XFrame/XFrame.html"}}}
Hi Jeff, just follow your steps i deployed Lync mobility for Lync Server 2013. All the step done and test OK. But When i try to sign in from Lync Store App on Windows 8. i meet the error "Can not sign in because server version is incompatible with Lync…". i'm stuck here! So can u give me some guide or suggestion for this case? THanks!
[…] Technet: Planning for Mobility Client: open Jeff Schertz: Deploying the Lync 2010 Mobility feature: open […]
[…] internal and external web sites in IIS which were covered in detail in the previous article Deploying the Lync 2010 Mobility Service. This included a new Autodiscover service which paved the way for an entirely new approach […]
hello,
does anyone know how to push the lync 2010 mobile (android) settings into a device?
i mean.. remotely
many thanks
Philippe
i can follow this step in lync 2013 wait your reply
Recently came across an issue where a person did not set the ports which resulted in mobility obviously not working as well as a flood of Application Event ID 1309 with the line:
Exception message: Topology doesn’t have required sip listening port setting
I wrote up an article on it over at my blog:
http://www.taskrepository.com/2016/05/mobility-topology-doesnt-have-required.html
Hi Jeff.
This is an incredible article, and quite easy to follow. Do you have an article on Deployment of Web App Proxy?
I use this to connect all mobile devices such as smartphones and tablets.
I would like to revive or reinstall WAP for Skype for Business, as the deployment I have was for Lync 2013.
Thanks in advance.
Hello Jeff,
thanks for your great article. Unfortunately, Mobility Services for Lync 2010 cannot be found anymore. I’m desperately looking for “McxStandalone.msi” – do you still have this setup and could share it with me?
Thank you so much in advance,
Claudius