PowerShell is key to the Future of Exchange Administration

• #exchange
• #PowerSE
• #PowerWF

Exchange 2010 Room List Report from PowerShell

Mike Pfeiffer has a nice write up on querying a list of conference rooms in Exchange 2010 using PowerShell.

If you work in an campus type of environment, where you have conference rooms spread out across multiple buildings or physical sites, you may have heard of the Room Finder functionality introduced with Exchange 2010 and Outlook 2010. The Room Finder allows users to easily locate a room resource when scheduling a meeting in Outlook. Instead of users having to scroll through the Global Address List (GAL) or try to guess which room resources are located in a particular location, they can select the appropriate room list, and see all of the available rooms.

Room lists are essentially just a special type of Distribution Group in Exchange. To populate the room list, you simply add one or more resource mailboxes to the group. After you’ve defined several room lists, you’ll probably get to the point where you need to generate a report listing all of the room lists and their associated resource mailboxes. The key to generating a report is to simply query the members of each distribution group that are designated as a room list.

(read more and view code)

• #powershell
• #exchange
• #powerwf
• #PowerSE

Exchange Managment using PowerShell and PowerSE

As I mentioned the other day, I’ve installed PowerWF and PowerSE on my Exchange Server so I could start building some real-world samples for Exchange administrators.  The first step was to get access to all of the native features that you get from the Exchange Management Shell.

Basically the Exchange Management Shell is essentially the PowerShell console with its own profile and some basic environment settings applied.  The Exchange Management Shell also automatically connects you to the local Exchange Server.

To achieve this in PowerSE or PowerWF, add this to the top of your script.

## EXCHANGE SETUP ###############################

$exchbin = (get-itemproperty HKLM:\SOFTWARE\Microsoft\ExchangeServer\v14\Setup).MsiInstallPath + "bin\"
. $exchbin"RemoteExchange.ps1"

connect-ExchangeServer -Auto

The RemoteExchange.ps1 file will set up your Exchange environment, and the connect-ExchangeServer -Auto will get a connection to your local Exchange server.  In PowerSE, be sure to add the Exchange PowerShell Module using the Plugins dialog.

Note: Using PowerShell Remoting is common way for managing Exchange Servers.  I’ll discuss this in more detail at a later date.

• #exchange
• #powershell
• #powerwf
• #PowerSE

PowerWF for Exchange

I installed PowerWF on our Exchange 2010 server today so that I could start creating some Exchange specific sample workflows.  I knew the Exchange PowerShell module had a lot of cmdlets, but I had forgotten that there were close to 1000.  The nice thing about PowerWF is that it makes it easy for me to investigate all of these cmdlets.

Expect me to post a lot of Exchange related posts in the coming days and weeks.  If you know of any great PowerShell scripts for Exchange, send them my way.  If, on the other hand, you have some Exchange Management use cases that you are sure could be solved with PowerShell and PowerWF if you only had the time, leave a comment and I’ll see what I can do.

• #powershell
• #powerwf
• #exchange

Setting Outlook Folder Permissions Using PowerShell

Seems like Exchange is underrepresented on PowerShell blogs, but not this week.  Jim Martin has a post that tells you how to set folder permissions in Outlook using PowerShell.

When I was an Exchange Administrator, I was asked numerous times to “grant this person access to my folder and all of its subfolders”. Prior to Exchange 2010 there was no simple way to assign MAPI permissions to all of these Outlook folders. Exchange 2010 has added the Add-MailboxFolderPermission cmdlet which allows an administrator to now complete this task from the Exchange Management Shell.

You may also notice that Exchange 2010 provided another cmdlet, Get-MailboxFolder. When I saw this I thought “Wow! I can run the Get-MailboxFolder and pipe the Add-MailboxFolderPermission and I’m done.” Did you really think it would be that easy?

…

I was able to accomplish this task in two steps:

1. Get a list of folders from the mailbox
2. Add the permission to the folder

(read more)

I know I need to do this on some of our Outlook folders for other users.  I wish he would have included the final version of his script, but it looks easy enough to put together from the information provided.

• #exchange
• #powershell
• #PowerSE
• #powerwf

Exchange 2010 PowerShell One-Liner

Here is a link to a nice Exchange 2010 PowerShell One-Liner I stumbled across.  I would probably dump it to a grid view like this:

Get-MailboxDatabase -Status | select ServerName,Name,DatabaseSize,EdbFilePath,LogFolderPath| out-gridview

Or bring it into PowerWF and either format the results as HTML and send me a daily email, or send the data to SCOM.

• #exchange
• #powershell
• #PowerSE
• #powerwf
• #SCOM

Mailbox Size Report for Exchange

ExchangeServerPro.com has a PowerShell script that creates a simple report of mailbox sizes in Exchange.

One of the Exchange Server administration tasks I perform almost every day is creating mailbox size reports. There are a few different reasons that I create these reports, such as planning a mailbox migration project, responding to a storage capacity alert for a particular database, or providing a specific team of people with a report of their mailbox sizes.

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 to do all of the heavy lifting for me, and I’m sharing that script with you here. Let’s take a look at how the script works.

(read more)

I would probably make the report prettier and more useful in PowerWF by converting the output to HTML and then emailing it to myself every day or every week using the PowerWF agent.

• #powershell
• #exchange
• #powerwf

PowerShell for Microsoft Office 365

I figured it wouldn’t be to difficult to use PowerShell for Office 365 administration, but even though we use it, I haven’t taken the time to investigate it at all.  Looks like procrastination paid off; Axon-IT has done the prepreliminary work for me with an article called simply Microsoft Office 365 PowerShell.

It starts out as expected, by making a call to Get-Credetial, and using that credential ($LiveCred) to create a new PSSession to outlook.com and then using Import-Session.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange-ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection

Then the interesting part starts, showing you some of the cmdlets you can use, like adding or removing permissions.  Go give it a read.

• #exchange
• #office365
• #powershell
• #PowerSE

Bragging on PowerShell for Exchange

Tony Redmond at WindowsITPro has an article explaining why PowerShell is so awesome for Exchange Administrators.  The article does a decent job of selling the need for Exchange Administrators to start adding PowerShell to there world, but the one real gem of the article was borrowed from Mike Pfeiffer

For example, here’s a script posted by Exchang Servere MVP Mike Pfeiffer on his blog. This script might look complex, but when you boil it down to its basics, the script accepts an input parameter of one or more Client Access Servers (CAS) and then interrogates those servers to discover the number of unique users who are currently connected to the servers via RPCs (for example, Outlook users) or HTTP (Outlook Web App).

function Get-CASActiveUsers {
[CmdletBinding()]
param(
      [Parameter(Position=0, ParameterSetName=”Value”, Mandatory=$true)]
      [String[]]$ComputerName,
      [Parameter(Position=0, ParameterSetName=”Pipeline”, ValueFromPipelineByPropertyName=$true, Mandatory=$true)]
      [String]$Name
)

process {
      switch($PsCmdlet.ParameterSetName) {
               “Value” {$servers = $ComputerName}
                “Pipeline” {$servers = $Name}
       }
      $servers | %{
           $RPC = Get-Counter “\MSExchange RpcClientAccess\User Count” -ComputerName $_
           $OWA = Get-Counter “\MSExchange OWA\Current Unique Users” -ComputerName $_
          New-Object PSObject -Property @{
          Server = $_
          “RPC Client Access” = $RPC.CounterSamples[0].CookedValue
           “Outlook Web App” = $OWA.CounterSamples[0].CookedValue
      }
    }
  }
}

This script is valuable because it allows you to figure out the load that a CAS is under before you remove it from production to perform maintenance such as applying a service pack or roll-up update.

Read the whole article to see the whole case for PowerShell in Exchange environments.

• #powershell
• #exchange
• #powerwf
• #PowerSE

Active Directory Prep for Exchange 2010 Migration

Brien Posey at SearchExchange.com has a nice article on Preparing Active Directory using PowerShell as a preliminary step in Exchange 2010 migration.

Before performing an Exchange Server 2010 migration, you have to make sure Active Directory meets certain prerequisites. Thankfully, there are a number of PowerShell cmdlets to help you prepare your Active Directory forest for the move.

Validating your Active Directory forest
Before deploying Exchange Server 2010, your Active Directory forest must meet several different conditions:

• There must be at least one global catalog server running Windows Server 2003 SP1 or higher. This server must also exist in the same site that the Exchange server gets installed on.
• The Active Directory forest must run forest-functional level of Windows Server 2003 or higher.
• The domain you’re going to install Exchange in must be Windows Server 2003 or higher.
• The server with the schema master role must run Windows Server 2003 SP1 or higher.

Brien walks through each step, showing the PowerShell cmdlets to use (NOTE: you have to scroll to the bottom of the page to see the article).  It basically comes down to:

Get-ADForest | Format-List Name, GlobalCatalogs, ForestMode, Domains, SchemaMaster, Sites

Get-ADForest | Set-ADForestMode –ForestMode Windows2003Forest –Confirm:$True

Get-ADComputer –Filter {SamAccountName –EQ “<server name>$”} –Properties OperatingSystem, OperatingSystemServicePack | Format-List Name, OperatingSystem, OperatingSystemServicePack

Set-ADDomainMode –Identity <your domain’s FQDN> –DomainMode Windows2003Domain

Get-ExchangeServer | Format-List Name, ServerRole, Edition, AdminDisplayVersion

Basically this checks your current configuration and then sets it to the desired configuration. You should really read the whole article for details about what each cmdlet does and why these steps are performed.

• #exchange
• #Active Directory
• #powershell
• #PowerSE
• #powerwf