When attempting to modify the Provisioning Directory (ProvStore.xml) to remap the well-known attribute %MANAGER% to a custom field (e.g., eTCustomField95) and using the original displayname="Manager", the import of the modified XML file fails.
Failing Configuration Example:<ImsManagedObjectAttr physicalname="eTCustomField95" description="Manager" displayname="Manager" valuetype="String" wellknown="%MANAGER%" maxlength="128"/>
The import failure generates only a generic error in the server logs:
ERROR [ims.idmmanage] (Thread-XXXXXX) [facility=0 severity=0 reason=0 status=0 message=]
Identity Suite Virtual Appliance 14.5.1 CHF01, v15
The failure is suspected to be an environment-specific conflict caused by a hardcoded internal dependency on the displayname="Manager" value within the Provisioning Role logic.
In a clean, out-of-the-box Identity Manager 14.5 environment, changing the displayname to something else (e.g., displayname="differentthing") allows the import to succeed.
However, in customized customer environments (often with legacy metadata), the attempt to reuse displayname="Manager" causes the import to fail, even for a non-conflicting custom attribute.
The proper, supported method for this mapping should not involve manually editing and importing the ProvStore.xml.Solution / Workaround
The client's use case to synchronize a new custom field with the Manager attribute should be achieved directly through the Identity Manager Management Console and Account Template configuration, avoiding the manual modification of ProvStore.xml.
Follow these steps to configure the mapping:
1. Configure User Attribute Mapping (Advanced Settings):
Navigate to the Identity Manager Management Console.
Go to Home -> Environments -> [your_environment] -> Advanced Settings -> Provisioning.
Configure the User Attribute Mapping to associate the User Store Attribute (e.g., Manager) with the desired Custom Field (e.g., eTCustomField95 or eTCustomField97 as used in testing).
2. Update the Account Template:
Ensure the Account Template within the Provisioning Role configuration is updated.
The template must be configured to send the desired manager value (e.g., Managerid or the appropriate attribute) to the newly mapped Custom Field when an account is created or modified.
This approach successfully circumvents the hardcoded display name conflict that was causing the ProvStore.xml import to fail and was confirmed by the customer to have solved the issue in their production environment.