• Part 1 – How to Send SMTP Email Using PowerShell
• Part 2 - How to Add a Message Body to Emails Sent from Scripts
• Part 3 - How to Add a HTML Message Body to Emails Sent from Scripts
• Part 4 - How to Create Formatted HTML Output from Scripts

I also shared with you a script that can be used to check Exchange Server 2010 database backups and alert you to any that have not had a recent backup.

Now it’s time to bring all of that information together and demonstrate how you can set up an automated database backup alert email for your Exchange Server 2010 environment.

The two components of this are:

• The PowerShell script itself (we’ll use the one mentioned earlier but with some modifications to email-enable it)
• Task Scheduler for automatically running the script each day

Script for Exchange Server 2010 Database Backup Email Alerts

To email-enable the script I’ve made just a few modifications. The original script used this conditional logic to display the report in the PowerShell window.

#If alert flag is true output the report
if ($alertflag -eq $true )
{
	Write-Host "The following databases have not been backed up in" $threshold "hours."
	$alerts | ft -AutoSize
}
else
{
	Write-Host "No backup alerts required."
}

To change this to send an email alert we can use this code instead:

#If alert flag is true send the email alert
if ($alertflag -eq $true )
{
	#HTML styles for nice formatting
        $style = "<style>BODY{font-family: Arial; font-size: 10pt;}"
	$style = $style + "TABLE{border: 1px solid black; border-collapse: collapse;}"
	$style = $style + "TH{border: 1px solid black; background: #CC0000; padding: 5px; color: #FFFFFF;}"
	$style = $style + "TD{border: 1px solid black; padding: 5px; }"
	$style = $style + "</style>"

        #SMTP options for sending the report email
	$smtpServer = "ho-ex2010-caht1.exchangeserverpro.net"
	$smtpFrom = "reports@exchangeserverpro.net"
	$smtpTo = "administrator@exchangeserverpro.net"
	$messageSubject = "Exchange Backup Alerts"

        $intro = "The following databases have not been backed up in " + $threshold + " hours.<BR><BR>"
	$report = $alerts | ConvertTo-Html -Fragment

	#Get ready to send email message
	$message = New-Object System.Net.Mail.MailMessage $smtpfrom, $smtpto
	$message.Subject = $messageSubject
	$message.IsBodyHTML = $true
	$message.Body = ConvertTo-Html -Body "$intro $report" -Head $style

	#Send email message
	$smtp = New-Object Net.Mail.SmtpClient($smtpServer)
	$smtp.Send($message)

}

If any parts of that don’t make sense just refer to the previous tutorials on sending email with PowerShell.

Download the script file here: Get-DailyBackupAlerts.ps1 (downloaded 199 times so far)

If you’re using this script in your environment you will need to change the SMTP options to suit.

#SMTP options for sending the report email
$smtpServer = "ho-ex2010-caht1.exchangeserverpro.net"
$smtpFrom = "reports@exchangeserverpro.net"
$smtpTo = "administrator@exchangeserverpro.net"
$messageSubject = "Exchange Backup Alerts"

Save the script as Get-DailyBackupAlerts.ps1 in a folder called C:\Scripts on the server where you would like it to run each day. Note that the script depends on the Exchange Server 2010 management tools, so they will also need to be installed.

Using Task Scheduler to Run PowerShell Scripts

Now we need to configure the scheduled task in Task Scheduler. On a Windows Server 2008 server you’ll find this in the Administrative Tools. After you’ve launched Task Scheduler click on Create Task.

Give the task a meaningful name, set it to Run whether user is logged on or not, and also if necessary change the user account that it will run as (you may wish to create a special Exchange administrative account with a strong password for running these types of scripts).

On the Triggers tab click new and add a Weekly trigger for each of your normal business days that you want the script to run (eg Monday – Friday). Set the Start time to suit your normal backups finishing time and your own work schedule.

On the Actions tab click New and add an action of Start a program. Configure the program of powershell.exe and the arguments -command “c:\scripts\get-dailybackupalerts.ps1″

Click OK to finish creating the new task. You will be prompted to enter the credentials for the account that you configured the task to run as.

Now you can test the scheduled task by right-clicking on it in the Task Scheduler Library and choosing Run.

Assuming you have some databases that have not backed up recently you should receive an alert email shortly after running the scheduled task.

Note: if your backups are all up to date you can test the script by changing the $threshold variable to something very low such as 1.

Download the script file here: Get-DailyBackupAlerts.ps1 (downloaded 199 times so far)

Related posts:

• PowerShell Script: Check Exchange 2010 Database Backups
• PowerShell Script: Check Exchange Mailbox Database Last Backup Time
• Avoid Running Out of Transaction Log Disk Space on Exchange Servers
• Using Test-Mailflow with Exchange 2003 Servers
• How to Health Check an Exchange 2010 Mailbox Server

This article How to Set Up an Automated Exchange 2010 Database Backup Alert Email is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

If you’re not a Forefront user or you’re otherwise unaware of the situation, the issue is that Forefront Protection for Exchange and update rollups don’t play nicely together. For example during installation the update rollup can hang at stages such as restarting the Exchange services after the update has been applied.

Services not starting after Exchange Server rollup installation

This is why each update rollup release comes with the following instructions:

Note for Forefront Protection for Exchange users For those of you running Forefront Protection for Exchange, be sure you perform these important steps from the command line in the Forefront directory before and after this rollup’s installation process. Without these steps, Exchange services for Information Store and Transport will not start after you apply this update. Before installing the update, disable ForeFront by using this command: fscutility /disable. After installing the update, re-enable ForeFront by running fscutility /enable.

As a result we see comments like these from disgruntled customers.

Note for Forefront Protection for Exchange users: We still don’t care enough about you to add two lines to the setup script. Instead you have to do it manually. Or you can install the update via Microsoft Update and you’ll be in for a funny surprise.

Hey Microsoft…. could you not detect for your own software and automatically run the command fscutility /disable????, Now I cannot even get WUS to do this…. Annoyed! and feeling unappreciated as a FF customer

Microsoft actually has provided a solution for this, back when Exchange Server 2007 SP2 was released, and appears to have carried it forward for Exchange Server 2010 as well. A script named CustomPatchInstallerActions.ps1 can be used to perform pre- and post-installation tasks for update rollups.

I’m not sure why they don’t refer to it with each update rollup release, but as far as I can tell from my own testing it works fine.

Here is what you need to do.

1. In the \Scripts folder of your Exchange 2010 installation find the file named CustomPatchInstallerActions.ps1.template
2. Create a new sub-folder in \Scripts named Customizations
3. Copy the script template into that sub-folder, and remove the .template extension
4. Edit the file with the customizations you want, and the next time you install an update rollup the script will be called automatically

So what kind of customizations should you include? I did a little testing and here is what I suggest as a minimum. You’ll also find Microsoft’s advice here.

First, I ran fscutility /disable (from the C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server folder) to see what happens. I received the following output.

Error:
  Microsoft Forefront Protection cannot be disabled at this time.  Please stop
  the following services and then rerun this utility.

   FSCController
   MSExchangeTransport
   MSExchangeIS

So clearly some services need to be stopped first. That will need to go in the script.

After disabling those services fscutility /disable works successfully. So that can be run second.

  Removing dependencies...

      dependency on FSCController removed from Microsoft Exchange Information Store
      dependency on FSEIMC removed from Microsoft Exchange Transport Service
      Microsoft Exchange Transport Service Agent registration removed

Status:  Microsoft Forefront Protection NOT Integrated.

In the custom script itself the actions to perform before installing an update rollup go in the PrePatchInstallationActions function.

function PrePatchInstallActions
{
                Log "Running PrePatchInstallActions"

		Log "Stopping services"
		Stop-Service FSCController,MSExchangeTransport,MSExchangeIS -Force

		Log "Disabling Forefront"
		$fscutility = "C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server\fscutility.exe"
		Invoke-Expression $fscutility /disable

}

Notice I’ve also made use of the Log function that is in the script so that I can see in the log file later that my custom actions were run (or at least attempted to run). The log file is written to C:\ExchangeSetupLogs\CustomPatchInstallActions.log

After the update rollup is finished installing there is a similar process involved to re-enable Forefront. These steps go in the PostPatchInstallActions function.

function PostPatchInstallActions
{
                Log "Running PostPatchInstallActions"

		Log "Stopping services"
		Stop-Service FSCController,MSExchangeTransport,MSExchangeIS -Force

		Log "Enabling Forefront"
		$fscutility = "C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server\fscutility.exe"
		Invoke-Expression $fscutility /enable

		Log "Starting services"
		Start-Service FSCController,MSExchangeTransport,MSExchangeIS

}

When I upgraded two servers side-by-side, one with the CustomPatchInstallerActions.ps1 and one without, the one with the script updated without any problems and the one without hung while trying to start the services afterwards.

So in my testing this appears to work well, but it is something you should test in your own environment before relying on it too heavily.

Note that this script can be used for all kinds of situations even when Forefront is not installed. If you have any pre- or post-install actions required in your environment (eg running the StartDagServerMaintenance.ps1 script, disabling backups, disabling other antivirus software, sending an email alert to your team) you can include those in this CustomPatchInstallerActions.ps1 script.

Related posts:

• PowerShell Script to Generate Email Traffic in a Test Lab Environment
• How to Health Check an Exchange 2010 Mailbox Server
• How to List all Users Who Have Access to Other Exchange Mailboxes
• How to Generate a HTML Report of Your Exchange 2010 Environment
• PowerShell Script: Check Exchange Mailbox Database Last Backup Time

This article Dealing with Exchange Server Update Rollups and Forefront Protection for Exchange is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Each message tracking log entry records an event ID from the following list:

• BADMAIL
• DELIVER
• DSN
• EXPAND
• FAIL
• POISONMESSAGE
• RECEIVE
• REDIRECT
• RESOLVE
• SEND
• SUBMIT
• TRANSFER

Each event means different things. Healthy messages may record multiple receive, send, transfer, submit or deliver events, depending on your environment. Unhealthy messages may record badmail or fail events.

While there is no hard and fast rules about what percentage of each event you should see, it is still useful to take a look at a summary of the different events IDs in case you notice something that may warrant further investigation.

You can generate this summary using PowerShell and the Get-MessageTrackingLog cmdlet.

[PS] C:\>Get-MessageTrackingLog -ResultSize Unlimited | Group-Object -Property:EventId | Sort-Object Count -Desc | Select Name,Count

Name        Count
----        -----
RECEIVE     58679
DELIVER     47496
NOTIFYMAPI  20812
SUBMIT      20806
SEND        19863
RESUBMIT     8679
HAREDIRECT   6826
TRANSFER      351
DSN            96
FAIL           95
SUBMITDEFER     6
BADMAIL         2

