Tag Archives: Exchange Hybrid

HCW fails on intra-organization configuration

Posted on by
10

o365logoFor my lab, I often have to recreate the Exchange Hybrid configuration for a fresh setup of Exchange On-Premises using formerly used namespaces. Normally you would just run the Exchange Hybrid Configuration Wizard (HCW) after configuring certificates and endpoint URLs. If you don’t clean up the previous configuration information from your tenant upfront, you may then run in the following error message when running the HCW:

Updating hybrid configuration failed with error ‎’Subtask Configure execution failed: Configure IntraOrganization Connector Execution of the Get-IntraOrganizationConfiguration cmdlet has thrown an exception. This may indicate invalid parameters in your hybrid configuration settings. Multiple OnPremises configuration objects were found. Please use the OrganizationGuid parameter to select a specific OnPremises configuration object.

Multiple OnPremises configuration objects indicates there are multiple intra-organization objects defined in your tenant. You can clean up previous intra-organization configuration objects from your tenant as follows:

  1. First, in your Exchange On-Premises environment, run the Get-OrganizationConfig cmdlet from the Exchange Management Shell:
    image
  2. Copy the Guid value, in the example 1a95d446-ff56-4399-a95e-8ab46c30912b.
  3. Connect to Exchange Online (instruction here).
  4. Check the existing On-Premises definitions in your tenant by running Get-OnPremisesOrganization. There should be more than 1 entry.
  5. To remove the orphaned objects, remove all the objects that don’t match the Organization Guid you retrieved from your On-Premises environment earlier, e.g.:Get-OnPremisesOrganization | Where { $_.OrganizationGuid –ne ‘1a95d446-ff56-4399-a95e-8ab46c30912b’ } | Remove-OnPremisesOrganization
    image
  6. Now you could try re-running the HCW immediately, but chances are you will run in another error caused by orphaned intra-organization connectors (IOC). In those cases, when the HCW tries to run New-IntraOrganizationConnector, it will fail as the namespace defined by TargetAddressDomains is already in use by an existing connector, and ‘The domain <domain> already exists in another intra-organization connector’ is reported. Those connectors, named ‘HybridIOC – ’, where GUID is the Guid of previously used organizations, exist in your tenant. In your Exchange Online session, run the following cmdlet to remove orphaned connector definitions:Get-IntraOrganizationConnector | Where { $_.Identity –ne ‘HybridIOC – 1a95d446-ff56-4399-a95e-8ab46c30912b’ } | Remove-IntraOrganizationConnector
    image
  7. While you’re at it, you also might want to remove previously created connectors. Again, in your Exchange Online session, run the following cmdlets to remove orphaned inbound and outbound connectors (again, using the previously noted Organization GUID):
    Get-OutboundConnector | Where { $_.Identity –ne ‘Outbound to 1a95d446-ff56-4399-a95e-8ab46c30912b’ } | Remove-OutboundConnector
    Get-InboundConnector | Where { $_.Identity –ne ‘Inbound from 1a95d446-ff56-4399-a95e-8ab46c30912b’ } | Remove-InboundConnector

After removing these orphaned objects, you should be able to run the HCW succesfully.

HCW 2013 Subtask CheckPrereqs execution failed

Posted on by
2

Ex2013 LogoA quick heads-up on the Hybrid Configuration Wizard (HCW) in Exchange 2013, which is broken. The HCW in Exchange 2010 does not have this issue.

The HCW is needed when you want to configure or maintain your Exchange 2013 Hybrid configuration. When checking the prerequisites, the Exchange 2013 HCW may throw the following error message:

Subtask CheckPrereqs execution failed: Check Tenant Prerequisites
Deserialization fails due to one SerializationException: 
Microsoft.Exchange.Compliance.Serialization.Formatters.BlockedTypeException: 
The type to be (de)serialized is not allowed: 
Microsoft.Exchange.Data.Directory.DirectoryBackendType

The issue has been documented in KB2988229. An Interim Update is available, as reported here. The IU is available for Exhange 2013 Service Pack 1 (CU4) and Cumulative Update 5. Unfortunately, the IU is not available publicly, but must be requested through support.

The fix will be incorporated in Exchange 2013 Cumulative Update 6.

If you must, you can use Exchange fellow Steve Goodman’s instructions documented here, which describes the process to manually configure Exchange 2013 Hybrid deployments. Be advised that, as Steve also points out, the Exchange Hybrid deployment support status depends on the ability to run HCW successfully.

TechEd North America 2012 sessions

Posted on by
1

With the TechEd North America 2012 event still running, recordings and slide decks of finished sessions are becoming available online. Here’s an overview of the Exchange-related sessions:


TargetAddress, ExternalEmailAddress and Set As External

