That event log entry:

Event ID: 16028
Source: MSExchangeTransportDelivery
Message: A forced configuration update for Microsoft.Exchange.Data.Directory.SystemConfiguration.MailboxTransportServer has successfully completed.

...means that Exchange 2013's Transport Delivery service has refreshed its configuration settings for the Mailbox Transport Server object in Active Directory.

Breakdown of what this actually means:

• MailboxTransportServer is an AD object that holds config data for the Mailbox Transport service (which receives mail from the Transport service and delivers it to mailbox databases).

  
  



• This service is part of the internal routing pipeline on the Mailbox role in Exchange 2013.

  
  



• A forced reload occurred - possibly due to:

  
  
  
  
  • An admin action (e.g., restarting services, changing connector settings, etc.)
  
  
  • A transport config change (e.g., certificate change, receive connector update)
  
  
  • AD replication catching up
  
  
  
  



• The "successfully completed" bit is the good news: it didn't crash, fail, or misapply anything.

  
  

Why this matters:

This event usually shows up when:

• You change send/receive connector settings


• You adjust transport rules


• You reconfigure DNS, certificates, or routing


• Exchange detects stale data and refreshes its local cache of AD config

It's a routine internal refresh, and the fact it was forced rather than notification-based just means the system wasn't waiting for AD to tell it to reload - it reloaded proactively.

Action Needed?

None - unless this event appears repeatedly alongside actual delivery problems (e.g., 451 PRX2, queue stalls).
In your case, it's likely related to the receive connector changes and mail routing fixes you've been applying.

Let me know if you're seeing delivery delays or repeated PRX errors still - this could be part of the transport layer catching up with the config churn.

Ah - that does fit the pattern.

The Event ID 16028 showing up alongside persistent PRX2 stalls strongly suggests that Exchange Transport services are constantly trying to reconfigure themselves, but can't fully stabilize due to unresolved connector or routing issues.

Reminder: What is 451 4.7.0 PRX2?

• PRX2 is a proxy error that occurs during SMTP handoff between Exchange servers.

  
  



• It usually means:

  
  

  
  

  "I (the frontend transport service) can't proxy this message to the backend transport or destination mailbox server."

  
  

  
  

Root Causes in Your Scenario:

1. Conflicting Receive Connectors:

   
   
   
   

   • If multiple connectors are listening on 0.0.0.0:25, particularly with overlapping remote IP ranges, proxying gets confused.

     
     
   
   

   • Use:

     
     

     Get-ReceiveConnector | ft Name,Bindings,RemoteIPRanges,AuthMechanism,PermissionGroups -AutoSize
     

     
     

     and verify no overlap across connectors on EX2013.

     
     
   
   
   
   



2. Mail flow misrouting from the old Exchange 2007:

   
   
   
   

   • If Exchange 2007 is still routing outbound mail or not fully decommissioned, it might queue messages meant for 2013.

     
     
   
   

   • Use:

     
     

     Get-Queue -Server ARG-EX1
     

     
     

     to see if 2007 is still holding mail destined for 2013 and whether it's retrying with PRX2.

     
     
   
   
   
   



3. Misconfigured Send Connectors:

   
   
   
   
   • Check if the send connector's source servers include both EX2007 and EX2013.
   
   
   • Ideally, only EX2013 should be listed now.
   
   
   
   

   Get-SendConnector | fl Name,SourceTransportServers,AddressSpaces
   

   
   



4. DNS or Autodiscover Caching:

   
   
   
   
   • If internal DNS still points clients or Exchange services at EX2007, you're going to keep seeing proxying failures.
   
   
   
   

Suggested Fixes:

1. Clean up the receive connector bindings

Use:

Get-ReceiveConnector -Server EX2013 | Set-ReceiveConnector -Bindings @{Add="0.0.0.0:2525"}

...for any non-default connector that conflicts with 0.0.0.0:25, then restart transport:

Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport

2. Redirect mail queues on Exchange 2007

If Exchange 2007 still has queues named 'Hub Version 15', that's EX2013.

Try forcing the route manually:

Retry-Queue -Server ARG-EX1 -Identity "EX2013\Submission" -Resubmit $true

3. Remove EX2007 from send connectors

Edit the send connector:

Set-SendConnector "YourConnectorName" -SourceTransportServers EX2013

Final Note

You may need to disable the "Default Frontend" receive connector on EX2013 temporarily, or rebind it to a non-conflicting IP to isolate the problem - then test with:

Test-Mailflow -TargetEmailAddress [email protected] -Verbose

Let me know what you get back from Get-ReceiveConnector and Get-SendConnector, and we can tune the config live. We're nearly there.

Yes - you absolutely should disable all Exchange 2007 send and receive connectors now that Exchange 2013 is handling SMTP traffic and mail flow. Here's why, and how to do it carefully:

Why Disable the 2007 Connectors?

1. Prevent PRX2 and Routing Conflicts
   Exchange 2007 might still be trying to proxy or route email to EX2013, resulting in 451 PRX2 errors, stalls, or mail loops.

   
   



2. Ensure All Services Are Flowing Through EX2013
   Leaving connectors active on EX2007 means Outlook, other servers, or external senders might still try to use it.

   
   



3. Avoid Confusing AutoDiscover or Client Connectivity
   Services like OWA or ActiveSync can get confused if both servers respond - especially if DNS still has any legacy references.

   
   

Step-by-Step: Disable 2007 Connectors Safely

1. Review Current Connectors on EX2007

Get-ReceiveConnector -Server ARG-EX1 | ft Name,Bindings,Enabled
Get-SendConnector | ft Name,SourceTransportServers,Enabled

2. Disable Receive Connectors

If you've confirmed mail no longer enters via EX2007:

Get-ReceiveConnector -Server ARG-EX1 | Disable-ReceiveConnector

You can be selective here, but if you're decommissioning EX2007 soon, just disable all.

3. Remove or Reassign Send Connectors

If EX2007 is still a source server on any send connector:

Set-SendConnector "YourConnectorName" -SourceTransportServers EX2013

Then:

Remove-ExchangeServer ARG-EX1 -RemoveLastServerInSite:$false

4. Restart Transport Services on EX2013 (Optional Cleanup Step)

Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport

5. Flush Mail Queues on EX2007

If mail is still queued:

Get-Queue -Server ARG-EX1
Retry-Queue -Server ARG-EX1 -Resubmit $true

Final Caution

DO NOT remove or uninstall EX2007 just yet if public folders or arbitration mailboxes are still present, or if you haven't verified all mailboxes and services are working 100% through EX2013.

Let me know if you'd like help verifying AutoDiscover, mail routing, or client access services - we can walk through a post-migration checklist. You're very close now.