Hi Team,

In IDB 4, the Join Transformation has this configuration (see attached screenshot) 

Whereas, in IDB 5 looks like this (see attached screenshot) 

How come in IDB 4 its a - sign between [posstart] and time offset, whereas in IDB 5 its a + sign? What are the difference? Thank you

Regards,
Marc Laroza

When running an import on AD Groups, the objectSid field is defined as a string on the connector schema. SQL can import this field fine (although shows as jargon on the UI). Postgres fails to import with the following error:

Connector Processing page 1 for connector On-Prem Groups failed with reason 22P05: unsupported Unicode escape sequence. Duration: 00:00:08.3359933.
Error details:
Npgsql.PostgresException (0x80004005): 22P05: unsupported Unicode escape sequence
at Npgsql.NpgsqlConnector.<>c__DisplayClass161_0.<<readmessage>g__ReadMessageLong|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Npgsql.NpgsqlConnector.<>c__DisplayClass161_0.<<readmessage>g__ReadMessageLong|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Npgsql.NpgsqlDataReader.<nextresult>d__46.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Npgsql.NpgsqlDataReader.NextResult()
at Npgsql.NpgsqlCommand.<executedbdatareader>d__100.MoveNext()</executedbdatareader></nextresult></readmessage></readmessage>

Changing the field type to 'binary' and attempting an import yields a different error at an earlier stage:

nify.Product.IdentityBroker.EntitySchemaValidationException: Invalid binary - the value was a string, but was not able to be converted as a base64 encoded string from: ??? ? ---> System.FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
at System.Convert.FromBase64_Decode(Char* startInputPtr, Int32 inputLength, Byte* startDestPtr, Int32 destLength)
at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
at System.Convert.FromBase64String(String s)
at Unify.Product.IdentityBroker.EntityBinaryTypeSchemaValidator.CreateValue(Object dataValue)

Hi,

Recently we had an issue come up where the server ran out of disk space while writing the XML config files.

Would we be able to request a feature where the existing file is renamed to a .bak file before writing a new XML file.

If the server runs out of disk space, the file will fail to rename, preventing the mentioned issue.

Thanks

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.

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

Please see attached Broker configuration.  The "MIM LMS Group Users" connector generates records for groups, with a multivalued field "PersonNumbers" that is then used by the "MIM LMS Person" adapter in a Foreign Multivalued Group Transformation to generate the DNs of the groups each user is a member of.  When a group has no members, running an Import All on the connector causes a "Value cannot be null" error to be logged.  If I change the source data to not include any groups with no PersonNumbers data then the error does not occur

As a workaround, I've inserted a dummy value into blank PersonNumbers field values as shown here:

I tried to replicate this issue in a simpler Broker instance, but I could not sorry.

After changing the Required flag for a field in my PowerShell schema script, I re-ran Request Schema and the UI didn't show any fields as changed.  After I Merged Changes the field was not updated, and I had to update the Required flag manually.

It seems a reasonable expectation that a change of any field attribute should be flagged by the UI and applied when Merge is clicked.

I am trying to configure an export flow in MIM for a DN field in UNIFYBroker, and I see this error:

However, when I use LDP.exe to connect to UNIFYBroker via the LDAP gateway I can Add or Replace a DN value in that field successfully, so the limitation appears to be in the UNIFYBroker ECMA2 DLL rather than in UNIFYBroker itself.

Could you please advise if this is the expected behaviour?  If it is then could you comment on why the limitation exists and advise what we should do as a workaround?