Category Archives: Reach Client
At this time, there are going to be a few scenarios where you may need to deploy the R2 version of Communicator Web Access with Lync Server 2010. The core reason here, is that the RTM Version of Lync Server 2010 contains a feature on the front end called Lync Web App. Eventually, Lync Web App will become a full featured web client, however, today it is only used for users to join online meetings from the web. There is no ability to access Lync Web App from a URL and sign-in, or use it as a instant messaging too. This is planned to be released SP1 of the product, that timeframe is unknown right now.
To fill this gap, customers will have to deploy the OCS 2007 R2 CWA role, which can register against a Lync Server 2010 Pool. This post will show you how to configure OCS 2007 R2 CWA to work in your Lync Server 2010 environment.
Preparing the Environment
The most important piece of information in this blog, is that the Schema Prep for OCS 2007 R2 must be run in the environment before the Lync Server 2010 Schema Prep, or you will not be able to install the R2 version of CWA. If this is a deployment where there have not been prior installs of OCS 2007 R2, you will need to obtain this media, and run that Schema Prep before your Lync deployment starts, so it is very important to plan for this in your design/planning phase of your project.
Also, to get straight to the point for this blog, I am going to assume you have prepared the schema in the correct order, have your Lync Server 2010 environment online, and have already installed the CWA Role on a server. I will walk through creating the virtual directory, as well as integrating it with your Lync environment.
Use this Deployment Guide to install and configure the CWA role
Creating the OCS 2007 R2 Virtual Web Server
One you have the CWA role installed, and a valid certificate installed on the server, you must configure the virtual web server that clients will access.
I will walk you through the process for creating an External web server, however the same process applies for the Internal web server. The difference being the types of authentication allowed, external allows forms, where as internal also allows NTLM authentication.
Login to your R2 CWA server, and open the Communicator Web Access Admin Console
Once in the admin console, right click on your server and choose Create Virtual Web Server
Navigate through the setup wizard, choose only your Web Server Type, in my case I am choosing External. Make sure to select a valid HTTPS certificate when prompted.
When you get to this section, Specify IP Address and Port it is important to note that this is the IP and listening port for your web server, not the communication between Lync and your CWA server, we will get to that next.
After entering a description for your virtual web server, the most important part of this wizard is the Specify a Listening Port section. This port defines what this application will listen on, and communicate with your Lync front end on. Because of the change in ports between OCS R2 and Lync, previously used values like 5070, or 5071 as you will see in older blog posts of mine do not work. You must pick a port that is not being used by an application currently. For my example I am using 4790.This can be any port, as long as your Lync front end and this server can communicate on that port.
Next, define your next hop pool, choose the appropriate Lync pool as your next hop and leave the port to default 5061.
Complete the wizard and start the virtual server.
Your settings should look similar to this
Now that you have completed this, you will need to make Lync aware of this server.
As you will find in the OCS 2007 R2 to Lync Server 2010 Migration Guide, you must merge your Legacy (OCS 2007 R2 components in to your Lync Topology.
Configuring Lync Server 2010
Now that we have our CWA server configured, we must make the Lync topology aware of this server. To do so, we will merge the legacy topology in to our Lync topology. This is possible through PowerShell using the Merge-CSLegacyTopology cmdlet, however I will be using the GUI.
Before completing this task, you must install the OCS WMI Backwards Compatibility tool, this can be found on the install media, called ocswmibc.msi
First, navigate to your Lync front end and open the Topology Builder.
If you already have coexistence with a R2 environment you will be very familiar with this process, and you will also see the BackCompatSite listed.
Right click where it says Lync Server 2010 and choose Merge 2007 or 2007 R2 Topology
In this post, I am assuming there are no R2 pools, and we are just importing the CWA server and web site. Because of that, you will actually leave the wizard blank when it asks for servers. This wizard will connect to servers in your environment and pull configuration data out of WMI, and input them into this BackCompatSite that will reside on the CMS. This is the major change from OCS 2007 R2 to Lync, is what used to be in WMI, is now in the CMS. You can find plenty of resources to get into more detail about that on Nexthop.
Verify the setting selected in the wizard, and choose Next to merge your legacy topology.
Everything should complete, choose Finish and you will now see your new site.
Expand BackCompatSite and expand TrustedApplicationServers for this blog post, we are concerned only with the trusted application servers, this is where your CWA, and other R2 server roles like group chat will appear.
Once you have verified that your R2 CWA server appears correctly, right click where it says Lync Server 2010 and choose Publish Topology.
Once you have published your topology, we will have one last step to verify our web server was imported correctly.
Open the Lync Server Management Shell and run the following command: Get-CSTrustedApplication
This command will return trusted applications that are associated with Trusted Application Servers and Trusted Application Pools in your environment, you may have many depending on your topology. However the two we are looking for, involve CWA.
Your output should return something similar to below:
I have crossed out my server names, however there should be the FQDN of your CWA server where I have marked.
The two entries represent the external facing web site that users hit, as well as the port that is used to communicate with the Lync front end, as you can see highlighted below, the port you assigned should be listed there.
You should now be able to login to CWA as a Lync Server 2010 user! If you run into issues, make sure to check out this blog relating to the SPN error related to CWA service accounts in R2.
Also, make sure that your CWA server is on the latest release of OCS 2007 R2 patches which can be found here:
I hope this helps you extend CWA capability to your Lync users, if you have any issues please contact me via the comments and I will try to help you the best I can.
In my first blog post around TMG 2010, I outlined the setup of TMG and configuration for publishing OCS 2007 R2 web components and then CWA services through that same server. Please reference that post for the basics around the network configuration for this TMG server, and I will cover configuring publishing rules for your Lync Server Simple URLs and web components in this post.
First, I assume you have configured simple urls and web services when deploying your topology, and now need to publish this externally.
My URL information is as follows:
|Component||URL||IP Internal||IP External||Port on Front End||Port on External/ISA|
|Web Services||lyncweb.winxnet.com||10.117.117.9||126.96.36.199||8080 and 4443||80 and 443|
|Dialin Simple URL||dialin.winxnet.com||10.117.117.9||188.8.131.52||8080 and 4443||443|
|Meet Simple URL||meet.winxnet.com||10.117.117.9||184.108.40.206||8080 and 4443||443|
First off, let me point out by saying that you can use a single external IP address for all three of these URLs, as they go to the same place. Also, if you open IIS manager on your front end server, you will notice there is an internal, and an external site, the internal listens on 80 and 443, and the external on 8080 and 4443. When proxying requests through TMG, you will be sending external clients to the external site, listening on 8080 and 4443.
Also, one not so commonly known fact is that the Meet simple URL is required to provide external access to meetings. You will notice when clicking on the link to Join Online Meeting in your outlook, it is directing you to your meet simple URL.
As far as certificates go, you must also have a certificate with the following names:
Common Name: lynecwebservicesexternalurl.domain.com (lyncweb.winxnet.com
Subject Alt Name(s): meetsimpleurl.domain.com,dialinsimpleurl.domain.com(meet.winxnet.com,dialin.winxnet.com)
Import this certificate to the TMG server, and you can proceed with the following steps for configuration.
Another important thing regarding DNS:
If you have a separate internal domain name, you will need split brain DNS to get this working. You should already have split brain DNS configured to get your internal clients to work with auto signin.
For example, if your internal domain name is winxnet.local and your external is winxnet.com, your simple urls should be for the winxnet.com namespace, however you will need to resolve the winxnet.com simple URLs to the correct internal address.
At winxnet, we actually have a single namespace, winxnet.com so it was an oversight to point out the fact that you would need these DNS entries resolvable
internally and externally for this to work.
Thanks to Adam in the comments for pointing this out and working through the issue with me. Check out this link for a great review on how this DNS
configuration works for the rest of the services:
Steps to Create Publishing Rule
While in the TMG or ISA management console, Right click on Firewall Policy and choose New->Web Site Publishing Rule
Enter a name for the rule like Lync Web
Follow the wizard with the following options:
Select Rule Action : Allow
Publishing Type: Publish a single web site or load balancer
Server Connectivity Security: Use SSL to connect to the published Web server or server farm
Internal publishing details:
Internal Site Name: FQDN of front end server (winx-lyncrc1.winxnet.com)
If your internal server is a Standard Edition server, this FQDN is the Standard Edition server FQDN. If your internal server is an Enterprise pool, this FQDN is a hardware load balancer VIP that load balances the internal Web farm servers. The TMG Server must be able to resolve the FQDN to the IP address of the internal Web server. If the TMG Server is not able to resolve the FQDN to the proper IP address, you can select Use a computer name or IP address to connect to the published server, and then in the Computer name or IP address box, type the IP address of the internal Web server. If you do this, you must ensure that port 53 is open on the TMG Server and that it can reach an internal DNS server or a DNS server that resides in the perimeter network.
Path (optional): /*
Public Name Details:
Public Name: FQDN of external web services (lyncweb.winxnet.com)
Select Web Listener: Select New(This will open the new web listener wizard)
Web Listener Name: Anything you want, something like Lync Web Listener)
Client Connection Security: Require SSL secured connections with clients
Web Listener IP Address: Select External and then Select IP Address choose the appropriate IP address and add it to the listener
Listener SSL Certificates: Select Assign Certificate for Each IP Address, select the IP associated before, and choose your valid certificate.
Authentication Setting: No Authentication
Single Sign On Setting: Ignore, click Next
Complete the web listener wizard and choose Finish
Authentication Delegation: No Delegation, but client may authenticate directly
User Set: Ignore, click Next
Complete the rule configuration wizard and choose Finish. Then at the top hit Apply to save the configuration.
Once the rule is created, there are a couple important settings that need to be changed, this is really the only thing that makes the Lync setup different from OCS R2.
Open the newly created rule and modify the following settings.
On the To tab, ensure that the Forward the original host header instead of the actual one check box is checked.
On the Listener Tab, click to modify the properties of the web listener
Navigate to the Connections tab and enable port 80
On the Bridging tab, select to Redirect requests to SSL port and Redirect requests to HTTP port, enter 8080 and 4443 for your ports.
On the Public Name tab, add the Simple URLS to the list of allowed public names. In my example: meet.winxnet.com and dialin.winxnet.com.
Once these changes have been made, Apply the configuration and you are done. To verify access, you can test the following URLs in Internet Explorer.
For address book server: https://externalwebservicesfqdn/abs (https://lyncweb.winxnet.com/abs) You should receive an HTTP challenge, because directory security on the ABS folder is configured for Windows Authentication by default.
For Web conferencing: Generate an online meeting request in Outlook, or a meet now request in Lync 2010, try joining the URL provided from external, it should be similar to this: https://meet.winxnet.com/rwintle/KG2K4HDM
You should now have functioning simple URLs and web services which provide the following functionality:
- Enabling external users to download meeting content for your meetings.
- Enabling external users to expand distribution groups.
- Enabling remote users to download files from the Address Book Service.
- Accessing the Reach client
- Accessing the dial-in Web page
- Accessing the Location Information Service
- Enabling external devices to connect to Device Update Service and obtain updates.