Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 8231 Source: MSExchangeAL

Source
Level
Description
Permanent failure reported by policy group provider for 'CN=Recipient Policies,CN=Name,CN=MicrosoftExchange,CN=Services,CN=Configuration,DC=Name,DC=com':'MAD.EXE', error=8000ffff. Taking provider offline.
Comments
 
Please see Event ID 8247 from MSExchangeAL.
This occurred after a PDC had died and was rebuilt, not restored. When it was dcpromoed, it was never re-enabled as a Global Catalogue Server. This meant there was no GC present in the domain (2 DCs). After I enabled one of the servers as a GC, the services started.
- Error code: 8007203a - This occurred on a newly added Exchange server after decommissioning an old one in the same organization. Before that, the Recipient Update Service that was running on the old server was moved to the new one. The events started to appear right after moving RUS. In our case, the problem was that DNS resolution was not configured to add local domain names when looking for hosts.
In my case, the problem was related to a third party Fax application, FACSys. Following KB article ME286356 and also removing the entries for FACSys from the "Address Types" container solved the problem.
- Error code: 8000ffff - As per Microsoft: "This issue may occur if a member computer on the local domain has the same name as a computer on the remote domain. That is, the Computers section in Active Directory Users and Computers on the local domain has a computer with the same name as a computer in the Domain Controllers section of Active Directory Users and Computers on the remote domain. To resolve this issue, identify and rename the member computer on the local domain that has the same name as a computer on the remote domain". See ME867660 and ME275294 for more details on this issue.

As per Microsoft: "MSExchangeAL event 8231 indicates that problems were encountered when implementing Recipient Policies in an Exchange 2000 environment. The related events (2027, 2037, 8247, etc.) in the application log will indicate the underlying cause of the problems". See MSEX2K3DB for more details on this event.

From a newsgroup post: "In our case, the DNS SRV records were not all present due to miss-configured NIC on the DC. I reconfigured the NIC on the DC, reregistered DNS, and then everything was OK".


I had this error after adding a new RUS for a child domain and excluding "users with external email addresses" from the Recipient Policy. Adding "users with external email addresses" back into the Recipient Policy resolved it.
Error 8000ffff = "Catastrophic failure error" - ME286356 gave us a hint how to solve the problem. In our case it was Zetafax, a program for sending faxes with a plug-in for Exchange.
Error 80040103 = "MAPI_E_BAD_CHARWIDTH" - no additional info
Error 80040103 - This occurred after adding a new, and demoting an old DC. It seems that the Recipient Update service in the System Manager failed to redirect itself to the new DC and the old DC did not remove itself from DNS in gc._msdcs as a Global Catalog. As a result, Exchange can't connect to the LDAP for the address lists (try to preview them and it will fail) and therefore won't update AD with any subsequent changes to the directory.
Fix:  Re-promote the old DC, goto the Exchange System Manager and manually change the RUS connector to point to the new DC. Then go into the gc._msdcs folder in DNS and manually change all references from the old DC to the new DC.
I like to reboot everything after these steps and after the reboot these errors should no longer appear, you will be able to preview the address lists, etc...
Error 8000ffff = ""Catastrophic failure" - See ME294222, this issue can occur if Domain Name System (DNS) name resolution between the Exchange 2000 server that is running the Recipient Update Service and the target domain controller that is in the remote domain is malfunctioning. Or this can happen if the Short Name for the remote domain DC is not resolvable, even if the FQDN is able to be resolved. The Recipient Update Service may not be able to process users in the remote Windows 2000 domain. See also Error code 8000ffff.
Got this error when our exchange server was unable to create a connection to AD and as a result was unable to start up information store. Checked the recipient update service and found that the domain contoller we has assaigned was not in the browse list so choose our bdc and was able to get exchange back up.
I discovered three articles which may help to resolve this issue. The problem encountered on our Exchange server was due to a misconfigured x400 address space in the recipient policy. The articles are as follows: ME294222, ME286356 and ME274301.

Windows Event Log Analysis Splunk App

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.

Read more...

 

Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.

Read more...