Category: Azure AD Connect

Field Notes: Meeting the requirements for Interoperability between Microsoft Teams and Microsoft Exchange Server

Reading Time: 3 minutes

In this blog post, I want to walk you through my experiences with setting up and enable the interoperability between Microsoft Teams and on-premises Microsoft Exchange Server environments.

Since the beginning of this year, Microsoft Teams adoption has seen a tremendous uptick in usage. Organizations needed to adopt Microsoft Teams as their Unified Communications (UC) platform, but the other cloud migrations went on the back burner or were not even in scope anymore for this year. All is fine, until somebody asks: "I don’t see my calendar in Microsoft Teams… Can you fix this?"

Sure we can. In this blog post, I'll walk you through the process of enabling the interoperability between the Microsoft Teams service and the on-premises Microsoft Exchange Server environment.

Requirements

Let's start with listing the Microsoft requirements and what they actually mean in real life:

Known requirements

We start with the known requirements as listed here. Summarized these are:

  • The employee identities need to be synchronized to Azure AD;
  • The organization needs to have the Exchange Hybrid option in Azure AD Connect;
  • OAuth authentication between your on-premises Exchange and Exchange Online organizations needs to be configured;
  • Microsoft Teams scheduling of meetings by delegates require an additional partner application;
  • The employees need to have to be licensed: the Microsoft Teams license to be specific;
  • The on-premises Microsoft Exchange Server environment needs to run Microsoft Exchange Server 2016 CU3 or a newer version of Microsoft Exchange Server.
  • Good to know: The Microsoft hybrid Agent (Modern Exchange Hybrid) cannot be used for the Microsoft Teams calendar integration. It is listed here in the constraints of the Microsoft Hybrid Agent.

My approach

When a customer asks “I want to have my calendar visible is Microsoft Teams, is this possible for us and what do we need to do?”, then this is my approach:

To see if it’s even possible to realize the interoperability, we need to validate the current on-premises Microsoft Exchange Server environment in terms of the version: It needs to run at least Microsoft Exchange Server 2016 with CU3. The importance of this question is in the availability of the new AutodiscoverV2 and the new REST-based application programming interface (API) in the Exchange Web Services (EWS) capabilities. But that is not all: In order to benefit from these new capabilities, the mailbox needs to be homed on a Exchange Server 2016 CU3 or higher mailbox server. If this is all true, then I validate if Autodiscover service and Exchange Web Services of Exchange Server 2016 is accessible from the internet. If not, the organizations must be willing to allow this.

Initial checks

This results in the following checks:

  • Autodiscover and Exchange Web Services (EWS) need to be accessible from the internet and pointing to a Microsoft Exchange Server that runs at least Microsoft Exchange Server 2016 CU3;
  • The mailboxes for the employees in scope need to be homed on a Microsoft Exchange Server hat runs at least Microsoft Exchange Server 2016 CU3;
  • The employees must have Microsoft Teams licenses assigned;
  • Good to Know: Microsoft Teams will not use the configured hybrid configuration within Exchange Online, but trusts the native Autodiscover functionality. Via autodiscover.domain.tld it is pointed to the on-premises environment or via SRV records it needs to point to the on-premises environment.
  • Good to Know: Autodiscover (http) redirect will not work for the Microsoft Teams integration. This might impact the current public certificates that an organization might currently use.

If any of requirements are not met or not possible to achieve, then the integration is a NO GO.

Further implementation information

When the initial requirements are all met, we can ask the following questions:

  1. Are there any Microsoft Exchange Server left in the organization that run Microsoft Exchange Server 2010?
    If a Microsoft Exchange Server 2010 is present in the environment, then the Exchange Hybrid configuration wizard will not create the OAuth configuration with Azure AD during the setup and we need to do it manually.
  2. Is a Exchange Hybrid configuration desired and on the roadmap for the organization?
    Exchange Hybrid is a requirement from Microsoft for the interoperability between Microsoft Exchange Server and Microsoft Teams. If we cannot use the Exchange Hybrid configuration wizard (which is the preferred option),  we need to configure the Oauth configuration manually. 
  3. Is it required that delegates need to be able to make appointments on behalf of the delegator?
    If so, we need to perform steps 2 and 3 of the instructions listed here. The steps will provision the trust for the Skype for Business online integration.
  4. Can we configured the Exchange Hybrid Writeback permission on the AD Connector account in Active Directory for Azure AD Connect?
    Within Azure AD Connect we need to enable the synchronization option for the Exchange Hybrid feature. This requires that the configured service account has the correct writeback permissions for Exchange attributes. The list of required attributes to which we need write permissions is listed here.

Concluding

Compared to what is documented in the Microsoft docs and the real world, some parts are missing in the explanation or the requirements list of Microsoft. In this blog post I want to give you my past experience and help you with the little details to enable organizations to implement the calendar integration.

Field Notes: How has your Azure AD Connect been configured?

Reading Time: 7 minutesAs a consultant, I see a lot of different environments. Often, I need to know the answer to one of the most important questions:

What did you select during the setup of Azure AD Connect?

The answers vary:

A colleague did the setup and has left the company, department…

A external supplier did the setup for a pilot or part of a project…

Of course, these answers are supported by a lack of documentation.

Why is this important to know?

During the setup of Azure AD Connect, the Microsoft Azure Active Directory Connect wizard shows several options. These options are only shown during the initial setup. Some of these options are not displayed when you perform the View Configuration task after initial configuration. Some options cannot be altered after the initial configuration; They can only be achieved with a new installation of Azure AD Connect, except for one option.

Initial setup options

Let's look at these options as they are presented chronologically as you perform a Custom settings installation of Azure AD Connect:

Uniquely identifying your users
(cannot be altered after initial config)

When you install your first Azure AD Connect instance and configure the connection to Azure Active Directory, the following setup options are presented on the Uniquely identifying your users page of the Microsoft Azure Active Directory Connect wizard:

image

The top half of the Uniquely identifying your users page shows the option to configure how Azure AD Connect should behave, when the organization has deployed a user account forest and resource forest Active Directory topology. However, a more common scenario is when an organization merges with another organization and is consolidating resources; Instead of two Exchange Server environments or Skype for Business Server environments, all is provisioned from one forest.

Custom installation - sourceAnchor configuration

The bottom half of the Uniquely identifying your users page allows the option to choose the source anchor.

The Microsoft documentation on these options can be found here.

Azure AD sign-in configuration
(cannot be altered after initial config)

The second option is the selection of the source for the Azure Active Directory UserPrincipalName on the Azure AD sign-in configuration page of the Microsoft Azure Active Directory Connect wizard.

image

During the installation wizard, the administrator can choose which on-premises attribute should be used to populate the Azure Active Directory UserPrincipalName attribute.

The Microsoft documentation on this option can be found here.

Filter users and devices
(can be altered after initial config)

The last option I want to discuss is intended for pilot use only. The option on the Filter users and devices page enables administrators to  scope what objects are synchronized, based on a group membership instead of a selection of Organizational Units (OUs) and containers:image

The Microsoft documentation on this option can be found here.

What is configured in Azure AD Connect

Of course, we want to answer the initial question.

Native tooling

There are two ways to get the configuration from the Azure AD Connect server using native tooling:

  1. Azure AD Connect's Graphical User Interfaces (GUIs)
  2. Windows PowerShell

The GUI provides almost all the information you need. However, if you have configured the “pilot” group filtering, you see it’s enabled, but you cannot see the actual configured group.  If you also want to see the group. Then you will need to go to the second option.

The second option is to use Windows PowerShell to get all the configured options for your Azure AD Connect configuration.

Third-party tooling

A third option is to use a third party tool called Azure AD Connect Configuration Documenter.

Using the Graphical User Interface

