Office 365: Challenges with Distribution Groups for Migrated Mailboxes and a Script Based Solution ( Script Version 1.0 )

===========================================================================================

Group Migration Script v1.0 –> https://github.com/timmcmic/DLConversion/blob/master/src/DLConversion.ps1

===========================================================================================

Distribution groups are an excellent way to organize multiple recipients under a single address. Like Exchange Server on-premises, Office 365 supports mail-enabled distribution groups, security groups, and dynamic distribution groups. When Active Directory and Exchange are used on-premises, distribution groups are typically created in the on-premises Active Directory and Azure Active Directory Connect is used to maintain and replicate the distribution groups to Office 365.

Generally, there are two types of administration models that use distribution groups (which can co-exist or be used exclusively):

1. The first model uses centralized administration for all configuration and membership changes. When a member needs to be added or removed, the help desk or an admin typically processes the request. When co-existing with Office 365 this type of administration model is very effective. With all changes originating on premises – Azure AD Connect can easily replicated them into the Azure AD where Office 365 workloads can process them.

2. The second model delegates some or all to the user that owns the distribution group. In this model, Outlook is used for management of the distribution group. In a hybrid configuration, this model often creates management challenges. Outlook processes the membership changes by modifying membership on the domain controller provided to the user’s mailbox by Active Directory. After the membership change is made, Azure AD Connect pushes the requested changes to Azure AD where Office 365 workloads can process them. Office 365 mailboxes receive their list of domain controllers from Exchange Online, which prevents distribution group synchronized from on-premises from being modified in Office 365. Therefore, anyone whose mailbox has been migrated to Office 365 can no longer managed distribution groups. The same is also true for administrators that attempt to manage the distribution group in Office 365.

When asked how to allow migrated mailboxes to manage distribution groups that are owned by the mailboxes the answer is to migrate the distribution groups to Office 365. For some, this involves manually deleting and recreating the distribution groups. Others have also found scripts to do this, but they don’t always address all the attributes associated with a distribution group and instead focus on simple attributes like proxy addresses, membership, name, etc.

In this post, I’ll show you a script that addresses these concerns and allows you to migrate distribution groups to Office 365 with full fidelity. Before we get into the script, let’s look at some of the challenges encountered when attempting to migrate distribution groups.

Group Membership

Distribution groups created on-premises are managed using AD tools or Exchange management tools. When managing distribution groups with Exchange tools, membership rules are enforced (for example, a member can be added only if the object is mail-enabled). This can include mail contacts, mail users, and mailboxes. Groups and users, both mail-enabled and not, can be added using Exchange tools. AD tools are more forgiving, though; the administrator can add any valid AD object to the group membership (for example, a contact that is not mail-enabled could be added to the distribution group, although this would have no effect on mail flow).

Exchange Online has a set of rules for objects that are replicated from Azure AD to Exchange Online Active Directory. If an object is not mail-enabled, it is not represented in Exchange Online AD. This includes any groups that are members of an on-premises distribution group but not mail-enabled. An exception to this rule is user accounts. User account objects are replicated to Exchange Online even if they are not mail-enabled.

When migrating distribution groups, all objects that are not mail-enabled or users must be filtered out. Here is an example of a distribution group that contains a mix of members.

PS C:\> Get-DistributionGroupMember -Identity Migrate

Name              RecipientType
—-              ————-
Domain Users      Group
Journal Mailbox   UserMailbox
Brian Murphy      MailContact
Timothy McMichael MailUser
Migrate1          MailUniversalSecurityGroup
Migrate2          MailUniversalDistributionGroup
Team Manager      User
Dynamic           DynamicDistributionGroup
Test Contact      Contact

Users and Groups

For users and groups to be members of a distribution group they must exist in Office 365. There are common scenarios where Organizational Units are intentionally excluded from replication to Azure Active Directory. Before migrating any distribution groups you must ensure that the members exist in Office 365. If they don’t, attempts to create the distribution group through automation will fail. Since it is possible for groups to have other group as members, any type of migration of a group to Office 365 will require removal of the on-premises group. If the groups that are members are not migrated first, their membership in that group would be lost.

Multivalued Attributes

Distribution groups have several multi-valued attributes that require consideration before migrated. The attributes managedBy, moderatedBy, acceptMessagesOnlyFromSendersOrMembers, grantSendOnBehalfTo, rejectMessagesFromSendersOrMembers, and bypassModerationFromSendersOrMembers, for example, store their member references as distinguished names of objects. Here is a sample output:

PS C:\> $a=Get-DistributionGroup migrate
PS C:\> $a.managedBy
domain.local/Organization/Users/Officers/Timothy McMichael
domain.local/Organization/Users/Officers/Bill Smith
PS C:\> $a.moderatedBy
domain.local/Organization/Users/Officers/Timothy McMichael
PS C:\> $a.AcceptMessagesOnlyFromSendersOrMembers domain.local/Organization/Users/Officers/Bill Smith
domain.local/ConvertedDL/Migrate1
PS C:\> $a.BypassModerationFromSendersOrMembers
domain.local/ConvertedDL/Migrate1
PS C:\> $a.RejectMessagesFromSendersOrMembers
domain.local/ConvertedDL/Migrate2
PS C:\> $a.GrantSendOnBehalfTo
domain.local/Organization/Users/Officers/Timothy McMichael

If these attributes were extracted as arrays and then used with Office 365, the references would not work because the DNs of the objects stored in Office 365 needs to reference the DN of the object in Exchange Online.

The managedBy attribute is a shared attribute with Active Directory, and it can be set to a non-mail-enabled user. In Exchange Online, only a valid recipient object can be entered in the managedBy field. Thus, before you can convert the distribution group, you must ensure that all members of the managedBy field are Exchange Online recipients.

The remaining multi-valued attributes can only be set via Exchange cmdlets, which ensures that the objects are mail-enabled user objects.

Proxy / Email Addresses

The email addresses field is a multi-valued attribute. If the proxy addresses are not in use on another object in Exchange Online, they can be moved to the new distribution group. Note, that it is important to preserve the Reply To functionality. Migrated distribution groups don’t really change – they have the same name, same proxy addresses, and same members. But the nickname cache in Outlook uses the distinguished name of the group (which points to on-premises). If a user were to address an email to the migrated group by selecting the group from nickname cache, the message would NDR.

Other Attributes

Other attributes of a distribution group are mostly text based, allowing them to be exported and imported as text. There are also several Boolean values that can be translated to the equivalent on the new distribution group, including custom attributes.

Group Migration Script

The group migration script described in this post considers all the factors presented above. Executing the script starts by preparing some pre-requisites.

Prerequisites

The first pre-requisite is to establish an Organizational Unit (OU) within Active Directory that is not synchronized to Azure Active Directory. This OU will be where the group objects will be moved during the conversion process. The conversion process in v1 of the script retains the original distribution group. The distinguished name of this group will need to be recorded as it will be a script variable.

The second pre-requisite involves creating a secure credentials XML file that can be used by the script. The administrator must note the file names and the path where they are stored. These are variables within the script that must be updated, or the administrator can match the files contained in the script. Create one file for on-premises credentials and one file for cloud credentials. If using XML files is not your preferred method of handling credentials, you can modify the script to prompt for credentials or consider storing credentials using other methods supported by PowerShell.

$cred = get-credential

$cred | export-cliXML –path c:\Scripts\credentials.xml

For on preemies a domain administrator account is required. This account is required to move groups between OUs, track group membership in future versions, perform inbound and outbound replication from the specified domain controller, and make WinRM powershell connections to the domain controller where these operations will be performed. The account will also require Exchange Organization Administrator rights in order to perform Exchange Remote Powershell connections and issue Exchange commandlets.

For Office 365 at minimum a Exchange Organization Administrator is required – most commonly a global administrator is utilized. It is important to note that the account CANNOT utilize multi-factor authentication. The script manages multiple basic authenticated powershell sessions – and cannot utilize MFA or the modern powershell enabled module for Exchange Online.

One caveat to using these files is that they are signed to the user and machine on which they were created. Therefore, all admins using the script have to create their own sets of files.

