Provision Fails after join with failed-creation-via-web-services
Hi.
Contractors setup FIM but have left us with an issue which they claim cannot be resolved.
1. A user is created in AD
2. On the first Portal Export a join occurs (presumably this is a returning student and already exists in the Portal)
3. On the next Portal Export an error occurs "
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><AttributeRepresentationFailure><AttributeType>ObjectSID</AttributeType><AttributeValue></AttributeValue><FailureMessage>Exception:
ValueViolatesUniqueness
Stack Trace:
Why does it still try to provision even though there is an existing join? How do I stop this from occurring?
MM
February 3rd, 2015 7:29pm
You are not getting a join, most likely. The process of conversions is not that simple. It will not happen unless you do something about it. If this is a returning student, as you suspect, then it is a new user for all intents and purposes.
Does the old account have an ObjectSID in portal?? if yes, your new account has been joined to AD, but not to portal, and it has the same SID. You need to remove the old account in Portal, delete it manually.
February 4th, 2015 12:35pm
Thanks, is there a way of locating those objects in the Portal that aren't in AD. Perhaps if I was to remove all the orphans first the errors would stop.
February 4th, 2015 5:24pm
Except for looking at the errors and open the properties and find the duplicate, I dont think there is an easy way. Thats short term. Long term you need a process for preventing these from happening in the future.
February 4th, 2015 5:28pm
Thanks for your help thus far.
Originally I was told to delete the connector for provisioning and leave the join rule but there are so many and it takes ages to do that via the Service Manager.
So per your comments I deleted the Portal object for one user instead. This worked as it provisioned the user and I now have an Applied Expected rule entry in the Portal whereas I didn't before.
Now I just need to find an easier way to delete Portal object as I have over 900 to do.
February 5th, 2015 8:23pm
To automate this, it is a delicate task so I would not advise you to do anything unless you are absolutely sure you got it right. Basically, if you can identify these users, which I doubt you can, you can add them to a set and then create an MPR to delete
them. If this is not possible, then manualy deleting them may be your only choice. There is a third option, but I need to know mote about your portal configuration. Basically if there are no customizations, workflows, group management or sspr used in portal;
in other words if you are not doing anything in portal, you can delete all portal users, run delta inport and delta sync on FIM MA and all uses will be recreated. Be sure not to delete built in and admin accounts, otherwise there is no way back. There is a
powershell script somewhere in technet do do this. I can send it to you if you need it. The real sution, of course, is to finalize a process for conversions. This will keep happening again
February 5th, 2015 8:44pm
We are using Password Self Service via the Portal so we can't delete them all unfortunately. Looks like I might be busy for the next 24hrs. :-(
February 5th, 2015 8:49pm
Large coffee and lots of patience. Good luck!
February 5th, 2015 8:50pm
The contractor had setup a single step.
1.
Single step vs. multistep
A run profile with a single step of "Delta Import and Delta Synchronization" will not process disconnector objects that
already exist in a connector space.
When you configure a run profile with a
single step of the type "Delta Import and Delta Synchronization", a condition can occur in which existing disconnector objects from a previous run are not processed. This condition occurs because the existing objects in the
connector space that have not changed since the last run are ignored. For example, objects that have changed in a connected data source are imported to a connector space, rules determine that the object is not joined or projected to a metaverse object, and
the object becomes a disconnector object. Subsequent runs with a single run profile step of type "Delta Import and Delta Synchronization" ignore the object because it has not changed, and the disconnector object will remain in the connector
space. To prevent a buildup of disconnector objects in the connector space, run a run profile with a single step of the type "Delta Synchronization". The connector objects with pending changes and the normal disconnector objects that already
exist in the connector space are then processed (according to rules).
- Delta Import and Delta Synchronization
The delta import and delta synchronization run profile step type combines a delta import and a delta synchronization into one single step type.
This run profile step type imports only those objects and attributes from the connected data source whose values have changed since the last time the management agent was run. During the following delta synchronization
step, only the objects that have pending changes from the delta import are processed.
-
Marked as answer by
iampuzzled2
7 hours 58 minutes ago
May 28th, 2015 7:29pm
The contractor had setup a single step.
1.
Single step vs. multistep
A run profile with a single step of "Delta Import and Delta Synchronization" will not process disconnector objects that
already exist in a connector space.
When you configure a run profile with a
single step of the type "Delta Import and Delta Synchronization", a condition can occur in which existing disconnector objects from a previous run are not processed. This condition occurs because the existing objects in the
connector space that have not changed since the last run are ignored. For example, objects that have changed in a connected data source are imported to a connector space, rules determine that the object is not joined or projected to a metaverse object, and
the object becomes a disconnector object. Subsequent runs with a single run profile step of type "Delta Import and Delta Synchronization" ignore the object because it has not changed, and the disconnector object will remain in the connector
space. To prevent a buildup of disconnector objects in the connector space, run a run profile with a single step of the type "Delta Synchronization". The connector objects with pending changes and the normal disconnector objects that already
exist in the connector space are then processed (according to rules).
- Delta Import and Delta Synchronization
The delta import and delta synchronization run profile step type combines a delta import and a delta synchronization into one single step type.
This run profile step type imports only those objects and attributes from the connected data source whose values have changed since the last time the management agent was run. During the following delta synchronization
step, only the objects that have pending changes from the delta import are processed.
-
Marked as answer by
iampuzzled2
Thursday, May 28, 2015 11:27 PM
May 28th, 2015 11:26pm