Monday, July 18, 2011

Exchange Certificate Renewal Causes Lync\Exchange IM Integration Fail

Recently ran into an issue where Lync\Exchange IM Integration stopped working after renewing the certificate on the Exchange server. This was caused by the change of the ThumbPrint of the certificate.


The ThumbPrint of the new certificate has changed and this needs to be updated by running the following Cmdlet


After updating the ThumbPrint, IM is available again in OWA.

Friday, July 15, 2011

Outlook Anywhere NTLM Authentication by TMG 2010

This MS White Paper provides a nice step-by-step instruction on how to use TMG\UAG to publish Outlook Anywhere with NTLM authentication. However there are still some "Gotchas" that are not covered in the article.

1. The TMG server must be domain-joined.

2. If your Web Listener uses FBA (in most cases it does) to publsh OWA\ActiveSync\Autodiscover\EWS\OAB, you can't use the same listener to publish Outlook Anywhere. The reason behind this is the nice "FBA Fallback to Basic" feature does not apply to NTLM. As the name implies, it only falls back to Basic, not NTLM. If you try to use the same Listener for Outlook Anywhere with NTLM, you will get promot endlessly for credentials in the Outlook client.  So if you want to keep FBA for OWA, you'll have to create a separate Listener for Outlook Anywhere that will use HTTP\Integrated authentication.


So what's the big deal? Well, a separate Listener means the following:
  • a new public URL\DNS for Outlook Anywhere
  • a new cert that has the URL\DNS as the common name
  • a new external IP address for the ULR\DNS
  • a new internal IP on the TMG server
  • firewall rules changes
So you'll end up having something like this:

IP Address
URL\DNS
Description
131.107.155.10
Owa.contoso.com
OWA\ActiveSync
131.107.155.11
Outlook.contoso.com
Outlook Anywhere\EWS\OAB
131.107.155.10 or .11
Autodiscover.contoso.com
Can be either .10 or .11

3. So you change the ExternalHostName for Outlook Anywhere to Outlook.contoso.com. And you just add outlook.contoso.com to the existing certificate instead of buying a new one since it's a SAN certificate. Let's say the common name of the SAN certificate is owa.contoso.com, you will get some error below when you run Exchange Remote Connectivity Analyzer against OutlookAnywhere

The certificate common name owa.contoso.com doesn’t validate against the mutual authentication string that was provided: msstd:outlook.contoso.com

As the errro indicates, the MSSTD name must match the common name on the certificate. Since outlook.contoso.com is not the common name on the certificate, the mutual authentication would fail. To fix it, run the following Comlet:

Set-OutlookProvider -CertPrincipalName "msstd:owa.contoso.com"

These are the things I've run into so far. You probably don't have to do it depending on different scenarios.

For those of you who want to know the difference between Basic and NTLM authentication, here are some quick notes from Microsoft.


Basic authentication
  • Basic authentication sends the user's user name and password in clear text – this doesn’t mean the connection is not secure. It’s still encrypted by the SSL layer.
  • Basic authentication also requires the user to enter their domain, user name, and password every time they connect to the Client Access server.

NTLM authentication
  • NTLM authentication is also known as Integrated Windows authentication. When NTLM authentication is used, the user's credentials aren't sent over the network. Instead, the client computer and the server exchange hashed values of the user's credentials.  
  • NTLM can also use the current Microsoft Windows operating system logon information.

Thursday, July 14, 2011

Outlook CACHE causing NDR when recreating mailbox during migration

No matter what you do, some mailboxes just fail to move during the migration. My last resort would be to blow the mailbox away on the legacy server, re-create on the new server, then import the PST back to the new mailbox. However, this would cause another headache afterward: other internal users will get NDR when sending emails to the new mailbox due to the Outlook cache. Below is a quick way to fix it without touching each Outlook client to manually delete the cached name:

1. Write down the LegacyExchangeDN value before removing the mailbox. You can do this either using ADSIEDIT.MSC or running the following Cmdlet from EMS:

Get-Mailbox AWang | fl LegacyExchangeDN

2. After you recreate the mailbox on the new server, create a new X500 address for the user and put in the LegacyExchagneDN recorded in step 1.

Wednesday, July 13, 2011

Exchange Server and Update Rollups Builds Numbers

http://technet.microsoft.com/en-us/library/hh135098.aspx

Exchange Server
Product nameBuild numberDate
Microsoft Exchange Server 20036.5.69446/30/2003
Microsoft Exchange Server 2003 SP16.5.72265/25/2004
Microsoft Exchange Server 2003 SP26.5.763810/19/2005
Microsoft Exchange Server 20078.0.685.2412/9/2006
Microsoft Exchange Server 20078.0.685.2512/9/2006
Microsoft Exchange Server 2007 SP18.1.240.611/29/2007
Microsoft Exchange Server 2007 SP28.2.176.28/24/2009
Microsoft Exchange Server 2007 SP38.3.083.66/20/2010
Microsoft Exchange Server 201014.0.639.2111/9/2009
Microsoft Exchange Server 2010 SP1 14.1.218.158/24/2010

Exchange Server 2007 Service Pack 1
Product nameBuild numberDateKB
Microsoft Exchange Server Exchange 2007 SP18.1.240.611/29/2007
Update Rollup 1 for Exchange Server 2007 Service Pack 18.1.263.12/28/2008KB945684
Update Rollup 2 for Exchange Server 2007 Service Pack 18.1.278.25/8/2008KB948016
Update Rollup 3 for Exchange Server 2007 Service Pack 18.1.291.27/8/2008KB949870
Update Rollup 4 for Exchange Server 2007 Service Pack 18.1.311.310/7/2008KB952580
Update Rollup 5 for Exchange Server 2007 Service Pack 18.1.336.111/20/2008KB953467
Update Rollup 6 for Exchange Server 2007 Service Pack 18.1.340.12/10/2009KB959241
Update Rollup 7 for Exchange Server 2007 Service Pack 18.1.359.23/18/2009KB960384
Update Rollup 8 for Exchange Server 2007 Service Pack 18.1.375.25/19/2009KB968012
Update Rollup 9 for Exchange Server 2007 Service Pack 18.1.393.17/17/2009KB970162
Update Rollup 10 for Exchange Server 2007 Service Pack 18.1.436.04/9/2010KB981407

Exchange Server 2007 Service Pack 2


Product nameBuild numberDateKB
Microsoft Exchange Server 2007 SP28.2.176.28/24/2009
Update Rollup 1 for Exchange Server 2007 Service Pack 28.2.217.311/19/2009KB971534
Update Rollup 2 for Exchange Server 2007 Service Pack 28.2.234.11/22/2010KB972076
Update Rollup 3 for Exchange Server 2007 Service Pack 28.2.247.23/17/2010KB979784
Update Rollup 4 for Exchange Server 2007 Service Pack 28.2.254.04/9/2010KB981383
Update Rollup 5 for Exchange Server 2007 Service Pack 28.2.305.312/7/2010 KB2407132


Exchange Server 2007 Service Pack 3

Product nameBuild numberDateKB
Microsoft Exchange Server 2007 SP38.3.083.66/20/2010
Update Rollup 1 for Exchange Server 2007 Service Pack 38.3.106.29/9/2010KB2279665
Update Rollup 2 for Exchange Server 2007 Service Pack 38.3.137.312/10/2010KB2407025
Update Rollup 3 for Exchange Server 2007 Service Pack 38.3.159.003/2/2011KB2492691
Update Rollup 3-v2 for Exchange Server 2007 Service Pack 38.3.159.23/30/2011KB2530488
Update Rollup 4 for Exchange Server 2007 Service Pack 38.3.192.17/7/2011KB2509911


Exchange Server 2010

Product nameBuild numberDateKB
Microsoft Exchange Server 2010 RTM14.0.639.2111/9/2009
Update Rollup 1 for Exchange Server 201014.0.682.112/9/2009KB976573
Update Rollup 2 for Exchange Server 201014.0.689.03/4/2010KB979611
Update Rollup 3 for Exchange Server 201014.0.694.04/9/2010KB981401
Update Rollup 4 for Exchange Server 201014.0.702.16/17/2010KB982639
Update Rollup 5 for Exchange Server 201014.0.726.012/13/2010KB2407113

Exchange Server 2010 Service Pack 1

Product nameBuild numberDateKB
Microsoft Exchange Server 2010 SP1 14.1.218.158/24/2010
Update Rollup 1 for Exchange Server 2010 SP114.1.255.210/4/2010KB2407028
Update Rollup 2 for Exchange Server 2010 SP114.1.270.112/9/2010KB2425179
Update Rollup 3 for Exchange Server 2010 SP1
14.1.289.33/7/2011KB2492690
Update Rollup 3-v3 for Exchange Server 2010 SP114.1.289.7 4/1/2011KB2529939
Update Rollup 4 for Exchange Server 2010 SP114.1.323.16/22/2011KB2509910
Update Rollup 4-v2 for Exchange Server 2010 SP114.1.323.67/27/2011KB2579150

Lync FE External Web Services without Reverse Proxy

Lync installation creates two web sites: Internal Web Services and External Web Services.

The internal website is pubished on ports 80/443, while the external site is pubished on 8080/4443. Microsoft recommends to use a reverse proxy server, such as TMG 2010, to publish the external website and redirect 80/443 from the web to the FE server over 8080/4443.

However, in a small Lync environment where a reverse proxy server is not available which usually sits in the DMZ, this can cause external Lync users unable to access the web services, such as Address Book, Conferencing URL, etc. Here is what we can do to provide external web services to external Lync users without reverse proxy.

  1. Assign an additional IP address to the FE server

     2. Change the external website to use the additonal IP address on port 80/443 from IIS Mananger


     3. Assign a 3rd-party certificate to the external website using Lync Server Deployment Wizard.

     4. Change the firewall to NAT to the additonal IP on the FE server and allow inbound 80/443

You will not be able change port settings for the external web services from the Topology Builder. So just leave it as the way it is.


External Lync users now should be able to access all external web services.

Notes: This can be used as a workaround to bypass reverse proxy for either a small environment where security is not a big convern or in a test\lab enviroment. You should always consider deploying reverse proxy to publish FE servers whenever possible.