Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Source: MSExchange ADAccess|
|Maintenance: Recommended maintenance tasks for Exchange servers|
Process Microsoft.Exchange.RpcClientAccess.Service.exe (PID=2768). Object [CN=SMTP OutboundCN=ConnectionsCN=Exchange Routing Group (DWBGZMFD01QNBJR)CN=Routing GroupsCN=Exchange Administrative Group (FYDIBOHF23SPDLT)CN=Administrative GroupsCN=DOMAINCN=Microsoft ExchangeCN=ServicesCN=ConfigurationDC=domainDC=com]. Property [HomeMTA] is set to value [domain.com/Configuration/Deleted Objects/Microsoft MTA
DEL:d010ad07-b9c9-485b-9b45-165177948b94] it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.
|English: Request a translation of the event description in plain English.|
I got during a migration from SBS 2008 to SBS 2011. The "SBS ... Connector <SourceServer>" was not removed after uninstalling Exchange 2007 from the source server. The homeMTA Attribute of the Connector was updated though to point to the source server object now residing in Deleted Objects. I just removed the SBS something with companyweb <sourceserver> connector via adsiedit. No more errors so far.
I got this when the Exchange Organization was upgraded from 2003 through 2007 to 2010. It appears that the original RGCs from the 2003-2007 conversion were not (or were improperly) removed. It is not fixed yet.
From a support forum: "After further investigation i've learned that there are 2 ways to correct this issue:
1. Update-Recipient : Running the update-recipient cmdlet against an affected user should correct the issue. The logic for update-recipient has been updated to address the homeMTA scenarios. (update-recipient jsmith)
2. Move Mailbox : If you coincidentally plan on moving the affected mailboxes, this should correct the issue as well since update-recipient is automatically included at the end of move mailbox.
So, i'm guessing the obvious and more popular method is going to be update-recipient. In this case, you can use the cmdlet to run against users in bulk, for example:
This we get all mailboxes on DB1 and kickoff update-recipient against them.
get-mailbox -database "DB1" | update-recipient
Or, against all mailboxes in an OU:
get-mailbox -OrganizationalUnit "contoso.com/fabrikam.com Users" | Update-Recipient
Obviously there are many different and probably more creative ways to query for certain users and kick this off."
|Private comment: Subscribers only. See example of private comment|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated