Currently the default provisioning script relies on "good" data being passed to it. Some changes that should be made:

• Check that all required fields (Person Number, given names, sn, termination state etc) are present
• Include an easy configuration option at the top to specify a particular PersonNumber or department so it's clear how LITE can be tested gradually.
• Include userPrincipalName in script

It's pretty easy to miss the fact that you have to update the connector after the schema is updated, a yellow bar similar to that used in the standard warnings above the schema mappings would help this.

After successfully exporting users to Aurion Security Users and attempting to import the change from the Security users connector - The new users are not being picked up.

If i attempt to export again the Aurion API errors "Aurion API error -1: User ID is already recorded in Aurion" which indicates that the export completed successfully. Its just the changes that are not being processed.

I think the first thing to check is that the AURIONSECUSER report created by Lifehouse is outputting these new users.. If not - the issue starts there..

Any other recommendations would be appreciated.

Receiving the same error as mentioned in SALMAT-23..

Attempted to clear the XML_FILE_PATH value as mentioned by Patrick Johannessen - as a result, Aurion defaults back to a local path.
When setting the path still receiving the permission error mentioned above.

Which service account should have permissions to the XML_FILE_PATH?

I understand this an in old issue and may be stretching memory - But any help would be appreciated

I know that earlier versions of the Aurion broker were artificially limited to writing back telephone number only with EMP_UPD_PERS. Has that restriction been lifted? If so, is it all attributes available in the API Function of just a select number?

Please confirm that there are no requirements for updates to the Broker solution if the client upgrades from Aurion 10.1 to Aurion 10.2

When certain errors occur within an Identity Broker for Aurion connector, the Management Studio circles continue to spin green instead of correctly turning red.

Configurating Identity Broker for Aurion write "ContactPhoneNo" back to Aurion system in Identity Broker configuration.
The configuration should be correct as there are times that I can perform update into Aurion system and other times I cannot.

Performed the following are the observation at various point of data flow:

1. In Aurion HR system the ContactPhoneNo = (09) 622 1123
2. Projected into Metaverse telephoneNumber = (09) 622 1123
3. Provisioned into AD MA cs telephoneNumber = (09) 622 1123
4. Exported to AD endpoint
5. Modified in AD endpoint telephoneNumber = (01) 111 1111 - change made in AD to flow back to Aurion
6. Imported into AD MA cs telephoneNumber = (01) 111 1111
7. Did a Full Sync
8. Updated Aurion MA cs ContactPhoneNo = (01) 111 1111
9. Exported Aurion MA
10. In IdB's Adapter entity search = ContactPhoneNo = (01) 111 1111
11. In IdB's Connector entity search = ContactPhoneNo = (01) 111 1111 - changed reflected in Identity Connector entity search as expected
12. In Aurion HR system Contact_Phone_Number = (09) 622 1123 - change did not update in Aurion system. In correct result

After several tried with failure the following error is found in the Identity Broker log file:

20101026,11:27:29,Save entities to connector failed.,Connector,Warning,"Save entities Count:1 to connector Aurion Person failed with reason Aurion API error -1: Specified item CONTACT_PHONE does not exist for function QUERY_TO_XML. Duration: 00:00:01.0585937
Error details:
Unify.Communicators.AurionApiCommunicatorException: Aurion API error -1: Specified item CONTACT_PHONE does not exist for function QUERY_TO_XML
at Unify.Communicators.AurionWebServiceApiCommunicator.RaiseExceptionOnErrorCondition(Decimal pStatus, String pMessage)
at Unify.Communicators.AurionWebServiceApiCommunicator.SetValue(String item, String value)
at Unify.Communicators.AurionApiFunctionBase.SetStringValue(String item, String value)
at Unify.Communicators.EmpUpdatePersAurionApiFunction.SetFunctionValues()
at Unify.Communicators.AurionApiFunctionBase.RunFunction()
at Unify.Communicators.AurionCommunicator.SaveEmployee(IAurionEmployee employee)
.
.
.

It could be that while Identity Broker is performing "getAllEntities" and I run "Export" profile in FIM may created a conflict or confusion with the Aurion API.

Here is Shane Day's thought on this error:

I've had another thought about this - the Aurion API only allows one concurrent transaction, therefore if you are attempting two transactions (a query, and an update) at once, the API gets confused. That's the source of that error.

I'm going to suggest that we put a mutex around operations with one Aurion instance to prevent this situation from occurring. It already cannot happen by two query requests as the connectors are all in the same connector group.

Full imports fail on CSV connectors when there are no existing entities in the connector.

Currently, the CSV connectors in Identity Broker for Aurion are single-keyed connectors of type StringValue.

As there is a small chance that the usage of these connectors at the Department of Finance will require composite keys, the connectors should be upgraded to support this possibility.