UPN update problem?

Hi gardianmemeti kavo 

Depending on the requirements (and complexity), if it were me I'd probably use the below logic

1) Create a change workflow, triggered on change to a users UserPrincipalName

2) Add a script activity, where your script would

a. Update the mail attribute from to be set new UPN

b. Update proxyAddress

i. Get a list of all current proxyAddresses

ii. Get the new smtp address

iii. If new SMTP address already existing in proxyAddress, then make all other address secondary (lower case before the : character), before ensuring the existing proxy address has upper case characters before the : character)

iv. If new SMTP address doesn't exist in proxyAddresses, then make all other address secondary (lower case before the : character), before adding the new entry, with uppercase SMTP before the : character

The user case can get complex, if you have a lot of protocol in use, like SIP, X400, X500 etc etc. As you'll probably want to ensure consistency. Also if you have an environment where UPN (and or other attributes which should trigger a change to the UPN, like a surname change) occur a lot, you may end up in a situation where a user account holds a lot of proxyAddresses, and are never freed up (if you wanted this to occur, you'd need a way to be able to know which addresses should be removed, and when). All this is really down to your requirements, and designing how you want it to work.

As an example, proxyAddress generally appears as <Protocol>:<Address>, IE

SMTP:user.test@domain.com

smtp:user.oldtest@domain.com

smtp:user.oldertest:domain.com

Where user.test@domain.com is the primary SMTP address, and the other two a secondary (or other smtp addresses).

This also apply to SIP addresses (from memory)

SIP:user.test@domain.com

sip:user.oldtest@domain.com

sip:user.oldertest:domain.com

If it were just the mail attribute being changed, it would be a straightforward workflow, or admin policy. But for proxyAddresses, you also need to validate and ensure that there is only a single primary entriy for each protocol in the list, but also the value being entered is unique (across all users in the domain, you don't have to validate it, but to save you pain later, it makes sense to do that, that would be validating against all users ProxyAddresses as well as mail attributes).

Hope this helps

Stu

Hi gardianmemeti kavo 

Depending on the requirements (and complexity), if it were me I'd probably use the below logic

1) Create a change workflow, triggered on change to a users UserPrincipalName

2) Add a script activity, where your script would

a. Update the mail attribute from to be set new UPN

b. Update proxyAddress

i. Get a list of all current proxyAddresses

ii. Get the new smtp address

iii. If new SMTP address already existing in proxyAddress, then make all other address secondary (lower case before the : character), before ensuring the existing proxy address has upper case characters before the : character)

iv. If new SMTP address doesn't exist in proxyAddresses, then make all other address secondary (lower case before the : character), before adding the new entry, with uppercase SMTP before the : character

The user case can get complex, if you have a lot of protocol in use, like SIP, X400, X500 etc etc. As you'll probably want to ensure consistency. Also if you have an environment where UPN (and or other attributes which should trigger a change to the UPN, like a surname change) occur a lot, you may end up in a situation where a user account holds a lot of proxyAddresses, and are never freed up (if you wanted this to occur, you'd need a way to be able to know which addresses should be removed, and when). All this is really down to your requirements, and designing how you want it to work.

As an example, proxyAddress generally appears as <Protocol>:<Address>, IE

SMTP:user.test@domain.com

smtp:user.oldtest@domain.com

smtp:user.oldertest:domain.com

Where user.test@domain.com is the primary SMTP address, and the other two a secondary (or other smtp addresses).

This also apply to SIP addresses (from memory)

SIP:user.test@domain.com

sip:user.oldtest@domain.com

sip:user.oldertest:domain.com

If it were just the mail attribute being changed, it would be a straightforward workflow, or admin policy. But for proxyAddresses, you also need to validate and ensure that there is only a single primary entriy for each protocol in the list, but also the value being entered is unique (across all users in the domain, you don't have to validate it, but to save you pain later, it makes sense to do that, that would be validating against all users ProxyAddresses as well as mail attributes).

Hope this helps

Stu

Stu.Pollock covered this well.  I would just add some comments around checking for duplicate email addresses.  If you are operating an Exchange Hybrid or Exchange on-prem environment, your AR service account needs Exchange Admin permissions anyway.  Checking for a duplicate email address before you change the primary SMTP or indeed apply a new proxy is as easy as establishing a connection to the Exchange server and then performing a Get-Recipient <new email address>.  If this returns nothing then you are fine to assign it.  If it returns something then you will need to implement some code to somehow de-dupe the new address - whether that is by adding a numeric suffix (easiest) or possibly adding a middle initial to the mail address (not so easy because in my experience, a middle initial is not readily available in AD).

Thank you man , 
Its done almost like you said. Just I need to add also synch with Azure AD.