The steps below describe how to use the graphical user interface (GUI) to get information on the configured options:

  1. Sign in interactively to the Azure AD Connect server using an account that is a member of local Administrators and the SyncAdmins groups.
  2. Open the “Azure AD Connect ” link to the Microsoft Azure Active Directory Connect wizard, found on the desktop or start menu.
    image
  3. Click Configure on the Welcome to Azure AD Connect page:
    image
  4. Select the View current configuration task on the Additional tasks page and click Next.
    image
  5. All the configuration options are shown on the Review Your Solution page:
    image

So let's review our configured solution:

The first part provides information on the Azure AD tenant, the  Active Directory environments it is connected to and the Azure AD Connect service account per Active Directory environment:
image

The second part provides the actual configuration of the Azure AD Connect instance:
image

The top two rows of this information shows the configured options that are mentioned before:

image

In the table below I map the configuration item to the setup option.

Configuration Item Setup Option
SOURCE ANCHOR image
USER PRINCIPAL NAME image
SYNC CRITERIA image
FILTER OBJECTS TO SYNCHRONIZE BY GROUP image

As mentioned before, the GUI shows that we configured a group to scope synchronization, but it will not show the actual configured group:

image

The Windows PowerShell steps below provides the method to get the actual group name

Using Windows PowerShell

The steps below describe how to use Windows PowerShell to get information on the configured options:

  1. Sign in interactively to the Azure AD Connect server using an account that is a member of local Administrators and the SyncAdmins groups.
  2. Open Windows PowerShell as administrator.
  3. Issue the following line of Windows PowerShell: Get-ADSyncGlobalSettingsParameter | Select-Object * | Sort-Object -Property Name | Out-GridView
  4. It will now show the configured options of Azure AD Connect:
    image

In the Out-GridView windows there are multiple entries. In the table below a overview of the configuration items and setup option is shown:

Configuration item Setup Option
Microsoft.OptionalFeature.GroupFiltering image
Microsoft.SynchronizationOption.AnchorAttribute image
Microsoft.SynchronizationOption.JoinCriteria image
Microsoft.SynchronizationOption.UPNAttribute image

To get the actual configured group that is configured on the Filter users and devices page, follow these steps:

  1. Issue the following line of Windows PowerShell in the elevated Windows PowerShell window:( (Get-ADSyncConnector).GlobalParameters | Where-Object {$_.Name -eq "Connector.GroupFilteringGroupDn"} ).Value
  2. It will now show the configured group:image

Using the Azure AD Connect Configuration Documenter

The Azure AD Connect Configuration Documenter is a free tool to document the configuration of Azure AD Connect. It is available on GitHub.

I use this tool every time when an update is needed of a Azure AD Connect instance. I use it to get a snapshot of the configuration before an update and after the update. Also, I use it to compare the configuration between Azure AD Connect instances, when an organization has one or more Azure AD Connect Staging Mode instances running or has instances running in their development, test, acceptance and production environments.

To use the tool, follow the provided instructions located in the readme file on GitHub.

The tool creates a report. In the report, there is a Global Settings section and this looks similar to the output when you'd use Windows PowerShell:

image

At time of writing this blog. The Azure AD Connect Configuration Documenter doesn’t show the configured group on the Filter users and devices page, if the option to filter based on a group has been activated.

Concluding

For me, as a consultant, it's important to provide as much documentation as possible to the customer about what I did or what is configured.

When I configure Azure AD Connect,  I use the Problem Step Recorder (PSR) a lot, which is available by default on Windows installations and installations of Windows Server with the Desktop Experience. PSR takes a full screenshot when you click your mouse and when you type and leave the entry field. The PSR file of my activities is the raw draft for the actual as-built documentation that I always deliver to my customers.

I hope every consultant and systems administrator uses the same method, but it's not always the case. If not, I use the described methods to retrieve the actual Azure AD Connect configuration.

I hope to have given you the tools to retrieve the configuration yourselves, and find out what is actually configured, too.