I am using Broker/Plus to only join to objects from Aurion to AD, and not to provision (i.e. Outgoing Provisioning is disabled).  For a user in Aurion (with corresponding Locker record) where there is no corresponding AD record (i.e. the join criteria are not met for any existing AD adapter objects) the Link still reports an Outgoing Change for that object.

I have 7 Lockers:

I have four users in AD:

When I run a Baseline Synchronization on the AD Link, I see this:

Note that there are 7 Outgoing Changes, even though there are only 4 objects in the AD Adapter, and Provisioning is disabled so it should not be provisioning new ones.

Log file attached:

UnifyLog20190624.csv

In Broker/Plus, outgoing provisioning tasks are run even when the outgoing provisioning flag is disabled.

That task can be used for out of band provisioning operations.  Since the configuration flag only turns off object provisioning via the target adapter (and not any out-of-band provisioning activities that the task performs) the flag isn't as useful as it could be and the flag operates in a manner that may be contrary to user expectations.

When I run 'Request Schema' on the Broker/AD connector, the 'accessExpires' AD attribute does not appear.

How do I add this attribute to my connector so that I can synchronise it in Broker/Plus?

We are seeing unwanted/impacting behavioural variations in the IdB5 adapter data when compared with the legacy IdB4 adapter for the same JadeStar record.

When values are missing in the connector they are (correctly) not being surfaced in the IdB4 adapter, but are being surfaced as empty strings in IdB5.

Here is an example of the problem, as exposed for employee 500015 via LDP:

ld = ldap_open("localhost", 389);
Established connection to localhost.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)

-----------
res = ldap_simple_bind_s(ld, 'MIM_ReadWrite', <unavailable>); // v.3
Authenticated as: 'MIM_ReadWrite'.
-----------
Expanding base 'CN=500015,OU=JadeStar,DC=IdentityBroker'...
Matched DNs: CN=500015,OU=JadeStar,DC=IdentityBroker
Getting 1 entries:
Dn: CN=500015,OU=JadeStar,DC=IdentityBroker
CellphoneCountryCode: <ldp: binary="" blob="" 0="" bytes="">; 
CellphoneNumber: <ldp: binary="" blob="" 0="" bytes="">; 
CellphonePrefix: <ldp: binary="" blob="" 0="" bytes="">; 
DDiCountryCode: +64; 
DDiNumber: 222 4456; 
DDiPrefix: 4; 
DepartmentCode: 260526; 
DepartmentDescription: External Retail Network; 
DepartmentJadeCode: 1476; 
DeskNumber: <ldp: binary="" blob="" 0="" bytes="">; 
DivisionCode: SAS; 
DivisionDescription: Sales and Service; 
DivisionJadeCode: 30; 
DivisionSubCode: RETAIL CHANGE; 
DivisionSubDescription: Retail Change and Agencies; 
DivisionSubJadeCode: 225; 
EffectiveDate: 20190601000000.000Z; 
EmailAddress: <ldp: binary="" blob="" 0="" bytes="">; 
EmployeeNumber: 500015; 
EmployeeStatus: <ldp: binary="" blob="" 0="" bytes="">; 
EmployeeType: Temporary; 
EmploymentEndDate: 25000101000000.000Z; 
EmploymentStartDate: 20190601000000.000Z; 
ExpiryDate: 25000101000000.000Z; 
Extension: <ldp: binary="" blob="" 0="" bytes="">; 
FaxCountryCode: <ldp: binary="" blob="" 0="" bytes="">; 
FaxNumber: <ldp: binary="" blob="" 0="" bytes="">; 
FaxPrefix: <ldp: binary="" blob="" 0="" bytes="">; 
FirstName: Indiana; 
Function: <ldp: binary="" blob="" 0="" bytes="">; 
Initials: IM; 
JobFamily: <ldp: binary="" blob="" 0="" bytes="">; 
Level: <ldp: binary="" blob="" 0="" bytes="">; 
LocationCode: WN 20 Customhouse Quay; 
Manager: CN=852206,OU=JadeStar,DC=IdentityBroker; 
MiddleName: <ldp: binary="" blob="" 0="" bytes="">; 
objectClass: employee; 
OccupancyEndDate: 25000101000000.000Z; 
OccupancyStartDate: 20190601000000.000Z; 
OccupancyType: Std; 
OID: 7878.93689; 
OrganisationLevel: 0; 
OU: JadeStar; 
PositionCode: K2A-0012; 
PositionName: Agent Manager - Kiwibank Thorndon Sth; 
PositionOccupancyReportsToEmployee: 852206; 
PositionOccupancyReportsToName: Andrew Holford; 
PreferredName: Indiana; 
PrimaryOccupancyIndicator: TRUE; 
PrimaryPositionIndicator: FALSE; 
ReportsToEmployee: 852206; 
ReportsToName: Andrew Holford; 
ReportsToPositionCode: K2-4666; 
ReportsToPositionName: Commercial and Contracts Manager; 
StandardHoursFortnight: 80.00; 
subschemaSubentry: CN=JadeStar,cn=schema; 
Surname: Manager; 
TeamCode: EXT RETAIL NETWORK; 
TeamDescription: External Retail Network; 
TeamJadeCode: 10837; 
Title: <ldp: binary="" blob="" 0="" bytes="">; 
UserID: <ldp: binary="" blob="" 0="" bytes="">; 

-----------
</ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></ldp:></unavailable>

The above record shows "0 bytes" for a large number of attributes, as opposed to no value at all (NULL) which is what both myself and the legacy FIM rules extensions had expected.

The FIM data imported in LDIF format from IdB4, however, shows no data in these fields at all (i.e. correctly interpreting null values in the adapter).

dn: CN=500015
objectClass: person
IdBID: 65b70aac-4666-4396-9b95-0bcb33803c53
FaxCountryCode: 
EmailAddress: 
LocationCode: WN 20 Customhouse Quay
ReportsToEmployee: 852206
Initials: IM
DDiNumber: 222 4456
PreferredName: Indiana
EmployeeNumber: 500015
EmploymentStartDate: 2019-06-01T00:00:00.000
Extension: 
FaxNumber: 
ReportsToName: Andrew Holford
MiddleName: 
CellphonePrefix: 
FaxPrefix: 
EmployeeStatus: 
CellphoneCountryCode: 
OID: 7878.93689
Title: 
CellphoneNumber: 
DDiCountryCode: +64
Surname: Manager
FirstName: Indiana
DeskNumber: 
EmploymentEndDate: 2500-01-01T00:00:00.000
DDiPrefix: 4
UserID: 
EmployeeType: Temporary
DepartmentCode: 260526
DepartmentJadeCode: 1476
DivisionCode: SAS
DivisionJadeCode: 30
DivisionSubCode: RETAIL CHANGE
DivisionSubJadeCode: 225
OccupancyEndDate: 2500-01-01T00:00:00.000
OccupancyStartDate: 2019-06-01T00:00:00.000
OccupancyType: Std
PositionCode: K2A-0012
PrimaryOccupancyIndicator: True
PrimaryPositionIndicator: False
PositionOccupancyReportsToEmployee: 852206
PositionOccupancyReportsToName: Andrew Holford
StandardHoursFortnight: 80.00
TeamCode: EXT RETAIL NETWORK
TeamJadeCode: 10837
DepartmentDescription: External Retail Network
DivisionDescription: Sales and Service
DivisionSubDescription: Retail Change and Agencies
EffectiveDate: 2019-06-01T00:00:00.000
ExpiryDate: 2500-01-01T00:00:00.000
Function: 
JobFamily: 
Level: 
OrganisationLevel: 0
PositionName: Agent Manager - Kiwibank Thorndon Sth
ReportsToPositionCode: K2-4666
ReportsToPositionName: Commercial and Contracts Manager
TeamDescription: External Retail Network
Manager: CN=852206

Given the problematicdata includes fields such as CellphoneCountryCode from the base connector (i.e. untransformed), can the above behaviour be traced back to a problem with the IdB5 version of the JadeStar connector that can be easily corrected in the one place please?

TIA

I'm not sure that this is really a product issue but raising a ticket in case this has been encountered before. I've connected to a cloud instance of Aurion. The agent Test Connection returns correctly but when I try to import on the Person or Employee connectors, I get a schema validation warning with a warning in the error log "The entity <null> (GUID) in the connector Aurion Employee failed validation 1 times for the following reasons: EmployeeNumber is a required and is not present". Same thing on the person connector but I get it for PersonNumber. The query has been scoped to one user for testing. When we run the report in the Aurion App we can see the PersonNumber in the XML. I tried turning on the trace logging in the exe config but it's not outputting any files, is this because the connection is https? It seems the report is running but either has no data at all or the key field just isn't populated. Any ideas?

What do I need to do with a web service URL that is https? I'm assuming I'll need a certificate installed somewhere. Do I just need to install it to the machine where broker is running? Is there anything else I need to do to communicate over https?

I will attach the Extensibility files.  This used to work, but some configuration change has caused it to stop working now.  Reverting is not an option as there have been many changes and this project is under time constraints to deliver ASAP.

In my Broker/Plus environment (based on UNIFYAssure for Aurion) I am trying to synchronise the manager attribute to AD but seeing the following error:

My configuration has an Aurion connector/adapter -> Link -> Locker -> Link -> AD connector/adapter in a standard setup.

The Manager attribute in the Aurion adapter is calculated via a DN join:

Here's an example, looks correct.

I synchronise the Manager attribute from the Aurion Adapter to the Locker:

It looks correct in the Locker:

Then from the Locker to the AD Adapter:

Here's the AD Adapter configuration:

When I attempt a Baseline Synchronisation on the AD Link this is what I see, and the error above appears in the log file:

Can you please tell me what I need to do to get the synchronisation of the manager attribute to work correctly from the Locker to the AD Adapter?

When a provisioning task fails in a Broker Plus Link due to a PowerShell error, the information written doesn't indicate which provisioning task failed, which line the error occurred on, or which entity was being processed.

It would be extremely helpful for debugging to know which provisioning task is the source of the error and which line is executing when the error occurs.

It would also be helpful to know which entity is being processed, but given that the PowerShell script loops over objects internally this information is not automatically available to the calling engine.  In order to help with this I suggest adding a function which allows the PowerShell script to (optionally) indicate when it starts and finishes processing an entity, in order to allow Broker to include that information in the log entry.

i.e.

foreach ($joinedEntity in $joinedEntities)
{
    # Tell Broker which entity we're working on
    $personNumber = $SourceEntity["PersonNumber"].Value
    $username = $SourceEntity["sAMUsername"].Value
    $logger.setIdentifier("Person $personNumber ($username)")

    # Process the entity
    $isTerminated = $joinedEntity.SourceEntity["Terminated"].Value
    $joinedEntity.TargetEntity["isTerminated"] = $isTerminated -eq "True"

    # Tell Broker we're finished processing the entity
    $logger.resetIdentifier()
} 

This page 

https://voice.unifysolutions.net/knowledge-bases/7/articles/2942-configuring-unifybroker-for-use-with-embedded-web-server

says that using the embedded server as of v5.2 is deprecated. Is this correct? If so, can we get some kind of company announcement about something like this because I've just installed without IIS at a client and told them we wouldn't be using IIS.