Author Archives: TIMMCMIC

Office 365: Correcting users who have had a mailbox in the cloud and on-premises…

In some previous blog posts I have outlined conditions where users may have inadvertently had a mailbox both on premises and in the cloud at the same time.  The following links outline these scenarios and how to attempt to proactively identity users that may fall in this condition.

https://blogs.technet.microsoft.com/timmcmic/2018/04/10/office-365-detecting-and-preventing-duplicate-mailboxes-between-on-premises-and-exchange-online/

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/

With an understanding of the scenarios that lead to this and how to proactively identity users administrators can quickly identify the conditions that lead to this occurring and work to prevent it for other accounts moving forward.  How do we handle an account though that has encountered this condition?

There are two methods to handle accounts that have had mailboxes both on premises and in the cloud.  I will outline the options below for administrators to consider – as each has benefits and drawbacks.

OPTION #0:  Delete the existing Azure Active Directory Account

The Exchange Online mailbox object is linked to an Azure Active Directory account.  When the azure active directory account is removed and subsequently purged from the recycle bin the Exchange Online mailbox is placed in a soft deleted state.  During the next Azure Active Directory Connect synchronization cycle the user will be resynchronized to Azure Active Directory as new and will carry forward the Exchange attribute from on premises.  This should result in a mail user created in Exchange Online and not a mailbox object.  The mailbox object can now be migrated from on premises and the associated soft deleted mailbox merged into the original to retain data.

There are several benefits to this approach:

  • Deleting and purging an account from Azure Active Directory is generally a simple process.
  • The mailbox can be immediately migrated from on-premises once the mail user object is provisioned.
  • Exchange Online supports the administrator merging mailbox contents.  The soft deleted mailbox belonging to the user can be merged into the migrated mailbox allowing for no messages to be lost.

There are several potential drawbacks to this approach:

  • This is a complete Azure Active Directory account reset.
  • All permissions granted to this account within the service – for example Sharepoint site ownership / OneDrive / and any other services will be lost.
  • Any membership in cloud only distribution lists – for example Office 365 groups – will be lost.
  • There may be a brief interruption in mail flow to this account while the deletion and recreation of the Exchange Online object occurs.

In Exchange Online we can verify the presence of a mailbox that matches an on premises account.

Exchange Online:

PS C:> Get-Mailbox testduplicate


Name                      Alias           Database                       ProhibitSendQuota    ExternalDirectoryObjectId
—-                      —–           ——–                       —————–    ————————-
testduplicate             testduplicate   NAMPR06DG282-db128             49.5 GB (53,150,2… e3eaf6c1-f012-42e9-a54…

On-Premises Exchange:

[PS] C:>Get-Mailbox testduplicate


Name                      Alias                ServerName       ProhibitSendQuota
—-                      —–                ———-       —————–
Test Duplicate            testduplicate        azure-mbx        Unlimited

In the portal we can verify that the account is synchronized from the on-premises active directory.

image

The synchronized user has now been verified to have both a mailbox in the cloud and on-premises.

To begin the recovery the administrator should capture the Exchange Online mailbox information – specifically the Exchange GUID of the mailbox.  This GUID will be utilized in the recovery of the soft deleted mailbox.

PS C:> Get-Mailbox testduplicate | select-object ExchangeGUID


ExchangeGuid
————
fa38094d-cbfd-46b7-82f6-8a3022e39a66

Using Azure Active Directory powershell the account can be removed and purged from the recycle bin.

PS C:> Remove-MsolUser -UserPrincipalName testduplicate@domain.com -Force
PS C:> Remove-MsolUser -UserPrincipalName testduplicate@domain.com -Force –RemoveFromRecycleBin

The deletion can be verified using powershell.  The user cannot be found in either the active users list or the recycle bin – this indicates a successful deletion.

PS C:> Get-MsolUser -UserPrincipalName testduplicate@domain.com
Get-MsolUser : User Not Found.  User: testduplicate@domain.com.
At line:1 char:1
+ Get-MsolUser -UserPrincipalName testduplicate@domain.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
     + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser


PS C:> Get-MsolUser -UserPrincipalName testduplicate@domain.com -ReturnDeletedUsers
Get-MsolUser : User Not Found.  User:
testduplicate@domain.com.
At line:1 char:1
+ Get-MsolUser -UserPrincipalName testduplicate@domain.com -Return …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
     + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser

In Exchange Online we can confirm that the mailbox object is no longer present.

PS C:> Get-Mailbox testduplicate
The operation couldn’t be performed because object ‘testduplicate’ couldn’t be found on
‘CO1PR06A002DC02.NAMPR06A002.prod.outlook.com’.
     + CategoryInfo          : NotSpecified: (:) [Get-Mailbox], ManagementObjectNotFoundException
     + FullyQualifiedErrorId : [Server=DM6PR06MB4026,RequestId=76d78567-e257-4608-a175-2dc3cd8658c2,TimeStamp=7/15/2018
     3:51:45 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 260B3828,Microsoft.Exchange.Management.Rec
   ipientTasks.GetMailbox
     + PSComputerName        : ps.outlook.com

The duplicate online mailbox should now be in a soft deleted state.

PS C:> Get-Mailbox testduplicate -SoftDeletedMailbox


Name                      Alias           Database                       ProhibitSendQuota    ExternalDirectoryObjectId
—-                      —–           ——–                       —————–    ————————-
Test Duplicate            testduplicate   NAMPR06DG282-db128             49.5 GB (53,150,2…

At this time the online portion of the accounts have been cleaned up.  Azure Active Directory Connect synchronization can be performed and the object should be reprovisioned from the on-premises directory.

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


UserPrincipalName             DisplayName    isLicensed
—————–             ———–    ———-
testduplicate@domain.com      Test Duplicate False

The object should now be successfully provisioned as a mail user within Exchange Online.  This is the expected recipient type for an on premises mailbox.

PS C:> Get-MailUser testduplicate


Name                                     RecipientType
—-                                     ————-
Test Duplicate                           MailUser

At this time the on-premises mailbox can be migrated to Office 365.  This is an optional step – but would be required in order to perform the merge of any data contained within the service at this time.

image

When the migration has completed successfully the object will become a mailbox object within Exchange Online.

PS C:> Get-Mailbox testduplicate


Name                      Alias           Database                       ProhibitSendQuota    ExternalDirectoryObjectId
—-                      —–           ——–                       —————–    ————————-
Test Duplicate            testduplicate   NAMPR06DG143-db051             99 GB (106,300,44… 7ba2fffc-e3ce-4d65-b350-d0a3763e5ffa

To complete our recovery the mailbox restoration can be processed.  To begin we need the Exchange GUID of the migrated mailbox.

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


ExchangeGuid
————
e683f1ee-4c85-4b99-b4bc-7511572a361d

The Exchange GUID for the soft deleted mailbox was previously recorded.  Using this information we can begin the merge process.

New-MailboxRestoreRequest -SourceMailbox fa38094d-cbfd-46b7-82f6-8a3022e39a66 -TargetMailbox e683f1ee-4c85-4b99-b4bc-7511572a361d –AllowLegacyDNMismatch

Name           TargetMailbox Status
—-           ————- ——
MailboxRestore testduplicate Queued

The merge can be monitored with get-mailboxRestoreRequest. 

PS C:Userstimmcmic> Get-MailboxRestoreRequest


Name           TargetMailbox Status
—-           ————- ——
MailboxRestore testduplicate InProgress

PS C:Userstimmcmic> Get-MailboxRestoreRequest

Name           TargetMailbox Status
—-           ————- ——
MailboxRestore testduplicate Completed

At this time this option has completed.

OPTION #1:  Remove the Exchange Online License

The Exchange Online mailbox object is linked to an Azure Active Directory account.  When the Exchange Online license is removed from the object the associated mailbox will be made unavailable.  This should result in a mail user created in Exchange Online and not a mailbox object.  The mailbox object can now be migrated from on premises and the associated soft deleted mailbox merged into the original to retain data.

There are several benefits to this approach:

  • The existing Azure Active Directory account is preserved.
  • All permissions assigned to the object are preserved across Sharepoint and OneDrive etc.  (This assumes ONLY the Exchange Online license is removed…)

There are several potential drawbacks to this approach:

  • The Exchange Online mailbox is not recoverable.  Any data contained will be lost.
  • There may be a brief interruption in mail flow to this account while the deletion and recreation of the Exchange Online object occurs.

To begin the mailbox can be confirmed in Exchange Online and On-Premises.

Exchange Online:

PS C:> Get-Mailbox testlicense


Name                      Alias           Database                       ProhibitSendQuota    ExternalDirectoryObjectId
—-                      —–           ——–                       —————–    ————————-
TestLicense               TestLicense     NAMPR06DG103-db019             49.5 GB (53,150,2… c686dfd9-aa4a-4b54-8680-cc0d4c9b0a62

On-Premise Exchange:

[PS] C:>Get-Mailbox testlicense


Name                      Alias                ServerName       ProhibitSendQuota
—-                      —–                ———-       —————–
Test License              testlicense          azure-mbx        Unlimited

In the portal we can confirm that the account is synchronized from the on-premises Active Directory.

image

The synchronized user has now been verified to have both a mailbox in the cloud and on-premises.

The Exchange Online license can now be removed through the portal.

image

When the license removal has synchronized into Exchange Online the mailbox will be converted to a mail user.

PS C:> Get-MailUser testLicense


Name                                     RecipientType
—-                                     ————-
Test License                             MailUser

When the conversion to a mail user has occurred the mailbox can be migrated from on premises.  If the license is re-assigned the object will convert back to a mailbox.  Assigning an Exchange Online license should be withheld until the mailbox is migrated (or the previous recipient type is changed – reference the previously attached blogs) allowing it to be safe to apply a license.

OPTION #3:  The user has no license but has an error with correlation ID in Azure Active Directory

I recently worked with a customer where we were looking at pursuing Option #2 as documented in this article.  With Option #2 our plan was to remove licenses, migrate the mailboxes, and forgo any ability to recover data that might be contained within the Office 365 mailbox. 

When reviewing the properties of the user in the Office 365 Portal (Azure Active Directory) the user had no Exchange license currently assigned.  When reviewing the object within Exchange Online the mailbox object existed as a User Mailbox type.

PS C:> Get-Mailbox testlicense

Name                      Alias           Database                       ProhibitSendQuota    ExternalDirectoryObjectId
—-                      —–           ——–                       —————–    ————————-
TestLicense               TestLicense     NAMPR06DG103-db019             49.5 GB (53,150,2… c686dfd9-aa4a-4b54-8680-cc0d4c9b0a62


One issue that we noted in the properties of the user account within the Office 365 portal was an error condition and a correlation ID.

image

In addition executing get-msolUser –userPrincipalName testLicense@domain.com shows the errors field populated and validation status error.

Errors                                 : {Microsoft.Online.Administration.ValidationError, Microsoft.Online.Administration.ValidationError}

ValidationStatus                       : Error


The presence of a correlation ID and error indicates that there are synchronization and object validation issues between Exchange Online and Azure Active Directory.  Due to the fact that there are multiple reasons this could occur – especially for accounts that are in this state – my recommendation is we fail back to Option #1 for the recovery of these types of accounts.

Office 365: Exchange Migrations and the data migrated information…

In Office 365 migration batches are the preferred method of establishing mailbox migrations to Office 365.  When a migration batch is established the users included in the batch are represented as migration users within the service. 

Within the context of each migration user is where we track the migration process.  One of the data points contained within the migration process is the DATA MIGRATED tab.  When enumerating the users within a migration batch, and selecting a migration user, this information is visible within the portal.

USER@domain.com

Status: Synced

USER@domain.com Skipped item details

Data migrated: 1.4 GB ‎(1,503,707,494 bytes)‎
Migration rate: 0 B ‎(0 bytes)‎
Error:
Report: USER@domain.com Download the report for this user

Last successful sync date: 7/2/2018 6:12:47 PM

Status:

Queued duration: 00:00:09.5015268
In-progress duration: 6.04:36:17.0329441
Synced duration: 36.10:02:28.6166962
Stalled duration: 02:12:43.4040899

One of the common questions and comments that I receive is that the DATA MIGRATED field may often reflect sizes that are slightly more to drastically more than the mailbox being migrated.  This on occasion leads to confusion about the migration process and the data that was migrated.  Here’s an example.

I recently migrated a mailbox from an on premises Exchange 2010 installation.  With Exchange 2010 being the source we can already expect that the data migrated to the service to be more than the reported mailbox size due to the inconsistencies in the methods Exchange 2010 reports mailbox sizes.  At the time that the mailbox migration completed the following was reported within the migration portal.

user@domain.com

Status: Completed

user@domain.com Skipped item details

Data migrated: 2.485 GB ‎(2,668,722,884 bytes)‎
Migration rate: 0 B ‎(0 bytes)‎
Error:
Report: user@domain.com
Download the report for this user

Last successful sync date: 7/3/2018 3:14:56 PM

Status:

Queued duration: 00:00:08.5213717
In-progress duration: 01:01:30.1987283
Synced duration: 00:00:00
Stalled duration: 01:21:09.3851867

In this example the data migrated field shows 2.485 GB migrated.  If we review the migration statistics associated with the mailbox we can get an idea of the reported mailbox size to be migrated. 

PS C:> Get-MigrationUserStatistics user@domain.com -IncludeReport | Export-Clixml -Path c:tempmigration.xml


PS C:> $stats=Import-Clixml -Path C:tempmigration.xml


PS C:> $stats.EstimatedTotalTransferSize

1.501 GB (1,612,092,317 bytes)

In this particular instance the estimated mailbox transfer size was 1.5 GB.  If we look at the data migrated verses the estimated data transfer size the difference is almost 1 GB difference.  Even accounting for reporting inconsistencies from Exchange 2010 mailbox size estimates 1 GB is a significant difference.  Why has this happened?

The data migrated field is a summary counter of all data transmissions between Office 365 and the on premises Exchange environment.  It is NOT a reflection of the data migrated verses the estimated mailbox size.  In this particular instance the mailbox move process was interrupted several times.  The interruptions may be the result of throttling, connection problems, or other migration interruptions. 

7/3/2018 2:22:35 PM [CO2PR07MB2711] The job has been paused temporarily due to unfavorable server health, with request throttling state: ‘StalledDueToTarget_DiskLatency’. It will automatically resume after ‘7/3/2018 2:23:35 PM’.
7/3/2018 2:28:38 PM [CO2PR07MB2711] The Microsoft Exchange Mailbox Replication service ‘CO2PR07MB2711.namprd07.prod.outlook.com’ (15.20.930.16 ServerCaps:FFFFFF, ProxyCaps:0FFFC7FD6DFDBF5FFFFFCB07FFFF, MailboxCaps:, legacyCaps:FFFFFF) is examining the request.
7/3/2018 2:28:38 PM [CO2PR07MB2711] Content from the Shard mailbox (Mailbox Guid: 6021ac05-d3f5-4bf4-ad03-f749aa02a1e4, Database: 545e461d-55da-4037-9c3e-d57a539e5e43) will be merged into the target mailbox.
7/3/2018 2:28:38 PM [CO2PR07MB2711] Connected to target mailbox ‘live.domain.comf28fad8a-546d-4965-8bcd-94806d53967d (Primary)’, database ‘NAMPR07DG170-db053’, Mailbox server ‘CO2PR07MB2711.namprd07.prod.outlook.com’ Version 15.20 (Build 930.0).
7/3/2018 2:28:45 PM [CO2PR07MB2711] Connected to source mailbox ‘live.domain.comf28fad8a-546d-4965-8bcd-94806d53967d (Primary)’, database ‘DAG-Administration’, Mailbox server ‘MICHAEL.domain.com’ Version 14.3 (Build 382.0), proxy server ‘PROXY.domain.com’ 15.1.1531.3 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:0FFD6FFFBF5FFFFFCB07FFFF.

7/3/2018 2:28:47 PM [CO2PR07MB2711] Request processing continued, stage LoadingMessages.

7/3/2018 2:28:47 PM [CO2PR07MB2711] Stage: LoadingMessages. Percent complete: 20.
7/3/2018 2:41:04 PM [CO2PR07MB2711] Stage: CopyingMessages. Percent complete: 85.
7/3/2018 2:41:04 PM [CO2PR07MB2711] Copy progress: 17097/21426 messages, 1.299 GB (1,394,743,256 bytes)/1.501 GB (1,611,958,891 bytes), 30/67 folders completed.

7/3/2018 2:41:04 PM [CO2PR07MB2711] The job has been paused temporarily due to unfavorable server health, with request throttling state: ‘StalledDueToTarget_DiskLatency’. It will automatically resume after ‘7/3/2018 2:42:04 PM’.

7/3/2018 2:49:49 PM [CO2PR07MB2711] The Microsoft Exchange Mailbox Replication service ‘CO2PR07MB2711.namprd07.prod.outlook.com’ (15.20.930.16 ServerCaps:FFFFFF, ProxyCaps:0FFFC7FD6DFDBF5FFFFFCB07FFFF, MailboxCaps:, legacyCaps:FFFFFF) is examining the request.
7/3/2018 2:49:55 PM [CO2PR07MB2711] Content from the Shard mailbox (Mailbox Guid: 6021ac05-d3f5-4bf4-ad03-f749aa02a1e4, Database: 545e461d-55da-4037-9c3e-d57a539e5e43) will be merged into the target mailbox.
7/3/2018 2:49:55 PM [CO2PR07MB2711] Connected to target mailbox ‘live.domain.comf28fad8a-546d-4965-8bcd-94806d53967d (Primary)’, database ‘NAMPR07DG170-db053’, Mailbox server ‘CO2PR07MB2711.namprd07.prod.outlook.com’ Version 15.20 (Build 930.0).
7/3/2018 2:50:02 PM [CO2PR07MB2711] Connected to source mailbox ‘live.domain.comf28fad8a-546d-4965-8bcd-94806d53967d (Primary)’, database ‘DAG-Administration’, Mailbox server ‘MICHAEL.domain.com’ Version 14.3 (Build 382.0), proxy server ‘PROXY.domain.com’ 15.1.1531.3 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:0FFD6FFFBF5FFFFFCB07FFFF.

7/3/2018 2:50:04 PM [CO2PR07MB2711] Request processing continued, stage LoadingMessages.

7/3/2018 2:50:04 PM [CO2PR07MB2711] Stage: LoadingMessages. Percent complete: 20.
7/3/2018 3:00:05 PM [CO2PR07MB2711] Stage: CopyingMessages. Percent complete: 89.

In this example the move request was stalled several times.  Each time after the stall the migration request is picked back up – and message loading occurs.  This would be an example of additional data added to the transfer set that was not mailbox level items that would have been accounted for in the mailbox size. 

If I was curious about the status of the migration and understanding the full migration status – how can I ensure the data was moved.  When a move enters the finalization phase the source mailbox and target mailbox are locked.  We have a mailbox folder verification process that is executed.  The mailbox folder verification process iterates through each folder in the source mailbox and compares it to the target mailbox.  Item counts and sizes are compared in real time.  If there are any discrepancies identified the move will be placed into a failed state.  The mailbox verification is logged into the migration log file and can be viewed by the administrator.

PS C:> Get-MigrationUserStatistics user@domain.com -IncludeReport | Export-Clixml -Path c:tempmigration.xml


PS C:> $stats=Import-Clixml -Path C:tempmigration.xml


PS C:> $stats.Report.MailboxVerification

Source                                         : 10188 [1.152 GB (1,237,342,091 bytes)]
SourceFAI                                      : 27 [1.203 MB (1,261,537 bytes)]
Target                                         : 10188 [1.464 GB (1,571,440,111 bytes)]
TargetFAI                                      : 27 [1.227 MB (1,286,579 bytes)]
Corrupt                                        : 0 [0 B (0 bytes)]
Large                                          : 0 [0 B (0 bytes)]
Skipped                                        : 0 [0 B (0 bytes)]
FolderSourcePath                               : /Top of Information Store/Inbox
FolderTargetPath                               : /Top of Information Store/Inbox
FolderSourceID                                 : {0, 0, 0, 0…}
FolderTargetID                                 : {0, 0, 0, 0…}
ParentSourceID                                 : {0, 0, 0, 0…}
ParentTargetID                                 : {0, 0, 0, 0…}
WKFType                                        : Inbox
WKFTypeInt                                     : 10
FolderIsMissing                                : False
FolderIsMisplaced                              : False
MismatchedFlagsCount                           : 0
MissingItemsInTargetBucket                     : 0 [0 B (0 bytes)]
MismatchedFlagsSample                          : {}
DuplicatedItemsInTargetBucket                  : 0 [0 B (0 bytes)]
MissingInSourceExtraItemsInTargetBucket        : 0 [0 B (0 bytes)]
MismatchedSyncFolderIdExtraItemsInTargetBucket : 0 [0 B (0 bytes)]
NonMRSSyncedExtraItemsInTargetBucket           : 0 [0 B (0 bytes)]
FolderExclusionExtraItemsInTargetBucket        : 0 [0 B (0 bytes)]
MailboxGuid                                    : f28fad8a-546d-4965-8bcd-94806d53967d
UnknownElements                                :
UnknownAttributes                              :
XmlSchemaType                                  :



Source                                         : 5129 [247.9 MB (259,986,587 bytes)]
SourceFAI                                      : 3 [5.91 KB (6,052 bytes)]
Target                                         : 5129 [500 MB (524,288,275 bytes)]
TargetFAI                                      : 3 [8.085 KB (8,279 bytes)]
Corrupt                                        : 0 [0 B (0 bytes)]
Large                                          : 0 [0 B (0 bytes)]
Skipped                                        : 0 [0 B (0 bytes)]
FolderSourcePath                               : /Top of Information Store/Deleted Items
FolderTargetPath                               : /Top of Information Store/Deleted Items
FolderSourceID                                 : {0, 0, 0, 0…}
FolderTargetID                                 : {0, 0, 0, 0…}
ParentSourceID                                 : {0, 0, 0, 0…}
ParentTargetID                                 : {0, 0, 0, 0…}
WKFType                                        : DeletedItems
WKFTypeInt                                     : 14
FolderIsMissing                                : False
FolderIsMisplaced                              : False
MismatchedFlagsCount                           : 0
MissingItemsInTargetBucket                     : 0 [0 B (0 bytes)]
MismatchedFlagsSample                          : {}
DuplicatedItemsInTargetBucket                  : 0 [0 B (0 bytes)]
MissingInSourceExtraItemsInTargetBucket        : 0 [0 B (0 bytes)]
MismatchedSyncFolderIdExtraItemsInTargetBucket : 0 [0 B (0 bytes)]
NonMRSSyncedExtraItemsInTargetBucket           : 0 [0 B (0 bytes)]
FolderExclusionExtraItemsInTargetBucket        : 0 [0 B (0 bytes)]
MailboxGuid                                    : f28fad8a-546d-4965-8bcd-94806d53967d
UnknownElements                                :
UnknownAttributes                              :
XmlSchemaType                                  :

In summary – the DATA MIGRATED field cannot be used as a measure of migration success or failure.  Only in cases where the move is started and almost immediately finalized with no errors, stalls, or interruptions will the value be near or close to the mailbox size being migrated.

Office 365: The mystery of mobile phone…

In the last few weeks I have worked several escalations from customers inquiring about inconsistencies with the mobile phone attribute.  In almost all cases inconsistencies were noticed in the Exchange Online contact card where mobile phone listed did not match on premises.

When directory synchronization is enabled on an Office 365 tenant a set of attributes are locked with a source of authority flag establishing on premises as the SOA.  The implications here are that changes to these attributes should only be accepted through the Azure Active Directory Synchronization software.  Administrators and end users can see this behavior when attempting to change – for example – first name.

PS C:> Set-MsolUser -UserPrincipalName tim.mcmichael@domain.com -FirstName Test
Set-MsolUser : Unable to update parameter. Parameter name: FIRSTNAME.
At line:1 char:1
+ Set-MsolUser -UserPrincipalName tim.mcmichael@domain.com -FirstName  …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : OperationStopped: (:) [Set-MsolUser], MicrosoftOnlineException
     + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,Microsoft.Online.Administration.Automation.SetUser

As with other attributes mobile phone is initially setup with the expectation that it will be provided through the Azure Active Directory Synchronization software.  Let us review a sample user:

The remote mailbox object is provisioned on-premises and a mobile number set.

[PS] C:>Get-User testmobile | fl *mobile*



MobilePhone : 8035551212

The recipient is successfully replicated to Azure Active Directory and the mobile number from on premises is retained.

PS C:> Get-MsolUser -UserPrincipalName testmobile@fortmillems.org | fl *mobile*



AlternateMobilePhones : {}

MobilePhone           : 8035551212

At anytime the mobile number may change on premises to a different value.

[PS] C:>Set-User testmobile -MobilePhone 9991112222
[PS] C:>Get-User testmobile | fl *mobile*



MobilePhone : 9991112222

The recipient is again successfully replicated to Azure Active Directory and the mobile number from on premises is again retained.

PS C:> Get-MsolUser -UserPrincipalName testmobile@domain.com | fl *mobile*



AlternateMobilePhones : {}

MobilePhone           : 9991112222

In Office 365 there are several self service options for attributes.  For example users can enroll themselves in Multi-Factor Authentication or potentially manage some of their personal attributes.  One of these attribute is mobile phone.  This allows the end user to set their own mobile phone number.  In addition administrators have access to user attribute both via the portal and powershell where mobile phone can also be adjusted. 

PS C:> Get-MsolUser -UserPrincipalName testmobile@domain.com | fl *mobile*



AlternateMobilePhones : {}

MobilePhone           : 1234567890

So wait – mobile phone was previously accepted from on premises when directory synchronization was enabled but is now also taking updates from Azure Active Directory directly?  That’s correct – mobile phone is a unique attribute.  When directory synchronization is enabled mobile phone will continue to be populated from on premises through the sync process.  Although this occurs – the mobile phone can be updated through any number of cloud interfaces.   What happens now if the mobile number changes on premises.

[PS] C:>Set-User testmobile -MobilePhone 0987654321
[PS] C:>Get-User testmobile | fl *mobile*



MobilePhone : 0987654321

Synchronization is now allowed to complete and reviewing the attributes of mobile number in Azure Active Directory we note the attribute HAS NOT updated.

PS C:> Get-MsolUser -UserPrincipalName testmobile@domain.com | fl *mobile*



AlternateMobilePhones : {}

MobilePhone           : 1234567890

This is by design.  When the mobile phone number was adjusted in Azure Active Directory the source of authority was changed from on premises to Azure Active Directory.  When Azure Active Directory Sync pushes any changes of the mobile attribute from on premises to Office 365 – Azure Active Directory ignores the change. 

So what about Exchange Online – what will display in the users contact card.  Exchange Online takes all of the information as provided by Azure Active Directory.  Regardless where the source of authority lies – the value stamped on the object in Azure Active Directory will be the value of the attribute on the mail enabled object in Exchange Online and what will subsequently appear in the global address list.  Here is a sample get-user from Exchange Online:

PS C:> Get-User testMobile | fl *mobile*



MobilePhone : 1234567890

If you have mobile phone attributes that you need populated from on premises to Office 365 and are encountering this issue a support case can be utilized to discuss options with product support services.

Office 365: Unable to locate an Azure Active Directory user for an Exchange Online Mailbox

In order for an Exchange Online mailbox to exist in Office 365 it must be attached to an Azure Active Directory object.  In Exchange Online we record the object ID for the Azure Active Directory account as the external directory object id of the mailbox.

PS C:> Get-Mailbox tmcmichael | fl name,externalDirectoryObjectID



Name                      : Timothy McMichael
ExternalDirectoryObjectId : 61425db0-7812-49dd-b6aa-1a732bdec569

Using the external directory object ID we can locate the Azure Active Directory account that the mailbox is linked to.

PS C:> Get-MsolUser -ObjectId 61425db0-7812-49dd-b6aa-1a732bdec569


UserPrincipalName          DisplayName       isLicensed
—————–          ———–       ———-
tmcmichael@domain.org      Timothy McMichael True

I recently had a customer that presented with the inability to locate the Azure Active Directory Object for an associated mailbox. 

Using get-mailbox the mailbox object was successfully located:

PS C:> Get-Mailbox contact | fl name,externalDirectoryObjectID



Name                      : Contact Mailbox
ExternalDirectoryObjectId : 3959607e-8c53-4413-9d39-1af548b00819

When using get-msolUser the Azure Active Directory account could not be successfully located.

PS C:> Get-MsolUser -ObjectId 3959607e-8c53-4413-9d39-1af548b00819
Get-MsolUser : User Not Found.  User: 3959607e-8c53-4413-9d39-1af548b00819.
At line:1 char:1
+ Get-MsolUser -ObjectId 3959607e-8c53-4413-9d39-1af548b00818
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
     + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser

If the mailbox object was a valid object – why can an Azure Active Directory account not be located.

In this particular instance we discovered that the mailbox was set as the JournalingReportNDRTo.

PS C:> Get-TransportConfig | fl JournalingReportNdrTo



JournalingReportNdrTo : contact@domain.com

When a mailbox is specified as the journalingReportNDRTo recipient the mailbox cannot be deprovisioned.  In this particular instance we suspect that the Azure Active Directory Account was removed and subsequently purged.  When the object is purged from Azure Active Directory the associated Exchange Online Mailbox should enter a soft deleted state.  In this instance the mailbox was not soft deleted because of an external dependency.

Office 365: Mail disable an on premises security group…

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.

Office 365: Resetting a migrated users Azure Active Directory account….

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

image

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.

image

image

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.

Office 365: Trusting application emails sent through internal relay…

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.

image

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”.

image

image

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

Office 365: Detecting and preventing duplicate mailboxes between On-Premises and Exchange Online

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.

Office 365: Internal forwarding and remote domains…

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.

Office 365: Licensing mail users results in mailbox objects.

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.