I was encountering this error in a FIM Workflow with an If-Else statement that was using a Declarative Rule Condition where the declarative rule condition name was the “condition name”.

The fix was to add something like the following in the code behind:

private void ccManagerEmailFound(object sender, ConditionalEventArgs e)

{

e.Result = bManagerEmailFound;

}

Then, change the If-Else to a Code Condition and select the new code condition just added.

Oracle and I are new acquaintances and I had a few problems getting the WSDL to generate from the Integration Repository. Here are the steps I took that (I think ) eventually got me past the “SOAProvider Access resulted in exception server returned HTTP response code 500 for URL” error.

1. Reset the ASADMIN user password from the console.

2. Updated the system-jazn-data.xml file with the new password (pre-pended with !).

3. Restarted the Oracle Process Manager service from “Services”.

4. Granted “All Users” permission on the “User Account” procedure.

5. Selected the “User Account” procedure and clicked “Generate WSDL”. It took a few minutes to run.

6. Clicked “Deploy”.

Ran into a case where SharePoint was remembering the client credentials–even though we’d never selected a “remember” box. The credentials were being remembered even after the browser had had all instances shut down.

This turned out to be a browser issue in my case. The domain *.domain.com was listed as a Trusted Site (Tools–>Internet Options–>Security–>Trusted Sites).

I was receiving the error at the end of this post when running the ETL script for FIM Reporting.

SCSM was reporting that the Load.Common module was failing. When I opened the job, the LoadDWDataMartFIMAttributeTypeDim module was in the failed state.

I have no idea what caused it but the (most likely unsupported) fix was to back up the DWDataMart and DWRepository databases. Then, I truncated the dbo.FIMAttributeTypeDim tables in both databases. (I also truncated the dbo.FIMAttributeTypeDim_bulkstg table in the DWDataMart db, but that might not have been necessary.)

I ran the ETL script again and didn’t get an error.

Event Viewer error:

ETL Module Execution failed:

ETL process type: Load

Batch ID: 15444

Module name: LoadDWDataMartFIMAttributeTypeDim

Message: Cannot insert duplicate key row in object ‘dbo.FIMAttributeTypeDim’ with unique index ‘IX_FIMAttributeTypeDim_FIMAttributeTypeName’.

The statement has been terminated.

Stack:    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)

at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)

at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)

at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)

Our client would like users to be forced to re-register for their password reset questions when they have had their password reset from the portal.

I already had a custom workflow to reset the user’s password, but that was just reading single valued attributes. Reading the multi-valued “UniqueIdentifier” attribtue was a new one to me.

Here’s the code to read the attribute:

List<Microsoft.ResourceManagement.WebServices.UniqueIdentifier> listAuthNWFRegistered = newList<Microsoft.ResourceManagement.WebServices.UniqueIdentifier>();

listAuthNWFRegistered = resource2["AuthNWFRegistered"] as List<Microsoft.ResourceManagement.WebServices.UniqueIdentifier>;

foreach (Microsoft.ResourceManagement.WebServices.UniqueIdentifier val in listAuthNWFRegistered)

{

sAuthNWFRegisteredGuid = val.ToString().Replace(“urn:uuid:”, “”);

}

And  then, to remove the attribute, the UpdateRequestParameter is this:

new UpdateRequestParameter(“AuthNWFRegistered”, UpdateMode.Remove, sAuthNWFRegisteredGuid)

I recently had a requirement to make security group members be members of a set in FIM. This is not as easy as it sounded. Our requirements were:

- Users should only be able to assign roles to other users that they themselves have.

- Roles translate to security group membership in AD based on criteria-based security groups.

We decided to change the thought process a bit and realized we were only using roles to create security groups. So, why not take roles out all together. The end result works something like this:

1. A new Reference multivalued attribute is on the user called SecurityGroups.
2. This attribute contains the groups the user belongs to.
3. A new Set of Users is created for each security group.
a. The set is a criteria based set where the SecurityGroup attribute of the user contains the security group.
4. A new Set of Groups is created for each security group.
a. This is a criteria based set where the display name is the name of the group.
5. A new MPR is created for each set of users created in step 3 to grant them permission to write to the SecurityGroup attribute on all users.
6. A new MPR is created for each set of groups created in step 4 to grant the set of users created in step 3 read permissions on the set of groups created in step 4.

It needs some workflow automation probably to be feasible, but in theory this allows us to have sets based on group membership.

The PES service needs to be installed on the source domain.

However, it relies on keys generated on the target domain.

So, on the machine running ADMT, execute this command to create the keys:

admt key /option:create /sourcedomain:domain.com /keyfile: peskeys /keypassword: password1

Move the resulting key file to the DC in the source domain.

Download PES from http://www.microsoft.com/en-us/download/details.aspx?id=113070 (x86 version)
or http://www.microsoft.com/en-us/download/details.aspx?id=1838 (x64 version)

Double click the exe file to start the installation. You will need to provide the path for the key file. You will also need to provide a service account. Although you can use the Local System account, if you run it as a domain user from the target domain you can avoid having to add the Everyone group and Anonymous Logon group to the Pre-Windows 2000 Compatible Access group.