Category Archives: CWA
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 previous post I outlined configuring Forefront TMG 2010 to publish the OCS 2007 R2 web components. Please see that post for basic installation instructions and network configurations.
In this post, I will outline publishing Communicator Web Access (CWA) to the internet using Forefront TMG 2010.
DNS Records and Certificate Requirements
First lets cover the new DNS records and certificate entries required for communicator web access. With the addition of desktop sharing to CWA, additional DNS records and certificate entries are required to provide that functionality.
The following DNS records are required for CWA:
CWA Desktop Sharing
CNAME to cwa.domain.com
CWA Desktop Sharing
CNAME to cwa.domain.com
Your certificate will need to have all of the names above on it.
In my environment I have the following certificate information:
Common Name: cwa.winxnet.com
Subject Alt Name(s): as.cwa.winxnet.com download.cwa.winxnet.com
CWA Web Site Configuration
In my example I have two web sites configured on the CWA server. One for internal access and one for external access. When you create virtual servers for CWA you have two options for site types, Internal and External. The only difference is authentication type. Internal sites will let you choose NTLM authentication, which allows for simple access from inside the corporate network on domain joined machines. External sites will use Forms-Based Authentication, or Custom Authentication. Custom authentication can be used to perform two factor authentication with services like RSA or other smart card/pin authentication methods.
In our example our Internal site will be a standard internal site listening on port 443. Our external site however will run on port 4443, and we will perform bridging with the forefront TMG server to give users access to this site.
I will outline creating the external web server, assuming an internal web server has been configured listening on port 443.
First, open the Communicator Web Access management console, this is separate from the OCS 2007 R2 primary admin console, but is included when you install the admin tools on any machine.
Right click on the server name and choose Create Virtual Web Server.
At the next window, this is where you will choose your web server type, choose External.
The next window allows you to choose your authentication types. If you were using a third party authentication method you would specify it here. Although it says in the description that the built in windows integrated and forms-based authentication will be used, the external web site will only allow Forms-Based Authentication.
The next window confirms those authentication settings, notice NTML is grayed out.
The next screen has you specify an SSL certificate to be used with the https requests. You can choose HTTP if you are using an SSL Accelerator device, but you cannot use CWA over HTTP without such a device.
Choose the certificate you created with all the necessary name entries and hit Next
The next screen has you specify the IP address and port the web site will listen on. If you have an additional IP address you can use port 443 with a separate IP than your internal server. In our example, I will be using a single IP address and utilizing bridging with Forefront TMG, so I will enter the port as 4443.
On the next screen, enter a name to identify the external web site such as CWA External.
The next screen has you specify a port to listen to OCS traffic. This is seperate from the web site listening settings. This port is really important if you are collocating OCS Services, or even in this case where we have multiple CWA virtual servers on the same server. This port really does not matter, as long as it does not conflict with another port on the same server used for OCS Traffic. In my case I am entering 5071, my internal server listens on 5070.
At the next screen you must specify a Next Hop Pool, this drop down will display all the pools in your environment and allow you to choose a pool and listening port. In my case our poolname is ocs.winxnet.com.
Hit Next twice to confirm your settings for the new virtual server, the wizard will create the virtual directory and start the web site for you. As with all of the OCS installations, a log is available at the end for success and failure.
Now review your two sites, a screenshot of how the site summary should display is below.
Now that the OCS configuration is complete, we will configure Forefront TMG Web Site Publishing rules to allow traffic to your CWA services.
Forefront TMG 2010 Configuration
My last post reviewed networking configurations for this Forefront server. You can get away with a single External/DMZ IP address for all of these services if you have a single certificate with all of the names. In my case I have multiple certificates, so another IP address will need to be assigned to the DMZ network card on my Forefront TMG 2010 server.
Once you have added your external IP address, and imported the certificate used on your web server; (See my last post for instructions on both of these steps). We will now create the web site publishing rule for CWA.
Right click on Firewall Policy and choose New->Web Site Publishing Rule.
For a rule action, choose Allow. Hit Next
For the Publishing Type choose Publish a single web site or load balancer. Hit Next.
For Server Connection Security choose Use SSL to connect to the published Web server or server farm. Hit next.
For your internal site name, you will want to specify the same Internal/External site name, whatever is the common name on your certificate, in my case it is cwa.winxnet.com.
If you cannot resolve the name correctly from the TMG server, or want to specify a different computer to connect to for that name, you can do so by specifying a computer name or IP Address.
Once you have made the necessary entries, hit Next.
For internal publishing details, under path type /* to allow all sub directories required by CWA. Hit Next.
Under Public Name Details enter the public name for your site, and hit Next. In my case it is cwa.winxnet.com.
On the next page to specify a web listener, choose New.
In the new web listener wizard first page, enter a name for the listener like CWA.
For Client Connection Security choose Require SSL secured connections with clients.
On the Web Listener IP Address page, select the check box next to External, highlight external and choose Select IP Addresses… On this next page, specify the IP address you set aside for CWA.
Hit Next, on the next page for Listener SSL Certificates, highlight the IP Address selected on the last page and choose Select Certificate… Choose your valid certificate and choose Select. Hit Next.
For Authentication settings, choose No Authentication.
Because we chose No Authentication, we have no SSO options, just choose Next.
Review the settings for your listener and hit Finish.
With your listener selected from the drop down menu, hit Next.
For Authentication Delegation choose No Delegation, but client may authenticate directly. Hit Next.
Leave the default settings for User Sets and hit Next.
On the next page, select Test Rule to verify all rule settings are correct. If the result is OK, hit close, then select Finish.
Make sure to Apply your settings to the Forefront TMG server before continuing.
If you had a separate IP address for you internal site, and your external site you do not need to do the next step. This next step will configure bridging to direct our user request to port 4443 for this external virtual server.
Right click on your CWA rule and choose Properties.
On the Properties page, select the Bridging tab.
Where it says Redirect requests to SSL port, enter port 4443, or whatever port you specified during your website configuration. Hit OK.
Again, apply your changes before continuing.
You can test the rule again from the Properties page. Simply open the Properties page for the rule and Test Rule will be an option there. If the test returns OK, continue to test your site from a computer outside the network.
Testing and Known Issues
You can test access to this site from Internet Explorer outside the network, you should simply be able to specify the https:// URL of your site, and TMG 2010 will handle bridging the request to the correct virtual server on the CWA server. You can also use CWA for access to a great IPhone OCS App called iDialog by Modality Systems.
A very common known issue for CWA configurations is receiving the error Cannot sign in because your computer clock is not set correctly or your account is invalid. (Error Code: 0-1-492)
This is an easy fix, and has to do with Service Principal Name (SPN) settings for the CWA Site.
To fix this issue, simply add the correct SPN to your CWA Service Account. This is the account specified during CWA installation to run the service.
You can modify this setting using ADSI Edit, and looking for the attribute servicePrincipalName.
Other than those two instances, this configuration is pretty straight forward and just works.
CWA Error through F5 Load Balancer: Your Connection was ended. Please Sign in Again. (Error Code: 0-1-482)
On a recent deployment we deployed CWA internally and externally using ISA Server 2006. The customer decided they wanted to provide high availability to the CWA service, so we introduced a hardware load balancer to provide that functionality. After we set the two servers with identical site settings behind the load balancer we started having users receive this error when connecting to the CWA site:
At first glance deploying CWA through a load balancer would seem pretty basic, they are websites you access over https, however there is some key information in the R2 Documentation for deploying CWA behind a load balancer. http://technet.microsoft.com/en-us/library/dd441196(office.13).aspx
Communicator Web Access supports most hardware load balancers, provided that the load balancer:
- Allows you to set the TCP idle timeout to 1,800 seconds (30 minutes). The TCP idle timeout represents the amount of time the server will wait for information during a session. If you are using a reverse proxy server (such as Microsoft Internet Security and Acceleration Server) then the TCP idle timeout on that computer should also be set to 1,800 seconds.
- Allows you to use a source network address translation (SNAT) pool if you need to handle more than 65,000 simultaneous connections. SNAT is designed to "hide" multiple servers behind a single IP address (that is, a number of servers can be accessed using just one IP address). With a SNAT pool, servers can be hidden behind multiple IP addresses.
- Allows you to use cookie persistence when configuring session affinity. With cookie persistence, information about the actual Communicator Web Access server being used for a session is stored in an Internet cookie on the client computer. When configuring the load balancer’s session persistence profile it is recommended that you use "HTTP Cookie Insert." With this configuration method, information about the server to which the client is connected is inserted in the header of the HTTP response from that server as a cookie.
Our issue was related to the persistence profile. When a user connects to CWA they must maintain a connection to the same server as the initial connection or it will not work. The persistence profile, using a HTTP Cookie Insert method will enable this persistence.
We were using an F5 BIG IP LTM Load balancer for this deployment, we actually chose “Source Address Affinity”. Below you can seen a screenshot of the persistence profile used in this configuration.