In order to support the unit testing requirements for transitioning PS solutions on Broker+ to the UNIFYConnect hosted platform, a test harness is required for all PowerShell transformations.

It is becoming an impediment to future UNIFY* opportunities, particularly in the hosted solution space, that UNIFYBroker runs only on the Windows Server O/S.  If porting it to run natively on Azure would significantly reduce the current hosting impediments, while at the same time retain the natural partitioning between sites that comes from hosting the service within a VM, this would be of significant benefit to all parties from Sales to Implementation.  It would also make the idea of having Broker 3rd-party configurable more of a possibility.

I have added a new string field to the Aurion Person connector "ExtraField1". We already had "ExtraField2" (which was working).

The config already had a mapping:

<attribute name="Extra_Field_2" target="ExtraField2">

I have added underneath that:

<attribute name="Extra_Field_1" target="ExtraField1">

When I try to run the Import All now it runs for quite a while (this report takes a long time to generate), then fails with the error:

Attempting to retrieve the CollectionKeyId for caption ExtraField2 failed. No collection key found for that caption.

What has gone wrong?

I will send full error and config files by email once someone picks this up.

Tested Against: Identity Broker v5.3

Currently if you have no adapters enabled in IDB, and you attempt to create an MA in MIM using the MIM Adapter ECMA2, you get the following error:

The extensible extension returned an unsupported error.
  
The stack trace is:
 "System.InvalidOperationException: Sequence contains no elements
   at System.Linq.Enumerable.Aggregate[TSource](IEnumerable`1 source, Func`3 func)
   at Unify.Product.IdentityBroker.LdapConnectionProxy.get_Schema()
   at Unify.Product.IdentityBroker.UnifyLdapConnectorTypeProxy.GetSchema(KeyedCollection`2 configParameters)
Forefront Identity Manager 4.4.1302.0"

It would be good if the error could either be reported in a more logical way (IE inform that there's no adapters enabled, and therefore no OU's to load), or simply allow the creation process to continue and the user will realise there's no adapters enabled in a subsequent step.

The error also occurs if you have adapters which are enabled with valid schema, but inhibited due to a condition with the base connector. 

In doing development I found myself continually jumping between IDB Connector and Adapter pages to look at high level statistics such as polling object counts and pending changes on a few adapters - this can result in having half a dozen tabs open for this purpose.

As an enhancement it would be nice if the IDB Dashboard displayed some more high level statistics such as last run time/status, object counts and pending changes (for adapters) to get a more complete view of the system state.

IdB 5, Powershell connector, target system is RedHat LDAP.

There are three objects which exist as entities in the IdB connector and adapter but do not exist in LDAP. FIM is trying to update them and we're getting "Object does not exist" errors back from LDAP.

Connector Full Imports have been run. I turned on the verbose logging I'd added to the script which lists the DN of every object found by the Import script and these objects are not listed. I can't see any errors in the IdB log and the Full Import appears to have completed successfully.

So the question is, if they were not imported in a connector full import, shouldn't the entities have been removed from IdB?

Add support for integration external Workflow/Ticketing systems

A UNIFYConnect customer has requested the ability to implement a safety catch feature to stop updates if they are over a certain threshold. I know that Broker/BrokerPlus has a safety catch feature for entity deletion thresholds, but does anything currently exist for updates? Ideally this would be a check that if the number of changes on a link are over X amount it stops the sync, disables the schedules for that link, and then throws an error in the logs to be picked up via the monitoring/alerting.

The only topic I could find on this at the moment is Safety Catch Feature / UNIFYBroker Forum / UNIFY Solutions. 

I have noticed that if a link has a PowerShell task on an outgoing sync task that modifies and sets attributes in the target, then a change flows through to only that attribute modified in the PowerShell task, then the link doesn't pick it up as pending sync change. Only running a baseline sync on the link would trigger the PowerShelltask to change/modify that attribute. 

Discussion was had with Matt Davis on the possibility of using the Register-Contribution function on a link for the attributes that are being modified through the PowerShell task to then recognise changes for those entities. However it is unsure whether the Register-Contribution function is available for links or not. As an alternative, the PowerShell script can be used on the adapter in a reverse transform, which triggers on outgoing sync changes from a link to a connector. Then the contributing attributes can be sync as direct mappings in the link.

I have noticed that under normal operation, a baseline synchronization task on a link cannot be executed while the link is disabled. In the link UI, the option to run a baseline sync only becomes visible when the link is enabled. However I have found that on the Links page (that lists the links in the solution) selecting a disabled link and running a baseline sync through the Actions button at the top of the page still executes the baseline sync on the disabled link. Not sure if this is expected behaviour or is a bug.

Screenshot #1: Running a baseline sync task on a disabled link through the Actions button:

Screenshot #2: The baseline sync still executed even though the link is disabled: