From the MS Exchange Team blog:

It’s been a long road, but the initial release of the Exchange 2013 Server Role Requirements Calculator is here. No, that isn’t a mistake, the calculator has been rebranded. Yes, this is no longer a Mailbox server role calculator; this calculator includes recommendations on sizing Client Access servers too!

I recommend reading the rest of that post because it does outline some very interesting things about Exchange 2013 sizing.

Download the calculator here.

This article Exchange 2013 Server Role Requirements Calculator is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

If you take a look at the properties of a Send Connector you will notice an option to proxy through a Client Access server.

When this option is enabled outbound email that is being sent via a Send Connector does not go directly out from the Mailbox server, and instead is proxied through a Client Access server in the site.

There is nothing complicated going on here, the Client Access server simply acts as a proxy for the connection so that the receiving host out on the internet sees the connection as coming from the Client Access server name and IP address rather than the Mailbox server.

To demonstrate, here is a message header for an email sent without the proxy option enabled.

Notice that in hop 2 the message is received by E15MB1, and then in hop 3 you can see E15MB1 send to mx.google.com. In other words, it was send directly without proxying.

And here is a message header for an email sent with the proxy option enabled. Note the extra hop before the email goes out to the Google mail servers.

Notice the subtle difference. In hop 2 the message is received by E15MB3, but then in hop 3 the message is being sent from E15MB1 to mx.google.com. E15MB3 has silently proxied the message through the Client Access server role on E15MB1.

This option is likely to be more useful for organizations that do not use a smart host or Edge Transport server for outbound email routing, and want to control where outbound SMTP connections are coming from. A justification for this would be to simplify the firewall rules.

Personally I don’t expect to see this option used much in small environments, however it could certainly be useful in some larger organizations.

This article Proxying Outbound Email Through Exchange 2013 Client Access Servers is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

This version includes a number of important bug fixes, as well as adding the DAG health check (from Get-DAGHealth.ps1).

You can download the new version here.

Please continue to report bugs and make feature requests in the comments on that post.

This article Test-ExchangeServerHealth.ps1 v1.2 Released is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Send Connectors are not configured by default when you first install Exchange Server 2013. If the Exchange 2013 server is installed in an existing organization then other Send Connectors may already exist that facilitate outbound mail flow. Otherwise, you will need to create at least one Send Connector yourself.

Most organizations will be dealing with one of the following outbound email flow scenarios:

• email sent directly over the internet to the recipient’s server
• email sent to the internet via a smart host

Sending directly over the internet vs sending via a smart host

There are other scenarios as well, such as:

• email sent outbound via an Edge Transport server
• email sent directly to a partner organization using TLS encryption

An organization can have one, two, or several Send Connectors to provide the specific email routing that they need.

For this article we’ll focus on the first two scenarios, as they are the most common; sending directly to the internet, and sending via a smart host. We’ll also cover testing and troubleshooting a Send Connector, and some more advanced configuration options.

Configuring Outbound Mail Flow Direct to the Internet

Configuring your Exchange 2013 organization to send means that your Exchange server will look up the MX records for the recipient’s email address, and then use those MX records as the IP address(es) to connect to via SMTP.

Looking up MX records means your server will be relying on DNS. If the server’s TCP/IP settings are configured for DNS servers inside your network that can’t resolve external names, then you can configure Exchange to use different DNS servers for external lookups.

To create the Send Connector for sending outbound email directly to the internet open the Exchange Admin Center and navigate to Mail Flow -> Send Connectors.

Click the + button to create a new Send Connector.

Give the connector a name and set the type to Internet. Click Next to continue.

Leave the network settings set to MX record. If you needed to configure specific external DNS servers you should also tick the box, but if your Exchange server can already resolve external DNS names then that should not be required. Click Next to continue.

Click the + button to add a new address space. Specify the FQDN of * (the wildcard character that effectively means “anything”). The cost can remain at the default setting of 1 if this is the only send connector for your organization. Click Save and then click Next to continue.

