IN THIS CHAPTER

For years, Exchange administrators had two choices for performing repetitive tasks: Do them manually by using the graphical interface, or write scripts in complicated and time-consuming programming languages. Although these programming languages can be used to perform many routine tasks in an Exchange environment, they weren’t developed specifically with that purpose in mind. Hence, even the simplest task could take hundreds of lines of code.

Over time, the inability to automate tasks easily has proved to be one of the most frustrating aspects of managing an Exchange environment. Windows automation in general wasn’t sufficient because of Microsoft’s reliance on GUIs and little support for CLIs. This frustration became the motivation for the PowerShell team, led by Jeffrey Snover, to develop a CLI shell interface that enables administrators to do everything from the command line.

Around the same time PowerShell was being developed, the Exchange product team was designing the specifications for the next version of Exchange (E12, which became Exchange Server 2007). Initially, it seemed the team would develop yet another limited Microsoft Management Console (MMC) GUI as the Exchange management interface. However, the Exchange team decided to take a different course by embracing the concept of PowerShell-based management.

The result is that in Exchange Server 2007, configuration and administration are done with two new administrative tools: the Exchange Management Shell (EMS) and the Exchange Management Console (EMC). Both utilities rely on PowerShell to access and modify information and configuration settings in an Exchange Server 2007 environment.

The EMS is a command-line management interface for performing server administration and configuration. Because it’s built on a PowerShell platform, it can connect to the .NET runtime (also known as the Common Language Runtime, or CLR). So, tasks that previously had to be done manually in the management application can now be scripted, giving administrators more flexibility for repetitive tasks. Furthermore, administrators can manage every aspect of Exchange Server 2007, including creating and managing e-mail accounts, configuring Simple Mail Transport Protocol (SMTP) connectors and transport agents, and setting properties for database stores. Every management task in the Exchange environment can now be accomplished from the command line. In addition, the EMS can be used to check settings, create reports, provide information on the health of Exchange servers, and, best of all, automate tasks that need to be done frequently.

The EMC is an MMC 3.0 GUI utility for viewing and modifying the configuration of Exchange Server 2007 Organizations. Although similar to the Exchange System Manager (ESM) in previous Exchange versions, the EMC’s interface has been redesigned to be more organized and easier to learn. The EMC is limited in the scope of modifications administrators can make, so some configuration settings can be accessed only by using the EMS.

The EMS and EMC rely on PowerShell to accomplish management tasks. The EMC is a graphical interface that calls the EMS to perform tasks, and the EMS is a snap-in for PowerShell. Therefore, no matter which utility administrators use to create a report or modify a setting, they’re actually using PowerShell. While keeping with this concept, this chapter’s goal is to explain how the EMS and PowerShell can be used to manage an Exchange Server 2007 environment. Additionally, you review three PowerShell scripts that can be used to manage an Exchange Server 2007 environment.

The first Exchange Server 2007 script you examine in this chapter is the GetDatabaseSizeReport.ps1 script, which produces a report on the size of a mailbox database in an Exchange organization. The report contains the following information:

Here’s an example of the report GetDatabaseSizeReport.ps1 produces:

Any information about your network environment is helpful. However, when you’re using Exchange, an understanding of mailbox database sizes, their growth, free space on the hosting drive, and an overall picture of how mailbox databases work in a network environment can help you prevent potential problems.

This script was developed for companyabc.com, a small manufacturing company with a network consisting of several hundred users and two Exchange servers. Because of budget constraints, the IT department is made up of only one person. The limited budget has also prevented companyabc.com from purchasing and installing monitoring and reporting software for IT systems. As a result, the IT employee has only manual methods for ensuring the systems’ operational status and often doesn’t have time to do any proactive monitoring.

As a result, the Exchange mailbox databases have grown to the point that offline maintenance can no longer be done, and database disks tend to run out of space. After several near disasters, companyabc.com’s management has asked the IT employee to find a way to improve monitoring of the Exchange databases. Needing a quick, flexible, and cost-effective solution, the IT employee turned to scripting and requested the development of the GetDatabaseSizeReport.ps1 script.

A working copy of this script can be downloaded from www.informit.com/title/9789780768687187. Running this script doesn’t require any parameters be defined. However, an optional parameter, ExportFile, should have its argument set to the name of the CSV file where you want to export report data. Here’s the command to run the GetDatabaseSizeReport.ps1 script:

Figures 15.2 and 15.3 show the execution of the GetDatabaseSizeReport.ps1 script.

Figure 15.2. The GetDatabaseSizeReport.ps1 script being executed

Figure 15.3. The GetDatabaseSizeReport.ps1 script after being executed

The GetDatabaseSizeReport.ps1 script performs the following sequence of actions:

The first code snippet contains the header for the GetDatabaseSizeReport.ps1 script. This header includes information about what the script does, when it was updated, and the script’s author. Just after the header is the script’s only parameter ExportFile, shown here:

For the GetDatabaseSizeReport.ps1 script, only one function (Export-DataTable) is loaded, as shown in the next code snippet:

To perform the data export, the Export-DataTable function uses the .NET System.IO.StreamWriter class to create an object based on the .NET TextWriter class. The resulting TextWriter object ($LogFile) can be used to write an object to a string, write strings to a file, or serialize XML. In this script, $LogFile is used to dump the DataTable’s contents into the CSV export file (which is created along with $LogFile). To perform this task, the Export-DataTable function writes DataTable’s column names, separated with a comma (,) delimiter, to the CSV export file. Then, the function loops through each value in DataTable’s rows and writes these values to the CSV export file, separated with a comma (,) delimiter.

If Export-DataTable is called and a CSV export filename isn’t specified, this function makes use of a .NET System.Windows.Forms.SaveFileDialog class to construct a Save As dialog box for collecting the export file’s name and location (see Figure 15.4).

Figure 15.4. Windows Forms Save As dialog box

This example shows how PowerShell can use .NET-based Windows Forms to collect or display data.

In the next code snippet, variables that will be used later in the script are defined. In addition, the library file LibraryGen.ps1, which contains the script usage functions, is being dot sourced:

Next, the script checks to see if the user needed any usage help, as shown in the following code snippet:

In the next code snippet, the two DataTable objects are created. The first DataTable is the $ServersTable, which stores server information. The second DataTable is the $ReportTable, which stores the report information:

The Out-File cmdlet is used to create an error log and write header information to it. Then, the Get-ScriptHeader function is used to indicate to the script operator that the automation portion of the script has started, as shown here:

After displaying the script header to the user, the script’s next task is to get a list of mailbox servers using the Get-MailboxServer cmdlet. Then, for each server object in $MailboxServers variable, the script pings that server to determine its status. During this task, both the resulting status and the server’s name are written to a new row in the $ServersTable DataTable, as shown in the next code snippet:

The next task, as shown in the following code snippet, is to generate the final report. To do this, the script uses the Get-MailboxDatabase cmdlet to get the EdbFilePath for each Exchange server that is online. Then, for each mailbox database, the script uses WMI to collect the database size and free space for the drive on which the database is located. After collecting and formatting report information, the script then adds a new row to the $ReportTable DataTable that contains the database information, its size, and the drive free space:

Finally, the script writes the report to the PowerShell console using the Format-Table cmdlet and then exports the data to a CSV file using the Export-DataTable function, as shown here:

Administrators can use the GetEvent1221Info.ps1 script to search the Application event logs of Exchange Server 2007 mailbox servers and generate a report containing Event ID 1221 messages. Exchange administrators can use these messages to determine the amount of whitespace present in a database over a specified time span (number of days before the current day). Based on information gathered from Event ID 1221 messages, the report contains the following:

Here’s an example of the report GetEvent1221Info.ps1 produces:

This script was developed for companyabc.com, a marketing firm of 50 users who have large (4GB and up) Exchange mailboxes. It produces marketing packages consisting of digital images, which result in an average package size of more than 20MB. Because companyabc.com’s employees are scattered among many home offices and remote locations, they usually e-mail marketing packages to each other instead of posting them to a shared location.

Employees have been using their mailboxes as online file systems, so mailbox sizes have grown rapidly. Realizing that mailboxes of this size would be costly and difficult, companyabc.com’s Exchange administrator has requested that marketing content be saved locally to users’ hard drives and then deleted from their mailboxes. This practice has kept the Exchange databases from growing too quickly; however, the high deletion rate of large e-mail messages has created another problem: large areas of whitespace in Exchange databases.

The amount of whitespace is important because after an Exchange database grows, its size can’t be decreased until the administrator does an offline defragmentation. For example, a database has grown to 12GB, but users have deleted 3GB of messages. After an online defragmentation, Event ID 1221 logs report 3GB of whitespace. New messages written to the database use this whitespace, and the database doesn’t grow until that whitespace is exhausted.

