Lyle Epstein's Systems Engineer Blog

After migrating a SBS 2003 server to a SBS 2008, a good practice is to run not only the SBS 2008 BPA but also the Exchange 2007 BPA built into the Exchange Management Console. In this case, the SBS BPA revealed no issues, but Exchange did. In the Exchange BPA, it was showing

Site folder server deleted

The site-wide public folder database for administrative group ‘first administrative group’ has been deleted. Current public folder store: CN=Public Folder Store (OLDSBS03SERVER)\0ADEL:73d46e40-79b1-42c1-b3aa-535c97646ebd,CN=Deleted Objects,CN=Configuration,DC=domain,DC=local.

If you clicked on the link to tell you more about it, it would direct you to an article that was last updated in March 2006 that is for Exchange 2003. When I followed this article, the siteFolderServer attribute it indicated was wrong, was in this case correct at both locations. Further, the public folder store it was referencing was the old SBS 2003 /Exchange 2003 server.

So what happened? This issue occurs because the siteFolderServer attribute represents the Distinguished Name (DN) of the old Public Folder store, (i.e. the one on the old SBS 2003 server) which didn’t get replicated properly, in the scenario of migration from SBS 2003 to SBS 2008, the public folders replication occurs between source server and destination server, if there is any error in this process, the replication may fail and cause this issue.

Here’s how to fix it:

1. Open the ADSIEidt.msc and locate to CN=Configuration,DC=domain,DC=local > CN=Services > CN=Microsoft Exchange > CN=First Organization > CN=Administrative Groups.

2. Delete the CN=first administrative group (Kind of scary to delete this, but is not needed in a pure Exchange 2007 environment)

3. Restart the Exchange Information Store and the Exchange System Attendant. 

4. Now open up the Exchange Management Console and run the BPA to check the health again.

5. Now open up the Exchange Management Console and go to Server Configuration, Mailbox.

Do you now get the following error:

——————————————————–
Microsoft Exchange Warning
——————————————————–
The following warning(s) were reported while loading topology information:

get-PublicFolderDatabase
Completed

Warning:
Object SERVER\Second Storage Group\Public Folder Database has been corrupted and it is in an inconsistent state. The following validation errors have occurred:

Warning:
PublicFolderHierarchy is mandatory.

Warning:
PublicFolderHierarchy is mandatory.

——————————————————–
OK
——————————————————–

If so, read on, we have a few more things to do to bring this server back to a healthy state.

This error indicates the public folder database hierarchies have been corrupted and cannot retrieve the necessary information from the active directory, and the possible cause is the msExchOwningPFTree attribute has a null value so the EMC cannot retrieve the information from it.

1. Open up ADSIEidt.msc and locate to CN=Configuration,DC=domain,DC=local > CN=Services > CN=Microsoft Exchange > CN=First Organization > CN=Administrative Groups > CN=Exchange Administrative Group (FYDIBOHF23SPDLT) > CN=Servers > CN=Server > CN=InformationStore > CN=Second Storage Group.

2. Right-click the CN=Public Folder Database and select Properties, then find the msExchOwningPFTree, and check if the value is point to the correct DN, for example, in this case, it should be:
CN=Public Folders,CN=Folder Hierarchies,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange, CN=Services, CN=Configuration,DC=domain,DC=local

3. If the value is null or pointed to an incorrect DN, check if the Folder Hierarchies object is lost in AD. Chances are it is missing.

4. If the Folder Hierarchies object is present, go to CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange, CN=Services, CN=Configuration,DC=domain,DC=local, and check if CN=Folder Hierarchies object. Double-click CN=Public Folders and find the distinguishedName and copy the value then paste it to the msExchOwningPFTree according to above steps.

5. If the CN=Folder Hierarchies object is missing, follow the steps below to recreate it.

Re-create public folder hierarchy using the following steps:
====================
Create the "Folder Hierarchies" under the Exchange Administrative Group (FYDIBOHF23SPDLT)

a. Right click on Exchange Administrative Group (FYDIBOHF23SPDLT)
b. Select New Object
c. Select msExchPublicFolderTreeContainer for the class and click Next
d. Enter “Folder Hierarchies”, click Next
e. Click Finish

Create Public Folder Tree Object

a. Right click CN=Folder Hierarchies -> New Object
b. Select msExchPFTree for the class
c. For the value enter, "Public Folders" and click next
d. Click on the "More Attributes" button, select msExchPFTreeType and set the value to 1.
Note: This is very important that this value is set to a value of 1 as this tells Exchange that this is a MAPI Tree
e. Click Ok and then finish

