The current Vibe model for provisioning users from an organizational data store is to query a neutral LDAP source (Active Directory or eDirectory) and to synchronize this information with the SQL data store that Vibe uses.

Because Filr and the iPrint appliance (and perhaps others) are derived from the Vibe codebase, they use this same process. Changes to the derived products are usually incorporated into Vibe as well.

Our organization has had a terrible experience with this module over numerous versions and numerous years. We have opened multiple SRs against it. Amongst the issues encountered:

1. The code originally did not store GUID, and then when it required it no reconciliation was made between old and new entries.
2. The data model does not allow for context, so multiple users and groups with the same name cannot be held or distinguished (this is one of the advantages of eDirectory)
3. The process times out too easily against large user sets.
4. The codebase did not allow for paging, which is required for large AD installations, then it *required* it, which breaks large eDirectory installations. We were the original discoverers of both these bugs!
5. The process is very sequential, and therefore slow. It is not ideal for running daily.
6. It is very easy to make non-recoverable changes to Vibe users based on trying to handle inactive users intelligently.
7. As others have noted elsewhere, it does not work with more sophisticated means of user management such as IDM.

In a perfect world Vibe and its compatriots would follow the ZENworks model and query LDAP directory, holding only the user information specific to Vibe.

What I would like to see is either this model adopted, or a much more sophisticated (i.e. knowledgable about X.500 Directories) and "bulletproof" revision to the existing model.

by: Johnnie O. | over a year ago | Administration