3. Test-ServiceHealth
Another extremely useful cmdlet is Test-ServiceHealth,
which does what its name suggests: it checks the health of all required
Exchange services on the server. Since the cmdlet recognizes roles as
well, it doesn't just check for every service; it only looks for the
services the installed roles use. It won't check for MSExchangeRPC on a
Hub Transport server, for example, or for MSExchangeMailSubmission on a
Client Access server.
This cmdlet also uses a very simple syntax; just type Test-SystemHealth,
press Enter, and peruse the results. The output from this cmdlet is
preformatted into a table and simply reports on the status of the
required services; an example of the output is shown in Figure 4.
If you want to quickly check the status of a single
server, the two preceding cmdlets can save a lot of time and effort.
However, neither cmdlet runs against multiple servers at once. To check
the configuration of a group of servers, or even every server in the
organization, you need a tool that runs at a higher level.
4. Exchange Best Practices Analyzer
If you've been using Exchange for the last few
years, you're probably familiar with the Exchange Best Practices
Analyzer (generally known as ExBPA). If not, or if you're new to
Exchange, this tool will probably become one of your best friends,
particularly during troubleshooting. It's one of the best free tools
Microsoft ever produced, and it's no stretch to say that it completely
changed the way Exchange administrators work with the product.
|
Company GHIJ had been having weird errors with their
Exchange server. The issues were affecting client connectivity and,
like most good, weird errors, were unpredictable and inconsistent. At
times the problems affected two or three of their 620 clients and at
other times a few dozen. Every time the Exchange administrator would
start troubleshooting the problem, the errors would clear up.
For months, they chalked up this problem to merely
ghosts in the network or some hard-to-reproduce error. Their
administrator decided one day to run the Exchange Best Practices
Analyzer; she had not done so since the Exchange server had first been
installed. The first time she ran the scanner it reported no issues,
but she noted that she did not allow it to update its rule set from the
Internet.
She ran the scanner again with an updated rule set,
and it reported several potential issues that should be resolved. She
investigated each of the reported issues and found one that would
produce inconsistent network issues for Outlook clients. Once she
applied the recommended fix, the issue did not return.
This organization learned an important lesson about
the ExBPA; run it on a regular basis and make sure that you have
updated rule sets.
|
The Exchange Best Practices Analyzer is, at its heart, a rules-based data collection and display engine (see Figure 5).
In its most common usage, it connects to a group of servers that you
specify, collects a host of data about each of them, and then compares
what it finds against a defined set of specific criteria. If it finds a
match for a particular value, it displays that information in the form
of a recommendation, complete with links to authoritative Microsoft
online content. It might not sound too exciting, but it's powerful—very powerful.
What makes ExBPA so powerful is the collective
knowledge base it represents: all of the various Exchange subject
matter experts within Microsoft contribute their knowledge to this
tool, and the rules reflect their input.
For the ExBPA to be truly useful and up-to-date for
your organization, you should ensure that you have updated it with the
newest rule sets and definitions prior to using it. To ensure that the
ExBPA has the latest rule sets, make sure that the server or
workstation from which you are running it has the latest available
service packs or rollup fixes for Exchange Server 2010. This is a
change from Exchange 2007 and earlier, where you could download the
updates separately.
|
Because ExBPA is such an easy and thorough data
collection tool, Microsoft support engineers will always ask you to
send them an XML output tool when you open a support case. If you do
need to open a case for troubleshooting, you can save time by providing
an up-to-date ExBPA output file right away.
|
The Exchange Best Practices Analyzer (see Figure 6)
is included on every Exchange server as part of the EMC. It's available
in the Toolbox along with a number of other tools . To launch it, simply select Best Practices
Analyzer and click Launch Tool in the Actions pane.
If you have any serious configuration or system issues, you will notice the output of the ExBPA and the output of Test-SystemHealth will be similar. That's because Test-SystemHealth and ExBPA use the same basic configuration information, albeit in different forms. Both tools check configuration, but while Test-SystemHealthTest-SystemHealth.
runs against only one server, ExBPA can scan every system in your
environment at once. Of course, the ExBPA will provide a much more
detailed report than
ExBPA provides runs in four basic modes:
Health Check
This is the mode you'll use the most, and it
does the checks we covered earlier: it connects to a group of servers,
reads configuration information about those servers, and then alerts
you to possible issues arising from that configuration.
Connectivity Check
This is a quick scan that's useful for ensuring
that all servers in your environment are up and running, that the
account you provided has access to them, and that critical system
services on the servers are started and accessible; this includes
Remote Procedure Call (RPC), Windows Management Instrumentation (WMI),
and the Remote Registry.
Baseline Check
This scan allows you to select one server as a
reference system and then compare all other servers to it. Differences
between the systems are highlighted, allowing you to quickly and easily
audit your Exchange environment.
Health Check With Performance
This is a super-set of the Health Check test
case listed earlier, with a performance capture bolted onto the end.
You probably won't need to run this mode, because there are better
tools available for performance analysis.
No matter which mode you choose, you'll need to
select an appropriate network speed from the drop-down menu. There are
four choices: Fast LAN, LAN, Fast WAN, and WAN. These correspond to
timeout values built into the tool: ExBPA will wait longer to consider
a server unreachable if you select WAN, as it increases the timeout
value to 300 seconds (5 minutes). Conversely, it will only wait 30
seconds to declare that system "dead" if you've selected Fast LAN.
Once you've done this, go ahead and click Next to
begin the test. The next screen will be a progress screen of sorts,
with each server to be scanned listed on the left and progress bars for
each on the right.
|
ExBPA has a little quirk that you should be aware
of: when it finishes scanning all the Exchange servers, it attempts to
connect to all the domain controllers those servers have accessed via
the ADAccess component. In a large environment, that could be literally
hundreds of domain controllers. So if you see the main screen progress
bar stuck at 99 percent despite the fact that all the Exchange servers
have completed, don't worry—it's just checking the domain controllers.
|
After ExBPA has finished collecting data, it'll let
you know that scanning is complete, and it's at this point that the
real fun begins. Click Next to have ExBPA analyze the output, and when
it's processed all the raw data, it'll present you with the list of
issues. The default view only shows you the critical issues, however,
so be sure to click All Issues to see the complete list such as the
list shown previously in Figure 6.
Each issue should include a descriptive title (like
"Exchange information store service is not set to start"), a more
detailed description that becomes visible when you select the issue,
and three additional links: one for more information online, one to
hide that instance of the issue, and one to hide that issue
permanently. The Tell Me More About This Issue link takes you to some
of the best and most descriptive content on the Microsoft site; you can
learn an awful lot of stuff about Exchange simply by going through the
ExBPA content. The other two links let you clean up your output a bit.
If you know that the Information Store service isn't set to start on a
specific server, and it's by design, you can simply hide that issue.
|
The ExBPA is an excellent tool and one that can save
you many hours of potential problems or hours on the phone with
support. The collective knowledge built in to the ExBPA's rule sets
represents literally thousands of hours of field experience and
Microsoft product support experience.
However, these rule sets make recommendations based
on typical organizations and typical configurations. Do not blindly
make configuration changes or apply patches without understanding the
ramifications to your own Exchange environment. The ExBPA may be your
consultant-in-a-box, but there is no way that Microsoft can accommodate
the variations found in all Exchange organizations in the world. Your
own knowledge of your system, research, and personal experiences must
still supplement this powerful tool.
|
Although it was designed primarily as a
troubleshooting tool, many administrators use it for other purposes.
Some engineers use ExBPA as a validation tool, running it both before
and after making changes to the environment, while others use it to
discover if any changes were made in the last week or month. However
you use it, you'll definitely want to make it a part of your standard
troubleshooting toolkit, because it's useful in bringing so many things
to light.
