In Office 365 mailboxes are migrated to the service by configuring a migration batch.  When establishing the move configuration settings a “More Options” button was present.  The “More Options” button allowed administrators to configure the bad item limit and large item limit when the migration batch is created.

 

 

In current versions of the Office 365 / Exchange management tools the “More Options” button is missing.

 

 

The “More Options” button was removed as a part of the Office 365 / Exchange Management tools upgrade. 

 

If the bad item limit and large item limit must be adjusted, they must now be adjusted after the migration batch has been created.  These settings can only be adjusted on a migration batch that is not in progress. 

 

When creating new migration batches where these settings should be modified administrators should select the option “Manually start the batch later (by selecting it in the migration dashboard and then clicking Start)”.  This will stage the migration batch but not start it, allowing administrators to immediately adjust the bad item and large item limits.  The status of the migration batch will be “created”.

 

 

If the migration batch was created and has started it must be stopped.  This can be performed by selecting the migration batch and pressing the stop button (square button).  This will place the migration batch into a “stopped” state.

 

 

With the migration batch created or stopped the properties of the batch can be accessed by selecting the batch and pressing the edit button (pencil button).  On the properties of the batch, on the general tab, the bad item limit and large item limit are editable. 

 

 

After entering the appropriate values the save button can be utilized to commit the changes to the batch.  The batch can then be started or resumed by selecting the batch and pressing the resume button (play button). 

 

At this time we expect the “More Options” button to appear in the Office 365 / Exchange management tools in a future version. 

I recently worked with a customer that was utilizing directory synchronization to create distribution groups in their on-premises active directory and have them mail enabled within Office 365.  They noticed that when creating these distribution groups the display name in Office 365 was automatically changed and differed from the display name set on-premises.

 

Let’s take a look…

 

Using Active Directory Users and Computers a new distribution list is created.

 

 

Using the attribute editor the following attributes were manually set:

 

DisplayName:  TestDL

ProxyAddresses:  SMTP:TestDL@domain.com

Mail:  TestDL@Domain.com

 

After the distribution list was created directory synchronization was performed.  Monitoring directory synchronization we can validate the properties of the group synchronized into Office 365.

 

 

Using Powershell connected to Office 365 we can validate the properties of the MSOL Group.

 

PS C:Userstimmcmic> Get-MsolGroup -ObjectId df617972-c874-4d6d-ba73-993e73219514 | fl

ExtensionData    : System.Runtime.Serialization.ExtensionDataObject
CommonName       : TestDL
Description      :
DisplayName      : TestDL
EmailAddress     : TestDL@domain.com
Errors           : {}
GroupType        : DistributionList
IsSystem         : False
LastDirSyncTime  : 4/9/2014 2:56:34 PM
ManagedBy        :
ObjectId         : df617972-c874-4d6d-ba73-993e73219514
ProxyAddresses   : {smtp:TestDL@domain.onmicrosoft.com, SMTP:TestDL@domain.com}
ValidationStatus : Healthy

 

The attributes of the group within Office 365 and the on-premises Active Directory match after directory synchronization has completed.

 

When reviewing the properties of the same distribution list from Office 365 Exchange it is noted that the name has changed.  In this case a prefix was appended DL_:

 

PS C:Userstimmcmic> Get-DistributionGroup TestDL | fl NAME,DISPLAYNAME,EMAILADDRESSES

Name           : DL_TestDL
DisplayName    : DL_TestDL
EmailAddresses : {SMTP:TestDL@domain.com, smtp:TestDL@domain.onmicrosoft.com}

Where did the DL_ come from?  Exchange and Office 365 allow administrators to define a distribution group naming policy.  The distribution group naming policy is set in the organization’s configuration.  More information on distribution group naming policies can be found here:  https://aka.ms/Bry5y2

 

In this instance the tenant had a distribution group naming policy that utilized DL_<GroupName>:

 

PS C:Userstimmcmic> Get-OrganizationConfig | fl distributiongroupnamingpolicy

DistributionGroupNamingPolicy : DL_<GroupName>

 

When a distribution group naming policy is utilized after directory synchronization has successfully synchronized the group and the new group is provisioned within Exchange Office 365 the naming policy will be applied.  The MSOL object will continue to reflect the attributes as synchronized from the on-premises Active Directory but the Exchange object will reflect the attributes modified by the naming policy.

 

In our case it was desired that the naming policy would not be applied.  This required removing the naming policy from the organizational configuration:

 

PS C:Userstimmcmic> Set-OrganizationConfig -DistributionGroupNamingPolicy:$NULL

 

By removing the naming policy the Exchange Office 365 groups will now reflect the attributes as synchronized from the on-premises Active Directory.

Recently I was re-reading a blog post from 2012 about on Tuning Failover Cluster Network Thresholds that was posted by Elden Christensen, a Principal PM on the Windows Failover Cluster team. I think Elden’s post is a must-read for anyone planning a highly-available Exchange deployment.  One of the reasons I find this post an excellent read is that it addresses many things administrators need to understand when they decide to tune cluster heartbeat subnet delays and thresholds in Exchange environments.

 

The post first makes an excellent point in addressing that the changes to these thresholds alter the amount of time it takes to detect that a node is down.  Elden uses a great metaphor here:

 

“Think of it like your cell phone, when the other end goes silent how long are you willing to sit there going “Hello?… Hello?… Hello?” before you hang-up the phone and call the person back.  When the other end goes silent, you don’t know when or even if they will come back.”

As subnet thresholds are adjusted up, this increases the amount of time it takes to detect a failure. The higher the values, the longer it takes to detect a failure, and therefore the longer it takes to act on that failure. There is a balance between reacting quickly to a failure and providing resiliency to transient networking issues.

 

The other point that I think is worth understanding is the number of times these values are adjusted in the absence of an analysis or correction of underlying networking issues.  Elden sums this up, too, and I could not agree with him more:

 

“It critical to recognize that cranking up the thresholds to high values does not fix nor resolve the transient network issue, it simply masks the problem by making health monitoring less sensitive. The #1 mistake made broadly by customers is the perception of not triggering cluster health detection means the issue is resolved (which is not true!). I like to think of it, that just because you choose not to go to the doctor it does not mean you are healthy. In other words, the lack of someone telling you that you have a problem does not mean the problem went away.”

I often find myself in conversations with customers who have changed these values and have the perception that something is “fixed.” There are legitimate cases where these values need to be changed – but I always encourage a networking analysis enables you to understand what issues you are facing and how adjusting these values would help. Unfortunately, it seems that adjusting these thresholds without this understanding is far more common than it should be.

 

I strongly encourage all Exchange administrators to read Elden’s post.