Office 365: Distribution List Migrations Version 2.0 – Part 38

Enabling support for migrations with pre-defined name prefix and suffix.

In Azure Active Directory administrators have access to a group naming policy. This allows administrators to enforce a naming policy for Microsoft 365 groups that are created by end users. The group naming policy does not apply to mail enabled distribution or mail enabled security groups. Customers who are considering migrating distribution lists to Office 365 may want to implement something similar for their mail enabled security or distribution groups. The desire was to utilize the migration process to begin implementing this naming convention.

 

Version 2.9.8.14 implements two new switches that administrators may use to implement a name prefix or suffix during the migration. The prefix switch -dlNamePrefix allows any string to be specified as the name prefix. The suffix switch -dlNameSuffix allows any string to be specified as the name suffix. When using a prefix or suffix this value is appended to not only the distribution group name but also the distribution group display name. This enforces the same name in both directory queries and global address list queries. Generally speaking the name and display name match. If you’re display name does not match the directory name of the group the same names will be preserved but with the prefix.

 

The directory name assigned to a group may not exceed 64 characters. When specifying a prefix, suffix, or both if the combined string length is greater than 64 characters the migration will fail and the administrator will be informed of an error in the log.

 

[PS] C:\>$group = Get-DistributionGroup “defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd”

[PS] C:\>$group.name

defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd

[PS] C:\>$group.name.Length

64

[PS] C:\>$group.Alias

defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd

[PS] C:\>$group.Alias.Length

64

 

In the above example adding any prefix or suffix will cause the migration to fail.

 

[7/19/2023 2:33:48 PM] – ********************************************************************************

[7/19/2023 2:33:48 PM] – +++++

[7/19/2023 2:33:48 PM] – Pre-requist checks failed. Please refer to the following list of items that require addressing for migration to proceed.

[7/19/2023 2:33:48 PM] – +++++

[7/19/2023 2:33:48 PM] –

[7/19/2023 2:33:48 PM] – =====

[7/19/2023 2:33:48 PM] – Alias:

[7/19/2023 2:33:48 PM] – Name: defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd

[7/19/2023 2:33:48 PM] – PrimarySMTPAddressOrUPN:

[7/19/2023 2:33:48 PM] – RecipientType:

[7/19/2023 2:33:48 PM] – GroupType:

[7/19/2023 2:33:48 PM] – RecipientOrUser:

[7/19/2023 2:33:48 PM] – ExternalDirectoryObjectID:

[7/19/2023 2:33:48 PM] – OnPremADAttribute:

[7/19/2023 2:33:48 PM] – DN:

[7/19/2023 2:33:48 PM] – ParentGroupSMTPAddress:

[7/19/2023 2:33:48 PM] – isAlreadyMigrated: False

[7/19/2023 2:33:48 PM] – isError: True

[7/19/2023 2:33:48 PM] – isErrorMessage: NAME_LENGTH_EXCEPTION: The DL Name plus the prefix and / or suffix exceeds 64 characters. To complete migration wih the prefix and / or suffix the group name must be shortened to prefix + name + suffix to less than 64 characters.

[7/19/2023 2:33:48 PM] – =====

[7/19/2023 2:33:48 PM] – Pre-requist checks failed. Please refer to the previous list of items that require addressing for migration to proceed.

out-logfile : [7/19/2023 2:33:48 PM] – Pre-requist checks failed. Please refer to the previous list of items that require addressing for migration to proceed.

At C:\Repository\DLConversionV2\DLConversionV2.psm1:2904 char:13

+ out-logfile -string “Pre-requist checks failed. Please r …

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException

+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Out-LogFile

 

If the name, prefix, and suffix combinations are less than 64 characters the migration is allowed to proceed. The module does not automatically truncate the name or replace characters in order to accommodate a prefix or suffix.

 

At the conclusion of the migration the Office 365 distribution list will have the prefix and / or suffix added to the name and display name attribute.

 

PS C:\> Get-DistributionGroup defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd | fl name,displayname

 

Name : DL-defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd-DL

DisplayName : DL-defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd-DL

 

At the conclusion of the migration the group is still retained on premises. The renaming operation occurs with the ! added to the end of the name. The name prefix or suffix is not utilized in the renamed group or any hybrid mail flow objects that are created to satisfy the migration.

 

[PS] C:\>Get-DynamicDistributionGroup defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd | fl name,alias

 

Name : defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd

Alias : defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd

 

[PS] C:\>Get-MailContact defdefdefdefdefdefdefdefdefdefdefdefdefdefdefde-MigratedByScript | fl name,alias

 

Name : defdefdefdefdefdefdefdefdefdefdefdefdefde-MigratedByScript

Alias : defdefdefdefdefdefdefdefdefdefdefdefdefdefdefde-MigratedByScript

 

[PS] C:\>Get-Group defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd! | fl name,samaccountname

 

Name : defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd!

SamAccountName : defdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefdefd!

 

By allowing administrators to manage a prefix or suffix during the migration process as groups are created they can match their desired naming conventions moving forward.

Office 365 – Distribution List Migrations Version 2.0 – Part 37

Planning distribution lists migrations to Office 365.

Office 365 – Distribution List Migrations Version 2.0 – Part 36

Introduction to Distribution List Migrations using DLConversionV2 @Pilot_365

Office 365: Graph, Dirsync, and Attribute Modifications

Microsoft Graph can be used to modify and manage properties of objects created in Azure Active Directory. In order for graph to modify and manage properties the object in Office 365 should be a cloud only object. Objects that are synchronized have their source of authority set to on-premises locking out certain attribute sets from modification in the cloud.

 

I recently worked with a customer that had a custom synchronization solution. This solution utilized Microsoft Graph to manage user properties from a directory they controlled. Each object provision in Azure as a cloud only object. Their application would manage attributes including manager, proxy addresses, and custom attributes. These are the same attributes that are accessible through Exchange Online Powershell.

 

Due to a misconfiguration directory synchronization was enable. The solution that was utilized to provide the sync interface successfully matched each user in Azure to their corresponding entry in the database. This in turn converted the objects from cloud only to directory synchronized. When this change occurred the graph application that was previously managing the attributes was no longer able to manage them.

 

Once this misconfiguration was determined the customer disabled directory synchronization. The directory synchronization disablement process can take several hours to complete but was successful in converting all objects back to cloud only. Although the objects were cloud only the subsequent graph updates failed. Specifically, attributes that would typically be set through Exchange Online Powershell interfaces such as custom attributes were failing. Other attributes such as name were successful.

 

This is a sample error in the graph application.

Operation failed

Error:

Error executing request. An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online. However, it failed. Detailed error message: Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration. DualWrite (Graph) RequestId: 689d3418-cce2-4de1-9d8a-bc8399be91f4 The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information.

 

This error is counter intuitive as we have successfully confirmed that directory synchronization was disabled. Why would we receive an error that the object is mastered on-premises? The issue is that the object was cloud only, converted to directory synchronized, and then converted to cloud only. When the conversion process between states occurs there are certain attributes that are attributed to the workloads that they were designed for. In this case extension attributes are not natively available in Azure Active Directory but are there to service Exchange Online. These attributes are added to a hidden attribute set which locks their editing to the platform they are linked to. In this case extension attributes are present for Exchange Online so they can no longer be edited in Azure Active Directory but must be edited in Exchange Online. We were able to demonstrate that the attributes were successfully modified using Exchange Online.

 

If you have software that depends on utilizing the graph interfaces to manage all users attributes do not convert them to directory synchronized. There are future architectural changes to Azure Active Directory pending which will remove this limitation and allow graph updates to continue for attributes belonging to other workloads if the users are converted between cloud synchronization states.

Office 365: Unable to add and validate a subdomain linked to a viral tenant

In Office 365 end users can sign up for trial subscriptions for service. These services may include PowerBI or Azure Rights Management as an example. The services that users were trialing often required cloud storage or services in order to service the trial. Prior to October 2021 when users signed up for these trials a “viral” or “unmanaged” Office 365 tenant was created on behalf of the trial and the user. The email domain utilized for the trial, if not associated with another Office 365 tenant, would be added to this unmanaged Office 365 instance. After October 2021 this behavior no longer occurs and has been replaced with a one time passcode process. For more information see Email one-time passcode authentication on by default starting October 2021 | Azure updates | Microsoft Azure.

 

Many administers discover that there exists a viral tenant when they choose to use the domain in the unmanaged tenant within their Office 365 instance. If the domain exists in an unmanaged tenant, it cannot be added and validated to another tenant through the standard domain add process. We have two self-service options that allow administrators to assume ownership of this domain. Admin takeover of an unmanaged directory – Microsoft Entra | Microsoft Learn. In many cases the self-service options are sufficient to allow the administrator to remove the domain and successfully validate it in the tenant of their choice.

Administrators may also test for the existence of a domain registered in Office 365 using the following link:

https://login.microsoftonline.com/common/userrealm/domain.com?api-version=2.1

Administrators replace domain.com with the domain they wish to test. If the domain is not found the following is displayed:

 

{

“NameSpaceType”: “Unknown”,

“Login”: “domain.com”,

“cloud_instance_name”: “microsoftonline.com”

}

 

If the domain is found the following information is displayed:

 

{

“NameSpaceType”: “Managed”,

“Login”: “contoso.com”,

“DomainName”: “contoso.com”,

“FederationBrandName”: “Contoso, Ltd”,

“TenantBrandingInfo”: null,

“cloud_instance_name”: “microsoftonline.com”

}

 

