MMSSPP does not deprovision Exchange mailbox and mail-enabled objects from the dedicated managed Office 365 environment

Article translations Article translations
Article ID: 2655364 - View products that this article applies to.
Expand all | Collapse all

Symptoms

Microsoft Managed Services Service Provisioning Provider (MMSSPP) does not deprovision Microsoft Exchange mailbox or mail-enabled objects from the dedicated managed Microsoft Office 365 environment.

Cause

This issue occurs for one of the following reasons:
  • Correct processes or best practices to deprovision objects are not followed.
  • An error in the MMSSPP synchronization report causes mailbox deprovisioning to fail.
  • Misconfiguration of the mailNickName, targetAddress, or mail attribute prevents MMSSPP automation from running the disconnect cmdlet successfully.
  • A mailbox that is on active litigation hold cannot be deprovisioned.

Resolution

Note Some deprovision methods are approved for use when an account is moved to a new domain or forest. The account should not be deleted or removed from the MMSSPP scope as part of this process. For more information, see the following document:
Tech Brief - Effects of Customer User Account Migration

All Microsoft Online Services (MSO) may be removed for a user only by taking one of the following actions:
  • Deleting the customer Active Directory object
  • Removing MSO from the scope of organizational units (OUs) from which MMSSPP synchronizes
  • Adding the criteria for the mailbox deprovisioning rule on the customer Active Directory object

    Generally, when an object meets the mailbox deprovisioning rule, it also meets the mail-enabled provisioning rule. These rules are not mutually exclusive. In this action, the object will be transformed from a mailbox-enabled user to a mail-enabled user.
Note Starting with MMSSPP version 11.1, a managed object remains for three days after it is deprovisioned or if a source object is moved out of OU scope. This enables customer cross-forest moves. Basically, users can connect a new source object to an existing managed object. This feature is called Automatic Service Reconnection (ASR).

Best practices for mail object deprovisioning

Best practices for mail object deprovisioning include the following:
  • Accounts should not be deleted or removed from the MMSSPP scope as part of a domain or mailbox move process.
    For more information, see the following document:
    Tech Brief - Effects of Customer User Account Migration
  • Do not remove or change any mail attributes from the mailbox. This includes the following attributes:
    • targetAddress
    • ProxyAddress
    • mailNickName
    Important Valid mail and mailNickName attribute values are required for automatic deprovisioning to be completed successfully.
  • If the deprovisioning rule is used, make sure that it is set correctly. For example, set the following rule: extensionAttributeX=removeMSOMailbox. In this situation, the attribute and value will vary.
  • If you want to create a mail-enabled user object, do not try to make multiple changes to a source object.
  • Wait for MMSSPP synchronization to be completed. Deprovisioning is processed after the synchronization is complete, and times vary.
  • If the source-object changes are applied during an active synchronization cycle, you must wait for another synchronization cycle for these updates to be imported into MMSSPP.
  • When the deprovisioning-mailbox process is successful, the logical next step is to provision a mail-enabled user or to remove all mail functionality.

If the object is not deprovisioned

If the appropriate deprovisioning steps and best practices are followed but the object is not deprovisioned as expected, follow these steps:
  1. A synchronization error report that describes any provisioning or synchronization errors is generated and sent to customer contacts each day. The report describes any provisioning or synchronization errors. Check this report for errors, and then take any necessary actions.

    For more information about MMSSPP synchronization errors, click the following article number to go to the article in the Microsoft Knowledge Base:
    2590119 How to troubleshoot MMSSPP synchronization error messages
  2. If you see one of the following managed errors listed in the synchronization error report, escalate to Microsoft Support for help:
    • ambiguous-import-flow-from-multiple-connectors
    • cd-error
    • cd-missing-object
    • dn-attributes-failure
    • extension-dll-exception
    • extension-unexpected-attribute-value
    • flow-multi-values-to-single-value
  3. If multiple changes are applied to the source object address attributes, such as the mail, targetAddress, proxyAddress, and mailNickName attributes, and the mailbox is not deprovisioned successfully, take steps to provision objects successfully in order to recover from this scenario. For more information about how to provision objects, click the following article number to go to the article in the Microsoft Knowledge Base:
    2615447 MMSSPP does not synchronize Exchange mailbox and mail-enabled objects to the managed Office 365 environment
    And then deprovision the objects again by only taking the approved deprovisioning steps.
  4. If a mailbox is on litigation hold, the mailbox cannot be deprovisioned by any of the deprovisioning conditions. Verify that the mailbox is not on litigation hold. To do this, run the following cmdlet in Windows Remote PowerShell:
    Get-mailbox alias | fl LitigationHoldEnabled
    The LitigtionHoldEnabled value must be set to FALSE before a mailbox is deprovisioned.
  5. After the mailbox is deprovisioned, make additional changes to the object address attributes. For more information about how to provision mail-enabled users, click the following article number to go to the article in the Microsoft Knowledge Base:
    2615447 MMSSPP does not synchronize Exchange mailbox and mail-enabled objects to the managed Office 365 environment
    If no mail functionality is needed, but OCS entitlements are needed, you can delete the mail and targetAddress attributes of the object.
  6. Verify that the managed object is no longer linked to a mailbox. To do this, connect to the managed environment, and then use Remote Windows PowerShell or the LDP tool, as follows:
    • Run the following Remote PowerShell cmdlet:
      Get-Mailbox alias  |fl *Recipient*
      The results will display an error if the mailbox is disconnected successfully. If the mailbox is not disconnected successfully, the results will include the RepientTypeDetails property that is listed as LinkedMailbox.
    • Use the LDP tool or ADSIEdit tool to connect to the managed domain, search on values that you have available, and then verify whether the homeMDB attribute exists. If the homeMDB attribute exists, this indicates that the mailbox is not deprovisioned.

    Note
    For customers who have Automatic Service Reconnection (ASR) enabled, a deprovisioned mailbox will remain available for self-service reconnection for a specified period of time. For more information about the specified period of time, see the content in step 7. The mailbox will continue to receive mail during this time. No additional modifications should be made to the object during this time to avoid putting the mailbox into a problem state. The benefit of ASR is to enable cross-forest moves. However, in the context of the deprovisioning behavior, see the following steps.
  7. For MMSSPP versions 11.1 or later versions with ASR enabled, deprovisioning action will result in moving the managed object to the Pending Deletions OU for a period of time. The time depends on the MMSSPP version. For more information about the time, see the content that appears later in this step. Therefore, any attempt to fix common problems by using the deprovisioning mailbox method will be delayed for the Pending Deletions retention period. After the retention period ends, the managed object will be deleted. If a customer object is moved into scope after the Pending Deletions retention period, MMSSPP creates a new managed object and will not reconnect to the original managed mailbox. In this situation, a new empty mailbox is created.
    For MMSSPP versions 11.1 to 12.3
    The default Pending Deletions retention period is three (3) days for users and groups, and zero (0) days for contacts. By filing a change request (CR), users can set up the duration within the range of 0 to 3 days.

    If an object must be deleted from the Pending Deletions OU before the scheduled expiration time, contact Microsoft Support to complete this task.
    For MMSSPP 13.1 or later versions
    For existing customers who are upgraded from earlier versions of MMSSPP, the default Pending Deletions retention period is thirty (30) days for users and groups, and zero (0) days for contacts. By filing a CR, users can set up the duration within the range of 0 to 30 days. The default duration for new customers is 30 days for users and groups, and 0 days for contacts.

    If an object must be deleted from the Pending Deletions OU before the scheduled expiration time, this can be performed through modification to the source Active Directory object.

    To set an object to be removed from the Pending Deletions OU during the next MMSSPP synchronization cycle, follow these steps:
    1. Select one of the following attributes to add the deletenow value:
      • The SetMailboxType provisioning attribute
      • The attribute that is selected for deprovisioning
    2. Remove all values that exist in the selected attribute.
    3. Insert the deletenow value.

    For more information about how to set an object to be removed, see the object filtering & deprovisioning scenarios section of the MMSSPP Provisioning Interfaces Handbook.

    Notes
    • The deletenow method must be used at least one synchronization cycle before the object is deleted from the on-premises Active Directory Domain Services (AD DS), or before the object is moved out of OU scope or is filtered from synchronization. If you do not set this flag before the on-premises object is deleted or moved, you must perform a manual deletion of the object in the managed environment. To do this, contact Microsoft Support.
    • Any customer may request a Pending Deletion retention period that is shorter than the limits that are set by the current MMSSPP version. To do this, the customer should submit a CR through their Microsoft Service Delivery Manager
  8. There may be instances where a source object is accidentally filtered, moved out of OU scope, or deleted from the source AD DS. To reconnect an accidentally-deleted source object before the Pending Deletion time expires, consider the following scenarios.

    Assumptions
    • The version of MMSSPP is 11.1 or a later version.
    • ASR is enabled.
    • The Pending Deletion time has not yet expired.

Scenario 1: Customer accidentally filters or moves a synched object out of OU scope

Effect
This action causes the managed object to be moved into the Pending Deletions OU for the retention period that is defined. For as long as the managed object exists in that OU, it continues to receive mail.
Action to reconnect
Remove the filter on the source object or move the filter back into an in-scope OU within the retention period.
Result
The source object is automatically reconnected to the original managed object, and all mailbox contents, configuration, and permissions are retained.

Scenario 2: Customer accidentally deletes an object from the source AD DS

Effect
This action causes the managed object to be moved into the Pending Deletions OU for the retention period that is defined. For as long as the managed object exists in that OU, it continues to receive mail.
  • Option 1
    Action to reconnect
    Run the ntdsutil authoritative restore command on the deleted object from the source AD DS. The source object automatically connects to the original managed object and its mailbox if the restoration is finished within the retention period.
    Result
    If the Pending Deletions period is passed, but the restoration is finished within the 30-day tombstone period for the managed mailbox, the mailbox is automatically reconnected. In this scenario, mailbox permissions must be reapplied.
  • Option 2
    Action to reconnect
    Restore the deleted object from the source AD DS. Make a minor change to any synched attribute (for example, add a period to the street address) so that MMSSPP recognizes the restored object. The source object is automatically connected to the original managed object and its mailbox, and the source object is provided that the restoration is finished within the retention period.
    Result
    If the Pending Deletions period is passed, but the restoration is finished within the 30-day tombstone period for the managed mailbox, the mailbox is utomatically reconnected. In this scenario, mailbox permissions must be reapplied.
  • Option 3
    Action to reconnect
    Create a new managed object, and then populate the new object by using the values of the original object. In the attribute that is reserved for ASR, enter the value from the GUID string of the original object. If this value is unknown, you can find it in the ms-msCustomerGUIDString attribute of the managed Pending Deletions object. The mail value of the new object must also match the mail value of the deleted object. When the sync process begins, MMSSPP runs an ASR reconnection to the object in the Pending Deletions OU. Then, all mailbox contents, configuration, and permissions are retained.
    Result
    If the Pending Deletions period is passed, don't stamp a value in the ASR attribute. A new managed object must be created. To restore the contents of the disconnected mailbox, file a service request at Microsoft Online Support.

More information

For more information about the ADSI Edit tool, go to the following Microsoft TechNet website:

http://technet.microsoft.com/en-us/library/cc773354(WS.10).aspx
For more information about the LDP tool, go to the following Microsoft TechNet website:
http://technet.microsoft.com/en-us/library/cc772839(WS.10).aspx

Properties

Article ID: 2655364 - Last Review: August 16, 2013 - Revision: 16.0
Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal
  • Microsoft Exchange Online
Keywords: 
vkbportal226 KB2655364

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com