EN 
05.11.2024 Miriam WELCOME IN MY WORLD

This website is originally written in the Czech language. Only part of the content is machine (AI) translated into English. The translation may not be exact and may contain errors.

Tento článek si můžete zobrazit v originální české verzi. You can view this article in the original Czech version.
Exchange Hybrid - schránky a jejich umístění, příjemci, atributy a opravy chyb

Exchange Hybrid - mailboxes and their locations, recipients, attributes and bug fixes

| Petr Bouška - Samuraj |
This article describes some important principles of hybrid Exchange configuration. What attributes must be synchronized to Azure AD for correct functionality. How mailboxes are handled in an On-Premises organization versus Exchange Online and how we can find out where a user has a mailbox. How to properly create and move a mailbox. Describes all the situations that can arise in practice, in terms of placing a mailbox for a single user. It deals with the repair of non-functional variants. The situation where one user has a mailbox on an internal server and a mailbox in the cloud (one of them is basically broken) is mostly discussed. Many things have to be done using PowerShell.
displayed: 7 390x (7 335 CZ, 55 EN) | Comments [3]

Azure AD Connect and attributes for Hybrid Exchange

Setting up using the Exchange Hybrid wizard does not solve the users and their mailboxes. Only routing and communication are set up. The prerequisite for a hybrid deployment is Active Directory Synchronization. But Azure AD Connect must be configured correctly. When we run the wizard for the first time, it will retrieve the data from our domain and set the synchronization rules accordingly, i.e., which attributes should be synchronized.

ExchangeGUID

In the lab, I installed Exchange only after the Azure AD Connect was set up. So no Exchange attributes were getting into Azure AD. When the user was assigned an Exchange Online license, a mailbox was created for them in the cloud, even though they already had one on the On-Premises server. The fact that the user has a mailbox in the On-Premises organization, and therefore a new one should not be created in the online organization, is determined by the ExchangeGUID property (attribute msExchMailboxGuid). This must be synchronized to Azure AD with the user.

If Exchange attributes are not synchronized

If there are changes to the AD DS schema, such as the installation of an Exchange server (or some Cumulative Update that modifies the schema), it is necessary to run the Azure AD Connect task Refresh directory schema. Then the synchronization of Exchange attributes to Azure AD will be completed. This is likely handled by the In from AD - User Exchange rule.

Azure AD Connect - Refresh directory schema

To make the mailboxes work in both organizations, we also need to synchronize some attributes back from Azure AD to the On-Premises directory. To set this up, we run the Azure AD Connect task Customize synchronization options and enable the optional feature Exchange hybrid deployment. The list of attributes is available in the Azure AD Connect sync: Attributes synchronized to Azure Active Directory.

Simple check

Before setting up Exchange Hybrid, we can easily check if the Exchange attributes are being replicated to Azure AD. When we look at Exchange Online, all internal users with a mailbox should be created as contacts. In the Exchange Admin Center (EAC), we can see them under Recipients - Contacts.

Users and Recipient Type

Objects (users and resources) that send and receive mail in an Exchange organization are called recipients. They have an email address and other mail-related attributes (mail-enabled object) in Active Directory. Exchange contains many recipient types, which it identifies by the RecipientTypeDetails property (attribute msExchRecipientTypeDetails). It also uses more general types in the RecipientType property (attribute msExchRecipientDisplayType). When synchronizing to Exchange Online, an additional property RemoteRecipientType (attribute msExchRemoteRecipientType) is used.

More information in Exchange recipient types, Recipient Type Values, list of RecipientTypeDetails parameters Get-User.

Exchange PowerShell contains several cmdlets that return information about users and mailboxes. We provided some information and examples in the first part of the article PowerShell for Azure AD, Exchange Online, working with licenses. Most cmdlets are designed for a specific object type.

A general cmdlet for user information that does not contain properties related to the mailbox, but shows the recipient type, is:

Get-User | FT Name, *RecipientType*

What interests us at the moment is the recipient type:

  • UserMailbox - a mailbox assigned to a user in our (local) Exchange organization
  • MailUser - a Mail-Enabled user (has an account in our organization, but does not have a mailbox here), who represents a user outside our organization (typically in Exchange Online)
  • User - this is not actually a recipient type, but a user account that is not mail-enabled, used by the Get-User cmdlet

Exchange PowerShell cmdlets for objects

The Get-User cmdlet shows users of all types (Mail-Enabled and Non-Mail Enabled), but does not show resources (objects). To display all recipients (Mail-Enabled objects, such as users, groups, contacts), we can use Get-Recipient. For detailed information, we have cmdlets by recipient type, such as Get-Mailbox, Get-MailUser, Get-Contact, Get-MailContact, Get-DistributionGroup, etc.

A special cmdlet is Get-RemoteMailbox, which displays information about local accounts that have a mailbox in the cloud (MailUser). It displays only the mailbox information that is located in the local AD. For more (and more accurate) information, a query in Exchange Online is required.

Another cmdlet that will display certain information about the mailbox location is shown below. According to the documentation, it is only for Exchange Online, but it also works for me on Exchange Server 2016, but only for the mailboxes located here.

Get-MailboxLocation -Identity bouska@firma.cz

Identifying where the mailbox is located

Verifying whether a user has a mailbox on On-Premises Exchange or in Exchange Online is not always easy, especially in problematic or (according to Microsoft) non-standard situations (which can occur quite often). It is important to compare the data in both Exchange organizations.

Using the Exchange Admin Center (EAC)

We can use the Exchange Admin Center (EAC). When looking at the local Exchange (Enterprise), the mailboxes have a Mailbox Type column, where it is User for a local mailbox or Office 365 for a cloud mailbox. It would seem that we should see all users with a mailbox here. But depending on how the mailbox was created in the cloud, some will not be visible (and those will be problematic).

On-Premises EAC - různé typy schránek

When we switch to Exchange Online (Office 365), on the Mailboxes tab we see only users with a mailbox in the cloud, of type User. But we can also see some that we did not see in the On-Premises. If we switch to Contacts, we will see the synchronized users with a mailbox on the On-Premises Exchange, of type Mail user (in practice, we will also see many Guest mail user, guest accounts).

Exchange Online EAC - různé typy schránek

Using Exchange PowerShell (EMS)

Using Exchange PowerShell, we can similarly list users, and perhaps limit the output in some way. The type is seen from the perspective of the organization in which the query is running.

For the local Exchange.

[PS] C:\>Get-User -RecipientTypeDetails User,UserMailbox,RemoteUserMailbox | FT Name, RecipientType*

Name              RecipientType RecipientTypeDetails
----              ------------- --------------------
Bouška Petr         UserMailbox          UserMailbox
Černý                  MailUser    RemoteUserMailbox
Petr Poslední              User                 User

And for the Exchange Online.

PS C:\> Get-User -RecipientTypeDetails User,UserMailbox,MailUser | FT Name, RecipientType*

Name                        RecipientType RecipientTypeDetails
----                        ------------- --------------------
Bouška Petr                 MailUser      MailUser  
Černý                       UserMailbox   UserMailbox         
Petr Poslední               UserMailbox   UserMailbox  

List of Mail-enabled objects with ExchangeGUID for the local Exchange

[PS] C:\>Get-Recipient -RecipientTypeDetails UserMailbox,RemoteUserMailbox | FT Name, ExchangeGuid, RecipientType*

Name            ExchangeGuid                         RecipientType RecipientTypeDetails
----            ------------                         ------------- --------------------
Bouška Petr     bd27a862-cd7e-4071-986b-85815e5fbc6c   UserMailbox          UserMailbox
Černý           ceb0ee0d-35e0-4843-9875-4c0a9e588454      MailUser    RemoteUserMailbox

List of Mail-enabled objects with ExchangeGUID for the Exchange Online

PS C:\> Get-Recipient -RecipientTypeDetails UserMailbox,MailUser | FT Name, ExchangeGuid, RecipientType*

Name            ExchangeGuid                         RecipientType RecipientTypeDetails
----            ------------                         ------------- --------------------
Bouška Petr     bd27a862-cd7e-4071-986b-85815e5fbc6c MailUser      MailUser            
Černý           ceb0ee0d-35e0-4843-9875-4c0a9e588454 UserMailbox   UserMailbox         
Petr Poslední   77b54d03-c6a1-416d-987b-d447681508d1 UserMailbox   UserMailbox         

In the example, there are three users. Petr Bouška has a mailbox on the On-Premises Exchange and correct information in the Exchange Online. In contrast, Černý has a mailbox in the Exchange Online and correct information on the On-Premises Exchange. Then there is Petr Poslední, who has a mailbox in the Exchange Online, but the On-Premises organization is not aware of it (he is here as a user who is not mail-enabled).

Different Mailbox Placement Scenarios and Potential Issues

In practice, we can encounter various scenarios for creating and existence of mailboxes for a single user. Especially if we have a separate On-Premises and cloud environment that we are combining. Microsoft considers the standard situation to be when we have an On-Premises environment and are building a cloud from scratch (and according to them, ideally move everything there). In many non-standard situations, mail delivery will not work correctly, so we need to fix them.

Correct and Functional Scenarios

  • Local user with a mailbox on the Exchange server, account synchronized to Azure AD, license assigned - local mailbox (UserMailbox), a contact is created in the cloud (MailUser)
    • if the mailbox is moved to Online - in the cloud it changes to a mailbox (UserMailbox), locally to an Office 365 mailbox (RemoteUserMailbox)
  • User created locally with a mailbox in the cloud, account synchronized to Azure AD, license assigned - a Office 365 mailbox is created locally (RemoteUserMailbox), a mailbox is created in the cloud (UserMailbox)

Bad and Non-Functional Scenarios

  • Local user without a mailbox, account synchronized to Azure AD, license assigned - a mailbox is created in the cloud (UserMailbox), nothing locally (remains User) - problem (cannot be moved to On-Premises, mail from internal servers is not delivered)
    • there is no problem creating a mailbox locally, then the same problem arises as in the next point
  • Local user with a mailbox on the Exchange server, cloud user with an online mailbox, connected via synchronization - in Azure AD the user is connected, but the mailbox remains, so one user with two mailboxes is created - local mailbox (UserMailbox), cloud mailbox (UserMailbox) - problem

Correct Creation of a Mailbox in Exchange Online

I was unable to find an official Microsoft procedure. For such an important operation, I would expect information in the Exchange Hybrid description. The following information is from practice. Related information Recipients in Exchange Online.

If we create a user in the On-Premises AD and synchronize it to Azure AD, where we then assign a license to them. This will create a mailbox in the cloud, but the Exchange attributes will not be added to the local AD. From the perspective of the local Exchange, it is a user without a mailbox. So it will not be able to deliver mail from mailboxes in On-Premises (and possibly also from the internet, if mail comes through local servers). We must therefore correctly create a user in the cloud or then fix the problem.

Using the Exchange Admin Center (EAC)

Using the Exchange Admin Center (EAC), we can create a user with a mailbox in the cloud. There is no option to create a mailbox for an existing user. The choice is located (if we have set up Exchange Hybrid) in Recipients - Mailboxes - the New (plus) icon and the Office 365 mailbox item.

On-Premises EAC - vytvoření uživatele se schránkou v cloudu

Using Exchange PowerShell (EMS)

In the Exchange Management Shell (EMS) we have two cmdlets New-RemoteMailbox, Enable-RemoteMailbox. The first creates a user with a mailbox in the cloud, just like the EAC. The second creates an online mailbox for an existing user. We must specify the RemoteRoutingAddress, which has a domain in the form tenant.mail.onmicrosoft.com (the tenant is the name of our Tenant - organization).

Enable-RemoteMailbox bouska -RemoteRoutingAddress bouska@firma.mail.onmicrosoft.com

How the Mailbox Creation in the Cloud Works

The mentioned methods do not directly create an Exchange Online mailbox, but set specific attributes on the user account. Then the synchronization using Azure AD Connect must be performed correctly. Only then will the mailbox be created in the cloud. Some online guides state that we must first assign the user a license before the mailbox is created. But the mailbox is created even without a license and is functional for 30 days, during which time we must assign the license. This is confirmed by the note in Create user mailboxes in Exchange Online.

