Hi all, I have a customer who has a requirement to perform some rudimentary logging whilst provisioning out to AD. Simple stuff, username, OU, date and time. If I was starting the connector programatically, I'd just write some stuff in there (can you still use Microsoft.MetadirectoryServices.Logging?), but I've written the provisioning logic as a synchronization rule, so could I still do it in there? It strikes me that it might be better to catch the SUCCESSFUL creation though, so to do it on the import. Just wondered if anyone had any ideas on best approach? What about importing a constant from AD and using that to start a new sync rule that writes out to a text file? Or am I way off the mark? Thanks, Paul.

What is your preference re. the location of the log? And what format should it be in? And how does one view the "report"? If you're using the portal (which it sounds like you are) then you could utilise relationship criteria to create a DRE resource. You could create a search scope and navigation bar resource to render users with AD DS DREs and you could add a new "tab" (grouping) to the user to show the properties to administrators only (have the Synchronisation service write the values to some custom attributes bound to a user and only permit administrators access to these attributes, i.e. don't let users have read access to them).

One place that you can catch the actual values being written to AD is to enable logging on the export run profile. Might not be exactly what you need, but worth checking it out.

I've actually done this to a log file when the client wanted something like that. It was completed by a workflow that waited until the DRE came back (or in my case I used a flag) to then write it to a text file. It isn't that difficult to write it to SQL database as well, if that is what is desired. When doing logging in FIM, I have done it in a variety of ways: 1. As part of the provisioning code for when the entry is actually being provisioned. This works fine although an error during export can cause multiple entries to appear. 2. As part of a rules extension project where a flag attribute is set to "false" when the account is first created by the upstream connector and AD, being authoritative sets it to true when the object is imported into the system. When the value is changed, the log entry is created. If the value is already true, a log entry is not created. 3. As part of a workflow activity when the declarative (SR) rule is assigned that will cause the entry to be provisioned. 4. As part of a workflow activity that waits until the DRE or flag value is set when the entry is imported from Active Directory. That is one of the great things about FIM, you can do things in so many ways depending where on the process you want it to occur. (As an aside, I generally prefer putting the messages into the SQL databases for the users so that they can do queries on them more readily as well as the FIM Service/Synchronization Service can both write to it regardless of whether they are on separate servers or not). Thanks B