This utility walks the directory and makes the checks listed below on all call handler, subscriber, subscriber template, interview handler, locations and directory handler objects in the database. If there's a problem the string "(error)" will appear in red in the output HTML. Warning strings in yellow that start with "(warning) are also logged for items that you should check on but are not necessarily problems. If an item is automatically fixed, a string that starts with "(fixed) will be logged in green directly under the error to indicate what was done. See the example file output below for more.

When it's complete a dialog will pop up letting you know it's finished and telling you how many errors and warnings were encountered in the process and you'll be given the opportunity to view the output file. Just search the output file for the string “(error)” or “(warning)” and you will be taken right to each problem in the log. Brief explanations of the problems encountered will usually appear on the following line in the log, be sure to read them in their entirety to determine what you should do about them, if anything.

Some problems are logged as errors and fixed automatically on the fly (i.e. if the standard contact rule or greeting rule has been disabled, it will be enabled again on the fly). Some problems are fixed optionally if you indicate it’s OK (i.e. orphaned call handlers are removed if you check the option to do so at the top of the form). Other problems cannot be fixed automatically and you will need to intervene manually to clear the issue up.

The logging detail drop down can be set to show information about all objects checked during the database walk or you can choose to limit the output to only those objects that encounter one or more errors or warnings or just those objects that encountered one or more errors (default). Each time you press the "Walk Database" button, a new output file is generated and stored under the \logs\ directory where you installed dbWalker. To quickly view the logs directory you can select File | View Log Directory from the menu and it'll open File Explorer to that directory automatically. Whenever dbWalker runs it will automatically delete any logs in this directory older than 10 days.

Setup

dbWalker 3.x runs on Unity Unity 3.0(1) and later versions only. For users of Unity 2.x you will need to obtain a version of Unity 2.x off www.CiscoUnityTools.com or the CCO Utilities download page.

dbWalker must run on the local Unity server, it cannot run off box.

A Word About Automatic Fixes

It is strongly recommended that you first run dbWalker with no automatic fix options selected at all and review the output it generates before you select any automatic fix options. Once you've run the tool, reviewed the resulting output and understand what changes will be made with the selected automatic fixes (see below), then run dbWalker again and select the desired automatic fix options.

Checks Made

Subscribers

Display Name, makes sure it's not blank.

Primary Call Handler exists and is valid and is unique in the dialing domain

All alternate extensions are unique in the dialing domain.

Primary Call handler is not "shared" by another mail user.

COS reference exists and is valid.

Location exists and is valid.

Language selected for user is installed on the box. This can be automatically fixed if desired.

Switch ID is valid and references a switch installed on the box. This can be automatically fixed if desired.

Makes sure voice name referenced in database actually exists as a WAV file on the hard drive.

The rest of the data associated with a subscriber is contained in the "primary call handler" assigned to this subscriber and those checks are made during the call handler sweep.

Checks that private distribution lists have display names associated with them. A warning is logged if it's empty.

Checks that private distribution lists have members associated with them - if not a warning is logged. This can be fixed automatically by removing the list if desired.

Checks that the exit destination for the subscriber is valid (Unity 4.0 and later only)

Ensure the smtpAddress value is not NULL

(optional) Transfer strings, notification devices and fax delivery numbers are checked against the restriction tables assigned to the COS the subscriber is associated with. This check is optional because in some situations a company may wish to assign subscribers to COSes that don't allow any numbers to be entered by the subscribers themselves, instead requiring they go through a help desk administrator to change these. By default this check is not done, you need to select the checkbox at the top of the form to have these additional tests run. This can be fixed automatically by disabling the offending device if desired. See "A Note About Fixing Restriction Table Violations" below before you do this.

For all remote subscribers, make sure the remoteAddress column is not NULL - this is done for 4.0(1) and later only.

For all remote subscribers, make sure the remoteAddress column is unique for each subscriber in the global subscribers table. This is done for 4.0(1) and later only.

For all remote subscribers, make sure the legacy mailbox ID and RemoteNode id values are valid. Both can be NULL or both can have values. If they do have values make sure both are all digits and that they are a unique pair in the global subscribers table. This check is made for 4.0(1) and later only.

Checks to be sure the DirectoryID value is not blank/NULL - this indicates that the object has not yet synchronized properly with the directory.