For more tips and examples on searching message tracking logs with PowerShell check out this article.

Incidentally you may find this type of summary report to be faster to generate using Log Parser instead. In my tests the PowerShell command took almost 5 minutes to complete, whereas Log Parser took only 9 seconds on the same server. Your mileage may vary. You can check out the Log Parser query here.

Related posts:

• Searching Exchange Server 2010 Message Tracking Logs with PowerShell
• Calculate Hourly Email Traffic using Message Tracking Logs and Log Parser
• Calculate Daily Email Traffic using Message Tracking Logs and Log Parser
• Reporting Exchange Server 2010 Message Tracking Event IDs with Log Parser
• Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

This article Reporting Exchange Server 2010 Message Tracking Event IDs with PowerShell is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Although the message tracking log explorer is fine for simple searches on a single server, it doesn’t work so well when you want to do wildcard searches, search multiple servers at once, or export data for further analysis.

Message tracking log explorer

For those operations PowerShell is the way to go, and frankly once you’ve seen how powerful PowerShell is for message tracking log searches you’ll probably never use the explorer tool again.

Getting Started with Searching Message Tracking Logs Using PowerShell

Message tracking log searches are performed in the Exchange Management Shell by running the Get-MessageTrackingLog cmdlet. You can run this cmdlet with no parameters on any Edge Transport, Hub Transport or Mailbox server and it will return all of the log entries on that server.

[PS] C:\>Get-MessageTrackingLog

EventId    Source      Sender                                 Recipients                               MessageSubject
-------    ------      ------                                 ----------                               --------------
RECEIVE    SMTP        Ivana.Ferrary@exchangeserverpro.net    {Ana.Williams@exchangeserverpro.net}     Luminary asep...
DELIVER    STOREDRIVER John.Tilleray@exchangeserverpro.net    {Lucy.Spratley@exchangeserverpro.net}    Egress concor...
RECEIVE    STOREDRIVER Ambrine.Berry@exchangeserverpro.net    {Lorraine.Oza@exchangeserverpro.net}     Brazen
DELIVER    STOREDRIVER Ivana.Ferrary@exchangeserverpro.net    {Ana.Williams@exchangeserverpro.net}     Luminary asep...
RECEIVE    SMTP        Donna.A'Bear@exchangeserverpro.net     {Marc.Itoje@exchangeserverpro.net}       Garble expedi...
RECEIVE    SMTP        Priya.Smith@exchangeserverpro.net      {Melanie.Thomas@exchangeserverpro.net}   Enthral boorish
DELIVER    STOREDRIVER Donna.A'Bear@exchangeserverpro.net     {Marc.Itoje@exchangeserverpro.net}       Garble expedi...
RECEIVE    SMTP        Jane.Martin@exchangeserverpro.net      {Charlotte.Bonsey@exchangeserverpro.net} Palate causti...
DELIVER    STOREDRIVER Ambrine.Berry@exchangeserverpro.net    {Lorraine.Oza@exchangeserverpro.net}     Brazen
RECEIVE    SMTP        Yvette.Willis@exchangeserverpro.net    {Jan.Marway@exchangeserverpro.net}       Malign edible
DELIVER    STOREDRIVER Priya.Smith@exchangeserverpro.net      {Melanie.Thomas@exchangeserverpro.net}   Enthral boorish
RECEIVE    STOREDRIVER Joy.Singh@exchangeserverpro.net        {Mary.Friel@exchangeserverpro.net}       Obfuscate
HAREDIRECT ROUTING     Joy.Singh@exchangeserverpro.net        {Mary.Friel@exchangeserverpro.net}       Obfuscate
....

You can also search a remote server using the -Server parameter. This is useful when you are running the search from your own admin workstation or a separate management server.

[PS] C:\>Get-MessageTrackingLog -Server HO-EX2010-MB2

The Get-MessageTrackingLog cmdlet also accepts input from the pipeline. This is a very convenient way to perform searches on multiple servers at once. For example to search all Hub Transport servers at once:

[PS] C:\>Get-TransportServer | Get-MessageTrackingLog

Sometimes you may wish to search the transport servers only within a particular site. Because I might need to work with that list in a few different commands I’ll usually collect those into a variable first, for example all Hub Transport servers in the “HeadOffice” site:

[PS] C:\>$hubs = Get-ExchangeServer | Where {$_.Site -like "*HeadOffice" -and $_.IsHubTransportServer -eq $true}

I can then pipe that array of servers into the Get-MessageTrackingLog cmdlet.

[PS] C:\>$hubs | Get-MessageTrackingLog

Remember Default Resultsize of 1000

Often you will be running message tracking log searches that return a lot of results. However, by default the cmdlet will return only 1000 results.

Because of this you should try to get in to the habit of using the -Resultsize parameter to return unlimited results when running Get-MessageTrackingLog.

[PS] C:\>Get-TransportServer | Get-MessageTrackingLog -Resultsize unlimited

Run Long Queries Once by Collecting Results in a Variable

When you’re performing investigative searches of your message tracking logs, particularly across multiple servers, those queries can take a long time to return the results. If you then found you needed to adjust the query, for example to be more specific, or to format the results in a different way, you have to wait a long time for the query to run a second time as well.

So a good tip is to always collect your query results into a variable, particularly very broad queries that take a long time to run, so that you can pick apart the collected data without having to re-run the query.

For example, if I want to investigate reports of email problems sending to Alan Reid, I can run one broad query across all Hub Transport servers and collect the results in a variable I will call $msgs.

