I'm building a Powershell based connector that integrates with a system with a few thousand records. Each record has a User Name which must be unique, however not all users are to be imported into FIM. The IdB Powershell MA has to be provisioned to, so as part of that a unique User Name has to be generated.

This has lead me down the route of developing extension code to perform an LDAP lookup on the Identity Broker 5 LDAP interface to check whether a user name is available or not (as I can't compare with the metaverse since the end system isn't fully represented there). I've found that the string attributes exposed by the Identity Broker 5 LDAP interface have an Equality rule of 'caseExactMatch'. I can't guarantee what the case is of data in that end system unless I manipulate it on import to Identity Broker (have my Powershell MA cast to Upper case for example). As a result, any query against the LDAP interface is going to be complicated by the fact that I can't merely search for objects with (USNAME=Svcfimadmin) since that won't give me a result is the USNAME is 'svcfimadmin'. I would need to use (USNAME=svcfimadmin) to get any result. Instead I'll likely need to do something like get the first character and import all objects with that name, grab all the User Names and manipulate them in code.

That could be avoided if I could set the comparison to be case insensitive. I can't really think of any cases at all where I'd want a comparison to be case sensitive, and indeed on review of the issue it appears that Active Directory and other systems typically have comparisons set as case insensitive (a few attributes are sensitive). Many end systems will ignore the case for attributes like Account Names etc too.

I imagine the case sensitive could make more difficult in other situations where someone wants to make use of the LDAP interfaces to perform searches and the like.

I'm not sure how feasible it would be to add a 'case insensitive' string type, or provide a flag that could be set on an attribute basis to determine how searches via the LDAP interface are handled.

While the next run information is always correct, the CheckDue function of exclusion timings starts returning true if an exclusion period ends, rather than at the appropriate next run time. This is because the internal timing's NextRun property is not updated when an exclusion period is in effect, and as such will retain a NextRun value in the past, causing it to run on the next CheckDue call outside of the exclusion.

The definition about "console" is a bit unclear. I had no clue until Tony explained what it is referring to,
"it writes to the console if you're debugging Identity Broker through the console at:

C:\Program Files\UNIFY Solutions\IdentityBroker\Services\Unify.Service.Connect.Debug.exe"

I think it could be a good idea to add some detailed information on the page just to make it clear for everyone.

Cheers,
Sam

SCOM integration capability for consumption in EB 3.1 and IdB 4.1

System administrators prefer to observe activity and errors through existing monitoring tools, such as SCOM. The value of Event Broker (and our entire product range) in an Enterprise would be greatly improved by permitting this.

There is currently no character field in Identity Broker. This is currently worked around by storing those values in the StringValue field:

GET: entity.GetValue<StringValue>(...).Value0;
SET: entity.SetValue<StringValue>(character.ToString(...));

However if this won't take much time it might be more descriptive to include a character field type.

The service installer should configure the web engine settings for FIM Event Broker and Identity Broker.

Consider stopping ActionRefresh when the page isn't focused as it would reduce network usage.

If you create a Custom Log Writer with the same display name as an existing one it goes back to the Logs page with an error "A log writer already exists with the name "BlahBlahBlah" " You lose any configuration. Could be good to validate first.

We should investigate whether we can use phantom query strings to prevent the use of the CSS/JS cache when upgrading to new product versions. See: http://davidwalsh.name/prevent-cache

Though RFC4180 states the end of each row should be CRLF, some CSV files I've encountered (such as from here: http://www.ourairports.com/data/) use the lone, Unix/OSX LF at the end of rows. Our CsvEnumerable is intended to parse these but currently doesn't