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

It appears there may be an issue with my current environment.

I have a set of connectors and adapters I am trying to delete due to them no longer being in use. Their entities have been cleared for quite some time (a few months at least) and I am simply trying to delete them.

I am able to delete the connectors and adapters just fine within the interface, however upon restarting the UnifyBroker service, the service will fail to start back up. Giving the following error in the event logs:

Service cannot be started. Unify.Framework.UnifyServiceStartException: The DELETE statement conflicted with the REFERENCE constraint "FK_Entity_ObjectClass". The conflict occurred in database "Unify.IdentityBroker", table "dbo.Entity", column 'ObjectClassId'.

The statement has been terminated. ---> System.Data.SqlClient.SqlException: The DELETE statement conflicted with the REFERENCE constraint "FK_Entity_ObjectClass". The conflict occurred in database "Unify.IdentityBroker", table "dbo.Entity", column 'ObjectClassId'.

The statement has been terminated.

at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)

at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)

at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Bo...

I have tried this twice, so far and both ended with the same result. The first time I suspected maybe I didn't wait long enough before clearing the entities, deleting the configuration components and then restarting. However this second time the entities were cleared months ago, and when deleting the connectors/adapters I waited several hours before restarting the UnifyBroker service. So it would appear the DB has some sort of data issue preventing the deletion.

The connectors in question are just PowerShell connectors and the adapter have no transformations.

Version 5.3.2

Hi guys,

As per the title, we have had an inquiry as to whether the Content Manager connector supports updating the 'Alternative Login' field?

This appears to be a new field added in the latest version of Content Manager, so wouldn't be surprised if a patch is required.

Version information:
UNIFYBroker: v5.3.3
HP TRIM Connector: 5.3.1.0

Thanks,
Liam

Hi Gents,

Raising this in regards to an issue experienced recently at DCCEEW.

An adapter that is primarily used to provision out to a target system was modified with a join transform to include an additional attribute from another connector. This attribute happened to be the key field for the connector it was sourced from and naturally configured as a required field in the connector schema. After the join transform was applied the attribute was added to the adapter schema, but in addition the required field status was also reflected on the adapter.

As this was a mapped field, and not included in the attributes being exported through the adapter, this caused exports to fail with a schema validation error. 

Attributes mapped via a join transform should not be set as required on the adapter schema.