As I have said previously, the HR data that feeds FIM is out of my direct control and has had some data quality issues.
As a result, I have ended up putting some consistency checking into my code. I’ll present a few from my MVExtension here, what I’m tending to be looking for is where the user has already been provisioned, but then the reference has been deleted in HR, but no-one has told me so that I can tidy up the account in AD and FIM.
The ID’s that showed up after putting in the bit looking for FIM only references, was caused by disconnecting a table that validates historical end dates. I was assured that I would not need it anymore, because the end dates would not be randomly set to a period in the past that mean that I would never receive that update… However, this did not pan out, so I re-attached the table, but did not reset the MV object deletion rule afterwards, so I ended up with ID fragments in the portal – referenced only by ObjectID.
Again I used the Lithnet PowerShell module to clear these up. There were around 40 to do, so I just got the ObjectID’s from the job xml, put them in a text file and ran this:
ForEach ($DN in $DNs)
$a=Get-Resource -ObjectType Person -AttributeName ObjectID -AttributeValue "$DN" | Remove-Resource
If MyADADMAConnectors = 0 And HRMAConnectors > 0 Then
'This bit applies to ID's that are coming from HR - New users - a user should be provisioned here....
'what would follow is the code to created the various attributes needed for that new user...
If MyADADMAConnectors = 0 And HRMAConnectors = 0 And FIMMAConnectors > 0 Then
'This point looks for ID's that exist only in the portal - there shouldn't be any right now,
'but in the future, I want to be able to create new service accounts via the portal.
'So, as there shouldn't be any of these now, lets just raise an error:
Throw New Exception("Something odd going on here - remnant in FIM only?")
If MyADADMAConnectors = 1 Then
adDN = mventry("adDN").Value 'this is construvted as part of the HR input sync
DN = ADMA.CreateDN(adDN)
'There is already an AD connector, so...
csentry = ADMA.Connectors.ByIndex(0)
'If the expected DN has changed change it in AD too
If Not csentry.DN.ToString.ToLower.Equals(DN.ToString.ToLower) Then
csentry.DN = DN
'Check for real people who have been previously provided by HR (they have an EndDate),
'who have become disconnected from the HR PersonAssignment table.
'i.e. they have been deleted but the message has not been passed on! So, raise an
'error to ensure that the user is manually deleted from AD and FIM.
'We only care about those who have an EndDate, as all service accounts and some particular
'Users do not have an EndDate - for example those who have historically been added, but are no longer referenced in HR.
If HRMAPAConnectors = 0 Then
If mventry("employeeEndDate").IsPresent Then
Throw New Exception("User in AD, but not in HR - possible duplicate deleted but not informed!")
If MyADADMAConnectors > 1 Then
'There should never be anything except 0 or 1 MyADADMAConnectors, so raise an error.
Throw New UnexpectedDataException("Multiple MyADADMAConnectors:" + MyADADMAConnectors.ToString)