Due to IDB-799, the schema retrieval for MOSS List and 2007 User Profile does not work:

As a workaround, the connector factories should call CreateComponent to recreate the connector in the schema retrieval rather than relying on the connector repository.

As per our discussion - the SharePoint2010UserProfileConnector and 2007 User Profile connector requires an account field to be the first key for ModifyAnchor to work.

A determination should be made about whether the AccountName field in SharePoint can change, and if so whether the current field name can be retrieved.

This raises a question about the concrete requirements for a fixed schema in a larger sense, and what a fixed schema is event meant to be.

There are a number of ways of potentially thinking about fixed schemas:

e.g.

• A fixed schema field is a field that cannot be changed from a concrete/constant field defined in IDB
• A fixed schema field is a field that must be present, and needs to be requested from the target identity management store.
• A fixed schema field is a field which must be a key or must have a name, or must be readonly etc., but all other values can change
• A fixed schema field is there to help, and that takes precedence over whether it doesn't necessarily need to be in the schema (but will always be in the target store).

etc. etc.

The Chris21ListRequest enumerable allows for the handling of "Specific" list requests, denoted by the value "S" being sent to Chris21. This seems to mean that only fields present in the schema will be returned. The connector currently throws a "not supported" exception in the case where the connector is configured in this way.

"Default" and "All" type retrieval are used in current Chris21 configurations without any issues, so this is a minor issue to revisited at some stage. Until then, it may be worth commenting the "Specific" type out of the enumerable so it is not selectable via the UI.

Estimate includes updating the connector to support specific handling and testing.

Update connector to work with SharePoint 2013.

A change was made to the domain casing so that they are consistent, in this case I added .ToLowerInvariant() to user.Domain (AccountNameToDistinguishedNameAdapter.cs, Line 43)
As i mentioned this might not be applicable to all sites, so an option to enable/disable would be appropriate. Possibly also an option to select between Upper or Lower case might be useful too.

As per Dustin Page from ASC:

Hi Andre,

Looks like I found the issue, one of the guys made a change to the SQL server environment in Production a few weeks ago and forgot to set all the database collation types back properly. I did move it back to what it’s meant to be set to but it seems I’m still getting the following error in the logs;

20120914,05:25:47,Connector processing failed.,Connector Processor,Information,"Connector Processing page 1 for connector Aurion Schedule Connector failed with reason Cannot resolve the collation conflict between ""SQL_Latin1_General_CP1_CI_AS"" and ""Latin1_General_CI_AS"" in the equal to operation.. Duration: 00:00:01.5635366

SQL collation is set back to SQL_Latin1_General_CP1_CI_AS as per the test environment. Yet I’ve restarted the Broker Service and it keeps seeing the same error?

Marked as critical because I have been requested to have an answer by 1pm Brisbane time.

E-mail from Peter Williams:

"There technical guy Andrew Stewart will be on the call. I spoke with him this morning and he had a detailed technical question about setting up the Aurion connection. Can you please try to have an answer for this by the meeting today.

Question: What type of account does the Identity Broker for Aurion connect to in Aurion? Is it an employee self-service (ESS) account or is it a client account?"

Preparation question from a client:

Aurion has 2 API types, xml rpc and xml document binding or such. Which does Unify need for their broker?

I know we've dealt with this question before, but I couldn't find the answer on here or in the documentation.

Restarting the service to enable WCF tracing is a PITA.

Might be possible to do something like mentioned in this thread:
http://stackoverflow.com/questions/4041289/change-switchvalue-on-trace-listener-in-runtime

Or:
http://stackoverflow.com/questions/7795614/can-i-control-wcf-tracing-programmatically

Connector and transformation post handling does not currently handle validation errors correctly. If custom view data is invalid, the post engine will attempt to access the next sink or stream source. Instead, they should be configured to redirect to the same step of the process.

With Unify Identity Broker 4.0 & 4.1 we can configure Windows Event Log Writer to write to a custom log: https://unifysolutions.jira.com/wiki/display/IDB41/Windows+Event+Log+Writer

Will Unify Identity Broker create the custom log when we configure this and if so do we have to restart the server or what steps must be taken as it is not stipulated.

Required for health check data collection scripts.