Fixing WPDOMAIN.DB FilesGroupWise 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:
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:
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. |