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

As discussed on PRODUCT-64, the Employee and Schedule connectors should be expanded to support all possible attributes.

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

With the ECMAs for FIM that I've written myself, one of the most useful features I was able to easily implement was the ability to set an ECMA parameter that would allow me to reprocess the last full import (LDIF in this case) file generated by either the ECMA full or delta import. I know that when FIM R2 comes this appears to change the paradigm, but nonetheless with the time that it takes me to construct a full import file before I can test my FIM solution in a lab, the ability to replay import files this way would be very handy. An added spin-off for this was to be able to replay production-generated LDIF files in a lab environment for analysis - something that proved crucial for me @ CSODBB in both troubleshooting and testing.

Adding field to connector schema cached in IE6, as same field attempted to add on different requests for IE6; whereas in chrome this could be added fine.

Create an Adapter for Adv_Worx_Person successfully with now additional transformation, Run "Generate Change Token" and there are 290 Pending Changes but 0 Processed Entity Count.
Check the log files and found the following error:

Request to reflect change entities of the adapter.
Request to reflect change entities of the Adv_Worx_Person (7fb73121-2311-4dfd-ad8f-ef1512ffc9fb) adapter errored with message: Byte array contains invalid string characters.. Duration: 00:00:00.2812421
Error details:
System.Exception: Byte array contains invalid string characters.
 at Unify.Product.IdentityBroker.Asn1OctetStringBase.StringValue()
 at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
 at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
 at Unify.Product.IdentityBroker.LDAPChangeAdd.Format()
 at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
 at System.String.Join(String separator, IEnumerable`1 values)
 at Unify.Product.IdentityBroker.ChangeReportToChangeLogAdapter.<HandleAdds>d__2f.MoveNext()
 at Unify.Product.IdentityBroker.ChangeReportToChangeLogAdapter.<Transform>d__0.MoveNext()
 at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
 at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
 at Unify.Product.IdentityBroker.Adapter.ReflectChanges()
 at Unify.Product.IdentityBroker.AdapterNotifierDecorator.ReflectChanges()
 at Unify.Product.IdentityBroker.ReflectAdapterOnChangeDueJob.<RunBase>b__0(IOperationalAdapter adapter)