Information to have ready before calling Novell Technical Support for Novell Identity Manager or DirXML

  • 7002229
  • 19-Dec-2008
  • 26-Apr-2012

Environment

Novell DirXML 1.1a
Novell Identity Manager 2.0.2+
Novell Identity Manager 3.0.1
Novell Identity Manager 3.5.1
Novell Identity Manager 3.6
ConsoleOne 1.3.6h with DirXML 1.1a plugins
iManager 2.7 with IDM 3.6 plugins

Situation

Information to have ready before calling Novell Technical Support for Novell Identity Manager or DirXML

Additional Information

Before the world ends...

Before you have problems it is a good idea to have some of the following done already to see baseline operation of your environment.  Driver exports are very important to have saved somewhere and traces can show how things worked before a change caused a problem.  If this is an initial implementation previous traces may not be available but after everything is working it is a good idea to have those with a working, proven driver.
Patches

Patches are regularly released for the engine, remote loader, and individual drivers.  These are released to fix bugs or ease implementation and should be applied once they are released.  Patches are available from https://support.novell.com/: Download: Patches: Novell eDirectory: [ProductName].  Instructions for applying patches are included with the patch or from the page where the patch is downloaded from.  The online documentation also discusses various ways of patching components of Novell products and should be utilized to reach those ends.  A ChangeLog is included with patches detailing which specific issues were addressed by the patch and should help you determine if your issue is easily resolved by a patch.  Some issues may be fixed in a patch and not be in the documentation, though, so being on the latest code is still the best policy.

When applying patches it is strongly suggested, as with any software upgrade, that you first implement the patch in a test environment.  Patches should not break configurations but we cannot possibly test every customized situation our drivers make possible and, for that reason, you should test before going live with a patch.  If you can verify that a patch has broken an implementation that worked properly before the patch please report it so we can look into the situation.
Driver Exports

Driver exports allow Novell engineers to see your current driver exactly as it is implemented in your system.  Details of the connection and rules for the driver are all contained within the driver export.  Exporting and importing a driver or driverset requires ConsoleOne or iManager with the appropriate snapins or plugins and is covered in TID# 10075323.
Driver Traces

When capturing a DirXML/IDM trace we must set the trace level (detail level) to at least 3. It may be necessary, at times, to have a trace at level 5 or 6 but that is rare. Getting an initial trace at level 3 should be fine.  TID# 10097185 tells how to configure DirXML or IDM for the correct trace level.
Implementation Details

What should happen and what is the end goal?  Which OS is the engine running on?  Remote Loader?  Patch level of engine, remot loader, and driver?  What changes from the default driver import have been made?  Did it ever work or is it a new implementation?  If in production did it work in the test environment?  Is the driver a flat or mirrored driver?  Uni- or bi-directional?  Is eDirectory or the Application authoritative?  Which attributes should synchronize that are not?  What replica types of which partitions does the engine server's eDirectory contain?  Was the documentation being followed for the implementation and, if so, which step are you on (provide URL)?  Remote Loader or Engine setup?  If it was working what changed in the environment that could have caused it to fail?
What parts, if any, do work?

Isolating sections of the driver that do work aids the troubleshooting process.  The driver has sections that work independent of eachother and, if just one is broken, troubleshooting the rest can be a futile waste of time.  The following are some sample questions that may help isolate what is working and what is not.  Applicable questions will depend on your driver and implementation details.

User synchronization works except for passwords?  Some attributes synchronize but not others?  Some contexts but not others?  Synchronization one way but not another?  Creates but not modifies?  Creating but not matching?
Password Synchronization

Password Synchronization behaves very differently depending on the version you are using.  Password Sync 1 is a separate download from DirXML 1.1a while Password Sync 2 is a part of IDM.  Password Sync 1 is an option for IDM as well as DirXML while Password Sync 2 is only an option for IDM.  Password Sync 2 requires Universal Password synchronizing to Distribution Password in the Identity Vault or other eDirectory trees and takes advantage of those technologies to allow synchronization to various other systems.

Including as many details as possible about your current system and your end goal can help speed up Password Sync troubleshooting.  Details about how users typically change passwords (Active Directory, eDirectory, Password Self-Service Portal, Novell Client (with or without NMAS installed and enabled on the server and client side), custom applications, other connected systems, etc.) could also impact password synchronization and should be included.
What to do with this wealth of information...

Traces and driver exports can be attached to an existing SR before even talking to an engineer through your customer portal.  Answers to questions in the "Implementation Details", "What parts, if any, do work", and "Password Synchronization" sections can be put into a text file and also attached.  Having these ready you can update the SR (again, though the portal) with any additional information or requests you have (response via e-mail or phone, when you are available, miscellaneous information).  Waiting in the IDM queue is fine as well but, if you have done all of the above, you may be able to save time waiting for an informed callback.  The choice is, of course, yours.

Keeping some of this information on hand permanently is not a bad idea.  Driver exports are very useful should the engine server have problems.  Baseline traces are good for showing what should happen.  Documentation about what should happen and what your goal is can satisfy a multitude of business needs and ease your job in the future.
Formerly known as TID# 10098620