A Forum reader recently asked:
“How would I upgrade individual driver configurations to the new architecture outlined in section 2 of “Understanding Policies for Identity Manager 3.5.1″? We have done some driver customization in various policies, but we used the existing default names.
If we overlay the policy configuration files to exploit the new architecture, is that where the potential risk arises?”
And here is the response from Aaron Burgemeister …
Regarding the transition from IDM 3.0.x to 3.5.x …
3.0.x uses linkages between policies (linked list-ish). 3.5.x uses a multi-valued attribute on the driver itself, which points to all of the policies. The IDM 3.5.x engine will work with the 3.0.x style; each time you go into the driver it alerts you that you should convert.
The “risk” is negligible (I’ve really never seen this break myself during the conversion) because the policies themselves are not really touched. Only the linkages to the policies are modified, which doesn’t involve
looking at your rule names or logic.
Here’s a rough overview of how it works:
~ Output Transform Stuff -> OutTransPolicy0 -> OutTransPolicy1
~ Creation Stuff -> MatchPolicy0 -> MatchPolicy1
~ Matching Stuff -> MatchPolicy0 -> MatchPolicy1
~ Output Transform Stuff
~ Creation Stuff
~ Matching Stuff
The contents in the policies and their respective rules don’t matter – only how the driver points to the policies is changed. Just have an export beforehand and you’ll be fine. This is really simple to convert, so there haven’t been any issues that I know of.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.