If a connector satisfies the following:

• Implements modify anchor;
• Implements update;
• Uses the connector key to look up the repository entity on update;

The update will fail as the new key won't match the repository entity.

See if the matching entities can be modified so that they have the updated key. This was an issue for v4.1, but may not be an issue with v5.0 as the connector doesn't need to look up the entities.

For the PowerShell connector, the collection of original entities should be available to the script.

This issue is really 2 issues in one:

• the Copy Connector function causes duplicate Timing id GUIDs to be generated, and
• the presence of duplicate Timing id GUIDs cause the corresponding timing node not to fire the connector when the cycle comes around.

So Richard Green - I have just discovered the cause of FIM issue 133 (and most likely 134 as well) - namely multiple connectors with the same polling id GUID, causing the timer not to fire. How they got there I believe was via the COPY CONNECTOR menu option, and I have just proven this (see comments following this issue description).

In the attached configuration, the GUID 43b343ba-a287-401f-b92a-347d572b80f0 appears on 2 connectors' polling Timing nodes, and the GUID 15c3fa6b-cf9e-4fb5-8724-5eae2027da49 appears on several getAllEntities Timing nodes.

The impact of the GUIDs being the same appears to be that the timings count down and then roll over and nothing happens (nothing executed - no log of execution). This would explain why a number of the connectors hadn't reported any changes between the time they were installed to TEST last Friday, and the time the bug report was raised (Wednesday).

I am wondering how many other IdB 4.* implementations out there have this sleeper? As a result I have assigned a CRITICAL status (due to the potential impact), even though I now know the cause of the problem and have implemented a solution.

Edit: FIM Event Broker has been confirmed to generate new id's, and as such is not going to have this issue.

The customers have to the following questions which I am not enough understanding of Identity Broker for chris21 and chris21 system to simlulate a termination of a user. I will attempt to provide my answer below. Please assist in clarifying or answering these questions if possible.

AHG
I've found that the Connector Delta Import process doesn't seem to pick up termination changes. When I do a Full Import the change comes through.

The steps I have followed are:

1. Terminate user in Chris21
2. Perform 'Synchronise Import' on the connectors
3. Run the Chris21 MA Delta Import process

The Synch stats show that there are no changes that have been picked up.
If I perform a Full Import using the Chris21 MA I still have no changes.

Shane Lim - I understanding is the "Synchronise Import" on the Termination Connector to bring in the delta change into the Termination connector table. This delta change would then be processed/transformed into the Adapter table. When the user perform the "Delta Import" in FIM chris21 MA the delta change in the Adapter table would flow in FIM chris21 MA.
Having said this I have not done this scenario before since I have no knowledge how to terminate a user in chris21.

AHG
If I complete a full import on all the connectors, then a delta import using the Chris21 MA I have the update I expect. Is this the correct behaviour? I had expected that performing a Synch Import would pick up such a change, or am I mistaken?

Shane Lim I expect the "Synchronise Import" in Unify Management Studion followed by the "Delta Import" in FIM chris21 MA to pick up the delta change.

AHG
The other question is, out of curiosity, when I terminate someone, should I be able to just import from the Termination connector seeing as the only change that was made to Chris21 is the addition of a termination record? Currently this doesn't work, I get the same GTR error we were getting last week. I have to first import from Person, then the Termination connector.

Shane Lim I expect that each Identity Connector be able to perform the "Synchronise Import" independently.
PS: Cabrini Health fundamentally using the same Identity Broker for chris21 Connector and Adapter configuration files and they have not report experiencing the same behaviour here.

AHG
Something else I have noticed is that for the Metaverse to be updated by the change made to AD to disable the account for the terminated employee, I have to perform a Full Import using the ADDS MA and then a Delta Sync. Again, I had expected that a delta import should do the job, but, I may be mistaken?

Could you please clarify this for me as perhaps i'm misunderstanding when we need to perform a Full Import versus a Delta Import. I thought we really only needed to perform a Full Import when we are populating the Metaverse and the Connected Spaces for the first time. After that I thought Delta's should give us any changes made but that doesn't seem to be the case. I am running through multiple cycles as you recommended so I can ensure the data change flows through all the different steps properly.

Shane Lim
My understanding and expectation is that a "Full Import" in the Unify Management Studio and in the "Full Import" in the FIM chris21 MA is not necessary after the initial "Full Import" is completed. But then we do have the schedule in the Identity Broker for chris21 Connector configuration for performing getAllEntities.
Thus now I am no certain what the expected behaviour.

Please assist.

This issue is a follow on to the now resolved https://unifysolutions.jira.com/browse/IDB-1216

What I'm finding is that if I provision an entry to UNIFY Identity Broker, and then perform a delta import, the entryUUID is not in the list of values returned. This then results in FIM throwing an exported-change-not-reimported error. If however a full import is performed, the entryUUID is present.

Generally this likely won't matter if the entryUUID isn't explicitly being used, but it is an issue if the adapter DN is UID=@idBID and you thus need to set the UUID (as the previously linked to issues final post implies)

I've captured some screen shots of the error and behaviour of delta and full imports

Performing a full sync preview which triggers provisioning that sets some defaults, as well as applies some flows

Export to occur, including the entryUUID (set so that I could also control the DN, pictured)

Errors resulting from a delta import performed after the export (there was a 1 minute gap between the export and running this import)

Missing attribute

What the delta Import brought in

Finally running a full import, which has the entryUUID present

I'd expect that deltas should bring in the entryUUID following a provision. To reproduce it I don't think you necessarily need to be using the entryUUID as part of the DN for the adapter, just select on the MA that as an attribute to be read into FIM and then provision a new record and follow it up with a delta import.

The time offset flag transformation deals with times, but does not have a local setting. To allow for local calculations without having to use the offset, add the local setting.

To better accommodate large deployments or deployments consolidating many copies of the same system, allow either or both of the following:

• Support subschema;
• Allow attributes with the same configuration to be shared.

Perform upgrade of Identity Broker for chris21 from v3.0.5 to 3.0.5.2 (by uninstalling older version and install the newer version).

Make no change to any of the Identity Broker's Connector and Adapter configuration for chris21.

Restart Identity Broker service successully.

Performed "Clear All..."

Performed "Import All Connectors..." result in the following errors for all Connectors for chris21.

20110203,23:18:56,Adapter clear started.,Adapter,Information,Adapter d5251d7d-05cc-4d35-916e-e99e06b9ffd3 clear started.,Normal
20110203,23:18:58,Adapter clear completed.,Adapter,Information,Adapter d5251d7d-05cc-4d35-916e-e99e06b9ffd3 clear completed in duration 00:00:02.7343750.,Normal
20110203,23:19:27,Change detection engine import all items started.,Change detection engine,Information,Change detection engine import all items for connector Chris21 Person Connector started.,Normal
20110203,23:19:27,Chris21 Person Connector,GetAllEntities,Information,Started successfully.,Verbose
20110203,23:19:27,chris21 GTR EAI Communicator,List,Information,Started successfully.,Verbose
20110203,23:19:28,chris21 GTR EAI Communicator,List,Warning,"Logout failed with the following message:

GTR line type is recognized but not valid [Command].",Verbose
20110203,23:19:28,chris21 GTR EAI Communicator,List,Information,Completed successfully after [00:00:00.0468750] duration.,Verbose
20110203,23:19:28,Chris21 Person Connector,GetAllEntities,Information,Completed successfully after [00:00:00.0468750] duration.,Verbose
20110203,23:19:28,Request to get all entities from connector.,Connector,Information,Request to get all entities from connector Chris21 Person Connector.,Normal
20110203,23:19:28,chris21 GTR EAI Communicator,List,Information,Chunking [2000] is implemented after [00:00:00.0468750] duration.,Verbose
20110203,23:19:28,Get all entities from connector failed.,Connector,Warning,"Get all entities from connector Chris21 Person Connector failed with reason GTR line type is recognized but not valid [Command].. Duration: 00:00:00.0156250
Error details:
System.IO.InvalidDataException: GTR line type is recognized but not valid [Command].
   at Unify.Framework.Chris21GtrWorker.ExtractListResult(ICollection`1 entities, IChris21GtrRecord record, Int32 entityKeyCount)
   at Unify.Communicators.Chris21GtrCommunicatorBase.<ListWithChunking>d__0.MoveNext()
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at Unify.Framework.EnumerableExtensions.<ActionOnFirst>d__1c`1.MoveNext()
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at Unify.Framework.ActionOnExceptionEnumerator`1.MoveNext()
   at Unify.Framework.EnumerableExtensions.<ActionOnLast>d__16`1.MoveNext()
   at Unify.Framework.EnumerableExtensions.<ProduceAutoPages>d__9`1.MoveNext()
   at Unify.Framework.Visitor.ThreadsafeVisitorEvaluator`1.Visit()
   at Unify.Framework.Visitor.VisitEvaluateOnThreadPool[T](IEnumerable`1 visitCollection, Action`2 visitor, Int32 maxThreads)
   at Unify.Framework.RepositoryChangeDetectionWorkerBase.PerformChangeDetection(IEnumerable`1 connectorEntities)
   at Unify.Framework.ChangeDetectionImportAllJob.ImportAllChangeProcess()
   at Unify.Framework.ChangeDetectionImportAllJob.RunBase()
   at Unify.Framework.MutexJobDecorator.Run()
   at Unify.Framework.DefinedScopeJobAuditTrailJobDecorator.Run()
   at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)",Normal

Is there any other configuration that I may need to update or change?

Post upgrade of Identity Broker for chris21 from version 3.0.5 to 3.0.5.2

I ran into the issue that I cannot perform "Synchronisation Import" or "Full Import" on any exist chris21 Connectors. See end of issue IDBCHRS-13 for details of the error.

Since I need my Lab environment for other work for chris21 I downgrade Identity Broker for chris21 back to version 3.0.5. This is done by uninstalling Identity Broker for chris21 v3.0.5.2 and install Identity Broker for chris21 v3.0.5.

I also restore to Connector and Adapter configuration file to the known working ones.

When starting the Identity Broker service I encounter the following error:

Unify.Framework.UnifyServerInitializeException: Could not load file or assembly
'Unify.Framework.LogWorker.Interfaces, Version=3.0.5.0, Culture=neutral, PublicK
eyToken=84b9288cb2633de4' or one of its dependencies. The located assembly's man
ifest definition does not match the assembly reference. (Exception from HRESULT:
 0x80131040) ---> System.IO.FileLoadException: Could not load file or assembly '
Unify.Framework.LogWorker.Interfaces, Version=3.0.5.0, Culture=neutral, PublicKe
yToken=84b9288cb2633de4' or one of its dependencies. The located assembly's mani
fest definition does not match the assembly reference. (Exception from HRESULT:
0x80131040)
File name: 'Unify.Framework.LogWorker.Interfaces, Version=3.0.5.0, Culture=neutr
al, PublicKeyToken=84b9288cb2633de4'
   at Unify.Connectors.Chris21GtrConnectorFactoryBase`3.CreateComponent(IMultiKe
yedConnectorFactoryInformation factoryInformation)
   at Unify.Framework.PlugInGeneratorBase`4.CreateComponent(TFactoryInfo factory
Information)
   at Unify.Framework.ConnectorEngineConnectorGenerator.CreateComponent(IMultiKe
yedConnectorFactoryInformation factoryInformation)
   at Unify.Framework.ConnectorGenerator.CreateComponent(IConnectorGeneratorInfo
rmation factoryInformation)
   at Unify.Framework.PollingConnectorEngineConfigurationFactory.CreateConnector
ConfigurationBase(XElement xmlConfiguration, IConnectorHelper connectorHelper, I
Timing pollingTiming, INotificationMessageService messageService, ITiming getAll
EntitiesTiming, IConnectorGroup connectorGroup)
   at Unify.Framework.PollingConnectorConfigurationFactoryBase`2.CreateComponent
(IConnectorConfigurationFactoryInformation`1 factoryInformation)
   at Unify.Framework.PlugInGeneratorBase`4.CreateComponent(TFactoryInfo factory
Information)
   at Unify.Framework.ConnectorConfigurationGeneratorBase`4.CreateConnectorConfi
gurationFromNode(THelper connectorHelper, XElement connectorNode, TConnectorConf
igurationCollection connectorConfigurationCollection, IConnectorGroup connectorG
roup)
   at Unify.Framework.ConnectorConfigurationGeneratorBase`4.CreateConnectorConfi
gurationCollection(XElement xmlCollection, THelper connectorHelper)
   at Unify.Framework.ConnectorEngine.Initialize()
   at Unify.Framework.UnifyEngine.Initialize()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\M
icrosoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure lo
gging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fus
ion!EnableLog].

   --- End of inner exception stack trace ---
   at Unify.Framework.UnifyEngine.Initialize()
   at Unify.Services.Connect.Debug.ProgramProxy.Execute()

I thought that the core files are somehow wrong version thus I uninstall Identity Broker Service v3.0.5.6 and re-install it. The problem persist.

Any advise or assistant on how to resolve this issue would be much appreciated.

Thank you.

Add the ability to update non-primary work address. The type of address should be configurable if possible, otherwise hard-code to work address. It should be the non-primary address.

The rules in Workday will ensure that there is only one address that satisfies these conditions.