This page is the third and final step in the 3 stage Exchange upgrade series of articles. It deals with setting up (or updating) autodiscover, creating certificates and finally creating a Microsoft Federated Gateway. It assumes you have completed Step 1 and Step 2 and run ISA 2007 Servers as your firewall.
Steps 37 onwards assume that the external organisation has completed the same steps from their end (they would also need to complete all steps here).
The steps are:
1. Contact your ISP to add external DNS entry for autodiscover.yourdomain.com to point to the external IP for your ISA Server.
Once this has been completed and has replicated you can proceed to step 2.
2. Update static Autodiscover internal DNS entry to Exchange 2010 CAS created in Step 2. Test Outlook autodiscover on a workstation that has had DNS updated (ipconfig /flushdns).
3. If you do not have a Subject Alternative Name (SAN) field in the e-mail certificate from your certificate provider then you will need to obtain new one, specifying audtodiscover. yourdomain.com as Subject Alternative Name (SAN).
4. Install Cert on ISA Servers.
5. Log on to ISA Server.
6. Open ISA Server management.
7. Right-click the current rules you use for OWA and select Copy.
8. Right-click the same rule and select Paste.
9. Look at Properties of new rule.
10. Under General tab rename to Outlook Autodiscover (or something that is relevant to yoru current naming system). Update Description.
11. Under Paths tab remove all and add /autodiscover/*
12. Under Public Name tab ensure only autodiscover.yourdomain.com is listed.
13. Go to Actions > New > Exchange Web Client Access Publishing Rule
14. Name the rule Federation Autodiscover. Hit Next.
15. Select Exchange Server 2007 with Outlook Anywhere ticked. Hit Next.
16. Publish a single Web site. Hit Next.
17. Under Paths tab remove all /autodiscover/* and add /ews/mrsproxy.svc, /ews/exchange.asmx/wssecurity, /autodiscover/autodiscover.svc/wssecurity and /autodiscover/autodiscover.svc.
18. Under Public Name tab ensure only autodiscover.yourdomain.com is listed.
19. Create test exchange mail account of [email protected]
20. Test autodiscover from https://www.testexchangeconnectivity.com/ . Choose Outlook Autodiscover and use account created in Step 19.
21. Log on to EXCHANGE2010CAS.
22.Open the Exchange Management Console (EMC) and select the Organization Configuration node.
23. In the Actions pane, select New Federation Trust. The New Federation Trust wizard will run.
24. Click New to form the new trust with the Microsoft Federation Gateway. The wizard will create a new self-signed certificate called Exchange Delegation Federation with the subject name of Federation. The Federation and SMTP services will be assigned to this certificate, but it will not change the default SMTP certificate. The Microsoft File Distribution service will automatically copy and install this self-signed certificate to all of your Exchange 2010 client access servers.
25. Click Finish to close the wizard.
26. Open Exchange Management Shell (EMS).
27. Type Get-FederatedDomainProof -DomainName yourdomain.com (this will return a long “proof” which looks something like: whTGGuUq0D3000000OCp+yuXumHYBR5NooooooWB7sZZo0NSmHwo2DR0ooooookyCjHtSU26Vy7rkK000000Fw==)
28. Type Get-FederatedDomainProof -DomainName exchangedelegation.yourdomain.com (again this will return a long proof similar to the one above)
29. Request your ISP create 2 DNS TXT entries. They are yourdomain.com with the Data field being the proof retrieved in Step 27, and exchangedelegation.yourdomain.com with the Data field being the proof retrieved in Step 28.
Once this has been completed and has replicated you can proceed to step 30.
30. In the EMC on EXCHANGE2010CAS navigate to Hub Transport in the Organization Configuration node.
31. Click the Accepted Domains tab and click New Accepted Domain in the Actions pane.
32. Enter Exchange Federated Delegation for the Name and enter exchangedelegation.yorudomain.com for the Accepted Domain, then click New. (This new authoritative accepted domain will never be used by users – it is only used by the federated trust.). Click Finish.
33. Click the Organization Configuration node and select the Microsoft Federation Gateway trust under the Federation Trust tab. Click Manage Federation in the Actions pane. You will see the current federation certificate status. You can click Show distribution state to check that the federation certificate is installed on all Exchange 2010 client access servers.
34. Click Next to bring up the Manage Federated Domains window.
35. Click Add and select the Microsoft Federated Trust accepted domain you created in Step 19.
36. Click Next and Manage to configure Microsoft Federated Trust. When the configuration is successful you will see the federation trust has an Application Identifier and Application URI.
(If the TXT records you created in Steps 27 & 28 are incorrect or have not propagated yet to the Microsoft Federated Gateway server, you will get the following error: Proof of domain ownership has failed. Make sure that the TXT record for the specified domain is available in DNS. The format of the TXT record should be “example.com IN TXT hash-value” where “example.com” is the domain you want to configure for Federation and “hash-value” is the proof value generated with “Get-FederatedDomainProof -DomainName example.com”.
The proof of domain ownership is not valid or is missing.)
Now that the federated trust has been created and then validated by the MFG, you can create organization relationships. These are the federation sharing policies that determine what is shared with whom.
37. Click the Organization Relationships tab on the Organization Configuration node in the EMC.
38. Click New Organization Relationship in the Actions pane. The New Organization Relationship wizard will start.
39. Enter External Company Organization Relationship (or whatever unique name you choose, this is not externally relevant).
40. Select the Enable free/busy information access checkbox and specify Free/busy access with time, plus subject and location.
41. Add domains ext1.domain.com and exchangedelegation.ext1.domain.com to federate with, then click Next and include ALL domains at the external company that you wish to see Free/Busy information for.
42. Click New. The organization relationship has been successfully configured should be listed under the Organization Relationships tab. Sharing Enabled and Calendar Enabled will show as True.
43. Complete Steps 38-42 for any other organisations you need to federate with.
44. Ensure other agencies have created the Organization Relationship at their end, test viewing free / busy info.
(As a side note, after creating the Mail Federation Gateway I found that the Exchange 2010 CAS box showed Application Log error:
4002 Error “MSExchange Availability”
“Process 4780: ProxyWebRequest IntraSite from [email protected] to https://mail.yourdomain.com/ews/exchange.asmx failed. Caller SIDs: NetworkCredentials. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The request failed with HTTP status 401: Unauthorized.”
I thought that EWS was a strange request for the Mail Cluster so ran
To see if the MAIL cluster had been accidentally configured as a CAS.
I got a response and could see that although MAIL wasn’t set up as a CAS, one of the Exchange 2007 boxes (EXCHANGE2007-02) had mailcluster.yourdomain.com as its internal EWS URL (the MAIL cluster had no CAS roles installed). I then ran
get-webservicesvirtualdirectory -server EXCHANGE2007-02 | fl
to discover that the full path was https://mailcluster.yourdomain.com/ews/exchange.asmx
Finally I ran
set-webservicesvirtualdirectory -id “ EXCHANGE2007-02\EWS (Default Web Site)” -InternalUrl https://EXCHANGE2007-yourdomain.com/ews/exchange.asmx
to update the “InternalURL” field. This resolved the issue.)