Provide Unify EvB license in Base64 Format, rather than binary so that they can be pasted into RDP sessions.  It's often difficult to get these binary files into certain environments. 

Using EvB 4.0, the display name property for a new operation list is not defaulted and the user is forced to enter a value:

1. For an existing Operation List, select New Operation
2. Select Operation Run Profile Operation / click CREATE
3. Select Agent (if more than one agent) / click CREATE
4. Select Management Agent / click CREATE
5. Display Name appears blank with the field box in RED and the warning "The DisplayName field is required."

The behaviour for version 3..2.1 is as above for steps 1-4, but for step 5 we have:

5. Display Name appears with a checkbox, and by selecting the checkbox the default calculated display name could be overridden ... by not selecting this checkbox the default operation name is created, e.g. Management Agent: PHRIS - Run Profile: Delta Import.

The old v3 behaviour of defaulting the operation display name is requested to be reinstated, as this creates unnecessary work for the implementer.  I suspect that the logic to do this is still there, but the UI change to make DisplayName mandatory has ensured that this can no longer fire.

I just logged into EvB at APRA test env & saw that it wasn't running the AD Outgoing Operation as it was queued.  It hadn't been able to run for hours.  It didn't appear to be blocked.  RAM usage was very high.

Does EvB log the reason that it was blocked? I couldn't find any detail in the logs.

Hi I have the following error: 

I followed the requirements  which are in the page: https://unifysolutions.jira.com/wiki/spaces/EB32/pages/93454604/Prerequisites

Firewall: Checked: Able to connect to SQL Server via telnet

• Log on as a service. For details see here; Checked
• Access to write to its Logs directory. Defaults to: Checked FULL CONTROL

  • C:\Program Files\UNIFY Solutions\Event Broker\Services\Logs

• Ability to create the Logs file directory;Checked
• Full update access to the Extensibility directory. Defaults to:  Checked FULL CONTROL

  • C:\Program Files\UNIFY Solutions\Event Broker\Services\Extensibility

• Permission to create a WCF end-point (see Create WCF end-point); Checked 

PS C:\> netsh.exe http add urlacl url=http://+:59990/ user=****\svc_fimeb

Url reservation add failed, Error: 183
Cannot create a file when that file already exists.

• Permission to write to C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files; Checked FULL CONTROL
• Membership in the FIMSyncAdmins group. Checked
• Read permission (db_datareader) to the FIMSynchronizationService database, either for the service account, or a separate SQL authentication login. Checked Created a SQL agent with same connection string. Work perfectly

If installed on the same machine as Microsoft Identity Lifecycle Manager or Microsoft Forefront Identity Manager, the service account also requires the following:

• Read access to the local FIM WMI namespace (overview, Setting Namespace Security)

 Checked FIMSYNCADMINS group full control on MicrosoftIdentityIntegrationServer 

Do you have another ideas about the root cause?

Thanks in advance.

On upgrade to version 4, the existing IIS website for the Event Broker application failed to open due to a permissions error.  This was subsequently resolved by re-enabling Integrated Authentication on the IIS website.

One possibility for the issue might be that the IIS application pool identity (svcFIM_EBrokerWeb) in this case is not configured to be the same identity as the Event Broker service account (svcFIM_EBroker - as specified in the MSI).  However this is only a guess.

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.