Fixing WPDOMAIN.DB Files


Fixing WPDOMAIN.DB Files

GroupWise WPDOMAIN.DB files should be approached differently than GroupWise WPHOST.DB files. Here are some concepts to keep in mind when repairing WPDOMAIN.DB files:

  • Secondary domain databases are always rebuilt from the perspective of the primary domain's WPDOMAIN.DB file.

  • The primary domain and its secondary domains might not always be in sync.

  • In some circumstances (although rarely), accessing the backup WPDOMAIN.DB file might be the best solution.

  • On some rare occasions, rebuilding a domain database might actually cause more problems than it fixes.

The best way to explore these concepts is through some scenarios.

For scenario #1, you are connected to the primary domain. You attempt to connect to DOMAINC, and when trying to do so, you get the error shown in Figure 22.3.

Figure 22.3. An error from a damaged WPDOMAIN.DB file


This error is telling you that your attempt to connect to the WPDOMAIN.DB for DOMAINC could not be changed because of a problem with the WPDOMAIN.DB for DOMAINC. On further investigation, you also see that the message transfer agent (MTA) for DOMAINC is not loaded. Things aren't looking good for DOMAINC's domain database.

It's a safe bet that DOMAINC's WPDOMAIN.DB file is corrupt beyond use. You can validate this theory by running a validate operation against DOMAINC. It will give some kind of an error, such as Error opening database. The WPDOMAIN.DB file needs to be replaced. The question then is should the WPDOMAIN.DB file be replaced from backup tape, or should it be rebuilt?

Theory tells us that everything that is in a secondary domain's WPDOMAIN.DB file is replicated up to the primary domain. If there is no reason to believe that this process of replication was impeded, don't hesitate to rebuild the DOMAINC WPDOMAIN.DB file. The WPDOMAIN.DB for DOMAINC is rebuilt from the WPDOMAIN.DB of the primary domain.

The decision to rebuild a WPDOMAIN.DB file rather than bringing it back from backup largely depends on your administration model. Suppose that you and one other person administer your GroupWise system. You both connect to the primary domain for administration purposes and connect to a secondary domain only occasionally. In this scenario, with an understanding of architecture, there is no reason to recover a secondary domain database from tape. The primary domain already knows about changes made to that secondary domain, because it proposed all the changes.

Now consider the following twist: Suppose that there is a damaged secondary domain that is in one of your field offices. A team in the field administers the secondary domain, and the team's wide area network (WAN) link to you is often unreliable. You and the domain administrator already concur that some of the changes made to the secondary domain might never have made it to the primary domain. If the field office has a recent backup of the WPDOMAIN.DB file, the team's copy might be the most accurate regarding the objects they own.

If they recover their WPDOMAIN.DB from backup tape, you have a new procedure to consider. You can assume that their WPDOMAIN.DB file is accurate, minus any changes that they made in their domain since the backup. The secondary domain administrator can worry about remaking those changes. As long as they didn't add, rename, or delete any users, it's not a big deal. Unfortunately, this secondary domain's WPDOMAIN.DB database is not going to be accurate regarding the changes made to the rest of the GroupWise system. To make matters more confusing, the primary domain database is not going to be accurate regarding objects owned by this out-of-sync secondary domain.

If you rebuild this secondary domain, the field office will lose some changes that the primary domain never knew about, unless, of course, you synchronize the primary domain with the secondary domain first. Here is the procedure for synchronizing the primary domain with the secondary domain:

1.

Highlight the secondary domain.

2.

Choose Tools, GroupWise Utilities, System Maintenance.

3.

Select Sync Primary with Secondary and click Run.

4.

After that procedure is complete, you can rebuild the secondary domain database.

Note

You will need file access to the secondary domain to go through this procedure. Because you are dealing with a field office with unstable WAN connections, consider bringing a copy of that office's domain database to your local site. When you are prompted for the path to the domain database to synchronize with, and later to rebuild, you can point to your local drive, or to a location on the network.

You had to synchronize the primary domain with the secondary domain so that the primary domain knew about the changes made to the secondary domain. When a secondary domain is rebuilt, it is done from the perspective of the primary domain. The secondary domain database on disk is ignored altogether. The Sync Primary with Secondary operation took care of this task for you, pushing up the secondary domain's information, on the objects it owns, to the primary domain. Then when the secondary domain is rebuilt just after the synchronize operation, the secondary domain will receive those objects back correctly. The secondary domain will also have all the correct information about the state of the GroupWise objects throughout the rest of the GroupWise system.

For scenario #2, the primary domain's WPDOMAIN.DB file is corrupted beyond repair. You know this because you cannot connect to the WPDOMAIN.DB in ConsoleOne, and the MTA for the primary domain will not load.

First of all, as a responsible network administrator, you should certainly have a backup of your primary domain. The question is whether restoring that backup is going to be the best thing to do. Typically, it is not the best solution.

The primary domain's WPDOMAIN.DB file on your backup will quite likely be outdated, especially if your system is administered from multiple secondary domain sites. Your best hope is a secondary domain that you feel is likely to be in sync with the primary domain. Recall the GroupWise architecture. The GroupWise primary domain broadcasts all changes made to all domains to every other domain. In theory, then, if everything is in sync, a secondary domain is just as well informed about the state of the GroupWise directory as the primary domain. You now need to generate a copy of the primary domain database from a secondary domain. Here is the procedure to generate a copy of the primary domain database from a secondary domain:

1.

Make sure that the primary domain's MTA is unloaded and that nothing is accessing the primary domain's WPDOMAIN.DB file.

2.

Rename the primary domain's WPDOMAIN.DB file to something that will indicate that this is the corrupt or bad database.

3.

Connect to the secondary domain that is most likely to be in sync with the primary domain.

4.

Highlight the primary domain.

5.

Choose Tools, GroupWise Utilities, System Maintenance.

6.

Select the Replace Primary with Secondary option, as shown in Figure 22.4.

Figure 22.4. The Replace Primary with Secondary option allows you to recover a lost primary database


You have now re-created the primary domain from the secondary domain. This solution is ideal because it does not require going to a backup solution.



NOVELL GroupWise 7 Administrator Solutions Guide
Novell GroupWise 7 Administrator Solutions Guide
ISBN: 0672327880
EAN: 2147483647
Year: 2003
Pages: 320
Authors: Tay Kratzer

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net