Exchange Server 2010 Windows PowerShell: Troubleshooting Mailboxes

0
102
7 min read

 

Microsoft Exchange 2010 PowerShell Cookbook

Microsoft Exchange 2010 PowerShell Cookbook

Manage and maintain your Microsoft Exchange 2010 environment with the Exchange Management Shell and Windows PowerShell 2.0 using this book and eBook

        Read more about this book      

(For more resources on this subject, see here.)

The reader will benefit from referring two previous articles: Managing Mailboxes and Reporting on Mailbox.

Performing some basic steps

To work with the code samples in this article, follow these steps to launch the Exchange Management Shell:

  1. Log onto a workstation or server with the Exchange Management Tools installed.
  2. Open the Exchange Management Shell by clicking on Start | All Programs | Exchange Server 2010.
  3. Click on the Exchange Management Shell shortcut.

Checking mailbox logon statistics

If you have worked with Exchange 2000 or 2003, you probably remember that you could easily view several mailbox-related details for each mailbox under the Logons node of the Exchange System Manager. These details included the user-name, last access time, and more. When viewing mailboxes in the Exchange Management Console in Exchange 2010, these details are not displayed. In this recipe, we will take a look at how we can gather some of this information the Get-LogonStatistics cmdlet.

How to do it…

The following command will provide a logon statistics report for all mailboxes in the organization:

Get-MailboxServer |
Get-LogonStatistics |
Select UserName,ApplicationId,ClientVersion,LastAccessTime

How it works…

The Get-LogonStatistics cmdlet c an be useful for doing some basic checks on client logons, but the information returned from the previous command can be a little confusing and might seem inaccurate. For example, the ClientVersion property returned for each logon will always be reported as the same version number for end-user logons. This is due to the fact that client connections go through the Client Access role in Exchange 2010. Whether or not this will be fixed in future versions is unknown.

The ApplicationId property will indicate whether clients are connected via RPC or through Outlook Web App. Keep in mind that, depending on the client, multiple connections could be reported. Client’s applications initiate multiple connections, so you will likely notice that this cmdlet will return anywhere from three to five records for each user connected to a mailbox. You will also see connections where the username is reported as the name of one or more databases or a system mailbox. These are generated by transport servers and mailbox assistant agents.

There’s more…

There are a couple of other ways you can run this cmdlet. First, you can generate a report for an individual user. Instead of selecting individual properties, you can pipe the command to Format-List with a wildcard to display all of them:

Get-LogonStatistics -Identity testuser | Format-List *

You can also retrieve the logon statistics for a particular database using the -Database parameter:

Get-LogonStatistics -Database DB1

When users access their mailbox through Outlook Web App you may find that logon statistics for these sessions are missing or not what you would expect when running the Get-LogonStatistics cmdlet. This is because OWA users are not continuously connected to the Exchange server and the OWA client only connects to the server as needed to perform a task.

Setting storage quotas for mailboxes

One thing that has been around for several versions of Exchange is the concept of storage quotas. Using quotas, we can control the size of each mailbox to ensure that our mailbox databases don’t grow out of control. In addition to setting storage quotas at the database level, we can also configure storage quotas on a per-mailbox basis. In this recipe, we will take a look at how to configure mailbox storage quotas from the Exchange Management Shell.

How to do it…

Use the following command syntax to set custom limits on mailbox:

Set-Mailbox -Identity testuser `
-IssueWarningQuota 1gb `
-ProhibitSendQuota 1.5gb `
-ProhibitSendReceiveQuota 2gb `
-UseDatabaseQuotaDefaults $false

How it works…

The Set-Mailbox cmdlet is used to configure the quota warning and send and receive limits for each mailbox. In this example, we are setting the -IssueWarningQuota parameter to one gigabyte. When the user’s mailbox exceeds this size, they will receive a warning message from the system that they are approaching their quota limit.

The -ProhibitSendQuota is set to 1.5 gigabytes, and when the total mailbox size exceeds this limit, the user will no longer be able to send messages, although new incoming e-mail messages will still be received.

We’ve set the -ProhibitSendReceiveQuota parameter value to two gigabytes. Once this mailbox reaches this size, the user will no longer be able to send or receive mail.

It’s important to point out here that we have disabled the option to inherit the storage quota limits from the database by setting the -UseDatabaseQuotaDefaults to $false. If this setting were set to $true, the custom mailbox quota settings would not be used.

There’s more…

By default, mailboxes are configured to inherit their storage quota limits from their parent database. In most cases, this is ideal since you can centrally control the settings for each mailbox in a particular database. However, it is unlikely that having single quota limit for the entire organization will be sufficient. For example, you will probably have a group of managers, VIP users, or executives that require a larger amount of space for their mailboxes.

Even though you could create a separate database for these users with higher quota values, this might not make sense in your environment, and instead, you may want to override the database quota defaults with a custom setting on an individual basis. Let’s say that all users with their Title set to Manager should have a custom quota setting. We can use the following commands to make this change in bulk:

Get-User -RecipientTypeDetails UserMailbox `
-Filter {Title -eq 'Manager'} |
Set-Mailbox -IssueWarningQuota 2gb `
-ProhibitSendQuota 2.5gb `
-ProhibitSendReceiveQuota 3gb `
-UseDatabaseQuotaDefaults $false

What we are doing here is searching Active Directory with the Get-User cmdlet and filtering the results so that only mailbox-enabled users with their title set to Manager are returned. This command is piped further to get the Set-Mailbox cmdlet which configures the mailbox quota values and disables the option to use the database quota defaults.

Finding inactive mailboxes

If you support a large Exchange environment, it’s likely that users come and go frequently. In this case, it’s quite possible over time that you will end up with multiple unused mailboxes. In this recipe, you will learn a couple of techniques used when searching for inactive mailboxes with the Exchange Management Shell.

How to do it…

The following command will retrieve a list of mailboxes that have not been logged on to in over 90 days:

$mailboxes = Get-Mailbox -ResultSize Unlimited
$mailboxes | ?{
(Get-MailboxStatistics $_).LastLogonTime -and `
(Get-MailboxStatistics $_).LastLogonTime -le `
(Get-Date).AddDays(-90)
}

How it works…

You can see here that we’re retrieving all of the mailboxes in the organization using the Get-Mailbox cmdlet and storing the results in the $mailboxes variable. We then pipe this collection to the Where-Object cmdlet (using the ? alias) and use the Get-MailboxStatistics cmdlet to build a filter. This first part of this filter indicates that we only want to retrieve mailboxes that have a value set for the LastLogonTime property. If this value is $null, it indicates that these mailboxes have never been used, and have probably been recently created, which means that they will probably soon become active mailboxes. The second part of the filter compares the value for the LastLogonTime. If that value is less than or equal to the date 90 days ago then we have a match and the mailbox will be returned.

There’s more…

Finding unused mailboxes in your environment might be as simple as searching for disabled user accounts in Active Directory that are mailbox-enabled. If that is the case, you can use the following one-liner to discover these mailboxes:

Get-User -ResultSize Unlimited -RecipientTypeDetails UserMailbox |
?{$_.UserAccountControl -match 'AccountDisabled'}

This command uses the Get-User cmdlet to search through all of the mailbox-enabled users in Active Directory. Next, we filter the results even further by piping those results to the Where-Object cmdlet to find any mailboxes where the UserAccountControl property contains the AccountDisabled value, indicating that the associated Active Directory user account has been disabled.

LEAVE A REPLY

Please enter your comment!
Please enter your name here