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.

Converted to topic from comment on https://voice.unifysolutions.net/knowledge-bases/7/articles/2937-installing-the-unifybroker-service#

It seems the account that you run the installer needs permission to create the database. The installer does not use the service account to do this, even when you select the Service Account in the Authentication screen when attempting a new install of the database.

At a customer site there's a problem with the IDB Requirement for Name Pipes protocol in SQL. Named Pipes doesn't support some of the High Availability stuff they're doing and they're also critical of Named Pipes being a 2008 technology that has been superseded by TCP/IP. They want to at least turn named pipes off after installation. Is this supported? IdB seems to be functioning with Named Pipes turned off post installation.

I need to set a user's account name when provisioning via Broker/Plus, but then flow that value back in from AD subsequently (so the value is picked up when joining to an existing AD account, and so that if the username can be changed in AD it will be automatically updated in Broker).

Can you please confirm whether or not the approach below will work, and advise if there is a better way to do it?

1. Set the Link mapping on the AD->Locker to Bidirectional for the AD username field
2. Set a value for the attribute in the Outgoing Pre-Provisioning Task