[PS] C:\>$msgs = Get-TransportServer | Get-MessageTrackingLog -Recipients "Alan.Reid@exchangeserverpro.net" -resultsize unlimited

I’ve now got thousands of records that I can begin to filter and dissect in different ways without having to re-run my query.

[PS] C:\>$msgs.count
13297

For example I can find the top 10 senders to Alan Reid within seconds, instead of re-running the entire Get-MessageTrackingLog search again.

[PS] C:\>$msgs | Group-Object -Property Sender | Select-Object name,count | sort count -desc | select -first 10 | ft -auto

Name                                  Count
----                                  -----
Andrea.Sharma@exchangeserverpro.net     110
Richard.Bennett@exchangeserverpro.net   108
Judy.Mollo@exchangeserverpro.net        104
Ferzana.King@exchangeserverpro.net      102
Debra.Lowe@exchangeserverpro.net        100
Nicola.Noad@exchangeserverpro.net       100
Diane.Hall@exchangeserverpro.net         96
Caroline.Ball@exchangeserverpro.net      96
Chris.Majumdar@exchangeserverpro.net     96
Hugh.Sharma@exchangeserverpro.net        96

According to Measure-Command the above command took 1.3 seconds to complete, whereas the re-running the full log search again would take 47.4 seconds. By collecting the results into a variable the first time all of the subsequent analysis of that data is able to be performed much faster.

Each Single Message is Multiple Log Entries

You’ll notice as you begin looking at message tracking logs that each individual email message generates multiple log entries. This is because each message goes through multiple events in the process of getting from sender to recipient, that the number of events will vary depending on how the message needs to be routed throughout your organization, as well as whether it is successfully delivered or not.

So a single email message may record a series of events such as:

EventId  Source   Sender                            Recipients                        MessageSubject
-------  ------   ------                            ----------                        --------------
RECEIVE  SMTP     Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish
DEFER    STORE... Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish
DUPLI... STORE... Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish
RECEIVE  STORE... Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish
DELIVER  STORE... Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish
RESUBMIT DUMPSTER Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish
TRANSFER STORE... Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish
SEND     SMTP     Famida.Ghtoray@exchangeserverp... {Alan.Reid@exchangeserverpro.net} Prolix apropos embellish

Dealing with System.String[] in Exported Message Tracking Log Data

At some stage you will want to export some message tracking log data to CSV for further analysis in Excel. If you were to pipe the output above into the Export-CSV cmdlet you will notice that some of the fields, such as Recipients, will appear as System.String[] in the output file.

problem”]

The Export-CSV System.String problem

To resolve this issue you need to first pipe your Get-MessageTrackingLog results into Select-Object and select the Recipients and RecipientStatus fields like this:

... | Select-Object eventid,sender,timestamp,@{Name="Recipients";Expression={$_.recipients}},@{Name="RecipientStatus";Expression={$_.recipientstatus}},messagesubject | Export-CSV filename.csv

This will give you the correct exported data.

Correct Recipients and RecipientStatus output

Examples of Message Tracking Log Searches

In the next part of this article series I’ll cover some specific examples of message tracking log searches using PowerShell.

Related posts:

• Reporting Exchange Server 2010 Message Tracking Event IDs with PowerShell
• Calculate Hourly Email Traffic using Message Tracking Logs and Log Parser
• Calculate Daily Email Traffic using Message Tracking Logs and Log Parser
• Reporting Exchange Server 2010 Message Tracking Event IDs with Log Parser
• Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

This article Searching Exchange Server 2010 Message Tracking Logs with PowerShell is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

I have been trying to get a script that can log into mailboxes automatically. The reason is that I have 500 mailboxes and when I attempt to query their statistics I get an error that the mailbox has never been logged into and therefore can’t generate any stats.

Let’s take a quick look at the issue itself. When a new mailbox is created and you attempt to use Get-MailboxStatistics to query the mailbox, you will receive a warning similar to this.

WARNING: The user hasn’t logged on to mailbox ‘exchangeserverpro.net/Company/Branch Office/Users/Blake Johnson’
(’0971ff8e-d6d1-4bd6-98b9-384b35103a2d’), so there is no data to return. After the user logs on, this longer appear.

In itself this is not a problem, but it might produce undesirable results for some mailbox reporting tasks, or at the very least make them a little more difficult.

The idea of creating a script that automatically logs on to new mailboxes is one approach to solving the problem. However it is probably more difficult than another solution which is also available.

That other solution is to simply send the mailbox an email. Once you do that the Get-MailboxStatistics cmdlet will return a result for the mailbox like this:

[PS] C:\>get-mailbox blake.johnson | Get-MailboxStatistics | ft -auto

DisplayName   ItemCount StorageLimitStatus LastLogonTime
-----------   --------- ------------------ -------------
Blake Johnson 1                 BelowLimit

But is it practical to send 500 mailboxes an email? If it is a test lab you could simply add them all to one distribution group, and send that group an email. It would take just a few moments.

If it is a production system and new mailboxes are created regularly, you can automate the task. MVP Pat Richard has written a PowerShell script that can be run as a scheduled task to automatically send a welcome email to new mailboxes. You can customize the welcome message to provide useful information to new users on the network. It really is a great idea if you ask me, plus it solves this issue with mailbox reporting. Check out Pat’s script here.

Related posts:

• Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports
• How to Calculate Exchange 2010 Mailbox Sizes with PowerShell
• How to Reconnect a Disconnected Mailbox in Exchange Server 2010
• How to Move Exchange Mailboxes in a Text File using PowerShell
• Counting Exchange Server 2010 Mailboxes with PowerShell

This article The User Hasn’t Logged on to Mailbox So There is No Data to Return is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Having realistic email traffic within a test lab environment means you can do such real world activities as:

• test backup and recovery scenarios
• learn how to use message tracking logs
• test archiving solutions

In the past I’ve used some simple VBScripts that just sent random messages via SMTP as a way to fill up test lab mailboxes. That approach had some disadvantages though. The scripts I wrote only sent a stream of email messages at a single rate rather than at varying rates through the day as you would see in the real world. They also filled up inboxes only, never putting the messages in the Sent Items folder for the From address.

So last week I got to work creating a new PowerShell script to generate the email traffic. I tracked some of the development in the forums and can now share the complete script here.

This script does require some setting up before you run it, so please read the instructions to get it working in your test lab. I have only written and tested this script for Exchange 2010 training lab environments on the assumption that most people will be training for the latest version of Exchange.

Before we go further let me be absolutely clear that this script is for test lab environments only. Under no circumstances should you attempt to run this script in a production environment.

Using the Start-MailGen.ps1 Script in Your Test Lab

The scripts uses the Exchange Web Services Managed API so the first step is to download and install that on your test lab server.

EWS Managed API

Next, download the script and extract the three files to your server. I placed mine in C:\Scripts\MailGen.

Download the script file here: Start-MailGen.ps1 (downloaded 292 times so far)

Open the Start-MailGen.ps1 file in the PowerShell editor or in Notepad and check the following items.

The $dllfolderpath variable is set to the default installation path for the EWS Managed API v1.1. If you install a different version, or to a different path, update this variable.

#Path to the Exchange Web Services DLL
$dllfolderpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"

The script uses a switch statement to determine how many emails to send each hour of the day. These values are what I use but you can change them up or down to suit your test lab. The hours 6am to 7pm are individually specified, and then the default value at the end is used for the remaining hours of the day.

06 {$sendcount = 50}
07 {$sendcount = 80}
08 {$sendcount = 600}
09 {$sendcount = 600}
10 {$sendcount = 800}
11 {$sendcount = 1000}
12 {$sendcount = 600}
13 {$sendcount = 600}
14 {$sendcount = 800}
15 {$sendcount = 800}
16 {$sendcount = 900}
17 {$sendcount = 400}
18 {$sendcount = 200}
19 {$sendcount = 80}
default {$sendcount = 10}

You can just specify even numbers like the above because the script varies the send count further by adding a random number each time. This will give you a realistic level of email traffic through the different hours of the day.

Sample email traffic graph

The service account that will be running the script needs impersonation rights granted to it. I run mine as Administrator since it is just a test lab. Open the Exchange Management Shell and run the following command to grant the impersonation rights.

[PS] C:\>New-ManagementRoleAssignment -Name:impersonationAssignmentName -Role:ApplicationImpersonation -User:administrator

You may also need to set your script execution policy to unrestricted.

[PS] C:\>Set-ExecutionPolicy Unrestricted

Also, as the script file was downloaded from the internet you may need to right-click the file and choose Properties, and then click the Unblock button.

The script also depends on the Active Directory remote administration tools. These should be installed already on an Exchange 2010 mailbox server, but if you’re running the script from a non-Exchange server you may need to install them.

Finally, to start generating email traffic open the Exchange Management Shell and run the script.

[PS] C:\Scripts\Mailgen>.\Start-MailGen.ps1

The script begins to send email and will show a progress indicator.

Start-MailGen.ps1 running

The script will select a random sender and recipient from the available mailboxes in your test lab environment, and then construct a random email message using the two files that are provided with the script.

After sending the applicable number of emails for that hour of the day the script will sleep for 5 minute blocks until it reaches the next hour, and will start sending again.

You can leave the script running for several days if you wish, or set it as a scheduled task to ensure that it starts up again if the server is rebooted.

Related posts:

• Dealing with Exchange Server Update Rollups and Forefront Protection for Exchange
• How to Health Check an Exchange 2010 Mailbox Server
• How to List all Users Who Have Access to Other Exchange Mailboxes
• How to Generate a HTML Report of Your Exchange 2010 Environment
• PowerShell Script: Check Exchange Mailbox Database Last Backup Time

This article PowerShell Script to Generate Email Traffic in a Test Lab Environment is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

For several versions of Exchange Server now we’ve had the capability to manage email addresses for recipients by using policies. In Exchange Server 2010 these are referred to as Email Address Policies.

In this article I’ll provide an overview of the key concepts of email address policies and demonstrate some examples of how they can be used.

The Exchange Server 2010 Default Email Address Policy

Any Exchange 2010 organization will have one email address policy named “Default Policy”. You can view this in the Exchange Management Console under Organization Configuration -> Hub Transport, in the Email Address Policies tab.

Exchange 2010's default email address policy

One of my gripes with managing email address policies in the console is that you can’t open a Properties view to see how they are configured. However you can right-click and choose Edit to achieve the same outcome.

The first thing you’ll notice that the default policy is not scoped to any particular recipient container, so it will apply to any object in Active Directory. The other thing you’ll notice is that the policy will apply to “All recipient types”, not a limited subset of the available types such as mailboxes, contacts, or groups.

Scope of the default email address policy in Exchange 2010

At the next dialog you get a chance to preview the results of the conditions in the email address policy.

Previewing the results of email address policy conditions

If you preview the default email address policy you should see all mail-enabled objects in the organization returned.

At the next dialog you’ll see the email addresses that the policy will apply to those recipients that fall within the scope of the policy.

Email addresses applied by the default email address policy

So the outcome of this policy is that it will apply an email address of alias@exchangeserverpro.net (because alias is used if nothing else is specified) to any recipient type.

When are Exchange 2010 Email Address Policies Applied?

But when does the email address policy apply? At the next dialog we can see the schedule options for the email address policy.

Email address policy schedule options

The options we can choose from are:

• Do not apply – the email address policy will be created (or edited) but not applied to the recipients that fall within its scope
• Immediately – the email address policy will be applied immediately to the recipients that fall within its scope
• At the following time – the email address policy will be applied at the nominated time. This is convenient if you are preparing the email address policy in advance of a scheduled change (such as the rebranding exercise I mentioned earlier)

Something you need to be aware of is that no matter which of the above options you pick right now, the email address policy will continue to be assessed and applied to recipients on an ongoing basis in the future each time a recipient is created or modified.

So for example when a new mailbox is created the email address policies are assessed and applied accordingly. Similarly, if you modify an existing mailbox user, for example to change their alias or move it to another database, the email address policies will be reassessed for that recipient.

For that reason you want to be sure that any email address policy that exists in your organization is ready to be applied to recipients.

Creating a New Email Address Policy with the Exchange Management Console

Click New E-Mail Address Policy to start creating a new policy.

New Email Address Policy

For this example I’ve narrowed the scope of the email address policy to just one particular OU for “Example Corp”, the new business entity.

Select recipient container for new email address policy

If that particular OU contained users in other companies I could also narrow the scope down based on Company or Department attributes, but in this example I don’t need to. Clicking Preview shows me the one user that exists in that OU so far.

Email address policy conditions

Next I’ll add an SMTP address of %m@example.com to the policy (%m = “alias”).

Configuring SMTP addresses for an email address policy

Note that whatever domain you choose to use here needs to have already been configured as an Accepted Domain for the organization. If you haven’t already done so you can switch back to the Exchange Management Console and add the domain without having to cancel your new email address policy wizard.

Finally I will choose not to apply the email address policy just yet, so that I can demonstrate some scenarios for this.

Choosing when to apply the email address policy

Finally, click New to create the email address policy. If it all goes well you’ll see a successful completion message.

Completing the new email address policy wizard

Note that the completion dialog reveals the PowerShell commands used behind the scenes to perform the task. This will be relevant later when we look at an example of creating an email address policy in PowerShell.

Applying Email Address Policies

Now let’s check the results. Because I chose not to apply the policy yet the user Amy Lawrence does not have an @example.com email address yet.

Email addresses before the policy is applied

If I move another mailbox user into the same OU, they also do not have the email address policy applied.

User moved into OU

Jo Rigby’s email addresses haven’t changed just because her OU membership changed.

No change to email addresses yet

However, if I modify Jo Rigby’s recipient properties, such as adding the new company name, and apply that change…

Modifying recipient properties to trigger email address policies

…the new SMTP address is immediately applied by the policy, because modifying and saving any change to a recipient triggers policy assessment.

SMTP addresses after email address policy is applied

If I simply wish to apply the email address policy to all of the users in that OU I can right-click the policy and choose Apply, and choose to apply it immediately or at a scheduled time.

Manually applying an email address policy

Now Amy Lawrence also has the new @example.com email address without me having modified any of her other recipient properties, because I manually triggered the application of the policy.

SMTP addresses after email address policy is applied

You may wonder how primary SMTP address is determined when two policies are potentially valid for a recipient. The answer to that question is in the priority value of each policy. The policy with the highest priority will apply, but only that one policy applies.

For example, new user Bob Winder in the Example Corp OU gets mailbox-enabled and only receives an @example.com SMTP address from the “Example Corp” policy, but doesn’t receive an @exchangeserverpro.net address from the default policy that is of a lower priority.

SMTP address for a new mailbox user

So each policy needs to contain all of the SMTP addresses that you intend those recipients to receive, so that new recipients get them all. You can’t rely on different email address policies to apply cumulatively.

Note: Email Address Policies are Additive Only

You may have noticed in the examples above that the prior SMTP address of @exchangeserverpro.net was not removed from the mailboxes, it was simply changed to being a secondary email address.

This is due to the behavior of email address policies in that they are additive only. An email address policy will not remove or overwrite an email address on a recipient.

If the recipient falls out of scope of the email address policy they will not have any email addresses removed from the account, though their primary SMTP address may change when a different policy applies. In the case of Jo Rigby, if she is moved out of that OU and her company attribute changed again (or any other modification made to trigger policy assessment) she reverts to an @exchangeserverpro.net primary SMTP address, but retains @example.com as a secondary address.

SMTP address changed after policy no longer applies

Nor will the removal of the email address policy entirely cause recipients to lose those email addresses.

Removing an email address policy

Note that removing a policy causes those recipients to assess policies again. Amy Lawrence’s primary SMTP address changed back to @exchangeserverpro.net with no other recipient modification or manual applying of other policies required, but again she retained the @example.com secondary address.

SMTP addresses after email address policy is removed

Creating a New Email Address Policy with the Exchange Management Shell

There will be times when you find the options available in the console when creating a new email address policy are not suitable for your particular scenario. In those cases you can use the Exchange Management Shell to create a more specific filter for the email address policy.

