Search results for 'app:weblogs' matching tags 'guest blogger' and 'messaging and communication'

Get Exchange Online Mailbox Size in GB

Anonymous — Wed, 27 Feb 2013 06:00:00 GMT

Summary: Microsoft PFE, Brian Jackett, talks about using Windows PowerShell to get Exchange Online Mailbox size in GB.

Microsoft Scripting Guy, Ed Wilson, is here. Today I want to welcome back guest blogger, Brian T. Jackett.

Brian T. Jackett is a premier field engineer at Microsoft who has specialized in SharePoint development, Project Server, and Windows PowerShell for over four years. Brian is a steering committee member of the Buckeye SharePoint User Group, and he enjoys giving back to the community through giving presentations, planning and volunteering at conferences, maintaining a SharePoint/.NET-centric blog, and contributing to the SharePoint Twitterverse. He also holds several Microsoft Certified Technology Specialist (MCTS) certifications for SharePoint-related technologies.
Brian’s blog: The Frog Pond of Technology

Now, here’s Brian…

Office 365 is picking up in deployments and user adoption. Windows PowerShell is one tool for the administration of Office 365 that is similar to its on-premises counterparts, but it can have a few differences. In this post, I will discuss one way to get the size of an Exchange Online mailbox in bytes and consequently GBs.

Problem

Getting the size of an on-premises Exchange 2010 mailbox is fairly easy. In his blog The Get-MailboxStatistics Cmdlet, the TotalitemSize Property, and that pesky little “b”, fellow PFE Gary Siepser, explains how to accomplish this task by using the mailbox TotalItemSize property with methods such as ToMB() and ToGB(). Note that Gary’s script will not work when remoting from a local machine that doesn’t have the Exchange object model installed or loaded.

A similar type of scenario exists if you are executing Windows PowerShell against Exchange Online. The data type for TotalItemSize being returned (ByteQuantifiedSize) exists in the Exchange namespace. If the WindowsPowerShell session doesn’t have access to that namespace (or hasn’t loaded it), Windows PowerShell works with an approximation of that data type.

The following script is a sample on the TechNet article View Mailbox Sizes and Mailbox Quotas Using Windows PowerShell, which a customer of mine tried, but it was failing. (I made minor edits to fit it on page and remove references to deleted item size.)

Get-Mailbox -ResultSize Unlimited |

Get-MailboxStatistics |

Select DisplayName,StorageLimitStatus, `

@{name="TotalItemSize (MB)"; expression={[math]::Round( `

($_.TotalItemSize.Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}}, `

ItemCount |

Sort "TotalItemSize (MB)" -Descending

The script is targeted to Exchange 2010, but it fails for Exchange Online. In Exchange Online, when referencing the TotalItemSize property, there is not a Split method, which ultimately causes the script to return no data for “Total Item Size (MB)” column.

Solution

A simple solution would be to add a call to the ToString method off of the TotalItemSize property (shown in bold on line 5 in the following script).

Get-Mailbox -ResultSize Unlimited |

Get-MailboxStatistics |

Select DisplayName,StorageLimitStatus, `

@{name="TotalItemSize (MB)"; expression={[math]::Round( `

($_.TotalItemSize.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}}, `

ItemCount |

Sort "TotalItemSize (MB)" -Descending |

Export-CSV "C:\My Documents\All Mailboxes.csv" -NoTypeInformation

This fixes the script to run but the numerous string replacements and splits are an eyesore to me. I attempted to simplify the string manipulation with a regular expression. (For more information about regular expressions in Windows PowerShell, see the Regular-Expressions.info website.)

The result is a working script that adds two pieces of functionality. First, the script allows you to input a specific user to search for (or all users if no input is supplied). A technique called splatting is used to allow “@Params” to send additional optional parameters to the Get-Mailbox cmdlet. Second, the script adds a new member to the mailbox statistics called TotalItemSizeInBytes. With this member you can then convert to any byte level that suits your needs (for example, KB, MB, or GB).

Note You can download the full version of this script from the Script Center Repository (it includes commands to connect to Exchange Online session):
Get Exchange Online Mailbox Size in GBs

$userToFind = Read-Host -Prompt "Enter user to find (leave blank for all)"

$params = @{}

if([string]::IsNullOrEmpty($userToFind) -eq $false)

{$params = @{Identity = $userToFind}

}

$UserMailboxStats = Get-Mailbox -RecipientTypeDetails UserMailbox `

-ResultSize Unlimited @Params |

Get-MailboxStatistics

$UserMailboxStats |

Add-Member -MemberType ScriptProperty -Name TotalItemSizeInBytes `

-Value {$this.TotalItemSize -replace "(.*$)|,| [a-z]*$", ""}

$UserMailboxStats |

Select-Object DisplayName, TotalItemSizeInBytes,@{Name="TotalItemSize (GB)"; `

Expression={[math]::Round($_.TotalItemSizeInBytes/1GB,2)}}

The regular expression ‘$this.TotalItemSize –replace "(.*$)|,| [a-z]*$", ""’ is searching for the following three patterns and replacing them with empty strings. The result is the total item size in bytes with no other extra characters.

.*\( = Any number of characters followed by an opening parentheses
, = Commas
[a-z]*\) = Any number of alphabetic characters followed by a closing parentheses (i.e. “bytes)”)

Moving from on-premises to the cloud with Windows PowerShell (and Windows PowerShell remoting in general) can sometimes present new challenges due to what you have access to. This means that you must always test your code and scripts.

I still believe that not having to physically RDP to a server is a huge gain over some of the small hurdles that you may encounter during the transition. Scripting is the future of administration, and it makes you more valuable. Hopefully this script and the concepts presented help you be a better admin and developer.

For more information, watch my video series: The One Thing: Brian Jackett and SharePoint 2010.

—Frog Out

Links

Awesome job, Brian. Thanks for an informative and helpful guest blog post. Join me tomorrow when I will talk about using Windows PowerShell to explore process threads.

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

Send Email from Exchange Online by Using PowerShell

Anonymous — Sat, 24 Sep 2011 05:00:00 GMT

Summary: Guest blogger Mike Pfeiffer shows how to send email messages using Windows PowerShell and Exchange online.

Microsoft Scripting Guy Ed Wilson here. Guest Blogger Mike Pfeiffer recently published a book called Microsoft Exchange 2010 PowerShell Cookbook. Mike has been in the IT field for over 13 years, spending most of his time as an enterprise consultant focused on Active Directory and Exchange implementation and migration projects. He is a Microsoft Certified Master on Exchange 2010, and a Microsoft Exchange MVP. You can find his writings online at mikepfeiffer.net, where he blogs regularly about Exchange Server and Windows PowerShell-related topics.

Sending the output of a script in an email message is simple with Windows PowerShell 2.0, thanks to the Send-MailMessage cmdlet. I have seen some great solutions people have created with this cmdlet to generate and deliver automated reports, notifications, and monitoring alerts. Even before Windows PowerShell 2.0, it was easy to use the classes in the System.Net.Mail namespace to accomplish the same goal. In either case, as long as you have access to an SMTP server, you can easily automate the transmission of email messages with Windows PowerShell.

Messaging is getting a little more complicated these days, though. Now we have hosted solutions such as Exchange Online offered through Office 365. Imagine that your organization has decided to go with a fully hosted deployment of Exchange Online, meaning that all of your organization’s mailboxes are hosted exclusively in the cloud. What do you do with your scripts that need to send email messages?

Out of the box, SMTP Relay with Exchange Online requires a Transport Layer Security (TLS) connection, and you must connect on SMTP port 587. The good news is that there is an easier way to send email messages via Exchange Online using Windows PowerShell. The answer is the Exchange Web Services (EWS) Managed API, which is a fully object-oriented .NET Framework wrapper for the EWS XML protocol.

Here are a few of the benefits to using EWS to send email messages:

Messages are sent through the web services endpoint on port 443, which is firewall friendly.
The API has a built-in autodiscover client that will determine the web service endpoint for you automatically. You don’t need to provide a server name.
You don’t need to worry about connector settings, mail relay, and TLS.
Messages sent through the API can be saved in the senders Sent Items folder, which can provide tracking and reporting information.

In order to use the EWS Managed API and the code provided in this article, you’ll need a machine running Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista. You’ll also need Windows PowerShell 2.0 with.NET Framework 3.5 installed. As long as these requirements are met, head over to the Microsoft Download Center and grab EWS Managed API 1.1. You will want to download the appropriate MSI package for your machine, either x86 or x64, and run through the installation. The installer simply extracts the EWS assembly to a folder on your hard drive, which by default will be under C:\Program Files\Microsoft\Exchange\Web Services\1.1

After this is complete, we are ready to write some code. Before we can start working with the classes in the EWS Managed API, the assembly must be loaded so that the .NET Framework types are available:

Add-Type -Path 'C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll'

Next, we need to create an instance of the ExchangeService class that can be used to send SOAP messages to an Exchange server using the API. This class basically defines the connection information for the web service. It provides several properties and methods, some of which can be used to specify our credentials and set the web services endpoint URL using the built-in autodiscover client:

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService -ArgumentList Exchange2010_SP1

Notice that we are passing the Exchange version to the ExchangeService class constructor. This is actually optional in this case because the 1.1 version of the API will automatically set this to Exchange2010_SP1, which is the same version running in the cloud. However, it's good to know if you ever want to write code that targets an Exchange server running on premise. The ExchangeVersion Enumeration contains all of the supported versions that can be used.

Since our goal is to send a message from Exchange Online, we will need to authenticate to the web service. This can be set on the existing $service objects Credentials property:

$service.Credentials = New-Object Microsoft.Exchange.WebServices.Data.WebCredentials -ArgumentList user@yourdomain.onmicrosoft.com, “P@ssw0rd”

The credentials used here should be the mailbox from which you want to send the email message. This will be a valid user name and password for an existing Exchange Online user account.

At this point, we can use the AutoDiscoverUrl method of the $service object to automatically set the EWS end-point:

$service.AutodiscoverUrl('user@yourdomain.onmicrosoft.com', {$true})

The first argument provided for the AutoDiscoverUrl method is the e-mail address for your Exchange Online user account. The API will take the domain portion of the address and query DNS for an autodiscover record. Once it is resolved, the API will hit the autodiscover endpoint and determine the Exchange web services URL in the cloud. The second argument passed to the method is a scriptblock that returns $true. This allows the server to redirect API to the appropriate Exchange Online server during the autodiscover process.

If you take a look at the $service object after invoking the AutodiscoverUrl method, you’ll notice that the EWS URL is automatically set to an Exchange Online server running in the cloud.

Now that we have an authenticated connection established to Exchange Online, we can create an instance of the EmailMessage class and send a message:

$message = New-Object Microsoft.Exchange.WebServices.Data.EmailMessage -ArgumentList $service
$message.Subject = 'Test is a test'
$message.Body = 'This message is being sent through EWS with PowerShell'
$message.ToRecipients.Add(‘sysadmin@contoso.com’)
$message.SendAndSaveCopy()

Setting the Subject, Body, and From properties of an EmailMessage object is pretty straightforward. Adding recipients requires that we use the Add method of the ToRecipients property. When adding multiple recipients, you can call this method for each one. There are also properties for CcRecipients and BccRecipients.

When it comes to actually sending the message, there are two methods that can be used. The SendAndSaveCopy method sends the message and retains a copy in the senders Sent Items folder. Alternatively, the Send method will send the message without saving a copy. Because we passed the $service object to the EmailMessage class constructor when creating the message, our Exchange Online credentials and web services endpoint located through autodiscover will be used to transmit the message.

While the code we have looked at so far is useful, we can automate things even further. Let us wrap the code up into a reusable function to make this a little easier.

function Send-O365MailMessage {

[CmdletBinding()]

param(

[Parameter(Position=1, Mandatory=$true)]

[String[]]

$To,

[Parameter(Position=2, Mandatory=$false)]

[String[]]

$CcRecipients,

[Parameter(Position=3, Mandatory=$false)]

[String[]]

$BccRecipients,

[Parameter(Position=4, Mandatory=$true)]

[String]

$Subject,

[Parameter(Position=5, Mandatory=$true)]

[String]

$Body,

[Parameter(Position=6, Mandatory=$false)]

[Switch]

$BodyAsHtml,

[Parameter(Position=7, Mandatory=$true)]

[System.Management.Automation.PSCredential]

$Credential

)

begin {

#Load the EWS Managed API Assembly

Add-Type -Path 'C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll'

}

process {

#Insatiate the EWS service object

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService -ArgumentList Exchange2010_SP1

#Set the credentials for Exchange Online

$service.Credentials = New-Object Microsoft.Exchange.WebServices.Data.WebCredentials -ArgumentList `

$Credential.UserName, $Credential.GetNetworkCredential().Password

#Determine the EWS endpoint using autodiscover

$service.AutodiscoverUrl($Credential.UserName, {$true})

#Create the email message and set the Subject and Body

$message = New-Object Microsoft.Exchange.WebServices.Data.EmailMessage -ArgumentList $service

$message.Subject = $Subject

$message.Body = $Body

#If the -BodyAsHtml parameter is not used, send the message as plain text

if(!$BodyAsHtml) {

$message.Body.BodyType = 'Text'

}

#Add each specified recipient

$To | ForEach-Object{

$null = $message.ToRecipients.Add($_)

}

#Add each specified carbon copy recipient

if($CcRecipients) {

$CcRecipients | ForEach-Object{

$null = $message.CcRecipients.Add($_)

}

#Add each specified blind copy recipient

if($BccRecipients) {

$BccRecipients | ForEach-Object{

$null = $message.BccRecipients.Add($_)

}

#Send the message and save a copy in the Sent Items folder

$message.SendAndSaveCopy()

}

This function provides several parameters used to set the subject, body, and recipients for the message. The To, CcRecipients, and BccRecipients parameters accept multiple addresses and you can specify one or more addresses for each recipient type when sending a message. I’ve also included a BodyAsHtml switch parameter, which can be used to send the message in HTML format—or in plain text, when the parameter is not used.

After you have added this function to your shell session, you can call it just like a cmdlet and send a message through the web service:

$creds = Get-Credential

Send-O365MailMessage -To user@domain.com -Subject 'test' -Body 'this is a test' -BodyAsHtml -Credential $creds

This code first uses the Get-Credential cmdlet to store your Exchange Online credentials. We then call the Send-O365MailMessage cmdlet to send an email message through Exchange Online.

As a side note, EWS works the same on premise as it does in the cloud. If you have an existing Exchange 2010 SP1 deployment onsite, you can use the code samples in this article to send messages through the web service on your on-premise servers.

Thank you, Mike, for sharing your knowledge and experience with us today.

Ed Wilson, Microsoft Scripting Guy

A PowerShell Exchange Best Practices Analyzer XML Parser

Anonymous — Mon, 05 Sep 2011 05:00:00 GMT

Summary: In this guest blog post, you will learn how to create a Windows PowerShell parser to parse the XML file generated using ExBPAcmd.exe.

Microsoft Scripting Guy Ed Wilson here. I want to welcome our Guest Blogger Thiyagu again today. Here is a little about Thiyagu:

I am the founder of the Singapore PowerShell User Group. I am an Exchange administrator, and I have been scripting for more than seven years now. Before Windows PowerShell, I did most of my scripting in VBScript. With Windows PowerShell, I automate Exchange/Active Directory tasks, and I am also good at WMI, ADSI, and generating custom reports. I have developed custom applications in C# for automation. I love to automate things! You will find me on my blog.

What Is the Best Practices Analyzer?

The Best Practices Analyzer (BPA) is a server management tool that is available in Windows Server 2008 R2. BPA can help administrators reduce best practices violations by scanning one or more roles that are installed on Windows Server 2008 R2, and reporting best practices violations to the administrator. Administrators can filter or exclude results from BPA reports that they don’t need to see. Administrators can also perform BPA tasks by using either the Server Manager GUI, or Windows PowerShell cmdlets.

BPA is part of the Windows Server 2008 R2, and you can run it on most of the roles installed on the server.

The following list includes some of the roles against which you can run BPA:

Active Directory Domain Services
Active Directory Certificate Services
Domain Name System (DNS) Server
Remote Desktop Services
Web Server (IIS)
Active Directory Rights Management Services (AD RMS)
Application Server
DHCP
File Services
Hyper-V
Network Policy Server (NPS)
Windows Server Update Services (WSUS)

You can use the following Windows PowerShell cmdlets to work with the various Best Practices Analyzers:

Get-BPAModel
Get-BPAResult
Invoke-BPAModel
Set-BPAResult

Analyze Email Message Headers with PowerShell—Part 2

Anonymous — Fri, 19 Aug 2011 05:00:00 GMT

Summary: Learn how to use Windows PowerShell to analyze email headers and obtain detailed origination information.

Microsoft Scripting Guy Ed Wilson here. Guest Blogger Thiyagu continues with part 2 of his post about analyzing email headers with Windows PowerShell. See yesterdays’ post for information about Thiyagu and for the first part of the article.

In part 1, we saw how to use Regex and parse the email message header. So far, we have a PSObject with all the required properties parsed from the email message header. Sometimes with certain types of headers, you will have another set of headers. Instead of having just the “Received: from,” there will also be one named “Received: by.” I also wrote another function, just like this one to process that information as well as to build a custom PSObject.

Both of these functions will return a collection of PSObjects. Remember in part 1, I mentioned that we should be reading the email message header from bottom up, but we did not do that. We were doing this from top down. You can use this approach to reverse an array of objects:

$byObjects = $byObjects[($byObjects.Length-1)..0] # Reversing the Array

Alternatively, for large arrays, using the static Reverse method from the Array class will have much better performance. This technique is shown here:

[Array]::Reverse($byObjects)

Now we have two objects: one from “Received: from” and another from “Received: by.” “Received: by” sections come first and then “Received: from.” Now, enter the main function, which is going to do all the work.

The main function takes both the receivedby and the receivedfrom objects. The function starts with the receivedby object first, because it is the first part that starts. It then takes the server name and the protocol (if available) and continues on to the next object in the array of objects that is passed. The function now starts its calculation, and compares the time of the previous entry with the time of the current entry. The function obtains the difference between the two time stamps and calculates the number of seconds.

After it has this information, it is stored in a variable called $delay. This delay value is later added to the final PSObject, which will have all the info gathered from the headers. Here is what the function looks like; I am posting only the partial function here to show you the portion that matters:

if($fromObjects)

{

$fromObjects = $fromObjects[($fromObjects.Length-1)..0] #Reversing the Array

for($index = 0;$index -lt $fromobjects.Count;$index++)

{

$hop = $hop + 1

$receivedfrom = $fromobjects[$index].ReceivedFromFrom

$receivedby = $fromobjects[$index].ReceivedFromBy

$with = $fromobjects[$index].ReceivedFromWith

$time = $fromobjects[$index].ReceivedFromTime

$time = $time.touniversaltime()

if($prevTime)

{

$delay = $time - $prevTime

$delay = $delay | Select-Object -ExpandProperty totalseconds

}

else

{

$delay = "*"

}

$prevTime = $time

$finalHash = @{

Hop = $hop

Delay = $delay

From = $receivedfrom

By = $receivedby

With = $with

Time = $time

}

$obj = New-Object -TypeName PSObject -Property $finalHash

$finalArray += $obj

}

These are all the fields we need:

Hop
Delay
From
By
With
Time

Also notice that I am converting all the times to universal time (UTC), so this way we have one set of times instead of all different time zones such IST, PDT, and EST.

Delay is calculated by subtracting the time of the previous hop from the current time value:

$delay = $time - $prevTime

$delay = $delay.totalseconds

Then I just get the totalseconds property. Now let us just build a PSObject with all these parameters and then we are good to go. Finally it out that PSObject onto a gridview and here is what I get:

You can see now easily that on hop two, it took eight seconds, and in the next hop, it took around five seconds. Finally, there was delay of six seconds to submit to the server “incoming.green.com”. I converted the script to an advanced function, which takes in Filename as an input to parse the information. You can use it like a cmdlet and I have included some examples as well. The complete script containing the advanced function can be downloaded from the Scripting Guys Script Repository.

Usually Level 1 teams do this type of job of checking these headers. I think we should give them a tool to do this work, instead of giving them this big Windows PowerShell script. Therefore, here is how I put together the GUI piece for this tool. I used ShowUI to build this tool in 15 lines. Here is the code:

[System.Reflection.Assembly]::LoadWithPartialName("System.windows.forms") | Out-Null

$OpenFileDialog = New-Object System.Windows.Forms.OpenFileDialog

$OpenFileDialog.ShowDialog() | Out-Null

$filename = $openfiledialog.FileName

$data = c:\Scripts\MSGHeaderProcessor\Parse-EmailHeader.ps1 -InputFileName $filename

New-Window -Title "Email Header Parser" -SizeToContent WidthAndHeight -Show {

New-DataGrid -Name MessageHeader -Columns {

New-DataGridTextColumn -Header "Hop" -Binding {Binding -Path "Hop"}

New-DataGridTextColumn -Header "Delay(Seconds)" -Binding {Binding -Path "Delay"}

New-DataGridTextColumn -Header "From" -Binding {Binding -Path "From"}

New-DataGridTextColumn -Header "By" -Binding {Binding -Path "By"}

New-DataGridTextColumn -Header "With" -Binding {Binding -Path "With"}

New-DataGridTextColumn -Header "Time(UTC)" -Binding {Binding -Path "Time"}

} -ItemsSource $data

}

The first four lines are about showing the Windows Open Dialog box and getting the file name that the user wants to parse. I then call the script with that file name as the input and store the value in the $data variable, which now is the PSObjects collection.

Next comes the ShowUI code. I create a new window and inside that I create a datagrid. Inside the datagrid, I add one datagridcolumn for each of the properties of the PSObject. The interesting thing here is the –Binding parameter:

-Binding {Binding –Path “Hop”}

The parameter checks the itemsource property of the datagrid, it uses the Hop property of the object there, and then it populates that information in the grid. The output from the ShowUI code is shown in the following figure.

Therefore, in 15 lines we could make a reusable tool and distribute it to the teams. The complete code can be downloaded from the Scripting Guys Script Repository. I have only uploaded the Advanced function there; you can use the ShowUI code in the article to get the GUI part of it.

Note I have tested this with many headers, and it works well with Microsoft Header Version 2.0 headers, but I have not done testing on any old or different types of headers. If you guys notice any parsing issue on any header, please let me know.

I want to thank Thiyag for an awesome two-part series of articles about parsing email headers. Well done!

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Parse Email Message Headers—Part 1

Anonymous — Thu, 18 Aug 2011 05:00:00 GMT

Summary: Guest Blogger Thiyagu teaches how to use Windows PowerShell to parse and analyze email message headers.

Microsoft Scripting Guy Ed Wilson here. Thiyagarajan Parthiban is our guest blogger today with an interesting article about using Windows PowerShell to analyze Exchange email. First, though, let’s learn something about Thiyagu.

I am the founder of the Singapore PowerShell User Group. I am an Exchange administrator, and I have been scripting for more than seven years now. Before Windows PowerShell, I did most of my scripting in VBScript. With Windows PowerShell, I automate Exchange/Active Directory tasks, and I am also good at WMI, ADSI, and generating custom reports. I have developed custom applications in C# for automation. I love to automate things!

You will find me on my blog.

Take it away, Thiyagu!

Last year, a survey was conducted to figure out the number of email messages sent every day across the globe. It was estimated that approximately 294 billion messages per day are sent, which is 2.8 million messages per second. By the way, 90 percent of all email is either spam or viruses.

Each and every email message you send or receive has a piece of information in it called a message header. Every email message you receive in your inbox has this information. There are different ways to view this message header, depending on which email client you are using. For example, here are instructions for getting the message header of an email address if you are using Outlook 2010. The following figure shows how a message header looks.

This text information contains a lot of details about the message you have received. RFC 822 tells how to place information about an email message into this header.

For now, focus on the green box in the preceding figure. This section has information about how this message got to your inbox. For an email to come to your inbox, it takes so many routes. That is our main focus in today’s post: we want to get this data parsed out of this messy text and present it in a nice little table so that you can understand what really happened with that email message.

Whenever you try to make sense of an email message header, read it from the bottom up. The above piece of code has only four lines and is cut into different lines. Here is how it looks after removing the unwanted lines:

You see, it looks already a lot cleaner, after you remove those extra lines. Take a look at the boxes and circles in the image above, and read it like this:

Received the email from Server “Corp.red.com ([16.25.5.17])” by Server “Singapore.red.com ([15.60.22.16])” with protocol “mapi id 14.01.0323.002” and at time “Wed, 13 Jul 2011 18:50:16 +0800” , which is UTC +8 (which is Singapore), you can tell from the server which received the message it says “Singapore.red.com”

If that did not make much sense, it might help to visualize it like in the following figure.

Now, this server will send the message again to another server and so on. Each trip from server to server is called a hop. The hop chain continues until it finally reaches your inbox. At times, there might be a delay when going through one of these chains. Maybe a server was busy or there was too much load, which could cause delays to email being delivered to your inbox. In this example, we have four lines, so we have four hops for the email to reach your mailbox.

Enough of theory. Let’s talk about Windows PowerShell, starting with another figure.

We have to extract the piece of information between the above-mentioned sections to form our objects. You can see from the preceding screenshot that it has a pattern. Luckily, this is where regular expressions come to the rescue. Read this great article by PowerShell MVP Tome about regular expressions and Windows PowerShell.

We need to get four pieces of information from each line:

All text after Received: from until there is a word called by. This will be our Received From Server information.
All text after by until there is a word called with. This info will be the server who receives the email from the server above.
All text after with, until there is a character ; (a semicolon) and this is the protocol.
All text after ; (a semicolon) and get the next minimum 32 to 36 space/nonspace data.

This data is the date. Here is a sample date:

Wed, 20 Jul 2011 22:28:16 -0700. This is the maximum possible for standard time, so we can get other data as well. Sometimes, there might be space or there is new line, so I am giving myself a buffer, so later we can remove unwanted data from this string.

Here is the regular expression pattern I came up with:

$regexFrom1 = 'Received: from([\s\S]*?)by([\s\S]*?)with([\s\S]*?);([(\s\S)*]{32,36})(?:\s\S*?)'

Can you believe, that the above regular expression pattern can do all four of the things I said above? If you are good at Windows PowerShell and still haven’t used regular expressions, you are missing an important weapon in your Windows PowerShell arsenal.

Note Check out this webcast by Tome. It is a great introduction to regular expressions.

Because we do not know how the text is going to be in the message header, it is good to read the whole data as one long string and work with it. Here is the technique to do read a file into one big string.

$text = [System.IO.File]::OpenText("C:\Scripts\msg6.txt").ReadToEnd()

His file now has the same information as the first screenshot in this post. I wanted to write a function that would take this $text as input, process the string, give out all the parsed data, package it in an array of PSObjects, and return them. I used Select-String along with the regular expression pattern and iterated through all the matches I got.

Here is how I did that:

Function Process-ReceivedFrom

{

Param($text)

$regexFrom1 = 'Received: from([\s\S]*?)by([\s\S]*?)with([\s\S]*?);([(\s\S)*]{32,36})(?:\s\S*?)'

$fromMatches = $text | Select-String -Pattern $regexFrom1 -AllMatches

if ($fromMatches)

{

$rfArray = @()

$fromMatches.Matches | foreach{

$from = Clean-string $_.groups[1].value

$by = Clean-string $_.groups[2].value

$with = Clean-string $_.groups[3].value

Switch -wildcard ($with)

{

"SMTP*" {$with = "SMTP"}

"ESMTP*" {$with = "ESMTP"}

default{}

}

$time = Clean-string $_.groups[4].value

$fromhash = @{

ReceivedFromFrom = $from

ReceivedFromBy = $by

ReceivedFromWith = $with

ReceivedFromTime = [Datetime]$time

}

$fromArray = New-Object -TypeName PSObject -Property $fromhash

$rfArray += $fromArray

}

$rfArray

}

else

{

return $null

}

To explain the regular expression a little bit:

'Received: from([\s\S]*?)by([\s\S]*?)with([\s\S]*?);([(\s\S)*]{32,36})(?:\s\S*?)'

Each of those is matched into groups and then you can access them using the matches property. This is true except for the last one (in the world of regular expressions, “?:” means don’t group them). This is the class it will get stored in: Microsoft.PowerShell.Commands.MatchInfo.

I just loop through the matches and then build a PSObject for each of the matches. Now, if I output the results of the function to a gridview, I see what is shown in the following figure:

Read the next part tomorrow, where I show how I put the pieces together to get delay information from different hops and then finally to build a GUI tool for this functionality.

Thiyagu, this is an excellent article. Thank you for sharing your time with us and for sharing your expertise with the Windows PowerShell community. I am really looking forward to part 2 tomorrow!

Ed Wilson, Microsoft Scripting Guy