Friday, August 5, 2011

Move mailbox from Exchange 2010 On Premise to Office 365

Screenshots below outlines the process of moving a mailbox from on-premise Exchange 2010 enviroment to Office 365.

Assumptions:
  • Primary SMTP Domain: CONTOSO.COM
  • Federated Service Domain: SERVICE.CONTOSO.COM
  • External URL for Co-exist Exchange 2010 server: OWA.CONTOSO.COM
Prerequisites:
Steps:

1. From EMC On-Premise, go to Recipient Configuration -> Mailbox, highlight the mailbox you are going to move, click New Remote Move Request from the Action pane

2. Choose Office 365 as the target forest; specify external URL of your co-exist Exchange 2010 server with an account that has adequate permission to the on-premise Exchange environment

3. Enter the federated service domain as the Target Delivery Domain

4. After the remote move request has been generated successfully, go to EMC Cloud -> Recipient Configuration- > Move Request to verify the status of the move request. You can also run Get-MoveRequest | Get-MoveRequestStatistics from a remote powershell session that connects to Office 365 to verify the status.

5. The move request has completed successfully.

6.  As a result, user4 now is showing as the Contact in on-premise Exchange

    And a mailbox in Office 365.

Thursday, August 4, 2011

Exchange 2010 Federated Delegation with TMG

During a recent rich co-exist deploymnet between on-premise Exchange 2010 and Office 365,  I noticed therer is a problem establishing organizational relationship from Office 365 to on-premise Exchange coexist server when on-premise Autodiscover is published by a TMG server. Exchange 2010 federation uses SAML tokens—not user accounts—to authenticate against IIS for EWS calls. TMG doesn’t know how to validate SAML tokens, so the incoming requests can’t be authenticated and passed on to the Exchange Server 2010 coexist server. Every time a cloud user tries to view free/busy information of an on-premise user, there is a log in the TMG server indicating "Access Denied"


The end result is that we couldn’t get a proper sharing relationship setup and you can’t federate calendar data.

When we knew what the problem was, fixing it involved modifying the OWA and ECP virtual directories on all of our Exchange Server 2010 CAS servers to perform FBA, then modifying the Web listener on our TMG Server to disable pre-authentication. Finally, we needed to modify the authentication settings for each of the TMG publishing rules for ActiveSync, Outlook Anywhere, and OWA to set them to No Delegation, But Client May Authenticate Directly, and to revise the Users settings from All Authenticated Users to All Users. Revising the Users settings is important; without this, ISA won’t pass any connections on to the CA servers. You may also need to verify that the authentication settings of your other Exchange virtual directories are valid; many organizations will allow basic authentication between TMG and their CAS servers, but require NTLM or Windows Integrated from external clients to TMG.

If you’re using multiple Web listeners to publish Exchange 2010, then your step may be different. The federated delegation feature requires direct access to the EWS vdir on your CAS servers, and EWS is typically published on TMG as part of the Outlook Anywhere rules. If you publish those using a separate Web listener—which will require a separate IP address, FQDN, and SSL certificate—you can simply disable pre-authentication for that Web listener, but still allow it on your OWA, ECP, and EAS directories.

Calendar sharing and TMG FBA pre-authentication are both wonderful features, but at this point they are not compatible.

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.