Minor adjustment for Multi domain users
Purpose:
A minor adjustment for multi domain environments utilizing the Xink agent. At them moment the latest Xink client relies on (HKCU:\SOFTWARE\Microsoft\Office\16.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\00000002\Account Name) as the truth of source for the email address. Instead of needing to modify a Microsoft Outlook key. Modify a seperate custom key as to not impact Outlook at all.
Proposal:
In the past i was suggested by Xink support to modify the Account Name key for our multi domain users in order to feed them the correct signature, path shown above in the purpose section.
I propose a minor adjustment to be implemented which would look at a custom key before checking HKCU:\SOFTWARE\Microsoft\Office\16.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\00000002\Account Name. Perhaps check if key exists called HKCU:\SOFTWARE\Xink\Xink Client\Account Name exists and if it exists use that as the truth of source rather than the Account Name key in the Outlook reg directories.
Hi Daniel,
Thanks for your suggestion.
The need for Xink to look for a local registry starts when the user's UPN or logon email does not match the email of the user in the Xink portal under Employees. This happens mostly when Xink is deployed via Intune/Endpoint Manager. We do not intend for users to manually modify any registry key. In fact we want to automate it so we look into the email that was added under "Account Name" when the Outlook Profile was created. Xink cannot use a custom registry key as it does know the email yet. We really need to rely on what Outlook considers as the primary email. We only would require clients to modify the key when there is a mismatch or the Outlook profile name is not accurate because Xink will not find any match.
I hope this makes sense.
If you know any specific registry location that are more consistent and accurate in showing the actual email of the logged-on user, it will be a perfect replacement to what we use now. Otherwise, in the meantime, this registry will remain until Microsoft creates an alternative location for email address in the registry.
Let us know if you have further questions.
Hi Waylord,
Appreciate you looking at this.
Just going off your quote ""We do not intend for users to manually modify any registry key. In fact we want to automate it so we look into the email that was added under "Account Name"
I understand this for standard use cases. However You say Xink will only start looking at the key when logon email does not match employee in the Xink portal. But the scenario i'm talking about is to cover for those situations when logon email does not match between Xink portal as well as the registry key "Account Name".
Keep in my mind this implementation is not intended for users and only admins to assist with automation and implementation.
So as you say at the moment Xink looks at Logon email == Xink Portal, if not equal look at Account Name regkey. What I'm proposing is user logon == portal, if not equal look at an optional custom HKU key (only needs to exist if needed by organization) and if not exist look at Account Name regkey.
Hi Daniel,
Who will set the custom HKU key?
Xink cannot set it as the idea is to find the email of who is logged in to the machine and authenticate it against the email that exists in the Xink portal. If admins will set it, it would be an additional step in your deployment process which is what we avoid as the issue of the Account Name key is only for selected users who either have the wrong email as value or has named their Outlook profile differently.
We can discuss this further via an online meeting. Please pick my timeslot below.
https://calendly.com/waylord/30
Hi,
I vote for this request too.