Summary: Microsoft Scripting Guy, Ed Wilson, shows that with a little knowledge of Windows PowerShell, it is easy to administrator products like Exchange Server.

Microsoft Scripting Guy, Ed Wilson, is here. Yesterday’s live meeting, Windows PowerShell Essentials for the Busy Admin went extremely well. I am looking forward to today’s live meeting because I will be talking about using the Windows PowerShell pipeline. I made an impromptu posting last week that has the abstracts for all five sessions, in addition to the registration links. All the sessions will be recorded, and made available via the Learn PowerShell page. But if at all possible, you should attend the live meeting—it is more fun, and you get to ask questions. The questions, for me anyway, are the highlight of the event.

The other day I was hanging out on Twitter, and I noticed a tweet about a particular blog post. I read the post, and I decided that I needed to meet the person who wrote it. As it turns out, the author, Derek Schauland, is a Microsoft MVP and a real fun person to talk with. During our conversation, he mentioned wanting to script mass changes to user’s aliases on an Exchange Server. He said that he needed aliases that would be formatted as First name <period> Last name, and not as First initial, Middle initial, Last name that he currently has. I thought it would be a cool script—but more than a script, I figured I could do it as a one-liner in Windows PowerShell.

PowerShell is PowerShell is PowerShell

I have said this before, but it bears repeating: PowerShell is PowerShell is PowerShell! This means that if you know Windows PowerShell, you can easily use it to perform other tasks. For example, because I know Windows PowerShell pretty well, I am familiar with the Windows PowerShell pipeline. I know that I can take the output from one cmdlet, and in general, pipe the input to another cmdlet (assuming the cmdlet accepts piped input). This means that all I need to do is find certain cmdlets, and then find other cmdlets, and then I can accomplish what I need.

Enable mailboxes for test users

For example, I have a group of test users in an organizational unit, and I need to enable their mailboxes. I happen to know that Microsoft Exchange Server ships with a cmdlet called Get-User. It stands to reason that Get-User will be able to get all the users in my test OU. I try it out, and it works. I next decide that a cmdlet to enable a mailbox on a user should be called something like Enable-Mailbox, and that it should accept pipelined input. Here is the command that I decided to try.

Get-User -OrganizationalUnit mytestou | Enable-Mailbox

I give it a whirl, and before I know it, I have enabled mailboxes for all five of my test users. The image that is shown here contains the command that I typed and the output from the command.

Verify the current email aliases

That went well. Now I want to take a look at the aliases for these users. I think the Get-Mailbox cmdlet will provide that information. I use the Up arrow to retrieve the previous command, and I change the Enable-Mailbox cmdlet to the Get-Mailbox cmdlet. The revised command is shown here.

Get-User -OrganizationalUnit mytestou | get-mailbox

The command and the associated output shown in the image that follows confirm my suspicion that the Get-Mailbox cmdlet does indeed provide the alias information.

Get-User -OrganizationalUnit mytestou | get-mailbox

Use PowerShell objects

One of the most powerful features of Windows PowerShell is that everything is an object. This means that instead of having to parse a bunch of text, all I need to do is find the property and access it. I just saw that the property I need exists on a mailbox object—it is the Alias property. At least I am assuming that I need the Alias property because most of the time, the property that appears at the head of a table is the actual property name that might be needed in other places.

Note   Occasionally, developers decide to change the column heading to make things more friendly, but this really annoys most advanced Windows PowerShell users. This goes back to the old problem that the fields that appear in Active Directory Users and Computers are not the names needed when writing an LDAP query. Luckily in Windows PowerShell, all I need to do is pipe the output to Get-Member if a command fails due to renamed table headers.

I also reason that if Get-Mailbox displays the information, then Set-Mailbox should set the information—it makes sense, right? I will give it a shot. But before I do, because I have not used Set-Mailbox very often, I decided to take a look at Get-Help on the Set-Mailbox cmdlet. The results are shown here.

OK, now I need to change the email aliases from First name Last name to First name <period> Last name. To do this, I use the Foreach-Object cmdlet to walk through the piped input. Inside the Foreach-Object cmdlet, I call the Set-Mailbox cmdlet. I use a format operator to create the pattern for the new email alias. The command is shown here. (This command is a one-line command, but I broke it for readability at the pipeline character. The % sign is an alias for the Foreach-Object cmdlet).

Get-User -OrganizationalUnit mytestou |

% {Set-Mailbox -Identity $_.identity -Alias ("{0}.{1}" -f $_.firstname, $_.lastname)}

No output displays from the command, so I decide to rerun my command to get the mailboxes. This command, the previous command, and the output from the commands are shown in the image that follows.

Cool, it worked! That is all there is to using Windows PowerShell to modify user aliases in Microsoft Exchange Server. I invite you to join me tomorrow for more Windows PowerShell cool stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy