| Author | Messages | |
Thomas Vuylsteke
Posts:207
 | | 05/06/2010 8:05 PM |
| * I'm in the progress of setting up GAL Sync and the use of the FIM Portal on FIM 2010 RTM (+updates now) in a lab environment. Technically I understand what's going on, but I'm experiencing some problem.
To start with: I had a more-or-less working setup with a SQL, FIM portal and AD. Users could get added to the SQL, got in the portal and then provisioned to AD. After adding two GAL Sync MA's things started getting messy.
*
* First I had to alter the galsync code to allow the projection of the Sync Rules, the ERE's and DRE's into the MV.
(http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/3b326c28-466a-4beb-a4e5-1386515d19d2)
If I now perform a deletion of a user in my portal, I get a sync error from the GALSync.dll stating "Microsoft.MetadirectoryServices.UnexpectedDataException: Unhandled object type in DetermineMVDeletion called with csentry CS FIM Person e060700c-6e17-4fe5-8e2a-700e393b4d2b and mventry MV person 2cc03765-b4fd-4e5b-8ce4-9176afe64380"
If I check the code, that makes perfectly sense as the GALsync code only checks for "users", "group"," contact", namely the Active Directory object types concerned in GAL Sync. I can easily extend it to also allow "Person" as a known object type to galsync.dll. Or I could try to restrict the GALsync.dll to only do it's magic on the GAL Sync MA's connector spaces. But I'm wondering, the more and more I alter the GALsync code, the bigger the chance I screw up somewhere and have undesired results.
How are you guys coping with this? Do you have a separate FIM Sync service (server) which handles just the GAL Sync part (no interference with FIM Service persons, sync rules, EREs and DREs) and another FIM sync service which does normal provisioning/attribute flowing/fimportal stuff or do you really extend the GALsync.dll code to work together with the FIM service? Anyone who can give some real world feedback?
I also posted this on Technet, but no answers. I guess their more focused to problem-solving questions
The Question on technet: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/04e256fc-6bf3-4cd8-bfc8-9090a49ca54c
Any feedback would be welcome.
Regards,
Thomas
| | | |
| ZJORZ
Posts:363
| | 05/06/2010 8:52 PM |
| I think there is something wrong with either DEPROVISIONING logic in the
Rules Extension DLL and/or the object deletion rule configuration in the
metaverse for the person objecttype
Met vriendelijke groeten / Kind regards,
Jorge de Almeida Pinto
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Thursday, May 06, 2010 21:04
To: activedir@mail.activedir.org
Subject: [ActiveDir] [OT] FIM 2010: GAL Sync MA's versus FIM Service MA, SQL
MA's, ...
. I'm in the progress of setting up GAL Sync and the use of the FIM
Portal on FIM 2010 RTM (+updates now) in a lab environment. Technically I
understand what's going on, but I'm experiencing some problem.
To start with: I had a more-or-less working setup with a SQL, FIM portal and
AD. Users could get added to the SQL, got in the portal and then provisioned
to AD. After adding two GAL Sync MA's things started getting messy.
.
. First I had to alter the galsync code to allow the projection of
the Sync Rules, the ERE's and DRE's into the MV.
(http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/3b326c28-466a-
4beb-a4e5-1386515d19d2)
If I now perform a deletion of a user in my portal, I get a sync error from
the GALSync.dll stating
"Microsoft.MetadirectoryServices.UnexpectedDataException: Unhandled object
type in DetermineMVDeletion called with csentry CS FIM Person
e060700c-6e17-4fe5-8e2a-700e393b4d2b and mventry MV person
2cc03765-b4fd-4e5b-8ce4-9176afe64380"
If I check the code, that makes perfectly sense as the GALsync code only
checks for "users", "group"," contact", namely the Active Directory object
types concerned in GAL Sync. I can easily extend it to also allow "Person"
as a known object type to galsync.dll. Or I could try to restrict the
GALsync.dll to only do it's magic on the GAL Sync MA's connector spaces. But
I'm wondering, the more and more I alter the GALsync code, the bigger the
chance I screw up somewhere and have undesired results.
How are you guys coping with this? Do you have a separate FIM Sync service
(server) which handles just the GAL Sync part (no interference with FIM
Service persons, sync rules, EREs and DREs) and another FIM sync service
which does normal provisioning/attribute flowing/fimportal stuff or do you
really extend the GALsync.dll code to work together with the FIM service?
Anyone who can give some real world feedback?
I also posted this on Technet, but no answers. I guess their more focused to
problem-solving questions
The Question on technet:
<http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/04e256fc-6bf3-
4cd8-bfc8-9090a49ca54c>
http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/04e256fc-6bf3-4
cd8-bfc8-9090a49ca54c
Any feedback would be welcome.
Regards,
Thomas
| | | |
|
|