The cool tools continue to roll out from the great folks in Redmond. This month marks the release of the Microsoft Log Parser Studio, a much needed GUI front end to the powerful Log Parser that you’ve probably heard of, even dabbled with, over the years. Log Parser, now at version 2.2, has been around for years and was always known as the go to tool for digging through tons of log files. Log Parser can consume log files in text, XML and CSV, and can also work with Event Logs, the registry, Active Directory and more. The only drawback to Log Parser 2.2 is that it’s command line.

The powerful search and output capabilities of Log Parser can find practically anything you can formulate a query for, and output it to another source including text, chart, SQL or even syslog format. The challenge for many is that the command line interface can be a turn-off, and the query language is not for the meek at heart. It works very well and is extremely powerful, but unless you are already used to writing SQL queries it can be more effort than you want to exert. Continue reading Another Cool Tool: The Log Parser Studio

We’ve been gradually ramping up our coverage of the Exchange Management Shell and the capabilities of PowerShell here at The Email Admin, and it’s great to see that Microsoft hasn’t slacked off when it comes to the EMS and PS either. There’s a new tool out, currently in beta, which shows all the signs of being a command-line junkee’s new crave.

The Microsoft Script Explorer for Windows PowerShell is a new graphical tool that can help you navigate all the twists and turns of using Windows PowerShell. The tool is designed to make finding, understanding, and reusing existing scripts as quick and easy as possible. Whether those scripts are of your own creation, created by your coworkers, or contributed by others to online repositories, Script Explorer is built to help you find, and use, just what you need as quickly and as easily as possible. Continue reading Scripting with Microsoft Script Explorer

If you’ve ever used the Exchange Server Deployment Assistant (ExDeploy), you may be interested to learn that Microsoft recently updated ExDeploy to include scenarios for both Exchange 2010 SP2 and Office 365 Hybrid Deployments. If you have not seen this tool before, and you are considering an upgrade of your existing Exchange environment, or a new Exchange 2010 deployment, you owe it to yourself to check out ExDeploy to see what it can do for you. Continue reading ExDeploy Updated for SP2

Becoming comfortable, and even skilled, at using the Exchange Management Shell (EMS) is going to take time, repetition, and it certainly helps if you can pick up some quick tips and tricks to make it seem less arcane, and more friendly. Here’s a list of ten quick tricks to help you get a little more comfortable with the EMS and also a little more efficient early on. Continue reading 10 Tricks in the Exchange Management Shell

As you begin to dig deeper and deeper into Exchange 2010 (or 2007) administration, you will find yourself spending increasing amounts of time in the Exchange Management Shell (EMS). Your daily mailbox and user maintenance activities can be done in the GUI, but even those activities can become more efficient when you use the EMS, and script actions that must be done frequently. One problem many admins (myself included) have with using EMS is that it can be challenging to remember just exactly what you did, or in what order, and sometimes you would love to do again what you did last week, but you just cannot remember the switches you used, or find that KB article (I knew I should have bookmarked, but I didn’t).

Other times, you may just want to have the ability to show what you did or did not do, when someone else asks about something that happened or didn’t. Having a record to refer to is useful in all of these circumstances, but recording screenshots is too unwieldy and doesn’t really let you copy and paste a command from last week into a shell session you are running now. That’s where the start-transcript command comes in. Built into PowerShell and therefore available to you in the Exchange Management Shell, start-transcript is a command that will start and maintain a text file record of everything you do during an EMS session. This handy utility creates that record of what you did and how you did it, providing you with just the thing to review, or use to repeat, actions when necessary. Continue reading Put EMS on the Record with Start-Transcript

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets (slow being at best a relative term, and never specific enough about what precisely is considered to be slow) can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 6 of this series, we’re going to troubleshoot client connectivity issues to Exchange. Continue reading Troubleshooting Exchange Networking: Client Connectivity (Part 6)

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets can be extremely challenging to work on, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent.

The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 5 of this series, we’re going to discuss how Exchange is dependent upon and uses Remote Procedure Calls (RPCs) on the network. Continue reading Troubleshooting Exchange Networking: RPCs (Part 5)

Hot on the heels of last month’s release of Exchange 2010 SP2, Microsoft has released Rollup 1. Available to download now, KB2645995 updates Exchange 2010 SP2 to address several issues that could impact certain customers in very specific situations, and also includes some other updates for Exchange.

This 30MB release is an update only; unlike Exchange 2010 SP2 it does not contain the files necessary to install Exchange, so for each new SP2 server you deploy, you need to then apply RU1. Before we list the fixes contained in RU1, let’s look at some special situations that can affect your deployment of RU1. Continue reading Microsoft Releases RU1 for Exchange 2010 SP2

One of the things that I get a lot of questions about when I start leading people down the CLI path is whether or not the Exchange Management Shell is just PowerShell with a fancier icon. We frequently open the EMS in order to perform certain managerial tasks in Exchange, and we hear more and more coming out of Redmond regarding PowerShell. So let’s discuss it.

As it turns out, the Exchange Management Shell is PowerShell (big surprise there) but it’s a more specialized environment than you get when simply running PowerShell.exe, with a lot of specific settings to make it talk to Exchange. In this post, we’ll go over the differences, and when you want to use one or the other. Continue reading Exchange Management Shell vs PowerShell

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue.

While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 4 of this series, we’re going to look at the humble physical layer (DoD, not OSI) and discuss troubleshooting NICs. Continue reading Troubleshooting Exchange Networking: NICs (Part 4)