Tag Archives: Azure AD Connect

Azure AD Connect versions

Be honest, how often do you check the software versions on your Azure AD connect server? I have to admit, Exchange is not an issue, this is updated regularly, but Azure AD Connect is a different story. At the moment of writing my Azure AD Connect version is running 1.4.38.0 (installed on December 31, 2019 so more than 6 months ago) while version 1.5.30.0 is already available for some time now (source: Azure AD Connect: Version release history). And although Azure AD Connect supports auto upgrade (Check with the Get-ADSyncAutoUpgrade cmdlet), not all updates of Azure AD Connect support auto upgrade and thus need to be upgraded manually.

Azure AD Connect older versions

It is important to have a look at the versions of Azure AD Connect, I was bit surprised (but can totally understand) to read the following on the Microsoft site:

“Starting on November 1st, 2020, we will begin implementing a deprecation process whereby versions of Azure AD Connect that were released more than 18 months ago will be deprecated. At that time we will begin this process by deprecating all releases of Azure AD Connect with version 1.3.20.0 (which was released on 4/24/2019) and older, and we will proceed to evaluate the deprecation of older versions of Azure AD Connect every time a new version releases.”

You can download the latest versions of Azure AD Connect from https://www.microsoft.com/en-us/download/details.aspx?id=47594. After starting the Azure AD Connect package, enter the global tenant admin credentials and follow the wizard.

Upgrade Azure AD Connect

The upgrade should be finished in a minute or two.

Starting with Azure AD Connect version 1.5.30.0 Microsoft implemented the Azure AD Connect sync V2 endpoint API (public preview) which will improve performance to Azure AD synchronization. You can enable the new endpoint using the following commands in a PowerShell window on the Azure AD Connect server (elevated permissions):

Set-ADSyncScheduler -SyncCycleEnabled $false
Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
Set-ADSyncAADConnectorExportApiVersion 2
Set-ADSyncAADConnectorImportApiVersion 2
set-ADSyncScheduler -SyncCycleEnabled $True

Azure AD Connect v2 endpoint

In the first screenshot you can also see the Azure AD Password Protection proxy. This was installed on December 17, 2019 and the version installed is 1.2.125.0. This is also the latest version, which you can check on Azure AD Password Protection agent version history.

The Azure AD Password Protection proxy also supports auto upgrade, you can check the settings using the Get-AzureADPasswordProtectionProxyConfiguration cmdlet on the Azure AD Connect server.

More information

HCW8001 – Unable to determine the tenant routing domain

As a consultant in messaging and collaboration I have created dozens of Exchange hybrid configurations that last years, ranging from Exchange 2010 to Exchange 2019.
Today we’ve run into an issue I have not seen before, the HCW8001 – Unable to determine the Tenant Routing Domain error:

Unable to determine the tenant routing domain

Note. In one of my earlier blogs Moving from Exchange 2010 to Office 365 somebody mentioned this specific error in the comments in September 2018.

When you click Learn more you are redirected to the following Microsoft page:
https://support.microsoft.com/en-us/help/3068010/unable-to-determine-the-routing-domain-for-the-cloud-organization-erro which states you have to enable Directory Synchronization using the following command:

Set-MsolDirSyncEnabled -EnableDirsync $true

Which of course we did, but no success.

Azure AD Connect was running fine, I checked the configuration (optional features) and found nothing strange and no errors were logged.

Optional Features

When checking the Microsoft Portal I could see Directory Synchronization was running:

Azure AD Connect

The tenant routing domain is typically something like <tenantname>.mail.onmicrosoft.com and this is set in Office 365 when installing Azure AD Connect. But when checking the Accepted Domains (in Exchange Online) this domain is not available:

Accepted Domains

There’s no way you can add this <tenantname>.mail.onmicrosoft.com domain manually (also not via the Microsoft Online Portal) so you are out of luck (I tried the Azure AD Connect server multiple times, but it didn’t work).

You can open a ticket with Microsoft Support or see if you can create a new tenant and start over again. Since this happens rarely I would be surprised you run into this again with a new tenant.

 

Upgrade Azure Connect

Although it is possible to auto-upgrade your Azure AD Connect server, not all releases are available through the auto-upgrade mechanism.

The current version of Azure AD Connect is 1.4.38.0, released on December 9, 2019 and is not available through auto-upgrade for example. The version on my Azure AD connect server is 1.4.18.0. You can easily check this in Control Panel | Programs | Programs and Features.

