Exchange 2016 Decommission - Permission Issue

Question

Exchange 2016 Decommission - Permission Issue

Jon Shaw 20

Hi all,

I am trying to decom my 2016 environment and cannot disable (Disable-Mailbox) the final 16 mailboxes (out of thousands). Am getting the error

Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0.

I have been troubleshooting this for HOURS now. It's not enabling inheritance on the user perms (every article suggests that). The perm exchange trusted subsystem permissions are there. The users do not have any admin groups. It's nothing that I can find in the first 6 pages of googling. Sadly, of course, there is no support anymore so can't even raise a ticket.

Can't uninstall Exchange with mailboxes left :(

Any idea's are more than welcome, please.

Thank you.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Gabriel-N 16,565 Microsoft External Staff Moderator

Hello Jon Shaw

From your description, this error may be related to permission inheritance at the OU level rather than (or in addition to) the individual user objects.

In a similar scenario I researched, the parent OU containing the affected users had inheritance disabled. As a result, the Exchange Trusted Subsystem permissions weren’t being applied properly to the mailboxes inside it.

You might want to check the OU path where the impacted users are located (for example: dcg.dekalb.loc/State & Magistrate Court/State & Magistrate Court Users/Traffic Division). Then review the following:

Open the OU in Active Directory Users and Computers (Advanced Features enabled)
Go to Properties > Security > Advanced
Verify whether “Include inheritable permissions from this object’s parent” is checked

If inheritance is disabled, enable it on that OU (or its immediate parent) and allow permissions to propagate. In the case I saw, once inheritance was re-enabled on the OU, the mailbox operations completed successfully.

While you’re there, also quickly check the 16 user objects themselves for “adminCount=1” or the “Protect object from accidental deletion” checkbox, those are the other two common culprits for the final handful of mailboxes.

Please try the suggestion and let me know the outcome.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Jon Shaw 20 Reputation points

2026-04-28T10:56:30.4366667+00:00

Hi, thank you for your reply.

The parent OU has inheritance enabled. It is enabled up the OU's until the root of the domain.

Used: get-aduser -Filter {admincount -gt 0} -Properties adminCount -ResultSetSize $null | select name

And none of the 16 users are listed as having admincount greater than 0. The box is not ticked for accidental deletion.

Have checked all these many times yesterday sadly.

1 thing to add....I tried to remove-mailbox and that worked. Of course it deletes the user account so I restored it from the AD recycle bin straight away but strange it allows me to remove and not disable.

Any other ideas?

thank you
Gabriel-N 16,565 Reputation points Microsoft External Staff Moderator

2026-04-28T15:13:52.5466667+00:00
Hello Jon Shaw

Thank you for the detailed information you’ve shared.

Based on what you described, the behavior you’re seeing actually aligns with how these commands work. Disable-Mailbox needs to modify Exchange-related attributes on the user object, while Remove-Mailbox removes the mailbox entirely. If some of those attributes are protected or not writable, Disable-Mailbox can fail even though Remove-Mailbox succeeds.

In one similar case I came across, clearing Exchange-related attributes at the AD level helped resolve the issue. You might consider checking that as a possible direction.

If that doesn’t resolve the issue, you could try the following as a Domain Admin / Enterprise Admin and test in one account first:

# Test on ONE user first – replace with the actual sameAccountName $User = "problemuser" Set-ADUser -Identity $User -Clear ` legacyExchangeDN, mailNickname, msExchMailboxGuid, msExchHomeServerName, ` msExchRecipientTypeDetails, msExchRecipientDisplayType, msExchPoliciesIncluded, ` msExchMailboxSecurityDescriptor, msExchVersion, homeMDB, msExchUserAccountControl, ` proxyAddresses, mail, targetAddress Write-Host "Exchange attributes cleared for $User"

After running it, run Get-Mailbox $User (or just Get-Mailbox). The user should no longer appear in Exchange. If it works cleanly, you can turn this into a quick loop for all 16.

Alternatively, you may want to test at the object level for one affected user:

Open one affected user in AD Users and Computers (Advanced Features enabled) > Properties > Security > Advanced

Look for any explicit Deny entries (especially anything involving your admin account or “Exchange Trusted Subsystem”)

If you see any, remove them, then click Add > add Exchange Trusted Subsystem > grant Full Control > set Apply to “This object only”. Also click Restore defaults at the top of the Advanced window

Test Disable-Mailbox on that user afterward. If it now works, you can repeat (or script) the same for the rest.

Give the one-user test a try and let me know the result.
Jon Shaw 20 Reputation points

2026-04-28T16:49:27.99+00:00

Hi @Gabriel-N

That script worked, removing the attributes from the user object.

Thank you so much! I needed to get Exchanged decommissioned today and you've saved the day!

Thanks again

Jon
Gabriel-N 16,565 Reputation points Microsoft External Staff Moderator

2026-04-29T07:39:24.1166667+00:00

Hi Jon Shaw

I'm glad to hear that your issue has been resolved.

If possible, please consider marking my answer as accepted so it can serve as a helpful reference for others facing similar challenges. Your feedback also contributes to building a stronger and more supportive community.

Thank you for your understanding.

Share via

Exchange 2016 Decommission - Permission Issue

0 additional answers

Your answer