A Blog About Exchange & Office 365

Menu

Exchange 2013 PowerShell Scripts – A Practical Guide – Part 1

While exploring possible topics for a User Group Presentation I came up with the idea of promoting the use of PowerShell Scripts for use with Exchange Server 2013. Now while this may seem like a novel topic, it is nevertheless a good topic because so many on-prem support engineers are failing to see the benefit of the scripts in the Scripts directory, scripts written by MVPs or in the TechNet Wiki, let alone creating their own scripts. So this article is going to serve as a primer for those who are not using the scripts, afraid to use the scripts or just don’t know they exist. In part one (1) of this series I will cover some of the scripts included with Exchange Server 2013.

Included Scripts
With each version, and sometimes with each update, of Exchange Server, Microsoft adds more scripts for working with Exchange Server. Exchange Server 2013 CU5 currently has 80 included scripts. These script are used for a multitude of functions in Exchange. From getting Anti-Spam reports to disabling features in Exchange, to putting a server into maintenance mode for patching. Let’s explore some sample included scripts and see what can be done with them.

In the below fur screen shots you can see the four different parts of these scripts. Description. Parameters. Body. Signature.

When running these scripts, make sure to review the description to determine if it is the script you need. Then review any Parameters that might be defined for the script as well.

If your Exchange org does not have an Edge Transport, an external filtering service or an internal filter/appliance, then Microsoft recommends using the additional agents installed using this script to enable better message hygiene.

When you run the Install-AntiSpamAgents.ps1 script, an additional five Transport Agents are added to the original four:

These agents are similar, if not identical, to the ones that were available in Exchange Server 2007 / 2010. For more information on each agent enabled see the below list:

About 75-90% of my clients won’t utilize these extra agents due to either having an appliance like Sopho’s Email appliance:

Or they utilize an outside vendor like Mimecast, Microsoft’s EOP, or MessageLabs.

These vendors all provide some sort of email scanning and can be much more effective that the built-in agents included in this script. Some agents are effective shielded or are of no value as the third-party is already using a similar function / feature.

Get Anti-Spam Statistics
For this category there are quite a few useful scripts that are provided with Exchange Server 2013:

get-AntispamFilteringReport.ps1

get-AntispamSCLHistogram.ps1

get-AntispamTopBlockedSenderDomains.ps1

get-AntispamTopBlockedSenderIPs.ps1

get-AntispamTopBlockedSenders.ps1

get-AntispamTopRBLProviders.ps1

get-AntispamTopRecipients.ps1

In order for these scripts to be useful, the Exchange Server needs to have the Anti-Spam agents installed. This enables the various agents and logging needed in order to generate any useful results. As a side note, if these scripts are run in their default configuration an error finding the Agent Logs will show up in red in the PowerShell window:

The location of the Agent Logs are incorrectly configured in these scripts. The correct directory should be “%Exchange Installed Directory%\TransportRoles\Logs\FrontEnd\AgentLog”

These logs provide useful reports about the SMTP traffic that is flowing through your Exchange organization.
get-AntispamFilteringReport – Creates reports based on the type of criteria you are examining – messagesrejected, messagesdeleted, connections and messagesquarantined .
Get-AntispamSCLHistogram.ps1 – Report on how many messages that Exchange has received at the various SCL levels (0-9) as well as any messages that were classified.
get-AntispamTopBlockedSenderDomains – Creates a report of which domains have sent your organization the most SPAM.
Get-AntispamTopBlockedSenderIPs – Enumerates the top SMTP servers that have connected to Exchange (external and internal connections).
get-AntispamTopBlockedSenders – Top 10 report of the biggest spammers.
get-AntispamTopRBLProviders – Top 10 report of your most effective RBL providers.
get-AntispamTopRecipients – Report of the top receivers of SPAM in your organization.

Redistribute Active Databases
Commonly used after patching a multi-node Exchange 2013 DAG cluster. This script can also be used to redistribute databases in a failover testing scenario where a complete site has been failed to another site. The end result is to distribute mailboxes databases among the DAG members. This ensures that no one (1) server will be overloaded with client request because of an uneven distributed database count. The script uses a few parameters to make the redistribution of the databases more intelligent:

BalanceDbsByActivationPreference When this option is specified, the script attempts to move databases to their most preferred copy (based on activation preference) without regard to the Active Directory site.

BalanceDbsBySiteAndActivationPreference When this option is specified, the script attempts to move active databases to their most preferred copy, while also trying to balance active databases within each Active Directory site.

To illustrate how this works, I created a test lab with four (4) Exchange 2013 servers that had five (5) databases with a copy on each server. I randomly selected the preference of the databases for each copy on each server. I then wanted to sort my databases. In my case I used the ‘balanceDbsByActivationPreference’ parameter because I only have one site to work with for Exchange/AD. In a more complex environment, the ‘BalanceDbsBySiteAndActivationPreference’ parameter might be needed instead.

So, if we review the screenshot, you will see that the script first figures out how many databases, servers and copies are involved in the process. After sorting through its algorithm for database distribution, databases are moved to a more optimal layout and the scripts asks you to confirm these moves. Once all the moves are complete, a report of what was moved is generated. In my test lab, only one database was moved and the other database were left as is. In a much larger environment (say 10 servers with 30 databases and 3 copies of each) this could take some time depending on what needs to be sorted out. In summary, keep this script in mind for DAG failovers, maintenance and general resorting that may be needed with the creation of large numbers of databases.

Part 2 of this series will cover scripts written by MVPs and other Exchange engineers as well as some scripts that I have written for Exchange.