I recently encountered an interesting scenario where the self service options did not work. The customer that I worked with had a registered domain in their production tenant contoso.com. They also had a subdomain domain.consoto.com that they had previously used for other purposes. This domain had a legitimate external DNS namespace and an MX record pointing to Office 365. In Exchange Online the customer has configured an accepted domain contoso.com and enabled the option to accept email for this domain and all subdomains. In essence email should have been routed correctly into Office 365 and the email addresses at this subdomain functioning.

 

When the customer chooses to utilize this sub domain they noted that NDRs were generated to these addresses.

 

451 4.4.4 Mail received as unauthenticated, incoming to a recipient domain configured in a hosted tenant which has no mail-enabled subscriptions. ATTR5 [DM3NAM02FT022.eop-nam02.prod.protection.outlook.com 2023-05-10T16:06:51.301Z 08DB5127CEBAA8D8]

 

Why did this NDR occur? In this case the customer was relying on the accept mail for all subdomains feature to accept mail into their Exchange Online environment where the subdomains were not verified and added to the tenant explicitly. When mail arrives in Exchange Online, we attempt to attribute the mail to a particular tenant. In this instance the message arrived in Exchange Online due to the MX record pointing to the MX of the customers production tenant and parent domain, but the domain was attributed to the viral tenant. The viral tenant had no mail enable subscriptions, so the message was not delivered.

 

It was the non-delivery report that started the investigation of the domain and the determination it was registered to a viral tenant. The customer, having researched this began the process of asserting ownership of the domain to their production tenant. In order to assert ownership of the domain you must be able to receive email at the domain or be able to add the domain and validate it forcefully with a DNS entry. This is where things got slightly complicated.

 

The domain namespace was set to route email to the customers only email solution Exchange Online. Exchange Online was already rejecting the requests. This prevented the customer from using the internal takeover method and simply providing validation and accessing the viral tenant. To use the email option the customer would have had to find another place to route the domain email and subsequently receive it. This was not an option.

 

This led us to investigate the user of the external admin takeover method. I generally prefer the external takeover method myself as it does not involve accessing the original tenant, cleaning it up, and then removing the domain. The external method essentially just allows us to add the domain, validate it, and move on. If this method exists, why did it not work in this particular instance. In Office 365 when you add a subdomain where the parent domain is registered the domain is automatically validated. The domain has the presence of the RootDomain attribute signifying the parent / child domain relationship exists in Office 365. Attempting to add the domain with new-msolDomain generated an “unknown error”. The error was actually known in that the domain could not be added and automatically validated since it existed in an unmanaged viral tenant. If you are unable to add the domain, you are unable to get the proof of domain ownership, and therefore unable to forcefully takeover the domain.

 

Add and verify custom domain names – Microsoft Entra | Microsoft Learn

 

Add subdomains of a custom domain

If you want to add a subdomain name such as ‘europe.contoso.com’ to your organization, you should first add and verify the root domain, such as contoso.com. The subdomain is automatically verified by Azure AD. To see that the subdomain you added is verified, refresh the domain list in the browser.

If you have already added a contoso.com domain to one Azure AD organization, you can also verify the subdomain europe.contoso.com in a different Azure AD organization. When adding the subdomain, you are prompted to add a TXT record in the DNS hosting provider.

 

The self-service instructions were not going to easily work in this instance. Where there is a will there is a way! In order to self service the takeover of this domain where email could not be received by another solution we needed to use a tenant where the parent / child relationship did not exist. Fortunately for us the customer we were working with had a development tenant where the parent domain contoso.com did not exist (obviously because it existed in their production tenant). We were able to use the development tenant to add the domain, secure the ownership validation, and verify domain ownership forcefully using the external admin takeover method. Once the domain was successfully added to the development tenant it was then removed. Removing the domain freed the domain from all tenants. The customer could then add the domain explicitly to their production tenant where automatic validation was able to succeed, and the domain was added as an automatically verified subdomain of an existing parent domain. We also assume that if necessary, a trial tenant could have been utilized in place of the development tenant for these purposes.

 

I decided to write this up because it was a first for me. When I saw this in the past the customers I was working with had the ability to receive email at an alternate location for the domain. This allowed us to proceed with the internal admin takeover. The inability to receive email was a unique variable to this scenario. Although there is not necessarily a best practice recommendation, I encourage customers to add the domains to their tenants that they want to ensure are protected from being registered in other tenants. This was more of a relevant recommendation prior to October 2021 when domains would be added to unmanaged tenants but doing so even after ensures that domain ownership has been validated and is locked to the tenant where the domain resides. This may or may not be possible depending on the number of domains that a customer owns as there is an upward limit of 5000 domains.