Tag Archives: Azure

Azure AD, Office365

Upgrade Entra Connect Sync to Entra Cloud Sync

Leave a comment

Microsoft is offering two directory synchronization solutions for synchronizing identities from Active Directory to Entra ID:

  • Entra Connect Sync.
  • Entra Cloud Sync.

The first one is available since the beginning of directory synchronization (with different names over the years), Cloud Sync was introduced in January 2019 as the successor of the Entra Connect server.

With the introduction of Cloud-Managed Remote Mailboxes, Microsoft also announced that subsequent phases of this solution will run on Entra Cloud Sync. Therefore, it is time to consider migrating from Connect Sync to Cloud Sync.

Entra Cloud Sync

Entra Connect sync is using an on-premises server where the synchronization server is installed. This synchronization server utilizes a SQL Database (SQL Express for smaller deployments, or a SQL server/cluster for larger deployments), where all information is stored. This is called the metaverse. All aggregated data from Active Directory and Entra ID is synchronized with Entra ID.

Entra Cloud Sync is using a Sync Service in Microsoft Azure. This is where all the logic and processing take place. There’s a lightweight agent on a server on-premises that communicates with the sync service in Azure.

For available purposes, multiple of these lightweight agents can be installed on multiple servers (as long as they have internet connectivity, of course).

The features and functionality are similar; you can filter recipients by Organizational Unit, and you can create your own rules (in the rules editor) in the sync service.

Upgrade to Entra Cloud Sync

Installing the cloud sync agent is similar to installing the connect sync server. The following prerequisites apply to installing the cloud sync agent:

  • The admin account that installs the cloud sync agent and configures the cloud sync service needs an Entra ID P1 license.
  • The installation account must be a Domain Administrator or Enterprise Administrator. During the installation, a group managed service account (gMSA) is created to run the agent.
  • The minimum requirement to configure the cloud sync service is to use a Hybrid Identity Administrator in Entra ID.
  • The server where the agent is installed must run Windows 2016 or higher.

To install and configure the cloud sync agent/service, use the following steps:

  • Create a backup of your Entra Connect sync.
  • Download the cloud sync agent from the Microsoft Entra portal (https://entra.microsoft.com –> Entra ID –> Entra Connect –> Cloud Sync –> Agents as shown in the following screenshot:
  • Installing the Agent is straightforward; open the downloaded agent and follow the wizard. And for the provisioning agent extension, select HR-driven provisioning.
  • Follow the wizard and use your (cloud) admin credentials to logon to EntraID and the on-premises Active Directory and select the create gMSA option. It takes one or two minutes for the agent installation to complete, and when finished click Exit.
  • To configure the cloud sync engine, go to the Entra portal and select Entra ID –> Entra Connect –> Cloud Sync. Click +New Configuration to start the wizard.
  • In the New cloud sync configuration window you will see the Active Directory domain where the agents are installed. This does not have to be a regular TLD, but can also be a .local domain as shown in the following screenshot:
  • If you don’t see the local Active Directory domain, restart the server where the agent is installed (not sure if a reboot is mandatory, but it did help in my environment). Click Create to start the process.
  • There are multiple step you must or can do:
    • Add scoping filter (mandatory)
    • Add attribute mapping (optional)
    • Synchronization test (recommended)
  • Scoping is mandatory; this is where the agent selects the identities that need to be synchronized to Entra ID. My Entra Connect server was scoped on an Organizational Unit, so in Cloud Sync the same OU must be selected. The OU must be entered with its distinguished name, and there’s no AD browse button as shown in the following screenshot:
  • When the DN of the OU is entered, click Add, and click Save to continue.
  • The attribute mapping is optional, this is where the attributes in Active Directory are mapped to attributes in Entra ID. In a typical environment there’s no need to change this, but your environment can be different of course. Change this when needed.
  • When everything is ok, select the Provision on Demand option. Here you can test the cloud sync configuration. Create a user account in Active Directory and select this user in the Provision on demand window. Again, no browse button so you must enter the distinguished name of this user as shown in the following screenshot:
  • When everything is ok and the user account is successful created in Entra ID, click Overview, select Review and Enable and click Enable Configuration. This will finalize the wizard and cloud sync will continue to synchronize accounts with Entra ID.
  • You can now uninstall Entra Connect Sync and continue synchronizing with Entra Cloud Sync.

Manage Entra Cloud Sync

Entra Cloud Sync can be managed using the Entra Portal (https://entra.microsoft.com). Login with your administrator account and navigate to Entra Connect –> Cloud Sync. Here, you can view the cloud configuration (created in the previous step) and check provisioning logs and audit logs.

When you open the configuration for your environment, you can change it, but you can also check the properties and check the sync status info, as shown in the following screenshot:

It is also possible to manage Entra cloud sync using PowerShell. To do this, you have to install the AADCloudSyncTools PowerShell module. To install the prerequisites for this PowerShell module, execute the following commands on the server where the connect sync agent is installed:

[PS] C:\> Import-module -Name "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Utility\ AADCloudSyncTools"
Azure AD Cloud Sync Agent configured with TenantId '54263331-b7f2-49e0-9dfc-c5c8bea6ff8b'
Please start with 'Connect-AADCloudSyncTools [-LoginHint <UserPrincipalName>]' before calling any other cmdlets.

PS C:\> Install-AADCloudSyncToolsPrerequisites
Installing 'PowerShellGet' Module. Please wait...
WARNING: 'PowerShellGet' Module installed successfully. Close this PowerShell window and run 'Install-AADCloudSyncToolsPrerequisites' again.

Close the PowerShell window and rerun both commands.

PS C:\> Import-module -Name "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Utility\AADCloudSyncTools"
Azure AD Cloud Sync Agent configured with TenantId '54263331-b7f2-49e0-9dfc-c5c8bea6ff8b'
Please start with 'Connect-AADCloudSyncTools [-LoginHint <UserPrincipalName>]' before calling any other cmdlets.

PS C:\> Install-AADCloudSyncToolsPrerequisites
Installing 'MSAL.PS' Module. Please wait...
Installing 'AzureAD' Module. Please wait...
All AADCloudSyncTools prerequisites installed successfully.

No dedicated PowerShell cloud sync is created, so every time you want to use this PowerShell module, you must load it in a regular PowerShell window using the following command:

PS C:\> Import-module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Utility\AADCloudSyncTools"

To manage Entra cloud sync, execute the Connect-AADCloudSyncTools command and login to your tenant with your admin credentials. Use the Get-Command CloudSync command to get a list of all CloudSync related PowerShell commands:

PS C:\> Get-Command *CloudSync*
CommandType Name
----------- ----
Function    Connect-AADCloudSyncTools
Function    Disable-AADCloudSyncToolsDirSyncAccidentalDeletionPrevention
Function    Export-AADCloudSyncToolsLogs
Function    Get-AADCloudSyncToolsInfo
Function    Get-AADCloudSyncToolsJob
Function    Get-AADCloudSyncToolsJobSchedule
Function    Get-AADCloudSyncToolsJobSchema
Function    Get-AADCloudSyncToolsJobScope
Function    Get-AADCloudSyncToolsJobSettings
Function    Get-AADCloudSyncToolsJobStatus
Function    Get-AADCloudSyncToolsServiceAccount
Function    Get-AADCloudSyncToolsServicePrincipal
Function    Install-AADCloudSyncToolsPrerequisites
Function    Invoke-AADCloudSyncToolsGraphQuery
Function    Remove-AADCloudSyncToolsGroupMembers
Function    Repair-AADCloudSyncToolsAccount
Function    Restart-AADCloudSyncToolsJob
Function    Resume-AADCloudSyncToolsJob
Function    Set-AADCloudSyncToolsJobSchema
Function    Set-AADCloudSyncToolsTenantId
Function    Start-AADCloudSyncToolsVerboseLogs
Function    Stop-AADCloudSyncToolsVerboseLogs
Function    Suspend-AADCloudSyncToolsJob

For example, use the Get-AADCloudSyncToolsJobStatus command to view information about the most recent synchronization run between the agent and the sync service. If you need to restart a synchronization or force an interim synchronization for any reason, you can use the Restart-AADCloudSyncToolsJob command.

The Microsoft documentation on the various commands is poor (to say the least…) but you can also use the Get-Help command in PowerShell. For example, to get more information about restarting a synchronization job, execute the following command:

PS C:\> Get-Help Restart-AADCloudSyncToolsJob -Detailed

Summary

Microsoft Entra Cloud Sync is the successor to the well-known and widely used Entra Connect Server, a directory synchronization tool. Over time, you will see Microsoft move towards cloud sync, which is becoming visible with the recently announced Cloud-Managed Remote Mailboxes.

If you are still running Entra Connect Sync it time is here to start thinking about moving to cloud sync.

Exchange, Exchange Hybrid

Exchange Hybrid strange calendar behavior and mail flow

Leave a comment

In a hybrid Exchange environment, mail flow is erratic, meetings are not always visible, and the Teams calendar does not match the calendar in Outlook. The user sends an email, and all recipients receive it. However, the sender does not always receive replies, sometimes resulting in a Non-Delivery Report (NDR). Another issue is that external users send emails to a user, but the user does not always receive the messages. Also, the calendar in Teams does not match the information shown in the Outlook calendar.

This issue occurs in a hybrid Exchange environment when this user accidentally has two mailboxes: one in the Exchange server and one in Exchange Online.

One account with two mailboxes? Yes, this is usually a result of a glitch in the provisioning. Let me explain what happens:

  • A user account is created in Active Directory and most of the time, the user is added to a security group used to assign licenses in Office 365.
  • When Entra Connect runs, the user account is synchronized with Entra ID, and a license is automatically assigned to the new account. As a result, a mailbox in Exchange Online is automatically and immediately created.
  • The last step is creating a mailbox on the Exchange server. The Exchange Server will gladly accept this since it does not know the mailbox in Exchange Online.

Outlook will then connect to the mailbox in Exchange on-premises. Depending on how the mail flow is configured, mail is sometimes delivered to the Exchange Online mailbox and sometimes to the Exchange server mailbox. Since the user’s Outlook is connected to the mailbox in the Exchange server, the user will never see items delivered to the Exchange Online mailbox.

In this situation, the Teams client shows the calendar information found in Exchange Online, while the user’s Outlook looks at the calendar information in Exchange on-premises. You can guess the results.

To fix this, the mailbox in Exchange Online must be removed and to do this, you can follow these instructions:

  • Remove the M365 license from the user, typically by removing the user account from the Security Group that’s used for licensing and wait for Entra Connect Sync to kick in and synchronize with Entra ID.
  • Open Exchange Online PowerShell and execute the following command:
    Get-User | Select name,Recipient
  • The property PreviousRecipientTypeDetails must have the value ‘MailUser’. If it contains the value ‘UserMailbox’ it means that the user has a mailbox in Exchange Online (which is not what we want in this situation)
  • Execute the following command:
    Set-User -PermanentlyClearPreviousMailboxInfo
  • This will permanently remove the mailbox in Exchange Online from the user (keep in mind that it also cannot be restored anymore!)
  • Wait for Entra Connect Sync to synchronize the latest attributes so that the account now becomes a mail-enabled account.
  • Assign the license again to the server, typically by adding the user again to the Security Group used for licensing.

The user now has a mailbox in Exchange on-premises, and this mailbox is represented as a mail-enabled user in Exchange Online.

As a side note: I’ve seen this happen also in a situation where Exchange is running on-premises and Entra Connect Sync is configured without the ‘Exchange Hybrid Deployment’ option as shown in the following screenshot:

If this is the case you can use the same procedure as outlined above.

Office365

No MFA in Microsoft 365 due to lost phone (locked out)

1 Comment

I have lost my phone and thus lost my Microsoft Authenticator app. Too bad, two admin accounts in two different tenants only have the Authenticator app configured. So, when logging on to a tenant, the password is accepted, and the second factor is requested. It’s too bad this won’t work since the new phone is not configured for this tenant. I didn’t notice this earlier because in older tenants, you have the SMS option as a backup by default, and for newer tenants, this is no longer the case. My bad I’m afraid.

If the option “I can’t use my Microsoft Authenticator app right now” is selected, only a verification code is possible, which is only available in the Authenticator app. No phone number, no phone call-back, and no SMS are possible, so it’s an endless loop.

The only option right now is to log a call with Microsoft Support from a different tenant. To my surprise, the initial support agent called me within 15 minutes. After verifying that it was me, he added some notes and escalated to the compliance team.

Within two days, an engineer from the compliance team contacted me. After checking again, he found that it was me. He created a new incident in the original (not accessible) tenant and closed the current incident. He then reset the MFA configuration, and within a couple of hours, I was able to log on again with my existing password and configure MFA on my new authenticator app.

Valuable lesson learned: make sure that you have a backup MFA solution, otherwise there’s the risk of locking yourself out.

Exchange, Exchange Hybrid, Office365

Special characters in Active Directory and Exchange Online

Leave a comment

During migrations to Exchange Online I get the question regarding special characters in the User Principal Name (UPN) and e-mail address. Every time I have to check this again and again, so it’s time to do a write-up.

The UserPrincipalName (UPN)

The UserPrincipalName (UPN)

The UPN is the user’s identifier in Active Directory, and it is formatted like j.wesselius@exchangelabs.nl. It is a Microsoft recommendation to keep the user’s email address and UPN identical, but that’s not a hard requirement.

The UserPrincipalName attribute has the following characteristics and/or requirements:

  • The @ character is required.
  • The @ character cannot be the first or the last character of a UPN.
  • The total length cannot exceed the 113 characters limit. 64 characters in front of the @ character (i.e. username) and 48 characters after the @ character (i.e. domain name).
  • Allowed characters are A – Z, a – z, 0 – 9, ‘ . – _ ! # ^ ~
  • Invalid characters are \ % & * + / = ? { } | < > ( ) ; : , [ ] “
  • An Umlaut, tilde and accents are also invalid characters.
  • The UPN cannot end with a dot.
  • The UPN cannot contain spaces.
  • With directory synchronization in mind:
    • a routable domain must be used for the UPN (for a stand-alone AD this is not the case).
    • UPN must be unique and cannot contain any duplicated value in the directory (like UPN of user A is the same as e-mail address of user B).

The last bullet is something I see a lot in hybrid scenarios. In Exchange 2019 it is possible to have a user with a UPN like J.Doe@exchangelabs.nl, and another user with an identical email address J.Doe@exchangelabs.nl. Although it is confusing, it is possible on-premises.

In Exchange Online this is not possible, and when you have Entra ID in place, it will generate error messages, and strip the email address from the second user. Needless to say, you must fix this inconsistency (which can be problematic since you must remove an email address from a mailbox).

A little bit related is the samAccountName attribute of a user. This has the following limitations:

  • The maximum length is 20 characters.
  • It must be unique in the entire organization.
  • The following characters are invalid: [ ] \ | / , : < > + = ; ? * ‘ and the double quoute character “

Email Addresses

In Exchange and Exchange Online there are four e-mail address related attributes:

  • The mail attribute. The mail attribute of a recipient must be unique in the entire organization.
  • mailNickName (or alias). Must be unique in the entire organization and it cannot start with a period.
  • ProxyAddresses. This is a multi-valued attribute and has the following restrictions:
    • The maximum length of an entry is 256 characters.
    • It cannot contain a space character.
    • It must be unique in the entire organization.
    • It cannot contain any of the following characters: < > ( ) ; , [ ] and a double quote character “. The colon character : is allowed, but only after an identifier like SMTP: or X500:
    • Special characters with an umlaut, accent or tilde are invalid.
    • TargetAddress. This is used for forwarding email messages, in a hybrid environment this is the remote routing address. It is a singe value attribute, and has the same limitations as the proxyAddresses attribute.

Most likely there are more related attributes that need attention, but these are the most interesting I see when working with customers.

Azure, Exchange

Exchange Server in Azure – Part III

Leave a comment

In two previous post I blogged about a site-to-site VPN connection to Azure and about installing a Domain Controller (and Azure AD Connect) in Azure. In this blog I will discuss that last server, the Exchange 2019 server in Azure.

The last in most interesting part (in my opinion) is installing an Exchange 2019 server in Azure. This can be your last Exchange server for management purposes, or maybe an Exchange server still hosting (some) mailboxes or performing SMTP Relay. It can be quite expensive to host mailboxes on an Exchange server in Azure, moving Mailboxes to Exchange Online is much cheaper. But then…. If you are already decommissioning your own datacenter… All business requirements are different of course 🙂

Exchange in Azure Setup

Currently Exchange server are located on-premises in a hybrid scenario. There’s already a Domain Controller in Azure, and the Azure AD Connect is running in Azure too. Now I want to install an Exchange 2019 server in Azure and run the Hybrid Configuration Wizard to create a hybrid configuration with the Exchange 2019 server in Azure. Webmail and Autodiscover will point to the Exchange server in Azure as well. In short, the configuration will look something like this:

Inbound mail will be sent to Exchange Online Protection and delivered to mailboxes in Exchange Online. When a mailbox is located on-premises, it will be routed to the Exchange server in Azure and when needed, routed to the Exchange server on-premises.

But first we have to think about sizing the Exchange server in Azure.

Sizing Exchange in Azure

The first question about Exchange server in Azure is sizing the Exchange server. First of all, deploying Exchange on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage (please see the Exchange Server Virtualization article on Microsoft Learn.

When you are planning to host active mailboxes on the Exchange server running in Azure then you should use the Exchange 2019 storage requirements calculator to figure out the correct size for the Exchange server. You can find the storage calculator on the Exchange 2019 ISO images in the \Support directory.

If you are planning to install an Exchange server in Azure just for management purposes, or for lab purposes, I would recommend using a ‘Standard d8s v3’ VM. This is a VM with 8 vCPU, 32 GB memory and a maximum of 16 additional disks.
When you create a new VM in the Azure Portal and select ‘see all sizes’ it will show a list of most used virtual machines by Azure users as shown below:

For my own lab environment I selected the DS3_V2 VM. Not the fastest VM, but for my own test- and management purposes it is sufficient, but your mileage may vary of course. Attached to my VM are two SSD disks of each 1TB. Be aware that the disks can be a costly thing, especially in a lab environment! The network interface is connected to the internal VNET that was created earlier, and it is connected to the Microsoft network using a public IP address. I also created a DNS name (exchlabsnl.westeurope.cloudapp.azure.com which can be used as a CNAME record for some other DNS name) but that’s not really needed since I can use the public IP address in a regular DNS A record.

Installing and Configuring Exchange in Azure

When you have the VM up and running in Azure and you have configured the storage as required, you can install the Exchange server. This is not different from a regular Exchange server. Install the prerequisite software, patch the machine, install the latest Exchange 2019 Cumulative Update and install the latest security update for this CU.

Configuring the Exchange server in Azure is similar to configuring the Exchange server on-premises. Install a proper certificate, configure the virtual directories (hopefully needless to say, but use a different FQDN in Azure since it is a different site in Active Directory) and configure the transport database on a different disk.

Configure the Network Security Group (NSG) to allow access on port 443 and port 25 from the Internet. Depending on your security requirements, you can configure the NSG of the Exchange server with the IP ranges of Exchange Online (https://learn.microsoft.com/en-gb/microsoft-365/enterprise/urls-and-ip-address-ranges) so only Microsoft can fully access your Exchange server in Azure. If you have clients that need to connect to the Exchange server, they can use a VPN connection (that’s what I typically recommend to customers these days, and what I do in my lab environment).

If you are planning an Exchange server just for management purposes, I would recommend not using a public IP at all and only connect to the Exchange server using the private Vnet. In this scenario there’s no need to publish the Exchange server to the Internet, and all changes to recipients are replicated to Exchange Online using Azure AD Connect. No Internet connection is less prone to external attacks of course. And another interesting thing when using a management server only, you can turn it off when not in use. This can save you quite some money.

The next step is to run the Hybrid Configuration Wizard which you can download from https://aka.ms/hybridwizard. When going through the wizard, select the Exchange server in Azure for the Receive Connector configuration and for the Send Connector configuration.

When finished, add the public IP address of your Exchange server in Azure to your SPF record for outbound mail, or configure the SMTP connector to Exchange Online to route all outbound mail via Exchange Online, that’s up to your requirements of course.

What happened in my scenario, my public IP address was assigned by Microsoft and you never know what happened previously with this IP address, but I had to delist it from SpamHaus before I was able to send out email from my Exchange server.

Then move your resources from the on-premises Exchange server to the Exchange server in Azure and decommission your Exchange server on-premises when needed.

Summary

In the past three blogpost I explained what it takes to install an Exchange server in Microsoft Azure and it contains of the following steps:

  • Create a site-to-site connection between your on-premises network and a Vnet in Azure.
  • Install a Domain Controller in Azure, connected to the Vnet. Optionally you can install an Azure AD Connect server in Azure as well.
  • Install and configure an Exchange server in Azure, connected to the Vnet (and to the Internet when needed)

An Exchange server in Azure is fully supported, as long as the Mailbox database and transaction logfiles are located on premium storage, that should be no problem.

Sizing your Exchange server in Azure is like an on-premises Exchange server. Use the storage calculator to determine the size of your Exchange server, and look for a VM that matches these requirements.

When installing an Exchange server in Azure just for management purposes it’s much easier. You can use a relatively lightweight Exchange server, there’s no need to publish it to the Internet (much safer) and you can turn it off when not in use.