Have you ever noticed that the Exchange System Manager
really doesn’t have many options for working with Exchange full text indexing?
I have always felt like I wanted to have more control over the indexing
process, but was prevented from having that control by limitations in the
graphical user interface.

Fortunately, Microsoft has realized that these limitations
can sometimes be a problem and has created a utility called MSSearch Admin tool.
This tool can be used to do things such as enabling and disabling an index,
checking an index’s status, fixing index configuration problems, and resetting
a malfunctioning index. In this article, I will show you where to get this tool
and how to use it.

Acquiring the MSSearch Admin tool

You can download the MSSearch Admin tool directly from Microsoft’s
Web site
. The download consists of a
94 KB (yes, that’s KB, not MB) self extracting executable file.

Installing the MSSearch Admin tool

The installation procedure for the MSSearch Admin tool is
simple. Just double click on the file that you downloaded, and the file’s
contents will be extracted. Actually preparing the tool for use is a different
story though. The MSSearch Admin tool is a Visual Basic script.

There are two reasons why this complicates things. First,
the script is completely text based, which means that you will have to manage
your server’s full text index from the command line. The second reason why the
tool being Visual Basic Script based complicates things is that Windows Server
2003 can’t natively run this particular script from the command line.

Running the MSSearch Admin tool

After you extract the MSSearch Admin tool, it will create a
folder containing several files. Most of these files are XSL style sheets, but
there is also a script file called MSSearch_Admin.vbs. You must copy the VBS
and the XSL files to the directory on your server’s hard drive that contains
the Exchange System Manager console (usually C:\Program Files\Exchsrvr\bin).

Earlier, I mentioned that Windows can’t natively run the
MSSearch Admin tool from the command prompt. In order to be able to run the
script, it must get a little help from a file named ADS.DLL. ADS.DLL is a
component in another Microsoft utility called Array Convert. You can download
and install the Array Convert utility and then copy the ADS.DLL file from Array
Convert to the Exchange System Manager folder. You can download this utility
from the Microsoft Web site.

The command’s syntax

As I have already explained, the MSSearch Admin tool is
actually a Visual Basic script with no graphical user interface. As such, you
will have to use the tool via the command line. Like most of Microsoft’s
command line based tools, there are several parameters that can be used in
conjunction to the MSSearch_Admin.vbs command. The full syntax is listed below:

MSSearch_Admin.vbs /Action:<action> [/ExServer:<servername>]
[/Application:<application>] [/Index:<index>] [/OutputFile:<filename>]

In the sections below I will discuss each of these
parameters in detail.

The Action parameter

If you look at the syntax of the MSSearch Admin tool, you
will notice that the /Action parameter is the first parameter that must be
specified. The /Action parameter is used to control what the tool is actually
going to do. For example you would use the Action parameter to tell the
MSSearch Admin tool whether you want to check an index’s status or disable the
index. In many cases the /Action parameter can be used without the need for
other parameters.

However, to get the most benefit from the /Action parameter,
you need to at least be familiar with the other parameters that are available
to you. That being the case, I am going to talk about the other MSSearch Admin
parameters first, and then come back to the /Action parameter later on

The ExServer parameter

The ExServer parameter is used to specify the name of a
target Exchange Server. The usage of this parameter is pretty simple, but there
is one important thing to keep in mind. The server that you specify must exist
within the same domain as the machine that you are running the MSSearch Admin
tool from.

To specify a server name, simply use the following syntax:


For example, if you wanted to run the MSSearch Admin tool
against a server named MYSERVER, then you would use the /ExServer parameter as
shown below:


The Application parameter

Normally, you will only have to use the Application
parameter if you are running the MSSearch Admin tool against a clustered
Exchange Server deployment. The reason for this is that each Exchange Server
deployment (clustered or not) is assigned an application name that can be
referenced through the MSSearch Admin tool.

In a non-clustered environment, the application name is
always ExchangeServer_<servername> where <servername> is the name
of your Exchange Server. The MSSearch Admin tool knows that the application
name is always a direct reflection of the server name, so in non clustered
environments it isn’t necessary to specify the application name because the
MSSearch Admin tool is smart enough to figure out the application name for

