Using Lync 2010 Mobility on your Corporate WIFI Networks
Lync 2010 Mobility 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 networks which I haven’t seen documented in very good detail on Technet or other blog articles. Now keep in mind, this blog article is for deploying Lync Mobility on your corporate wifi networks, not your guest wifi networks. Basically, any wifi network that can access your Front End Servers.
There are two considerations to take when deploying Lync 2010 Mobility on your Corporate WIFI Network that you need to be cognizant of after reading Jeff Schertz’s Mobility article and the official Mobility documentation:
- Certificates
- Talking to the External Mobility Services
Certificate Issues for Lync 2010 Mobile Clients Connecting over Corporate WIFI
If we take a look at Jeff’s article or the official Lync Mobility document, we can see that there is an FQDN we add to internal DNS:
- lyncdiscoverinternal.domain.com
The basic process for how the Lync 2010 Mobile Client will connect to Mobility Services while on a corporate WIFI network is as follows:
As we can see by the above, the Lync 2010 Mobile client does a lookup for lyncdiscoverinternal.domain.com. It is because of this, the Lync Mobile documentation has us replace the certificate on our Front End Servers. Now with that said, that means that any request to Lyncdiscoverinternal.domain.com will eventually terminate (SSL termination) against our Front End Server. Now in the majority of deployments, the Front End Servers and Internal Edge NIC will have certificates signed by your internal certificate authority.
Now with that said, that means that Mobile clients will have some issues with connectivity to Lync 2010 Mobile Services as lyncdiscoverinternal.domain.com would be signed by your internal certificate authority. Domain-Joined machines will automatically have most likely have a copy of your Root Certificate Authority’s self-signed certificate. If your Root Certificate Authority is an Enterprise Root CA, it automatically publishes its certificate to Active Directory. When domain joined machines sign into AD, they will install these certificates. For Standalone Root CA’s, you have probably used Group Policy to publish your Root/Intermediate certificates or used certutil -dspublish. The issue here is that these Mobile Devices do not have a copy of your internal Certificate Authority’s certificate. Thus, they will have certificate/connectivity problems when on the WIFI Network.
My experience at a previous client with the different mobile devices have shown the following results:
- Windows Phone 7: Seemed to function even without the root certificate. The WP7 seem to employ some kind of silent fallback mechanism to connect to the external network and attempt to find the external web services name.
- IOS 5: Retrieved an error that we could not connect to the server without any certificate warning. It just would not connect to the server. After importing the root certificate on the IOS device, we could connect without any issue.
- Android: Retrieved a certificate warning. We were presented with a connect button on the bottom left which allowed the user to connect regardless of the warning/error that they received about not trusting the server they were connecting to.
Now, these certificate warnings may be unacceptable to your organization. If they are, you will want to replace your Front End/IIS Certificate(s) with a certificate from a Public Certificate Authority. Keep in mind you will want to replace the internal Edge Server’s certificate with a Public Certificate as well. I have seen issues where if the Front End and Internal Edge had certificates from different CAs, they would stop replicating with each other. This bug may have been fixed as this happened several months ago when Lync 2010 was still relatively new.
However, other than having Public Certificates in the entire infrastructure, there is another method.
How to prevent certificate errors and still utilize internal certificates on your internal Lync 2010 infrastructure
There is a method you can use to get Lyncdiscoverinternal.domain.com to function without needing to configure your Lync 2100 Front End Servers and Lync 2010 Edge Server’s Internal NIC with a public certificate. Another method in which you can use to prevent certificate errors is by having all LyncDiscoverInternal.domain. requests go to your Reverse Proxy which will use a Public Certificate. By taking a look at the Lync Mobility documentation, we can see that both 80 and 443 can be used to service Lync Autodiscover Mobile requests. Because of this, we can have TMG also service LyncDiscoverInternal.domain.com requests. A couple options here would be to:
- On the Web Services rule for Lync 2010 which handles Simple URLs and the External Web Services FQDN, we can add all LyncDiscover.domain.com FQDNs (one for each SIP Domain) as well as all LyncDiscoverInternal.domain.com (one for each SIP Domain).
- Create a new Web Listener and Web Services rule for Lync 2010 Mobile Autodiscover requests that handle Lync 2010 Autodiscover Only. This Web Listener will listen on port 80. The Web Listener will bridge to 8080 on the Front End Server or Hardware Load Balancer that services the Lync 2010 Pool. The Mobile Client, as stated earlier, will attempt both HTTP and HTTPs for Autodiscover. Because the Autodiscover FQDNs will point to the Reverse Proxy (ISA/TMG), HTTP will work for Autodiscover and the client will successfully connect.
In taking a look at the following diagram that is provided in the Lync 2010 Planning Documentation, the DNS record on the far right, lyncdiscoverinternal.contoso.net would point to the NIC on the Reverse Proxy Server. This would require you to ensure that internal communications over either 80 or 443 (depending on which scenario above is used) so autodiscover requests from the Lync 2010 Mobile client on WIFI networks function properly.
To verify that LyncDiscoverInternal.domain.com functions properly while on the Internal WIFI Network, connect to the WIFI Network and use the following Autodiscover URL to test Autodiscover Connectivity:
The following Autodiscover results are provided back to Internet Explorer. As you can see, it provides Redirect Information on where the client should now connect to make a successful Autodiscover Request:
We will use the following new URL to see the entire Autodiscover result:
This provides us with the new following results. As you can see, the MCX URL we use is the External Web Services FQDN. This means that even if we have a client on the internal corporate WIFI, they must connect to the external web services FQDN that is published through TMG.
Another way to look at the Autodiscover response is by taking a look at the Lync client’s Mobility Diagnostic Log. For information on how to view these diagnostic logs, please see Randy Wintle’s article here. The following XML data will be seen which is formatted a bit differently than viewed above:
All Lync Mobile clients must connect through the external web services FQDN
So by now, we realize that a Mobile Client on the corporate network must connect through external web services. This means we must do the following:
- Create our external web services FQDN (ExternalWeb.domain.com) in our internal DNS infrastructure that mobile clients resolve against. This FQDN will point to the Public IP of External Web Services. Essentially, the DNS record created in External DNS and the DNS record created in Internal DNS will be identical.
- Allow our mobile client connected to WIFI to connect to external web services. This will be done by hairpinning. Essentially, this means if the mobile client when connected to WIFI must connect out to the 131.x.x.50 (in this example, 131.x.x.50 will be our external web services IP pointed to the external interface of TMG) and then back into the NAT’d IP of TMG without completely going out to the internet. Thus the traffic is hairpinned.
Now I’m sure the following question is going through your head: Why must we have all mobility services connect to the External Web Services FQDN and why aren’t we using the Pool and Edge Server just like the Lync 2010 client installed on Desktop Operating Systems? There are a couple answers to this question:
- SIP protocol by nature has long hold times. HTTP protocol by nature has short hold times. Mobile clients these days have the ability to switch between WIFI and cellular networks in a very fast if not seamless manner. By having Lync 2010 Mobile clients use HTTP which have short hold times, Lync 2010 Mobile Clients can mantain connectivity during this WIFI to cellular (and vice versa) transition.
- The reason why we always want to connect to external web services is because now that we understand why we are using HTTP based on the above bullet, we want to maintain connectivity to the same location to ensure a faster/smoother transition between WIFI and cellular (and vice versa) networks. We must also maintain the same persistence while maintaining these connections. Having the clients connect to the same place and maintaining affinity (if using HA and a certificate for cookie based affinity on the HLB) we can maintain affinity from your Mobile Client to the Reverse Proxy to the Hardware Load Balancer and then to the Front End Pool Servers.
An Alternative Way to connect to external web services without the use of hairpinning (Less Preferable than Hairpinning)
Let me start this by saying, this method is not reconnected due to extra traffic and burden on your bandwidth and DNS Servers. If for whatever reason, you cannot hairpin the traffic so the internal WIFI network can communicate to the external web services public IP address, would be to point the external web services FQDN that is located in Internal DNS to the Internal IP address of your Reverse Proxy Server. With this mechanism, when the Mobile Client while connected to WIFI gets the external Web Services FQDN while on Internal DNS, they will get a private IP response and connect to Reverse Proxy in that fashion. When an internet connected mobile device gets the Autodiscover Response and does a DNS lookup, they will receive the Public IP address of External Web Services.
Now if you have read the bottom 2 bullets in the section entitled, “All Lync Mobile clients must connect through the external web services FQDN” you will understand that this method goes against the Mobility model. One of the ways to alleviate issues when switching between WIFI and cellular networks (and vice versa) would be to change the External Web Services FQDN (in both internal and external DNS) to have a lower TTL value or even a TTL value of 0. This way, when a mobile client switches from WIFI to cellular (or vice versa), they will do a new DNS lookup since the TTL value is 0 and find the new IP address and successfully connect. This will obviously not be a seamless transition but it does provide a method of being able to reestablish a connection. But, this also means that Mobile Clients and all other Lync 2010 Clients (Phone Edition, desktop client, etc.) will constantly have to do DNS lookups which will now cause more network utilization as well as DNS Server Utilization. So if it is decided this is the roue that will be taken, be sure to be aware of the negative ramifications that this ensure.
Elan Shudnow :: Mar.12.2012 :: Lync 2010 :: No Comments »
Enabling QoS for Lync Server 2010 – Part 2
Welcome to Part 2 on how to Enable QoS for Lync Server 2010. The purpose of this multi-part article (first part for QoS on Lync Client and second part for QoS on Lync Server) is to lay everything out in a concise manner to help you, the reader, understand how to enable QoS. Keep in mind that this article is only for the ability to enable QOS, it is not a comprehensive guide on all the various dynamic ports available in Lync to lock down your firewalls. For that, you can check out my other article here. Second of all, the question may arise, why and when would you want to enable QoS. Audio and Video are synchronize traffic that can be affected by jitter, delay, and packet loss on an IP Network. Lync has been designed to work without QoS but Lync Administrators can choose to enable both Lync endpoints as well as servers to mark Differentiated Services Code Point (DSCP) values on audio and video packets. This ensures that audio/video packets get prioritized on a network that is enabled for Differentiated Services (DiffServ).
To better understand DiffServ and its affect on the network, please check out the excellent blog article written by fellow Lync MVP Jeff Schertz at the following URL: blog.schertz.name/2011/08/lync-qos-behavior/
Part 1
Part 2
Server QOS
General Procedure for Server QoS
In Part 1, we talked about Windows Vista/7 vs Windows XP. Windows 7 and Windows Vista utilize Policy based QoS and Windows XP used QoS based on the Packet Scheduler. For Lync Servers, you’ll always use Policy based QoS since Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2 which both utilize Policy based QoS. For Server based QoS, we can configure Conferencing Servers, Application Servers, and Edge Servers (which will use QoS based on the destination port rather than the source port as everything else does).
Client to Server Port Configuration for Conferencing Servers and Application Servers
Client to Server Port ranges are out of the box different for all modalities except for Application Sharing. The default ports for a Conferencing Server are as such:
- Audio: 49152 to 57500
- Video: 57501 to 65535
- Application Sharing: 49152 to 65535
At least 40 ports minimum are required for Application Sharing. We will specify a 8,348 port range that is unique from other ports. Ultimately, we will set Application Sharing to use the following ports:
- Application Sharing: 40803 to 49151
To set this, we will run the following command:
Configuring an Application Server is identical. The only difference is that you use the Set-CSApplicationServer command instead of the Set-CSConferencingServer. Make sure to include these ports in the QoS Policies for Edge Servers as you will learn later.
Client to Server Port Configuration for Dedicated Mediation Servers
A Mediation Server of course only handles Audio since it’s job is to transcode RTAudio to G.711. The default ports for a Mediation Server are as such:
- Audio: 49152 to 57500
No Changes to this port range will be required. If the Mediation Server is collocated on a Front End Server, no changes will need to be done as you can see the Audio Port Range for a dedicated Mediation Server is the same as the Audio Port Range for a Front End Conferencing Server.
Edge Server Policy Configuration
An Edge Server doesn’t get configured per se. But the policy that you create is based on a destination port (rather than source port like client peer to peer or client to server). The destination port configuration in the QoS Policy is configured based on the client peer to peer ports you defined in Part 1 of this article series as well as the client to server ports you defined in this Part 2 of this article series.
So if we take a look at everything we’ve done so far, we have the following peer to peer configuration from Part 1 of this article series:
- Audio: 20000 to 20039
- Video: 20040 to 20079
And we have the following client to server configuration from Part 2 of this article series:
- Audio: 49152 to 57500
- Video: 57501 to 65535
- Application Sharing: 40803 to 49151
The Edge QoS Policy will need to have several QoS Policies configured to handle each modality (Application Sharing not as critical as Audio/Video but can be enabled) for peer to peer (Audio/Video) and client to server (Audio/Video). Additional QoS Policies may be needed depending on Application Servers in the environment and whether they have any different port ranges from your Peer to Peer or Client to Peer port configurations.
Configuring Policy Based QOS in Group Policy for Windows 2008 and/or Windows 2008 R2 for a Conferencing Server
As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2. Both Windows 2008 and Windows 2008 R2 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.
In the below example, we will show how to create the Policy-based QoS for Audio. Once finished, be sure to also create Policy-based QoS policies for Video. The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS. Right-Click and choose Create new policy.
In the new Policy, give it a name and specify the DSCP Value. DSCP Values for audio is typically 46. Make sure the Outbound Throttle Rate check box is cleared. Click Next.
Because there are multiple applications that will stamp DSCP Values, we will choose All Applications. Click Next.
On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.” Click Next.
On the following screen, choose TCP and UDP. In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed. Because of this, our source port range will 49152 to 575000 specified as 49152:57500.
Let’s go ahead and set the DSCP Value for Video with a DSCP value of 34. Right-Click Policy-based QoS and choose Create new policy. In the new Policy, give it a name and specify the DSCP Value. DSCP Values for video is typically 34. Make sure the Outbound Throttle Rate check box is cleared. Click Next.
Because there are multiple applications that will stamp DSCP Values, we will choose All Applications. Click Next.
On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.” Click Next.
On the following screen, choose TCP and UDP. In our information above we stated the default video port range is 57501 to 65535 and does not need to be changed. Because of this, our source port range will 57501 to 65535 specified as 57501:65535.
If you would like Client to Server QoS for Application Sharing, feel free to also create a new QoS Policy that provides DSCP Values for the port ranges specified for Application Sharing. If you made this port range contiguous with Video, feel free to modify your Video QoS Policy to add the ports for Application Sharing if you are fine with also using a DSCP value of 34.
Now go ahead and restart your Lync Conferencing Servers so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:
Configuring Policy Based QOS in Group Policy for Windows 2008 and/or Windows 2008 R2 for a Dedicated Mediation Server
As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2. Both Windows 2008 and Windows 2008 R2 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.
In the below example, we will show how to create the Policy-based QoS for Audio only. The DSCP Value for Audio will be 46. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS. Right-Click and choose Create new policy.
In the new Policy, give it a name and specify the DSCP Value. DSCP Values for audio is typically 46. Make sure the Outbound Throttle Rate check box is cleared. Click Next.
Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that the Mediation Server uses utilizing the executable MediationServerSvc.exe. So make sure you choose the “Only applications with this executable name” and specify MediationServerSvc.exe. Click Next.
On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.” Click Next.
On the following screen, choose TCP and UDP. In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed. Because of this, our source port range will 49152 to 575000 specified as 49152:57500.
Now go ahead and restart your Lync Mediation Servers so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:
Configuring Policy Based QOS in Group Policy for Windows 2008 and/or Windows 2008 R2 for an Edge Server
As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2. Both Windows 2008 and Windows 2008 R2 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.
In the below example, we will show how to create the Policy-based QoS for Audio. Once finished, be sure to also create Policy-based QoS policies for Video. The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS. Right-Click and choose Create new policy.
In the new Policy, give it a name and specify the DSCP Value. DSCP Values for audio is typically 46. Make sure the Outbound Throttle Rate check box is cleared. Click Next.
Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that the Edge Server uses utilizing the executable MediaRelaySvc.exe. So make sure you choose the “Only applications with this executable name” and specify MediaRelaySvc.exe. Click Next.
Update (2/28/12) – I was informed that there is a bug and packets are not being stamped with DSCP if you specify MediaRelaySvc.exe. The documentation has you specifying MediaRelaySvc.exe but I have been informed that by specifying MediaRelaySvc.exe causes QoS on Edge to not work.
On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.” Alternatively, you can change the Source IP Address to the internal IP of your Edge. Click Next.
On the following screen, choose TCP and UDP. In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed. Because of this, our source port range will 49152 to 575000 specified as 49152:57500.
‘
I will not display the remainder of the QoS Policy configuration for the Edge as I’m sure by now, you are a master at configuring QoS Policies for Lync. The remainder of the three QoS Policies will look as such:
Peer to Peer Video:
- Policy Name: Lync Edge Peer to Peer Video
- DSCP Value: 34
- Only applications with the following executable name: MediaRelaySvc.exe
- Specify Outbound Throttle Rate is Unchecked
- Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
- Destination Port Range of 20040:20079
Client to Server Audio:
- Policy Name: Lync Edge Conferencing Audio
- DSCP Value: 46
- Only applications with the following executable name: MediaRelaySvc.exe
- Specify Outbound Throttle Rate is Unchecked
- Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
- Destination Port Range of 49152:57500
Client to Server Video:
- Policy Name: Lync Edge Conferencing Video
- DSCP Value: 34
- Only applications with the following executable name: MediaRelaySvc.exe
- Specify Outbound Throttle Rate is Unchecked
- Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
- Destination Port Range of 57501:65535
After all QoS Policies are created, reboot the Lync Edge Server. You should see the following registry changes:
Elan Shudnow :: Nov.28.2011 :: Lync 2010 :: 8 Comments »
Enabling QoS for Lync Server 2010 – Part 1
There’s a doc available by Microsoft on how to enable Quality of Services (QoS) in Lync which you can find here. The purpose of this multi-part article (first part for QoS on Lync Client and second part for QoS on Lync Server) is to lay everything out in a concise manner to help you, the reader, understand how to enable QoS. Keep in mind that this article is only for the ability to enable QOS, it is not a comprehensive guide on all the various dynamic ports available in Lync to lock down your firewalls. For that, you can check out my other article here. Second of all, the question may arise, why and when would you want to enable QoS. Audio and Video are synchronize traffic that can be affected by jitter, delay, and packet loss on an IP Network. Lync has been designed to work without QoS but Lync Administrators can choose to enable both Lync endpoints as well as servers to mark Differentiated Services Code Point (DSCP) values on audio and video packets. This ensures that audio/video packets get prioritized on a network that is enabled for Differentiated Services (DiffServ).
To better understand DiffServ and its affect on the network, please check out the excellent blog article written by fellow Lync MVP Jeff Schertz at the following URL: blog.schertz.name/2011/08/lync-qos-behavior/
So, let’s dive into my version of how to enable QoS. Shall we?
Part 1
Part 2
Client QOS
Windows 7 versus Windows XP
Windows Vista and Windows 7 utilize Policy based QOS. Policy based QOS has the benefit that you can restrict the QoS application at the application level. For Lync, this would be communicator.exe. Windows XP uses separate QOS Group Policy Options that do not allow you to restrict the DSCP values at the application level. This means that all applications that utilize the Audio/Video ports we configure for Audio/Video will get DSCP markings stamped.
Peer to Peer Port Configuration
All client port ranges need to be changed as they are all overlapping by default. Client Media traffic by default utilizing ports 1024 to 65535 when doing Peer to Peer. To specify the client media port ranges, Set-CSConferencingConfiguration must be used. The port ranges for each modality must not conflict with another modality. Also, it is highly recommended to ensure that when each modality is locked down to its own port range that all ports are contiguous as this will make configuring Group Policy later on a bit easier as you will see later on in the article.
The command used to