objectGUID returns 'System.Byte[]' when using Query AD activity

shill · ‎06-20-2016

I am needing to update a user record that was created outside of the LDAP import with its objectGUID value as that is what our LDAP import uses to coalesce on.

I am using the Query AD orchestration activity and returning the proper user data.

But in the return json, I am getting "objectguid":"System.Byte[]" instead of something like /v5pExxhx0uGQq0UTNbs9g== . The latter is what is provided in the LDAP import.

Is it possible to retrieve the same value as the LDAP import would receive via this activity?

This is part of our onboarding process, so I need update the new record so that the LDAP import does not duplicate the user.

Robert Beeman · ‎06-20-2016

I'm doing this by passing AD's GUID property into this PoSh function:

function Get-B64($guid) {

   [System.Convert]::ToBase64String((new-Object system.Guid($guid)).ToByteArray())

}

View solution in original post

Robert Beeman · ‎06-20-2016

Hi Steven,

Yes, these functions would be used in a Custom Activity (or Run Powershell) along with the ConvertTo-Json cmdlet. I haven't worked with the objectGUID from the Query AD activity, but it looks like it has already replaced the binary with the string "System.Byte[]". You could confirm that by looking in the payload XML of the input record on the ECC queue.

sergiovsj · ‎08-16-2016

Hi Steven,

I'm facing the same issue as you. Did you finally manage to solve it? How?

In my Run Script activity, after Query AD activity, I'm getting 'System.Byte[]' and I'm not able to transform it. As Robert said, this is the payload I'm receiving in my ECC queue. How to use Robert's function when Query AD return is 'System.Byte[]'?

Thanks,

Sergio

shill · ‎08-16-2016

Sorry Sergio, I ended up going in another direction to solve my issue instead of using the query AD option.

I'm just not that familiar with PowerShell.

sergiovsj · ‎08-16-2016

Thanks for your quick response. Can you share with me the other direction you took? Maybe a new idea can help. I'm also not familiar with PowerShell.

Thanks,

Sergio

shill · ‎08-16-2016

I used a version of what is shown here LDAP query every 5 to 10 minutes

So here is my setup:

The instance receives an email from HR as soon as a new employee is added to our HR system.
AD acct is also created with a integration between AD and our HR system at the same time.
I parse the email and create a custom Onboarding record along with a shell user acct with name, manager, email, location, and user ID.
This allows our Service Desk to start the onboarding process immediately instead of waiting for the overnight load.
Every 5 mins, I run a scheduled script to check for new onboarding users that I've created, gather their user ID's and using the process above, create a OU filter for a specific OU definition searching for only those user ID's that I need to update the shell acct I created.
This uses a custom transform map to coalesce on the user ID instead of the GUID like our normal import.

The scheduled job is necessary as if two creations come in too fast to each other, the script that sets the filter on the OU definition will overwrite the filter before the other import is complete.

Definitely more working parts, but for me, much easier to create and know what is going on.