I'm having a strange problem with an account: when FIM tries to delete it, the AD MA reports the error "The directory service can perform the requested operation only on a leaf object." If I check the account in AD, I see that it has indeed a child object, of type msExchActiveSyncDevice. However, the account used by the AD MA has full control over the users' OU and descendant objects, so it should be able to delete that as well. If I check the permissions on that object explicitly, I see that the AD MA account *has* full control over it, and I see nothing particular about the permissions for this object (e.g. a deny permission somewhere). It's the first time that I see this error, so I would guess that the best approach will be to assume that something has gone bananas with that object, delete it manually and forget about it, but if someone has some insights it would be great... Cheers, Paolo Paolo Tedesco - http://cern.ch/idm

I've come across this a couple of times and it is a pain. Nothing to do with permisisons, it is just that the AD MA won't even try and delete the child objects. You will have to add something to do this before the AD MA runs and does the delete. Maybe: 1. Import the msExchActiveSyncDevice objects into the MV and deprovision/delete them first. Either the AD MA or an ECMA. 2. Delete them directly from AD using a custom activity or provisioning code (not so nice).

it is not a permissions issue. "The directory service can perform the requested operation only on a leaf object." ??> means that the deletion of the object can only occur if the object does not have other child objects In this case the user account DOES HAVE child objects. Because of that the AD MA should issue a TREE DELETE instead of a normal delete. It does not. Different approaches possible: * Delete the child objects out-of band first through FIM portal (have some activity run some script against AD to check for child objects and delete the child objects first as needed) * import the objects into the AD MA CS and join those (somehow) to the MV object of the AD user (making assumptions here) <o:p></o:p> Cheers,<o:p></o:p> (HOPEFULLY THIS INFORMATION HELPS YOU!) Jorge de Almeida Pinto | MVP Identity & Access - Directory Services ------------------------------------------------------------------------------------------------------- * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/ ------------------------------------------------------------------------------------------------------- ################# Jorge's Quest For Knowledge ############### ###### BLOG URL: http://JorgeQuestForKnowledge.wordpress.com/ ##### #### RSS Feed URL: http://jorgequestforknowledge.wordpress.com/feed/ #### -------------------------------------------------------------------------------------------------------<o:p></o:p> "Paolo Tedesco" wrote in message news:be0c6d6f-df45-4770-b45a-e9e2b5fe6486@communitybridge.codeplex.com... I'm having a strange problem with an account: when FIM tries to delete it, the AD MA reports the error "The directory service can perform the requested operation only on a leaf object." If I check the account in AD, I see that it has indeed a child object, of type msExchActiveSyncDevice. However, the account used by the AD MA has full control over the users' OU and descendant objects, so it should be able to delete that as well. If I check the permissions on that object explicitly, I see that the AD MA account *has* full control over it, and I see nothing particular about the permissions for this object (e.g. a deny permission somewhere). It's the first time that I see this error, so I would guess that the best approach will be to assume that something has gone bananas with that object, delete it manually and forget about it, but if someone has some insights it would be great... Cheers, Paolo Paolo Tedesco - http://cern.ch/idm Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

I like Jorge's idea of a custom activity to delete the leaf object prior to AD MA deprovisioning. I've recently been looking at a similar problem as our 3rd-party self-service password reset application records security question data in an object under the user account. At least with ILM (and I'd expect FIM to behave the same way), if you include the class of object that is under the account and import it, you will no longer be able to rename/move the user accounts. It will throw a similar error about leaf objects on a rename now that it knows the user account is not a leaf object based on data in the connector space. (If FIM isn't like that, please let me know!) Since I'm not yet using FIM, I'm looking at possibly adding an separate MA to import information about the SSPR objects to make decisions about whether or not to issue the deprovision, or possible to export deletions of said objects prior to the AD MA deletion export. I haven't gotten too far into the weeds with that because I don't actually have a mandate yet to automate account deletions. I may just leave them disabled for now, tag them with an attribute to make the deletion-pending accounts easy to find with an LDAP query in ADUC, or move them to a "burn bin" OU. Chris

Thank you all for your answers. For the time being, I just deleted the object manually, if the problem happens again I'll think of a proper solution. The custom activity seems the simplest solution (even if it's not particularly elegant). Cheers, PaoloPaolo Tedesco - http://cern.ch/idm