Click the + button to add the source servers for the connector. These are the servers that will be responsible for routing email out from your organization to the internet. Multiple servers will provide redundancy for outbound mail flow. Click OK and then click Finish.

The send connector is now visible in the Exchange Admin Center.

For further configuration and tested steps refer to the last section of this article.

Configuring Outbound Mail Flow via a Smart Host

Configuring a Send Connector to send outbound internet email via a smart host is the same process as above, with the following differences.

First, the network setting is configured to Route mail through smart hosts instead of MX records. You must then click the + button to add at least one smart host name or IP address. Multiple smart hosts are permitted and are recommended for redundancy.

When you choose to use a smart host you also get the option to configure authentication for the Send Connector. This is only necessary if the smart host requires it. Many email security servers/appliances or even hosted solutions will simply authenticate you based on your IP address rather than require other credentials.

Testing a New Send Connector

The obvious way to test a new send connector is to send an email from inside the organization to an external recipient.

When the message is received in the external mailbox you can then take the message headers and use the MXToolbox header analyzer or the ExRCA Message Analyzer to inspect the headers and confirm that the email passed through the source servers you were expecting it to for that outbound route.

If the email does not arrive you can inspect the transport queues on your Exchange servers for stuck email.

[PS] C:\>Get-TransportService | get-queue

Identity                   DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
--------                   ------------ ------ ------------ -------- --------- -------------- -------------
E15MB1\22206               SmtpDeliv... Ready  0            0        Normal    0              mailbox database 1
E15MB1\Submission          Undefined    Ready  0            0        Normal    0              Submission
E15MB1\Shadow\22204        ShadowRed... Ready  0            0        Normal    0              e15mb3.exchange2013dem...
E15MB2\22750               SmtpDeliv... Ready  0            0        Normal    0              mailbox database 2
E15MB2\Submission          Undefined    Ready  0            0        Normal    0              Submission
E15MB2\Shadow\22748        ShadowRed... Ready  0            0        Normal    0              e15mb1.exchange2013dem...
E15MB3\Submission          Undefined    Ready  0            0        Normal    0              Submission
E15MB3\Shadow\16452        ShadowRed... Ready  1            0        Normal    0              e15mb1.exchange2013dem...
E15MB3\Shadow\16456        ShadowRed... Ready  1            0        Normal    0              e15mb2.exchange2013dem...

To look more closely at the messages stuck in a single queue you can use Get-Queue and Get-Message together.

[PS] C:\>Get-Queue E15MB1\22206 | Get-Message | ft

If the properties of the stuck messages do not reveal the problem then another valuable source of troubleshooting information is the protocol logs. For more tips refer to the following article:

• Troubleshooting Email Delivery with Exchange Server Protocol Logging
  

Further Configuration Options for Send Connectors

Some additional configuration options you can explore are:

• Proxying email through Front End/Client Access Servers
• Configuring protocol logging for Exchange 2013
• Configuring outbound message size limits for Exchange 2013
• Configuring the FQDN for HELO/EHLO on a send connector

This article Configuring Outbound Mail Flow in Exchange Server 2013 is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2013 will not allow you to disable/unassign an SSL certificate from a service that requires SSL. Instead, you should enable another SSL certificate to that service, which will automatically disable the existing one for you (for that specific service, not necessarily all services).

This article Checkboxes Greyed Out When Managing Services for an Exchange 2013 SSL Certificate is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

“Warning: Please restart the Microsoft Exchange Information Store service on server E15MB1 after adding new mailbox databases.”

This warning can occur on mailbox servers that are members of a database availability group, as well as standalone mailbox servers.

Despite the warning the new database will mount and be available to host and serve mailbox data.

The warning did not appear in Exchange 2013 RTM, although the reasons for the warning were present in RTM.

To help you understand this warning here is a slide from the Exchange Server 2013 Architecture Deep Dive session at TechEd Australia 2012.

Note in particular that last bullet point:

“Restart service process when adding/removing copies…”

As Scott Schnoll explains in the presentation, in previous versions of Exchange the entire ESE cache would be allocated to the Information Store (store.exe) process.

In Exchange 2013 a change was made so that each individual database now runs as a separate worker process, and therefore each worker process has their own ESE cache.

The server needs a way to allocate each worker process a share of the available memory for ESE cache. The factors for this allocation are:

• the amount of memory that the server has
• the number of databases on the server
• whether those databases are active or passive

Scott also makes the point in the video that this applies when you make significant changes to your database layout. This may mean that the implications for adding a single database are not that serious, hence the warning rather than a hard error.

However, this is a new operational challenge for Exchange administrators so the best practice for this has yet to be established. At face value it appears that database creation is no longer an “anytime” activity with no impact.

To quote Scott from that session recording:

“Hopefully that is something that will change at a later date…”

So what to do about it? We know the warning is valid, so if we assume that the implications for not taking the advice are serious then we have to restart the service.

Standalone Mailbox Servers – there is no alternative but to restart the Information Store service during an arranged outage window.

Database Availability Group Members – after adding a new database and configuring the desired database copies, a series of rolling restarts of the Information Store services across each DAG member would then be required, putting each server into maintenance mode then taking it out of maintenance mode again. This would be a similar process as installing cumulative updates.

I would anticipate that if this warning condition remains in place that database creation will become a planned maintenance activity that occurs during the same window as monthly security patching or quarterly cumulative update installation.

For a deeper look at the reasons behind this check our Tony Redmond’s article here.

What are your thoughts on this?

This article Warning: Please Restart the Microsoft Exchange Information Store Service After Adding New Mailbox Databases is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

However it is also quite easy to create a situation where SMTP traffic is not being load balanced as intended, and worse still there are scenarios where the use of some load balanced configurations may actually diminish SMTP high availability, or even undermine security.

Let’s take a look at some of the issues and how they can be identified and resolved.

Issues with Load Balancer Configurations

The first issues are reasonably easy to correct if they exist. These are primarily related to the configuration and features of the load balancer itself, such as:

• the priority of the target servers
• the load balancing method/algorithm used
• whether source NATing is being used
• the health monitors/probes

Consider the following scenario where incoming internet email is passed through an email security server/appliance, which is configured to then send the traffic to a load balancer for distribution to the Hub Transport servers. Various internal applications and systems also use the load balancer as their SMTP target.

Priority of Target Servers

In most load balancer configurations you can configure a priority or weight for the servers that are the targets of the traffic. Different vendors use their own terminology for this, but the general idea is that it provides the option to have preferred servers that will be considered first for a new connection if they are available.

Now there are situations where this is a deliberate design choice, and if that is your case then you may not need to worry about this particular issue. However there are some considerations to be aware of if you find that your servers are weighted differently for no particular reason.

Here is a traffic graph of a typical day for two servers that were configured with different weightings/priorities in the load balancer. You can see that SERVER1 handled a higher volume of traffic than SERVER2.

This graph was created by gathering traffic stats from the message tracking logs. For more information see Calculate Daily Email Traffic using Message Tracking Logs and Log Parser.

Depending on your server resources and traffic load this may not be an issue for you, but in some environments it could lead to load issues that interrupt mail flow. So if your actual intention is evenly distribute traffic across multiple Hub Transport servers then you would consider adjusting the server weight/priority accordingly.

In the above scenario when the weightings were adjusted the traffic became more evenly distributed (not perfectly, but that is due to other factors in that environment which I will cover next).

Load Balancing Method/Algorithm

Along similar lines to the previous issue, a load balancer will usually have multiple methods for deciding which server should be used for a connection. For example, the Kemp load balancers have quite a few scheduling options available.

If you’re seeing SMTP traffic imbalances similar to those in the previous example, and your server weighting/priority is not the cause, you should look at the load balancing method and investigate whether your current configuration is not the best suited for that traffic.

As one specific example, if the load balancing is based on source IP it may inadvertently lead to traffic imbalances. In the example environment shown at the beginning of this article, source IP-based load balancing would generally result in well balanced traffic from the internal applications and systems, assuming each internal IP is sending roughly equal volumes of email, otherwise some imbalances can still occur.

