Thanks for the feedback, Michael.

In the particular case of case of creating a connector with no available agents, the UI does direct you to create an agent, however it doesn't direct you back to the connector afterwards.

This would be quite difficult to implement currently, but we are planning an overhaul to the UI in an upcoming release, so I will add this to the list of desirable workflows that it should support.

This issue is most commonly caused by "broken" connections - connections between locker entities and adapter entities where the adapter entity has since been deleted, and the connection wasn't properly deleted.

You can find such entities with a SQL query like

SELECT *  
FROM [Connections] [c]
LEFT JOIN [Entity] [e] ON [c].[AdapterEntityId] = [e].[EntityId]
WHERE [e].[EntityId] IS NULL
AND [c].[LinkId] = 'your-link-id'

Deleting any connections identified by that with the following query should resolve the issue.

DELETE  
FROM [Connections]
WHERE [ConnectionsKey] IN (
    SELECT [ConnectionsKey]
    FROM [Connections] [c]
    LEFT JOIN [Entity] [e] ON [c].[AdapterEntityId] = [e].[EntityId]
    WHERE [e].[EntityId] IS NULL
    AND [c].[LinkId] = 'your-link-id'
)

Alternatively, clearing the adapter context and re-generating the entities should clear up the connections.

We will need to investigate the cause of the broken connections.

No, as there was no requirement to be able to query it directly. See http://voice.unifysolutions.net/topics/2929-auditing/ for details on how to keep track of this information (among other changes).

Hi Tom,

In cases where both the existing value and the new value in an update are both from un-prioritised sources, the newest value (the update) is taken - last write wins.

The base script that I'd recommend starting with and adapting is as follows. It can be run unlimited times without duplication as it checks for users in AD that haven't been enabled. This particular script uses the default Exchange rules for mailbox name, but can be adapted by changing the arguments supplied to the Enable-Mailbox command:

# STEP 1
#   The first step involves securing the password to Exchange.
#   The following command should be run in a PowerShell console, changing the out-file to the desired location:
#     read-host -assecurestring | convertfrom-securestring | out-file C:\securestring.txt
#   Enter the password to Exchange. A file should be written to the desired location.
#   If a permission error was shown, try running the script as administrator, or select a new location.
# STEP 2
#   Configure the following settings:
#     ExchangeServer - Configure the URL to the PowerShell virtual directory on the Exchange machine.
#     AdminAccount   - The name of the account being used to connect to the Exchange machine.
#     SearchBase     - The deepest container that holds all items being managed.
#     Filter         - The LDAP filter to select items that have not been mail enabled. This will probably not need to be updated.
#     Password       - The file path should be updated to the file created in STEP 1.
$ExchangeServer = http://exchange/PowerShell/
$AdminAccount = "DOMAIN\Administrator"
$SearchBase = "OU=RootContainer,DC=organization"
$Filter = "(&(objectCategory=user)(objectClass=user)(!msExchHomeServerName=*))"
$Password = cat C:\securestring.txt | convertto-securestring
# END OF CONFIGURABLE SECTION #
$UserCredential =  New-Object -Typename System.Management.Automation.PSCredential -Argumentlist $AdminAccount,$Password
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $ExchangeServer -Authentication Kerberos -Credential $UserCredential
Import-PSSession $Session
Add-Type -Assembly Microsoft.ActiveDirectory.Management
Import-Module ActiveDirectory
$users = get-aduser -LDAPFilter $Filter -searchbase $SearchBase -searchscope "Subtree"
if ($users -ne $null) 
{
    foreach ($user in $users)
    {
        Enable-Mailbox $user.SamAccountName | Set-Mailbox -SingleItemRecoveryEnabled $true
    }
}
#Exit-PSSession
Remove-PSSession -session $Session

Hi Daniel,

They relate to how often it checks for changes in adapters. The basic process is as follows:

1. Connector import (manual or scheduled)
2. Change detection process detects changed connector entities
   1. Entries created in changes register to indicate connector entities which have changed
3. Reflection runs (scheduled every few seconds), processes changed connector entities and updates adapter entities
   1. Entries created in sync changes register to indicate adapter entities which have changed
4. Synchronization runs (manual or scheduled), processes changed adapter entities and updates locker entities

Do we have schemas for the Chris21 forms somewhere?

Yes, it's one of our most widely used connectors, check out any of the other projects or fire up a demo machine.

Does IdB plus have a concept of initial flow only? For password

Yes, for connectors that support password sync they often have a concept of an initial password script.

For provisioning mailboxes via IdB plus, would I just write a PowerShell script in the post-provisioning step? Does post-provisioning only run on creation or also on synchronisation?

https://unifysolutions.jira.com/wiki/display/IDBPLUS51/Tasks

How does syncing the manager attribute to AD in IdB Plus work? Do I generate a DN in the transformation and flow that or is there something special with reference attributes especially to do with the order of provisioning (manager not provisioned/joined yet but a reference is flowed)?

This has been done before, check out another solution.

What triggers a synchronisation on a specific user? Because in Chris21 the manager is in a position and if the person filling that position changes it will need to update the manager attribute on all users whose manager just changed.

https://unifysolutions.jira.com/wiki/display/IDBPLUS51/Synchronization

I'm also not sure where DN calculation should take place since it needs to be ensured unique. Do I have access to the entities in a pre-provisioning script like I have in a PowerShell adapter transformation so that I can check for uniqueness then set it back to the entity and have that flow out on provision? Same for sAMAccountName.

https://unifysolutions.jira.com/wiki/display/IDBPLUS51/Tasks