The following code:

            var values = from rightSideEntity in context.Entities
                         where IncludeEntity(leftSideValues, rightSideEntity)
                         select rightSideEntity;

in MembershipListEntityDistinguishedNameTransformationBase

IncludeEntity method cannot be used this way, as the Entity Repository LINQ expression for function IncludeEntity cannot be transformed into LINQ to SQL.

Fix this issue.

To cut down on the time required to add Move transformations for each field
to ensure that it is LDIF-compliant, it may be useful to give the user the ability to hit a "Make LDIF compliant" button, which would either add a series of Move transformations automatically or add a single LdifComplianceTransformation.

In Identity Broker v3.0.5.6, for the IDB305:Move attributes transformation the use of SourceAttribute and TargetAttribute is in the reverse order (swapped). This caused inconstency with the documentation for <columnMapping>, IDB305:Column mapping configuration and other transformation type such as IDB305:Relational transformation and IDB305:Relational with string priority transformation

Please see -ACGCEO-10- for further details of this issue.

There is a race condition in Identity Broker that can be exhibited by the following:

• Begin a full import against a connected source.
• While full import is occurring, export a new item from the Identity Management platform.
• The full import finishes.
• The change detection takes place and completes.

For some connectors, any export of a new item before the full import finishes will mean that item is not reported in the full import list. This will result in the item being deleted.

For all connectors, if the export of a new item occurs during the change detection phase, it may result in the item being deleted as the item is in the entity repository but not in the list of reported items from the connected source.

For most level 1 compliant connected sources, this will self correct over time, but there may be a window in which the item is in limbo. For level 0 compliant connectors, this will invariably end up with the item being lost, even though it may exist in the connected source.

A common FIM requirement is to be able to provision users based on membership of an AD group. For FIM to be able to do this OOTB would be required that it was possible to define a SET based on the (derived or explicit) ComputedMember collection of a group, but as of a recent FIM build this is now not possible.

In the following thread, Markus Vilcinskas (moderator of the ILM and FIM forums on TechNet) suggests a solution designed to work around this shortcoming: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/a8f5ecea-7375-48da-a920-e4bcea87bba3?prof=required

... and in this thread on the same subject I pointed out that the post marked as an answer to the problem is no longer valid: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/e6661c08-3747-4c99-bb1a-cbba75b89726

At NAB this requirement was satisfied using a custom activity (written by Paul Williams, MVP) prior to UNIFY involvement in the account.

In the end, all of the above mechanisms are really just complicated work-arounds and leave you asking the question ... surely there's a better way?

I am thinking that we could promote the use of the Identity Broker Placeholder Connector to write out both group and user objects with the group.member relationship, and "reflect back" (via a Group.Relation.dn transformation) the "back-link" user.memberOf collection (which confuses everyone when they first see this collection in AD only to find that the memberOf attribute isn't "real" but calculated in AD). The benefit of this approach would be that we could "black box" this solution (it is 100% generic) and it would provide superior performance and simplicity over any of the suggested work-arounds above, especially leveraging the intrinsic delta import capability of Identity Broker which would translate changes to group.member into changes to user.memberOf.

Firstly, can someone confirm that the above configuration will work the way I have described, and secondly (if the assumption is correct) what would it take to package this solution (IdB 3.*, Placeholder Connector, IdB for FIM, pre-generated MA configuration) as a salable commodity to the FIM world?

I am thinking that Peter Wass may have done something like this in the past, but at the time wasn't thinking of how it could apply to this dilemma. Note that this is a special case where the authoritative source of the group.member change is the AD MA. If we had our own Identity Broker for Active Directory MA then we wouldn't need to worry about the Placeholder connector, and could provide this feature OOTB. That might be an even more appealing option, but in the meantime I'm thinking that the only thing stopping the Placeholder Connector option from being a reality is UNIFY buy-in, followed by packaging and marketing ...

The Identity Broker service is currently failing to start, Rev 389, running the 32-bit service:

The error is occurring on an attempt to retrieve the isolated storage file. Of note is that the 64-bit installer attempts this in the OnStart() method of the service, whereas the 32-bit attempts this in the service constructor.

Everything working fine until today. Last major change was on the 25/09/2012 when the WofG->Health connection was introduced.

Today since lunchtime the IdB service keeps crashing.

In the System Event log:

Log Name:      System
Source:        Service Control Manager
Date:          3/10/2012 12:17:12 PM
Event ID:      7034
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      PRDAPP119VS.act.gov.au
Description:
The UNIFY Identity Broker v3.0.6 service service terminated unexpectedly.  It has done this 1 time(s).

In the Application Event log at the same time:

Log Name:      Application
Source:        Microsoft-Windows-MSDTC Client 2
Date:          3/10/2012 12:17:12 PM
Event ID:      4879
Task Category: CM
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      PRDAPP119VS.act.gov.au
Description:
MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system PRDAPP119VS.

The server it is failing to establish a secure connection with is in fact itself.

There have been no further MSDTC errors but IdB no longer works. I can start the service but as soon as I try to run an Import from the WofG FIM server IdB on the Health server crashes immediately with the same error in the System event log.

Restarting the DTC service does not help.

As part of IDB-125, the GeneralizedTime format is successfully generated by the compliant LDIF adapter for DateValue and TimestampValue types. The .NET DateTime conversion does not recognize this format, and fails to convert the value to the respective value type when reading LDIF back in. These validators must be updated to support this format.

Adapter request to retrieve DN generation configuration adapter space.
Adapter request to retrieve DN generation configuration from adapter space 27e24050-eb57-4f35-a725-30509f996262.

Is continuously being logged to the IDB logs.

This will probably be the result of the LoggingLevel being to high.

During an export of 3000 users to Identity Broker, the following error appeared 4 times in the Event log. This can be seen on Test1 14/12/11 4:28:04pm, 4:31:59pm, 4:37:15pm, 4:43:14pm