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

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.

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.

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.

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.

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

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. :-(

Large coffee and lots of patience. Good luck!

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).

 

1. 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

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).

 

1. 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