But that configuration may result in imbalanced email traffic coming from the internet (via the email security server/appliance), because that all appears to come from a single IP.

As the earlier graph showed this was causing some imbalance in overall SMTP traffic even after the server weight/priority was reconfigured, because while that resolved traffic imbalance from internal sources that are all on different IP addresses, the incoming internet email was still treated as coming from a single IP and was almost entirely being sent to a single Hub Transport server.

The obvious reaction here may be to choose a different load balancing algorithm, however my recommendation for environments where incoming internet email all traverses a single host like that is to consider not using the load balancer for distribution of that incoming internet traffic.

I will explain my reasons for that in the next sections.

Source NATing

One of my concerns with source NATing and load balanced SMTP traffic is the impact is has on the protocol logs generated by the Hub Transport servers.

Note that much of data presented in this section relies on protocol logging being turned on for all receive connectors on the Hub Transport servers.

[PS] C:\>Get-ReceiveConnector -Server SERVER1 | select name,protocollogginglevel | ft -auto

Name                                    ProtocolLoggingLevel
----                                    --------------------
Default SERVER1                                      Verbose
Client SERVER1                                       Verbose
Internal Relay                                       Verbose
Internet via Gateway                                 Verbose

For more on protocol logging see Troubleshooting Email Delivery with Exchange Server Protocol Logging.

With all internal and incoming SMTP traffic going via the load balancer, which is source NATing the connections, the protocol logs only recorded traffic from the load balancer (IP 10.1.1.12 below) and no other IP addresses.

IP             Name                    Hits
-------------- ----------------------- -----
10.1.1.12      10.1.1.12               25976

Statistics:
-----------
Elements processed: 1428114
Elements output:    1
Execution time:     13.49 seconds

The above stats were collected using protocol logs and Log Parser. For more information see Report Top Sender IP’s on Exchange Server 2010 using Log Parser.

Looking at hits per receive connector (recorded as “connector-id” in protocol logs) there was no traffic being handled by the receive connector that was configured for internet traffic.

Connector                                          Hits
-------------------------------------------------- -------
SERVER1\Internal Relay                             1422080
SERVER1\Default SERVER1                               4363

While this doesn’t necessarily result in an email disruption for your environment, if you have a receive connector for a specific purpose and it is not being used for that intended purpose then your environment is not operating as intended.

Aside from that there is also the issue of being able to identify the relative traffic volume of internal vs internet email, if you’re relying on protocol log data to give you that information about your email traffic patterns.

Depending on your incoming email routes there are multiple ways to respond to this issue.

In the example scenario used in this article the email security server has its own load balancing capability for incoming email because you can specify multiple internal hosts to deliver email to. This would also apply to hosted email security services.

By configuring each Hub Transport as an internal delivery target instead of just using the load balancer, the protocol logs now log incoming internet email as coming from the IP addresses for the email security system, rather than the load balancer.

IP             Name                    Hits
-------------- ----------------------- -----
10.1.1.12      10.1.1.12               24819
192.168.0.32   192.168.0.32            115
192.168.0.31   192.168.0.31            105

Statistics:
-----------
Elements processed: 1397172
Elements output:    3
Execution time:     22.47 seconds

If you do not have an email security server/appliance or other hosted solution, and SMTP connections go directly from the internet to the load balancer, then you could look at using multiple MX records instead, although this would require the availability of multiple public IP addresses.

In addition, any traffic imbalance being caused by the use of source IP-based load balancing should no longer be present. This graph represents incoming internet SMTP connections per server, which began imbalanced and then evened out almost precisely once the load balancer was bypassed.

And importantly, with traffic bypassing the load balancer it should be getting handled by the intended receive connector (which I will explore more in the section further down on security implications).

Connector                                          Hits
-------------------------------------------------- -------
SERVER1\Internal Relay                             1257702
SERVER1\Internet via Gateway                       6374

Statistics:
-----------
Elements processed: 1267529
Elements output:    2
Execution time:     3.23 seconds

Health Monitors and Probes

Yet another issue with load balancing SMTP is the nature of how load balancers detect service availability.

