This article highlights common issues that you may experience if your organization is migrating to Microsoft Office 365 dedicated/ITAR (vNext). This article also discusses familiar topics that may be different in vNext and legacy dedicated environments (called "dedicated" in this article).
Q1: How do I provision an object in vNext?
In order to establish cross-forest permissions and address book equivalency, you must bring all recipient objects into the scope for directory synchronization. Typically, the scope for directory synchronization should be the equivalent of any on-premises Organizational Unit (OU) that is the scope for Microsoft Managed Services Service Provisioning Provider (MMSSPP).
The dedicated object must have a presence in vNext as a mail user:
RecipientType : MailUserRecipientTypeDetails : MailUserExternalEmailAddress : SMTP:firstname.lastname@example.org
The vNext object should still have a presence in dedicated, but as a remote mailbox:
RecipientType : MailUserRecipientTypeDetails : RemoteUserMailboxRemoteRoutingAddress : SMTP:email@example.com
Note If you're running a Get-Recipient cmdlet instead of a Get-RemoteMailbox cmdlet in the dedicated environment, the displayed parameter name is ExternalEmailAddress, not RemoteRoutingAddress.
The following table demonstrates the on-premises Active Directory (AD) attributes that provision different kinds of objects in the vNext environment.
Azure AD provisioning
On-Premesis AD attributes
License applied (Yes/No)
targetAddress (onmicrosoft address) *
The get-mailbox output in vNext should show SKUAssigned=TRUE.
Mailuser (prepped for migration)
targetAddress (mgd address)
The Get-Recipient output in vNext should show SKUAssigned=TRUE.
The Get-Recipient output in vNext should show ExchangeGuid populated with a value. Therefore, the license can be set safely.
targetAddress (mgd address)
The Get-Recipient output in vNext should show SKUAssigned=FALSE.
targetAddress (mgd address)
This occurs because the ExchangeGuid value is blank. This means that the writeback of this value from dedicated to on-premises doesn't occur. Therefore, the value is not written to the cloud.
When the license is applied in vNext, it creates a new ExchangeGuid value and a newly provisioned mailbox. Now, the user has two mailboxes: One in dedicated and one in vNext.
This process is explained in the Note in step 2 of the following Knowledge Base article:
Mailbox (Directly provisioned)
targetAddress (onmicrosoft address)
At some point in the transition process, you may start directly provisioning mailboxes in vNext. An ExchangeGUID is not required to do this. A correctly configured object on-premises together with a license can create the mailbox. A remote mailbox or mail user in dedicated is still required for Autodiscover and mail flow to work during coexistence.
For resources such as rooms, see the following article that lists additional source AD attributes that must be synced if you are experiencing the issue that is described in this article:
Note Resource mailboxes (room, equipment, shared) do not require licenses in Exchange Online.
Q2: Why can't I see a dedicated user in the address book?
There is an address book in both dedicated and vNext, one for each forest. A user who has a mailbox in the dedicated environment uses the address book in the dedicated environment. A user who has a mailbox in vNext uses the address book that is in vNext. If there is a problem that affects an address book entry, make sure that you are troubleshooting the object in the correct environment.
Q3: How does Autodiscover work?
In order for Autodiscover to work, it's important that you have the user's onmicrosoft.com RemoteRoutingAddress (ExternalEmailAddress) property set correctly in dedicated. The migration routing relies on having a dedicated object together with an address that points to vNext.
The following example code shows how this works. In the communication to the dedicated Autodiscover endpoint, the server returns XML data to the client that indicates the appropriate redirect address.
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> <Account> <Action>redirectAddr</Action> <RedirectAddr>firstname.lastname@example.org</RedirectAddr> </Account> </Response></Autodiscover>
The client uses the suffix of the redirect email address to run Autodiscover in the vNext environment.
Q4: Will AutoComplete work?
The x500 address that exist on the dedicated object is written back to on-premises Active Directory Domain Services (AD DS), and will be written to the vNext object.
Note Other proxy addresses are not, for example, a secondary SMTP addresses such as email@example.com. Other secondary SMTP addresses should already exist in AD DS.
Q5: How do I correctly set up delegates, send-as, and send-on-behalf?
For a detailed description of how to set up delegates, see the following Office 365 extranet website:
The following are common scenarios in which an object must be "ACLable" (that is, the object can be added to an Access Control List):
- Can’t add mailbox or folder permissions in Outlook after migration to Office 365 Dedicated/ITAR (vNext)
- Cross-forest delegation troubleshooting for Office 365 Dedicated/ITAR customers (vNext)
- Can’t add a Room or Resource mailbox in another forest in Outlook for Office 365 Dedicated/ITAR (vNext)
Q6: What are MMSPP writebacks, and why do I need them?
Some directory information (for example, msExchMailboxGuid (ExchangeGUID) and publicDelegates (GrantSendonBehalfTo)) must be transferred from the dedicated directory to Azure Active Directory (Azure AD). To do this, the required information is extracted from the dedicated directory and written to your on-premises Active Directory. From there, Azure Active Directory Connect (AAD Connect) is used to transfer the information to the cloud. This MMSSPP writeback process is enabled in coordination with Microsoft deployment resources in advance of migrations. As soon as the process is enabled, MMSSPP automatically completes the writeback of data during standard syncs.
Note For ANSI-D 2010 environments, the writeback process is manual.
If the msExchMailboxGuid (ExchangeGuid) from dedicated is not populated to Azure AD, a new mailbox is created in vNext. For more information, see the following articles:
Q7: How do I manage quotas?
- Primary Mailbox: When a mailbox is migrated from dedicated, the existing size, 5 GB for example, is applied in the vNext environment. To change the size, use Configure storage quotas for a mailbox to increase it up to the maximum size that's listed for the assigned license. For example, the E3 license has the largest mailbox size at 100 GB.
For a list of Primary Mailbox limits, see the following table: Exchange Online Limits -> Storage limits across Office 365 options
- Recoverable Items: The limit for an active (primary) mailbox is 30 GB. The limit for an active (primary) on-hold mailbox is 100 GB. If more space is required, you should use an archive mailbox.
For a list of Recoverable Item limits, see the following table: Exchange Online Limits -> Mailbox folder limits across Office 365 options
- Archive Mailbox: The limits for an archive mailbox and associated recoverable items are listed in the Primary Mailbox and Recoverable Items tables. If an archive is present on the mailbox, the ArchiveGuid value is non-zeros. An auto-expanding archive is being released and may already be available in your environment. If you're experiencing limitation issues, Microsoft can increase the archive mailbox to 170 GB.
Q8: Is there an Automatic Service Reconnection (ASR) feature?
There is no ASR feature in vNext. If a user is provided a new Azure AD account (for example, if the user is transferred from contractor to full-time status), a new mailbox is automatically created in vNext. The customer should be directed to complete a mailbox restore process (by using the New-MailboxRestoreRequest cmdlet) to copy the content from a soft-deleted or inactive mailbox to the new active mailbox.
For more information, see the following TechNet topics:
Q9: How do I deprovision users?
Soft-deletedDeprovision: This occurs when an on-premises Azure AD account is moved out of scope of AAD Connect. The process is explained here at Delete or restore user mailboxes in Exchange Online.
Reprovision: The AD account is recoverable within 30 days by moving it back into scope or by restoring the content by using the New-MailboxRestoreRequest cmdlet.
Locating the deprovisioned mailbox: The customer can find the mailbox by using the following cmdlet:
Hard-deleted (disconnected)Deprovision: This occurs when the Exchange Online license is removed from the mailbox. The process is explained here: Delete or restore user mailboxes in Exchange Online.
Reprovision: The Exchange Online license is recoverable by reassigning it.
Locating the deprovisioned mailbox: The customer cannot see mailboxes in this state.
InactiveDeprovision: This occurs when mailbox is enabled for litigation hold and is then deleted. Content is then discoverable in the eDiscovery search UI. The process is explained in the following Exchange Online topic:
Note If the mailbox is not deleted, the user may still have access (even without a license). Therefore, the steps have to occur in this article earlier which includes deleting the mailbox.
Reprovision: The mailbox is recoverable using the New-MailboxRestoreRequest cmdlet. The process is explained in the following Exchange Online topic:
Locating the deprovisioned mailbox: The content is discoverable in eDiscovery search UI and the customer can find the mailbox by using the following cmdlet:
Q10: How do I license users?
In the "Q1: Azure AD provisioning" table, you can see how licensing plays a role in provisioning a mailbox in vNext. In addition to working in the Admin Center, you can use Azure AD PowerShell to manage users and licenses. To gain access to the "msol" commands, install the module, and then connect to it. Start here to download the Azure AD PowerShell module, and then review the commands that are available.
When you're ready, run the following cmdlet to connect.
$UserCredential = Get-CredentialConnect-MsolService -Credential $UserCredential
For more information, see Assign licenses to user accounts with Office 365 PowerShell.
If it's necessary, you can disable individual services in a license. To do this, follow these steps:
- Query the current status of the user's services by using the following cmdlet:
(Get-MsolUser -UserPrincipalName firstname.lastname@example.org).Licenses.ServiceStatus | sort-object ProvisioningStatus
Follow the instructions in the following Office 365 article to build scripts for single or multiple users to selectively disable specific services:
ID do Artigo: 4035834 - Última Revisão: 28/07/2017 - Revisão: 39