If you are syncing local AD users to Azure AD and using Seamless Sign-On (see https://www.ajni.it/2021/05/configuring-azure-ad-connect-for-user-synchronization/ and https://www.ajni.it/2021/05/configure-seamless-sign-on-for-microsoft-365-login-with-azure-ad-connect/), there is an awesome registry key that automatically creates the Outlook profiles without user interaction.

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

DWORD ZeroConfigExchange 1

Alternatively, you can add the DWORD ZeroConfigExchangeOnce 1 key to automate the creation of the first profile. Successful profiles have to be created manually.

References:

https://docs.microsoft.com/en-us/outlook/troubleshoot/profiles-and-accounts/let-zeroconfigexchange-automatically-create-first-profile

If you have an AD synced distribution group and want to only allow senders from your organization, the msExchRequireAuthToSendTo attribute must be set to TRUE in the Attribute Editor. If you try changing that in the Exchange Online console, an error will appear.

When syncing local AD users to Azure AD, you can configure Seamless Sign-On to automatically login to Microsoft 365 Apps like Sharepoint Online, OneDrive, or Exchange Online. This is very easy to do and will make logins for users less painful.

Assuming Azure AD Connect is already set up with Pass-through authentication (see https://www.ajni.it/2021/05/configuring-azure-ad-connect-for-user-synchronization/), just open Azure AD Connect and then hit "change user sign-in" and log in with an Azure AD Global admin. After that, select "Enable single sign-on".

Enter Domain Admin credentials.

When the pre-checks is complete, hit configure and exit.

A Computer Account named AZUREADSSOACC will be created in Active Directory which allows the authentication validation between Azure AD and local Active Directory. The Kerberos decryption key is saved in the cloud and should be changed regularly. You can see that on the Computer account, service principal names are configured

Lastly, you can roll out the feature with Group Policy. The URL https://autologon.microsoftazuread-sso.com must be added to the intranet zone list, which allows the browser to send Kerberos tickets to that site.

The GPO can be found under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List.

Status bar updates via script must be also enabled. This GPO is located under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone > Allow updates to status bar via script.

You can test the feature by opening portal.office.com. After entering the username, login should be done automatically without needing to insert a password.

References:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start

The first step in the journey to the cloud is to install and configure Azure AD Connect. This will synchronize users in local Active Directory to Azure AD and will allow you to use cloud services like OneDrive For Business, Sharepoint Online, Exchange Online, or Microsoft Teams.

Before installing the service itself, we have to set an alternate UPN suffix as in Azure AD. In Active Directory Domains and Trusts add a new UPN suffix. The suffix should be equal to the custom domain name in Azure AD.

Users synchronizing to Azure AD should have that UPN suffix set:

In the Azure AD panel, select Azure AD Connect and then "Download Azure AD Connect"

Start the installer and select "Customize"

Hit install

Select Password Hash Synchronization and login with your Azure AD global admin

Select Create new AD Account and enter Enterprise Admin credentials. The tool will automatically set the correct permission on the OU without adding Domain Admin rights to the user.

You will notice that a new user named MSOL_xxx has been created.

This is just a warning. We already set the correct UPN suffix.

Deselect the top checkbox and select the OU containing AD Users. Service users should not be synchronized.

Leave everything else on default settings and then hit install.

With the synchronization service you can check what objects have been synced and the last time a sync ran.

In Azure AD the synced user should show up. You can see that the correct UPN has been configured on the user.

If you want to manually start AD Sync, in Windows PowerShell enter this command:

Start-ADSyncSyncCycle -PolicyType Delta

When synchronizing on-prem users to Azure AD, there is a chance that Exchange attributes like msexchHideFromAddressLists are missing in Active Directory because the Exchange schema has never been updated, since there has never been a local installation of Microsoft Exchange. In that case, you could either extend the AD schema to include Exchange attributes or you could work with Azure AD synchronization rules, which is safer in my opinion.

On the Azure AD server, open Synchronization Rules Editor

Edit the rule "in from AD - User join". This will disable the rule itself and create a new one. Give the rule a descriptive name and a precedence of 50.

Under Transformations, add a new rule:

Expression msexchHideFromAddressLists IIF(IsPresent([msExchAssistantName]),IIF([msExchAssistantName]="HideFromGAL",True,False),NULL) Update

Now, you can set the attribute msExchAssistantName to HideFromGAL on the AD user. This will tell Azure AD Connect to set msexchHideFromAddressLists to true on the cloud side.

Obviously, you could use another attribute to achieve the same goal. Just change the if statement slightly.

IIF(IsPresent([msExchAssistantName]),IIF([msExchAssistantName]="HideFromGAL",True,False),NULL)

References:

https://jackstromberg.com/2018/08/how-to-hide-users-from-the-gal-in-office-365-synchronized-from-on-premises/