Home » Exchange Server » Browsing Mailbox Databases in Exchange 2007 and 2010

Browsing Mailbox Databases in Exchange 2007 and 2010

A reader asks whether it is possible to browse through mailbox databases to view the details and statistics of the mailboxes they host on Exchange Server 2007 and 2010.  You might recall this was simple to achieve using the Exchange Server 2003 System Manager tools.

The nearest equivalent feature in the Exchange Management Console is using filters in the Recipient Configuration/Mailboxes section of the console.

However this feature does not expose mailbox statistics such as item count and total size.  For those types of details we can use the Exchange Management Shell instead.

For example, we can view the mailbox databases in the organization.

Or to look at the mailboxes within a given database we can pipe one shell command into another.

We can also look at statistics such as item count and total mailbox size of all mailboxes in a given database.

Alternatively, we can take a closer look at the mailbox statistics for one specific mailbox.

One of the common tasks that the Exchange Server 2003 System Manager was used for was exporting lists of mailbox users into CSV format for reporting in Excel. We can still achieve this in the Exchange Management Shell by exporting output to a CSV file.

The CSV output is formated correctly for easy import into Microsoft Excel.

As you can see although it may seem less intuitive than the previous method of browsing through a GUI the Exchange Management Shell actually makes it much simpler and easier to gather information about the mailboxes in your organization.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Scott K Swan says:

    Tried your method to create a .csv for excel, but it does not work for me (Server-W2K8R2, Exch 2010 – Workstation-WinXP Pro SP3, Excel 2007). I even copied and pasted your line, changing only the database number and the drive to write the file to. Below is a partial of what I get. Strangely enough, it works when I display it. This would be a useful tool for one of my reports, if I can get it to work.

    #TYPE Microsoft.PowerShell.Commands.Internal.Format.FormatStartData
    ClassId2e4f51ef21dd47e99d3c952918aff9cd pageHeaderEntry pageFooterEntry autosizeInfo shapeInfo groupingEntry
    033ecb2bc07a4d43b5ef94ed5a35d280 Microsoft.PowerShell.Commands.Internal.Format.TableHeaderInfo
    27c87ef9bbda4f709f6b4002fa4af63c <(followed by about 40 lines of that)

      • Scott K Swan says:

        No luck. Tried it letter-by-letter and space-by-space, and I still get the same results when I open the csv file. Everything works, but the “export” part of it. I will just use the display listing and go from there. That is still a big help.

        Thanks for your time and assistance.

      • Hi Scott, remove the format-table part of the command, it should work then.

        Get-MailboxDatabase “Mailbox Database 01” | Get-MailboxStatistics | Sort totalitemsize -desc | Export-Csv C:mailboxes.csv

        • Mishri Nishad says:

          This command will work in this way,

          Get-Mailbox -database “Mailbox Database 01″ | Get-MailboxStatistics | Sort totalitemsize -desc | Export-Csv C:mailboxes.csv

  2. dan says:

    “As you can see although it may seem less intuitive than the previous method of browsing through a GUI the Exchange Management Shell actually makes it much simpler and easier to gather information about the mailboxes in your organization”
    You’ve got to be kidding? We’re now back in the 1980’s days of DOS, CPM and UNIX shell scripting. MS is not helping the everyday SMB sys admin, we’ve really got other things to do than figuring out cryptic scripts.
    Nice work on the actual tutorial, well written and informative, keep it up. 🙂

    • Steve says:

      “We’re now back in the 1980′s days of DOS, CPM and UNIX shell scripting. MS is not helping the everyday SMB sys admin”

      You mean they’re not doing anything for the system admin who hasn’t learned anything since the ’80s.. The truth is, if you’re running a mail server for 50 people, you’re right – you might not get as much bang for the buck in learning Powershell, and a GUI is more your style, but then again, those small companies are probably migrating to GMAIL or Office365 and hiring a college student to manage it with the web GUI… If you’ve got a large enterprise of 25000 mailboxes, and you are tired of having to point and click at everything all day, and want to automate the mundane tasks, you’ll be MUCH BETTER OFF if you spend a day or so learning EXACTLY those commands described in this post, and learn to leverage them. There are SO MANY things you can do, from automating mailbox moves, doing reports, etc. that you could NEVER do in the old GUI. Besides – Microsoft has given a HUGE opening for someone to come behind (see Quest tools) to write a GUI front end management tool that would far exceed what Microsoft would have written in the first place.

      • Wayne says:

        I would politely and respectfully disagree. As a direct and immediately pertinent example, the output generated by the scripts above can produce so much chaff that in turn must be sifted through to arrive at a meaningful report, it makes the process cumbersome and tedious. In contrast, gleaning information from previous versions was as simple as taking a glance.
        Additionally, in the past there were much easier (aka quicker) ways of managing mailboxes and queues – provided as yet another example, it was much easier in earlier versions to free up a mailbox/queue by identifying and removing individual problems (e.g. incorrectly formed and/or corrupted emails).
        With each iteration of Exchange, we see less ease-of-use, and more scattered controls that don’t really help admins – they only seem to obfuscate and intentionally complicate day to day processes.
        I think for most admins, the opinion is that going back to CLI is definitely NOT an advantage for any product – it is a major step backwards, sorry.
        I will say however, that the work presented here is of great benefit for those of us who must endeavor to put up with these unfortunate changes.

        • Frankly Benson says:

          I’m one of those 80’s folks, so have always been very comfortable with scripting. I also have to disagree on Powershell being an advance. It is lousy! Syntax is not consistent. Commands are more likely to be “not recognized” than to actually work, because of the way modules are loaded in and out. Generating simple information requires piping so many different commands together it is ridiculous.

          Nice try by Microsoft, but they need to scrap it and start again. Take a hint old scripting languages to get it right. And while they are at it, why not keep the GUI full-functional and also provide solid scripting capability?

      • Amanda Byrne says:

        Yes, this is a huge back step, and just explains that much more how ineffective and inefficient Exchange has become. Seriously, displaying mailbox size is pretty basic. We are one of those smaller organizations that you say are “probably going to gmail”. We can’t because of some of the features in Exchange that we utilize. Quite frankly given the IT needs of our organization, I don’t have time to migrate OR learn Exchange Powershell GUI.

        It’s ludicrous for any product to come out with a new version that is more cumbersome, more resource-heavy, but less functional.

        • If features in Exchange are important to your business, but you also want less management overhead, then Office 365 is something you should take a serious look at.

          Other than that, I can only recommend looking at PowerShell as a tool to make your entire IT administration life more efficient (across all Microsoft products – Windows, Windows Server, Exchange, SQL, Lync, Active Directory, Azure, etc etc) and embrace it for the benefits it can provide to you, rather than reject it because of the initial learning curve.

        • Amanda Byrne says:

          It still doesn’t change that mailbox size is very basic, necessary information, and this is important functionality that was removed in a new version of the software.

          In my defense, my job IS mostly tackling learning curves, and I’m good at it. But you have to prioritize which learning curves to take on, and it really stinks when you have to tackle a new learning curve just to get functionality you had before.

          • In Exchange 2007/2010/2013 you can still open the properties of a mailbox and see the size info.

            I guess what you’re talking about here is that persistent view of the mailbox sizes when you’re viewing a list of mailboxes in Exchange 2003? Collecting that info adds load to servers. Anything that adds load decreases performance. When you’re talking about software that needs to run well at enormous scale then every minor performance hit you can mitigate is a good thing.

            So just as you need to prioritize things, so do software vendors. This is useful but minor functionality that is still available to us, just not in a way that is detrimental to server performance. We can always write ourselves scripts to save time typing out long-ish commands. Like this one:


  3. Julian Milano says:

    I agree with Dan. What? Can’t the Exchange GUI run the Powershell commands here to create an easily accessible data output?

    I have to now store all my scripts in text files and recall them when I need them then I have to modify the scripts and see what result I get.

    I do love the 80s, but……………………

    • Hi Julian, I’ve been running a lot of these scripts lately as I work on migration planning. Personally it doesn’t bother me, I like being able to kick off the script and find a nicely formatted CSV file at the end. I get it that not everyone sees it that way.

      The capability is probably there (though the exact steps are beyond me right now) to automate the process such that it collects this data on a scheduled basis and makes it available in a graphical report that you can look at when needed. I’m sure if you dug around some of the PowerShell dedicates blogs and websites you’d see some useful tips along those lines.

      • Steve says:

        Yep.. I’ve got 26000 users spread across 5 servers and 104 databases, and I get daily reports on user counts on each server, which servers are filling up, what mailboxes are new each day, how many users have excessive mail counts in the “critical” folders, when each database was last backed up, etc.. all through powershell, delivered to me in email daily. Powershell is AWESOME. You can even build GUIs in PS if you do need something interactive with pull-down menus and pushbuttons.

  4. Richard says:

    This works great! Worked the first time! I have different deparments on one database. After the export, I can sort by name, but I cannot get it to include the LDAP field “department”. This would help me GREATLY if I could export and sort by department to send out to the groups to clean up their mailboxes.


  5. Faisal Khan says:

    all worked first time! Nice article.

    How can we reduce the result set of get-mailboxstatistics command as you did with get-mailbox command useing resultsize. i just want to get only top 30 users e.g. and i have noticed that resultsize does not work with get-mailboxstatistics command.

  6. Joe says:

    Paul, I noticed in your one PS command that the output showed GB, MB and bytes in () witout using any expressions. The best I am able to do is @{expression={$_.totalitemsize.value.ToMB()};label=”Size(MB)”} which would show MB rounded off (no decimal). How did you achieve this?

  7. DK says:

    I get this error, can’t go any further

    PS C:\> Get-MailboxDatabase
    The term ‘Get-MailboxDatabase’ is not recognized as the name of a cmdlet, function, script file, or operable program. C
    heck the spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:20
    + Get-MailboxDatabase <<<<
    + CategoryInfo : ObjectNotFound: (Get-MailboxDatabase:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

  8. Mario Canchis says:

    Hei Paul

    I´ve got a few questions, which i would like to help me solving:

    Here windows 2k3 exc 2k7 sp1
    get-mailboxstatistics | ft displayname,lastlogontime,storagelimitstatus,servername,{$_.TotalItemSize.Value.ToMB()}

    How can i add the PrimarySmtpAddress to be listed using the ps?
    Besides when export to a txt file; i get the short view, i mean dislpay name: Mario Can…. but not full field for any (storagelimitsstatus servername lastlogontime..etc)

    I would like to use “| Export-Csv c:test.csv” using the command shown before does not work; but it does in the next command

    Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,ServerName,PrimarySmtpAddress, @{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | Export-Csv c:mailbox_alias1.csv

    Thanks for any advice you can give and specially for your time.


  9. Tim says:

    Hi Paul, this is the perfect article to get me familiar with the Exchange Powershell and getting some useful info from my Exchange DB. I came here because a user was getting an auto generated e-mail stating that his mailbox was “almost full” and gave him a maximum and current size. I have bought some time by asking him to remove large attachments to e-mails but I am rather stumped by my output csv with the three database quota columns saying unlimited….so what is generating the message?


    • The quota settings on the database will be inherited by any mailbox in that database that is set to inherit quota settings.

      A mailbox can be configured with it’s own quota settings, that override those set on the database.

      So in your case you should look at the properties of the mailbox itself, and examine the storage quotas that are configured for that specific mailbox.

  10. Danny says:

    Great article, thanks, I was looking through your site and have not seen articles outlining how to take this Exchange PS script and make it a re-occuring time process. Can you please point me to an article? Thank you.

  11. Mohammed Ahmed says:


    Firstly I would like to mention that I am a BIG FAN

    Secondly, you have changed the way I Google issues or information (I am always adding up “PAUL CUNNINGHAM” at the end of any Exchange Server related Search)

    Thank You 🙂

  12. Abhishek Gupta says:


    Above ItemCount and ItemSize include hidden NON_IPM_DATA mesages count .
    How can exclude hidden NON_IPM_DATA mesages from ItemCount .
    While We run Get-MailboxStatistisc & Get-MailboxFolderStatistics.

    Please give me a solution . Its urgent Which is required for my current project.

  13. LoneWolf says:

    Is there a way to perform mailbox browsing (or better yet, multi-mailbox searching) on a recovery database versus the live mailbox database?

  14. Proxy-SI- says:

    To those “NEW” IT Admin’s/Technicians out there who complain about Powershell and having to take on a new learning curve please shut up and stop complaining.

    After 10 years i can honestly say i have not stopped taking on new challenges, learning new technologies, new tools that make my life easier. Before Powershell and EXCHANGE i was using Oracle Solaris and a simple mail server which has pop, imap and smtp. Everything was done via a CLI. I still prefer this as it has more functionality, more options than these GUI products contain.

    Serious the new generation of IT are like script kiddies out there whom need someone to code the program in a way they can do everything in 1 or 2 clicks of the mouse. Embarassing.

    This script works very well actually;
    I have found that:

    Get-MailboxDatabase | Get-MailboxStatistics | Sort totalitemsize -desc | Export-CSV C:mailboxes.csv

    Works Quite Well for those whom need to create some report for their higher up or senior in regards to mailbox size management. It works in Exchange 2010 SP1, 2, and 3. Works in Server 2012 R2 as well as previous 2012 and 2008 R2. If you can’t get this command to work your exchange server has more problems than you can imagine and maybe you should be looking in eventvwr or any other tools you have for monitoring and managing the server.

    Just wanted to write this up because every time i enter a forum where someone posts a working script there are a bunch of amateur IT folks who try to claim it doesn’t work for them. It isn’t the script, its the person who doesn’t know what they are doing but decide to do it anyways not knowing the consequences, these are the SAME IT Folks who reduce the number of permanent position jobs out there because they *FUCK* up the previous job so the employer does contract work only thereafter.

    Thank you,

    (IRC User – Botnet 50K Class approaching 75K – Well known IT Administrator in Toronto)

  15. Sérgio Tivane says:

    Hi Paul,

    Thanks very much for your priceless support, you´re a star!

    Your articles never let me down.

    Keep it up sharing your valuable knowledge.


  16. Frankly Benson says:

    Didn’t work. Not sure if Microsoft changed something or if it is one of those (many) PowerShell is screwed up things. But my output for the Get-MailboxStatistics only shows item count. It does not show database size as your example output. The only way I see to get the actual size is Get-MailboxStatistics -identity ” | fl.

    Boooo for PowerShell. Sorry, just how I feel.

Leave a Reply

Your email address will not be published. Required fields are marked *