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.
Monday, July 18, 2011
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:
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.
NTLM authentication
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.
- 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
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.
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
Exchange Server 2007 Service Pack 1
Exchange Server 2007 Service Pack 2
Exchange Server 2007 Service Pack 3
Exchange Server 2010
Exchange Server 2010 Service Pack 1
Exchange Server
Product name | Build number | Date |
Microsoft Exchange Server 2003 | 6.5.6944 | 6/30/2003 |
Microsoft Exchange Server 2003 SP1 | 6.5.7226 | 5/25/2004 |
Microsoft Exchange Server 2003 SP2 | 6.5.7638 | 10/19/2005 |
Microsoft Exchange Server 2007 | 8.0.685.24 | 12/9/2006 |
Microsoft Exchange Server 2007 | 8.0.685.25 | 12/9/2006 |
Microsoft Exchange Server 2007 SP1 | 8.1.240.6 | 11/29/2007 |
Microsoft Exchange Server 2007 SP2 | 8.2.176.2 | 8/24/2009 |
Microsoft Exchange Server 2007 SP3 | 8.3.083.6 | 6/20/2010 |
Microsoft Exchange Server 2010 | 14.0.639.21 | 11/9/2009 |
Microsoft Exchange Server 2010 SP1 | 14.1.218.15 | 8/24/2010 |
Exchange Server 2007 Service Pack 1
Product name | Build number | Date | KB |
Microsoft Exchange Server Exchange 2007 SP1 | 8.1.240.6 | 11/29/2007 | |
Update Rollup 1 for Exchange Server 2007 Service Pack 1 | 8.1.263.1 | 2/28/2008 | KB945684 |
Update Rollup 2 for Exchange Server 2007 Service Pack 1 | 8.1.278.2 | 5/8/2008 | KB948016 |
Update Rollup 3 for Exchange Server 2007 Service Pack 1 | 8.1.291.2 | 7/8/2008 | KB949870 |
Update Rollup 4 for Exchange Server 2007 Service Pack 1 | 8.1.311.3 | 10/7/2008 | KB952580 |
Update Rollup 5 for Exchange Server 2007 Service Pack 1 | 8.1.336.1 | 11/20/2008 | KB953467 |
Update Rollup 6 for Exchange Server 2007 Service Pack 1 | 8.1.340.1 | 2/10/2009 | KB959241 |
Update Rollup 7 for Exchange Server 2007 Service Pack 1 | 8.1.359.2 | 3/18/2009 | KB960384 |
Update Rollup 8 for Exchange Server 2007 Service Pack 1 | 8.1.375.2 | 5/19/2009 | KB968012 |
Update Rollup 9 for Exchange Server 2007 Service Pack 1 | 8.1.393.1 | 7/17/2009 | KB970162 |
Update Rollup 10 for Exchange Server 2007 Service Pack 1 | 8.1.436.0 | 4/9/2010 | KB981407 |
Exchange Server 2007 Service Pack 2
Product name | Build number | Date | KB |
Microsoft Exchange Server 2007 SP2 | 8.2.176.2 | 8/24/2009 | |
Update Rollup 1 for Exchange Server 2007 Service Pack 2 | 8.2.217.3 | 11/19/2009 | KB971534 |
Update Rollup 2 for Exchange Server 2007 Service Pack 2 | 8.2.234.1 | 1/22/2010 | KB972076 |
Update Rollup 3 for Exchange Server 2007 Service Pack 2 | 8.2.247.2 | 3/17/2010 | KB979784 |
Update Rollup 4 for Exchange Server 2007 Service Pack 2 | 8.2.254.0 | 4/9/2010 | KB981383 |
Update Rollup 5 for Exchange Server 2007 Service Pack 2 | 8.2.305.3 | 12/7/2010 | KB2407132 |
Exchange Server 2007 Service Pack 3
Product name | Build number | Date | KB |
Microsoft Exchange Server 2007 SP3 | 8.3.083.6 | 6/20/2010 | |
Update Rollup 1 for Exchange Server 2007 Service Pack 3 | 8.3.106.2 | 9/9/2010 | KB2279665 |
Update Rollup 2 for Exchange Server 2007 Service Pack 3 | 8.3.137.3 | 12/10/2010 | KB2407025 |
Update Rollup 3 for Exchange Server 2007 Service Pack 3 | 8.3.159.0 | 03/2/2011 | KB2492691 |
Update Rollup 3-v2 for Exchange Server 2007 Service Pack 3 | 8.3.159.2 | 3/30/2011 | KB2530488 |
Update Rollup 4 for Exchange Server 2007 Service Pack 3 | 8.3.192.1 | 7/7/2011 | KB2509911 |
Exchange Server 2010
Product name | Build number | Date | KB |
Microsoft Exchange Server 2010 RTM | 14.0.639.21 | 11/9/2009 | |
Update Rollup 1 for Exchange Server 2010 | 14.0.682.1 | 12/9/2009 | KB976573 |
Update Rollup 2 for Exchange Server 2010 | 14.0.689.0 | 3/4/2010 | KB979611 |
Update Rollup 3 for Exchange Server 2010 | 14.0.694.0 | 4/9/2010 | KB981401 |
Update Rollup 4 for Exchange Server 2010 | 14.0.702.1 | 6/17/2010 | KB982639 |
Update Rollup 5 for Exchange Server 2010 | 14.0.726.0 | 12/13/2010 | KB2407113 |
Exchange Server 2010 Service Pack 1
Product name | Build number | Date | KB |
Microsoft Exchange Server 2010 SP1 | 14.1.218.15 | 8/24/2010 | |
Update Rollup 1 for Exchange Server 2010 SP1 | 14.1.255.2 | 10/4/2010 | KB2407028 |
Update Rollup 2 for Exchange Server 2010 SP1 | 14.1.270.1 | 12/9/2010 | KB2425179 |
14.1.289.3 | 3/7/2011 | KB2492690 | |
Update Rollup 3-v3 for Exchange Server 2010 SP1 | 14.1.289.7 | 4/1/2011 | KB2529939 |
Update Rollup 4 for Exchange Server 2010 SP1 | 14.1.323.1 | 6/22/2011 | KB2509910 |
Update Rollup 4-v2 for Exchange Server 2010 SP1 | 14.1.323.6 | 7/27/2011 | KB2579150 |
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.
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.
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.
- 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.
Subscribe to:
Posts (Atom)