iPlanet Meta-Directory v 5.0 Configuration and Administration Guide: Appendix C Troubleshooting Meta-Directory

Previous Contents Index DocHome Next

iPlanet Meta-Directory v 5.0 Configuration and Administration Guide

Appendix C     Troubleshooting Meta-Directory

This appendix describes troubleshooting techniques for Meta-Directory. In addition, it addresses some common configuration problems and how they can be fixed. This chapter contains the following sections:

Verifying End-to-End Flow

Viewing Link Information

Checking Operational Status

Examining Log Files

Turning Off UID Uniqueness

Fixing Join Problems

Fixing Data Flow Problems

Fixing Large Synchronization Failures

Common Problems

Verifying End-to-End Flow

To determine whether a Meta-Directory event occurred as expected, use the Meta-Directory console to systematically verify the attribute flow from the meta view to the connector view and then to the external data source. If the window is not available to verify that an entry has been modified, added, or deleted, invoke the related view in Netscape Communicator by typing the entry's LDAP URL in the location window and pressing Return. You can also use any LDAP viewer application.

Viewing Link Information

The attributes of an entry indicate whether the Meta-Directory link information between the connector view and the meta view was added correctly. Note that the join engine adds several attributes to each entry that contain useful debugging information.

mdsEntityOwner

You can use the mdsEntityOwner attribute for an entry to determine whether the connector view is properly configured, including which view owns the entry. For example:
mdsEntityOwner: MV, MYMV
If you cannot delete an entry from a connector view, it may be because the meta view owns the entry. Only a view that owns an entry can delete the entry.

mdsLinkToCV

Viewing this attribute is useful in determining where the entry is linked and to what it is linked. It points to a meta view entry's corresponding entry in a connector view. For example:
mdsLinktoCV: MYMV#HRCV#cn=thowes
Multiple values for this attribute are possible, one for each connector view to which the entry is linked.

mdsLinkToMV

Viewing this attribute is useful in determining where the entry is linked and to what it is linked. It points to a connector view entry's corresponding entry in the meta view. For example:
mdsLinktoMV: MYCV#HRMV#cn=thowes

Checking Operational Status

To make sure a connector view is working correctly, you can check the Status and Statistics windows in the Meta-Directory console. More information on these windows can be found in Chapter 14 "Monitoring Meta-Directory Components".

Status Window

When a problem occurs between the meta view and a connector view, check the status of the connector view in the Meta-Directory console. The Status window indicates whether the view is enabled, disabled, or performing a refresh operation. For flow problems occurring between the meta view and the connector view:

If the connector view is enabled and remains enabled, the likely cause is a misconfigured join rule. You can check each of the rules for questionable syntax by using the Join Rule Tester (Configuration > Join Rules > Rule Tester). To find out exactly what failed, you can view the logs.

If the connector view is enabled but becomes disabled, the likely cause is a bad DN mapping rule, attribute flow rule, or corrupted data. This causes a flow problem to occur between the meta view and the connector view.
Normally, a view is automatically disabled when the join engine encounters an error with one of the rules that would compromise data integrity.

Statistics Window

The Statistics window usually indicates whether or not errors are presently occurring. Here is a guide for what to look for in the Statistics window:

When many errors appear during a refresh, the likely cause is a bad rule or rule set. Make sure you have added rules to the rule set. You can use the Join Rule Tester to check each of the rules or rule sets for incorrect syntax. You can also check the logs as described above under Status Window.

When add or modify operations appear without errors, and then an error suddenly appears causing the counter to stop, this indicates that the view was disabled by corrupted data.

Note The Windows NT Synchronization Service only reports operational status and not statistics.

Data Server Test Connect Button

This button is a useful tool when you want to check if the configuration for your data server is correct. This button provides feedback on your configuration.

Examining Log Files

You can track the flow of information between connector and meta view by examining the logs.
Most problems with flow involve a failure in the configuration of flow rules. Join engine logs are helpful in determining the cause of the problem if, for example, the join engine couldn't contact a server or if a bind operation failed.
The join engine log reports the transactions between the meta view and connector views. Each transaction is time-stamped and includes the relationship between the meta view and the connector view and a message. When a new entry is added, the join engine detects the changes and initiates action using all the rules defined for the enabled connector views. The join engine evaluates rules in the following order:

Filter configuration rules

Join rules

DN mapping rules

Attribute flow rules (including constructed attributes)
To see how each rule executed, you can increase the logging level of data access to 3 (Configuration > join-engine > Log > Verbosity). This should enable you to see exactly which rule failed and why it failed, thereby assisting you in correcting your rules grammar. However, for the case of a faulty constructed attribute, the log does not indicate the problem directly. If a constructed attribute fails, the information at the highest logging level (3) only states that the mapping failed for the rule.
For more information about monitoring log files, refer to Chapter 14 "Monitoring Meta-Directory Components."

Turning Off UID Uniqueness

UID uniqueness is one of the constraint violations that can occur, and is the most common one with Directory Server 4.x. If you have multiple views on one Directory Server, and the entries are using UID, you could have two entries in two different views with the same UID. To Meta-Directory, this is acceptable, but to a Directory Server with the UID plug-in turned on, this is an error.
By default, UID uniqueness is turned on for Directory Server 4.x, but turned off for Directory Server 5.0. For constraint violations in Directory Server 4.x, you should turn off UID uniqueness.
Use the following methodology to resolve a problem that might occur when your data has an attribute UID.

Open the Directory Server through the Console.

Click on the Configuration tab.

Click on the topology tree at Plugins.

Scroll down to "uid uniqueness" and click to open.

Uncheck the Enable plugin box.

Restart the Server.

Fixing Join Problems

If you are experiencing unexplained incorrect joining, make sure that data is not flowing directly from the connector into the meta view.
If the join engine won't install, the most common reason is that the Directory Server is improperly configured. During installation, the join engine must point to a Directory Server instance that contains the configuration directory o=NetscapeRoot.
The following error messages, when received during join engine configuration, indicate a Directory Server configuration problem:

DA_E_INVALID_CREDENTIALS

The user and/or password are set incorrectly.

DA_E_NO_SUCH_OBJECT

The o=NetscapeRoot suffix is not set in the Directory Server, or the entry does not exist.

DA_E_OBJECT_CLASS_VIOLATION

The Meta-Directory schema was not properly loaded into the Directory Server.

MDS_CONTROLLER_UNAVAILABLE

You have not created the 4.x changelog (retro changelog plug-in 5.0), or you have created, configured, and enabled it through instance creation, but have not restarted the Directory Server. Check that the path and suffix/subtree you provided for the changelog is valid.

Fixing Data Flow Problems

Use the following methodology to resolve problems that you might encounter with data flow.

View the data source and make sure that data exists. To check that the data hasn't already synchronized, use refresh the view to see updates.

Verify end-to-end attribute flow.

Check operational status. Is the view enabled? What statistics are being reported for the view?

Check statistics.

Make sure the join engine and the connectors are running.

For indirect connectors where no data appears to synchronize to the connector view, check the scheduled time the data is configured to synchronize. Wait until that time has elapsed, then schedule the task to run more frequently.

Examine the relevant log files. The join engine log keeps track of errors resulting from rules that aren't configured properly. The Directory Server logs show objectclass violations, constraint violations, or other LDAP problems. You can also increase the log level to check rules (Configuration > join-engine > Log > Verbosity).

Fixing Large Synchronization Failures

Large synchronizations can fail on very slow systems or networks. You can initiate the debug process by increasing the log level to 3 (Configuration > join-engine > Log > Verbosity) if you see the message USER_TIMELIMIT_EXCEEDED. You can also go to Configuration > Meta-Directory > Data Servers > Tuning and increase the value in the Maximum Operation Result Time field.

Common Problems

This section discusses common configuration problems and their possible solutions. Tabular information is presented for problems associated with the following components:

Instances

Configuration

Views

Connectors

Meta-Directory

Directory Server

Instances

lists troubleshooting tips for problems you might encounter while creating instances.

Table C-1    Problems with Instance Creation

Problem

Suggested Action

Schema/objectclass violations occur when you try to save configurations through the console.

Check whether you loaded the schema into all directory servers in your system, including the directory server containing the configuration.

The join engine failed, and the log shows MDS_CONTROLLER_NOT_AVAILABLE.

Check that you did the following:
Enabled the changelogs for all Directory Servers in your system, including the configuration Directory Server.
Restarted the Directory Server after enabling the changelog.
Provided a valid changelog path for the Directory Server changelog enabling dialog. The path given should have the .dbb files in it, and you should be able to search the changelog suffix. (The default is cn=changelog.)
Provided a valid, unique, non-preexisting, well-formed subtree/suffix for your changelog. Can you search for it?

The join engine failed, and the log shows MDS_CONTROLLER_NOT_AVAILABLE, but you enabled the Directory Server 5.0 changelog through the Directory Server console.

If you are using Directory Server 5.0 and you enabled the changelog through the Directory Server console (and not Meta-Directory instance creation), make sure to enable the retro changelog, rather than the normal replication changelog.

Some changes never flow.

Is your Directory Server culling changelog entries before the join engine can process them? The changelog cleanup has to be set to infinity, or large enough to not delete changes before the join engine examines them.

The Join Engine or connector instance isn't responding to commands.

Allow the join engine or connector sufficient time to start.

The instance creation or view creation failed, and the log shows NO_SUCH_OBJECT.

During instance or view creation, did you specify a view location under an existing suffix that has no data nodes under the suffix? For example, the following scenario would fail:
Use the Directory Server console and specify o=MV suffix, then during instance creation specify ou=MV1,ou=MvEntries,o=MV as the base dn. To make this work, you would need to add the entries o=MV and ou=MvEntries.

Configuration

The following tables list troubleshooting tips for problems you might encounter after configuring iPlanet Meta-Directory.

Table C-2    General Rule Problems

Problem

Suggested Action

Corrupted data, missing values, or objectclass violations are leading to no flow.

Are all your rules being applied in the correct direction? The rules usually will only make sense going one way (meta view to connector view, for example), but not the other way, so if you didn't assign them to the correct direction, nothing will function.

You are not seeing any flow, or your joins are failing.

Make sure all your rules are syntactically correct and free of typos.

Your multi-valued attributes are not flowing correctly.

iPlanet Meta-Directory 5.0 doesn't handle multi-valued attributes very effectively.

The join engine isn't using your rules.

Did you wait long enough for the join engine to re-read the configuration? If the join engine is busy, it might not read the configuration for some time, since it relies on the DCNS queue, and there could be a lot of data changes ahead of your config changes.

You added a rule and it didn't show up in other parts of the console.

Did you try refreshing the console after adding your new rule that didn't show up in other parts of the interface? When you invoke a console refresh, it re-reads everything from the LDAP configuration. As a last resort, restart the console.

There are problems with the data flow.

Does your Join Rules tester produce one entry, no entries, or more than one entry? It should produce exactly one entry. More than one entry means that your rule isn't based on a unique attribute.

Table C-3    Problems with Join Rules

Problem

Suggested Action

You are having problems with corrupted data.

Are the optional token assignments for your join rules correct for all entries that the rule applies to? Your token assignments are possibly failing for certain entries.
Is the selection criteria for your join rules selecting the correct entries? Your selection criteria is possibly identifying the wrong entries or missing some, etc.
Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.

Some entries are not joining.

