1928 Error message Error 0x7810 A user with this name already exists in the database is shown after submitting SDForm when an existing Azure AD use

Where one user known to Azure AD is deploying SecureDoc to an endpoint device, and in SDForm specifies a different Azure AD User as the intended "owner" of the device, the installer will throw a "Error 0x7810: A user with this name already exists in the database" message.

Scenario:
This will occur in the following circumstances:
ADSync is synchronized to Azure AD
Client joined Azure AD successfully
Steps:
1. Login Windows with native AAD user: e.g., [email protected]
2. Deploy the SecureDoc Installation Package to the client with these options in the Profile.
Windows Account
Auto-Provisioning is disabled, SDForm will be shown to permit a manual process of defining device ownership

In SDForm, a specific User is entered (this user exists in Azure AD) e.g., [email protected]
--> Submit SDForm (user in SDform is [email protected])


3. Click OK button and observe

Expected:  Normally one would expect Boot Logon to be installed, the client device to be encrypted and ownership granted to user [email protected]
The Issue: What actually occurs is:  The error message " Error 0x7810. A user with this name already exists in the database " is shown
Client device will have the  SD package successfully installed, but without creating a Key File or relationship to the device for the user specified in SDForm ([email protected] in our example).
Note that this issue does NOT occur when deploying in an environment that uses an on-premises (regular) Active Directory.
Comment:  This is an non-typical way of deployment by using a different (not logged in yet) AzureAD user. I.e. product is installed under AAD user A but user's B name (UPN) is entered into registration details.
At this point SDForm is unable to recognize this user as being an Azure AD user and submits what it has to SES.
Typically the local computer name is used as a "fallback" domain. SES gets confused by this data as well and it results in a user name duplication as an Azure AD user with the same name exists  already in the database, thanks to ADSync.

Solution:  Until WinMagic has a longer-term solution, either:
a) Do not specify 3rd-party Azure AD Users in SDForm. Permit the deploying Azure AD user to be the device owner, then change ownership to a different user later, or
b) Use a standalone/non-Azure AD user name.