Event 2937 is a warning from Exchange's directory access layer (ADAccess): an Exchange process read an object whose attribute still points to something that has been deleted from Active Directory. It usually appears after an old Exchange server is removed or an OU is deleted, and it repeats every time the object is read. In this post I'll show how to read the event, find every affected object in one pass, and fix each type safely.
Errors this guide fixes
Event ID 2937 (MSExchange ADAccess)Application log+1 more guideProperty [HomeMTA] is set to value [contoso.com/Configuration/Deleted Objects/Microsoft MTA DEL:<GUID>]Application log (event 2937)it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.Application log (event 2937)Property [RecipientContainer] is set to value [contoso.com/Deleted Objects/<OU> DEL:<GUID>]Application log (event 2937)Property [HomeMtaServerId] is set to value [contoso.com/Configuration/Deleted Objects/Microsoft MTA DEL:<GUID>]Application log (event 2937)
Symptoms#
Event ID 2937 (MSExchange ADAccess) warnings like this one appear in the Application log, repeating whenever the object is read:
Log Name: Application
Source: MSExchange ADAccess
Event ID: 2937
Task Category: Validation
Level: Warning
Description: Process w3wp.exe () (PID=4120). Object [CN=Jane Doe,OU=Staff,DC=contoso,DC=com]. Property [HomeMTA] is set to value [contoso.com/Configuration/Deleted Objects/Microsoft MTA DEL:<GUID>], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.The process changes with whichever component read the object: w3wp.exe when the user opens OWA, EdgeTransport.exe during routing, powershell.exe in the shell, and so on. The property tells you what to fix:
| Property in the event | Where it appears | What was deleted |
|---|---|---|
HomeMTA | Mailbox users, arbitration mailboxes (SystemMailbox{…}), users whose mailbox was removed long ago | The Microsoft MTA object of a removed Exchange server |
RecipientContainer | Dynamic distribution groups | The OU the group's filter was scoped to |
HomeMtaServerId | Connector objects, such as a legacy SMTP Connector for Internet Mail or a send connector that once listed the removed server | The Microsoft MTA object of the server the connector pointed to |
For a dynamic group or a connector, the property part of the description looks like this:
Property [RecipientContainer] is set to value [contoso.com/Deleted Objects/<OU> DEL:<GUID>]
Property [HomeMtaServerId] is set to value [contoso.com/Configuration/Deleted Objects/Microsoft MTA DEL:<GUID>]Why it happens#
Attributes such as homeMTA store a reference to another AD object. When that object is deleted, Active Directory doesn't clear the references that point to it, so the value now resolves to the deleted object in the Deleted Objects container (the DEL:<GUID> suffix is how AD renames deleted objects). ADAccess validates what it reads and logs 2937 when a value points there.
Each Exchange server has a Microsoft MTA object under its server object in the configuration partition, and it disappears with the server. Any recipient whose homeMTA still named that server, or any dynamic group scoped to a deleted OU, starts producing the warning. The object usually keeps working, but the noise buries real warnings and shows that the directory still references infrastructure that no longer exists.
How to fix it#
1. Find every affected object#
Fixing objects one event at a time is slow. On a server with the Active Directory PowerShell module:
Import-Module ActiveDirectory
$config = (Get-ADRootDSE).configurationNamingContext
$objects = @(Get-ADObject -LDAPFilter '(homeMTA=*)' -Properties homeMTA) +
@(Get-ADObject -LDAPFilter '(homeMTA=*)' -Properties homeMTA -SearchBase $config)
$objects | Where-Object { $_.homeMTA -like '*CN=Deleted Objects*' } |
Select-Object Name, ObjectClass, DistinguishedName | Export-Csv .\homeMTA-deleted.csv -NoTypeInformationIn a multi-domain forest, repeat the first query for each domain with -Server. For dynamic groups, use the Exchange Management Shell:
Get-DynamicDistributionGroup -ResultSize Unlimited |
Where-Object { $_.RecipientContainer -like '*Deleted Objects*' } | Format-Table Name, RecipientContainer2. Fix mailboxes with HomeMTA#
Get-Mailbox -Identity jdoe | Update-Recipient
(Get-ADUser jdoe -Properties homeMTA).homeMTAUpdate-Recipient stamps the Exchange attributes on a recipient again, and admins report that it resets HomeMTA to a valid value. If the value doesn't change (reported when msExchHomeServerName also names a removed server), move the mailbox, which stamps its home attributes again for the target database:
New-MoveRequest -Identity jdoe -TargetDatabase DB02Arbitration mailboxes are handled the same way: Get-Mailbox -Arbitration lists them, and they can be moved with New-MoveRequest like any other mailbox.
3. Fix dynamic distribution groups#
Set-DynamicDistributionGroup -Identity "All Sales" -RecipientContainer "contoso.com/Sales"
$g = Get-DynamicDistributionGroup "All Sales"
Get-Recipient -RecipientPreviewFilter $g.RecipientFilter -OrganizationalUnit $g.RecipientContainer -ResultSize Unlimited | Measure-ObjectPick the OU that now holds the people the group is meant to include, and check the member preview before you call it fixed.
4. Fix leftovers on objects without a mailbox#
Export the object first, so you can put the value back if needed:
ldifde -f jdoe-before.ldf -d "CN=Jane Doe,OU=Staff,DC=contoso,DC=com" -p base# No mailbox (no homeMDB): the stale value describes nothing, so remove it
Set-ADUser -Identity jdoe -Clear homeMTA
# A mailbox that step 2 didn't fix: copy the value from a healthy mailbox in the same database
$good = (Get-ADUser healthy.user -Properties homeMTA).homeMTA
Set-ADUser -Identity jdoe -Replace @{homeMTA = $good}ADSI Edit does the same job if you prefer a GUI: open the object, edit homeMTA, and paste a DN of the form CN=Microsoft MTA,CN=EX01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com.
5. Handle legacy configuration objects carefully#
HomeMtaServerId warnings come from connector objects: most often routing group connectors created by an Exchange version you have since removed, and, as admins report, send connectors that once listed a removed server. Admins also report that clearing the attribute in ADSI Edit fails with an error saying a required attribute is missing. If the connector is still needed, point it at a current server's Microsoft MTA DN in ADSI Edit. If it's an orphan, treat its removal as an AD change: export it, make sure you have a current AD backup, and remove it in a change window.
Watch out: don't "fix" 2937 by deleting the recipient or the Exchange server object. Change only the attribute named in the event, and keep the export.
Verify the fix#
- Run step 1 again: the CSV is empty and no dynamic group shows a
Deleted Objectscontainer. (Get-ADUser jdoe -Properties homeMTA).homeMTAnames a current server'sMicrosoft MTAobject, or is empty for a user without a mailbox.- Once AD has replicated and Exchange has had time to refresh its directory cache, this returns
0:
(Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MSExchange ADAccess'; Id=2937; StartTime=(Get-Date).AddHours(-2)} -ErrorAction SilentlyContinue | Measure-Object).CountPrevent it next time#
- Decommission servers with
Setup.exe /Mode:Uninstallafter moving everything off them, never by deleting objects; see uninstalling an old Exchange server. - Run the step 1 query after every server removal.
- Before deleting an OU, check whether any dynamic distribution group uses it as its
RecipientContainer.