Is the join filter for your join rules searching on something that uniquely identifies one entry? If the search filter comes up with zero or more than one entry, that entry is skipped.

Nothing is flowing.

The join filter for your join rules must produce a valid LDAP search filter that conforms to the standard and be accepted by the Directory Server. Check the access logs of the Directory Server.

You are experiencing unexpected joining.

Your join rules must be in the right order. The rules in a rule set are evaluated in order.

Table C-4    Problems with DN Mapping Rules

Problem

Suggested Action

Some entries have mangled DNs when they are created.

Are the optional token assignments for your DN mapping rules correct for all entries that the rule applies to? Your token assignments are possibly failing for certain entries.
Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.

You are having problems with mislaid DNs.

Check that your DN Mapping Rules selection criteria are selecting the correct entries. Your selection criteria are possibly identifying the wrong entries or missing some.

You have an entry with an empty or mangled DN (cn=,ou=,o=).

Check that your DN construction is based on a valid, existing attribute for all entries to which this rule applies. Problematic behavior occurs if the DN is based on an attribute that doesn't exist.

An entry is not being added because of an ALREADY_EXISTS error.

Check that your DN construction is based on a unique attribute for all entries to which this rule applies. You've created a problem if two entries have the same attribute value upon which the DN is formed.
Either your DN is not creating a unique DN and you should redesign it, or you actually want to join or link these two entries. In this case, you're using the wrong type of rule. You're missing a join rule which would do this join or link.

Entries are not being added.

Check that your DN construction produces a valid DN that conforms to the DN standard and that it is accepted by the Directory Server.

Entries are not being added in the right place, or are not being added at all.

The DN shouldn't be a complete DN. It needs to be relative to the view's base DN.

Table C-5    Problems with Attribute Flow Rules

Problem

Suggested Action

There is no flow because attribute values are not present, or there is incorrect attribute mapping.

Check that your Attribute Flow selection criteria are selecting the correct entries. Possibly the selection criteria are identifying the wrong entries or missing some, or there is a typo and you created the wrong mapping between the source view and the target view. Another reason may be that you are trying to map to an attribute that is the wrong data type for your source data.

There are missing attributes or no flow due to objectclass violations.

Check that your attribute flow is complete and that you haven't missed any attributes. What objectclasses are you trying to flow? Does your attribute flow produce objectclass compliant entries? Does your attribute flow produce LDAP-compliant entries? Do they have objectclasses?
Check which attributes are mandatory for that schema, such as cn and sn for inetorgperson. Check the Directory Server error log for clues about problems with objectclass violations.

There is no flow in a given direction.

Check that your attribute flow rule is configured for the correct direction. Each rule has a specific direction associated with it. Open the rule through the interface and make sure that the direction is correct.

Table C-6    Problems with Constructed Attribute Rules

Problem

Suggested Action

There is no flow because of corrupted data or objectclass violations.

Are the optional token assignments for your constructed attributes correct for all entries that the rule applies to? Your token assignments are possibly failing for certain entries.
Is the selection criteria for your constructed attributes selecting the correct entries? Your selection criteria is possibly identifying the wrong entries or missing some, etc.
Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.

There is no flow because of corrupted data, objectclass violations, or missing values.

Check that your attribute construction is based on valid, existing attributes with values. Check that you actually mapped your constructed attribute to something in attribute mapping.

Table C-7    Problems with Filter Rules

Problem

Suggested Action

There are missing entries.

Are the entries missing in the flow portion of an excluded subtree? If you've set up a subtree filter, any entries in the excluded subtrees won't flow.
Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.

Views

lists troubleshooting tips for problems you might encounter with connector views.

Table C-8    Problems with Views

Problem

Suggested Action

No data is flowing.

Make sure your view is enabled.

You have experienced unexpected or malfunctioning data flow.

Check that your LDAP-based views are in separate subtrees.
Have you or an application directly modified the data in the connector view? Only MDS should be handling the data.
Is the subtree of one view a descendant of another? The view subtrees cannot overlap.

No data is flowing.

Have you added the connector view from which you wish to flow as a participating view to the meta view? If the connector view isn't added as a participating view, nothing happens.

You've enabled your view, but no data is flowing and the view keeps getting disabled.

Check DN mapping and attribute flow for corrupt data, then check for faulty join rules.

You have experienced erroneous joining.

Make sure you are not sending data from the connector directly into the meta view.

Your rules aren't being used by the join engine.

Did you apply your rules to the participating view?

Using the MDS console, you were unable to see the contents of a view with many entries.

Did you create a browsing index in the Directory Server console for the suffix of the view with a lot of entries that you are trying to browse? The console can't handle too many entries at once, so it has to rely on the server to give it a Virtual List View, for which you need a special index. See your Directory Server documentation for more information.

No data is flowing, and you see MDS_S_INSUFFICIENT_CAPABILITIES in the join engine logs.

Is your participating view's capabilities set up so that changes/entries can flow in the desired directions?

You have experienced a mapping error and the connector view is constantly being disabled.

Is the root entry of your view flowing? You have to create selection criteria to exclude the objectclass of the root entry, or use a filter.

Connectors

The following tables list troubleshooting tips for problems you might encounter after configuring connectors.

Table C-9    Problems with the Universal Connector

Problem

Suggested Action

No data is flowing

Is your connector running?

The UTC became corrupted and you couldn't flow data.

Did you interfere with the UTC shutdown? Did you issue kill -9 or otherwise stop it uncleanly? Try refreshing to the connector view.

You made changes that the UTC didn't flow, or you clicked on refresh and nothing happened.

Make sure to wait for the default 15-minute polling interval for the UTC to flow your changes. Everything the UTC does is based on the polling interval, including refresh. Consequently, you'll have to change the 15-minute default if you want results sooner.

You have pre-existing connector view entries that are not flowing to the foreign data source.

Try a UTC filter refresh, or "touch" every entry by making a small modification to it.

Some attributes aren't reaching the connector view from the FDS, or you are experiencing objectclass violations.

Is your UTC attribute mapping complete? Did you miss an attribute? In this direction, any attributes not listed in the attribute mapping are dropped

Some modifications do not flow bi-directionally.

Do you have a UTC attribute flow defined, thereby forcing attribute level flow? You probably have entry level flow and are modifying the non-owner.

Some attributes flow to the FDS that shouldn't be flowing, and they're being rejected.

Do you have a UTC attribute flow defined for the connector view to FDS that doesn't handle the attributes that are being rejected by the FDS? When going from the connector view to FDS, everything flows.

You are experiencing objectclass violations.

Do you have different object types and your default values/attribute mapping isn't taking this into account? If you have multiple object types, you should be careful with the UTC rules. You may want to create this material in Perl script/task.cfg.

The UTC-based connector isn't picking up your configuration changes.

Make sure that you restarted the connector after making the configuration changes (except logging).

Some attributes are being mapped incorrectly, dropped, or mangled.

Is your Perl attribute mapping compatible with your UTC attribute mapping? If you've set up Perl script attribute mapping (like LineFormat in task.cfg), you need to make sure your UTC mapping takes that into account.

Your UTC filters aren't working correctly.

Make sure your UTC filters are expressed in connector view DNs, regardless of the direction.

Your 5.0 UTC won't run your script.

Does your UTC perl script have a package name in it? There should not be a package name in the script

Table C-10    Problems with the Universal Text Parser

Problem

Suggested Action

The UTP doesn't seem to be working.

Make sure you copied all the required .pm's, template.pl and the *.cfg files from NETSITE_ROOT/bin/utc50/ install/templates/
universalparser.
Make sure you renamed one of the .cfg files to task.cfg.
Did you forget to set the template.pl script path for the UTC?
Does the script path to template.pl specified in the UTC UI appear in an ls or dir listing from the command line?

The UTP isn't working correctly.

The text editor you used to edit task.cfg should not remove trailing white spaces from the end of lines. Did you specify DN as your IndexAttribute in task.cfg? IndexAttribute must be a unique attribute, but not DN.

The UTP isn't working because of objectclass violations.

Make sure you specified your LineFormat correctly in task.cfg. Does the resulting entry conform to inetOrgPerson or whichever objectclass you've specified?

The UTP isn't flowing data.

Is InputFile set correctly in task.cfg? Make sure that template.pl can find the input file.

The UTP isn't flowing changes to the external data source.

Make sure you specified your ImportLineFormat correctly in task.cfg. Is the import function expecting a different format?
Is the import utility accessible from template.pl? There may be a path problem or a permissions problem, or perhaps the utility doesn't exist or is not executable.

Table C-11    Problems with the NT Domain Connector

Problem

Suggested Action

No data is flowing

Is your connector running?

Changes aren't flowing to NT SAM.

Is the machine you specified as NT Domain host write a PDC?

Changes aren't flowing to or from NT SAM.

Check whether logs like ntdc-ntacc-*.log and ntdc-perl-*.log are in your NTDC instance. If no logs are present, the accessor never started. Check the host and domain names in ntdc.conf.

Writes to NT SAM are failing.

If you are running the NT Domain Connector on a machine other than the PDC, is it running under the Domain Administrator account?

Configuration changes you made to ntdc.conf haven't taken effect.

Did you restart the NT Domain Connector after changing ntdc.conf?

Some pre-existing entries in connector view for the NT Domain Connector aren't flowing to NT SAM.

Make sure you refreshed the meta view.

Entries are not flowing to NT SAM.

Make sure your join engine rules ensure the entry format that the NT Domain Connector is expecting.

Some changes to certain attributes made from the connector/meta view aren't flowing into NT SAM.

Are the attributes you changed on the list of attributes only changeable from NT SAM?

You are unable to modify some entries from the Admin Tool.

Are you flowing user names that are less than 20 characters in length?

Table C-12    Problems with the Database Connector

Problem

Suggested Action

No data is flowing

Is your connector running?

There are missing OCI errors in the database data server UI.

Make sure you installed OCI.

Changes won't flow to or from Oracle, or your database-based view keeps being disabled.

Did your DBA successfully run the SQL scripts against Oracle?

There are flow problems, or you see DA_E_ALREADY_EXISTS in the join engine logs.

For each table, make sure the columns you chose for nominated keys uniquely identify the row.

Oracle is rejecting your SQL scripts.

Did you replace any placeholders in the SQL instrumentation scripts with DBA-approved values.

Oracle is rejecting the SQL scripts, or the Database Connector is performing strangely.

Did you change anything in the SQL instrumentation scripts that were marked "Don't Change This"?

Oracle is rejecting the SQL scripts due to authentication problems or this error: "ORA-01031: insufficient privileges."

Did you or your DBA run the SQL instrumentation scripts against Oracle as the System Database Administrator User?

Instrumentation scripts fail during the creation of the changetables, or you see this error: "ORA-00957: duplicate column name."

For your data server, make sure you select column names for Action Column and SynchPoint Column that are unique across entire Oracle instance.

SQL scripts fail with "Cannot remove user."

Was the Join Engine trying to synchronize Oracle when you ran the Delete Data Server SQL scripts? This is because the join engine is probably connected to Oracle. Remove all views based on the data server from the meta view's participating views list first, and then wait for the join engine to finish before re-running the SQL commands. As a last resort, stop the join engine.

Oracle flow is failing because of objectclass violations.

Did you make a constructed attribute for Objectclass for your DB-based views?

Oracle flow is malfunctioning because of ALREADY_EXISTS errors and missing entries.

