Il titolo sarà un po’ criptico, ma probabile che se siete arrivati su questa pagina qualcosa avrete già intuito. Partiamo dal sintomo. Di recente con un Account Azure Exchange Online (Microsoft 365 ma questo è ininfluente) dovevo mettere degli alias ad un indirizzo di posta elettronica, ma mi sono trovato davanti questo messaggio di errore mezzo in italiano e mezzo in inglese
Togliendo il fatto che non ci fosse nessuna migrazione in corso delle caselle di posta, in effetti l’ambiente in cui sto operando è un Active Directory on-premise. Cioè l’Active Directory aziendale, quello sulla LAN locale, è collegato all’Active Directory su Azure.
Tuttavia, internamente non è presente nessun Server Exchange, che a sua volta sarebbe stato anch’esso on-premise. Questa cosa genera una discrasia funzionale, nella intranet è presente solo un Active Directory, fuori sul cloud, l’Active Directory è collegato ad un Exchange Online. Tradotto terra-terra; non ci sono gli stessi campi disponibili su entrami i lati del sistema.
E quindi nel momento in cui metto mano ad un utente, che di fatto è on-premise, se cerco di mettere un alias sia da Exchange Online che dalla console di amministrazione di Microsoft 365, ottengo l’errore di cui sopra. Da Azure Active Directory non posso intervenire, nemmeno in editing, sul campo E-mail o Proxy. Va detto che nel profilo viene presentato un campo fuorviante che risponde al nome di Email alternativa. Sono indirizzi alternativi presenti a livello di “contatto” cioè al pari di una compilazione dei campi via, azienda eccetera. In pratica è il luogo dove registrare le e-mail private di una utenza che chiaramente possono essere più di una. Ma questi indirizzi sono “stupidi” cioè non hanno facoltà di utilizzo sul nostro Exchange Online.
Quindi l’unico modo per risolvere è intervenire direttamente sull’Active Directory locale. Questa cosa però presumo possa funzionare solo da Windows Server 2012 in su. Infatti, il campo che andremo ad operare è visibile solo sull’interfaccia “Centro di amministrazione di Active Directory“
Se viceversa utilizziamo il vecchio software per la gestione dell’albero delle directory non è fattibile. Probabilmente esiste un metodo per farlo via Powershell, ma non ho indagato ulteriormente. Quindi è necessario andare sulla Organization Unit (OU) che apparirà sulla vostra sinistra, cercare l’utente a cui andrà applicato l’Alias e con un doppio click entrare nelle proprietà di quel profilo.
Una volta entrati cerchiamo “Estensioni” quindi “Editor attributi” e nella lunga lista andremo a scegliere proxyAddresses.
Nella schermata che esce possiamo aggiungere più parametri. Ma attenzione! Dopo un primo tentativo le cose si erano complicate. Infatti, nel profilo sotto la voce E-mail era presente la mail relativa al profilo. Parametro che era stato correttamente letto ed eseguito da Azure Active Directory ed Exchange Online. Tuttavia, proxyAddresses a quanto pare ha il potere di riscrivere tutti i protocolli SMTP di quel profilo. Infatti, sarà necessario prima di mettere la mail ALIAS, di inserire anche quella istituzionale, sempre utilizzando il medesimo metodo di inserimento per il valore con SMTP in maiuscolo:
SMTP:email@dominio
Mentre per agli alias va messo in minuscolo
smtp:alias@domininio
Se vogliamo essere sicuri possiamo chiedere un controllo via Powershell (cambia NOMEUTENTE-AD con il nome utente interessato).
get-aduser NOMEUTENTE-AD -properties proxyaddressesDopo aver salvato c’è da attendere che il protocollo di Sync tra Active Directory on-premise e Azure Active Directory si vadano ad allineare e a quel punto vedremo sia in Azure che in Exchange Online, l’Alias correttamente inserito.
Se non volete attendere potete aprire la Powershell come amministratore, caricare il modulo di AD sync e dare il comando di sincronia manuale.
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType DeltaOvviamente il problema non si pone se l’utenza è stata creata ex-novo su Azure, oppure se abbiamo un Exchange on-premise. Viceversa, la situazione in cui mi sono trovato presumo sia abbastanza classica, ovvero l’acquisto di una Exchange Online proprio per evitare l’acquisto e l’incombenza di un sistema interno di posta.