The third pre-requisite is to ensure that the PSLOGGING module from the PowerShell Gallery is installed. This module is necessary to create files that record operations along with clean-up and logging when an error has occurred.

install-module PSLOGGING

The fourth pre-requisite is to configure Basic authentication on a local PowerShell directory. By default, Basic authentication is not enabled in on-premises, which limits the ability to create a “remote” PowerShell session to on-premises Exchange server. Administrators often work around this by identifying one server where Basic authentication is enabled or by enabling Basic authentication on all PowerShell virtual directories behind a load-balanced name. Whether a single server or multiple servers are used, it is a requirement to establish an SSL session to the name provided, which means there must be a public certificate installed on the specified endpoint.

Get-PowerShellVirtualDirectory –server <SERVERNAME> | Set-PowerShellVirtualDirectory –basicAuthentication:$TRUE

The last pre-requisite is to review the variables contained within the script for any necessary modifications. Variables that are recommended for the admin to adjust are noted with ###ADMIN### in front of their definition. These variables include PowerShell URLs, paths, and file names.

Script Mechanics

With the pre-requisites covered, let’s dive into the mechanics of how the script works and review the individual functions.

The process starts by gathering the credentials XML files and preparing them for use in subsequent functions. The success or failure of these operations is largely dependent on ensuring the credentials stored in the files are accurate and that the associated variables with the files have been updated successfully.

The script then proceeds to create the necessary PowerShell sessions for operations to be performed. There are three PowerShell sessions created:

1. The first session is to an on-premises server where commands will operate against on-premises recipient objects.

2. The second session is to Office 365 where Office 365 recipient commands will be executed.

3. The third session is to the Azure AD Connect server, which will be used to invoke synchronization as recipient objects are modified.

To activate the on-premises and Office 365 PowerShell sessions, they must be imported. When importing remote PowerShell sessions, you can often have the same cmdlets returned in each session. In this case, there is definite overlap between Exchange and Exchange Online. To avoid any confusion when importing the Office 365 PowerShell session we append the cmdlets with O365. This effectively takes a cmdlet like Get-Recipient and makes it Get-O365Recipient. PowerShell is smart enough to detect the correct cmdlet and invoke it within the appropriate session.

After the underlying PowerShell sessions are started, the script exports all properties of the on-premises distribution group and all properties of the Office 365 distribution group to variables for later use. The Office 365 distribution group should match the on-premises group as the source of authority for the Office 365 group is on-premises.

After the data has been extracted, the script performs a safety check against the distribution group, which reviews the directory synchronization flag of the distribution group in Office 365. If this flag is set to FALSE, it indicates that the distribution group is cloud-only. If this scenario occurs, the script is automatically ended. The script can only be so smart, and it uses the SMTP address of the on-premises distribution group to locate the replicated copy in Office 365. Because it’s possible for a group in Office 365 and on-premises to share the same address even though they are not directory synchronized, the script must stop because if it continued, the Office 365 group would be removed and replaced with the on-premises group which could have unintended consequences.

After the safety check is complete, the script records and exports the information for the on-premises and Office 365 groups to XML files defined by the administrator. XML output allows us to retain full fidelity of the multivalued attributes in case something goes wrong, or we need to manually correct a failure condition.

The last portion of data collection (membership) and backup then proceeds. Membership is obtained and written to a variable that will be used in later operations. It is also exported to XML file to ensure that we have a copy of the information prior to starting any of the conversion activities.

With all the pertinent information stored within variables and backup XML files, the next step is processing this information. In the previous section, I outlined some of the challenges in working with this data. There can be non-mail-enabled objects that need to be accounted for – these will not have primary SMTP addresses. There are mail-enabled objects that need to be accounted for but may be stored as distinguished names on certain attributes. Knowing that we need to account for all these differences forces us to develop a method to translate those individual users and recipients to objects that can be located in Exchange Online. To that end, we know that we can locate recipients via their primary SMTP address or a user account through the user principal name. So, the script iterates through all the multi-valued attributes and attempts to normalize the data into references that can be found in Exchange Online. If the object is a recipient class, we record the primarySMTPAddress of the object. If the object is a non-mail-enabled user, we record the userPrincipalName of the object. For each multi-valued attribute this culminates in an individual array of references that will allow us to find the objects in Exchange Online.

When the arrays of normalized data have been built we need to validate that the objects can be found in Exchange Online. The script looks for objects in Exchange Online using Get-Recipient and Get-User cmdlets in the Office 365 PowerShell. If the object is found, the recipient or user is valid and is synchronized by Azure AD Connect. If an object is not found, the process stops and allows the administrator to correct any issues. Groups can also be members of distribution groups, so the script reviews all groups that are members and determines if they have been migrated to Office 365. Assuming all users are found, and all member groups have been migrated, it is safe to proceed with the migration.

The first step in finalizing the migration is to move the distribution group to the OU that does not synchronize. As the script proceeds, Azure AD Connect will see this as a group deletion and eventually remove it from Office 365. The removal from Azure AD will propagate to Exchange Online Active Directory, resulting in the distribution group becoming deleted.

To ensure that all domain controllers show that the group was moved to the OU, repadmin is used to force replication across all domain controllers in the domain. If your domain is very large, consider changing this function to a list of domain controllers or to a single domain controller. You can also comment out the function and just increase the wait time to allow for normal replication to occur.

With domain replication underway/completed, next is to remove the distribution group from Azure AD. This process uses a remote PowerShell session to perform a delta synchronization. A delta synchronization may already be in progress, so the script is designed to retry every 1 minute until it can assure that at least one delta sync was triggered by the script. A delta sync can take several minutes to run depending on the size of the environment, and it only removes the group from Azure AD. The forward synchronization process will detect the groups removal from Azure AD and synchronize the change to Exchange Online. Because there really is no way to monitor progress once the delta synchronization is issued, the script begins issuing calls to Azure AD for the group. If the call is successful, the group still exists, and the script waits 1 minute between attempts, looping until the group is not found (basically, an error occurs locating the group, which confirms the group is no longer in Office 365).

Once the group has been removed the script can now create the new replacement group using the base settings. Next, all the non-multivalued attributes of the distribution group are set, including email addresses, custom attribute, extension attributes, and other Boolean variables that control mail flow, delivery, etc. Next, multi-valued attributes are set by using the normalized arrays that were built previously. After all attributes have been addressed, the new distribution group in Office 365 now mirrors the original distribution group on-premises.

The final step is to gather all the settings of the new distribution group and export them to XML, which serves as a record of the operation. At the end of the script, all created PowerShell sessions are removed in preparation for the next migration.

Frequently Asked Questions

Q: How can I prevent PowerShell sessions from timing out?

A: There is really no method to prevent the PowerShell settings from timing out. During testing, we determined that the operation that ran the longest was building the array of normalized SMTP addresses for the distribution group membership. When the PowerShell session to Office 365 was left open during this process it would often be closed before we were ready to proceed with other portions. It was also determined that when processing long arrays (for example, adding all the distribution group membership), the session may time out. To overcome this, we routinely reset the session to Office 365 after portions of the script that took more time to process data.

Q: Can the script be run in bulk?

A: It is possible to feed the script a list of proxy addresses for distribution groups to migrate by calling the script multiple times. The process through would repeat in terms of domain controller replication, Azure AD Connect synchronization, etc. The original design of the script approached this from the perspective of servicing one-off requests for migration and not necessarily bulk migrations or conversions.

Q: Is the script efficient?

A: Efficiency is always relative…is it more efficient then trying to do all of this by hand and manage all the attributes? Certainly. The script must rely on several processes that do not necessarily have any guaranteed timelines. For example, we can’t predict how long a delta sync or forward sync will take. Thus, it’s not possible to give you a 100% accurate estimate of how long it takes to migrate a distribution group. There is also a great deal of logging that occurs during the script which adds some overhead, but given the nature and importance of distribution groups, having the additional information is important.

Q: What is the largest distribution group size that was tested?

A: The script was validated using a distribution group with 10,000 members and had a minimum of 10 members in each of the multi-valued attributes.

Q: How long did it take to migrate a group with 10,000 members?

A: A little more than 3 hours:

Days              : 0
Hours             : 3
Minutes           : 6
Seconds           : 57
Milliseconds      : 768
Ticks             : 112177687252
TotalDays         : 0.129835286171296
TotalHours        : 3.11604686811111
TotalMinutes      : 186.962812086667
TotalSeconds      : 11217.7687252
TotalMilliseconds : 11217768.7252

Q: What happens to mail flow during the migration process?

A: It depends. The distribution group is maintained on-premises during this entire process. If messages enter the on-premises environment first and are addressed to the distribution group, you can expect that expansion will occur and message delivery will happen. The group in Office 365 is in flux during the entire migration process. If the group is missing and a message is received, it may NDR. If the group has been created but member addition is in-progress, then only some of the members may receive it. I recommend that you provide warnings to distribution group owners that mail flow will be affected during the transition.

Q: If the distribution group is a mail-enabled security group, and that group has been assigned permissions to Office 365 workloads, what happens during the conversion?

A: Permissions would be lost. The script only works because the group is deleted – and this would be processed by other workloads as a group deletion.

Q: Do I have to keep the on-premises distribution group post-migration?

A: It depends. If messages are processed through the on-premises environment, there needs to be a corresponding mail-enabled object. We are looking into automating the conversion of the group to a mail contact in a future version of the script to allow for mail flow to continue.

Q: Dynamic distribution groups are not replicated by Azure Active Directory Connect. How does the script handle dynamic distribution groups?

A: Administrators must manually create dynamic distribution groups in Office 365. The script intentionally does not treat dynamic distribution groups differently then a normal recipient. In this case we detect a member and record the primary SMTP address. When we run the recipient test against Office 365 by primary SMTP address – the recipient is returned and the script can proceed. If the recipient is not found the script will fail.

Sample Invocations

===============================================================================

Attempting to convert the distribution group Migrate without ignoring invalid managers or invalid members. The group to be converted IS NOT located in Office 365. An error is generated and the script stops.

PS C:\Scripts> .\ConvertDL.ps1 -dlToConvert Migrate -ignoreInvalidDLMember:$FALSE -ignoreInvalidManagedByMember:$FALSE

Directory: C:\Scripts

Mode                LastWriteTime         Length Name
—-                ————-         —— —-
-a—-        9/18/2018   7:17 PM              0 DLConversion.log
***************************************************************************************************
Started processing at [09/18/2018 19:17:22].
***************************************************************************************************

Running script version [1.0].

***************************************************************************************************

This function imports the on premises secured credentials file….
The on premises credentials file was imported successfully.

This function imports the Office 365 secured credentials file….
The Office 365 credentials file was imported successfully.

This function creates the powershell session to on premises Exchange….
The powershell session to on premises Exchange was created successfully.

This function creates the powershell session to Office 365….
The powershell session to Office 365 was created successfully.

This function creates the powershell session to AAD Connect….
The powershell session to AAD Connect was created successfully.

This function imports the powershell session to on premises Exchange….
WARNING: The names of some imported commands from the module ‘tmp_y0ib5tyw.pmz’ include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb.

Name              : tmp_y0ib5tyw.pmz
Path              : C:\Users\admin.domain\AppData\Local\Temp\tmp_y0ib5tyw.pmz\tmp_y0ib5tyw.pmz.psm1
Description       : Implicit remoting for https://webmail.domain.com/powershell

Guid              : 1dfe9d4c-8ca2-4de2-aa8c-8e0281af907c
Version           : 1.0
ModuleBase        : C:\Users\admin.domain\AppData\Local\Temp\tmp_y0ib5tyw.pmz
ModuleType        : Script
PrivateData       : {ImplicitRemoting}
AccessMode        : ReadWrite
ExportedAliases   : {}
ExportedCmdlets   : {}
ExportedFunctions : {[Add-ADPermission, Add-ADPermission], [Add-AvailabilityAddressSpace,
                     Add-AvailabilityAddressSpace], [Add-ContentFilterPhrase, Add-ContentFilterPhrase],
                     [Add-DatabaseAvailabilityGroupServer, Add-DatabaseAvailabilityGroupServer]…}
ExportedVariables : {}
NestedModules     : {}

The powershell session to on premises Exchange was imported successfully.

