• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / Exchange 2007/2010 Public Folder Store in an Inconsistent State

Exchange 2007/2010 Public Folder Store in an Inconsistent State

April 30, 2011 by Paul Cunningham 9 Comments

In Exchange Server 2007 or 2010 you may encounter an error that the public folder store is corrupted and is in an inconsistent state.

The following warning(s) were reported while loading topology information:

get-PublicFolderDatabase
Completed

Warning:
Object EX2007PF1\EX2007PF1_SG1\Public Folder Store (EX2007PF1) has been corrupted and it is in an inconsistent state. The following validation errors have occurred:

Warning:
The item “fbd8a0c6-8083-4175-915c-6842e6408af6” in public folder referral does not reference an existing server.

In this particular case the problem was a server in the public folder referral list that no longer existed. This could be seen by inspecting the CustomReferralServerList attribute of the public folder database.

1
2
3
4
5
6
7
8
9
10
11
[PS] C:\>$list = (Get-PublicFolderDatabase -server EX2007pf1).customreferralserverlist
 
[PS] C:\>$list
 
ServerName          ServerGuid                         Cost Name
----------          ----------                         ---- ----
SYDEXPF1         3b1789ed-8d9b-43...                  10 SYDEXPF1:10
MELEXPF1          7521739a-6dc1-41...                  10 MELEXPF1:10
ADLEXPF1         5ce9557a-8e70-41...                  40 ADLEXPF1:40
                    fbd8a0c6-8083-41...                  90 {fbd8a0c6-8083-4...
EX2007PF2         8e074cb6-6170-46...                  25 EX2007PF2:25


Note the missing entry in the ServerName column above, though the ServerGuid, Cost, and Name were still populated.

But because the ServerName attribute was empty, removing the entry from the list could not be done by referencing it as the necessary pair of values (ie ServerName:Cost).

Fortunately PowerShell 2.0 makes it possible to remove an entry from an array by referencing it by number, using the RemoveAt method.

The first entry in an array is 0, so the fourth entry is 3.

1
[PS] C:\>$list.RemoveAt(3)


The array now has the invalid attribute removed.

1
2
3
4
5
6
7
8
[PS] C:\>$list
 
ServerName          ServerGuid                         Cost Name
----------          ----------                         ---- ----
SYDEXPF1         3b1789ed-8d9b-43...                  10 SYDEXPF1:10
MELEXPF1          7521739a-6dc1-41...                  10 MELEXPF1:10
ADLEXPF1         5ce9557a-8e70-41...                  40 ADLEXPF1:40
EX2007PF2         8e074cb6-6170-46...                  25 EX2007PF2:25


The final step is to update the public folder database with the new value.

1
[PS] C:\>Set-PublicFolderDatabase "EX2007PF1\Public Folder Store (EX2007PF1)" -CustomReferralServerList $list


This may take some time to replicate throughout your Active Directory, after which the public folder database should no longer report the inconsistent state.

Exchange Server EMS, Exchange 2007, Exchange 2010, Exchange Management Shell, PowerShell, Public Folders

Comments

  1. Aaron says

    September 28, 2017 at 9:54 pm

    Hi Paul, thanks for this great article. I am a bit confused about one section in your last code line:

    “EX2007PF1Public Folder Store (EX2007PF1)”

    I am not sure what to change this to in my environment. I see that the server name is referenced at the beginning but where do I acquire the rest?

    Reply
    • Paul Cunningham says

      September 28, 2017 at 10:32 pm

      Fixed now.

      Reply
  2. Matt says

    July 1, 2014 at 1:26 am

    I’ve just inherited an Exchange server that’s been reporting this error for months. The only entry in the referral list is the corrupt entry, is this safe to remove if it’s the only entry there?

    Reply
    • Paul Cunningham says

      July 1, 2014 at 10:30 pm

      A referral to a non-existent server/database should be safe to remove.

      Reply
  3. sunil says

    February 6, 2014 at 6:11 am

    Hi Paul

    Today I have found some of the public folders are corrupted and inconsistent state. Please guide me how to resolve this error.
    Exchange 2010 with Service Pack 3

    WARNING: Object domain.com/Microsoft Exchange System Objects/Bob Jones has been corrupted and it is in an inconsistent state. The following validation errors have occurred:

    WARNING: “Bob Jones” is not valid for Alias. Valid values are: Strings formed with characters from a to z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &,’, *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may be embedded in an alias, but each one of them should be preceded and followed by at least on of the other characters. Unicode characters from U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a best-fit US-ASCII string in the email address which is generated from such an alias”

    Reply
    • Paul Cunningham says

      February 6, 2014 at 8:08 pm

      You need to fix the invalid aliases.

      https://www.practical365.com/exchange-2010-fix-alias-script/

      Reply
      • sunil says

        February 7, 2014 at 12:38 am

        Thanks Paul

        Reply
  4. ayman says

    April 30, 2013 at 7:03 pm

    Please is there a way to from to remove from powershell ver1

    Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland