Connessione a Exchange Online PowerShell: guida passo passo

By Mirko Peters · 2026-11-12

Connetti Exchange Online PowerShell con Connect-ExchangeOnline: requisiti, accesso interattivo, MFA, opzioni per partner e per esecuzione senza intervento, e correzione degli errori.

Automatically translated with AI from the original post. Read the English original

Per connetterti a Exchange Online PowerShell, carica il modulo ExchangeOnlineManagement ed esegui Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com. Si apre una finestra di accesso, inserisci la password e approvi la richiesta MFA, e la shell risulta connessa. Questo articolo è rivolto agli amministratori di Exchange e Microsoft 365 che hanno bisogno dei passaggi esatti, delle opzioni per l'accesso da parte di partner e per l'esecuzione senza intervento, e di un breve elenco di correzioni quando la connessione non riesce. Segue la documentazione Microsoft attuale, quindi i comandi qui presentati presuppongono l'autenticazione moderna e nessuna sessione di PowerShell remoto.

Punti chiave

• Per connetterti a Exchange Online PowerShell, carica il modulo ed esegui Connect-ExchangeOnline con il tuo account amministratore in formato UPN.
• L'accesso interattivo funziona con e senza autenticazione a più fattori, quindi non serve una soluzione alternativa separata per l'MFA.
• L'autenticazione di base e il vecchio metodo New-PSSession non sono più supportati, quindi gli script che li utilizzano vanno riscritti.
• Usa Get-AcceptedDomain come test rapido dopo la connessione e termina sempre la sessione con Disconnect-ExchangeOnline.
• Gli script eseguiti senza intervento dovrebbero usare l'autenticazione solo app o un'identità gestita invece di una password memorizzata.

Di cosa hai bisogno prima di connetterti

Il comando di connessione proviene dal modulo, quindi il modulo deve essere installato per primo. Se non l'hai ancora fatto, installalo dalla PowerShell Gallery con Install-Module -Name ExchangeOnlineManagement. Nella documentazione Microsoft il modulo è indicato come modulo V3. Microsoft copre sia Windows PowerShell 5.1 sia PowerShell 7. Per PowerShell 7 serve il modulo versione 2.0.4 o successiva.

Quattro altri fattori determinano se la connessione funziona:

• Autorizzazioni. Il controllo degli accessi in base al ruolo stabilisce quali cmdlet puoi eseguire una volta connesso. Connettersi non è la parte difficile, lo è eseguire il cmdlet giusto. Microsoft ha una pagina su come trovare le autorizzazioni necessarie per un cmdlet, ed è utile salvarla nei preferiti.
• Accesso a PowerShell per l'account. L'account deve poter usare Exchange Online PowerShell. Se un amministratore ha disattivato questa funzione per il tuo utente, l'accesso riesce ma la connessione no.
• Rete. La porta TCP 80 deve essere aperta tra il computer e Microsoft 365.
• Un percorso del profilo pulito. Microsoft segnala che i comandi di connessione possono non riuscire se il percorso del profilo utente contiene caratteri speciali di PowerShell, come $. Se il tuo account ne ha uno, usane un altro.

Inoltre non serve modificare nulla in WinRM. Le connessioni attuali usano REST in background, quindi il vecchio suggerimento di abilitare l'autenticazione di base in WinRM non è più valido.

Come connettersi a Exchange Online PowerShell passo dopo passo

Questo è il metodo interattivo standard. Funziona allo stesso modo in Windows PowerShell 5.1 e in PowerShell 7, con o senza autenticazione a più fattori.

1. Apri una nuova finestra di PowerShell. Una finestra nuova evita conflitti di assembly con altri moduli che potresti aver caricato in precedenza nella sessione.
2. Carica il modulo con Import-Module ExchangeOnlineManagement. Se il modulo è già installato, Microsoft indica che di solito puoi saltare questo passaggio e passare direttamente al comando di connessione, perché PowerShell carica il modulo automaticamente.
3. Esegui Connect-ExchangeOnline -UserPrincipalName admin@contoso.com, ma con il tuo account nel formato UPN. In alcune organizzazioni puoi omettere -UserPrincipalName e ti verrà chiesto di inserirlo. Se non funziona, aggiungi il parametro.
4. Inserisci la password nella finestra di accesso e seleziona Accedi.
5. Se il tuo account usa MFA, inserisci il codice di verifica e seleziona Verifica. Il codice viene inviato con il metodo configurato, ad esempio un messaggio di testo o Microsoft Authenticator. In PowerShell 7 l'accesso usa per impostazione predefinita il browser.
6. Attendi il banner. Nessun errore significa che sei connesso.

Tutto qui. Lo stesso cmdlet ti connette alle sessioni di PowerShell per Microsoft 365 GCC senza parametri aggiuntivi. Solo gli altri cloud richiedono un'impostazione, che vedremo a breve.

Se non vuoi che il banner di benvenuto finisca in un log di script, aggiungi -ShowBanner:$false. Se vuoi che Get-Help mostri la guida per i cmdlet di Exchange Online, aggiungi -LoadCmdletHelp. A partire dalla versione 3.7.0 del modulo, la guida non viene più caricata per impostazione predefinita, e questo sorprende chi aggiorna il modulo e si ritrova con Get-Help che non restituisce quasi nulla.

Altri modi per connettersi: PowerShell 7, partner e cloud

La documentazione elenca diverse varianti. Scegli quella che corrisponde alla tua situazione.

PowerShell 7 senza browser. Esegui Connect-ExchangeOnline -Device. Il comando mostra un messaggio che ti invita ad aprire https://microsoft.com/devicelogin e a inserire un codice. Lo fai su un altro dispositivo, accedi, confermi, e la sessione originale completa la connessione. Funziona con e senza MFA ed è utile su server o macchine Linux senza desktop.

PowerShell 7 con credenziali inline. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -InlineCredential funziona per gli account senza MFA. La maggior parte delle organizzazioni richiede MFA per gli amministratori, quindi lo userai raramente.

Windows PowerShell 5.1 con un oggetto credenziale. Per gli account senza MFA puoi eseguire prima $Credential = Get-Credential e poi Connect-ExchangeOnline -Credential $Credential. Microsoft precisa che, se questo non funziona, devi usare invece -UserPrincipalName.

Tenant dei clienti come partner. I partner del programma Cloud Solution Provider e gli amministratori ospiti aggiungono -DelegatedOrganization, ad esempio Connect-ExchangeOnline -UserPrincipalName admin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com. La pagina Microsoft fa riferimento al programma Cloud Solution Provider e ai privilegi di amministrazione delegata granulari (GDAP) per la parte relativa alle autorizzazioni.

Cloud governativi e regionali. -ExchangeEnvironmentName seleziona l'ambiente. Il valore predefinito è O365Default, che copre Microsoft 365 e GCC. I valori documentati per gli altri sono O365USGovGCCHigh, O365USGovDoD, O365GermanyCloud e O365China.

Script senza supervisione. Non memorizzare una password di amministratore in uno script. Microsoft documenta due opzioni migliori. Un'identità gestita, ad esempio Connect-ExchangeOnline -ManagedIdentity -Organization "contoso.onmicrosoft.com", è adatta agli script che girano in Azure. L'autenticazione app-only con un certificato è adatta a tutto il resto. Il parametro del thumbprint del certificato è supportato solo su Windows. La configurazione prevede una registrazione dell'app in Microsoft Entra ID, l'autorizzazione applicativa Exchange.ManageAsApp con consenso dell'amministratore, un certificato e un ruolo supportato, come Amministratore di Exchange, assegnato all'app. Microsoft raccomanda i privilegi minimi, quindi non assegnare all'app il ruolo di Amministratore globale, a meno che non ci sia alcun modo alternativo. Segui l'articolo separato di Microsoft sull'autenticazione app-only invece di una versione abbreviata.

In un servizio di Windows, aggiungi -SkipLoadingFormatData per evitare errori. Se vedi errori che citano Web Account Manager, il modulo versione 3.7.2 o successiva include per questo lo switch -DisableWAM.

Mantieni gli script snelli: limita ciò che importi

Una connessione normalmente importa i cmdlet di Exchange Online che ti è consentito usare. Va bene per una rapida occhiata a una casella, ma uno script che richiede tre comandi non ha bisogno di tutti. La pagina del modulo di Microsoft riporta un suggerimento specifico. Chiamate frequenti di Connect-ExchangeOnline e Disconnect-ExchangeOnline nella stessa sessione possono causare una perdita di memoria. La soluzione è connettersi una volta per script e usare il parametro -CommandName per importare solo i cmdlet necessari.

Uno script che, ad esempio, legge solo le statistiche delle caselle ha bisogno di quel solo comando. Elenca i pochi comandi necessari, connettiti una volta all'inizio, esegui il lavoro e disconnettiti una volta alla fine. Gli script scritti così sono più facili da verificare, perché la riga di connessione indica a chi legge quali comandi utilizza lo script.

Due abitudini in più aiutano negli ambienti di team. Primo, tieni la riga di connessione in un unico punto, ad esempio in una piccola funzione, così una modifica al metodo di autenticazione avviene una volta sola e non in venti script. Secondo, registra nel log l'account o il nome dell'app che ha eseguito lo script, mai il suo segreto. Quando in una casella cambia qualcosa di inatteso, quella riga di log ti fa risparmiare ore.

