AR Azure/O365 BackSync is disabled?

Aidar.Karabalaev - so your customer is able to examine Azure object properties through the Active Roles UI even though no back sync is configured?

If yes, then I am wondering how this is possible for "legacy" objects - i.e. objects that were not created through Active Roles.  I have always understood that in order for AR to be able to display Azure properties, that the Azure Object GUID VA must be populated so that AR can find the object in Azure.  Typically, it is the back synch that does this.  Or so I always understood...

Aidar.Karabalaev - so your customer is able to examine Azure object properties through the Active Roles UI even though no back sync is configured?

If yes, then I am wondering how this is possible for "legacy" objects - i.e. objects that were not created through Active Roles.  I have always understood that in order for AR to be able to display Azure properties, that the Azure Object GUID VA must be populated so that AR can find the object in Azure.  Typically, it is the back synch that does this.  Or so I always understood...

The edsvaAzureObjectId Virtual Attribute needs to be populated in order for Active Roles to query the rest of the object's Azure attributes. The Back Sync is the included method of doing this, but it could also be done via a custom method as well. One of my customers has AADConnect modified to write the Azure cloudAnchor to an attribute and has a Policy Script which grabs that attribute and inserts a modified value into edsvaAzureObjectId. They don't have the Back Sync configured.

That makes sense - I just wasn't sure if there hadn't been some kind of magical built-in policy added that had made the back-synch redundant.

You know... now that you mention it, it is entirely possible to replace the Back Sync with a custom policy in Active Roles 7.4.x. We just need to use the new "O365 script execution configuration" activity to tie into the configured Azure credentials, then periodically query Azure and update any on-prem objects which are lacking the edsvaAzureObjectId.

Should be only a few lines of code.

I'm going to test it out in my lab and see if I can get something working.

Seems like a good idea.  I would use a scheduled Automation workflow just to make it more visible.

I did not investigated deeply AR behavior against legacy AD objects with AAD/O365. 

It is possible customer create AAD/O365 via AR provision only, or maybe and very possible, there is some issues with displaying AAD/O365 value in AR Website.

Is is possible BackSync GUID sync is configured in ADConnect (as per Terrance comment below).

At least the story is clear for me know.

thank you!