Tag Archives: Hybrid

MS Teams & pre-Exchange 2016CU3

Posted on by
4

Updated May 9th: Added Share to Teams. to table

With the emergency to facilitate working from home due to the Corona pandemic, many organizations were faced with a dilemma. When running Exchange 2013 or some even Exchange 2010 on-premises, and a desire to start using Microsoft Teams, organizations were confronted with the following requirements for integrating Microsoft Teams with Exchange on-premises (source):

  • Users with mailboxes hosted on-premises must be synchronized to Azure Active Directory.
  • Running Exchange 2016 Cumulative Update 3 or later on-premises.
  • OAuth needs to be configured (via Hybrid Configuration Wizard, or manual as MVP fellow Jaap blogged about here).
  • Recently, an additional requirement was added to explain that for delegates to schedule calendar meetings on behalf of another person, some additional steps are required (steps 2-3 mentioned here).

Now as you might know, Exchange 2010 does not support OAuth authentication. But, by putting Exchange 2016 in front of Exchange 2010, Exchange 2016 can be used for dealing with OAuth authentication, as well as dealing with client traffic as it can down-level proxy to Exchange 2010 for mailboxes hosted on those servers. Looking at these requirements, organizations might conclude that putting Exchange 2016 CU3 in front of their Exchange environment, and configuring OAuth would suffice the requirement to integrate Teams with their Exchange on-premises environment.

image

Alas, the additional requirement for full Teams integration is that the mailbox server hosting the mailbox should support REST API. Teams leverages Graph REST API calls to interact with mailboxes. In an Hybrid Exchange setup, on-premises mailboxes are identified, and related REST API calls will be directed at the on-premises REST endpoint, landing on your Exchange environment. The requirement for REST API support is something which is not explicitly stated in the Teams integration article, despite my earlier pull request.

It is however stated implicitly in an article on REST support in Hybrid Exchange or the original publication on REST API support in Exchange 2016 CU3 by the Exchange PG, two articles which you might easily have missed or forgotten about. Either way, it states that “All on-premises mailboxes that will use the REST APIs must be located on databases located on Exchange 2016 CU3 servers”.

Thus, with REST API support only being available per Exchange 2016 CU3, Teams will not fully integrate with mailboxes hosted on earlier versions of Exchange. Exchange 2016 can be used to offload OAuth when your mailbox is still on Exchange 2010 (which works fine for Exchange Web Services for Free/Busy, for example), but Exchange 2010 does not support REST API, and thus will never understand those ‘weird’ (proxied) requests landing on /api virtual directory, typical of REST API calls. Consequently, you will see AutodiscoverV2 and REST API calls greeted with a 404:

2020-04-29 20:22:52 fd86:b628:2775:1:9502:cdcc:d4b1:5950 GET /autodiscover/autodiscover.json Email=chefke%40contoso.com&Protocol=REST&RedirectCount=1 443 CONTOSO\EX2$ fd86:b628:2775:1:9f8:2d9:c8a1:3c4a SkypeSpaces/1.0a$*+ 404 0 2 31

Typically, first thing users usually will notice missing is the Calendar integration:

image

Knowing this, the assumption could be that this combination doesn’t work at all, but as often the truth lies somewhere in the middle. You can use Teams when mailboxes are still hosted on pre-Exchange 2016 CU3, if you can live with the limitations. Below I have included a short overview of these, or other noteworthy items. The information is complementary to the How Exchange and Teams interact article. I hope it may help in discussions on what works and what doesn’t.

Disclaimer: Validated with mailbox hosted on Exchange 2010 with Exchange 2016 in front, OAuth and SkypeOnline AppId configured, and using Outlook 2016 C2R. Information may be subject to change. The list may not be conclusive; if you have any additional observations, please leave them in the comments.

ActionsWorksComment
Create & View Meetings in TeamsNoNo Calendar integration as this requires Outlook Calendar REST API. Visual clue is absence of the Calendar button.
Modify User Photo in Teams (client)NoDoesn’t work when mailbox is hosted in Exchange on-premises.
Call HistoryYesHistory propagates to mailboxes hosted in Exchange on-premises in ‘Teams Calls’ folder.
Access Outlook ContactsNoWorks only with Exchange Online mailboxes.
VoicemailYesMay use & receive voice-mail, but can’t play from Teams.
Free/Busy statusYesUses EWS.
Create & View/Update Teams Meetings from OutlookYesUsing default Teams Meeting add-in.
Create Teams Meetings from Outlook as DelegateNoTeams Scheduler uses AutodiscoverV2 to discover delegate EWS endpoint, and fails. Outlook will display “Sorry, but we can’t connect to the server right now. Please try again later.”
View/Update Teams Meetings from Outlook as DelegateYesEWS is used to fetch and update the calendar item.
MailTips in TeamsNoMailTips like Out of Office are not shown in Teams. MailTips work for Exchange 2016 CU3+.
Create & View Channel Meetings in TeamsNoDoesn’t work when mailbox is hosted in Exchange on-premises.
Share to TeamsNoDoesn’t work when mailbox is hosted in Exchange on-premises.

Of course, the better experience is to be had when your mailbox is hosted on Exchange 2016 CU3 or later (including Exchange 2019), or best when you simply host them in Exchange Online. However, given the circumstances and pressure from the organization to use Teams, that route might not be an option for everyone. Organizations may look at substantial investments in time and resources. In those cases, it might be good to know of alternative less preferable scenarios, and more important, any possible limitations you might encounter when taking a shortcut.

Exchange Hybrid Agent GA

Posted on by
Reply

Ex2013 LogoIn February, Microsoft released the initial public preview version of the Hybrid Agent. The purpose of the Hybrid Agent, also branded as the “Exchange Modern Hybrid Topology”, is to simplify the process of setting up and deploying Microsoft Exchange Hybrid for Exchange 2010 and later deployments, where full “classic” Exchange Hybrid is not an option.

It can also address scenarios where deploying the Hybrid Agent would satisfy organizational migration requirements. For example, moving mailboxes between Exchange Online and Exchange on-premises while providing rich-coexistence features, but without requiring (re)configuration of the publishing of Exchange services. Other functionality the Hybrid Agent doesn’t offer is mail transport. Future builds of the Hybrid Agent might introduce cross-premises functionality, such as Send As delegations as demonstrated at Microsoft Ignite last year.

This week, the Hybrid Agent Public reached General Availability status. In the following article for ENow, I discuss the major changes in the agent since the initial Preview release.

Read the full article on the ENow Software blog.

Hybrid Configuration Wizard & F12

Posted on by
1

A small tip for those running the Exchange Hybrid Configuration Wizard. As announced at Ignite yesterday, a convenient feature was added to the HCW and is available now. Pressing F12 in the HCW will now open up a panel with shortcuts to the following tools and locations:

  • Exchange Management Shell
  • Exchange Online PowerShell
  • (current) Hybrid Configuration Wizard Log File
  • Create Support Package (to zip HCW logs for support)
  • Open Logging folder (of HCW)
  • Open Process Folder (of the HCW app)

Here is how it looks:

image

This might save you an occasional click or two.

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.