Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. MMSSPP doesn't deprovision an Exchange mailbox and mail-enabled objects from Office 365 Dedicated/ITAR

MMSSPP doesn't deprovision an Exchange mailbox and mail-enabled objects from Office 365 Dedicated/ITAR

View products that this article applies to.

Symptoms

Microsoft Managed Services Service Provisioning Provider (MMSSPP) doesn't deprovision a Microsoft Exchange mailbox or mail-enabled objects from an Office 365 Dedicated/ITAR environment.

↑ Back to the top

Cause

Deprovisioning has multiple definitions, and in the context of Office 365 Dedicated/ITAR, these services can mean any of the following:
  • Disconnection of a mailbox in Office 365 and conversion of the Office 365 object to a mail-enabled user. This is common in any of the following scenarios:
    • A user mailbox is migrated to a different environment (for example, from the cloud back to on-premises).
    • Where mail services are disabled but other cloud services (such as Lync or Skype for Business) are maintained.
    • Where contact information can be viewed in the global address list (GAL).
    • Where the user can be a member of a distribution or mail-enabled security group in Office 365.
  • Deprovisioning of a mail-enabled user or a contact. This removes mail entitlements and attributes (mail, mailNickname, legacyExchangeDN, proxyAddresses, and targetAddress) and removes the user from any mail-enabled distribution or security groups in Office 365, but keeps the provisioned Active Directory (AD) object.
  • Complete removal of the user's object from Office 365 Active Directory.
  • Conversion of an active mailbox that's on Litigation Hold to an Inactive state.
  • Removal of a mail-enabled group from Office 365 Active Directory.
Failure to deprovision may occur for one or more of the following reasons:
  • Correct processes or best practices to deprovision objects aren't followed.
  • A misconfigured attribute value that’s reported in the daily MMSSPP Sync Error Report blocks the deprovisioning of the mailbox or the mail user.
  • A mailbox is on Litigation Hold. Such a mailbox can never be deprovisioned as long as that flag is set (although it can be put in an Inactive state).

↑ Back to the top

Best practices

Scenario 1

User has a mailbox in Office 365D/ITAR and the mailbox must be deprovisioned. However, the Office 365D/ITAR object must stay in the GAL as a mail-enabled user.
  1. Check the daily MMSSPP Sync Error report, and fix any errors that are reported. After the error report file is unzipped, there's an attached Help file together and remediation steps for each error type.
  2. On the designated deprovisioning attribute, add the value that triggers mailbox deprovisioning. Make no other changes, and wait for the managed mailbox to be removed from the Office 365 environment (the homeMDB attribute value will become null). This is typically executed in one or two MMSSPP sync cycles.
    1. The attribute that's used for deprovisioning differs for each customer, and it's typically the same value as that's used for mailbox provisioning values (for example, a usually provisioned mailbox has extensionAttribute9=MBX=50GB;Type=EP2D;REG=EU;).
    2. The value that's used for deprovisioning is different for each customer. However, the value is typically RemoveMSOMbx (for example, extensionAttribute9=RemoveMSOMbx).
  3. After the mailbox is disabled, change the customer targetAddress attribute value to point to the desired location outside Office 365D/ITAR (typically, this is SMTP:sameAsMailValue), and remove the deprovisioning attribute. After some sync cycles, the object is mail-enabled and visible in the GAL.

Scenario 2

If the user has a mailbox in Office 365D/ITAR, the mailbox must be deprovisioned, and the Office 365D/ITAR objects must be removed from the Office 365 AD.
  1. Variation 1: Customer doesn't have the Automatic Services Reconnection (ASR) feature that's enabled for cross-forest mailbox reconnections. Any of the following methods are effective:
    • Move the user object into an organizational unit (OU) that's out of scope of MMSSPP.
    • Set the appropriate value for the MMSSPP filter. This value is set for each customer with respect to both the attribute and the value, but its structure may be something like extensionAttribute1=NoSync.
    • Use the universal filter for MMSSPP. This filter clears values from all the following attributes:
      • Mail
      • MailNickname
      • ProxyAddresses
      • TargetAddress
    • Delete the object from the customer AD.
  2. Variation 2: Customer has the ASR feature that's enabled for cross-forest mailbox reconnections. In this situation, objects that are filtered, moved, or deleted from the customer AD cause the managed objects to be moved into a retention OU (where they're hidden from the GAL but still receive mail) for 1-3 days.
    1. Correct any sync errors.
    2. Add the DeleteNow value to the designated mailbox provisioning attribute and enable at least one sync cycle to be completed. This is a staging-only value that doesn't trigger deprovisioning. It tells MMSSPP that when the filter is applied to immediately delete the managed AD object instead of keeping it in the PendingDeletions OU for 1-3 days.
    3. Make any of the changes that are noted in Variation 1(move, apply the custom filter, apply the universal filter, or delete).

Scenario 3

User's mailbox is on Litigation Hold. In this scenario, the Office 365 mailbox is connected, and the managed AD object is retained. This is the recommended process for putting the mailbox into an Inactive Litigation Hold state:
  1. If the customer's process is to delete the user's AD object after a time, change the values of the mail, targetAddress, and smtp proxyAddresses attributes to append _old or _litHold to the prefix. This lets the user access their original email and proxy addresses when they return to the employment. Make these attribute changes before you follow the next steps.
  2. If other services (such as Lync) must be changed, make the appropriate attribute changes.
  3. Add the Type=InHold; value to the attribute that's used for mailbox provisioning values (this differs per customer). Use this example:

    MBX=50GB;Type=InHold;REG=EU;
  4. Wait at least one sync cycle.
  5. After the Type=InHold; value is synched to Office 365D/ITAR, the user can no longer log on to the mailbox. The mailbox is hidden from the GAL, and senders to that mailbox receive a non-delivery report NDR).
  6. After you complete steps 1-5, the customer object can be filtered, moved out of scope, or deleted.
  7. If step 6 is finished before you complete steps 1-5 being, the managed mailbox is still inactive. However, skipping those steps may make queries more difficult and make restoration of services more complex when the user returns to work.

Scenario 4

Lync Dedicated/ITAR services must be deprovisioned:
  1. Lync can be deprovisioned independently of mailbox status by setting a value of 0 in the attribute that's selected for Lync provisioning. This differs for each customer.
  2. If the user mailbox is on Litigation Hold, the Lync deprovisioning value of 0 must be set before the customer object is filtered, removed from the scope, or deleted from the customer AD.

Scenario 5

A mail-enabled user (not a mailbox-enabled user) or mail-enabled contact must be deprovisioned. Be aware that mail-enabled users are typically users who can log on to the customer domain resources, but who receive mail at a mailbox outside the Office 365D/ITAR environment. These mailboxes may be located in the customer on-premises environment or on an external service. To disable a mail-enabled user, use any of the following methods:
  • Move the user object into an OU that's out of scope of MMSSPP.
  • Set the appropriate value for the MMSSPP filter. This value is set for each customer with respect to both the attribute and the value, but its structure may be something like extensionAttribute1=NoSync.
  • Use the universal filter for MMSSPP. This filter clears values from all the following attributes:
    • Mail
    • MailNickname
    • ProxyAddresses
    • TargetAddress
  • Delete the object from the customer AD.

Scenario 6

A mail-enabled group must be deprovisioned. In this situation, a group that's provisioned on Office 365D/ITAR is removed from the GAL and Active Directory. Additionally, it's removed as a member of any group of which it's a member. Either of the following methods is effective:
  • Clear the mail value for the group.
  • Delete the group object from the customer AD.

↑ Back to the top

Resolution

After consideration of the appropriate scenarios, you may correct a failed deprovisioning scenario by one of the following methods.

Scenario 1

An Office 365D/ITAR mailbox must be deprovisioned, and the user must be mail-enabled (not mailbox-enabled) in Office 365D/ITAR. 
  1. Return the values of the mail and targetAddress attributes to the original values necessary to provision an Office 365D/ITAR mailbox (for example, the mail attribute suffix is in the SMTP inclusion list, and the targetAddress attribute suffix resembles @mgd.customerdomain.com).
  2. Set the mailbox deprovisioning attribute value (for example, extensionAttribute9=RemoveMSOMbx).
  3. After the mailbox is deprovisioned (the get-recipient cmdlet finds no one, or the get-user cmdlet returns a value), set the values of the mail and targetAddress attributes to the desired state for a mail-enabled user.

Scenario 2

