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.                             

Microsoft Exchange 2010 – Cannot Send E-Mail To A Mail Enabled Public Folder

I was recently assisting a colleague with an issue he had experienced with a Microsoft Exchange 2003 to Microsoft Exchange 2010 migration. The migration had completed correctly, however for an unknown reason you could not send e-mail to any mail-enabled public folders, despite whether these were created newley from within the Exchange Management Console or were replicated as a part of the migration. All of the mail-enabled public folder properties were correct, including permissions, and Exchange 2010 Service Pack 1 had also been applied. When e-mailing a mail-enabled public folder from an external network no NDR was produced, however when e-mailing from the internal network the following NDR was returned:

#554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn’t found. ObjectNotFoundException: The Active Directory user wasn’t found. ##

After performing some research it turned out this is a known problem with Exchange 2010 migrations as detailed here. The issue occurs due to the legacy administrative group (First Administrative Group) being empty following the migration. To resolve this issue perform the following actions:

1. Open ADSI Edit on either a domain controller or your Microsoft Exchange 2010 server.

2. Navigate to the “CN=Servers” ADSI attribute by locating the below path, I have also included a screenshot of the location to help identify the attribute:

CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,
DC=domain,DC=local

ADSI Exchange Severs 300x279 Microsoft Exchange 2010   Cannot Send E Mail To A Mail Enabled Public Folder

3. Right click the “CN=Servers” container and select delete. Click OK when prompted in order to confirm the action. Note: Do not delete the top level container “First Administrative Group”, this is against Microsoft best practices and may have a negative affect on your Exchange organisation.

4. Ensure replication of your Active Directory database has occurred to all domain controllers and then attempt sending an e-mail to one of your mail-enabled public folders. You should now find e-mail makes it way to these folders as expected.

For more information on this issue, please see the following URL: http://msexchangeteam.com/archive/2010/05/05/454821.aspx

Microsoft Exchange 2010 – SSL Certificates

I recently installed my first third party certificate into an Microsoft Exchange 2010 environment. This process is almost identical to how it is performed in Exchange 2007, however the PowerShell commands differ very slightly. Microsoft Exchange 2010 does actually support certificate requests and installations directly through the Exchange Management Console, however I’m not much of a fan of this, it has a slightly clunky feeling to it much like the Small Business Server 2008 implementation of wizard driven certifcate requests and installations.

For this certificate installation I was using a Go Daddy UCC 5 Domain certificate, which is more than adequate for Exchange 2010. You may see Exchange certificates branded as UCC (Unified Communications) or SAN (Subject Alternative Name), these are essentially the same, just different vendors choose to brand them differently. As a rule of thumb, always go for at least a five domain Unified Communications certificate otherwise you will find yourself in a pickle when it comes to adding subject alternative names. The following section of this post details the steps required to generate your CSR and install your certificate into your Exchange 2010 environment.

1. The first step of this process is to generate the CSR that will be used to tell your SSL vendor all about your environment. To make life a little easier, DigiCert have created a web based tool that will compile the required CSR PowerShell command for you, which you can find here

Hopefully once you have filled out the required fields in the DigiCert tool, you should have something very similar to the below screenshot. Please pay attention to the Subject Alternative Names used and the order that they have been entered in.

DigiCert CSR 300x159 Microsoft Exchange 2010   SSL Certificates

Please note that where contoso.com is your public domain name, and where contoso.local is your local domain name. Mail.contoso.com would the public DNS A record that is pointed to your internet endpoint, for example the global IP address of your router or firewall.

2. Once you have filled out of the required fields, click the generate button and then copy the generated PowerShell command to your clipboard. Open the Exchange Management Shell (EMS) on your Exchange 2010 server and paste the copied PowerShell command into the EMS and press return. Once this has completed, navigate to the C:\ drive on your server and open the generated .csr file in notepad. The content of this notepad file is the information you need to submit to your SSL vendor when they request CSR information.

3. When your certificate has been generated, download it from your SSL vendors website onto the root of the Exchange 2010 servers C:\drive. Once this has been performed, we need to action a PowerShell command to both import the new certificate and append this certificate to all Exchange 2010 services.  The PowerShell command you need to run is the following:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\your_certificate.cer -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate -Services IIS,POP,IMAP,SMTP

In the above command, please edit the -Path attribute to read the file location of where you have stored your downloaded certificate.

4. To verify the certificate installation, browse to Outlook Web Access from an external source, so for example to https://mail.mydomain.com/owa and ensure that the correct certificate is being utilised by clicking the padlock icon in Internet Explorer or your preferred browser.