As-built of the nature of MIM Documenter and AAD Connect Documenter has long been an expected artifact of the Microsoft Workplace Identity Practice for all MIM and AAD Connect deployments.

Something at least similar to the SuccessFactors default attribute mapping can be generated for our UNIFY* customers as part of handover to BAU, providing a quick reference for both the customer and support alike.

Similar to the checklist developed on the back of the ultimately successful WA Water Lite implementation, this Aurion Pre-installation Checklist contains the necessary steps for a successful implementation UNIFYBroker+ as well as both UNIFYAssure and UNIFYConnect IdAAS flavours.

An updated checklist will now be required for each of the in-flight UNIFYConnect implementations, as well as future Broker+ installations (where the server specs are still required), and apart from the following recommendation needs to be specified by Engineering:

• Correlation IDs are available in all production and non-production Active Directory environments

With the increased focus lately on deployments of the UNIFYAssure/UNIFYConnect/UNIFYBroker+ solution set, recent experience has been that at times it would have been handy to still use UNIFYNow to enhance the operations user experience - even without MIM in the picture, the familiar Operation List concept could apply equally to a Broker+ deployment as it can for MIM sync.

While we may consider pursuing this idea, a better outcome would be to incorporate UNIFYNow features in the UNIFYBroker+ product configuration itself (i.e. not only adding the Locker menu, but also an Operations menu ... sharing the existing Agents/Groups/Logs menus I imagine, and using the Groups concept to simplify the UX.

In scenario where pre/post processing is required (e.g. mailbox provisioning, notifications, workflow-like activities, etc.) such a configuration would undoubtedly be more maintainable and operationally easier to handle than it is without the UNIFYNow model we enjoy today for MIM solutions with similar out-of-band integration.

I deleted a Connector Group in UNIYFBroker (using the Web UI) and now the API returns an invalid ID in the ConnectorGroups array in the response to Connector/GetConnector for a Connector which used to be a member of that group.

Using the latest UNIFYBroker release.

At the UNIFYBroker site I am presently working on there are now 7 Broker-driven management agents for MIM, most of which interact with multiple adapters.  I have found that it starts to get unwieldy when it a single schema change in a single connector requires a schema/interface refresh of all 7 management agents.  Furthermore, when deploying MIM sync configuration and using the schema matching dialog, there is a need to deselect all of the adapters (LDAP partitions) which are not relevant to each particular MA, complicating the deployment process.

It would be great if there was a way to limit visibility of the UNIFYBroker adapter set on a per-management agent basis - and the most obvious way I could think of achieving this would be by using multiple LDAP user accounts, and extending the Settings page to support mutli-selection of adapters per LDAP user.  In this way, adapters visible to any given MIM MA would be determined by the use of an appropriate user account - rather than the current practice of using the same LDAP user for every MA.

This would address both of my above scenarios as follows:

1. A single connector schema change would potentially limit the need for schema refreshes to a single MA; and
2. Partitions not visible to the LDAP account would no longer appear on the partition matching dialog, and in most cases this would reduce the number of partitions requiring deselection (and in many cases eliminate the partition matching dialog being displayed altogether) when importing MIM sync server config XML.

Hi guys,

I have multiple Chris21 connectors failing in a customer system with the following error when running a full import:

My initial thoughts were that this was a problem with Chris21. But I have had the customer run the GTR query directly against Chris21 and it has received no such status failed messages.

The customer had recently upgraded to Chris21 version 8.19.10. Identity Broker version is 4.1.1 and Chris21 Connector version 4.1.1.0. Version upgrades were undertaken on the 12/05 and completed on the 14/05, however the issue was only recently raised so we weren't able to grab logs before these date's to see if it was an active issue.

The customer has pointed out that one field has been renamed on one of the forms but this field is not used in the schema in Idb.

Before this the agent and connector was displaying this error which we fixed by setting the interface in Chris21 to "Default":

Not sure if it is related but I thought it would be helpful as to understanding the full scope of the problem.

Would anyone be able to shed any light as to why this could be happening?

Thanks, Liam

Hi All,

I am currently assisting a client with an issue in UNIFYBroker, whereby a Google Group connector, is reporting a duplicate account error for some users when trying to added them to google groups. We can inspect the groups manually in google and these groups definitely do not contain these users. Being unable to find a root cause for the issue in Broker/MIM, the client raised a ticket with Google and received the following response:

Thank you for contacting Google Cloud Support. I understand that you are not being able to add an address to one of your Groups as you are getting a message that the address has already been to the Group.

I reviewed the information you provided on the chat and did the checks we do in this cases. The reason you are not able to add the external address is because the address you are trying to add is either an alias, a contact or a recovery address for a Google account. The system has the Google account already associated to the Group and since the system already knows the main account is already added it does not let you add it again. In this case you will need to contact the external user and ask for an alternate address they may have and check if that address is already on the Group. The other address is already receiving the messages sent to the Group.

Not being able to find a solutions around this within Broker and MIM I was hoping you may be able to take a look and see if you can spot anything we may be missing here.

This issue has quite a big of attention within the client environment as key people are missing out on important Covid-19 information. The current work around is listed in Google's response, however this often takes weeks to remediate.

Let me know if you need any further information.

Thanks

Currently have a client getting errors on all exports to a Broker (5.3.1) adapter (ma-extension-error).

Happening on adds,updates,deletes

Not much in the way of messaging provided except for the following after each attempt at export:

The extensible extension returned an unsupported error.

The stack trace is:

"System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.

at System.ThrowHelper.ThrowKeyNotFoundException()

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

at Unify.Product.IdentityBroker.ExportProxy.EntryToModifyDNRequest(CSEntryChange entry)

at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()

at Unify.Product.IdentityBroker.ExtensionMethods.Take[TSource](IEnumerator`1 source, Int32 count, IList`1& items)

at Unify.Product.IdentityBroker.ExtensionMethods.d__3`1.MoveNext()

at System.Linq.Enumerable.d__5`2.MoveNext()

at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)

at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

at Unify.Product.IdentityBroker.BulkUpdateRequest.Send(Func`2 send, Func`2 recv)

at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)

at Unify.Product.IdentityBroker.ExportProxy.GetBulkRequestResult(BulkUpdateRequest request)

at Unify.Product.IdentityBroker.ExportProxy.BulkExportEntries(IList`1 csentries)

at Unify.Product.IdentityBroker.ExportProxy.Export(IList`1 csentries)

at Unify.Product.IdentityBroker.UnifyLdapConnector.PutExportEntries(IList`1 csentries)

Forefront Identity Manager 4.5.412.0"

I have an adapter with the following transform:

This transform works as expected in both directions, but when an update comes from the LDAP gateway to delete the DN value that LDAP request is successful, but the old values for the DN (SubsectionDN) and the source attribute (Subsection) are retained.

Hello,

I have been tracking this issue for a few weeks within an environment. And what I have been noticing is the performance of the UNIFYBroker service deteriorating over time. While there is an existing work around, it would be good to find the root cause of this, whether it be a poorly configured item somewhere or an underlying issue.

Currently in the environment we notice the service become slower, at a minimum, over the course of about a week. It will gradually take sets of operation lists longer and longer to run. More specifically this will be worse on Monday after all the Full Baseline operations run over the weekend. And then gradually get even worse from there. The only correlation I can see so far is during the times it is running slow, is the service will be using upward of 5GB of ram, even getting to over 10GB if left unattended for longer than a week. It will retain these high levels of memory usage even while no operations are running. The only way to resolve the issue, is to restart the service, which currently happens on a Monday every week.

The environment is quite large with a Broker instance that manages over 1 million entities. However the server (both local and DB) has the specifications to deal with the load. Please see these below. It is also worth noting here also that to eliminate concurrency issues, the scheduling is setup to run everything sequentially (i.e UNIFYNow will step through each operation one at a time and no two operations will run at the same time both in MIM and UNIFYBroker).

Broker Server Specs:

CPU: 16 cores

Memory: 32GB

DB Server Specs:

CPU: 12 cores

Memory: 48GB

Although I haven't gathered this information for previous weeks, I have noticed some strange occurrences this morning and have documented them below:

• Old LDAP Gateway connection that has not been closed:
• 
• Large number of SQL Connection to the UNIFYBroker DB:
• 
• High service memory usage while nothing is running (as mentioned before)
• 

I will attach the logs and additional information below. Also in the logs below I have included information on the DB connections both before and after recycle the LDAP Gateway. But also note that recycling the LDAP Gateway also had no effect on the memory usage of the service. Let me know if there was anything else I can do to assist.

UNIFYBroker: v5.3.1