When installing the software you get an error:
Login failed with error: 1385

The issue is that the account doesn't have logon as a service rights to the server.

Is it possible to grant that right if it doesn't exist? If not, can you trap that particular error and report the true cause as the account is fine and it'll drive the normals nuts.

I have demoted a connector out of a composite adapter. I am now trying to delete the other adapter that is part of the composite (the connector was deleted so I don't want it).

The product accepts it and returns you to the main page. However, if you then click on the composite adapter again it displays the 'deleted' connector. it should either tell you you can't do it, or do it and perhaps delete the composite as well (with a warning).

I recieved the error:
Error -2147217843: failed to create SQL database:
Unify.IdentityBroker, error detail: unknown error.

Make the installer clearer regarding the different types of authentication.

If we are using the Entity ID its because its an anchor or similar in FIM. Therefore, we would like to be able to search or filter for a specific entity by ID. Similarly, we may often not care what it is and would like to hide it. Can it be treated the same way as any other column?

Also, it would be good if clicking anywhere on the row brought up the entity view (which is great!), thus removing the issue if the column is hidden.

When removing an added column mapping in a adapter Relational transformation

The following error message is displayed:

Hey Guys,

I've uncovered a new issue with IDB in regards to renames.

This issue occurs when multiple renames are perfomed on the same object. I've performed a significant ammount of testing and analysis on this issue, which i'll explain in detail below, but in each case, after the second rename, the confirming import in FIM produces one or more need-full-object errors. I also believe I have determined where the issue is being produced.

In most cases, this is the general procedure for producing the issue:

1. Rename user (uid) in Active directory and produce a Provisioning Rename for Export to TAM.
2. Export rename to TAM (Successfull)
3. FIM Delta Import confirms rename. (Successfull)
4. Rename same user again in AD.
5. Export rename to TAM (Successfull)
6. FIM Delta Import - need-full-object error produced.

In each case the rename is successfully exported to TAM, and i have confirmed that in all cases the Modify Anchor method on the connector is being hit.

These are the cases tested, and the results:
(All UNIFYDelta files for these cases are in the attached ZIP)

1. - Rename user cladn3 to cladn30, and then rename back to cladn3.
2nd Import Result - need-full-object error produced on cladn3

2. - Rename user kxhep0 to kxhep50, and then rename again to kxhep70.
2nd Import Result - need-full-object errors produced on both kxhep70, and kxhep0

3. - Rename user uxngt0 to uxngt05. Perform an IDB full import, then rename user back to uxngt0.
2nd Import Result - need-full-object error produced on uxngt0

4. - Rename user ulgni1 to ulgni10. Perform a FIM full import, then rename user back to ulgni1.
2nd Import Result - need-full-object error produced on ulgni1

5. - Rename user ugfen1 to ugfen10. Perform an IDB & FIM full import, then rename user back to ugfen1.
2nd Import Result - need-full-object error produced on ugfen1

6. - Rename user bxttt0 to bxttt05. Drop IDB Connector Partition and FIM CS, then Reimport. Rename user back to bxttt0.
2nd Import Result - Rename successfull.

The need-full-object error is defined here: http://support.microsoft.com/kb/818559
We've seen this error before on QDET-156, and it occurs when an update operation is attempted on an object before the object is sucessfully renamed. The rename is completed by the presence of a moddn operation in the delta ldif file. Until this operation is processesd, the object in FIM retains it's original DN.

In viewing the UNIFYDelta ldif files produced on the second confirming import, the issue becomes apparant.

In the cases where the uid was changed back, no moddn entry is present to confirm the rename. Updates present for the object fail with the error as explained above.

In case 2, where the uid was renamed again to a different uid, the ldif file did contain a moddn, but it was incorrect. As above in this case, the first rename was from kxhep0 to kxhep50, and the second from kxhep50 to kxhep70. The second moddn (see below) was trying to rename from kxhep0 to kxhep70.

The moddn for the first rename in this case looked like this:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep50
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is correct, and the rename was successful.

The second rename:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep70
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is incorrect, as it is trying to rename from kxhep0 to kxhep70, but at this point in FIM, the DN is kxhep50.

After seeing this error, i performed some analysis on the database to monitor the status of the records around a simlilar operation. In this case i renamed a user from uxnnt3 to uxnnt30, and then to uxnnt31.
The results of this trace are in the attached excel sheet, but i was able to note that throught all of the exports and imports, the DN field on the entity table remained unchanged from it's initial state.

The fact that this field is not being updated explains all of the above issues. When the uid is being renamed as in case 2, it produces a moddn from the DN present, to the required DN. In cases where the uid is being changed back, as it allready has the same value in the DN field, it does not produce a moddn as assumes none is required.

It looks like this field is used to create the moddn entry, particularly in specifying the current DN of the object. On the second rename, the moddn entry is produced incorrectly, as the DN was not updated after the first rename. The result of this is that the rename is not confirmed on the FIM import, and remains in the state of awaiting export confirmation.

To summarise all of the above, i've confirmed that on rename operations within IDB, the DN field of the entity table is not updated to reflect the new DN of an object. The result of this causes issues when creating the moddn entries after a second object rename.

Multiple rows should be able to be selected for deletion on the connector schema. Possibly use a similar mechanism to add text boxes as is used for the connector/adapter pages.

QDET-194 shows that if a relational change affects a large data set, memory consumption can grow quite high and result in OutOfMemory exceptions. Changes should be made to the transformation contributions such that they do not load all potential matches immediately into memory.

Add the ability to create, read, update and delete all of the possible associations (i.e. "member of", "supervised by", "supervisor of", "delegate of", "has delegates", and "administrator of").

See comment on IDBTRIM-3 for further details.

When creating SQL connector: If there is an IDENTITY column in schema and 'IDENTITY_INSERT' is set to 'OFF' (not sure if it is possible to query table for current IDENTITY_INSERT config), create the attribute as read only.

When it is not read only, the error below is reported.

Cannot insert explicit value for identity column in table 'FIMEmployee' when IDENTITY_INSERT is set to OFF.