Things work a little bit differently in a clustered Exchange
Server deployment though. In a clustered environment, each node in the cluster
has its own server name, but there is also a virtual server name that is shared
by all of the servers in the cluster. If you want to run the MSSearch Admin
tool against an Exchange Server cluster, then you would use the Application
parameter to specify the cluster’s virtual server name. For example, if you had
two servers named Server1 and Server2 forming an Exchange cluster named
CLUSTER, then you would specify the Application parameter like this:


The Index parameter

The Index parameter is used when you want to perform the
specified action against a specific index. You will almost always want to use
the /Index parameter in conjunction with the /ExServer parameter. The reason
for this is that there is always the chance that you could have multiple
servers that use the same index name. To avoid confusion, it is best to tell
the MSSearch Admin tool the name of the server that you want to work with and
the name of the index on that server.

If you don’t know the name of the index, it’s no problem.
You can derive the index name from the Exchange System Manager. To do so, open
the Exchange System Manager and navigate through the console tree to
Administrative Groups | your
administrative group
| Servers | your server | the storage group containing
the indexed store | the store that you need to find the index for.

Now, expand the store’s node and you will see a sub container
named Full-Text Indexing. If you select this container, you will see some
summary information related to the index appear in the console’s details pane.
One of the pieces of information that is given is the index name. This is the
name that you will use with the /Index parameter.

The OutputFile parameter

The OutputFile parameter is always optional. If you use the
OutputFile parameter, then the script’s results will be written to the file
that you specify in XML format. If you do not use the OutputFile parameter then
the output will be displayed on the screen rather than being written to a file.
The syntax for the OutputFile parameter is:


The Action parameter

The Action parameter is the only parameter that the
MSSearch_Admin script actually requires you to use. It is however also the
parameter with the most options. In many cases, the /Action parameter can be
used without having to specify any of the other parameters that I have already
talked about. In other cases though, the Action parameter requires you to use
some of the other parameters that I have discussed so that you can specify a
particular Exchange Server or a specific index on an Exchange Server. The
syntax of the Action parameter is as follows:

MSSearch_Admin.vbs /Action:<action>

In this syntax, the <action> portion of the command
would be replaced by one of the following actions:

  • LIST
  • FULL
  • STOP
  • LIST

    As you probably know, full text indexing is applied at the
    information store level. Using the Action command with the LIST option causes
    the MSSearch Admin tool to query all of the Exchange Servers within the current
    domain to see which of those servers have Full Text Indexing enabled. If
    indexes are found, then the MSSearch Admin tool will display a list of which
    stores have full text indexing enabled.

    It is also possible to run the LIST option on a per server
    basis by using it in conjunction with
    the /ExServer:servername parameter. If you specify the LIST action along with
    the name of an Exchange Server, the MSSearch Admin tool will display a list of
    the stores on the specified server that have full text indexing enabled.


    As the name implies, the STATUS action allows you to check
    the status of an index file. Along with the index’s status, the STATUS action
    will return the index’s location on the server. The STATUS action will also let
    you know if the specified index has any configuration problems.

    As you may have already figured out, the STATUS action can’t
    be used by itself. You must also specify the server name and the index name.
    The full syntax of such a command would look something like this:

    MSSearch_Admin.vbs /Action:STATUS
    /ExServer:<server name> /Index:<index name>


    The FIXUP action is a little less intuitive than some of the
    other actions that I have talked about. I mentioned that the STATUS action
    would tell you if there were any configuration problems associated with an
    index. If the STATUS action does report a configuration problem, then the FIXUP
    command is what you would use to fix the configuration problem.

    The million dollar question though is what are these
    configuration problems? After all, full text indexing is mostly
    self-configuring. If you simply enable full text indexing for a store and let
    the index do its thing, then you will never have a configuration problem.
    Configuration problems are the result of bugs in Exchange Server that are
    triggered during administrative actions. There are three types of actions that
    can result in configuration problems.

    One action that results in a configuration problem is moving
    an index. When you move an index, the Active Directory still points to the
    index’s old location even after the move is complete.

    The second administrative action that causes configuration
    problems is renaming a domain. I’m not exactly sure of the nature of the
    configuration issue, but I’ve been told that it has to do with an Active
    Directory mismatch.

    The third circumstance that results in a configuration error
    is modifying the primary SMTP address for the default recipient policy. Again, doing so results in some sort of mismatch.

    Technically, you don’t even have to worry about
    understanding the nature of the configuration errors though. The STATUS action
    will tell you if configuration errors are present, and the FIXUP action will
    correct those errors. As with the STATUS action, the FIXUP action requires you
    to specify the server and index name that you want to run the MSSearch Admin
    tool against. The syntax is as follows:

    MSSearch_Admin.vbs /Action:FIXUP
    /ExServer:<server name> /Index:<index name>

    Once last thing that you need to know about the FIXUP action
    is that after running FIXUP against an index, the index will be disabled for
    searching. To make the index usable after running a FIXUP, you must run a full
    population against the index and then enable the index. The FULL and the ENABLE
    actions that I will discuss in a moment can be used for these purposes.


    As you have probably already figured out, the ENABLE action
    enables the specified index for searches. The syntax for the ENABLE action is
    as follows:

    MSSearch_Admin.vbs /Action:ENABLE
    /ExServer:<server name> /Index:<index name>


    Just as the ENABLE action is used to enable searches against
    an index, the DISABLE action prevents an index from being searched. If you want
    to disable an index, you can do so by using the following command:

    MSSearch_Admin.vbs /Action:DISABLE
    /ExServer:<server name> /Index:<index name>


    If you’ve done much work with full text indexing, then you
    know that after an index is created, it must be populated. If you want to
    perform a full index population, you can do so by using the FULL action. The
    only stipulation to using this action is that the indexes current status must
    be IDLE. You can perform a full population of an index by entering the
    following command:

    MSSearch_Admin.vbs /Action:FULL
    /ExServer:<server name> /Index:<index name>


    The INCREMENTAL action launches an incremental population of
    an index. An incremental population refers to a situation in which an index is
    already populated, but you want to update the index to reflect the most recent
    additions to the store. As with full population, the INCREMENTAL action can
    only be used against an index with a status of IDLE. The syntax for an
    incremental population is:

    MSSearch_Admin.vbs /Action:INCREMENTAL
    /ExServer:<server name> /Index:<index name>


    The PAUSE action temporarily suspends the index population
    process. You can pause the population process any time that an index’s status
    is either CRAWLING or CRAWLING INCREMETAL. The command for pausing
    an index population is:

    MSSearch_Admin.vbs /Action:PAUSE
    /ExServer:<server name> /Index:<index name>


    As you might have guessed, the RESUME action allows you to
    go back to populating an index after a pause. To resume the population process,
    use this command:

    MSSearch_Admin.vbs /Action:RESUME
    /ExServer:<server name> /Index:<index name>


    The STOP action works exactly like the PAUSE action except
    that instead of temporarily suspending index population, the population process
    is aborted. In order to use the STOP action, the index must have a status of
    CRAWLING or of CRAWLING INCREMENTAL. The command for aborting index population

    MSSearch_Admin.vbs /Action:STOP
    /ExServer:<server name> /Index:<index name>


    The RESET action is used to reset a malfunctioning index.
    This command should be used as a last resort only. The RESET command is
    basically the equivalent to deleting an index and recreating the index from
    scratch. Of course this means that the index will have to be completely
    repopulated after the reset occurs. If you decide that you need to reset an
    index, you can do so by using the following command:

    MSSearch_Admin.vbs /Action:RESET
    /ExServer:<server name> /Index:<index name>

    Getting control over indexes

    As you can see, the MSSearch Admin tool gives you more
    control over full text indexing than what the Exchange System Manager gives
    you. Although this utility takes a little getting used to, it is pretty much
    the most powerful tool available for managing indexing within an Exchange