Verifica la connessione e chiudila correttamente

Una connessione senza errori è un buon segno, ma verificala con un comando di lettura innocuo. Get-AcceptedDomain elenca i domini della tua organizzazione e impiega un secondo. Se compaiono dei domini, la sessione funziona e il tuo account ha almeno l'accesso in lettura.

Per vedere i dettagli delle connessioni, usa Get-ConnectionInformation. La pagina del modulo di Microsoft sottolinea che Get-PSSession non restituisce nulla di utile per queste connessioni basate su REST, quindi gli script più vecchi che controllano Get-PSSession devono essere modificati.

Al termine, esegui Disconnect-ExchangeOnline. Aggiungi -Confirm:$false negli script per saltare la richiesta di conferma. L'articolo di Microsoft sulla connessione avverte che chiudere la finestra senza disconnettersi può esaurire le sessioni disponibili, e a quel punto bisogna attendere che scadano.

Correggi gli errori di connessione più comuni

La maggior parte dei problemi deriva da un breve elenco di cause. Esaminale dall'alto verso il basso.

• Nome utente o password errati. Ripeti i passaggi e verifica entrambi. Sembra banale, ma controlla prima il formato dello UPN.
• L'accesso a PowerShell è disattivato per l'account. Un amministratore può abilitarlo. Microsoft ha un articolo separato su come abilitare o disabilitare l'accesso a Exchange Online PowerShell.
• La porta 80 è bloccata. Chiedi al team di rete di consentire il traffico TCP sulla porta 80 verso Microsoft 365.
• Account federato con un provider di identità non raggiungibile. Se il tuo IDP o STS non è disponibile pubblicamente, Microsoft suggerisce di usare per la connessione un account non federato in Microsoft 365.
• «Il termine 'Update-ModuleManifest' non è riconosciuto». La connessione richiede PowerShellGet e la sua dipendenza PackageManagement. Aggiorna entrambi e riavvia PowerShell.
• "Impossibile caricare il file o l'assembly 'System.IdentityModel.Tokens.Jwt'". Il modulo è in conflitto con un altro modulo nella stessa sessione. Connettiti in una nuova finestra di Windows PowerShell prima di importare qualsiasi altro modulo.
• Errori in una finestra aperta da un servizio o da un'attività pianificata. Prova con -SkipLoadingFormatData.

Se nessuno di questi casi si applica, il sospettato successivo è la versione del modulo. Esegui Update-Module -Name ExchangeOnlineManagement nello stesso ambito in cui lo hai installato e riprova in una nuova finestra.

Errori comuni

• Usare l'autenticazione di base oppure New-PSSession. Microsoft le riporta solo come riferimento storico e precisa che non sono più supportate. Uno script che crea ancora una sessione in questo modo deve passare a Connect-ExchangeOnline.
• Chiudere la finestra invece di disconnettersi. Può esaurire le sessioni disponibili. Inserisci Disconnect-ExchangeOnline come ultima riga di ogni script.
• Inserire una password in chiaro in uno script. Usa invece un'identità gestita o un certificato.
• Importare prima altri moduli. Un conflitto con un altro modulo può compromettere l'accesso. Connettiti prima a Exchange Online oppure usa una nuova finestra.
• Dare per scontato che la connessione equivalga all'autorizzazione. Se dopo la connessione un cmdlet viene segnalato come «non riconosciuto», il tuo ruolo non lo include. Non è un problema di connessione, ma una questione di RBAC.

Argomenti correlati da esplorare

• Installare e aggiornare il modulo: la connessione dipende dal modulo e dalla versione di PowerShell corretti, quindi leggi i requisiti del modulo PowerShell di Exchange Online prima di distribuirlo a un team.
• Trovare le autorizzazioni per un cmdlet: Microsoft spiega come verificare quale ruolo richiede un cmdlet specifico di Exchange.
• Connettersi a PowerShell di Security & Compliance: lo stesso modulo offre Connect-IPPSSession, che non è disponibile in PowerShell 7 su Linux o macOS.
• Automazione senza presidio: l'autenticazione dell'app e le identità gestite sono il modo sicuro per eseguire script di Exchange pianificati.
• Grandi operazioni in blocco: i cmdlet basati su REST hanno un timeout di 15 minuti, quindi suddividi gli aggiornamenti dei membri di grandi dimensioni in batch.

Prossimo passo

Per connetterti in modo affidabile a PowerShell di Exchange Online, inizia da una nuova finestra, esegui Connect-ExchangeOnline -UserPrincipalName con il tuo account amministratore, verifica con Get-AcceptedDomain e disconnettiti al termine. Poi pianifica i tuoi script senza presidio basandoti su un'identità gestita o su un certificato, così nessuno deve digitare o memorizzare una password.