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.
Unable to create Public Folder proxy object for folder "<folder name>" in the Active Directory.
|English: Request a translation of the event description in plain English.|
|Concepts to understand:|
What is the role of the Microsoft Exchange Information Store service?
What is an Exchange public folder?
I had this error after someone started the MS Exchange Event Service by mistake, under Exchange 2000.
I used events.exe after stopping the service to clean up the ghosted exchange public folder. See article ME187523, which explains the command syntax.
As per Microsoft: "When a public folder is mail-enabled, the Microsoft Exchange Information Store service needs to create an object in Active Directory for that folder. Often, this message indicates a permissions error in Active Directory". See MSEX2K3DB for additional information about ths event.
This issue may occur if the Microsoft Exchange System Attendant service is not set to start under the local system account. See ME327841 for more details.
A public folder's rights became corrupted. The Public Folder (Alerts) was deleted and then recreated. After the object was recreated the mail properties were unavailable and this error started showing up in the event log. There was an instance of the Alerts in the Public Folder Instances in the First Storage Group that did not have a Folder Path association. I could not remove this object using EXSM. I fixed the AD record as follows.
1. Deleted the public folder.
2. Opened ASDI editor from the Windows 2000 Resource tools and found the AD object of the Public Folder. (LDAP://ad01.jaytown.org/CN=Alerts, CN=Microsoft Exchange System Objects, DC=jaytown, DC=org) Took ownership of the object in AD and then deleted the object.
3. After the object was deleted a new folder (Alerts) was created and this object’s Mail properties were accessible. The content of the original folder was restored and the rights were recreated.
Apply the latest Exchange Service Pack. From a newsgroup post: "When a public folder is mail enabled, the Web Storage System needs to create an object in Active Directory for that folder. Usually this message indicates a permissions error in Active Directory. Review the Event Viewer for messages from the system attendant."
Also from newsgroup posts: "If you try to pull up properties on the PF objects in ESM, do you get this error: The mail proxy for this folder can not be found. This may be due to replication delays. The mail enabled pages will not be shown. ID no: C1038a21 If so, are you running Win2k SP2? There was a fix for a problem that sounds a lot like this included in Win2k SP2. Alternately, ensure that your computer account is a member of the "Exchange Domain Servers" group in the Users container. In order for the RUS to process objects such as these PFs successfully, your computer account must be a member of this group, and the permissions for this group must be applied throughout the AD."
As per ME309793: "This behavior can occur if the display name of a public folder is longer than 255 characters. The system attendant can neither create a public folder proxy object nor truncate the name.". The article confirms that this is an issue with Exchange 2000.
ME318552 specifies that "These errors can occur when there is a disjoint namespace, where one or more child domains are not under the root domain in the forest.". The latest Exchange service pack should solve the issue.
From ME278441: "This problem can occur if the public folder has not been stamped with a proxy address (for example, pubfolder@ domain.com).". The Q article provides the workaround.
Tip #3 below fixed the problem for me. I don't know how the Remote Registry Service is tied into AD or E2k, or how it was set to manual, but starting the service and unmounting/remounting the public folders fixed a week long problem:
This problem can occur if the public folder has not been stamped with a proxy address (for example, pubfolder@<domain>.com). Here are some possible solutions:
1. Stop and restart each of the Exchange 2000 services. Restart the server. > Run Exchange 2000 Setup again with the /DomainPrep switch.
2. Apply Service Pack 2 for Exchange
3. Check to see that the Remote Registry Service is running on the Exchange 2000 server.
4. Rerun setup with /reinstall switch. Reapply latest service pack.
5. Reboot if prompted.
If the System Attendant service is started with an account other than the Local System account this can be the cause of event ID 9543. This event is generated when the Recipient Update Service cannot stamp email addresses on public/system folders. To resolve this issue, start the System Attendant service using the Local System account and rebuild/update the Recipient Update Service.
|Private comment: Subscribers only. See example of private comment|
|Links: ME187523, ME278441, ME309793, ME318552, ME327841, MSEX2K3DB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated