On-Prem v AAD UPNs

Question

Hi

We have some Resource Accounts for our Teams Call Queues, many of which were created automatically by Microsoft. The UPNs for these are a long hex string starting with hg_.

All exist within our Azure AD, but some of these exist in our on-prem AD as well.

Before I realised that some existed in both places I changed the randomly generated UPNs in Azure AD to something more meaningful to us carbon-based units.

What I've discovered is that the UPNs haven't replicated back to on-premise.

Everything seems to be working still, so there's no panic going on, but I want to know is whether making a change to the accounts in on-prem AD will work (such as changing the Display Name), or if they'll cause some kind of issue where the UPN doesn't match.

For instance, let's say in Azure AD I changed the UPN for the resource account called 'Marketing' from

hg_d734a3df588547688e3867a00dec043d@domain  

to

Marketing_CQ@domain  

In AD on prem the UPN is still

hg_d734a3df588547688e3867a00dec043d@domain  

So what will happen if I change the UPN in on-prem AD to match the UPN in Azure AD?

Whether I do that or not, what will happen if I change the display name from, say, Marketing, to Marketing_CallQueue (in on-prem AD, since Azure AD won't let me change the display name there)?

Bonus question:
Since there's clearly good reasons why I'm not able to change the Display Name in Azure AD, why am I similarly not also blocked from changing the UPN in Azure AD for these dual-homed objects?

Answer 1

Hello, Azure AD Connect does not write on-premises user attributes such as the UPN. If you're able to update the UPN on the cloud it's because it's not a mapped attribute thus, there should be no problem. That being said, unless it's really neccesary, values set by Microsoft services should not be updated.

Let us know if you need additional assistance. If the answer was helpful, please accept it and complete the quality survey so that others can find a solution.