Identity Broker Forum
Welcome to the community forum for Identity Broker.
Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.
How do I delete an entity in a Powershell connector?
The issue is on a Delta import - we can detect that an object has been deleted from the connector system (LDAP) but I can't delete the entity in IdB. (I think a Full Import will but I wanted this to work on the Delta).
The example on this page https://unifysolutions.jira.com/wiki/display/IDB50/PowerShell+Connector under "Delete Entities" is either missing something, or it's about exports.
Hi Carol,
Let me start by clarifying a few more points about the PowerShell connector. The Import All, Import Changes (for the "Entity" Import Changes Method), Request Changes and Get Entities (for the "Entity Id" Import Changes Method) are all import scripts. Import scripts are run when the Identity Broker connector's Import All or Import Changes operations are triggered.
The Add Entities, Updates Entities, Delete Entities, Delete All Entities and Change Password scripts are all export scripts. Export scripts are run when an IDM (e.g. FIM) sends adds/deletes/updates (e.g. during a FIM Export run step) to the relevant Identity Broker adapter via the LDAP endpoint. To avoid confusion with FIM's Full Import and Delta Import operations, please refer to IDB operations as Import All and Import Changes, as they are not part of the same process.
I'll give an example of deleting entities during a PowerShell connector Import Changes operation. The connector schema has two fields, ID (the key) and Name, and assume there are 5 entities in the connector context with IDs 1 through 5.
This is the Request Changes script:
function Get-UpdatedKeys
{
return 1, 2, 3, 4, 5, 6;
}
foreach ($key in Get-UpdatedKeys)
{
$changedKey = $keys.Create();
$changedKey['ID'] = $key;
$changedKey.Commit();
}
This indicates that all 5 entities have been changed, and a previously unknown entity (with ID 6) has also been changed.
This is the Get Entities script:
function Get-EntityByKey
{
param ($key)
if ($key -eq 3) { return $null; } # let's say entity with ID 3 is deleted
return @{Key = $key; Value = "Value$key"};
}
foreach ($key in $components.InputKeys)
{
$changedEntity = Get-EntityByKey $key['ID'];
if ($changedEntity -eq $null)
{
# don't commit, deleted
continue;
}
$entity = $entities.Create();
$entity['ID'] = $changedEntity['Key'];
$entity['Name'] = $changedEntity['Value'];
$entity.Commit();
}
This iterates over the changed keys returned by the Request Changes script and retrieves the corresponding entities. If the entity is not flagged as deleted (Get-EntityByKey returns $null), then the entity is commited, otherwise it's ignored and the entity will be deleted from the connector space automatically by IDB. In this case, the entity with ID 3 would be deleted, the entity with ID 6 would be added, and the other entities would be updated.
Get a current entity count from Import script
Is there a way to get a current count of entities in the Connector from a Powershell Connector Import script? I would like to add a check on the number of objects I've discovered, before I start adding or updating entities.
Hi Carol,
In testing, I'm also finding some strange behaviour in counting EnumerableQueryable. I'm no PowerShell expert, but the only reliable way that I've found so far to do this is to wrap it in @(), i.e. @($components.ContextEntities).Count, but note that this most likely involves enumerating the entire context into an array, so I wouldn't advise it if you expect a very large number of entities.
ma-extension-error on Export from FIM
I need some help troubleshooting an ma-extension-error. I am exporting changes from FIM through IdB 5 and out through a Powershell connector and every export shows ma-extension-error in FIM. When you check the details it just says "unexpected-error".
In IdB I can see the Powershell "Update" script is running all the way through to the final line (which logs a completion message in the IdB logs). Everything is in try/catch blocks with error logging, and there are no errors at all being reported. I've put in a lot of information logging and everything seems to be running fine in the script.
The IdB logs don't have any errors at all from the time the export ran. Because FIM thinks the export failed it keeps re-queuing the export.
Any idea what could be causing this error to be reported in FIM?
Thanks Carol, Glad to hear you were able to resolve this issue.
It's disappointing that errors raised during the PowerShell connector export script weren't logged, I've added a bug to the backlog to improve the feedback for this.
Force connector delta import to run after export
I want the delta import to run immediately after the export without having to schedule it to run on its own. Is there a way I can trigger the delta import from the end of the Export script?
I did see something on the Google Apps Connector topic about import-after-export but can't see any such setting in the IdB 5 UI.
This is possible using the REST endpoint. Use the same operation that EB uses to trigger an import. Unfortunately Confluence is down at the moment so I can't link it.
This feature is on the Google Apps connector for quite a specific reason - as the v4.1 connector can export without waiting for the result, the import needs to run afterwards. It's not in v5.0 as batched exports make it unnecessary.
Let me know your use case if you would like a more generic feature to be added to Identity Broker.
How is $components.InputEntities populated?
I have an IdB Powershell connector talking to Office 365. One of the IdB schema attributes is “Alumni” (Boolean flag). I populate this on import from O365, so it’s not something that is flowing from FIM. (There are reasons why it has to be like this to do with AADSync delay.)
Question is: if entity[‘Alumni’] has been changed on Import, will this cause the entity to be part of the $components.InputEntities when the Update script runs on export?
I know if the change comes from FIM via the Adapter it will be in that collection – just want to understand what happens if the change came from the Connector instead.
I'm going to get around it by setting a Boolean value to 'true' on connector import if certain conditions are met. FIM has a constant export flow which sets the flag back to 'false' - so this should ensure the object is included in $components.InputEntries to the Update script.
MIM2016 and IdB5 using the Microsoft Generic LDAP Management Agent
Congratulations to the UNIFY PG for an outstanding job with IdB5. I haven't had a chance to use it in anger until this weekend just gone, and it was everything I hoped it would be. My goal was to set up a dummy HR connector to create a suitable platform to run my MIMTeam demo on 14th of April, and I was able to reuse some libraries from another project to rapidly build a PowerShell connector to a Mockaroo.com JSON webservice for 1000 random users (with controllable set of reference data).
I am almost finished the demo build and just wanted to say thanks - it's awesome how well this looks and works - particularly given I didn't really know what I was doing when I created the LDAP MA instance and pointed it to IdB5's LDAP service for the first time. Schema discovery meant that I could do refresh/rediscover multiple times as I built up the concepts. Performance is great, and flexibility is outstanding - looking forward to showing this off (just quietly).
Identity Broker dropping connector space
The PS script for importing all users from 0365 sometimes errors with the following:
Import all entities from connector failed.
Import all entities from connector Office 365 Staff Licenses failed with reason An unexpected error occurred.. Duration: 00:00:06.8594919
Error details:
Microsoft.Online.Administration.Automation.MicrosoftOnlineException: An unexpected error occurred.
at Unify.Product.IdentityBroker.PowerShellConnector.<GetEntitiesInScript>d__a.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at Unify.Framework.Collections.ActionOnExceptionEnumerator`1.MoveNext()
at Unify.Framework.Collections.EnumerableExtensions.<ActionOnLast>d__19`1.MoveNext()
at Unify.Framework.Collections.EnumerableExtensions.<ProduceAutoPages>d__a`1.MoveNext()
at Unify.Framework.Visitor.ThreadsafeVisitorEvaluator`1.Visit()
at Unify.Product.IdentityBroker.RepositoryChangeDetectionWorkerBase.PerformChangeDetection(IEnumerable`1 connectorEntities)
at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.ImportAllChangeProcess()
at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.RunBase()
at Unify.Framework.DefinedScopeJobAuditTrailJobDecorator.Run()
at Unify.Product.IdentityBroker.ConnectorJobExecutor.<>c_DisplayClass29.<Run>b_27()
at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)
Original discussion with product team suggested that since that function returns IEnumerable result that if the connection were to drop part way through the call would not complete. Modified script to define an array for the result and populate that. Sometimes the array populates sometimes it fails. Normally failure stops the script, but sometimes it gets seen as an empty result and the 45000 users are wiped from the IdB connector - which flows deletes to FIM CS. Next successful or partially successful load puts them back and they rejoin, but this should not be happening.
The portion of the PS script that connects and gets users has been run as a standalone from the server and did not drop out or fail, but running from IdB seems to be consistently flakey.
I understand that this is more likely to be an MSOL or PS issue, but would appreciate any assistance around how to troubleshoot the unexpected errors or any suggestions for possible workarounds.
prodo365staff.ps1
staff.ps1
student.ps1
Unify.IdentityBroker.Entity.PowerShell.dll
Powershell Connector - Failures.Push not reporting errors back to MA.
Hi Guys,
I've been experiencing issues with the PowerShell connector in reporting export errors back to the MA. I'm using a try catch arrangement - with $components.Failures.Push($entity) however this does not appear to succeed in returning an error to the MA.
Attached is my current export script for Adds (Note that the reporting lines are commented out at the moment).
The MA in use is of the new Extensible Connectivity V2.0 type. It occurs to me that this may be similar to the issues we used to have on the IDB MA's with export errors being squashed if the 'Merge pending exports...' flag was not set correctly. However this setting is not present on the new MA type.
Add.ps1
PowerShell connector question: Is update $entity OK after create?
We are using an instance of the PowerShell connector to create unique AD accounts which are then to be reimported to FIM to allow the normal FIM Active Directory connector to drive standard inbound/outbound flow rules.
Given we can't easily implement a delta import mechanism for AD, and that the only changes we're interested in checking are the ones made by Identity Broker itself, is it OK to perform say the following lines at the end of the ADD.PS1 script?
$entity['sAMAccountName'] = $sAMAccountName $entity['mailNickname'] = $mailNickname $entity.Commit()
Provide a "Drop in" replacement for Sorens PowerShell MA for IdB
Allow customers seamless upgrades to a commercially supported product
Customer support service by UserEcho
