Chi decide l'indirizzo primario di una casella ibrida

In un ambiente ibrido l’indirizzo primario di una casella non è un campo che si scrive. È il risultato di una contesa fra tre componenti che non si consultano fra loro: la politica degli indirizzi di Exchange, il comando che si sta eseguendo, e Entra al momento della sincronizzazione. Ognuno può sovrascrivere quello prima, e nessuno avvisa.

Primo: la politica rivendica il campo

Impostare l’indirizzo primario di una casella si fermava qui.

Couldn't update the primary SMTP address because this mailbox is
configured to use an email address policy.

Il messaggio è chiaro e dice la verità: con una politica degli indirizzi attiva, l’indirizzo primario lo decide la politica, non chi esegue il comando. È il comportamento voluto — serve proprio a garantire che centomila caselle abbiano indirizzi coerenti — ma diventa un ostacolo quando una singola casella deve fare eccezione.

Il tentativo istintivo di aggirarlo aggiungendo l’indirizzo a mano produce un secondo errore, più oscuro.

There are multiple primary SMTP addresses.

La causa è una maiuscola. Nel parametro -EmailAddresses, il prefisso SMTP: scritto in maiuscolo significa primario, mentre smtp: minuscolo significa alias.

# aggiunge un SECONDO primario: non ammesso
Set-Mailbox <utente> -EmailAddresses @{add="SMTP:[email protected]"}

Una casella può avere un solo indirizzo primario. L’aggiunta non sostituisce quello esistente: lo affianca, e Exchange rifiuta lo stato risultante.

Il rimedio è disattivare la politica su quella casella e usare il parametro dedicato, che retrocede da solo il vecchio primario ad alias — senza perderlo.

Set-Mailbox <utente> `
  -EmailAddressPolicyEnabled $false `
  -PrimarySmtpAddress <utente>@lab.impicciando.it

Secondo: gli oggetti che il tenant non vede

L’assegnazione delle deleghe falliva su tutti i gruppi.

Mailbox ufficio.acquisti or Group Gufficio.acquisti not found in EXO

Due cause sovrapposte, il che rende la diagnosi lenta: risolverne una sola non cambia niente.

I gruppi stavano fuori dall’ambito di sincronizzazione. Erano in CN=Users, mentre il filtro di Entra Connect era impostato su una unità organizzativa dedicata. Per il tenant quegli oggetti non esistevano affatto — non erano sbagliati, erano assenti.

Mancava l’opzione di distribuzione ibrida. Senza Exchange hybrid deployment attivo in Entra Connect, Exchange Online non riconosce gli oggetti locali come destinatari validi, anche quando li vede.

Il rimedio richiede tutti e tre i passi: spostare i gruppi nell’unità organizzativa sincronizzata, attivare l’opzione, e forzare un ciclo completo — non uno differenziale, che non riesamina oggetti già considerati fuori ambito.

Start-ADSyncSyncCycle -PolicyType Initial

Terzo: Entra riscrive quello che non può verificare

I gruppi sono saliti nel tenant. Con l’indirizzo sbagliato.

Invece di @lab.impicciando.it avevano un indirizzo su @impicciando.onmicrosoft.com, che nessuno aveva chiesto.

La ragione è la più ragionevole delle tre. Il loro indirizzo primario locale era su contoso.lab, il dominio Active Directory interno, che nel tenant non è verificabile: non è un dominio pubblico e nessuno può dimostrarne la proprietà. Entra scarta gli indirizzi su domini non verificati — non può fare altro, accettarli significherebbe permettere a chiunque di rivendicare qualunque dominio — e al loro posto assegna d’ufficio un indirizzo sul dominio di servizio.

Non è un guasto. È il sistema che rifiuta di credere a un’affermazione non dimostrabile.

Set-DistributionGroup <gruppo> `
  -EmailAddressPolicyEnabled $false `
  -PrimarySmtpAddress <gruppo>@lab.impicciando.it

Le tre lezioni

Quando un campo ha tre padroni, l’ordine conta più del valore. Politica, comando, sincronizzazione: scrivere il valore giusto nel momento sbagliato equivale a non averlo scritto.

Un dominio interno non è un dominio. contoso.lab funziona benissimo per Kerberos, LDAP e l’autenticazione, e non vale niente come identità di posta. Tenerli separati fin dall’inizio evita tutta questa categoria di problemi — ed è la ragione strutturale per cui il dominio AD non dovrebbe essere il dominio pubblico.

Un valore che ricompare sbagliato dopo la correzione non è un caso. È una sorgente autorevole a monte che riafferma quello che sa. Cercare dove viene generato è più veloce che correggerlo di nuovo.

Laboratorio costruito con il supporto di Ilie.