Summary: Learn how to use Windows PowerShell to troubleshoot and diagnose Microsoft Outlook performance issues.

  Hey, Scripting Guy! I recently upgraded to Microsoft Outlook 2010, and to be honest I am rather disappointed. It seems like it takes forever to launch. I can click the Outlook icon to start the program, open Internet Explorer, navigate to our Outlook Web Access (OWA) site, log on to OWA, check my email, and log out of OWA before Outlook is even connected to our Exchange Server. I mean the performance is really ridiculous. I do not know what this has to do with Windows PowerShell, but you seem to know everything else, so I thought I would ask you for help. So here goes…HELP!!!

—SH

Hello SH, Microsoft Scripting Guy, Ed Wilson, is here.

I am still trying to recover from spending the last two weeks on the road. Between the SQL Rally event in Orlando, TechEd in Atlanta, and hopping on up to the mountains so the Scripting Wife and I could visit my mother, we only just now arrived back in Charlotte, North Carolina. It has been an absolutely wonderful two weeks, and the Scripting Wife and I have made tons of new friends. Now it is time to settle back down to the business of writing a daily blog.

SH, I appreciate your kind words. Although no one really knows everything, I do have an idea as to how Windows PowerShell can aid you. I would predict that your problem with Microsoft Outlook 2010 is not really related to Outlook itself, but rather to an add-on to Microsoft Outlook. Microsoft Outlook has historically caught a bad rap—the network is congested, so email is slow, and Outlook gets the blame. Or the Exchange Server is started for memory or it is underpowered, so email is slow, and Outlook gets the blame. Active Directory is not properly configured, name resolution takes forever, so email is slow, and Outlook gets the blame.

One of the things the Microsoft Outlook team has been doing is exposing information related to networking and other infrastructure items. This provides a microscope into the environment, and it can enable intelligent troubleshooting. In Microsoft Outlook 2010, entries are written to the application event log, and they provide insight into the load behavior of add-ons. Outlook Event 45 appears in the following image.

To query the application event log by using the Get-WinEvent Windows PowerShell cmdlet, it is best to use a FilterHashtable parameter to filter out only event entries from the Outlook provider with an event ID of 45 that appear in the application event log.

Note: The use of the Get-WinEvent Windows PowerShell cmdlet is discussed in detail in these two Hey! Scripting Guy blogs. For a great series about working with Windows event logs, refer to this collection of Hey! Scripting Guy blogs.

The command to accomplish the previous task is shown here:

Get-WinEvent -FilterHashtable @{LogName=”application”;ProviderName=”Outlook”;ID=45}

The command and its associated output are shown in the following image.

Although the previous command and its associated output are exciting, they are suboptimal from a troubleshooting perspective. For example, I could care less when the event occurred, I need to know the content of the message—and that is truncated.

To view the content of the message property from the event log, I pipeline the results of the Get-WinEvent cmdlet query to the Select-Object cmdlet (because I am working in the Windows PowerShell console, I use the alias Select instead of the more verbose Select-Object). The command I use is shown here:

Get-WinEvent -FilterHashtable @{LogName=”application”;ProviderName=”Outlook”;ID=45} |

Select -ExpandProperty message

The command and its associated output are shown in the following image.

Unfortunately, the information that is returned from the application event log event 45 from the Outlook provider is not really nicely formatted. A special *.format.ps1xml file tells Windows PowerShell how to display the event entry properly. An idea of what the event log entry actually looks can be gathered by examining the friendly view of the entry as shown in the following image.

Because of the formatting challenges, it might be easier to work with one application event log entry because it contains the add-in load information for a specific session of Microsoft Outlook. I use it like this…

Suppose I start up my laptop, launch Outlook, and it seems to “take forever” to finish loading. I can, after Outlook is finally loaded, pop over to my trusty Windows PowerShell console and type the following command to retrieve the most recent report from Outlook event 45.

Get-WinEvent -FilterHashtable @{LogName=”application”;ProviderName=”Outlook”;ID=45} -maxEvents 1 | Select -ExpandProperty message

The new addition to the previous command was the MaxEvents parameter. By specifying a maximum number of events of 1 to return, this provides me with the most recent instance of the events that match the query. The command and its associated output are shown in the following image.

By limiting the results to the most recent entry, the offending Outlook add-on can be quickly identified.

SH, that is all there is to using Microsoft Outlook diagnostics. Microsoft Outlook Week will continue tomorrow.

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