Are your DN mapping rules for DB-based views based on the Primary or Nominated Key(s)? The DN must be based on the Primary Key/Nominated Key when flowing from the meta view to the connector view. This is also recommended when flowing from the connector view to the meta view.

All modify operations on the Oracle connector view fail.

Did you duplicate mappings between DN Mapping and Attribute Flow for the Database Connector? You should not duplicate mappings. If you've mapped EMPNO to employeeNumber in attribute flow and then made your DN mapping rule look like:
EMPNO=%mv.employeeNumber%
the flow from the meta view to the connector view will be broken.

There is no flow to or from Oracle.

Did you change the structure of any of your instrumented Oracle tables, such as removing a column? If you change the structure of the table, such as deleting an instrumented column, the Database Connector will cease to function. You will need to uninstrument and reinstrument.

There is no flow to or from Oracle, or you notice that the changelog is broken (no changes are being logged), or you see trigger-related error messages in Oracle.

Did you run the same DBC SQL script twice? Ask this if the user tells you no flow to/from Oracle is happening or if they notice that the changelog is broken (no changes are being logged) or if they see trigger-related error messages in Oracle. If you run the same script twice, the triggers cease to function.

Meta-Directory

lists general troubleshooting tips for iPlanet Meta-Directory.

Table C-13    Problems with iPlanet Meta-Directory

Problem

Suggested Action

The message DA_USER_TIMELIMIT_EXCEEDED appeared during the join process.

Is your data server search time-out parameter high enough?

The join engine is sluggish, and there's increased memory usage.

Is your data server poll interval high enough?

You are experiencing poor performance.

Are your join engine and/or console and/or Directory Server all on the same machine?

You are experiencing several "can't connect" errors, or time-outs.

Are all the machines reachable from one another? Ping all of the machines to make sure they can communicate with each other.

You are experiencing poor flow.

Do you see many errors in the Statistics window, or just a sudden stop? Many errors means faulty rules, and a sudden stop means corrupt data.

There is no data flow.

Make sure that both the join engine and connector are running.

Directory Server

lists general troubleshooting tips for Directory Server.

Table C-14    Problems with Directory Server

Problem

Suggested Action

No data is flowing.

Is your Directory Server running?

The Directory Server times out during large synchronizations.

If you're using Directory Server 4.x, make sure your ioblocktimeout parameter in slapd.conf set to a high enough value (180000000 or higher).

You are experiencing poor performance, especially during large synchronizations.

Make sure your Directory Server is properly tuned for writes.

You are experiencing poor performance, especially during large synchronizations, and errors such as DA_E_UNWILLING_TO_PERFORM, DA_E_USER_TIMELIMIT_EXCEEDED might appear, or other time-out messages might appear.

Did you add the indexes for the linkage attributes (mdslinktocv, etc.)?

The Directory Server disallows the addition of entries because of conflicting UIDs. You will see constraint violation errors.

Did you turn off the UID uniqueness plug-in?

You are experiencing poor performance and have already added the proper indexes for the linkage attributes.

Did you increase the allidsthreshold of the Directory Server?

You are experiencing poor performance and hear disk thrashing on the machine hosting the Directory Server.

Make sure your database cache is big enough to hold all the indexes.

You are experiencing poor performance and hear disk thrashing on the machine hosting the Directory Server, or you see the Directory Server warning at start-up or at the beginning of a database import about your cachesize/dbcachsize being too large for physical memory.

Make sure your Directory Server caches completely fit into physical memory.
Do you have a 3:1 ratio of database to entry cache allocation?
Are your calculations correct for determining the cache size? Did you factor in 25% memory overhead when computing cache size? Your database cache should not be configured for more than 1.6 gigs.

There are missing entries during the join process and/or time-out errors.

Are your Directory Server front-end settings too low? Check the limit, time-out, and so forth.

You see the following message:
ldap_modify: No such attribute: additional info: attribute type is unknown. Cannot delete.

While loading the Meta-Directory schema to a Directory Server instance that does not contain the join engine and meta view configuration information, ldapmodify attempted to delete an entry that does not exist. When ldapmodify applied the Meta-Directory schema, it attempted to delete the attribute type before a new one was added.

Problem	Suggested Action
Schema/objectclass violations occur when you try to save configurations through the console.	Check whether you loaded the schema into all directory servers in your system, including the directory server containing the configuration.
The join engine failed, and the log shows MDS_CONTROLLER_NOT_AVAILABLE.	Check that you did the following: Enabled the changelogs for all Directory Servers in your system, including the configuration Directory Server. Restarted the Directory Server after enabling the changelog. Provided a valid changelog path for the Directory Server changelog enabling dialog. The path given should have the .dbb files in it, and you should be able to search the changelog suffix. (The default is cn=changelog.) Provided a valid, unique, non-preexisting, well-formed subtree/suffix for your changelog. Can you search for it?
The join engine failed, and the log shows MDS_CONTROLLER_NOT_AVAILABLE, but you enabled the Directory Server 5.0 changelog through the Directory Server console.	If you are using Directory Server 5.0 and you enabled the changelog through the Directory Server console (and not Meta-Directory instance creation), make sure to enable the retro changelog, rather than the normal replication changelog.
Some changes never flow.	Is your Directory Server culling changelog entries before the join engine can process them? The changelog cleanup has to be set to infinity, or large enough to not delete changes before the join engine examines them.
The Join Engine or connector instance isn't responding to commands.	Allow the join engine or connector sufficient time to start.
The instance creation or view creation failed, and the log shows NO_SUCH_OBJECT.	During instance or view creation, did you specify a view location under an existing suffix that has no data nodes under the suffix? For example, the following scenario would fail: Use the Directory Server console and specify o=MV suffix, then during instance creation specify ou=MV1,ou=MvEntries,o=MV as the base dn. To make this work, you would need to add the entries o=MV and ou=MvEntries.

