ForeFront TMG – B4Z.co.uk

Lync Server 2013 Migration – Mobile Devices Issue

September 28, 2013 Leave a Comment

I recently performed a Lync Server 2013 migration whereby the customer would phase users over to the new front end pool over a reasonably long period of time. This particular customer had a high dependency on mobile devices, so there operation during the coexistence phase was required no matter what front end pool the user resided upon. From my own research I have generally found that mobile device support when in coexistence is reasonably poorly documented and TechNet social posts seem to confirm this also. My particular issue was related to either Lync 2010 or Lync 2013 mobile applications not functioning when a user was moved from the Lync Server 2010 pool to the Lync Server 2013 pool. In a slightly different approach to most of my other blog entries, here is a summary of the environment where the problem occurred.

Experienced Issue

When moving a user from the Lync Server 2010 front end pool to Lync Server 2013 front end pool, the user was unable to sign into the Lync 2010/2013 mobile applications internally or externally. The following setup had been implemented:

1. Lync Server 2010 and Lync Server 2013 are in a coexistence state.

2. The reverse proxy (Forefront TMG 2010) is configured to send web services traffic to the Lync Server 2010 front end.

3. The Lync Server 2013 pool has the same external web services FQDN as the Lync Server 2010 pool.

After some investigation into this issue, I found this interesting paragraph in Doug Deitterick’s blog:

“When in co-existence with Lync Server 2010, your Lync autodiscover URLs can still resolve to a Lync Server 2010 Front End Server or Director. The Lync autodiscover service will be return the correct external web services FQDN for your user based on your homed pool. The media traffic from the Lync 2013 mobile client can also use a Lync Server 2010 Edge Server.”

This explained my problem was web services orientated and my issue was occurring because my Lync Server 2o13 front end pools web services FQDN was the same as my Lync Server 2010 front end pools web services FQDN and therefore causing mobile application login failures for users who had been migrated.

Issue Resolution

To resolve the aforementioned issue, I had to ensure that mobile application requests for Lync Server 2013 users were directed to the Lync Server 2013 front end. In order to ensure this I performed the following.

1. Changed the Web Services URL for the Lync Server 2013 front end to webservices2013.domain.com in the Topology Builder and published the changes.

2. Regenerated the Consolidated Edge Server certificate, that also contained my web services URL, to include the new webservices2013.domain.com entry. Additionally a global DNS record for webservices2013.domain.com was created, pointing to the same IP address as the Lync Server 2010 web services address.

3. Imported the new SSL certificate as detailed in step 2, onto the customers Forefront TMG 2010 server and created a new reverse proxy rule that had a only a single public name of webservices2013.domain.com which in turn pointed to the Lync Server 2013 front end pool. The Lync Server 2010 proxy rule was left intact with the exception of updating its SSL certificate to the one created in step 2, as the original certificate it was using had now been revoked following the regeneration.

Following these changes, when a mobile application performs a user sign in the following occurs:

Application Sign-in Request -> lyncdiscover.domain.com traffic passed to Lync Server 2010 front end -> User identified as being homed on Lync server 2013 -> Autodisover returns a web services URL of webservices2013.domain.com -> Mobile application signs in via webservices2013.domain.com

That’s it, by implementing separate web services name spaces in a migration scenario you can retain mobile application functionality when in coexistence.

ISA To TMG – Site To Site IPSec VPN

September 18, 2010 Leave a Comment

I recently encountered an issue creating a site to site IPSec VPN tunnel between Microsoft ISA Server 2006 and Microsoft Forefront TMG 2010. The IPSec tunnel itself would establish correctly, however I found I could only contact resources at either end of tunnel if I initiated the connection from either the ISA or TMG servers themselves. If I attempted to send a PING command from a workstation on the ISA internal network, to a workstation on the TMG internal network it would simply timeout. CIFS, FTP and web traffic all suffered the same fate.

After creating the topology in a test virtual environment, I was able to replicate the exact same issue I was experiencing in the production environment. After a few days of performing traces, I contacted Microsoft Partner Support to ask if they had experienced this problem before. They informed me they had and it was addressed in post SP1 hotfix KB 980674. Even though my TMG toplogy did not contain an NLB, and the KB article specifically states the hotfix is for NLB topologies, it resolved my issue never the less. To ensure your ISA to TMG IPSec site to site VPN works correctly ensure the following actions are performed:

1. Ensure the name of the IPSec VPN is the same on both the ISA and TMG servers. For example, in the site to site VPN wizard on your TMG server, if you name the tunnel “IPSec VPN” this name must also be used when you set the tunnel up on the ISA server.

2. Change the IPSec Phase 1 and Phase 2 security settings on your TMG server to match those on your ISA server. By default, TMG uses a higher level of IPSec encryption than ISA. You can obtain the IPSec security settings by reviewing them in the properties of the site to site VPN tunnel as shown in the below screenshot.

3. Ensure the network address ranges you assign in the site to site tunnel wizard are correct. For example, if you are setting up the VPN connection on your TMG server and the ISA servers internal network address range is 172.16.10.0 – 172.16.10.255 you must specify the network in the tunnel wizard as 172.16.0.0 – 172.16.255.255, otherwise traffic will not pass over the tunnel correctly.

4. Ensure your ISA and TMG servers are fully service packed and all hotfixes are applied, in particular hotfix KB 980674 on your TMG server, even if you do not have an NLB configuration.

Hopefully this help will solve any cross platform IPSec VPN issues you are experiencing.

OCS 2007 R2 – External Audio/Video Conferencing Issues

September 9, 2010 1 Comment

The successful implementation of external audio/video conferencing in Microsoft OCS 2007 R2 appears to be an issue that many people face when deploying the product. I too have experienced this issue and this post will detail both the errors and resolutions put in place to enable external A/V conferencing on an OCS 2007 R2 Standard Edition deployment with a Consolidated Edge server. The implementation item’s listed in this post assume you have a firewall product in front of the Consolidated Edge server that is performing both resverse proxy and NAT features.

1. External A/V Conferencing – Errors

When testing multiparty A/V conferences I experienced the following errors. These errors were produced when adding a third participant to an existing two party (peer to peer) A/V conference.

Cannot perform the selected action. This action may not be permitted by the conferencing service. Please try again. If the problem persists, please contact your system administrator.

The call was disconnected because you stopped receiving audio from [email protected]. Please try the call again.

An error occurred while trying to take the call off hold. If the problem persists, contact your system administrator. More details (ID:500)

An error occurred while trying to start the conference. More details (ID:52031)

As you can see, there is not a single persistent error that is produced which unfortunately makes troubleshooting slightly more difficult. After spending some time performing SIPStack traces and reviewing Communicator logs via the Snooper Tool, I narrowed the errors down to a firewall and consolidated edge server configuration issue.

2. External A/V Conferencing – Resolution Items

The item’s listed below resolved the external A/V conferencing issues I was experiencing. These steps are also included in the official Microsoft production documentation for Consolidated Edge server deployments.

A/V Edge Service Name Resolution– Configure the Edge Server to resolve the FQDN associated with public A/V Edge service to the publicly routable IP Address, not it’s internal NAT’d IP address. For example, if your A/V Edge service has a public IP address of 100.200.255.255 and a NAT’d IP address of 10.45.16.5, if you run a command prompt from the Edge Server and type ping av.externaldomain.co.uk it must return 100.200.255.255. A good way of achieving this is making a hosts file entry on your Edge Server to force the FQDN to resolve to the public IP address.

A/V Edge Service NAT– Assuming you have a firewall product (ISA/TMG) in front of your Consolidated Edge server that is performing NAT, configure the A/V Edge service to support NAT by checking the “External IP address is translated by NAT” checkbox. This setting can be found under the Edge Servers properties dialog box.

Firewall Access Rules– Configure your firewall product with the following protocol definitions to allow A/V traffic to be passed to your Consolidated Edge server. Once you have performed this, create a new server publishing rule that targets your Consolidate Edge server and utilises the protocols you have just created. Please note the below protocol definitions target ISA/Forefront TMG deployments specifically. A very useful article on performing this can be found here.

Protocol name	AV TCP In
Protocol type	TCP
Direction	Inbound
Port Range	50000-59999

Protocol name	AV UDP in
Protocol type	UDP
Direction	Receive/Send
Port Range	3478, 50000-59999

Testing Access – If you are using internal clients to perform multiparty A/V testing then ensure those clients have unrestricted access through your internal firewall. I experienced an issue where outbound traffic from my test clients was being blocked by my internal firewall, which in turn created additional issues. Ensure you have complete outbound access for your test clients and then scale back access from there.

I hope this assists your external A/V conferencing implementation.

ForeFront TMG & GFI MailEssentials – Updating Issues

July 19, 2010 Leave a Comment

I have recently experienced an issue on several deployments of Microsoft ForeFront Threat Management Gateway in conjunction GFI MailEssentials 2010. When installing GFI MailEssentials on a server running ForeFront TMG, a configuration error occurs in the MailEssentials config.mdb file which incorrectly points the spam definition updating entry to “C:\Program Files\” opposed to “C:\Program Files (x86)\”. Due to this, updates for spam modules such as Phishing and SpamRazer do not download correctly and as a result you may experience the following error:

Despite the error stating the problem occurred due to a “network error”, it certainly is not and several hours of testing with ForeFront TMG’s own monitoring utilities and WireShark proved this theory correct. To resolve the issue, please perform the following actions:

1. Stop all GFI MailEssentials services and the Message Queuing service on the server running GFI MailEssentials 2010.

2. Click Start, and select Run. In the Run dialog box type the following without quotations “iisreset /stop” , and click ok

3. Navigate to the folder “C:\Program Files (x86)\GFI\MailEssentials” and copy the config.mdb file to a workstation that has Microsoft Access 2003 or higher installed.

4. Open the config.mdb file in Microsoft Access and open the table named “au_profiles”. In this table locate the “localpath” entry and change this to be “C:\Program Files (x86)\” opposed to “C:\Program Files\”

5. Save the amended config.mdb file and then copy this to the “C:\Program Files (x86)\GFI\MailEssentials” directory on your server, choosing to overwrite the existing file.

6. Click Start, and select Run. In the Run dialog box type the following without quotations “iisreset” , and click ok.

7. Start all GFI MailEssentials services and wait for, or manually update your anti-spam module definitions.