The database still takes up 12GB on the hard drive, even though it contains only 9GB of data. A larger-than-necessary database can increase the time needed for backup and restore jobs. By reviewing Event ID 1221 messages, administrators can determine whether an offline defragmentation is needed to shrink the database in an effort to improve overall performance. Furthermore, with periodic review of Event ID 1221 logs, administrators can track a database’s average whitespace amount, which helps determine the growth patterns of actual data in a database. This information can be helpful in deciding when additional space needs to be allocated for a database.

With no budget available to purchase a suite of Exchange tools, companyabc.com requested the development of a script for monitoring the amount of whitespace in Exchange databases. The resulting script is GetEvent1221Info.ps1.

A working copy of this script can be downloaded from www.informit.com/title/9789780768687187. Running this script requires defining one parameter. The Days parameter should have its argument set to the time period (in number of days) for querying Event ID 1221 messages from mailbox servers. An optional parameter, ExportFile, should have its argument set to the name of the CSV file where you want to export report data. Here’s the command to run the GetEvent1221Info.ps1 script:

Figures 15.5 and 15.6 show the execution of the GetEvent1221Info.ps1 script.

Figure 15.5. The GetEvent1221Info.ps1 script being executed

Figure 15.6. The GetEvent1221Info.ps1 script after being executed

The GetEvent1221Info.ps1 script performs the following sequence of actions:

The first code snippet contains the header for the GetEvent1221Info.ps1 script. This header includes information about what the script does, when it was updated, and the script’s author. Just after the header are the script’s parameters, as shown here:

Next, as shown in the following code snippet the Get-RemoteEventLog function is loaded. This function is used to collect remote EventLog information from a machine using the System.Diagnostics.Eventlog class. Then, the Export-DataTable function is loaded which was discussed in the previous section.

In the next code snippet, variables that will be used later in the script are defined. In addition, the library file LibraryGen.ps1, which contains the script usage functions, is being dot sourced:

Next, the script checks to see if the script user needed any usage help. If no help is needed, the script then checks to see if the Days parameter has been defined. If this parameter has not been defined, the script then informs the script operator that the parameter is required and shows the script usage information, as shown in the following code snippet:

Then, in the next code snippet, the two DataTable objects are created. The first DataTable is the $ServersTable, which stores server information, and the second DataTable is the $EventsTable, which stores the report information:

The Out-File cmdlet is used to create an error log and write header information to it. Then, the Get-ScriptHeader function is used to indicate to the script operator that the automation portion of the script has started, as shown in the following:

The next task is to get a list of mailbox servers using the Get-MailboxServer cmdlet. Then, for each server object in $MailboxServers variable, the script pings that server to determine its status. During this task, both the resulting status and the server’s name are written to a new row in the $ServersTable DataTable, as shown in the next code snippet:

In the next code snippet, the script generates the final report. To do this, the script uses the DataTable Select method to create a collection of online server objects ($OnlineServers). Then, for each server in $OnlineServers object collection, the script uses the Get-RemoteEventLog function to retrieve all the Application event messages from that server. For each event message retrieved with an event ID of 1221, a new row is added to the $EventsTable DataTable that contains formatted information from the event message and the server’s name:

The script exports the report information from the $EventsTable DataTable using the Export-DataTable function:

With the ProvisionExchangeUsers.ps1 script, Exchange administrators can provision mail-enabled user accounts in Exchange Server 2007 environments quickly and easily based on information in a CSV import file. This file is structured as follows:

Here’s an example of the import file:

With some tweaking to the code in ProvisionExchangeUsers.ps1, the format of the CSV import file and the information for provisioning mail-enabled user accounts can be tailored to fit any environment. This flexibility is important to meet changing automation needs.

This script was requested by companyabc.com, a large technology company that’s in the process of completing several mergers. The company needs to provision many new mail-enabled user accounts. Because of the number of accounts to create and the varying information for each merger’s account-provisioning process, an automated method that could be changed to meet different needs is the best solution. To meet the flexibility requirements, companyabc.com’s IT department developed the ProvisionExchangeUsers.ps1 script.

A working copy of this script can be downloaded from www.informit.com/title/9789780768687187. Running this script requires defining three parameters:

Here’s the command to run the ProvisionExchangeUsers.ps1 script:

Figures 15.7 and 15.8 show the execution of the ProvisionExchangeUsers.ps1 script.

Figure 15.7. The ProvisionExchangeUsers.ps1 script being executed

Figure 15.8. The ProvisionExchangeUsers.ps1 script after being executed

The ProvisionExchangeUsers.ps1 script performs the following sequence of actions: