In the example in Figure 1 below, you can see that I’ve navigated my way down to the First Storage Group on the server DCEXCH1.įigure 1: Public Store Location Using ADSIEdit With the ADSIEdit snap-in open, right-click ADSI Edit and choose the Connect to… option. In the resulting Connection Settings window, ensure that the naming context is set to Configuration and then click OK. This will then bind to the configuration naming context allowing you to navigate your way down to the public information store. You will therefore need to work your way down the tree accordingly:
MICROSOFT EXCHANGE PUBLIC FOLDER UPDATE
The first area to check when troubleshooting any public folder replication issues is the status of the hierarchy. For example, let’s say that you’ve installed a new Exchange server into an existing Exchange organization and you suspect that this new server has not been sent a copy of the hierarchy. In this case, the first thing you need to check is whether the public information store on the new server is correctly configured with an email address. Both public folder hierarchy and content changes are sent between Exchange servers via email messages, so it therefore follows that if the public information stores email each other, they’ll need an email address as well as a working email path between them. It’s the job of the Recipient Update Service (RUS) to ensure that objects are stamped with correct email addresses, and this includes the public information store. The first thing you should therefore check is the public information store’s email address which can be performed with ADSIEdit. You’ll find that ADSIEdit is installed as part of the Windows 2003 Support Tools. There are two main elements regarding public folders, namely the hierarchy and the content. To put it a basic way, the public folder structure that you see in Outlook is the hierarchy, whilst what’s actually stored in those folders is the content. Well, that’s fairly straightforward, so let’s get a bit more in-depth.