{"id":11501,"date":"2012-01-12T00:01:00","date_gmt":"2012-01-12T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2012\/01\/12\/use-powershell-to-troubleshoot-exchange-server-public-folders\/"},"modified":"2012-01-12T00:01:00","modified_gmt":"2012-01-12T00:01:00","slug":"use-powershell-to-troubleshoot-exchange-server-public-folders","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-powershell-to-troubleshoot-exchange-server-public-folders\/","title":{"rendered":"Use PowerShell to Troubleshoot Exchange Server Public Folders"},"content":{"rendered":"

Summary<\/b>: Microsoft PFE, Seth Brandes, discusses using Windows PowerShell to troubleshoot a customer problem with Exchange Server public folders.\nMicrosoft Scripting Guy, Ed Wilson, is here. Today we are happy to have Seth Brandes as our guest blogger.<\/p>\n

Seth Brandes is a premier field engineer who works in Microsoft Services. He began his foray into programming as a young lad punching the keys in BASIC on a Tandy TRS-80 back in the late 80s, and he gradually progressed through Pascal, VisualBasic, and C\/C++\/C#. He has most recently latched on to Windows PowerShell v2. He currently specializes in the Microsoft Exchange Server platform, providing Microsoft premier customers in the midwest guidance and support. He is currently gearing up his blog site and hopes to have it online in the near future.\nTake it away Seth…\nI was attending an internal Microsoft event a couple months ago, and one of my peers introduced me to Ed Wilson, THE Scripting Guy. Yes, I did get an autograph! He extended an invitation to me to write a guest blog illustrating an Windows PowerShell example related to Exchange Server, and needless to say, I could not refuse.\nRecently I had an interesting inquiry posed by one of my customers regarding an apparent inconsistency with the Get-PublicFolderStatistics<\/b> cmdlet in their Exchange Servedr 2010 environment. They had users calling their Help Desk complaining that certain public folders appeared empty of all content. Running the Get-PublicFolderStatistics<\/b> cmdlet against the folders in the Exchange Management Shell returned non-zero metrics as if there was content present! I directed them to run the cmdlet with the -server<\/b> switch against each server that contained replicas of the affected folder. They found discrepancies between the replicas because some were lacking content. We tied it back to a 2003 to 2010 routing group connector outage when they were migrating public folders. They updated the replicas and were placated. Great. Problem solved. Or so I thought… \nShortly after we wrapped that up, they had recurrences of the issue in several other folders. Therefore, they wanted a repeatable method that they could easily invoke to determine which folders had “mismatched” replica content in their hierarchy. I promptly informed them they already had a great monitoring system, the best ever designed in fact: the end user. \nThat didn’t go over so well; so, I thought this would be a great opportunity to create a simple little script sample in Windows PowerShell that can display replica metrics for any folder (or folder tree) to determine if any replicas have mismatched metrics. Note that any high-volume folder will likely have slightly off numbers when comparing replicas because source data needs a little time to get to replica copies—even under the best of circumstances. This script should be a piece of cake. \nI didn’t realize at the onset just how big the cake was going to be and what flavor. But I managed to cobble together a working script sample. Is it the best approach ever? Don’t know, probably not. Did I learn some things I didn’t know before? Sure. Is it a decent enough script to point out and review some cool Windows PowerShell concepts? I would say, “Yes.” Therefore, I decided to write this blog.\nBecause I had a preconceived picture about how I wanted the output to look, I started by sketching a visual output of the content on the whiteboard, thinking to myself that this should be doable. I envisioned a table with each row containing the folder and the item count of each replica, where the server names of the replicas would be the columns. Easy right? Let us get a mockup of how this should<\/i> look according to my imagination. This mockup is shown in the following table.<\/p>\n

Folder Path      Replica1  Replica2   ReplicaX<\/p>\n

———–      ——–  ——–   ——–<\/p>\n

Level1Sub1               2      2<\/p>\n

Level1Sub1SubSub1           3      3<\/p>\n

Level2           68\nNot too shabby. It’s pretty much a formatted table output. Let us get that filed away—check.\nNext, I wrote a brief outline of the overall flow:<\/p>\n

    \n
  1. Obtain folder as input so I know what to look for.
    Wait…do I want to get all fancy and do recursion to look at a portion of the tree hierarchy too?  Umm…sure, but let’s leave it up to user to decide.<\/li>\n
  2. Obtain input as whether or not to recurse. I mean, really, who doesn’t curse, recurse, and recurse again public folders? Seriously.<\/li>\n
  3. Grab the properties of the folder(s) in the folder list.<\/li>\n
  4. Because we are interested in only a couple of folder properties, we’ll specifically target the folder path, a unique identifier of the folder, and the list of replicas.<\/li>\n
  5. For each replica, call the Get-PublicFolderStatistics<\/b> cmdlet to obtain the item count metric…<\/li>\n<\/ol>\n

    DOH! This won’t work for replicas that are homed on Exchange Server 2003. What to do, what to do? The usual suspects for getting at 2003 are DAV, CDO, or WMI. I don’t really know DAV or CDO programming, and I know there are built in WMI-based cmdlets in Windows PowerShell, so I’ll give WMI a whirl. Let’s rewrite the logic for step 5:<\/p>\n

    5. For each replica, determine if is being hosted on a server running Exchange Server 2003 or on a server running Exchange Server 2007 or Exchange Server 2010. If it is 2003, make a WMI query via the Get-WMIObject<\/b> cmdlet to the server to obtain the item count, else use the Get-PublicFolderStatistics<\/b> cmdlet to obtain the item count. Store the results somewhere. Where? How? Why? Patience my young Padawan, patience. We’ll get to it.
    6. Rinse and repeat for each folder (ala steps 4-5).
    7. When all the information has been gathered and stored in a meaningful place, spit out the output as described earlier.
    8. Exit chair, open fridge, grab a cold drink.\n Eight steps ain’t so bad—especially step 8! Let’s get coding!!! Here is the opening to the script:<\/p>\n

    #get our input variables from the command line<\/p>\n

    Param(<\/p>\n

      #full PF path<\/p>\n

      [Parameter(Mandatory=$true)]<\/p>\n

      [ValidateNOtNullOrEmpty()]<\/p>\n

      [string] $Path,<\/p>\n

      #do we recurse?<\/p>\n

      [switch] $Recurse<\/p>\n

      )\nWe start by defining the input parameters of the script. The first is the folder path that will be stored as a string, and because we can’t do anything without it, we throw in a parameter on the parameter (er, pun intended?) to make it mandatory, along with a function to ensure it is not a null value. The second is the recurse<\/b> switch, which when defined with the type [switch], does not include a value; rather its presence alone is enough to use in a Boolean manner. So far, so good. Now add a bit of logic…<\/p>\n

    if($recurse) #recurse was requested, get the folder and all of its descendants<\/p>\n

      {<\/p>\n

      $pfCollection = Get-PublicFolder $Path -ErrorAction silentlycontinue -recurse | Select identity,replicas,@{Name=”LegPFDN”; Expression = {$_.identity.legacyDistinguishedName}}<\/p>\n

      }<\/p>\n

    else #recurse was not requested, get only the folder defined<\/p>\n

      {<\/p>\n

      $pfCollection = Get-PublicFolder $Path -ErrorAction silentlycontinue | Select identity,replicas,@{Name=”LegPFDN”; Expression = {$_.identity.legacyDistinguishedName}}<\/p>\n

      }<\/p>\n

    if(!$pfcollection) #validate a folder path was actually found, if not exit the script<\/p>\n

      {<\/p>\n

      Write-Host “ERROR! Could not find folder path: $path”<\/p>\n

      Write-Host “Please use a valid folder path.”<\/p>\n

      exit<\/p>\n

      } \nIn the previous code, we are doing three things:<\/p>\n

      \n
    1. Validating whether or not the user specified to use recursion.<\/li>\n
    2. Grabbing the properties that interest us about the folder(s) in question via the Get-PublicFolder<\/b> cmdlet.<\/li>\n
    3. Validating that we actually found at least the root folder specified—else, what’s the point right? Note that we are suppressing error output because we don’t care if the command fails to find a folder. We do our own validation after the fact, and keep the output nice and clean.<\/li>\n<\/ol>\n

      Note that we are grabbing three properties specifically:<\/p>\n

        \n
      1. Identity<\/b>. This is the full name of the folder including the folder path. This is useful for our final output later. Stay tuned.<\/li>\n
      2. Replicas<\/b>. This is a collection of one or more replicas, which we will use shortly to figure out which server they are on to use in querying for its replica’s item count stats\/metrics. Again, stay tuned.<\/li>\n
      3. LegPFDN<\/b>. Wha??? Huh?<\/li>\n<\/ol>\n

        That’s not a property of Get-PublicFolder<\/b>! Here we are actually grabbing the LegacyDistinguishedName<\/b> of the public folder, but because that’s a lot to type (and more importantly, I’m lazy), I elected to “rename” it to LegPFDN<\/b> by using a simple hash table definition to assign a custom “name” for our purposes. I love this technique because it can be used in so many places and the expression can include calculated values. So cool!\nAnywho…it’s important to note that the results will include the property name of LegPFDN<\/b> and not LegacyDistinguishedName<\/b>. Got it? Good. I know your burning to know why this specific property—read on and find out my friend, read on…\nBefore we continue with the code, let’s take a quick timeout to explain my chosen data storage methodology. I burned many a brain cell trying to figure out a cool, but useful, way to store the results in a manner that would be easy to manipulate the output that I envisioned and described up above. I decided to store all the replica item counts of a given folder into a custom object, aka record. Each “folder” record would contain the following properties:<\/p>\n