Sun logo      Previous      Contents      Index      Next     

Sun ONE Meta-Directory 5.1.1 Administration Guide

Appendix B  
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

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.

Note

To optimize the Join Engine for better performance, it is recommended to index this attribute.

For example: For deleted entries in the external data source, the Join Engine would search the Connector View to locate the entry that was linked to the deleted entry; by searching MDSLinktoCV with MV#ORacleCV#<UserDN_in_oracle>. This could result in poor performance of the Join Engine.

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

Note

To optimize the Join Engine for better performance, it is recommended to index this attribute.

For example: For deleted entries in the external data source, the Join Engine would search the Meta View to locate the entry that was linked to the deleted entry; by searching MDSLinktoCV with MV#ORacleCV#<UserDN_in_oracle>. This could result in poor performance of the Join Engine.

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 13, "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:

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:

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:

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 13, "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.x. 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.

  1. Open the Directory Server through the Console.
  2. Click on the Configuration tab.
  3. Click on the topology tree at Plug-ins.
  4. Scroll down to “uid uniqueness” and click to open.
  5. Uncheck the Enable plug-in box.
  6. 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.x), 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.

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

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

Table B-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 retro-changelog plug-in.

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.x changelog through the Directory Server console.

If you are using Directory Server 5.x 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 Meta-Directory.

Table B-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.

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 B-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 B-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 > Jjoin 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 B-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 B-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 B-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 B-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 B-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.0SP1 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 B-10  Problems with the Universal Text Parser 

Problem

Suggested Action

The UTP does not 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 is not 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 B-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 B-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.

Check whether the changelog database is running out of space. If so, ask your DBA to allocate more space for the changelog database. Also update the Flush Interval (DataServer - Oracle Changelog tab from within Sun ONE Meta-Directory console) in such a way to flush changelog database more frequently.

Table B-13  Problems with the Novell Directory Connector 

Problem

Suggested Action

You get an error (related to the creation of intermediate changelog database in MySQL database server) during instance creation.

Check if the value entered for MySQL Server Hostname is correct. Also check if it is possible to connect to MySQL server using the values entered for “MySQL DBA User” and “MySQL DBA Password”, from the host on which the Meta-Directory Console is running.

You find that no data is flowing immediately after creation of connector instance.

Is your connector running? Please start the connector instance manually since it is not started automatically after a successful instance creation.

You find that the connector shuts down immediately after you start it.

Set the log-level to “Debug” and restart the connector. This time the log file would point you to the cause of shutdown when the connector shuts down.

You find that the changes made in either of the trees in Novell Directory Server or the Connector View in Sun ONE Directory Server didn't flow/get-synchronized.

The default schedule set on the creation of a connector's instance is set to 15 minutes. Please change the default value for schedule to a value that is appropriate to your deployment needs.

You observe that some entries are not flowing because of objectclass violations.

Is the “Attribute Flow” configuration specifying the attribute mappings complete? Did you miss any attribute that is marked as required/mandatory at the destination-end? Object class violations occur when all the required attributes are not mapped in the “Attribute Flow” configuration. Also make sure that the “Attribute Flow” configuration has mappings specified for the appropriate synchronization directions.

You find that the connector instance is not picking up your configuration changes.

Make sure that you restarted the connector instance after making the configuration changes. All configuration items other than those related to Logging are “static” and hence need a connector instance's restart for the configuration changes to be effective.

You observe that write-operations to Novell or Sun ONE Directory Server are failing.

Check if the user (“ExternalLoginDN” or “DirectoryLoginDN”) has appropriate LDAP write access.

You find that the connector does not start up after an error.

Increase the log-level for the connector instance to “Debug” and save it. Look at the status of the WINDOWS service for the connector instance. If it still showing the status as “Started”, stop it manually and then restart the connector instance via the Meta-Directory Console.

You are trying to start the connector service on Windows, from the service-panel and it does not start successfully.

You can never start a connector from service panel without manually generating the start.conf file used by the connector service.

You delete the user objects in Novell Directory Server (that are owned by Connector View) that are already marked as members of a group object. This deletes the appropriate user-names from the members' list of the group object in Novell Directory Server. You expect that the ownership rule would add-back the users to Novell Directory Server and also update the members' list of the group object back to the old value(s). But you observe that the users get added-back the members' list remains in the changed state.

This behavior is due to the fact that Novell Directory Server updates the members' list dynamically based on the deletion of its member-user objects. So, the observed behavior is the expected behavior. You would need to add those members again to the group object in Novell Directory Server manually.

You face problems with synchronizing entries (end-to-end) between Novell Directory Server and Meta View.    

While configuring the “Object Class Flow Rule”, the value of the “Directory Naming Attribute” should be carefully selected based on the manner in which the DN of the entries in the Connector View get constructed. If the Connector View is configured with respect to the Join-Engine, then the contents of the DN rule(s) drive the selection of this “Directory Naming Attribute” for the flow between Novell Directory Server and the Connector View (in Sun ONE Directory Server). i.e. If the Meta View to CV DN rule designates “cn” as the “Naming Attribute for Connector View entries”, then “cn” (and not “uid”) should be the value entered for “Directory Naming Attribute” when the “Object Class Mappings” are created. Hence, when data is flowed end-to-end between the Novell Directory Server and the Meta View, a typical mapping for flowing user-entries between the Novell Directory Server and the Connector View would look like “inetorgperson#cn <-> inetorgperson#cn” (instead of the default “inetorgperson#cn <-> inetorgperson#uid”).

You find that the ‘uniqueMember’ attribute for group entries does not flow from the Connector View to DIT in Novell Directory Server 8.7.

The default attribute mapping (NDS attribute Vs LDAP attribute) for the NDS attribute ‘Member’ in the ‘LDAP Group Object’ in Novell Directory Server is incorrect.

Hence, modify (using ConsoleOne or ldapmodify) the attribute mapping (NDS attribute Vs LDAP attribute) for the NDS attribute ‘Member’ in the ‘LDAP Group Object’ in Novell Directory Server, by specifying ‘uniqueMember’ as the ‘Primary LDAP Attribute’ and ‘member’ as the ‘Secondary LDAP Atttribute’. This mapping would then be inline with the one in version 8.6.2.

Restart the Novell Directory Server. This schema change would allow the ‘uniqueMember’ attribute for group entries also to flow from the Connector View to DIT in NDS 8.7 (as in the case of version 8.6.2) once the connector instance is also restarted.

Table B-14  Problems with the Lotus Notes Connector 

Problem

Suggested Action

You get an error (related to the creation of intermediate changelog database in MySQL database server) during instance creation.

Check if the value entered for MySQL Server Hostname is correct. Also check if it is possible to connect to MySQL server using the values entered for “MySQL DBA User” and “MySQL DBA Password”, from the host on which the Meta-Directory Console is running.

You find that no data is flowing immediately after creation of connector instance.

Is your connector running? Please start the connector instance manually since it is not started automatically after a successful instance creation.

You find that the connector shuts down immediately after you start it.

Set the log-level to “Debug” and restart the connector. This time the log file would point you to the cause of shutdown when the connector shuts down.

You find that the changes made in either of the Lotus Notes Server or the Connector View in Sun ONE Directory Server did not flow/get-synchronized.

The default schedule set on the creation of a connector's instance is set to 15 minutes. Please change the default value for schedule to a value that is appropriate to your deployment needs.

You observe that some entries are not flowing because of objectclass violations.

Is the “Attribute Flow” configuration specifying the attribute mappings complete? Did you miss any attribute that is marked as required/mandatory at the destination-end? Object class violations occur when all the required attributes are not mapped in the “Attribute Flow” configuration. Also make sure that the “Attribute Flow” configuration has mappings specified for the appropriate synchronization directions.

You find that the connector instance is not picking up your configuration changes.

Make sure that you restarted the connector instance after making the configuration changes. All configuration items other than those related to Logging are “static” and hence need a connector instance's restart for the configuration changes to be effective.

You observe that write-operations to Lotus Notes or Sun ONE Directory Server are failing.

Check if the user (“ExternalLoginDN” or “DirectoryLoginDN”) has appropriate LDAP write access.

You find that the connector does not start up after an error.

Increase the log-level for the connector instance to “Debug” and save it. Look at the status of the WINDOWS service for the connector instance. If it still showing the status as “Started”, stop it manually and then restart the connector instance via the Meta-Directory Console.

You observe that some entries are not flowing because of objectclass violations.

Is the “Attribute Flow” configuration specifying the attribute mappings complete? Did you miss any attribute that is marked as required/mandatory at the destination-end? Object class violations occur when all the required attributes are not mapped in the “Attribute Flow” configuration. Also make sure that the “Attribute Flow” configuration has mappings specified for the appropriate synchronization directions.

You find that the connector instance is not picking up your configuration changes.

Make sure that you restarted the connector instance after making the configuration changes. All configuration items other than those related to Logging are “static” and hence need a connector instance's restart for the configuration changes to be effective.

You are trying to start the connector service on Windows, from the service-panel and it does not start successfully.

You can never start a connector from service panel without manually generating the start.conf file used by the connector service.

You face problems with synchronizing entries (end-to-end) between Lotus Notes Server and Meta View.

While configuring the “Object Class Flow Rule”, the value of the “Directory Naming Attribute” should be carefully selected based on the manner in which the DN of the entries in the Connector View get constructed. If the Connector View is configured with respect to the Join-Engine, then the contents of the DN rule(s) drive the selection of this “Directory Naming Attribute” for the flow between Lotus Notes Server and the Connector View (in Sun ONE Directory Server). i.e. If the Meta View to CV DN rule designates “cn” as the “Naming Attribute for Connector View entries”, then “cn” (and not “uid”) should be the value entered for “Directory Naming Attribute” when the “Object Class Mappings” are created. Hence, when data is flowed end-to-end between the Lotus Notes Server and the Meta View, a typical mapping for flowing user-entries between the Lotus Notes Server and the Connector View would look like “dominoperson#cn <-> inetorgperson#cn” (instead of the default “dominoperson#cn <-> inetorgperson#uid”).

You find “Javaserver.exe - Unable to Locate DLL” error when the connector is started.

Make sure PATH environment variable has notes client install location. If not, add notes client install location to global PATH environment variable. For example, if lotus notes client is installed in c:\lotus\notes directory, add c:\lotus\notes to the PATH environment variable.”

Meta-Directory

Lists general troubleshooting tips for the Sun ONE Meta-Directory software

Table B-15  Problems with 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.

Performance issues related with ‘libthread’ on Solaris 2.8

Use Solaris 2.9 libthread instead of the standard libthread available with Solaris 2.8.

To perform this, do the following:

1.  Create a special configuration file for the dynamic libraries loader using the’crle’ command-line tool:
crle -c /var/ld/ld.meta -a /usr/lib/libthread.so.1 -o /usr/lib/lwp

2.  In the start.pl script file, used to start the Join Engine (from the bin/join50/admin/bin directory), add an environment variable after the NETSITE_ROOT variable, called LD_CONFIG
$ENV{LD_CONFIG}=’/var/ld/ld.meta’;
This variable is used to indicate that the processes started from this shell should use an alternate configuration file for loading the dynamic libraries (the configuration file defined in step 1).

3.  Start the Join Engine and verify it is running with the Solaris 9 library (with ‘pldd’).

Directory Server

lists general troubleshooting tips for Directory Server.

Table B-16  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.



Previous      Contents      Index      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.