Posted on by
7

In co-existence scenarios, the targetAddress attribute is leveraged to accomplish routing to different Exchange organizations by specifying the “final destination” e-mail address. The e-mail domain part of this address can be a non-accepted domain (i.e. other organization). This will enable organizations, when used in conjunction with mail-enabled users or contacts, to provision the (global) address list of their Exchange organization with mail-enabled objects of other organizations, also in a migration co-existence phase. Simply said:

  1. It can allow users in the local organization to select the object from the (global) address list and that object exists in other organizations;
  2. Exchange can route the message to its final destination using the specified targetAddress.

Reason for this blog is that I still see people putting e-mail address in the targetAddress property or the object by scripting against Active Directory (e.g. ADSI), even while they’re scripting using the Exchange Management Shell.

In the Exchange Management Shell, you can set the targetAddress by using the Set-MailContact or Set-MailUser in conjunction with the ExternalEmailAddress parameter, e.g.:

Set-MailContact  michel -ExternalEmailAddress michel@contoso.com

Setting this address is also possible using the Exchange Management Console, which may be more appropriate for testing purposes or a small number of changes (though I’d prefer the less-prone-to-error script any day):

image

When utilized in scripts, you can use PowerShell Piping Power (is that abbreviation already taken?) to process (CSV) files or use filtering to select the objects of which you want to configure the targetAddress, e.g.:

Get-MailContact -OrganizationalUnit “contoso.local/Division” -Filter {EmailAddresses -like *@contoso.local} -ResultSize unlimited | ForEach { Set-MailContact –ExternalEmailAddress “$($_.Alias)@newcompany.local” }

Get-Content “users.txt” | Get-MailContact | ForEach{ Set-MailContact $_.Identity -ExternalEmailAddress “$($_.Alias)@newcompany.local”  }

This will configure all mail-enabled contacts in the Division OU with an @contoso.local e-mail address with a target address which consists of the current alias followed by @newcompany.local. The other example uses a text file with names to process contacts and set the targetAddress to the current value of “alias” followed by the external e-mail domain.

Needless to say, the connectors between contoso and newcompany  as well as the accepted domains should be properly configured to route those contoso.local and newcompany.local domains between those organizations. Of course, this also depends on whether you’re using internal or external domain names and if you want those messages to go through the public network or not.

Note that this is also how you can set configure the targetAddress of a local (DirSync’ed) mail-enabled contact with an Office 365 mailbox in a Hybrid setup, for example after moving the mailbox to Office 365. In such case you set the targetAddress to the service domain in a Hybrid Office 365 setup, e.g. mydomain.mail.onmicrosoft.com.

Federation Information could not be received ..

Posted on by
13

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:

image

When inspecting the Update-HybridConfiguration results, it reads:

Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships.
Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.
Federation information could not be received from the external organization.
..

The problem lies in the sentence “Federation Information could not be received from external organization”. 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.

Most of the time this problem comes down to one of the following issues, which can be verified by running the following cmdlet, where example.com is to be replaced by the federated domain:

Get-FederationInformation example.com –Verbose

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. When analyzing this output, you’ll see it contains two hints on the potential issues:

Get-FederationInformation : The discovery process returned the following results:
Type=Failure;Url=https://autodiscover.example.com/autodiscover/autodiscover.svc;Exception=Discovery for domain example.com failed.; …

1. Autodiscover
The first issue often overlooked is internal autodiscover not working via DNS or not being set up properly, i.e. split DNS configurations. Some customers don’t configure internal DNS autodiscover records or don’t allow (internal) autodiscover to go through the proxy from inside.

Normally, when using regular clients like Outlook, this isn’t an issue because domain joined clients will be using SCP records from AD. However, federation will use DNS records so you need allow it or set it up in DNS; a CNAME for autodiscover.example.com as well as autodiscover.service.example.com pointing to your hybrid server will suffice.

Also make sure you enable WSSecurity authentication for autodiscover on your hybrid server using:

Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication $true

2. Proxy rules
In the error message you’ll notice a autodiscover-related request going to /autodiscover/autodiscover.svc. These requests are normally caught by the autodiscover rule (path /autodiscover/*) in ISA or TMG. Issue is, these service requests require unauthenticated traffic. When you turn on logging in TMG, you’ll notice the requests for /autodiscover/autodiscover.svc will be denied.

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. 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:

  • /EWS/Exchange.asmx/wssecurity
  • /Autodiscover/Autodiscover.svc
  • /Autodiscover/Autodiscover.svc/wssecurity

After 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.

After applying the rule changes, Get-FederationInfo example.com should work and you can continue with the Hybrid Configuration.

For more information on setting up co-existence, consult the steps provided by the Exchange Deployment Assistent.