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.

Requirements/Special Notes

This version of dbWalker run on Unity 4.0(1) and later systems. For users of 2.x or 3.x, you will need to obtain the appropriate version of dbWalker off www.CiscoUnityTools.com.

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 for versions of Unity prior to 4.2(1). For versions of 4.2(1) or later, you need to use the Telephone Integration Manager application in the Tools Depot to repair invalid switch references.

· 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.

· The MailstoreObjectID value is checked to be sure it has a corresponding entry in the MailboxStore table in UnityDB.

· If the subscriber has their EncryptPrivateMessages flag turned on, dbWalker makes sure there is a certificate installed for message encryption. This check is made on 4.0(5) and later.

· If the subscriber has the option to edit broadcast messages, dbWalker ensures that they also have the ability to send broadcast messages. This check is made on 4.0(5) and later.

· Blind addressing members in private distribution lists are checked for corresponding entries in the global locations table. This check is made for Unity 4.0(5) and later.

Call Handlers

· Owner exists and is valid. This can be fixed automatically for NON primary call handlers. If a call handler is tagged as primary (i.e. it's supposed to be part of a subscriber) this will not be automatically fixed.

· Recipient exists and is valid. This can be fixed automatically for NON primary call handlers. If a call handler is tagged as primary (i.e. it's supposed to be part of a subscriber) this will not be automatically fixed

· Location exists and is valid.

· Text Name, makes sure it's not blank in the case of a nonprimary call handler.

· DTMF_ID, make sure it's not blank in the case of a primary call handler.

· DTMF_ID does not conflict with another object either locally or in the dialing domain. If a conflict is found, a list of all objects that share that ID in the dialing domain will be listed.

· If the call handler is primary it checks for all alternate extensions associated with the subscriber tied to the call handler to be sure the ID is unique in the dialing domain.

· If the after greeting action loops back around to itself a warning is logged for all greetings except the "error" greeting for which this is not unusual.

· After message action links to a valid object.

· All one key rules (caller input keys) link to valid objects. This can be fixed automatically if desired.

&midd