Lync 2013 EWS With Forefront TMG 2010 Issues

I recently performed a Microsoft Lync Sever 2013 migration and following this process I noted that Lync 2013 clients connecting from external networks were continually prompted for Outlook authentication in order to retrieve data from Exchange Web Services (EWS). After investigating the issue, it appears this occurs when utilising forms based authentication for the /Autodiscover/* and /EWS/* virtual directories when utilising an SSL web listener in Forefront TMG 2010. In order to resolve the issue a separate global IP address was obtained and assigned to a web listener that does not perform any pre-authentication and simply passes the authentication request directly to Exchange Server 2010. The reason a separate global IP address and web listener was utilised, is that should you be using a single web listener for all Exchange services you will need to disable forms based authentication for OWA, Outlook Anywhere and Exchange ActiveSync, in most environment this would not be a desirable approach, however using a separate listener purely for autodiscover and EWS satisfies most security requirements. The following steps were performed in Forefront TMG 2010 to resolve the issue.

1. In Forefront TMG 2010 right click “Firewall Policy” -> “New” -> “Exchange Web Client Access Publishing Rule”.

2. When the wizard invokes enter a name for the publishing rule such as “Exchange Web Services” and click Next.

3. On the select services page click the drop down item and select the appropriate version of Exchange Server for your environment, and then check to select “Outlook Anywhere (RPC\HTTP(s))” and then also select “Publish additional folders on the Exchange Server for Outlook 2007 clients” and then click Next.

4. On the Publishing Type page ensure that “Publish a single website or load balancer” is checked and click Next, on the following Server Connection Security page select “Use SSL to connect to the published web server for server farm” and click Next.

5. On the Internal Publishing Details page in the Internal site name dialogue box enter the fully qualified domain name of your Exchange Client Access Server and then click Next.

6. On the Public Names page enter the the fully qualified domain name used for external autodiscover, for example autodiscover.domain.com and then click Next.

7. On the Select Web Listener page click “New” and then enter and appropriate name for the listener and click next, on the following page select “Require SSL secured connections with client” and then click Next.

8. On the Web Listener IP address page, click External and then “Select IP Addresses” and continue to select the new global IP address that is to be used for Exchange Web Services and then click Next.

9. On the Listener SSL Certificate page click “Select Certificate” and then choose your third party SSL certificate for Exchange Services, this certificate must include the subject alternative name of autodiscover.domain.com, once selected click Next.

10. On the Authentication Settings page click the drop down item and select “No Authentication” and thenclick next and then next again past the Single Sign On page and the click Finish.

11. Back in the main publishing rule wizard, ensure the newly created listener is selected and then click Next. On the Authentication Delegation page click the drop down item and select “No delegation but client may authenticate directly” and then click Next, on the following User Sets page click Next and then Finish to create the publishing rule.

12. Once the rule has been created right click it and select properties and select the paths tab and remove the /OAB/* and /rpc/* entries and click OK. Following this change click Apply on the Firewall Policy page and wait for the TMG configuration store to update accordingly.

13. The Exchange Web Services rule is now created, and should look like the following as detailed below, please click to enlarge.

Web Publishing Rule Properties 1024x408 Lync 2013 EWS With Forefront TMG 2010 Issues

14. If the publishing of the rule has applied correctly, when connecting with your Lync 2013 client externally you should now longer be continually prompted for Outlook credentials and additionally under the configuration information section of the client, which can be accessed by holding down the control (Ctrl) key and then left clicking the Lync 2013 task tray icon and selecting “Configuration Information”, the EWS status should now say “EWS Status OK”.

That’s it, hopefully your EWS external access now works as intended.                             

ISA To TMG – Site To Site IPSec VPN

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.

IPSec Settings 250x300 ISA To TMG   Site To Site IPSec VPN

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.

ForeFront TMG & GFI MailEssentials – Updating Issues

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:

GFI 254x300 ForeFront TMG & GFI MailEssentials   Updating Issues

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.

ISA Server 2006 – Missing RRAS Ports

After recently rebooting a Microsoft ISA 2006 server, I found myself in the situation of being unable to establish VPN connectivity to it from a remote location. After performing several troubleshooting methods, I identified that there were no available PPTP RAS ports listed in the Routing and Remote Access (RRAS) console.

This explained why VPN connections could not be established, however I could see that a pool of ten ports had been configured but for some reason were not available. Some research on this issue led me to identify this was the result of a recent Windows Update. If you have applied KB 956570 to your ISA Server and then rebooted it, you may find yourself in the same situation. To resolve this issue, perform the following actions on the affected server:

1. Click Start and select Run

2. In the Run dialog box enter the following registry command to reset the servers reserved port threshold. Please note, enter this command without the quotation marks:

“reg add HKLM\SYSTEM\CurrentControlSet\Services\Fweng\Parameters /v ReservedPortThreshold /t REG_DWORD /d 1250 /f”

3. To uninstall the update, please run the following script which has been provided by Microsoft for this purpose. I have collated this script, which can be downloaded here for your convenience.

4. Create a new folder on the C: drive of your ISA Server named KBFix and copy the downloaded script (KB956570.vbs) to this folder location.

5. Open the command prompt and browse to the new folder you have just created. This can be achieved by typing cd c:\kbfix and then pressing return on your keyboard.

6. Once in the correct directory type cscript KB956570.vbs and then press return on your keyboard. This will now start the process of removing the update.

7. Once the removal process is complete, reboot your ISA Server and VPN connectivity will be restored.

For reference, here is the official Microsoft TechNet KB article on the problem: http://support.microsoft.com/kb/956570