Populate msExchOwningPFTree attribute object of the PF Stores in the organization

1. Get properties of the newly created "Public Folders" Tree object in ADSIEdit.
2. Copy the distinguishedname value to the clipboard and then click cancel.
3. Navigate to CN=Configuration,DC=domain,DC=local > CN=Services > CN=Microsoft Exchange > CN=First Organization > CN=Administrative Groups > CN=Exchange Administrative Group (FYDIBOHF23SPDLT) > CN=Servers > CN=Server > CN=InformationStore > CN=Second Storage Group. Right-click the CN=Public Folder Database and select Properties

4. Locate the msExchOwningPFTree attribute and paste in the value that was copied to the clipboard in step 2. Click OK.

5. Restart the Information Store Service.

If this is a SBS 2008 server, do the following:

Rerun the following wizards to fix the related settings.

1. Open the Windows SBS Console, re-run the Connect to the Internet and Setup your Internet Address.
2. After that, Navigate to Network > Connectivity.
3. In the Tasks pane, click “Fix my network” to check and fix any related networking issues.
4. Restart all Exchange services, including the Information Store and System Attendant service.

Now open up the Exchange Management Console and again, go to Server Configuration, Mailbox.

The stores should now be mounted and working correctly.

Ok, so you think we are done now and everything is fixed? In my case, I had two more errors in the Application log that needed to get fixed from this.

I had Event ID: 107 , MSExchange Search Indexer, with the following message:

Exchange Search Indexer has temporarily disabled indexing of the Mailbox Database First Storage Group\Database-new (GUID = adb30473-006a-4393-8156-1f2b45d2932b) due to an error (Microsoft.Mapi.MapiExceptionNetworkError: MapiExceptionNetworkError: Unable to read events. (hr=0x80040115, ec=-2147221227)

and

Event ID: 112, Microsoft Exchange OLEDB was unable to register OnSyncSave event for Schema propagation on MDB startup HRESULT = 0x8000ffff.

Well, these look pretty bad to me. The first error, Event ID 107, can  be safely ignored and Exchange Search will try to index the database when the store is back online or is mounted.

The second error indicates there is a duplicate system folder "schema-root" exists in Exchange, and the error is caused by removal of the first administrative group from ADSIEDIT.MSC in the beginning of this posting, but understand this issue is caused by Exchange 2003 not being decommissioned properly, thus resulting in multiple schema root folders in the System Folders of the Public Folders.

So for the second error, more steps need to correct this issue:

1. Generate a random GUID

a. Download GUID Generator from Microsoft Download Center
http://www.microsoft.com/downloads/details.aspx?FamilyID=94551f58-484f-4a8c-bb39-adb270833afc&displaylang=en
b. Extract the package and run guidgen.exe.
c. Select Registry Format and click Copy to get the GUID.
e.g. {50D52661-131C-47cf-9803-856F25DC790E}
d. Remove the brackets and hyphens in the GUID, separate every two characters with a space.
e.g. 50 D5 26 61 13 1C 47 cf 98 03 85 6F 25 DC 79 0E

2. Update the GUID of System Folders

a. Load ADSI Edit by running adsiedit.msc.
b. Expand nodes to locate the AD object CN=Configuration,DC=domain,DC=local > CN=Services > CN=Microsoft Exchange > CN=First Organization > CN=Administrative Groups.
c. On  the right pane, right click the CN=Exchange Administrative Group (FYDIBOHF23SPDLT) folder and select Properties.
d. On tab Attribute Editor, double-click attribute siteFolderGUID, paste the formatted GUID in step 1 to the textbox Value and click OK.

3. Restart Microsoft Exchange System Attendant service.

Now check your event logs. Mine are now clean!  I hope this helps others who run into this issue as I was unable to find appropriate answers on the net.

I came across this issue this weekend. According to Symantec, this seems to only affect SBS 2008 servers, but also could affect regular Exchange 2007 servers as well. Here is how to fix this issue:

 

To disable Exchange anti-spam agents:

1. Open the Exchange Management console.
2. Navigate to Organization Configuration -> Hub Transport in the console tree at the left hand side.
3. Click the Anti-spam tab.
4. Right click the Content Filtering Feature and select Disable
5. Repeat step 4 for each of the rest of agents in the Anti-spam view.

 

Source:http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2009102910285954