Azure AD Connect 1.4.18.0

For the version release history of Azure AD Connect check this page: Azure AD Connect: Version release history.

Upgrading is easy, download the latest version from Microsoft Azure Active Directory Connect download page and start the downloaded Windows installer package. When the Upgrade Azure Active Directory Connect window appears, click Upgrade and follow the wizard.

Upgrade Azure AD Connect

Enter the global tenant admin password in the Connect to Azure AD window, click Next and the Ready to Configure window appears.

Start the synchronization process when configuration completes

It will upgrade the Azure AD synchronization configuration and it will enable auto-upgrade. If needed, you can uncheck the start the synchronization process when configuration completes checkbox, this way you can make manual changes before synchronization start.

Click Upgrade and with 2 minutes the upgrade is finished, and synchronization will resume.

 

Azure AD and Office 365 Password writeback

My previous blogpost was about the Self Service Password Reset (SSPR). A nice feature for cloud identities, but this doesn’t work if you have synchronized identities or federated identities. These are managed in your on-premises Active Directory, so for SSPR to work you need to implement a password writeback solution.

Luckily this feature is available, but the standard Office 365 licenses do not include password writeback functionality. You this you need an Azure AD Premium P1 or Azure AD Premium P2 license. Enterprise Mobility + Security (EMS) E3 does include Azure AD Premium P1, EMS E5 does include Azure AD Premium P2.

To implement password writeback, you need to have SSPR up-and-running. To configure password writeback you have to run the Azure AD Connect wizard.

Note. Make sure you always have the latest version of Azure AD Connect running. Even better, use the auto update feature of Azure AD Connect to make sure you’re up-to-date. At the time of writing the latest version of Azure AD Connect was 1.1.882.0 (as of Sept. 8, 2018).

Start the Azure AD Connect wizard and select the Customize Synchronization Options. Follow the wizard until you reach the Optional Features. Check the Password Writeback option as shown in the screenshot below and click Next to continue.

optional_features

Follow the wizard until the configuration is complete and click Exit to finish the wizard and store the new configuration.
The service account that’s used by Azure AD Connect needs the appropriate permissions in your on-premises Active Directory to store the new password that has been set in Azure AD.
To find out which service account is used by Azure AD Connect, start Azure AD Connect and select View Current Configuration and check the account as shown in the following screenshot:

View_Current_Configuration

The following permissions need to be granted to the service account on either the domain object, or on an OU if you want to scope the permissions:

  • Reset password
  • Change password
  • Write permissions on lockoutTime
  • Write permissions on pwdLastSet

Open Active Directory and Computers, enable Advanced Features, select the properties of the domain, click on Security, click on Advanced and click Add.

Select the service account that was retrieved earlier under Principal and in the applies to dropdown box select Descendent User Objects. Check the following options:

  • Reset password
  • Change password
  • Write lockoutTime (scroll down)
  • Write pwdLastSet (scroll down)

Click on OK to apply the changes to Active Directory and close any following pop-up boxes.

Permission_Entry

To test the password write back option, follow the same procedure as in the SSPR blogpost. After you have changed your password, it is written back to your on-premises Active Directory and the following event is written to the eventlog of the Azure AD Connect server.

EventID_31001

Summary

In this blogpost I’ve shown you how to implement password writeback in your synchronized Azure AD environment. One prerequisite is that you need to have Self Service Password Reset implemented, and you need to have an Azure AD Premium P1 or Azure AD Premium P2.

Exchange Resource Forest and Office 365 – Part II

In my previous blog post I’ve explained more about the Exchange resource forest model where user accounts are located in a dedicated forest with only the user account (and their regular resources) and where Exchange is installed in a resource forest. There’s a forest trust between the resource forest and the account forest, and the mailboxes are configured as linked mailboxes. This is shown in the following figure:

image

In this blogpost we will add an Azure AD Connect server to enable synchronization between the on-premises Active Directories and Office 365.

Exchange Resource forest and Azure AD Connect

If we want to create a hybrid scenario with our resource forest and Exchange Online we have to implement Azure AD Connect first. Azure AD Connect will synchronize account information from the account forest, and linked mailbox information from the resource forest. To achieve this, we have to setup a multi-forest synchronization model (which is also fully supported by Microsoft).

The Azure AD Connect server will be installed in the account forest. To retrieve the information about the mailboxes from the resource forest, a service account will be used as shown in the following figure:

image

In a typical environment there’s only one Active Directory containing both user accounts and exchange servers. As such, the user accounts have the corresponding Exchange properties. In a Resource Forest scenario there are two user accounts, where the user account in the Resource Forest is disabled and this disabled account contains the Exchange properties.

The Azure AD Connect server (which is running in the Account Forest) combines the two accounts based on the objectSID and MSExchMasterAccountSid and synchronizes this ‘joined’ account information to Azure Active Directory, as shown in the following figure:

image

The prerequisites for Azure AD Connect is a Resource Forest scenario are the same as for a regular environment, so I won’t go into too much detail about this. Of course you need an internet routable domain for your accounts (i.e. don@accounts.local won’t work, so this needs to be changed to don@exchangefun.nl), your accounts need to be checked for inconsistencies with the IDFix tool and of course you have to configure your tenant in Office 365. For more information regarding the process, please check my blog Implementing Directory Synchronization. It’s a somewhat older blog, but the steps remain the same.

You can download the latest version of Azure AD Connect from the Download Azure AD Connect. I will only show the most important screenshots when running the Azure AD Connect wizard.

Azure AD Connect can be installed using an Express setup, this is the default setting and is sufficient if you have a single forest environment with less than 100,000 objects in Active Directory and where using SQL Express is sufficient. In our Resource Forest environment we have multiple Active Directory forest, so a custom setup is needed, so select Customize in the Express Settings window:

image

Continue with the wizard until you reach the User Sign-in window. Here you have to select which authentication method is used when users sign-in into Office 365. Make your selection and click Next to continue.

image

After entering the (Global) tenant administrator credentials, the forests need to be added to the Azure AD Connect wizard. In the Connect your directories window the Active Directory forest where your Azure AD Connect server resides will appear. To add this directory, click Add Directory:

image

The Add Forest Account window will appear. Here you can select if a new service account for Azure AD Connect will be created, or that an existing service account will be used. An Enterprise Admin Account will be used to create this service account, and configure Azure AD Connect for first use. It must be an Enterprise Admin account because information is written into the Configuration partition of Active Directory. Enter the credentials of the Enterprise Admin (in your Account Forest) and click OK to continue.

image

Repeat these steps for the Resource Forest, so enter the forest name, select the radio button to create a new service account and enter the Enterprise Admin credentials in the Resource Forest as shown in the following two figures:

image

image

Continue with the wizard, select the Domain/OU filtering options for both Forest and make sure you select the containers containing the user accounts in the Account Forest and the corresponding Mailboxes in the Resource Forest as shown in the following two figures:

image

image

The Uniquely identifying your users is the most important window in the Azure AD Connect wizard. This is where the user account in the Account Forest and the corresponding mailbox in the Resource Forest are tied together. In the previous blogpost I’ve explained the objectSID and the msExchMasterAccountSID, so this option is selected.

image

Continue the Azure AD Connect wizard, and in the Optional Features select the Exchange Hybrid Deployment checkbox and click Next to continue.

image

You’re now ready with the Azure AD Connect wizard. In the Ready to configure window you can chose to start the synchronization immediately, or enable the Azure AD Connect server in staging mode. In this mode it will collect all information and fill the SQL Express database with data, but it won’t write any data to Azure Active Directory until you’ve checked everything. Select the option you want and click install to finish the wizard and install/configure Azure AD Connect.

image

At the configuration complete window there are some recommendations and/or remarks for your reference, click Exit to stop the Azure AD Connect wizard.

image

Now, when you logon to the Microsoft Portal you’ll see that synchronization has occurred:

image

And when you expand the users option you’ll see which users are synchronized.

image

When you logon to the Exchange Admin Console in Exchange Online and check the Recipients | Contacts folder, you’ll see the users appear here. This makes sense, since the on-premises Mailboxes are represented as Mail-Enabled Users in Exchange Online.

image

Summary

In this blogpost I’ve showed you how to implement Azure AD Connect in an existing Exchange Resource Forest model. The Azure AD Connect server combines the user account from the Account Forest with the mailbox from the Resource Forest and synchronizes this to Azure Active Directory.

In my next blog I’ll create a hybrid environment based on the Exchange resource forest model.

Ps. a special thanks to ‘Trekveer Harry’ for his continuous brainstorm sessions and good ideas Smile