I know this is somewhere on the roadmap, but I thought I'd give you a specific example of how I would like to use this to lookup the Operation List name for a corresponding guid from within a PowerShell script. I know this method exists on the WCF endpoint because it is exposed in the WSDL. However it is not a simple exercise to access this from PowerShell.

For the time being I have a work-around which relies on looking up the Event Broker registry key to determine the extensibility file path, then querying the operations extensibility xml directly. However the limitation here is that this will only work if the script is running locally on the Event Broker service host.

Just upgraded UNIFYNow (4.0.0.1 to 4.0.4.0) after upgrading broker (5.2.0.2 to 5.3.2.0) and alot of the UNIFYNow operations lists that are supposed to trigger IDB operations lists are failing all with the same error. 

When an OU is configured for an AD agent that is NOT the domain root (e.g. "OU=Employees,DC=mim2016,DC=local") we get the following exception when the generated incoming operation list is activated:

Operation faulted: The server is unwilling to process the request. - Please see the log viewer for more details.

This is because the AD Sync Changes check operation uses the full DN for the "Domain" property instead of the DC part only (i.e. "DC=mim2016,DC=local").

To avoid this error the AD sync changes operation needs to extract the DC DN from the full DN supplied.

Presently the TO address supports only a single target email address. However this field is multi-valued in the sendmail API and the logger could easily be extended to support this. There is no tooltip on this field so it was not intuitive that this restriction applied - however attempts using "," and ";" delimiters both failed. Work-arounds include setting up multiple loggers, or using a distribution list. However there are times when this would still be handy - especially when d-lists are not easily modified or the requirement is only temproary.

With the release of Ryan Newington's latest Lithnet miis-powershell module it occurred to me that it may be possible in some scenarios (e.g. full imports vs. delta imports) to leverage the progress bar idea for the Event Broker console.

The native AD MA for the FIM Sync service has long had an optional configuration section for preferred DCs, so that administrators can nominate an ordered list of preferred DCs to connect to for imports/exports. When this is used with Event Broker, especially in forests where there are delays in AD replication between DCs, the result can be that Event Broker detects a change before it is replicated to the DC from which FIM is connecting. This generally results in a missed change.

A feature to configure the AD agent exactly in line with that in the corresponding AD MA is suggested here.

In attempting to upgrade an existing UNIFYNow site to work with the latest AAD Connect version, I found that the microsoftidentityintegrationservice WMI namespace was missing.  This was preventing the successful creation of an AAD Connect agent for the new AAD Connect host.

After locating articles on how to restore this namespace, I found this reference which stated "... the deprecated WMI endpoints for MIIS_Service have now been removed ...".  Furthermore, the local ADSyncAdmins, ADSyncBrowse, ADSyncOperators and ADSyncPasswordSet groups no longer exist - these being the security roles associated to the WMI namespace.

Guidance in the above reference is now this: "Any WMI operations should now be done via PS cmdlets"

Does this mean that UNIFYNow will not support AAD Connect from version 1.4.18.0 onwards, or is work underway to change the agent to connect via PS?

Microsoft has just published this MIM article which explains how to configure the MIM Sync and Server service accounts to be gMSA (ones that don't require passwords).

To make for a more compelling business case to leverage this at MIM sites it would help if UNIFYNow (and UNIFYBroker for that matter) also supported gMSA.  This would help simplify MIM/Broker deployments at customer sites.

Can we please have this feature request put forward for consideration?

Hello,

After a recent upgrade to UNIFYNow 3 days ago, after this the service was working fine for some time and confirmed last night still working as expected. Though this morning when attempting to create sub operations (i.e check operation/schedule/listen operation/operation) I get presented with the following error:

Unify.Framework.UnifyCommunicationException: The service client does not implement the IEventServiceClient type.
at Unify.Framework.Web.UnifyController.GetClient[TServiceClient]() in C:\agent\_work\69\s\Source\Web\Unify.Framework.Web\Extensions\UnifyController.cs:line 59
at Unify.EventBroker.Web.OperationController.<.ctor>b__103_1(UnifySiteMapNode node, UnifySiteNodeAttribute attribute, RequestContext context, IDictionary`2 dynamicValues, RouteData data, NameValueCollection postData, NameValueCollection queryString) in C:\agent\_work\86\s\Source\Unify.EventBroker.Web\Controllers\OperationController.cs:line 307
at Unify.Framework.Web.UnifySiteMapProvider`2.UpdateNodeForRequest(TNode node, TNodeAttribute nodeAttribute, RequestContext requestContext, IDictionary`2 dynamicValues, RouteData routeData, NameValueCollection postedData, NameValueCollection queryString) in C:\agent\_work\69\s\Source\Web\Unify.Framework.Web.SiteMap\UnifySiteMapProvider.cs:line 150
at Unify.Framework.Web.UnifySiteMapDynamicTree`2.UpdateParentForRequest(TNode parentNode, RequestContext globalRequestContext, IDictionary`2 dynamicValues, RouteData& childRouteData, NameValueCollection& childPostData, NameValueCollection& childQueryString, MethodInfo& childAction, UpdateNode`2 updateNode) in C:\agent\_work\69\s\Source\Web\Unify.Framework.Web.SiteMap\UnifySiteMapDynamicTree.cs:line 291
at Unify.Framework.Web.UnifySiteMapDynamicTree`2.FindNodeAndUpdateBranch(HttpRequest request, UpdateNode`2 updateNode) in C:\agent\_work\69\s\Source\Web\Unify.Framework.Web.SiteMap\UnifySiteMapDynamicTree.cs:line 222
at System.Web.SiteMapProvider.FindSiteMapNode(HttpContext context)
at System.Web.SiteMapProvider.get_CurrentNode()
at Unify.Framework.Web.UnifySiteMapExtensions.DecorateForm(HtmlHelper htmlHelper, Func`1 form, String submitText, String formId, String title, String name) in C:\agent\_work\69\s\Source\Web\Unify.Framework.Web.SiteMap\UnifySiteMapExtensions.cs:line 50
at ASP._Page_Views_Operation_CreatePlugInOperation_cshtml.Execute() in c:\Program Files\UNIFY Solutions\Event Broker\Web\Views\Operation\CreatePlugInOperation.cshtml:line 16
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
at System.Web.WebPages.StartPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass1e.b__1b(IAsyncResult asyncResult)

There are no additional logs produced in the application log or the even viewer logs.

The version of UNIFYNow is v4.0.4. I have checked the other environments and they are not affected by the issues. Any help is greatly appreciated.

Thanks