Problem	Suggested Action
Corrupted data, missing values, or objectclass violations are leading to no flow.	Are all your rules being applied in the correct direction? The rules usually will only make sense going one way (meta view to connector view, for example), but not the other way, so if you didn't assign them to the correct direction, nothing will function.
You are not seeing any flow, or your joins are failing.	Make sure all your rules are syntactically correct and free of typos.
Your multi-valued attributes are not flowing correctly.	iPlanet Meta-Directory 5.0 doesn't handle multi-valued attributes very effectively.
The join engine isn't using your rules.	Did you wait long enough for the join engine to re-read the configuration? If the join engine is busy, it might not read the configuration for some time, since it relies on the DCNS queue, and there could be a lot of data changes ahead of your config changes.
You added a rule and it didn't show up in other parts of the console.	Did you try refreshing the console after adding your new rule that didn't show up in other parts of the interface? When you invoke a console refresh, it re-reads everything from the LDAP configuration. As a last resort, restart the console.
There are problems with the data flow.	Does your Join Rules tester produce one entry, no entries, or more than one entry? It should produce exactly one entry. More than one entry means that your rule isn't based on a unique attribute.

Problem	Suggested Action
You are having problems with corrupted data.	Are the optional token assignments for your join rules correct for all entries that the rule applies to? Your token assignments are possibly failing for certain entries. Is the selection criteria for your join rules selecting the correct entries? Your selection criteria is possibly identifying the wrong entries or missing some, etc. Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.
Some entries are not joining.	Is the join filter for your join rules searching on something that uniquely identifies one entry? If the search filter comes up with zero or more than one entry, that entry is skipped.
Nothing is flowing.	The join filter for your join rules must produce a valid LDAP search filter that conforms to the standard and be accepted by the Directory Server. Check the access logs of the Directory Server.
You are experiencing unexpected joining.	Your join rules must be in the right order. The rules in a rule set are evaluated in order.

Problem	Suggested Action
Some entries have mangled DNs when they are created.	Are the optional token assignments for your DN mapping rules correct for all entries that the rule applies to? Your token assignments are possibly failing for certain entries. Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.
You are having problems with mislaid DNs.	Check that your DN Mapping Rules selection criteria are selecting the correct entries. Your selection criteria are possibly identifying the wrong entries or missing some.
You have an entry with an empty or mangled DN (cn=,ou=,o=).	Check that your DN construction is based on a valid, existing attribute for all entries to which this rule applies. Problematic behavior occurs if the DN is based on an attribute that doesn't exist.
An entry is not being added because of an ALREADY_EXISTS error.	Check that your DN construction is based on a unique attribute for all entries to which this rule applies. You've created a problem if two entries have the same attribute value upon which the DN is formed. Either your DN is not creating a unique DN and you should redesign it, or you actually want to join or link these two entries. In this case, you're using the wrong type of rule. You're missing a join rule which would do this join or link.
Entries are not being added.	Check that your DN construction produces a valid DN that conforms to the DN standard and that it is accepted by the Directory Server.
Entries are not being added in the right place, or are not being added at all.	The DN shouldn't be a complete DN. It needs to be relative to the view's base DN.

Problem	Suggested Action
There is no flow because attribute values are not present, or there is incorrect attribute mapping.	Check that your Attribute Flow selection criteria are selecting the correct entries. Possibly the selection criteria are identifying the wrong entries or missing some, or there is a typo and you created the wrong mapping between the source view and the target view. Another reason may be that you are trying to map to an attribute that is the wrong data type for your source data.
There are missing attributes or no flow due to objectclass violations.	Check that your attribute flow is complete and that you haven't missed any attributes. What objectclasses are you trying to flow? Does your attribute flow produce objectclass compliant entries? Does your attribute flow produce LDAP-compliant entries? Do they have objectclasses? Check which attributes are mandatory for that schema, such as cn and sn for inetorgperson. Check the Directory Server error log for clues about problems with objectclass violations.
There is no flow in a given direction.	Check that your attribute flow rule is configured for the correct direction. Each rule has a specific direction associated with it. Open the rule through the interface and make sure that the direction is correct.

Problem	Suggested Action
There is no flow because of corrupted data or objectclass violations.	Are the optional token assignments for your constructed attributes correct for all entries that the rule applies to? Your token assignments are possibly failing for certain entries. Is the selection criteria for your constructed attributes selecting the correct entries? Your selection criteria is possibly identifying the wrong entries or missing some, etc. Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.
There is no flow because of corrupted data, objectclass violations, or missing values.	Check that your attribute construction is based on valid, existing attributes with values. Check that you actually mapped your constructed attribute to something in attribute mapping.

Problem	Suggested Action
There are missing entries.	Are the entries missing in the flow portion of an excluded subtree? If you've set up a subtree filter, any entries in the excluded subtrees won't flow. Turn the log level for data access to 3 (Configuration > join-engine > Log > Verbosity) and resync or refresh. Look at the more detailed logs for clues as to how the rules were evaluated.

Problem	Suggested Action
No data is flowing.	Make sure your view is enabled.
You have experienced unexpected or malfunctioning data flow.	Check that your LDAP-based views are in separate subtrees. Have you or an application directly modified the data in the connector view? Only MDS should be handling the data. Is the subtree of one view a descendant of another? The view subtrees cannot overlap.
No data is flowing.	Have you added the connector view from which you wish to flow as a participating view to the meta view? If the connector view isn't added as a participating view, nothing happens.
You've enabled your view, but no data is flowing and the view keeps getting disabled.	Check DN mapping and attribute flow for corrupt data, then check for faulty join rules.
You have experienced erroneous joining.	Make sure you are not sending data from the connector directly into the meta view.
Your rules aren't being used by the join engine.	Did you apply your rules to the participating view?
Using the MDS console, you were unable to see the contents of a view with many entries.	Did you create a browsing index in the Directory Server console for the suffix of the view with a lot of entries that you are trying to browse? The console can't handle too many entries at once, so it has to rely on the server to give it a Virtual List View, for which you need a special index. See your Directory Server documentation for more information.
No data is flowing, and you see MDS_S_INSUFFICIENT_CAPABILITIES in the join engine logs.	Is your participating view's capabilities set up so that changes/entries can flow in the desired directions?
You have experienced a mapping error and the connector view is constantly being disabled.	Is the root entry of your view flowing? You have to create selection criteria to exclude the objectclass of the root entry, or use a filter.

Problem	Suggested Action
No data is flowing	Is your connector running?
The UTC became corrupted and you couldn't flow data.	Did you interfere with the UTC shutdown? Did you issue kill -9 or otherwise stop it uncleanly? Try refreshing to the connector view.
You made changes that the UTC didn't flow, or you clicked on refresh and nothing happened.	Make sure to wait for the default 15-minute polling interval for the UTC to flow your changes. Everything the UTC does is based on the polling interval, including refresh. Consequently, you'll have to change the 15-minute default if you want results sooner.
You have pre-existing connector view entries that are not flowing to the foreign data source.	Try a UTC filter refresh, or "touch" every entry by making a small modification to it.
Some attributes aren't reaching the connector view from the FDS, or you are experiencing objectclass violations.	Is your UTC attribute mapping complete? Did you miss an attribute? In this direction, any attributes not listed in the attribute mapping are dropped
Some modifications do not flow bi-directionally.	Do you have a UTC attribute flow defined, thereby forcing attribute level flow? You probably have entry level flow and are modifying the non-owner.
Some attributes flow to the FDS that shouldn't be flowing, and they're being rejected.	Do you have a UTC attribute flow defined for the connector view to FDS that doesn't handle the attributes that are being rejected by the FDS? When going from the connector view to FDS, everything flows.
You are experiencing objectclass violations.	Do you have different object types and your default values/attribute mapping isn't taking this into account? If you have multiple object types, you should be careful with the UTC rules. You may want to create this material in Perl script/task.cfg.
The UTC-based connector isn't picking up your configuration changes.	Make sure that you restarted the connector after making the configuration changes (except logging).
Some attributes are being mapped incorrectly, dropped, or mangled.	Is your Perl attribute mapping compatible with your UTC attribute mapping? If you've set up Perl script attribute mapping (like LineFormat in task.cfg), you need to make sure your UTC mapping takes that into account.
Your UTC filters aren't working correctly.	Make sure your UTC filters are expressed in connector view DNs, regardless of the direction.
Your 5.0 UTC won't run your script.	Does your UTC perl script have a package name in it? There should not be a package name in the script

Problem	Suggested Action
The UTP doesn't seem to be working.	Make sure you copied all the required .pm's, template.pl and the .cfg files from NETSITE_ROOT*/bin/utc50/ install/templates/ universalparser. Make sure you renamed one of the .cfg files to task.cfg. Did you forget to set the template.pl script path for the UTC? Does the script path to template.pl specified in the UTC UI appear in an ls or dir listing from the command line?
The UTP isn't working correctly.	The text editor you used to edit task.cfg should not remove trailing white spaces from the end of lines. Did you specify DN as your IndexAttribute in task.cfg? IndexAttribute must be a unique attribute, but not DN.
The UTP isn't working because of objectclass violations.	Make sure you specified your LineFormat correctly in task.cfg. Does the resulting entry conform to inetOrgPerson or whichever objectclass you've specified?
The UTP isn't flowing data.	Is InputFile set correctly in task.cfg? Make sure that template.pl can find the input file.
The UTP isn't flowing changes to the external data source.	Make sure you specified your ImportLineFormat correctly in task.cfg. Is the import function expecting a different format? Is the import utility accessible from template.pl? There may be a path problem or a permissions problem, or perhaps the utility doesn't exist or is not executable.

Problem	Suggested Action
No data is flowing	Is your connector running?
Changes aren't flowing to NT SAM.	Is the machine you specified as NT Domain host write a PDC?
Changes aren't flowing to or from NT SAM.	Check whether logs like ntdc-ntacc-.log and ntdc-perl-.log are in your NTDC instance. If no logs are present, the accessor never started. Check the host and domain names in ntdc.conf.
Writes to NT SAM are failing.	If you are running the NT Domain Connector on a machine other than the PDC, is it running under the Domain Administrator account?
Configuration changes you made to ntdc.conf haven't taken effect.	Did you restart the NT Domain Connector after changing ntdc.conf?
Some pre-existing entries in connector view for the NT Domain Connector aren't flowing to NT SAM.	Make sure you refreshed the meta view.
Entries are not flowing to NT SAM.	Make sure your join engine rules ensure the entry format that the NT Domain Connector is expecting.
Some changes to certain attributes made from the connector/meta view aren't flowing into NT SAM.	Are the attributes you changed on the list of attributes only changeable from NT SAM?
You are unable to modify some entries from the Admin Tool.	Are you flowing user names that are less than 20 characters in length?

