Encountering the following error:

WorkflowManager could not deserialize XOML definition: '<ns0:SequentialWorkflow x:Name="SequentialWorkflow" ActorId="00000000-0000-0000-0000-000000000000" WorkflowDefinitionId="00000000-0000-0000-0000-000000000000" RequestId="00000000-0000-0000-0000-000000000000" TargetId="00000000-0000-0000-0000-000000000000" xmlns:ns1="clr-namespace:Unify.Product.EventBroker;Assembly=Unify.EventBroker.PortalWorkflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=84b9288cb2633de4" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
xmlns:ns0="clr-namespace:Microsoft.ResourceManagement.Workflow.Activities;Assembly=Microsoft.ResourceManagement, Version=4.0.3594.2, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<ns1:EventBrokerChangesActivity x:Name="authenticationGateActivity1" EndPointAddress="http://DC1TSTFIM01:59990/EventBroker/EventBrokerManagementStudio.svc" OperationListName="{x:Null}" EndPointConfigurationName="ServerNotifications" Description="Invokes a specified Event Broker operation list. This activity should only be used to specify either an incoming operation list for the FIM Portal MA, or to point at a baselining operation list." OperationListGuid="92ea4487-c638-4dbf-a280-ae702cf5310d" />
</ns0:SequentialWorkflow>'.

Doesn't appear to be this problem: http://voice.unifysolutions.net/topics/2772-forefront-identity-management-service-is-not-able-to-serialize-this-xoml-definition/ as these are in place in the Microsoft.ResourceManagement.Service.exe.config file.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="FunctionLibrary" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0-4.65535.65535.65535" newVersion="4.4.1459.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.IdentityManagement.Activities" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0-4.65535.65535.65535" newVersion="4.4.1459.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.ResourceManagement.Automation" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0-4.65535.65535.65535" newVersion="4.4.1459.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.ResourceManagement" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0-4.65535.65535.65535" newVersion="4.4.1459.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.IdentityManagement.WFExtensionInterfaces" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0-4.65535.65535.65535" newVersion="4.4.1459.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.WorkflowServices" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0-4.65535.65535.65535" newVersion="3.5.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <system.diagnostics>

any ideas?

Using Event Broker 3.2.1.3

Error text:

20170816,07:11:48,UNIFY FIM Event Broker,Operations,Error,"Operation 6b3fa541-163f-4dd5-8841-a41841ba4398 failed in operation list with id 51a5cde2-681b-4329-8da8-d9a0e2b4fceb for the following reason. This is retry number 0: Unify.Framework.UnifyEngineException: Error in stored values engine attempting to write to storage, see the inner exception. ---> System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()
   at WriteArrayOfKeyValueOfGroupedNameValueCollectionKeyanyType70DdoCVIToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , CollectionDataContract )
   at System.Runtime.Serialization.CollectionDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeAndVerifyType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, Boolean verifyKnownType, RuntimeTypeHandle declaredTypeHandle, Type declaredType)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithXsiType(XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle objectTypeHandle, Type objectType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle, Type declaredType)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerialize(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
   at WriteStoredValueCollectionToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , ClassDataContract )
   at System.Runtime.Serialization.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
   at System.Runtime.Serialization.DataContractSerializer.InternalWriteObjectContent(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
   at System.Runtime.Serialization.DataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
   at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
   at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(XmlDictionaryWriter writer, Object graph)
   at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(Stream stream, Object graph)
   at Unify.Framework.StoredValues.IsolatedStoredValuesEngineBase.<>c__DisplayClass14_0.<savestoredvaluescollection>b__0()
   at Unify.Framework.ExtensionMethods.WaitOnMutex(Mutex mutex, Action work)
   at Unify.Framework.StoredValues.IsolatedStoredValuesEngineBase.SaveStoredValuesCollection(IStoredValueCollection storedValueCollection)
   --- End of inner exception stack trace ---
   at Unify.Framework.StoredValues.IsolatedStoredValuesEngineBase.SaveStoredValuesCollection(IStoredValueCollection storedValueCollection)
   at Unify.Framework.StoredValues.StoredValueCollection.InvokeItemChanged()
   at Unify.Product.EventBroker.ADSyncCommitPlugIn.Execute()
   at Unify.Product.EventBroker.OperationListExecutorBase.RunNextOperations(IEnumerator`1 operationEnumerator)",Normal</savestoredvaluescollection>

Operation details:

<operation id="6b3fa541-163f-4dd5-8841-a41841ba4398" plugin="Unify.EventBroker.PlugIn.ADSyncCommit" overridedisplayname="false" displayname="Active Directory Sync Commit">
          <failure retrycount="0" retrywaitperiod="PT10S" successaction="RunNext" failureaction="Stop"></failure>
          <agents></agents>
          <extended></extended>
        </operation>

Having installed the v4 EvB service and corresponding woirkflow activity, then updating the AIC and workflow definitions to correctly reference the latest signature, the workflow appears to run correctly in MIM but does not trigger the operation list corresponding to the configured GUID.  No exceptions are identifiable in any event or service log.

I know that the activity is being correctly referenced by MIM because the UI would otherwise not resolve, and the triggered request would fail.

This behaviour is consistent in both DEV and UAT after the upgrade:

• Incoming Operation List: http://localhost:8080/Operation/OperationList/6613ecf6-a2bb-4a26-bb8b-9913549bb9aa
• Triggered workflow activity configuration:
  • http://d-occcp-im303:59990/EventBroker/EventBrokerManagementStudio.svc
  • ServerNotifications
  • 6613ecf6-a2bb-4a26-bb8b-9913549bb9aa

The v3.2.1 workflow was working as required up until the time of the upgrade.

Are there any other components which need to be changed with this upgrade?

An old problem now appears to be showing up whereby incoming AD operations show the listener momentarily as Running and then Faulted.

I have the AD agent service account configured as svcFIM_MA@client.local instead of client\svcFIM_MA, since this format was previously discovered as necessary to ensure that the listener works properly (as it is in PROD with v3.2.1.3).

Listen Operation - Live 
Active Directory Listen 

However with 4.0.0.0 and the same account configuration, I am now seeing this in both UAT and DEV (for both AD listeners and one of the ADLDS listeners):

Listen Operation - Faulted 
Active Directory Listen 

I have been able to get the UAT ADLDS listener working (no idea why), but not the others.

I have tried changing the agent settings to various combinations of server settings, but to no avail, e.g.

D-OCCCP-DC201:389
D-OCCCP-DC202:389

D-OCCCP-DC201.client.local:389
D-OCCCP-DC202.client.local:389

I am using the SECURE authentication setting with the username svcFIM_MA@client.local (as was configured and working previously under v3.2.1.3)

I have attached a version of the the PS script provided to highlight the approach I took to handle the upgrade while avoiding creation of duplicate AID and WorkflowDefinition objects in my MIM configuration:

ConfigureEventBrokerChangesActivity.ps1

This version checks for the presence of an existing AIC object and updates it.  Then, because we can't automatically be 100% sure that there is an existing workflow, or realistically automate their update, it checks for their likely presence and if found explains the change required.

On running the EvB 4.0.0.0 scheduler for the first time for an upgraded 3.2.1.3 configuration, each operation with a MIM run profile began failing with the following error:

Operation faulted: Attempting to check for exports in non-existent management agent with id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - Please see the log viewer for more details. 

20170814,05:22:04,UNIFY MIM Event Broker,Operations,Error,"Operation Pending Export for Management Agent REDACTED with id REDACTED failed
in the operation list FIM Agent REDACTED with id REDACTED for the following reason. This is retry number 0:
Unify.Framework.UnifyConfigurationException: Attempting to check for exports in non-existent management agent with id REDACTED
   at Unify.Product.EventBroker.MIMAgent.ExportsPendingForManagementAgent(Guid managementAgentKey)
   at Unify.EventBroker.Agents.Audit.MIMAgentAuditingDecorator.ExportsPendingForManagementAgent(Guid managementAgentId)
   at Unify.Product.EventBroker.OutgoingPendingPlugIn.Check()
   at Unify.EventBroker.PlugIn.Audit.CheckOperationAuditingDecorator.Check()
   at Unify.Product.EventBroker.OperationListExecutorBase.RunCheck(ICheckOperationFactoryInformation checkOperation)",Normal

When running the EvB 4.0.0.0 console for the first time in a secure environment, the IE 11 browser raises a dialog saying that http://cdn.userecho.com is untrusted - instead it should be referencing https://cdn.userecho.com

The Event Broker 3.2.1.3 service is logging the following every 2 hours, but I don't have a corresponding schedule configured so I am thinking it must be built-in (???):

20170810,23:54:23,UNIFY FIM Event Broker,Agent Engine,Information,Scheduled job to perform a FIMAgentRefreshRequest on agent FIM Agent succeeded.,Normal

The reason I ask is that every day at the same time (and ONLY at this time) I am getting the following shortly afterwards (which happens to be just before the log rolls over):

20170810,23:54:33,UNIFY FIM Event Broker,OpenLDAPTriggerPlugIn.ResultsCallback.Error,Error,"System.DirectoryServices.Protocols:
System.DirectoryServices.Protocols.DirectoryOperationException: The server cannot handle directory requests.
   at System.DirectoryServices.Protocols.LdapPartialResultsProcessor.GetPartialResults(LdapPartialAsyncResult asyncResult)
   at Unify.Product.EventBroker.OpenLDAPListenPlugIn.ResultsCallback(IAsyncResult result)",Normal
...
20170810,23:56:42,UNIFY FIM Event Broker,OpenLDAPTriggerPlugIn.ResultsCallback.Error,Error,"System.DirectoryServices.Protocols:
System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
   at System.DirectoryServices.Protocols.LdapPartialResultsProcessor.GetPartialResults(LdapPartialAsyncResult asyncResult)
   at Unify.Product.EventBroker.OpenLDAPListenPlugIn.ResultsCallback(IAsyncResult result)",Normal

Every day for as long as the log files are retained, I get exactly the same sequence at almost exactly the same timestamps.

This is confusing because the agents all appear to be working fine for all of the dependent operations, with no errors reported that I can see otherwise.

The following log entry (EvB service version 3.2.1.3) cannot be used to identify the faulting agent:

20170809,23:56:43,UNIFY FIM Event Broker,OpenLDAPTriggerPlugIn.ResultsCallback.Error,Error,"System.DirectoryServices.Protocols:
System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
   at System.DirectoryServices.Protocols.LdapPartialResultsProcessor.GetPartialResults(LdapPartialAsyncResult asyncResult)
   at Unify.Product.EventBroker.OpenLDAPListenPlugIn.ResultsCallback(IAsyncResult result)",Normal

Can the message please be enhanced to identify the agent and/or operation and/or operation list by GUID AND NAME (identification by guid alone creates more unnecessary work in troubleshooting)?

As per the subject, iIf a task is queued, how long after the blocking task has finished executing should the queued? I am seeing instances where the MIM MA Incoming Run Profile runs, blocks the export Run Profile, the Incoming Run Profile run finishes but the export never starts.