Administrators may enable security groups on premises as distribution groups. 

[PS] C:>Get-DistributionGroup BlogSecurityGroup

Name              DisplayName       GroupType                  PrimarySmtpAddress
—-              ———–       ———                  ——————
BlogSecurityGroup BlogSecurityGroup Universal, SecurityEnabled BlogSecurityGroup@domain.org

Azure Active Directory Connect will provision these groups and they will appear as mail enabled objects in Exchange Online.

PS C:> Get-DistributionGroup BlogSecurityGroup

Name              DisplayName       GroupType                  PrimarySmtpAddress
—-              ———–       ———                  ——————
BlogSecurityGroup BlogSecurityGroup Universal, SecurityEnabled BlogSecurityGroup@domain.org

There may be requirements to remove the mail enabled attributes of the group.  This is done on premises through disable-distributiongroup.

[PS] C:>Disable-DistributionGroup BlogSecurityGroup

Confirm
Are you sure you want to perform this action?
Disabling distribution group “BlogSecurityGroup” will remove the Exchange properties from the Windows group object.

When the distribution group has been disabled it still appears in Exchange Online as a mail enabled group.  In this instance with a proxy address that defaults to the default onmicrosoft.com domain.

PS C:> Get-DistributionGroup BlogSecurityGroup

Name              DisplayName       GroupType                  PrimarySmtpAddress
—-              ———–       ———                  ——————
BlogSecurityGroup BlogSecurityGroup Universal, SecurityEnabled BlogSecurityGroup@domain.onmicrosoft.com

If the group must be completely removed from Exchange Online – the associated MSOL object must be removed.

PS C:> Get-MsolGroup -SearchString BlogSecurityGroup

ObjectId                               DisplayName                GroupType                  Description
——–                               ———–                ———                  ———–
c2d0b7df-f0d5-4f0a-9470-edfa56e4910e   BlogSecurityGroup          MailEnabledSecurity

PS C:> Get-MsolGroup -SearchString BlogSecurityGroup | Remove-MsolGroup

Confirm
Continue with this operation?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is “Y”): y

Exchange Online will receive notification that the group has been removed and fully clean up the associated distribution group object.

PS C:> Get-DistributionGroup BlogSecurityGroup
The operation couldn’t be performed because object ‘BlogSecurityGroup’ couldn’t be found on
‘CO1PR06A002DC01.NAMPR06A002.prod.outlook.com’.
     + CategoryInfo          : NotSpecified: (:) [Get-DistributionGroup], ManagementObjectNotFoundException
     + FullyQualifiedErrorId : [Server=DM6PR06MB4026,RequestId=62703e0c-3437-49b9-9b84-be6253159d2e,TimeStamp=4/29/2018
     6:18:49 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] FC078746,Microsoft.Exchange.Management.RecipientTasks.GetDistributionGroup
     + PSComputerName        : ps.outlook.com

If the group still exists on premises Azure AD Connect will recreate it as a security enabled group during the next synchronization cycle.

In certain support circumstances it may become necessary to hard delete an Azure Active Directory account.  When the user has a mailbox that has been migrated to Exchange Online additional steps may be required to restore mailbox access.

It is important to note that hard deleting an account should not be a common place operation.  There can potentially be significant impacts to the other services that are linked to an account – for example Sharepoint Online site ownerships / permissions and One Drive for Business files. 

When a mailbox is migrated to Exchange Online the on premises mailbox GUID is preserved in Office 365.  If the original Azure Active Directory account is hard deleted – the Exchange Online mailbox will be set to an inactive status.  The Azure Active Directory account will be provisioned as a remote mailbox but continues to have the Exchange GUID of the mailbox on premises.  If a license is assigned to the new account – a mailbox is not provisioned due to the presence of the on premises Exchange GUID.  The assumption is that the mailbox needs to be migrated again.

Let’s take a look at an example.

In this example there is an on premises mailbox.  This can be validated with get-recipient and noting the recipientType is UserMailbox.

[PS] C:>Get-Recipient BlogTest

Name      RecipientType
—-      ————-
Blog Test UserMailbox

The ExchangeGUID is stamped on the mailbox when created on premises and is utilized to create the link between the Active Directory object and the mailbox object within the database.

[PS] C:>Get-Mailbox BlogTest | Select-Object exchangeGuid

ExchangeGuid
————
3155cca2-d022-4cbe-8f93-e3ecfc98894d

In Office 365 an on premises mailbox is represented as a mail user object.  This can be validated with get-recipient and noting the recipientType is MailUser.

PS C:> Get-Recipient BlogTest

Name      RecipientType
—-      ————-
Blog Test MailUser

The same exchangeGUID found on premises is stamped on the mail user object in Office 365.

PS C:> Get-Recipient BlogTest | Select-Object exchangeGUID

ExchangeGuid
————
3155cca2-d022-4cbe-8f93-e3ecfc98894d

When the mailbox is successfully migrated to Office 365 a conversion of the object on premises occurs to a remote mailbox type.

[PS] C:>Get-RemoteMailbox BlogTest

Name         RecipientTypeDetails                    RemoteRecipientType
—-         ——————–                    ——————-
Blog Test    RemoteUserMailbox                       Migrated

The recipient in Office 365 is now a user mailbox object.

PS C:> Get-Recipient BlogTest

Name      RecipientType
—-      ————-
Blog Test UserMailbox

The GUIDs continue to remain the same.

[PS] C:>Get-RemoteMailbox BlogTest | Select-Object exchangeGUID

ExchangeGuid
————
3155cca2-d022-4cbe-8f93-e3ecfc98894d

PS C:> Get-Mailbox BlogTest | Select-Object exchangeGUID

ExchangeGuid
————
3155cca2-d022-4cbe-8f93-e3ecfc98894d

This represents the standard account creation and migration process.

At this time through a support engagement it is determined that the associated Azure Active Directory account needs to be hard deleted.  This is accomplished through the remove-msolUser command.

PS C:> Remove-MsolUser -UserPrincipalName blogtest@domain.org

Confirm
Continue with this operation?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is “Y”): y

PS C:> Remove-MsolUser -UserPrincipalName blogtest@domain.org -RemoveFromRecycleBin

Confirm
Continue with this operation?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is “Y”): y

When the Azure Active Directory account is removed the associated Exchange Online mailbox is also removed.

PS C:> Get-Mailbox BlogTest
The operation couldn’t be performed because object ‘BlogTest’ couldn’t be found on
‘CO1PR06A002DC01.NAMPR06A002.prod.outlook.com’.
     + CategoryInfo          : NotSpecified: (:) [Get-Mailbox], ManagementObjectNotFoundException
     + FullyQualifiedErrorId : [Server=DM6PR06MB4026,RequestId=0bfe62ac-6691-43d8-99e6-5ae8358796b5,TimeStamp=4/29/2018
     3:37:40 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] CEDE4B18,Microsoft.Exchange.Management.RecipientTasks.GetMailbox
     + PSComputerName        : ps.outlook.com

When the next Azure Active Directory Connect cycle runs the same account will be provisioned as a new object in Azure Active Directory.

PS C:> Get-MsolUser -UserPrincipalName blogtest@domain.org

UserPrincipalName        DisplayName isLicensed
—————–        ———– ———-
blogtest@domain.org      Blog Test   False

The provisioning of the new account is detected by Exchange Online and a mail user object is provisioned.

PS C:> Get-Recipient BlogTest

Name     RecipientType
—-     ————-
BlogTest MailUser

In this instance the object is a remote mailbox / migrated user.  It would be expected that a mailbox object would appear in Exchange Online – but the object is a mail user. 

When reviewing the properties of the Azure Active Directory object validation errors exist and an error is noted on the account in the portal.

PS C:> Get-MsolUser -UserPrincipalName blogtest@domain.org | Select-Object validationStatus

ValidationStatus
—————-
            Error

Why does the validation error exist?  When a mailbox has been migrated to Office 365 the ExchangeGUID continues to remain on the object on premises.  This was visible in the previous commands we executed.  Although the recipient type is remote mailbox – the presence of an ExchangeGUID on premises prevents a mailbox from being provisioned.  The service assumes there is still a mailbox to be migrated.

If this is the case – how do we get the blank mailbox that we were looking for to provision?  The exchangeGUID can be removed on premises.  This can be accomplished by using ADSIEdit and locating the account to be modified.

At the next Azure Active Directory Connect synchronization cycle the exchangeGUID will be cleared from the object in Office 365.  When the object is completed synchronization the Exchange Online object remains a mail user but the exchangeGUID is now null.

PS C:> Get-Recipient BlogTest | fl recipientType,skuassigned,exchangeGUID

RecipientType : MailUser
SKUAssigned   :
ExchangeGuid  : 00000000-0000-0000-0000-000000000000

At this time a license can be assigned to the user.

PS C:> Get-MsolUser -UserPrincipalName blogtest@domain.org | Select-Object isLicensed,Licenses

IsLicensed Licenses
———- ——–
       True {Organization:STANDARDWOFFPACK}

When the license assignment successfully provisions to Exchange Online the mail user is converted to a user mailbox – a new mailbox has been provisioned.

PS C:> Get-Recipient BlogTest | fl recipientType,skuassigned,exchangeGUID

RecipientType : UserMailbox
SKUAssigned   : True
ExchangeGuid  : ec78d8ce-fee9-40e7-b8a6-d0628a22c527

The original mailbox can now be merged into the new mailbox to preserve any data delivered to the original mailbox.

In todays connected environments there are several applications that send email through designated internal relay servers.  The messages may originate from application servers that generate notifications, scans from multifunction printers, or other network connected devices.  An excellent target for internal relay servers are the hybrid servers implemented for Office 365 integration or any Exchange 2010 or newer server. 

In some installations a connector is created that allows for anonymous access.  This is definitely the case when the Exchange server receives email from the internet.

In many cases the internet or anonymous connector is what is utilized for internal relay applications.  This works for accepting and sending email within the environment – but there are several limitations.  Any email that is received through only the anonymous permission is considered not authenticated.  Here are some implications:

• Sender addresses are not resolved to email addresses in the global address list.
• Email to distribution lists requiring authentication will not be processed.
• Message limits of the on premises organization are applied to the messages relayed.

In this example telnet was utilized to submit a message through the anonymous connector.  The message header indicates the message was received as anonymous.

21
X-MS-Exchange-Organization-AuthAs
Anonymous

In order for internal applications to reliably deliver email it may be necessary to trust these messages.  The messages must come from an authenticated source.  To allow this to occur a receive connector can be created the implements the following:

• IP restrictions to the sending applications or devices.
• Authentication using “Externally Secured”.

Exchange by default will always utilize the most restrictive connector.  When the device connects and the IP address is within scope of the connector the externally secured permissions will be applied.  When the connector with externally secured is selected this results in the authentication settings for the email being set as INTERNAL.  

In this example telnet was utilized to submit a message through the externally secured connector.  The message header indicates the message was received as internal.

19
X-MS-Exchange-Organization-AuthAs
Internal

For more information on the connector security settings please review the following article –> https://technet.microsoft.com/en-us/library/mt668454(v=exchg.160).aspx

In Office 365 when licenses are assigned to a user a mailbox should not be provisioned if the user has a mailbox on premises.  Our provisioning logic looks to see if there is a replicated Exchange GUID to make a determination on the type of object that should be provisioned.  The one exception of this is if the account has a previousRecipientDisplayTypeDetails of UserMailbox.  In all cases if this recipient type is a UserMailbox a mailbox will be provisioned.  This can lead to duplicate mailboxes between Office 365 and on premises Exchange.

I detail some of these situations in the following blog posts:

https://blogs.technet.microsoft.com/timmcmic/2017/09/10/office-365-users-have-both-a-cloud-and-on-premises-mailbox/

https://blogs.technet.microsoft.com/timmcmic/2018/04/09/office-365-licensing-mail-users-results-in-mailbox-objects/

To being identifying users that might have the probability of having a duplicate mailbox created we must first pull all mail users that have a populated Exchange GUID.  If a mail user has an Exchange GUID – it should match the on premise mailbox. 

$mailUsers=Get-MailUser -ResultSize unlimited | where {$_.exchangeGUID -notlike “*00000*”}
$mailUsers

Name                                     RecipientType
—-                                     ————-
Journal Mailbox                          MailUser
TestCloud0                               MailUser
TestCloud1                               MailUser
TestCloud2                               MailUser
TestCloud3                               MailUser
TestCloud4                               MailUser

The second step is to trim the list down further to those mail users that have a previousRecipientDisplayTypeDetails of UserMailbox. 

$users=$mailUsers | % {get-user $_.alias | where {$_.PreviousRecipientTypeDetails -eq “UserMailbox”}}
$users

Name       RecipientType
—-       ————-
TestCloud0 MailUser
TestCloud1 MailUser
TestCloud2 MailUser
TestCloud3 MailUser
TestCloud4 MailUser

The array of users created above should reflect all mail users where the Exchange GUID is populated and the previous recipient type details are UserMailbox.

We now support resetting the users previousRecipientTypeDetails through the set-user command.  IMPORTANT NOTE:  When resetting these values if there is any data in the cloud mailbox that you wish to have recovered DO NOT proceed with these instructions.  Continuing to follow these instructions will result in the inability to recover data.  Using a loop we are able to move through the array of users and clear the previous recipient type details. 

To reset the previousRecipientTypeDetails…

$users | % {Set-User -Identity $_.samAccountName -PermanentlyClearPreviousMailboxInfo -Confirm:$FALSE -Verbose}

VERBOSE: Delete all existing information about user “TestC505571820778136”?. This operation will clear existing values
from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that
  existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to
continue?
VERBOSE: Delete all existing information about user “Test56390-1214024844”?. This operation will clear existing values
from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that
  existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to
continue?
VERBOSE: Delete all existing information about user “TestCl56390595684140”?. This operation will clear existing values
from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that
  existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to
continue?
VERBOSE: Delete all existing information about user “TestCl50043487409662”?. This operation will clear existing values
from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that
  existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to
continue?
VERBOSE: Delete all existing information about user “Test58465-1005051264”?. This operation will clear existing values
from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that
  existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to
continue?

Using powershell to validate that our changes were successful by restarting the discover process outlined above.

$mailUsers=Get-MailUser -ResultSize unlimited | where {$_.exchangeGUID -notlike “*00000*”}
$users=$mailUsers | % {get-user $_.alias | where {$_.PreviousRecipientTypeDetails -eq “UserMailbox”}}
$users
$users.count
0

With the users array count being zero there are no mail users left with a previous recipient display type of user mailbox.  With this value cleared – should a license be assigned to the user a mailbox will not be generated in Exchange Online.

In Office 365 I often encourage customers to control user forwarding through the user of remote domains.  You can find two of my blog posts on this topic here:

https://blogs.technet.microsoft.com/timmcmic/2015/06/08/exchange-and-office-365-mail-forwarding-2/

https://blogs.technet.microsoft.com/timmcmic/2015/04/19/office-365-determine-accounts-that-have-forwarding-enabled/

In a default installation a remote domain is defined in the service only for the * domain.

PS C:> Get-RemoteDomain

Name                           DomainName                                   AllowedOOFType
—-                           ———-                                   ————–
Default                        *                                            External

The auto forwarding property can be adjusted to FALSE which prevents autoforwarding from succeeding even if configured by the end user.

PS C:> Get-RemoteDomain | Select-Object AutoForwardEnabled

AutoForwardEnabled
——————
              False

I recently had a customer present with an issue where forwarding was not working.  In this particular instance forwarding was not working when a mailbox in the service created a rule or was using forwarding SMTP address to a user that was not yet migrated.  The recipients mailbox was located on premises in the same organization.  Let us take a look at an example…

In Office 365 I have changed the forwarding SMTP address to be a proxy address of an object that has not yet been migrated.  The forwarding smtp address property is treated in the same manner as an inbox rule setting a forwarding or redirect address.  (For a details explanation of the different forwarding methods see my previously mentions posts).

Set-Mailbox Contact -ForwardingSmtpAddress journal@contoso.com

 

When the forwarding address as been set all emails directed to this mailbox should also be redirected to the forwarding address.

To test the forwarding using an external mailbox outside the organization I addressed an email to the mailbox where forwarding was enabled.  Using message tracing I traced the message and noted that the status now shows as FAILED.

PS C:> Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com

Received            Sender Address         Recipient Address       Subject Status
——–            ————–         —————–       ——- ——
4/9/2018 2:41:08 PM timmcmic@microsoft.com journal@contoso.com     Test    Failed

Using get-messageTraceDetail we can review the full path of the message including any drops.

PS C:> $trace=Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com | Get-MessageTraceDetail
PS C:> $trace

Date                   Event                Detail
—-                   —–                ——
4/9/2018 2:41:11 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co…
4/9/2018 2:41:11 PM    Drop                 Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward address…
4/9/2018 2:41:11 PM    Drop                 Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward address…
4/9/2018 2:41:11 PM    Spam Diagnostics

In this instance we can see two drop events have occurred.  We can review the specific details of one of the drop events.

PS C:> $trace[1].detail
Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward addressed to external recipient};{MSG=};{FQDN=};{IP=};{LRT=}]

This is interesting – the message trace details seem to indicate that the message was dropped to an external recipient.  Why?

In this case the message is leaving the office 365 organization and therefore is considered external even though the message is destined to the on premises organization.  Due to transport seeing the forwarding recipient as external – and the remote domain * being the only domain defined and having auto forwarding disabled – the message is turfed.

How can we fix this?

We can fix this by defining a remote domain for the internal namespace.

PS C:> New-RemoteDomain -DomainName contoso.com -Name “Contoso Remote Domain”

Name                           DomainName                                   AllowedOOFType
—-                           ———-                                   ————–
Contoso Remote Domain          contoso.com                                  External

set-remoteDomain –identity “Contoso Remote Domain” –isInternal:$TRUE

PS C:> Get-RemoteDomain “Contoso Remote Domain” | fl autoForwardEnabled

AutoForwardEnabled : True

The entire process can be retested after allowing time for replication.  In this instance we will observe that the forwarded message is now delivered.

PS C:> Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com  | where{$_.status -like “Delivered”}

Received            Sender Address         Recipient Address       Subject Status
——–            ————–         —————–       ——- ——
4/9/2018 3:06:30 PM timmcmic@microsoft.com journal@contoso.com     Test    Delivered

PS C:> $trace=Get-MessageTrace -RecipientAddress journal@contoso.org -SenderAddress timmcmic@microsoft.com  | where{$_.status -like “Delivered”} | get-messageTraceDetail
PS C:> $trace

Date                   Event                Detail
—-                   —–                ——
4/9/2018 3:06:33 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co…
4/9/2018 3:06:33 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co…
4/9/2018 3:06:33 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co…
4/9/2018 3:06:34 PM    Send external        Message sent to mail.contoso.com at IPAddress using TLS1.2 w…
4/9/2018 3:06:33 PM    Spam Diagnostics

The new remote domain settings are being applied as expected.

In Office 365 we allow administrators to create mail user objects.  A mail user object is a security principal in the local active directory that also has an external email address assigned.  The user will appear in the global address list as a recipient and when selected the messages sent to the external email address assigned to the user.

 

In recent weeks I have worked with customers that have begun the process of implementing automated license assignment or implementing group based licensing.  In the process of doing so their mail user objects were included within the licensing scope applied.  When the Exchange Online license was applied – the mail user objects were converted to mailbox objects causing interruptions in mail flow.

 

Here is an example of a mail user created on premises.

 

[PS] C:>Get-MailUser TestAssigned

Name                                     RecipientType
—-                                     ————-
Test Assigned                            MailUser

 

When Azure AD Connect has replicated the object it will be represented in Exchange Online as a mail user object.

 

PS C:> Get-MailUser TestAssigned

Name                                     RecipientType
—-                                     ————-
Test Assigned                            MailUser

 

When the mail user account is initially provisioned the account is not licensed.

 

PS C:> Get-MsolUser -UserPrincipalName testassigned@domain.com

UserPrincipalName            DisplayName   isLicensed
—————–            ———–   ———-
TestAssigned@domain.com      Test Assigned False

 

Using the Office 365 Portal an Exchange Online license can be assigned to the mail user account.

 

PS C:> Get-MsolUser -UserPrincipalName testassigned@domain.com

UserPrincipalName            DisplayName   isLicensed
—————–            ———–   ———-
TestAssigned@domain.com      Test Assigned True

 

Post license assigned the object is converted to a mailbox object within Exchange Online.

 

PS C:> Get-Mailbox testassigned

Name                      Alias                ServerName       ProhibitSendQuota
—-                      —–                ———-       —————–
Test Assigned             TestAssigned         cy1pr0601mb1626  49.5 GB (53,150,220,288 bytes)

 

The external email address property of the mail user is not preserved – all email will now be delivered to the mailbox that was provisioned.

 

This is considered by design.  In Exchange Online the only objects that will not provision a mailbox when a license is assigned is an on premises mailbox.  This is denoted in Exchange Online by a user object that is replicated with an Exchange Guid.  (Note:  There is one exception to this – information can be found here:  https://blogs.technet.microsoft.com/timmcmic/2017/09/10/office-365-users-have-both-a-cloud-and-on-premises-mailbox/)

 

To correct the condition the license can be removed through the Office 365 Portal (or though any means that can remove the Exchange Online sku).

 

PS C:> Get-MsolUser -UserPrincipalName testassigned@domain.com

UserPrincipalName            DisplayName   isLicensed
—————–            ———–   ———-
TestAssigned@domain.com      Test Assigned False

 

This will result in the object converting back to a mail user object and the external email address being applicable again.

 

PS C:> Get-MailUser testassigned

Name                                     RecipientType
—-                                     ————-
Test Assigned                            MailUser

 

In order to preserve mail user functionality Exchange Plans should not be assigned when licenses are assigned to these recipient objects.