Email address policies are created using the New-EmailAddressPolicy cmdlet. This cmdlet has a -RecipientFilter parameter that opens up a whole lot more possibilities (the documentation refers to Exchange 2007 but is unchanged for Exchange 2010) for defining the scope of your email address policies. Just be aware that it can’t be used in combination with some other parameters, all of which is spelled out here.

So let’s look at one example of creating an email address policy in PowerShell using the capabilities of -RecipientFilter.

To begin with I’ve removed the policy I created in the console earlier, and manually removed the @example.com addresses from those mailboxes to start over with a clean slate.

Example Corp users in their OU

Now I’ll create the email address policy, using a recipient filter that checks display names for the string “(Example Corp)”. The new policy will have the following properties:

• A name of “Example Corp”
• A priority of 1
• An email address template of “SMTP:%m@example.com” (the upper-case SMTP defines the primary SMTP address, lower-case would be a secondary SMTP address)
• A recipient filter for the DisplayName attribute of “*(Example Corp)” (the * is a wildcard)

Running that as a command in the Exchange Management Shell looks like this:.

New-EmailAddressPolicy -Name "Example Corp" -Priority 1 -EnabledEmailAddressTemplates "SMTP:%m@example.com" -RecipientFilter {DisplayName -like "*(Example Corp)"}

Name                                    Priority                                RecipientFilter
----                                    --------                                ---------------
Example Corp                            1                                       DisplayName -like '*(Example Corp)'

Now the new email address policy has been created, but as before it has not yet applied to any recipients. To trigger the policy for the three Example Corp users I’m going to modify their display names to append “(Example Corp) to them. I’m just doing them individually here but you could script it if you had a lot of mailbox users to modify.

[PS] C:\>Set-Mailbox Jo.Rigby -DisplayName "Jo Rigby (Example Corp)"

Jo now has the @example.com SMTP address assigned by the new policy.

[PS] C:\>Get-Mailbox Jo.Rigby | select displayname,emailaddresses | fl

DisplayName    : Jo Rigby (Example Corp)
EmailAddresses : {SMTP:Jo.Rigby@example.com, smtp:Jo.Rigby@exchangeserverpro.net}

And if I change her display name so it no longer has “(Example Corp)” in it, she reverts to the primary SMTP address @exchangeserverpro.net and retains the @example.com as a secondary SMTP address.

[PS] C:\>Set-Mailbox Jo.Rigby -DisplayName "Jo Rigby"

[PS] C:\>Get-Mailbox Jo.Rigby | select displayname,emailaddresses | fl

DisplayName    : Jo Rigby
EmailAddresses : {SMTP:Jo.Rigby@exchangeserverpro.net, smtp:Jo.Rigby@example.com}

Hopefully this article has provided you a good understanding of how email address policies work in Exchange Server 2010, and given you some ideas on how you can use them in your own Exchange organization.

Related posts:

• How to Set Up an Automated Exchange 2010 Database Backup Alert Email
• Dealing with Exchange Server Update Rollups and Forefront Protection for Exchange
• Reporting Exchange Server 2010 Message Tracking Event IDs with PowerShell
• Searching Exchange Server 2010 Message Tracking Logs with PowerShell
• The User Hasn’t Logged on to Mailbox So There is No Data to Return

This article Exchange Server 2010 Email Address Policies is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Now it is pretty easy to get the sizes for Exchange mailboxes and to handle the formatting of the Exchange 2010 mailbox statistics so that they are easier to perform calculations on, but it gets a bit boring running those commands day after day.

Even worse, after running the commands to create a CSV report I still had to open that in Excel, remove the unwanted details, use Excel formulas to convert the values from bytes to megabytes, sort them into order, and so on. Again not difficult, just boring after doing it hundreds of times.

So I created a PowerShell script, Get-MailboxReport.ps1, to do all of the heavy lifting for me, and I’m sharing that script with you here.

Download the script file here: Get-MailboxReport.ps1 (downloaded 3603 times so far)

Let’s take a look at how the script works. Here if a video to demonstrate:

I’ve included help information within the script itself so you can use Get-Help to discover how to run the script.

[PS] C:\Scripts\demo>Get-Help .\Get-MailboxReport.ps1

NAME
    C:\Scripts\demo\Get-MailboxReport.ps1

SYNOPSIS
    Get-MailboxReport.ps1 - Mailbox report generation script.

SYNTAX
    C:\Scripts\demo\Get-MailboxReport.ps1 [-database ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-file ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-server ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-mailbox ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-all] []

DESCRIPTION
    Generates a report of useful information for
    the specified server, database, mailbox or list of mailboxes.
    Use only one parameter at a time depending on the scope of
    your mailbox report.

RELATED LINKS
    For more script details, a video demo, or to give feedback please go to:

http://exchangeserverpro.com/powershell-script-create-mailbox-size-report-exchange-server-2010

REMARKS
    To see the examples, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -examples".
    For more information, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -detailed".
    For technical information, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -full".

Depending on which parameter you use the output will vary.

• If you use the -mailbox parameter to query a single mailbox, then the output will appear in the console window. I don’t really see the need to output a single mailbox’s details to a CSV file.
• If you use any of the other parameters, -server, -database, -file, or -all, the output will be written to a CSV file in the same folder you’re running the script from.
• You can use the optional -filename parameter to specify your own output file name

Once you’ve generated the CSV report you can open it with Excel and begin to analyze the data.