User has a mailbox in Office 365D/ITAR, the mailbox must be deprovisioned, and the Office 365D/ITAR objects must be removed from the Office 365 AD: 
  1. Variation 1: Customer doesn't have the ASR feature that's enabled for cross-forest mailbox reconnections. Any of the following methods is effective:
    • Move the user object into an OU that's out of scope of MMSSPP.
    • Set the appropriate value for the MMSSPP filter. This value is set for each customer who has respect to both the attribute and the value, but its structure may be something like extensionAttribute1=NoSync.
    • Use the universal filter for MMSSPP. This filter clears values from all the following attributes:
      • Mail
      • MailNickname
      • ProxyAddresses
      • TargetAddress
    • Delete the object from the customer AD.
  2. Variation 2: Customer has the ASR feature that's enabled for cross-forest mailbox reconnections. In this situation, objects that are filtered, moved, or deleted from the customer AD cause the managed objects to be moved into a retention OU (where they're hidden from the GAL but still receive mail) for 1-3 days.
    1. Correct any sync errors.
    2. Add the DeleteNow value to the designated mailbox provisioning attribute, and enable at least one sync cycle to be completed. This is a staging-only value that doesn't trigger deprovisioning. It tells MMSSPP that when the filter is applied to immediately delete the managed AD object instead of keeping it in the PendingDeletions OU for 1-3 days.
    3. Make any of the changes that are noted in Variation 1 (move, apply the custom filter, apply the universal filter, or delete).

Scenario 3

User's mailbox is on Litigation Hold.
  1. A mailbox isn't deprovisioned as long as it's on Litigation Hold.
  2. See the "Best practices" section for recommendations involving the process for moving a mailbox to an Inactive Litigation Hold state.
  3. Only after a mailbox is removed from Litigation Hold, actions in Scenario 1 or 2 will result in the mailbox being deprovisioned.

Scenario 4

User's mailbox is on Litigation Hold, but is in Inactive state before Lync services are deprovisioned. Lync services must be deprovisioned.
  1. If the customer object is still in scope of MMSSPP and not filtered (the mailbox was made Inactive by adding the Type=InHold; value to the provisioning attribute), set the attribute value to 0 for the Lync provisioning bitmask attribute. This value results in the deprovisioning of Lync services after some sync cycles. For example, extensionAttribute6=15 is changed to extensionAttribute6=0.
  2. If the user mailbox is on litigation hold, and the customer filtered or removed the object from scope before deprovisioning Lync, additional steps must be taken to deprovision Lync:
    1. With the customer object still filtered or out of OU scope, add the Type=InHold; value to the mailbox provisioning attribute (if it's not already set). This is very important if the mailbox is intended to remain inactive. If the value isn't added, the mailbox is returned to active status (enabling logon and mail delivery) as soon as it's returned to scope.
    2. Set the Lync bitmask attribute value to 0.
    3. Remove the filter or move the customer object back into OU scope.
    4. After some sync cycles, Lync services are deprovisioned.
    5. When Lync deprovisioning is completed, the customer object can be left unmodified, filtered, removed from scope, or deleted as per customer policy.

Scenario 5

A mail-enabled user (not a mailbox-enabled user) or mail-enabled contact must be deprovisioned. To disable a mail-enabled user, any of the following methods is effective:
  • Move the user object into an OU that is out of scope of MMSSPP.
  • Set the appropriate value for the MMSSPP filter. This value is set for each customer who has respect to both the attribute and the value, but its structure may be something like extensionAttribute1=NoSync.
  • Use the universal filter for MMSSPP. This filter clears values from all the following attributes:
    • Mail
    • MailNickname
    • ProxyAddresses
    • TargetAddress
  • Delete the object from the customer AD.

Scenario 6

A mail-enabled group must be deprovisioned. In this case, a group that is provisioned on Office 365D/ITAR is removed from the GAL and Active Directory. In addition, it's removed as a member of any group of which it's a member. Either of the following is effective:
  • Clear the mail value for the group.
  • Delete the group object from the customer AD.
Notes
  • After a user object is provisioned in Office 365D/ITAR, avoid clearing the mail attribute value. Clearing the attribute doesn't deprovision a mailbox, and it may make query results ambiguous and routine maintenance tasks unnecessarily complex.
  • This document is intended to provide best practices and simple remediation steps for deprovisioning mail and Lync services in Office 365D/ITAR environments. Other actions taken by the customer may result in the deprovisioning of services. For more information, see the Office 365D/ITAR Provisioning Tools Handbook.
  • When a mailbox is deprovisioned, regardless of the method, it's not immediately deleted from Office 365D/ITAR. Instead, it's retained in a disconnected state for the configured retention period (typically 30 days), during which time it can be automatically reconnected (if the original user object is un-filtered or moved back into MMSSPP scope) or manually reconnected (through an escalation to Microsoft Support Services).

↑ Back to the top

Keywords: kb, tsg, vkbportal250, vkbportal226

↑ Back to the top

Article Info
Article ID : 2655364
Revision : 2
Created on : 11/22/2019
Published on : 11/22/2019
Exists online : False
Views : 308