Once the cert has been installed you will need to enable the cert, you can run the following command to enable the certificate

Enable-ExchangeCertificate -Thumbprint 59 5e a4 7c f0 c0 4f 64 dc 3d 6d 29 95 f7 c4 b1 72 ca 0f 92 -Services "SMTP, IIS"

Note: The thumbprint needs to match the cert you have just installed, use either the get-certificate command or use the MMC, select the cert, click the details page and click on thumbprint or use the command specified in PART 1 to find the correct thumbprint

For each CAS server that is installed a Service Connection Point (SCP) record is created for the autodiscover service for internal clients

When i go into Outlook i get the following error:-

This is because i’m connecting to services using the NetBIOS name of mbx1 which does not match the name on the certificate. If i run Get-ClientAccessServer -Identity mbx1 | FL i’ll see that the AutoDiscoverServiceInternalUri says https://MBX1/Autodiscover/Autodiscover.xml, this does not match the certificate. I can also check the other services and see that i get the same results for OAB, EWS, Outlook Anywhere (OA) and Exchange Active Sync (EAS). So i need to update all theses internal url’s to match the name on the cert.

• Set-ClientAccessServer -Identity "mbx1" –AutodiscoverServiceInternalURI https://nlb.nwtraders.msft/autodiscover/autodiscover.xml

• Set-WebServicesVirtualDirectory -Identity "mbx1\EWS (Default Web Site)" –InternalUrl  https://nlb.nwtraders.msft/EWS/Exchange.asmx

• Set-OABVirtualDirectory -Identity “mbx1\OAB (Default Web Site)” -InternalURL https://nlb.nwtraders.msft/OAB

• Enable-OutlookAnywhere -Server mbx1 -ExternalHostname “nlb.nwtraders.msft” -ClientAuthenticationMethod “NTLM”

• Set-ActiveSyncVirtualDirectory -Identity “mbx1\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://nlb.nwtraders.msft/Microsoft-Server-Activesync

Note: If your customer does decide to enable OA externally it is important to note that the external host name value configured for Outlook Anywhere must match the Certificate Principal Name (CPN) on the certificate used by clients and must match the end point property in the client.

In order for Subject Alternate Name (SAN) certificates to be used for clients to connect to the OA service, where the CPN does not match the msstd value configured in the Outlook client profile (but the url is listed in the SAN part of the certificate), certain conditions need to be met, these are listed below:-

• Outlook 2007 or higher
• Vista SP1

Then when you open Outlook you should not longer get the cert error!

Written by Daniel Kenyon-Smith

**This blog is based on Exchange 2010 SP1 and not using the Hybrid configuration wizard e.g. SP2**

I’ve had a few customers in the last few weeks ask me how autodiscover works for Office 365 so thought i’d write a post to try and help! (please see my other post for the namespaces required, as the correct autodiscover records will need to be created in DNS for on-premise and Office 365)

As you probably already know, Exchange 2010 includes a service called the autodiscover service, this service allows an Outlook profile to be automatically configured when using Outlook 2007, 2010 or a Windows mobile 6.1 or later device. The autodiscover service uses a user’s email address and password to automatically configure a user profile. This profile can be configured whether the mailbox is located on-premise or in O365 (for more detailed information about the autodiscover service please the published white paper on TechNet).

On-Premise

For on-premise users to use the autodiscover service (where a user’s mailbox resides on-premise) there needs to be an A host record (other options are available, see the white paper ) created in external DNS that points to the externally facing IP address of the configured listener on TMG for example(for more details on publishing Exchange 2010 with UAG and TMG please see the following white paper - http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8946)

Office 365

For user’s who have a mailbox located in O365 there needs to be a CNAME record created for the service address space office365.company.com that points to autodiscover.outlook.com.

Example – autodiscover.office365.company.com --> autodiscover.outlook.com

When an on-premise mailbox is migrated to O365 their on-premise TargetAddress attribute will be updated to point to office365.company.com service namespace. Therefore when a user’s mailbox has been migrated to Office365 and Outlook attempts to autodiscover, Exchange will return the TargetAddress back to the user and Outlook will then lookup the autodiscover service at office365.company(which in turn points to O365) and will create the profile. See the diagram below for the process flow.

Note: That when a mailbox is migrated to O365 using rich coexistence there is no outlook reconfiguration or OST resync required after mailbox migration. Migrating mailboxes using rich coexistence supports full fidelity mailbox migrations.

Written by Daniel Kenyon-Smith

I’ve had the same question come up a few times recently so thought I'd blog about it as i assumed this is a FAQ.

When migrating from Exchange 2003 to 2007 will Outlook need to regenerate the .OST file?

The short answer is…no, it doesn't need to be created, the move is transparent as far as the user is concerned.

The long-ish answer is…when you use the move-mailbox command the mailbox GUID stays the same across the migration. The Outlook profile is tied to the mailbox GUID, so since the GUID moves with the migration the Outlook profile does not need to be recreated nor does the .OST associated with the profile!

Written by Daniel Kenyon-Smith

1             Here are the steps i followed for configuring ADFS for Office 365 (see my previous post for installing ADFS)

Steps	Action
Click, Start, Admin Tools, ADFS 2.0 Management
Click ‘ADFS 2.0 Federation server Configuration Wizard’
Click ‘Create a new Federation Service’ unless you want to join you server to an existing federation server farm
Select ‘Create a new Federation Farm’   Note: You create an Active Directory Federation Services (ADFS)-enabled Web server farm when you want to balance the load of incoming federated access requests that are made to one or more protected applications. The obvious benefits that can be obtained from a Web server farm are fault tolerance for the hosted applications and a possible increase in client-side browser performance. To client computers, the Web server farm performs like a single Web server servicing a highly scalable federated application. For more details see – When to Create a Web Farm
Select the SSL certificate name and Federation name specified earlier when creating the SSL certificate
Review the results and close

Written by Daniel Kenyon-Smith

Written by Daniel Kenyon-Smith