Download the script file here: Get-MailboxReport.ps1 (downloaded 3603 times so far)

Change Log:

• 6/02/2012 – V1.0 – Initial version
• 27/02/2012 – V1.1 - Improved recipient scope settings, exception handling, and custom file name parameter.

Related posts:

• How to Move Exchange Mailboxes in a Text File using PowerShell
• Reporting Exchange Server 2010 Message Tracking Event IDs with PowerShell
• Searching Exchange Server 2010 Message Tracking Logs with PowerShell
• The User Hasn’t Logged on to Mailbox So There is No Data to Return
• Using Test-Mailflow with Exchange 2003 Servers

This article Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports is © 2012 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

That means that often when you write a PowerShell script you need to account for servers running different versions and adjust accordingly. It can turn a simple scripting exercise into a big task.

Recently I was looking at ways to include our Exchange 2003 servers in some monitoring scripts that are already running for Exchange 2007/2010 servers. I wanted to perform a mail flow test for the Exchange 2003 servers, because that is a test that (if successful) very quickly confirms a lot of the elements involved in email availability are in fact healthy (ie the server is up, reachable, accepting SMTP connections, processing mail queues, the Information Store is running, and more).

For Exchange 2007/2010 the Test-Mailflow cmdlet can be used for these. You can build it into a health check script if you want to. But if you try to run it against an Exchange 2003 server you’ll get an error like this:

[PS] C:\>Test-Mailflow -Identity EX2007SERVER -TargetMailboxServer EX2003SERVER

Test-Mailflow : "EX2003SERVER" is running a previous version of Exchange and does not support this task.
At line:1 char:14
+ Test-Mailflow <<<<  -Identity EX2007SERVER -TargetMailboxServer EX2003SERVER
    + CategoryInfo          : InvalidArgument: (:) [Test-Mailflow], OperationOnOldServerException
    + FullyQualifiedErrorId : 642F2C5C,Microsoft.Exchange.Monitoring.TestMailFlow

However, if the Exchange 2003 server is in the same organization you can use a different parameter with Test-Mailflow to achieve the same result. All you need is an email address for one of the mailboxes on the Exchange 2003 server. You might want to create a mailbox on each of your Exchange 2003 servers (or even each of the databases on those servers) specifically for this purpose.

Then you simply run the Test-Mailflow cmdlet with the -TargetEmailAddress parameter instead of the -TargetMailboxServer parameter.

[PS] C:\>Test-Mailflow -Identity EX2007SERVER -TargetEmailAddress EX2003SERVER_test@domain.com

TestMailflowResult         MessageLatencyTime          IsRemoteTest
------------------         ------------------          ------------
Success                    00:00:19.5014893            True

As you can see this is a nice, simple way to test your Exchange 2003 server health using PowerShell.

Related posts:

• PowerShell: Configuring Settings on Multiple Exchange Mailbox Databases
• How to Set Up an Automated Exchange 2010 Database Backup Alert Email
• Reporting Exchange Server 2010 Message Tracking Event IDs with PowerShell
• Searching Exchange Server 2010 Message Tracking Logs with PowerShell
• Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

This article Using Test-Mailflow with Exchange 2003 Servers is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

If you’re like me then you get asked this question at least once per day. Of course there usually isn’t anything wrong with our Exchange servers but once the question has been asked then you have no choice but to investigate and confirm that everything is okay.

In this article I’m going to demonstrate how you can quickly check the health of your Exchange Server 2010 mailbox servers, and share a script with you that can help to speed up this task.

Exchange Server 2010 has a series of PowerShell cmdlets that make it easy to do a health check of mailbox servers. For example, we can:

• Run Test-Servicehealth to check the required services are all running
• Run Get-MailboxDatabase to check whether the mailbox databases are mounted
• Run Test-MapiConnectivity to verify that the databases are responding to MAPI requests
• Run Test-MailFlow to confirm that email is able to pass successfully between two servers
• Run Get-MailboxDatabaseCopyStatus for DAG members to check the database copy status, queues, and content indexes

That’s quite a few cmdlets to run, especially if we’ve got more than one mailbox server in the organization. And of course each of those cmdlets needs to run and show you output that you need to interpret.

I like to make life a bit easier and use PowerShell scripts to speed up these types of tasks. So naturally I put together a script for performing all of the above tests (and a few more) on my mailbox servers and display a nice simple colour-coded output so that I can tell at a glance whether there might be a problem.

This isn’t designed to do a diagnosis of any problems, it just checks the fundamentals and gives me a simple pass/fail and a few other indicators that I can then troubleshoot further if necessary.

Download the script file here: Test-MailboxServer.ps1 (downloaded 1770 times so far)

Extract Test-MailboxServer.ps1 from the Zip file and run it in your Exchange Management Shell to see output such as this:

If you have any questions or bugs to report please let me know in the comments below.

Change log:

• V1.0, 20/11/2011 – Initial version
• V1.1, 10/01/2011 – Fixed $null’s, bugs with Recovery DBs, and ping failure scenarios

Related posts:

• PowerShell Script: Check Exchange Mailbox Database Last Backup Time
• How to Set Up an Automated Exchange 2010 Database Backup Alert Email
• Dealing with Exchange Server Update Rollups and Forefront Protection for Exchange
• PowerShell Script to Generate Email Traffic in a Test Lab Environment
• How to List all Users Who Have Access to Other Exchange Mailboxes

This article How to Health Check an Exchange 2010 Mailbox Server is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com