"EDSA/EDSVA" meaning

A legacy name for Active Roles is the "Enterprise Directory Service".

EDSA is short for "Enterprise Directory Service Attribute" and EDSVA is short for "Enterprise Directory Service Virtual Attribute".

As a general rule of thumb, an EDSA attribute is computed, and is used to display something in a more user-friendly way. For example: edsaAccountIsDisabled is a Boolean which displays the current disabled/enabled status and allows someone with the necessary access to set that status easily. This is much friendlier than a bitwise mask on the userAccountControl attribute.

An EDSVA attribute is a virtual attribute which holds some value. For example: edsvaDeprovisionStatus is an enumeration which holds a value which displays the current Deprovision status and allows someone with the necessary access to set that status.

Thank you Terrence. This appears to be a text book explanation of the it. Thank you!

Hi Terrance! Are the EDSA and EDSVA fields you mention above only available in ARS and not available in native AD?

They are stored in the Active Roles configuration database so you have to access the Active Roles server in order to read them back.  This is most easily accomplished using the Quest PoSh cmdlets but you can also use the ADSI provider which is a more advanced method of coding in PoSh.

Example:

Get-QADUser -proxy -Identity "JSmith" -includedproperties edsvaMyVirtualAttributeName

you said edsa attributes are computed. How does it compute them? Especially for something like edsaAzureUserPrincipalName. I am finding some accounts where it is blank, but it shouldn't be.

That value is pulled from your AR-connected Azure tenant.  In order to do that, the edsvaAzureObjectId must be populated on the user as AR uses this to lookup the object in your tenant on the fly.

This population of edsvaAzureObjectId can be achieved either by using the Sync Service to back sync this value OR by using a workflow activity to create the object in the first place - in which case the value comes back right away from your tenant and gets stamped on the on-prem AD user object.

edsavaAzureObjectID is present. This is not my problem. I can pull that and it is correct. The edsaAzureUserPrincipalName is what is not present or being populated.

That would suggest that your connection with the tenant may not be working.

Here again is how you can check.