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.
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).
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).
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.
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?'.
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
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.
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.