In a blog post by Christopher Wells, alias vSamurai, the author positions VMware Zimbra Collaboration Server (ZCS 7.x) as an enterprise-ready drop-in replacement for Microsoft Exchange Server 2010 environments of all sizes. You can find the article on Dave’s blog here, including a personal note by Dave. Note: This blog was written together with Dave Stork after reading a Zimbra and Exchange product comparison. /Autodiscover/Autodiscover.svc/wssecurityĪfter configuring the rule, you need to put it above all the other Exchange rules, making it the first matching rule when federation traffic hits ISA/TMG.Īfter applying the rule changes, Get-FederationInfo should work and you can continue with the Hybrid Configuration.įor more information on setting up co-existence, consult the steps provided by the Exchange Deployment Assistent.You need to allow All Users (as opposed to Authenticated Users), set authentication to “No Authentication, but users can authenticate directly” and configure the following paths: To solve this issue, and to get federation working, you need to set up an additional ISA/TMG rule pointing to the hybrid server, using the proper public names (don’t forget autodiscover), bound to the OWA listener. When you turn on logging in TMG, you’ll notice the requests for /autodiscover/autodiscover.svc will be denied. Issue is, these service requests require unauthenticated traffic. These requests are normally caught by the autodiscover rule (path /autodiscover/*) in ISA or TMG. In the error message you’ll notice a autodiscover-related request going to /autodiscover/autodiscover.svc. Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication $true However, federation will use DNS records so you need allow it or set it up in DNS a CNAME for as well as pointing to your hybrid server will suffice.Īlso make sure you enable WSSecurity authentication for autodiscover on your hybrid server using: Normally, when using regular clients like Outlook, this isn’t an issue because domain joined clients will be using SCP records from AD. Some customers don’t configure internal DNS autodiscover records or don’t allow (internal) autodiscover to go through the proxy from inside. The first issue often overlooked is internal autodiscover not working via DNS or not being set up properly, i.e. Type=Failure Url= Exception=Discovery for domain failed. Get-FederationInformation : The discovery process returned the following results: When analyzing this output, you’ll see it contains two hints on the potential issues: You’ll probably see the cmdlet going trough the discovery motions using autodiscover, ending up in the same “Federation information could not be received from the external organization” message. Most of the time this problem comes down to one of the following issues, which can be verified by running the following cmdlet, where is to be replaced by the federated domain: To see where it goes wrong, you could run Set-HybridConfiguration and Update-HybridConfiguration manually, using additional parameters as shown in the result screen, providing proper credentials and additionally addint the Verbose parameter to increase output logged. The problem lies in the sentence “Federation Information could not be received from external organization”. This may indicate invalid parameters in your Hybrid Configuration settings.įederation information could not be received from the external organization. Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships.Įxecution of the Get-FederationInformation cmdlet had thrown an exception. When inspecting the Update-HybridConfiguration results, it reads: When setting up federation between Exchange organization using the Hybrid Configuration Wizard, to connect your on-premise Exchange environment with Office 365, you may encounter an error message in the 2nd step of the Hybrid Configuration Wizard, Update-HybridConfiguration: