Unable to evaluate condition “condition name” as there are validation errors

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 Generate WSDL returns error 500

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

 

SharePoint Not Prompting For Credentials

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

Removed that, deleted the saved passwords (Tools–>Internet Options–>Browsing History–>Delete–>Passwords) and closed all instances of IE.
Then, opened IE and was prompted for the login. Gave it. Closed IE and opened it again and was prompted for the login.
As an aside, before we figured this out, I also had to add some JavaScript to the master page to force the user to log out after a certain amount of time. Found this solution here:http://sharepoint.stackexchange.com/questions/29261/how-to-log-off-user-from-sharepoint-site-if-the-user-has-been-inactive-for-20-m

<scripttype=”text/javascript”>

function Timeout() {

var t = setTimeout(“RedirectToLogout()”, 20 * 60000);

}

function RedirectToLogout() {

    var path = “~/_layouts/SignOut.aspx”;

window.navigate(path);

}

Timeout();

</script>

ETL Module Execution failed: FIMAttributeTypeDIM

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)

Reading and removing a multivalued attribute in a FIM workflow

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” attribute 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)

FIM: Using group members as set members

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.

Installing Password Export Service

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.

Enable Account Change Auditing for migrating sidHistory in AD 2008

1. Open Group Policy Management from Administrative Tools.
2. Expand the tree until you find the domain you are using.
3. Expand the domain tree. (You may have to right click and select “Show domains” to see your domain.)
4. Select “Group Policy Objects”
5. Select “Default Domain Controllers Policy” and choose “Edit”.
6. In the new window that opens, navigate to: Computer Configuration–>Windows Settings–>Security Settings–>Local Policies
7. Select “Audit Account Management” and be sure both “Success” and “Failure” are selected for auditing.

You will have to reboot or wait about 15 minutes for the change to take effect.

One does not simply write to sidHistory

During the process of development, we discovered the following requirements for the writing to sidHistory to work.
– The process must run on the destination domain. Although the documentation for clonepr.dll says it must be run from the PDC, we did a test and ran it on a DC that can update sidHistory on other DCs. If running it on a DC, sidHistory is only set on that DC and AD replication should move the sidHistory.

– The process must be run from the same PDC that is referenced in the destination DC of the config file. Otherwise, an “Access is denied” error is returned.

– The process must reference the PDC of the source domain. Otherwise, an error will be reported that “The operation is only allowed for the Primary Domain Controller of the domain.”

– The account running the process must also have a foreign security principal in the source domain.

– The account must be an Administrator on the source domain.

– The account must have read write access to the sidHistory attribute destination domain. (A security group can be created to grant the account this right. In our environment, the account was also an ADMA account.)

– The account must have the “Delegate Control”->”Migrate SID” permission.

– The account change auditing needs to be enabled on both servers. (The document clonepr.doc has instructions on how to accomplish this.)

– The source domain needs a domain local security group called “DomainName” + “$$$”. No members need to be added to this group, but the process does add members to this group while it is migrating the SID and then removes the members from the group.

– The service account needs full control over the OU holding the objects that are having their sidHistory attribute populated.

In a FIM sync, without these settings, I was receiving a “permission-denied” error. These settings were for a separate program to migrate sidHistory.

FIM 2010 R2 Installation failure on SQL Step

I’m troubleshooting the error on FIM installation:

“Forefront Identity Manager Synchronization Service is having trouble contacting SQL server using the provided information. Please note that Forefront Identity Manager Synchronization Service requires Microsoft SQL Server 2008 SP1 or better. Verify the version, server and instance names as well as firewall settings and try again.”

The SQL Server is in a different domain and a different forest. There is a two-way trust. (I know one way trusts where SQL doesn’t trust the domain FIM is in don’t work.)

Since I’ve seen this error in the past, I thought I’d write out the steps I’m taking to troubleshoot:

1. Verify an ODBC connection can be made from FIM to SQL.
2. Verify Firewall rules.
3. Enable verbose logging on the installation: msiexec /i [File location] /lv*x [Log file location–file must already exist] (http://msdn.microsoft.com/en-us/library/windows/desktop/aa367988(v=vs.85).aspx) Search for return value 3 to find the error.
4. Disable IESC for Administrators.
5. Verify Full Text Search is installed on SQL.
6. If using a non-default SQL instance, verify the SQL Browser is running.
7. Verify SQL Agent is running.
8. Verify the SQL Native Client is installed on FIM.

In this case, the SQL Native Client was the issue.