On the On-Premises Exchange, either a new Mail-Enabled user (Mail User) is created or the type of an existing user is changed. The ExchangeGUID is set to 00000000-0000-0000-0000-000000000000. The mailbox created in the cloud is generated a ExchangeGUID, but this value is not synchronized back to On-Premises. This is a problem if we later want to move the mailbox to the On-Premises Exchange. The solution is to manually set the ExchangeGUID of the local user.

Solving the Problem of Two Mailboxes for One User

Note: Operations in the cloud take some time (minutes, exceptionally even hours), so we always have to wait a certain amount of time (for example, assigning a license - creating a mailbox or changing the user type).

If the user has a mailbox in both organizations (locally and online), it is of course a problem. Both in terms of access to the mailbox and in terms of message delivery (within Exchange Online, mail will be delivered to the online mailbox, within On-Premises to the local one). In this case, the user has a different ExchangeGUID in the On-Premises AD and a different one in the Azure AD.

Keeping the Exchange Online Mailbox

We can keep the mailbox in the cloud and delete it on the On-Premises server, then set the user as a Remote Mailbox and optionally restore the data that was in the local mailbox to the cloud. Official description How to recover when a mailbox exists in both Exchange Online and On-Premises, My user has a mailbox both On-Premises and in Exchange Online.

Keeping the On-Premises Exchange Mailbox

The second situation is that we want to keep the local mailbox and cancel the one in the cloud. For example, we originally used separate users with a license in the cloud for services like Teams. And only later did we synchronize with users from the On-Premises AD. Now we want to properly use the On-Premises mailboxes of the users for cloud services as well. The description is Permanently Clear Previous Mailbox Info.

If the user has an assigned license in the cloud, then the mailbox cannot be deleted (`Disable-Mailbox -PermanentlyDisable`). The only option is to remove the Exchange license from the user. At that point, the type and parameters will change according to the synchronized data and mail routing will start working.

The further description includes not only the necessary steps to resolve the two mailboxes of the user, but also a number of additional things. These serve to analyze the situation, compare values and understand the behavior.

Brief steps, with some time needed to wait between individual operations (until the changes take effect)

  • Microsoft 365 admin center - remove the user's Microsoft 365/Office 365 license or just remove the Exchange Online service from it (there are often links to other applications, so we must remove those as well)
  • Exchange Online PowerShell - use the cmdlet Set-User -PermanentlyClearPreviousMailboxInfo to remove the user's information about the previous mailbox
  • Microsoft 365 admin center - restore the user's license or service

Viewing User Information

First, let's display the user data in the internal organization.

[PS] C:\>Get-User posledni@firma.cz | Select Name,*Recipient*,MailboxLocations

Name                         : Petr Poslední
PreviousRecipientTypeDetails : None
RecipientType                : UserMailbox
RecipientTypeDetails         : UserMailbox
MailboxLocations             : {1;77b54d03-c6a1-416d-adcb-d447681508d1;Primary;firma.local;48c9a781-03fe-41df-b294-
                               7b8be749900a}

[PS] C:\>Get-Recipient posledni@firma.cz | Select Name,ExchangeGuid

Name          ExchangeGuid
----          ------------
Petr Poslední 77b54d03-c6a1-416d-adcb-d447681508d1

Then the same user in the online organization.

PS C:\> Get-User posledni@firma.cz | Select Name,*Recipient*,MailboxLocations

Name                         : Petr Poslední
PreviousRecipientTypeDetails : None
RecipientType                : UserMailbox
RecipientTypeDetails         : UserMailbox
MailboxLocations             : {1;a910edc4-695a-4c38-afd5-2952ec1edba8;Primary;eurprd06.prod.outlook.com;2fedd290-4342-4bdb-
                               8a87-4f232be828a4}

PS C:\> Get-Recipient posledni@firma.cz | Select Name,ExchangeGuid

Name          ExchangeGuid                        
----          ------------                        
Petr Poslední a910edc4-695a-4c38-afd5-2952ec1edba8

Removing the Exchange Online License

In the Microsoft 365 admin center, we remove the Exchange Online service (application) from the Microsoft 365 / Office 365 license of the user. After removing the service, the mailbox is deleted and the user type changes (from mailbox to contact), but the previous user type (PreviousRecipientTypeDetails) is also set. This information indicates that the user had a mailbox in the cloud. It's interesting to me that the ExchangeGUID changes to the value from On-Premises.

Displaying user data in the online organization after removing the license.

PS C:\> Get-User posledni@firma.cz | Select Name,*Recipient*,MailboxLocations

Name                         : Petr Poslední
PreviousRecipientTypeDetails : UserMailbox
RecipientType                : MailUser
RecipientTypeDetails         : MailUser
MailboxLocations             : {1;a910edc4-695a-4c38-afd5-2952ec1edba8;ComponentShared;eurprd06.prod.outlook.com;2fedd290-
                               4342-4bdb-8a87-4f232be828a4}

PS C:\> Get-Recipient posledni@firma.cz | Select Name,ExchangeGuid

Name          ExchangeGuid                        
----          ------------                        
Petr Poslední 77b54d03-c6a1-416d-adcb-d447681508d1

Attempt to Restore the Exchange Online License (do not perform)

At this point, mail delivery should be working correctly. But for some functions, we need to assign the Exchange license to the user again. If we do this, the original ExchangeGUID will be set and the mailbox will be connected / created in the cloud. So we're back where we started.

PS C:\> Get-User posledni@firma.cz | Select Name,*Recipient*,MailboxLocations

Name                         : Petr Poslední
PreviousRecipientTypeDetails : MailUser
RecipientType                : UserMailbox
RecipientTypeDetails         : UserMailbox
MailboxLocations             : {1;a910edc4-695a-4c38-afd5-2952ec1edba8;Primary;eurprd06.outlo
ok.com;2fedd290-4342-4bdb-8a87-4f232be828a4}

PS C:\> Get-Recipient posledni@firma.cz | Select Name,ExchangeGuid

Name          ExchangeGuid                        
----          ------------                        
Petr Poslední a910edc4-695a-4c38-afd5-2952ec1edba8

Deleting the Original Mailbox Information

Microsoft added a parameter to the Get-User cmdlet that deletes the information about the previous user type, ExchangeGUID, MDB. We must use it when the user has no license assigned (and therefore no mailbox in the cloud). When running the command, we confirm the warning that the data will be permanently deleted and the mailbox cannot be reconnected (nor can data be retrieved from it).

PS C:\> Set-User posledni@firma.cz -PermanentlyClearPreviousMailboxInfo
Confirm
Are you sure you want to perform this action?
Delete all existing information about user "Jon@contoso.com"?. 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?
Yes  Yes to All  No  No to All  [?] Help (default is "Y"): Y

Now, when we look at the user information in the cloud.

PS C:\> Get-User posledni@firma.cz | Select Name,*Recipient*,MailboxLocations

Name                         : Petr Poslední
PreviousRecipientTypeDetails : None
RecipientType                : MailUser
RecipientTypeDetails         : MailUser
MailboxLocations             : {1;a910edc4-695a-4c38-afd5-2952ec1edba8;ComponentShared;eurprd06.pr
od.outlook.com;2fedd290-4342-4bdb-8a87-4f232be828a4}

PS C:\> Get-Recipient posledni@firma.cz | Select Name,ExchangeGuid

Name          ExchangeGuid                        
----          ------------                        
Petr Poslední 77b54d03-c6a1-416d-adcb-d447681508d1

Assigning the Exchange Online License

After deleting the previous information, we can safely return the Exchange Online license. The account will remain as a contact and the correct ExchangeGUID will remain.

PS C:\> Get-User posledni@firma.cz | Select Name,*Recipient*,MailboxLocations

Name                         : Petr Poslední
PreviousRecipientTypeDetails : None
RecipientType                : MailUser
RecipientTypeDetails         : MailUser
MailboxLocations             : {1;a910edc4-695a-4c38-afd5-2952ec1edba8;ComponentShared;eurprd06.pr
od.outlook.com;2fedd290-4342-4bdb-8a87-4f232be828a4}

PS C:\> Get-Recipient posledni@firma.cz | Select Name,ExchangeGuid

Name          ExchangeGuid                        
----          ------------                        
Petr Poslední 77b54d03-c6a1-416d-adcb-d447681508d1

Fixing Using PowerShell Over a Group of Users

The information on how to work with Microsoft 365 / Office 365 licenses was described in the second part of the article PowerShell for Azure AD, Exchange Online, working with licenses. We described the use of PowerShell for removing services, setting licenses, retrieving information, and performing bulk operations on a group of users.

In the last chapter Fixing an account when a duplicate mailbox is deleted in the cloud, we provided PowerShell commands that we can use to perform the steps described in the previous chapters. Additionally, we can use the fix for multiple accounts at once, which we can perhaps save to a text file.

User with a Mailbox in the Cloud Without a Link in On-Premises

Another problematic situation that can arise if we synchronize a local user without a mailbox to Azure AD and assign them an Exchange Online license there. A mailbox is created in the cloud, but these data are not synchronized to the On-Premises Exchange.

I could not find an official solution, but the following may work, as suggested by the article How to recover when a mailbox exists in both Exchange Online and On-Premises. We change the local user to Mail-Enabled, which will start the mail routing. We set the Exchange GUID to the value from the cloud, so that the accounts are correctly connected (and perhaps migration of the mailbox works).

Displaying User Information

The local user is not Mail-Enabled, so we cannot use most Exchange PowerShell cmdlets. The attribute msExchMailboxGuid in AD DS is not set. The account type is User.

[PS] C:\>Get-User bouska@firma.cz | Select Name,*Recipient*

Name          PreviousRecipientTypeDetails RecipientType RecipientTypeDetails
----          ---------------------------- ------------- --------------------
Bouška Petr                           None          User                 User

In the cloud, the user has a mailbox and a set ExchangeGUID.

PS C:\> Get-Recipient bouska@firma.cz | Select Name,ExchangeGuid

Name          ExchangeGuid                        
----          ------------                        
Bouška Petr   f58dee79-79a8-48eb-8cad-d6ec6f126cf7

PS C:\> Get-User bouska@firma.cz | Select Name,*Recipient*,MailboxLocations

Name                         : Bouška Petr
PreviousRecipientTypeDetails : User
RecipientType                : UserMailbox
RecipientTypeDetails         : UserMailbox
MailboxLocations             : {1;f58dee79-79a8-48eb-8cad-d6ec6f126cf7;Primary;eurprd06.prod.outlo
ok.com;725d2e57-d140-4b65-b45a-b913dbba615e}

Setting the Remote Mailbox

On the On-Premises Exchange, we use a command that would create a mailbox in the cloud (which already exists). The correct type of the local account and attributes are set. The Exchange GUID is still not set.

[PS] C:\>Enable-RemoteMailbox bouska -RemoteRoutingAddress bouska@firma.mail.onmicrosoft.com

Name                 RecipientTypeDetails            RemoteRecipientType
----                 --------------------            -------------------
Bouška Petr          RemoteUserMailbox               ProvisionMailbox

Displaying the data on the local Exchange server.

[PS] C:\>Get-RemoteMailbox bouska@firma.cz | Select Name,*RecipientType*

Name                 : Bouška Petr
RemoteRecipientType  : ProvisionMailbox
RecipientType        : MailUser
RecipientTypeDetails : RemoteUserMailbox

[PS] C:\>Get-Recipient bouska@firma.cz | Select Name,ExchangeGuid

Name         ExchangeGuid
----         ------------
Bouška Petr  00000000-0000-0000-0000-000000000000

Note: Here the RemoteRecipientType ProvisionMailbox is shown. If we move the local mailbox to the cloud, the RemoteRecipientType will be set to Migrated.

Setting the Exchange GUID

As a final step, we set the local user's ExchangeGUID to the value that this user has in the cloud.

[PS] C:\>Set-RemoteMailbox bouska@firma.cz -ExchangeGuid f58dee79-79a8-48eb-8cad-d6ec6f126cf7

Moving Mailboxes Between Organizations

Mailbox moves (Move Mailboxes) from On-Premises Exchange to Exchange Online or vice versa are well described in the article Move mailboxes between On-Premises and Exchange Online organizations in hybrid deployments. We must have the Exchange Hybrid set up correctly. Microsoft recommends performing a mailbox move test as a check of the Exchange Hybrid configuration.

For moving a mailbox, we can use the Exchange Admin Center (EAC) on Exchange Online. We choose either Migrate to Exchange Online or Migrate from Exchange Online.

  • EAC - Office 365 - Recipients - Migration

Mailbox Not Found

One of the errors that can occur is that the corresponding Mailbox GUID could not be found. We perform the check (and any necessary configuration) using PowerShell, as described above. This problem is also described in the article "MigrationPermanentException: Cannot find a recipient that has mailbox GUID" error message when you try to move a mailbox in an Exchange hybrid deployment.

Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ?'f58dee79-79a8-48eb-8cad-d6ec6f126cf7?'.
 --> Cannot find a recipient that has mailbox GUID ?'f58dee79-79a8-48eb-8cad-d6ec6f126cf7?'.
Author:

Related articles:

Azure, Microsoft 365, Office 365, Cloud

Various popular topics regarding the public cloud. More focused on Microsoft services, i.e. IaaS, PaaS, SaaS Azure, Entra ID directory services (formerly Azure AD) and hosted Microsoft 365 / Office 365 services.

Microsoft Exchange

Almost since the beginning of my practice, I have been involved in the administration of the Microsoft mail server, i.e. Exchange Server. I started with the 2003 version and worked my way up to Exchange Online. The articles cover many areas of management. Most since the migration to Exchange Server 2016 and its complete configuration. But also Exchange Hybrid and e-mail security.

If you want write something about this article use comments.

Comments
  1. [1] gisbern

    Predem chci podekovat za krasne stranky, ktere je radost cist :)

    Nyni k memu dotazu. Ve firme s domenou xxx.cz mame vlastni on-premise server exchange 2016. Tak. A radi bychom vyuzivali nektere funkce 365 (PLANNER, TEAMS..) Nicmene vzhledem k GDPR nemuzeme preklopit kompletni exchange domenu do 365. Maily si chceme nechat na vlastnim serveru. Samozrejme to lze zrejme udelat tak, ze si na 365 zridime jinou domenu, yyy.cz , pak ale budeme mit dva maily, coz je neprakticke.

    1. Donutit 365 aplikace (teams atd..), aby spolupracovaly s on-premise exchange ? Pocitam, ze to je sci-fi a konfiguracně neproveditelné, ale bylo by to reseni, ktere by mi vyhovovalo

    2. na 365 jsem duplicitne zridil stejnou domenu xxx.cz se stejnymi schrankami jako na-onpremise exchange pro ucely pouziti teams apod. Nicmene jsou to porad oddelene schranky. Lze donutit takoveto schranky k nejakemu typu synchronizace mezi sebou ?

    Dekuji moc

    Monday, 07.06.2021 08:58 | answer
  2. [2] Samuraj

    respond to [1]gisbern: Ale vždyť to je přesně to, co popisuji v těchto článcích o Exchange Hybrid. A ještě tam zmiňuji, že je to potřeba právě pro využití Teams a přístupu do kalendářů.

    Musím synchronizovat uživatele z AD DS do Azure AD, nastavit komunikaci Exchange, uživatelé mohou zůstat On-Premises, ale cloudové aplikace mohou přistupovat ke schránkám (určitým omezeným způsobem). Nefunguje třeba ToDo, protože to běží přímo v Exchange Online.

    Monday, 07.06.2021 09:16 | answer
  3. [3] gisbern

    respond to [2]Samuraj: Moc dekuji za reakci. Ja si to proctu pozorneji. Me se prave zdalo, ze clanek puvodne popisuje to, ze CAST uzivatelu je na 365 a cast na on-premise.

    Co se tyka synchronizace, me by se pak libila synchronizace pouze kalendaru, aby maily zustavaly na lokalnim exchangi.

    Sunday, 13.06.2021 11:48 | answer
Add comment

Insert tag: strong em link

Help:
  • maximum length of comment is 2000 characters
  • HTML tags are not allowed (they will be removed), you can use only the special tags listed above the input field
  • new line (ENTER) ends paragraph and start new one
  • when you respond to a comment, put the original comment number in squar brackets at the beginning of the paragraph (line)