Problems encountered when restoring a DiRT backup to a newly installed system fall into two basic areas: not making sure the new system is fully functional prior to restore (very common) and having permissions issues in the directory that make the user synch process fail.  Since major changes to the DiRT restore have been few and far between in the last year, the vast majority of escalations that come into TAC for DiRT restore problems are not actually problems with the restore tool - they are issues with the environment that it was run in.  There's a few things you can do that will save you a bunch of time and pain.

 

Making sure the new installation is running properly first

 

By far and away the most common root cause of restore problems is the new installation is not completely tested and flying right before the restore is called.  This alone accounts for over %90 of the escalations that come to the BU for this tool.  Just because Unity comes up does not mean it's ready to go on all fronts.  Prior to doing the restore, here's a few things to do first.

 

1. Create a new subscriber via the SA.  This ensures the service accounts you have configured have rights to create new AD accounts and mailboxes among other things. 

2. After the user from #1 is created, leave them a message and make sure their MWI goes on.

3. After the MWI is on, call in as that user and listen to the message then delete it and make sure the MWI goes off.

 

If steps 1, 2 and 3 all work properly you can be sure the ability to create new accounts is there for the default user container, the mailstore integration is working and the phone integration configuration is all flying right.  DiRT restore relies on all of these being in place and working, it does not change any of these settings during restore.

 

4. If you are restoring into an environment where there are pre existing users in the directory, then import a user from EVERY CONTAINER that houses AD accounts you intend to import subscribers from.  A very common problem is permissions issues on specific containers in the AD forest.  If these users are tagged as subscribers already, then create a test AD account in those containers and import them.

 

Since DiRT uses the same procedure calls to synch users into the directory as the SA does, doing #4 will ensure existing users can be imported during the restore process.  It's important to note that DiRT never accesses the directory itself (either AD or Domino) - it goes through the existing Unity interfaces to have the directory facing service accounts do this work. 

 

You can delete subscribers after you import them, this wont cause a problem.  DiRT checks that there are fewer than 10 subscribers in the system prior to doing the restore to ensure you don't accidentally destroy a production system you didn't intend to.  Creating a few test subscribers is not going to cause the system to be considered "dirty" here.

 

As a final note here, just about every site that escalates due to a DiRT restore failures along these lines is %100 sure their permissions and account assignments are perfect and just about %100 turn out to be wrong.  Please, please, please test and don't assume.  The extra 15 minutes this will take could save you days of agony.

 

Reviewing logs after a restore

 

Catastrophic errors in the DiRT restore procedure that require the restore to abort (i.e. invalid configuration information found, Unity not running, etc...) will result in a dialog box popping up and the restore will abort.  All other errors and warning during restore are found in the DiRT restore log or the SQLSyncSvr log.  The DiRT restore log is offered after the restore completes and you can review it for the strings "(error)" or "(warning)" for potential issues.

 

The most critical part of the DiRT restore is the SQL synch - this is the process that matches up all the subscribers, locations and distribution lists that are defined in the backed up SQL database with objects in the directory.  DiRT does not directly access the directory itself, rather it goes through the same Unity interfaces that the SA uses when importing or creating new users.  There's nothing special or different about how DiRT goes about this.  Make sure to review the "Creating New Accounts or Binding to Existing Accounts" section in the Restore Procedure Overview section for details on how this works.

 

The SQL Sync procedure is the last thing DiRT calls - the DiRT restore itself is complete at this point - there are no further changes to be made to the database, registry or local file system after that.  DiRT is simply waiting for the SQL synchronization to complete.  If this fails, or seems to take too long (this can take many hours in a large system), check the SQLSync log found in the \Commserver\Logs\ directory - the most recent file that starts with SQLSync_* is the one to look at.  This log will enumerate each object being searched for in the directory, if it's found or not and if the bind or create function worked for that user.  If you see errors in here, it should give you a clue as to the source - if it finds a user but the bind fails, it's a pretty good bet there's a permissions issue with the directory account relative to that user.  If the find fails and it creates a new account but that gives an error, again this is very likely a permissions issue in the container the create is taking place.

 

Finally, if the restore fails for whatever reason, always include both the DiRT restore log and the SQLSync_* log - be sure to capture them both since they will both be necessary to determine the trouble.