Most load balancers that are service-aware have a health monitor or probe that makes an SMTP connection to the Hub Transport server, waits for a sign that the service is responding, then disconnects. That sign may be simply waiting for the SMTP banner to be returned, or waiting for a response to HELO.

For example, here is the protocol log data for a health check by a load balancer:

"220 SERVER1.domain.local Microsoft ESMTP MAIL Service ready at Fri, 26 Apr 2013 09:40:12 +1000"
helo domain.com
250 server1.domain.com Hello [10.1.1.10]
quit
221 2.0.0 Service closing transmission channel

That probe may detect complete service failures, but won’t necessarily detect back pressure if it only goes as far as a HELO.

For example, I pushed one of my test lab servers into “medium” back pressure and then used Telnet to connect and test the response.

As you can see below it was only when I progressed the SMTP conversation past HELO and into the “mail from:” stage that the server returned the familiar 452 4.3.1 Insufficient system resources error, but only for external senders.

220 HO-EX2010-MB1.exchangeserverpro.net Microsoft ESMTP MAIL Service ready at Mo
n, 29 Apr 2013 19:55:12 +1000
helo
250 HO-EX2010-MB1.exchangeserverpro.net Hello [10.1.1.4]
mail from: exchangeserverpro@gmail.com
452 4.3.1 Insufficient system resources
mail from:alan.reid@exchangeserverpro.net
250 2.1.0 Sender OK

So this server would be rejecting incoming internet email (the sender from @gmail.com), even though the load balancer considers the server to be healthy and available.

If you combine this service-awareness issue with the problem of all email coming from one IP address (ie the email security server/appliance) being distributed only to the server that is suffering back pressure, you can end up with an email disruption for your end users.

Admittedly the combination of factors required to cause that problem scenario may be uncommon, but the potential impact is quite high.

Security Implications

Another issue with some load balanced SMTP configurations is how it can impact the security of your Exchange environment.

The first potential impact is for distribution groups that are configured to require that all senders be authenticated but are otherwise not restricted as to who can send to them (this is the default for distribution groups created in Exchange 2007 and later).

Because some administrators add the source NAT address(es) of the load balancers into the list of remote IP addresses on their internal relay connectors configured in Exchange, this results in any sender that is coming via the load balancer being considered as authenticated and therefore allowed to send to the distribution list.

For internal relay connectors that aren’t exposed to the outside world this may only be a minor inconvenience.

Where this becomes more serious is when incoming internet email traffic arrives via that same load balancer, and can send email to any recipient anywhere – in other words, you’ve got an open relay.

This is a Telnet session from outside of my test lab firewall, through to the load balancer’s IP address, and I am able to relay an email through my Exchange servers.

250 HO-EX2010-MB2.exchangeserverpro.net Hello [10.1.1.12]
mail from: exchangeserverpro@gmail.com
250 2.1.0 Sender OK
rcpt to: paul@locklan.com.au
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
subject: test relay
test
.
250 2.6.0 <546b08e1-fd0f-4baa-a473-03fba110a1af@HO-EX2010-MB2.exchangeserverpro. net> [InternalId=334267] Queued mail for delivery

This occurs because the source NATing causes Exchange to believe that the email is originating from the load balancer (10.1.1.12), and that IP address is configured as a remote IP address on the internal relay connector.

Ideally if internet email traffic is coming in directly to a load balancer, and the load balancer has no other mechanism for preventing an open relay scenario, then you should ensure that the receive connectors configured for internal applications and systems to relay email are not also handling the internet email traffic.

This could be achieved by using a different VIP and source NAT pool on the load balancer for that traffic, so that it does not get included in the remote IP range for the internal relay connector.

Summary

I’ve covered a lot of points in this article and before you get too alarmed I want to make a few things clear.

Firstly, not all of these scenarios are necessarily bad. A traffic imbalance may not be a concern for smaller networks, and may even be a deliberate configuration in some situations.

The impact on protocol logs may not be a concern for administrators who simply do not make any use of the data they contain.

Limitations around health probes/monitoring by the load balancer may not be a concern if you have other robust enterprise monitoring systems alerting you to those conditions already.

Distribution groups being emailed by unauthenticated senders may not be an issue if there is spam filtering in place, and if the organization actually engages in a lot of group email with external parties.

And the sharing of a relay connector for both internal (trusted) and incoming (untrusted) email may not be an immediate issue if the incoming traffic first passes through another device or host that blocks the relay attempt (eg an email security server/appliance).

However, if you do have any concerns about any of these issues I’ve raised then it would be wise to review your configurations, perform some testing, and consider whether there is a better configuration you could move to that mitigates any issues you are actually experiencing.

This article Issues With Load Balancing SMTP Traffic is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

As an additional update I am pleased to announce that the script is now tested and working for Exchange Server 2013 database availability groups as well. I have not yet tested a mixed 2010/2013 org though.

You can download the new version here.

Please continue to report bugs and make feature requests in the comments on that post.

This article V1.1 of Get-DAGHealth.ps1 is Available is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

I am trying to find a command that will return the user and total item count for the inbox only. Can this be done?

The solution to Rebecca’s scenario is in the Get-MailboxFolderStatistics cmdlet. This cmdlet can be used to report on some or all of the individual folders within a mailbox, returning such information as their size and item count.

For example:

Get-MailboxFolderStatistics alan.reid

If you ran that command against a mailbox in your organization you will see a lot of information returned. You may wish to return just a few of the more interesting bits of information instead, for example:

[PS] C:\>Get-MailboxFolderStatistics alan.reid | Select Name,FolderSize,ItemsinFolder

Name                         FolderSize               ItemsInFolder
----                         ----------               -------------
Top of Information Store     0 B (0 bytes)                        0
Calendar                     49.89 KB (51,083 bytes)             11
Contacts                     26.75 KB (27,388 bytes)              7
Conversation Action Settings 0 B (0 bytes)                        0
Deleted Items                0 B (0 bytes)                        0
Drafts                       0 B (0 bytes)                        0
Import1                      0 B (0 bytes)                        0
Calendar                     0 B (0 bytes)                        0
Contacts                     0 B (0 bytes)                        0
Conversation Action Settings 0 B (0 bytes)                        0
Deleted Items                0 B (0 bytes)                        0
Drafts                       0 B (0 bytes)                        0
Inbox                        6.489 KB (6,645 bytes)               1
Journal                      0 B (0 bytes)                        0
Junk E-Mail                  0 B (0 bytes)                        0
Notes                        0 B (0 bytes)                        0
Outbox                       0 B (0 bytes)                        0
Recoverable Items            0 B (0 bytes)                        0
Deletions                    0 B (0 bytes)                        0
Purges                       0 B (0 bytes)                        0
Versions                     0 B (0 bytes)                        0
Sent Items                   0 B (0 bytes)                        0
Tasks                        0 B (0 bytes)                        0
Inbox                        347 KB (355,298 bytes)             167
Old mail                     0 B (0 bytes)                        0
Journal                      0 B (0 bytes)                        0
Junk E-mail                  389.4 KB (398,709 bytes)            10
News Feed                    0 B (0 bytes)                        0
Notes                        0 B (0 bytes)                        0
Outbox                       0 B (0 bytes)                        0
Quick Step Settings          0 B (0 bytes)                        0
RSS Feeds                    0 B (0 bytes)                        0
Sent Items                   351.2 KB (359,661 bytes)           157
Suggested Contacts           0 B (0 bytes)                        0
Sync Issues                  0 B (0 bytes)                        0
Conflicts                    0 B (0 bytes)                        0
Local Failures               0 B (0 bytes)                        0
Server Failures              0 B (0 bytes)                        0
Tasks                        0 B (0 bytes)                        0
Recoverable Items            127.5 KB (130,553 bytes)            54
Deletions                    0 B (0 bytes)                        0
Purges                       0 B (0 bytes)                        0
Versions                     0 B (0 bytes)                        0

Similarly you may wish to only look at specific folders and subfolders, which you can achieve using the -FolderScope parameter. For example:

[PS] C:\>Get-MailboxFolderStatistics alan.reid -FolderScope Inbox | Select Name,FolderSize,ItemsinFolder

Name     FolderSize               ItemsInFolder
----     ----------               -------------
Inbox    320.8 KB (328,501 bytes)           156
Old mail 25.42 KB (26,027 bytes)             11

So getting back to Rebecca’s question, what if we just want to know the total size of the inbox? The command above returns two values, one for the inbox and one for the subfolder “Old mail”. In a report of “Inbox sizes” we would want the total of both.

Fortunately one of the values returned by Get-MailboxFolderStatistics is for the size of the folder and subfolders.

[PS] C:\>Get-MailboxFolderStatistics alan.reid -FolderScope Inbox | Select Name,FolderandSubFolderSize,ItemsinFolderandSubfolders

Name     FolderAndSubfolderSize   ItemsInFolderAndSubfolders
----     ----------------------   --------------------------
Inbox    346.2 KB (354,528 bytes)                        167
Old mail 25.42 KB (26,027 bytes)                          11

Also, we just want the inbox itself in our report, not every subfolder listed individually.

[PS] C:\>Get-MailboxFolderStatistics alan.reid -FolderScope Inbox | Where {$_.FolderPath -eq "/Inbox"} | Select Name,FolderandSubFolderSize,ItemsinFolderandSubfolders

Name  FolderAndSubfolderSize   ItemsInFolderAndSubfolders
----  ----------------------   --------------------------
Inbox 346.2 KB (354,528 bytes)                        167

Finally, if I was interested in a report of the inbox sizes for all mailboxes in the organizations, I would probably whip up a quick script like this.

$mailboxes = @(Get-Mailbox -ResultSize Unlimited)
$report = @()

foreach ($mailbox in $mailboxes)
{
    $inboxstats = Get-MailboxFolderStatistics $mailbox -FolderScope Inbox | Where {$_.FolderPath -eq "/Inbox"}

    $mbObj = New-Object PSObject
    $mbObj | Add-Member -MemberType NoteProperty -Name "Display Name" -Value $mailbox.DisplayName
    $mbObj | Add-Member -MemberType NoteProperty -Name "Inbox Size (Mb)" -Value $inboxstats.FolderandSubFolderSize.ToMB()
    $mbObj | Add-Member -MemberType NoteProperty -Name "Inbox Items" -Value $inboxstats.ItemsinFolderandSubfolders
    $report += $mbObj
}

$report

Saving that as Get-InboxReport.ps1 I can then run it in the Exchange Management Shell.

[PS] C:\Scripts>.\Get-InboxSize.ps1

I could even output it to CSV file for further analysis.

[PS] C:\Scripts>.\Get-InboxSize.ps1 | Export-CSV inboxsizes.csv

The script above is just a few lines with no error handling, parameters, or other useful elements that you might find in a script, but it is just to give you an idea of what is possible with Get-MailboxFolderStatistics.

I hope that answers your question Rebecca.

This article Reporting Mailbox Folder Sizes with PowerShell is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

This computer requires the Microsoft Office Filter Packs – Version 2.0. Please install the software from…

This computer requires the Microsoft Office 2010 Filter Packs – Version 2.0 – Service Pack 1. Please install the software from…

These are warning messages and do not block the installation or upgrade of Exchange 2013. The Office Filter Pack is not a mandatory Exchange 2013 pre-requisite.

The Exchange 2013 pre-requisites page on TechNet, at the time of this writing, does include the Office Filter Packs as a step in the preparation of a server for Exchange 2013. What it doesn’t make clear is that they are not required.

The new Exchange Search already has support for indexing/searching Office file types, as well as a series of other file types including some third party formats such as PDF. You can see a full list here.

So should you install the Office Filter Pack? If you want to stop seeing that warning message, then yes. If you want to take the approach of only installing required software on your servers, then no. Consider also that installing it means potentially having to update it later on if there is a bug fix or a security issue.

This article Exchange Server 2013 FAQ: Is the Office Filter Pack Required? is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com