By using federated sharing it is possible to exchange free/busy informative between different Exchange organizations. This can be done by using the Microsoft Federation Gateway (MSFG) when no direct trust exists between the Active Directories. The MSFG is in this case responsible for providing a ticket which is used for authentication. By using a ticket a CAS can contact the CAS from the other organization to retrieve the free/busy information.
To use this feature several things will need to be configured:
- trust with the Microsoft Federation Gateway
- organizational relationship must be configured
- autodiscover and EWS must allow WS Security authentication
- the reverse proxy needs to allow unauthenticated traffic to the following url’s:
-
- /EWS/exchange.asmx/WSSecurity
- /autodiscover/autodiscover.svc/WSSecurity
- /autodiscover/autodiscover.svc
Several sites contain a step-by-step plan on how to configured this. An overview of those sites can be found on the end of this article.
When you setup these things everything should work, indeed should. In most cases it will work but in some cases you will need to perform some troubleshooting. In this serie of blogs we will have a look how you can validate that it works and perform some troubleshooting in case something doesn’t work.
But how can you troubleshoot these issues? First of all it is very useful if you have a contact person who has access to the other Exchange organization. In most cases this isn’t a big issue but when using Office 365 or another form of hosting this can be very hard sometimes.
To start the troubleshooting process you mostly would like to verify your own Exchange organization first. Things that could be checked are:
- verify if autodiscover allows WS Security for authentication
- verify the external EWS url
- verify if Exchange Web Services will allow WS Security for authentication
If your Exchange organization contains multiple CAS then Powershell is your friend and you can use several cmdlets to verify the steps above:
| _Get-AutodiscoverVirtualDirectory | select server, WSSecurityAuthentication_ |
You will get an output like above. Verify if the value of the column WSSecurityAuthentication _is set to _true
If WSSecurity is not true then use the following cmdlet to enable it:
| _Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication:$true_ |
Using this cmdlet the authentication method will be configured but to offer this authentication type you will need to perform an IISReset. Additional you can verify if the svc-integrated handler is attached to the autodiscover virtual directory:
Next step is to verify the Exchange Web Services, this can be done by using the Get-WebServicesVirtualDirectory cmdlet_:_
| _Get-WebServicesVirtualDirectory | select server, ExternalUrl, WSSecurityAuthentication_cmdle |
Again the same rule apples WSSecurityAuthentication _needs to be set to _true. Besides this the ExternalUrl needs to contains a valid value. This url needs to accessible from the internet. If this is not the case it simply won’t work.
In case that WSSecurity is not true enabled it by using the following cmdlet:
| _Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WSSecurityAuthentication:$true_ |
The same applies for EWS as it did for autodiscover perform an IISReset to activate the authentication method. Besides this verify if the ws-security handler is attached to the EWS virtual directory.
If no external url is configured you will need to configure one. Before you do this make sure the certificate contains all the correct names. If you will configure a value but it is not part of your certificate you will get errors.
To verify if the certificate contains the correct names we will use Powershell again:
| _Get-ExchangeCertificate | ? {$_.Services -like “*IIS*”} | select Subject, CertificateDomains | FL_ |
Verify if the CertificateDomains contain the FQDN you are planning to use for EWS, for example mail.domain.com of ews.domain.com. If this name is not on the certificate you will need to renew your certificate.
If the certificate contains the name for the external URL then you can continue configuring it:
| _Get-WebServicerVirtualDirectory | Set-WebServicesVirtualDirectory -Externalurl “https://ews.domain.com/EWS/exchange.asmx”_ |
Using the cmdlet above the external URL on all Client Access Servers will be configured the same. REMARK: in some scenarios this is not what you want. Please verify if this is the case in your scenario before configuring the external url.
When this has been configured and validated it is time to verify the Federation Trust and the Organization Relationship.
This can be done by starting with Test-FederationTrustCertificate which will verify if the certificate used for the trust is correct and is installed on all CAS. During the creation of the trust the self-signed certificate will normally be distributed to all CAS in your environment. But in some cases this may not happen. If this is the case the CAS will be unable to authenticate against the Federation Gateway of Microsoft which will eventually result the autodiscover process to fail.
Test-FederationTrustCertificate
Verify that the State column for all CAS contain the value installed.
Additionally you can run the Test-FederationTrust cmdlet to verify if the Federation Trust really works. By default this cmdlet will use the extest account:
Test-FederationTrust
If you don’t have an extest account or you would like to use another user add the UserIdentity parameter:
Test-FederationTrust -UserIdentity user@domain.com
This cmdlet will perform several tests and will output the results on the screen, verify if no errors did occur.
As final step of the process you can verify the Organization Relationship. This is only applicable if the other organization has issues when looking up the free/busy information for your mailboxes. By using an organization relationship you will give the other organization permission to retrieve free/busy information of your organization. If not all domains are listed here it can cause strange issues such as it works for domain A but not for domain B while they are located in the same Exchange environment.
To troubleshoot these kind of issues you can use two cmdlets:
- Get-OrganizationRelationShip, retrieves the current configuration
- GetFederationInformation, will send an autodiscover request to the other organization to retrieve the configuration
The following parameters are important in this case:
- DomainNames
- TargetApplicationUri
- TargetAutoDiscoverEpr
One remark must be made about the DomainNames parameter. In some cases this parameter doesn’t have to be the same for both cmdlets. Some organizations only want to share free/busy information with a specific domain and not all domains hosted by the other Exchange organization.
In this part of the series we did have a look which configuration items you will need to verify in your Exchange organization. Besides this we did had a look on how to fix them if they are configured incorrectly.
In the second part we will have a closer look at the reverse proxy and client part of troubleshooting.
Below are some pages which contain use full information about federated sharing:
Office 365 Community: How to configure TMG for Office 365: open
TechNet: How does Federated Calendar sharing work in Exchange 2010?: open
TechNet: Exchange 2013: Sharing: open
Comments