Problem	Suggested Action
No data is flowing	Is your connector running?
There are missing OCI errors in the database data server UI.	Make sure you installed OCI.
Changes won't flow to or from Oracle, or your database-based view keeps being disabled.	Did your DBA successfully run the SQL scripts against Oracle?
There are flow problems, or you see DA_E_ALREADY_EXISTS in the join engine logs.	For each table, make sure the columns you chose for nominated keys uniquely identify the row.
Oracle is rejecting your SQL scripts.	Did you replace any placeholders in the SQL instrumentation scripts with DBA-approved values.
Oracle is rejecting the SQL scripts, or the Database Connector is performing strangely.	Did you change anything in the SQL instrumentation scripts that were marked "Don't Change This"?
Oracle is rejecting the SQL scripts due to authentication problems or this error: "ORA-01031: insufficient privileges."	Did you or your DBA run the SQL instrumentation scripts against Oracle as the System Database Administrator User?
Instrumentation scripts fail during the creation of the changetables, or you see this error: "ORA-00957: duplicate column name."	For your data server, make sure you select column names for Action Column and SynchPoint Column that are unique across entire Oracle instance.
SQL scripts fail with "Cannot remove user."	Was the Join Engine trying to synchronize Oracle when you ran the Delete Data Server SQL scripts? This is because the join engine is probably connected to Oracle. Remove all views based on the data server from the meta view's participating views list first, and then wait for the join engine to finish before re-running the SQL commands. As a last resort, stop the join engine.
Oracle flow is failing because of objectclass violations.	Did you make a constructed attribute for Objectclass for your DB-based views?
Oracle flow is malfunctioning because of ALREADY_EXISTS errors and missing entries.	Are your DN mapping rules for DB-based views based on the Primary or Nominated Key(s)? The DN must be based on the Primary Key/Nominated Key when flowing from the meta view to the connector view. This is also recommended when flowing from the connector view to the meta view.
All modify operations on the Oracle connector view fail.	Did you duplicate mappings between DN Mapping and Attribute Flow for the Database Connector? You should not duplicate mappings. If you've mapped EMPNO to employeeNumber in attribute flow and then made your DN mapping rule look like: EMPNO=%mv.employeeNumber% the flow from the meta view to the connector view will be broken.
There is no flow to or from Oracle.	Did you change the structure of any of your instrumented Oracle tables, such as removing a column? If you change the structure of the table, such as deleting an instrumented column, the Database Connector will cease to function. You will need to uninstrument and reinstrument.
There is no flow to or from Oracle, or you notice that the changelog is broken (no changes are being logged), or you see trigger-related error messages in Oracle.	Did you run the same DBC SQL script twice? Ask this if the user tells you no flow to/from Oracle is happening or if they notice that the changelog is broken (no changes are being logged) or if they see trigger-related error messages in Oracle. If you run the same script twice, the triggers cease to function.

Problem	Suggested Action
The message DA_USER_TIMELIMIT_EXCEEDED appeared during the join process.	Is your data server search time-out parameter high enough?
The join engine is sluggish, and there's increased memory usage.	Is your data server poll interval high enough?
You are experiencing poor performance.	Are your join engine and/or console and/or Directory Server all on the same machine?
You are experiencing several "can't connect" errors, or time-outs.	Are all the machines reachable from one another? Ping all of the machines to make sure they can communicate with each other.
You are experiencing poor flow.	Do you see many errors in the Statistics window, or just a sudden stop? Many errors means faulty rules, and a sudden stop means corrupt data.
There is no data flow.	Make sure that both the join engine and connector are running.

Problem	Suggested Action
No data is flowing.	Is your Directory Server running?
The Directory Server times out during large synchronizations.	If you're using Directory Server 4.x, make sure your ioblocktimeout parameter in slapd.conf set to a high enough value (180000000 or higher).
You are experiencing poor performance, especially during large synchronizations.	Make sure your Directory Server is properly tuned for writes.
You are experiencing poor performance, especially during large synchronizations, and errors such as DA_E_UNWILLING_TO_PERFORM, DA_E_USER_TIMELIMIT_EXCEEDED might appear, or other time-out messages might appear.	Did you add the indexes for the linkage attributes (mdslinktocv, etc.)?
The Directory Server disallows the addition of entries because of conflicting UIDs. You will see constraint violation errors.	Did you turn off the UID uniqueness plug-in?
You are experiencing poor performance and have already added the proper indexes for the linkage attributes.	Did you increase the allidsthreshold of the Directory Server?
You are experiencing poor performance and hear disk thrashing on the machine hosting the Directory Server.	Make sure your database cache is big enough to hold all the indexes.
You are experiencing poor performance and hear disk thrashing on the machine hosting the Directory Server, or you see the Directory Server warning at start-up or at the beginning of a database import about your cachesize/dbcachsize being too large for physical memory.	Make sure your Directory Server caches completely fit into physical memory. Do you have a 3:1 ratio of database to entry cache allocation? Are your calculations correct for determining the cache size? Did you factor in 25% memory overhead when computing cache size? Your database cache should not be configured for more than 1.6 gigs.
There are missing entries during the join process and/or time-out errors.	Are your Directory Server front-end settings too low? Check the limit, time-out, and so forth.
You see the following message: ldap_modify: No such attribute: additional info: attribute type is unknown. Cannot delete.	While loading the Meta-Directory schema to a Directory Server instance that does not contain the join engine and meta view configuration information, ldapmodify attempted to delete an entry that does not exist. When ldapmodify applied the Meta-Directory schema, it attempted to delete the attribute type before a new one was added.

Previous Contents Index DocHome Next
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated August 03, 2001

DA_E_INVALID_CREDENTIALS	The user and/or password are set incorrectly.
DA_E_NO_SUCH_OBJECT	The o=NetscapeRoot suffix is not set in the Directory Server, or the entry does not exist.
DA_E_OBJECT_CLASS_VIOLATION	The Meta-Directory schema was not properly loaded into the Directory Server.
MDS_CONTROLLER_UNAVAILABLE	You have not created the 4.x changelog (retro changelog plug-in 5.0), or you have created, configured, and enabled it through instance creation, but have not restarted the Directory Server. Check that the path and suffix/subtree you provided for the changelog is valid.