Novell Documentation: Identity Manager Drivers - What's Different about This Driver?

1.5 What's Different about This Driver?

The Identity Manager Driver for Avaya PBX is different from some other drivers in the following ways:

Through policies, the driver can map users to phone extensions, rather than users to users.
Some drivers are used for user account administration, mapping user accounts in one system to user accounts in another. The Avaya PBX driver can help you maintain correct phone information for user objects, but the PBX understands only extensions and does not contain the concept of a user account, so the user objects in eDirectory must be connected to extensions in the PBX using the Object ID in the work order. See Section 8.0, Managing Existing Users.
The ObjectID in the work order (such as user object entry ID, or employee ID) is the piece of information that allows a user object to be updated with new phone information after a task is performed in the PBX. This ID needs to be a unique way to identify the user, and a policy must be customized to match the attribute that you use.
The driver places the Object ID in the Cable field of the extension in the PBX. This field has a character limit of 5 characters.

Even if the user has an Identity Manager association for this driver through a policy, in most cases the user cannot be updated unless the ObjectID is entered correctly. In fact, a user object can only be updated if the ObjectID is correct, even if the user does not yet have an Identity Manager association for this driver. See Section 8.0, Managing Existing Users.
The Publisher performs tasks in the Avaya PBX, rather than the Subscriber.
For many drivers, the Subscriber performs changes in the third-party application in response to events in eDirectory. However for this driver, the Publisher is the agent that performs work orders in the PBX. The Subscriber merely picks up events such as Add User events, creates work orders if configured to do so, and sends work orders to the Publisher if they are marked Send to Publisher or DoItNow.

There are several reasons for this design; for example the Publisher has the ability to run at a certain time of day, which is desirable for allowing you to specify that work orders be performed after business hours.
Creating a robust test environment can be a challenge (often the only PBX available in an environment is the production PBX. If this is the case, you can use emulation mode for testing.
One option is to set aside a certain range of extensions on the production PBX to use for testing, and use extra caution because it’s not an entirely separate test environment.
You can manage existing users without using the Migrate into NDS command. See Section 8.0, Managing Existing Users.