With the Lync 2010 mobility add-on out in the wild for quite some time now I see an issue that comes looking round the corner in almost every deployment. It’s called internal wifi clients.
This article 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 yet.
While external desktop clients need both the Lync 2010 Edge server and a Forefront server in the DMZ, the lync 2010 mobility add-on is designed to work via the reverse proxy only (Forefront TMG is used in this article). While this seems logical for external clients, internal clients should use the forefront server as well to reach the mobility website. So if you have iPhone or iPad clients on the internal wifi network, some adjustments have to be made to your lync deployment.
This article uses a simple setup to explain the issue, however the same problem can exist if your setup has split up the Lync roles across multiple servers. This article uses an infrastructure with the following features:
- Simple Lync environment with 1 internal server, 1 edge server and 1 forefront server.
- Split brain DNS configured.
Internal mobile clients connect to a lync environment as follows:
Image Source: Technet
- The internal employee logs on using the Lync 2010 mobile client (i.e. Lync for iOS)
- The client looks for the lyncdiscoverinternal.company.com DNS record. In most deployments, split brain DNS is configured, so your public DNS zone is also configured on the internal DNS environment.
- The lyncdiscoverinternal record points to your forefront server, which in turn redirects you to the internal site on your lync server (on port 443).
- Here, it downloads a file with information about the autodiscover configuration, which tells the client where to find the external Lync site.
- You are now redirected to the external site on the Lync server (on port 4443).
Forefront Setup Continue reading
This article documents the deviations that should be made to the guidelines described at Microsoft Lync Technet and the Microsoft Lync planning tool in regard to port numbers and DNS names when using a single public IP address to configure your Lync environment.
At my current employer we have several small to medium sized customers who want to enjoy the benefits of a Microsoft Lync environment, but don’t have the ability to obtain 3 public IP addresses for it. Microsoft supports the use of one single public IP address with your Lync system, however I found that this process is rarely documented on Technet.
In this article I will use 1 standard Lync Server on the LAN and 1 standard Edge Server that is placed in a DMZ. There is a firewall between the DMZ and the internal LAN, and ofcourse there is a firewall between the public internet and the DMZ. The firewall uses NAT to translate public IP addresses to private ones. The configuration is shown in the picture below:
…Is the question I was asked by a colleague. In Office Communicator (OCS) there is a web client available (commonly referred to as OCS Web Access) that made it possible to logon to your company’s OCS environment, retrieve your contact list and initiate IM conversations with your contacts.
So where did this feature go in Microsoft Lync 2010? The answer is that is has moved. Moved out of Lync to be precise. The ability to retrieve your contact list and initiate IM conversations with your contacts is now a feature in Microsoft Exchange 2010 Web Access. More information on this and how to configure your Microsoft Lync deployment to integrate with Exchange 2010 Web Access is available at the EXPTA blog.
But wait a minute, Lync 2010 does have Lync Web Access?
While the successor to Microsoft’s Office Communication Suite called Microsoft Lync 2010 is on the market for a few months now and I have my first deployment up and running, I want to talk about this issue I had with certificates I ordered from a public Certification Authority (CA). To be precise, I used a certificate from Thawte, although I don’t think the problem has anything to do with the vendor of the certificate. The unexpected behavior was the same with both the certificate for the internal / external web server, and the Lync Edge server.
Creating the Certificate Signing Request (CSR)
In both cases, the CSR was created using the Lync Deployment Wizard using the steps instructed on Technet. Take a look at the chapter “To create the certificate request for the external interface of the Edge Server” for a step-by-step guide on how to create the CSR.
Importing the Certificate
After I received both the certificates from the public CA, they were imported using the guidelines described at the Technet site above, chapter “To import the certificate for the external interface of the Edge Server”. The wizard ended with a message saying that the certificate was imported successfully.