This function imports the powershell session to Office 365….
WARNING: The names of some imported commands from the module ‘tmp_rt1gncnz.op4’ include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb.

Name              : tmp_rt1gncnz.op4
Path              : C:\Users\admin.domain\AppData\Local\Temp\tmp_rt1gncnz.op4\tmp_rt1gncnz.op4.psm1
Description       : Implicit remoting for https://outlook.office365.com/powershell-liveID/

Guid              : f829f0b4-a669-4e18-a789-4afa9e4e9bd0
Version           : 1.0
ModuleBase        : C:\Users\admin.domain\AppData\Local\Temp\tmp_rt1gncnz.op4
ModuleType        : Script
PrivateData       : {ImplicitRemoting}
AccessMode        : ReadWrite
ExportedAliases   : {}
ExportedCmdlets   : {}
ExportedFunctions : {[Add-o365AvailabilityAddressSpace, Add-o365AvailabilityAddressSpace],
                     [Add-o365DistributionGroupMember, Add-o365DistributionGroupMember],
                     [Add-o365MailboxFolderPermission, Add-o365MailboxFolderPermission], [Add-o365MailboxLocation,
                     Add-o365MailboxLocation]…}
ExportedVariables : {}
NestedModules     : {}

The powershell session to Office 365 was imported successfully.

This function collects the on premises distribution list configuration….
The on premises distribution list information was collected successfully.

This function collects the Office 365 distribution list configuration….

The operation couldn’t be performed because object ‘Migrate’ couldn’t be found on
‘CO1PR06A002DC02.NAMPR06A002.prod.outlook.com’.
     + CategoryInfo          : NotSpecified: (:) [Get-DistributionGroup], ManagementObjectNotFoundException
     + FullyQualifiedErrorId : [Server=MWHPR06MB2446,RequestId=bef7d47e-8d2d-4c75-a6d4-40264dee7723,TimeStamp=9/18/2018
7:17:47 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException]
F71693B4,Microsoft.Exchange.Management.RecipientTasks.GetDistributionGroup
     + PSComputerName        : outlook.office365.com
The operation couldn’t be performed because object ‘Migrate’ couldn’t be found on
‘CO1PR06A002DC02.NAMPR06A002.prod.outlook.com’.
     + CategoryInfo          : NotSpecified: (:) [Get-DistributionGroup], ManagementObjectNotFoundException
     + FullyQualifiedErrorId : [Server=MWHPR06MB2446,RequestId=bef7d47e-8d2d-4c75-a6d4-40264dee7723,TimeStamp=9/18/2018
     7:17:47 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] F71693B4,Microsoft.Exchange.Management.Rec
   ipientTasks.GetDistributionGroup
     + PSComputerName        : outlook.office365.com

ERROR: The Office 365 distribution list information could not be collected – exiting.
ERROR: The operation couldn’t be performed because object ‘Migrate’ couldn’t be found on ‘CO1PR06A002DC02.NAMPR06A002.prod.outlook.com’.
This function cleans up all powershell sessions….
All powershell sessions have been cleaned up successfully.

***************************************************************************************************
Finished processing at [09/18/2018 19:17:47].
***************************************************************************************************

===============================================================================

Attempting to convert the distribution group Migrate without ignoring invalid managers or invalid members. The group contains another distribution or security group that is not mail enabled. An error is generated and the script stops.

PS C:\Scripts> .\ConvertDL.ps1 -dlToConvert Migrate -ignoreInvalidDLMember:$FALSE -ignoreInvalidManagedByMember:$FALSE

Directory: C:\Scripts

Mode                LastWriteTime         Length Name
—-                ————-         —— —-
-a—-        9/19/2018   2:11 PM              0 DLConversion.log
***************************************************************************************************
Started processing at [09/19/2018 14:11:07].
***************************************************************************************************

Running script version [1.0].

***************************************************************************************************

This function imports the on premises secured credentials file….
The on premises credentials file was imported successfully.

This function imports the Office 365 secured credentials file….
The Office 365 credentials file was imported successfully.

This function creates the powershell session to on premises Exchange….
The powershell session to on premises Exchange was created successfully.

This function creates the powershell session to Office 365….
The powershell session to Office 365 was created successfully.

This function creates the powershell session to AAD Connect….
The powershell session to AAD Connect was created successfully.

This function imports the powershell session to on premises Exchange….
WARNING: The names of some imported commands from the module ‘tmp_rmsylwqo.1zq’ include unapproved verbs that might
make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the
Verbose parameter. For a list of approved verbs, type Get-Verb.

Name              : tmp_rmsylwqo.1zq
Path              : C:\Users\admin.domain\AppData\Local\Temp\tmp_rmsylwqo.1zq\tmp_rmsylwqo.1zq.psm1
Description       : Implicit remoting for https://webmail.domain.com/powershell

Guid              : bb38fffd-b692-41c6-bb7f-ac49fe3a006b
Version           : 1.0
ModuleBase        : C:\Users\admin.domain\AppData\Local\Temp\tmp_rmsylwqo.1zq
ModuleType        : Script
PrivateData       : {ImplicitRemoting}
AccessMode        : ReadWrite
ExportedAliases   : {}
ExportedCmdlets   : {}
ExportedFunctions : {[Add-ADPermission, Add-ADPermission], [Add-AvailabilityAddressSpace,
                     Add-AvailabilityAddressSpace], [Add-ContentFilterPhrase, Add-ContentFilterPhrase],
                     [Add-DatabaseAvailabilityGroupServer, Add-DatabaseAvailabilityGroupServer]…}
ExportedVariables : {}
NestedModules     : {}

The powershell session to on premises Exchange was imported successfully.

This function imports the powershell session to Office 365….
WARNING: The names of some imported commands from the module ‘tmp_4korcvyz.ikr’ include unapproved verbs that might
make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the
Verbose parameter. For a list of approved verbs, type Get-Verb.

Name              : tmp_4korcvyz.ikr
Path              : C:\Users\admin.domain\AppData\Local\Temp\tmp_4korcvyz.ikr\tmp_4korcvyz.ikr.psm1
Description       : Implicit remoting for https://outlook.office365.com/powershell-liveID/

Guid              : 1a019be1-7a24-410f-b38e-37dbcc282021
Version           : 1.0
ModuleBase        : C:\Users\admin.domain\AppData\Local\Temp\tmp_4korcvyz.ikr
ModuleType        : Script
PrivateData       : {ImplicitRemoting}
AccessMode        : ReadWrite
ExportedAliases   : {}
ExportedCmdlets   : {}
ExportedFunctions : {[Add-o365AvailabilityAddressSpace, Add-o365AvailabilityAddressSpace],
                     [Add-o365DistributionGroupMember, Add-o365DistributionGroupMember],
                     [Add-o365MailboxFolderPermission, Add-o365MailboxFolderPermission], [Add-o365MailboxLocation,
                     Add-o365MailboxLocation]…}
ExportedVariables : {}
NestedModules     : {}

The powershell session to Office 365 was imported successfully.

This function collects the on premises distribution list configuration….
The on premises distribution list information was collected successfully.

This function collects the Office 365 distribution list configuration….
The Office 365 distribution list information was collected successfully.

This function validates a cloud DLs saftey to migrate….
The DL is safe to proeced for conversion – source of authority is on-premises.

This function writes the on prmeises distribution list configuration to XML….
The on premises distribution list information was written to XML successfully.

This function writes the Office 365 distribution list configuration to XML….
The Office 365 distribution list information was written to XML successfully.

This function collections the on premises DL membership….
The DL membership was collected successfully.

This function writes the on prmeises distribution list membership configuration to XML….
The on premises distribution list membership information was written to XML successfully.

This function removes the Office 365 powershell sessions….
All powershell sessions have been cleaned up successfully.

Begin processing a DL membership array.
This function builds an array of DL members or multivalued attributes….

ERROR: Domain Users
ERROR: A non-mail enabled or Office 365 object was found in the group.
ERROR: Script invoked without skipping invalid DL Member.
ERROR: The object must be removed or mail enabled.
ERROR: EXITING.
This function cleans up all powershell sessions….
All powershell sessions have been cleaned up successfully.

***************************************************************************************************
Finished processing at [09/19/2018 14:11:55].
***************************************************************************************************

===============================================================================

Attempting to convert the distribution group Migrate without ignoring invalid managers or invalid members. The group contains another mail enabled distribution group that has not been migrated to Office 365. The script automatically stops as all sub groups need to be migrated prior to top level groups. The script was also run with –ignoreInvalidDLMembers TRUE – all non-mail enabled members or members not represented in Office 365 ar automatically ignored.

PS C:\Scripts> .\ConvertDL.ps1 -dlToConvert Migrate -ignoreInvalidDLMember:$TRUE -ignoreInvalidManagedByMember:$FALSE

Directory: C:\Scripts

Mode                LastWriteTime         Length Name
—-                ————-         —— —-
-a—-        9/19/2018   2:22 PM              0 DLConversion.log
***************************************************************************************************
Started processing at [09/19/2018 14:22:24].
***************************************************************************************************

Running script version [1.0].

***************************************************************************************************

This function imports the on premises secured credentials file….
The on premises credentials file was imported successfully.

This function imports the Office 365 secured credentials file….
The Office 365 credentials file was imported successfully.

This function creates the powershell session to on premises Exchange….
The powershell session to on premises Exchange was created successfully.

This function creates the powershell session to Office 365….
The powershell session to Office 365 was created successfully.

This function creates the powershell session to AAD Connect….
The powershell session to AAD Connect was created successfully.

This function imports the powershell session to on premises Exchange….
WARNING: The names of some imported commands from the module ‘tmp_b11x0ew3.20l’ include unapproved verbs that might
make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the
Verbose parameter. For a list of approved verbs, type Get-Verb.

Name              : tmp_b11x0ew3.20l
Path              : C:\Users\admin.domain\AppData\Local\Temp\tmp_b11x0ew3.20l\tmp_b11x0ew3.20l.psm1
Description       : Implicit remoting for https://webmail.domain.com/powershell

Guid              : 3c49dbae-b2af-428e-9be4-94ffc63126a4
Version           : 1.0
ModuleBase        : C:\Users\admin.domain\AppData\Local\Temp\tmp_b11x0ew3.20l
ModuleType        : Script
PrivateData       : {ImplicitRemoting}
AccessMode        : ReadWrite
ExportedAliases   : {}
ExportedCmdlets   : {}
ExportedFunctions : {[Add-ADPermission, Add-ADPermission], [Add-AvailabilityAddressSpace,
                     Add-AvailabilityAddressSpace], [Add-ContentFilterPhrase, Add-ContentFilterPhrase],
                     [Add-DatabaseAvailabilityGroupServer, Add-DatabaseAvailabilityGroupServer]…}
ExportedVariables : {}
NestedModules     : {}

The powershell session to on premises Exchange was imported successfully.

This function imports the powershell session to Office 365….
WARNING: The names of some imported commands from the module ‘tmp_ti245wqn.qju’ include unapproved verbs that might
make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the
Verbose parameter. For a list of approved verbs, type Get-Verb.

Name              : tmp_ti245wqn.qju
Path              : C:\Users\admin.domain\AppData\Local\Temp\tmp_ti245wqn.qju\tmp_ti245wqn.qju.psm1
Description       : Implicit remoting for https://outlook.office365.com/powershell-liveID/

Guid              : 4c2cf1a7-0042-4595-9025-98728851b5ed
Version           : 1.0
ModuleBase        : C:\Users\admin.domain\AppData\Local\Temp\tmp_ti245wqn.qju
ModuleType        : Script
PrivateData       : {ImplicitRemoting}
AccessMode        : ReadWrite
ExportedAliases   : {}
ExportedCmdlets   : {}
ExportedFunctions : {[Add-o365AvailabilityAddressSpace, Add-o365AvailabilityAddressSpace],
                     [Add-o365DistributionGroupMember, Add-o365DistributionGroupMember],
                     [Add-o365MailboxFolderPermission, Add-o365MailboxFolderPermission], [Add-o365MailboxLocation,
                     Add-o365MailboxLocation]…}
ExportedVariables : {}
NestedModules     : {}