There are some new issues with the next run information for connectors:

• The time shown only shows the time til the next Import All run
• The progress bar seems to only now show the results of Import All, not Import Changes
• The progress bar appears while the operation is running, then clears the progress bar very shortly after it is done from the home page, unsure whether or not this is by design

To observe this, I added an import all schedule that would run every 10 hours, and a import changes schedule every 30 seconds. This was using IE9.

When an org unit has a child org unit within and a delete attempt is made on the parent, the response is "Cannot delete entity with members (412)" and the delete fails.

A configurable option should be implemented that allows any child orgs to be deleted automatically when its parent is to be deleted.

It would be nice to see what operations were run from the Connector and Adapter index pages, eg. "Adapters X, Y and Z deleted". At the moment, the operations simply happen.

It would be great to have a progress meter in IdB, so that you can see something is actually happening during an import.
Perfmon Counters would also be great/better. Something along the lines of what's available in the FIM Sync Engine:
Objects Read
Objects Read /sec
Objects Exported
Objects Exported /sec
Objects Synchronized
Objects Synchronized /sec

A new critical alert is spawned each time the page refreshes.

Please ensure that the fix does not allow further dialogs to be spawned, as to not lose the current position and size.

When the import file cannot be generated it is unclear what has happened.
Namely the following is what can be seen from the Event Viewer on the FIM side:

The extensible extension returned an unsupported error.
 The stack trace is:
 
 "System.Exception: Error encountered attempting import: System.ServiceModel.CommunicationException: An error occurred while receiving the HTTP response to http://localhost:59990/IdentityBroker/FIMLDIFAdapter.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace: 
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Unify.Product.IdentityBroker.IdentityBrokerLDIFAdapter.ILDIFAdapter.ImportAll(Guid adapterId)
   at Unify.Product.IdentityBroker.IdentityBrokerManagementAgentProxy.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData) 

   at Unify.Product.IdentityBroker.IdentityBrokerManagementAgentProxy.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)
Forefront Identity Manager 4.0.3606.2"

whilst the following is what is available in the IDB logs

An exception has occured whilst performing a job for adapter 2656b225-d789-437d-bd32-03ae2f6ed07c job GetTransformedEntities (ParallelGate):
System.Data.ConstraintException: Only standard components can be contained inside a multipart component.
at Unify.Product.IdentityBroker.EntityMultiPartDistinguishedNameComponentGenerator`2.<>c__DisplayClassa.<GetDistinguishedNameComponents>b__9(IEntityDistinguishedNameComponentGenerator`2 generator)
at System.Linq.Enumerable.<>c__DisplayClass12`3.<CombineSelectors>b__11(TSource x)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Unify.Framework.IO.DistinguishedNameMultiPartComponent.ToString()
at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Unify.Framework.IO.DistinguishedName.GetStringValue()
at Unify.Product.IdentityBroker.Repository.AdapterEntityContext.SetEntityRowDetails(__EntityInsertRow row, IAdapterEntity entity, EntityDataContext sourceContext, IEntityCollectionKeyUtility`1 keyUtility)
at Unify.Product.IdentityBroker.Repository.KnownEntityContextBase`4.InsertItems(HashSet`1 addedItems, EntityDataContext sourceContext, SqlConnection connection)
at Unify.Framework.Data.LinqContextConversionBase`4.SubmitChanges()
at Unify.Framework.ParallelGate.ParallelGateJob.RunBase()
at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)

Schema provider should mention that it won't override existing fields of the same name. As this behaviour could be confusing if it's not specified as a piece of text on the provider.

The Identity Broker for chris21 seems to take significantly long period of time to perform "Full Import" from chris21 system into Identity Broker Connector and then process/transform the data into the IdB Adapter.

I am not familar with the flow process and the analysing the log file content. Thus the below investigation may not be entirely correct. But the overall time taken for processing data does seems significantly long in Identity Broker for chris21.

The customer has 4999 records/users in chris21.

Analysis 1:

1 - When performing the "Import All Connectors" for all six (6) Connectors took approximately 32 minutes at other times it does seems to take significantly longer time, eg 45 minutes. During this time the CPU and disk accessing activities are at 100%.

Started at

20101215,07:22:14,Change detection engine import all items started.,Change detection engine,Information,Change detection engine import all items for connector Chris21 Address Connector started.,Normal

Finished at

20101215,07:54:15,Change detection engine import all items completed.,Change detection engine,Information,Change detection engine import all items for connector Chris21 Org Unit Connector completed. Duration: 00:02:34.7343750,Normal

2 - When performing the "Full Import" in FIM for chris21 MA it took approximately 10 minutes. At other times we believe it took significantly longer.

Started at

20101215,07:55:56,Adapter request to get attribute changes from adapter space.,Adapter,Information,Adapter request to get attribute changes from adapter space d5251d7d-05cc-4d35-916e-e99e06b9ffd3.,Normal

Finished at

20101215,08:05:46,Adapter get attribute changes completed.,Adapter,Information,Adapter get attribute changes for adapter space d5251d7d-05cc-4d35-916e-e99e06b9ffd3 completed. Duration: 00:09:49.8125000,Normal

It has been mentioned that the "Import All Connectors" should take only a few minutes. Thus I would like to request a review of the IdB Connector and Adapter configuration files (attached) as to what could possibly create this behaviour. It is mentioned that the gtrChunkSize="1000" could be in appropriate for the volume of data in chris21.

Analysis 2:
Another example: When performing the "Import All Connectors" for all six (6) Connectors took approximately 14 minutes
Start at

20101213,07:01:22,Change detection engine import all items started.,Change detection engine,Information,Change detection engine import all items for connector Chris21 Person Connector started.,Normal

Finished at

20101213,07:15:17,Change detection engine import all items completed.,Change detection engine,Information,Change detection engine import all items for connector Chris21 Placement Connector completed. Duration: 00:02:19.6875000,Normal

2 - When performing the "Full Import" in FIM for chris21 MA it took approximately 27 minutes 30 seconds.

Started at

20101213,07:25:53,Request to get all entities for adapter space.,Adapter,Information,Request to get all entities for adapter space d5251d7d-05cc-4d35-916e-e99e06b9ffd3.,Normal

Finished at

20101213,07:53:34,Adapter get all entities to adapter space completed.,Adapter,Information,Adapter get all entities to adapter space d5251d7d-05cc-4d35-916e-e99e06b9ffd3 returned 4999 entities. Duration: 00:27:41.0937500,Normal

Analysis 3:
"Import all connectors" in IdB took approximately 12 minutes. I do not have the log file
"Full Import" in FIM for chris21 MA took approximately 6 minutes.

Please help to review the Connector and Adapter configuration files and also advice if the above time is acceptable or not.

From Frontier, the logonapplication shouldn't be required when logging in.

Failing exports aren't being picked up as failures in FIM.
To easily reproduce, try exporting to a disabled adapter.