Como conectar ao Exchange Online PowerShell: guia passo a passo

By Mirko Peters · 2026-11-12

Conecte-se ao Exchange Online PowerShell com Connect-ExchangeOnline: requisitos, login interativo, MFA, opções para parceiros e execução sem interação, além de como corrigir erros.

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

Para se conectar ao Exchange Online PowerShell, carregue o módulo ExchangeOnlineManagement e execute Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com. Abre-se uma janela de login, você informa sua senha e aprova a solicitação de MFA, e o shell fica conectado. Este artigo é para administradores de Exchange e Microsoft 365 que precisam dos passos exatos, das opções de acesso para parceiros e execução sem interação, e de uma lista curta de correções para quando a conexão falha. Ele segue a documentação atual da Microsoft, portanto os comandos aqui pressupõem autenticação moderna e nenhuma sessão de PowerShell remoto.

Pontos-chave

• Para se conectar ao Exchange Online PowerShell, carregue o módulo e execute Connect-ExchangeOnline com sua conta de administrador no formato UPN.
• O login interativo funciona com e sem autenticação multifator, então você não precisa de uma solução alternativa separada para MFA.
• A autenticação básica e o antigo método New-PSSession não são mais compatíveis, então scripts que dependem deles precisam ser reescritos.
• Use Get-AcceptedDomain como teste rápido depois de conectar e sempre encerre a sessão com Disconnect-ExchangeOnline.
• Scripts sem interação devem usar autenticação somente de aplicativo ou uma identidade gerenciada, em vez de uma senha armazenada.

O que você precisa antes de se conectar

O comando de conexão vem do módulo, então o módulo precisa estar instalado primeiro. Se ainda não instalou, instale-o pela PowerShell Gallery com Install-Module -Name ExchangeOnlineManagement. O módulo é chamado de módulo V3 na documentação da Microsoft. A Microsoft cobre tanto o Windows PowerShell 5.1 quanto o PowerShell 7. Para o PowerShell 7, você precisa da versão 2.0.4 ou posterior do módulo.

Outros quatro fatores determinam se a conexão funciona:

• Permissões. O controle de acesso baseado em funções define quais cmdlets você pode executar depois de conectado. Conectar não é a parte difícil; difícil é executar o cmdlet certo. A Microsoft tem uma página sobre como descobrir as permissões que um cmdlet exige, e vale a pena salvá-la nos favoritos.
• Acesso ao PowerShell para a conta. A conta precisa estar autorizada a usar o Exchange Online PowerShell. Se um administrador desativou isso para o seu usuário, o login é bem-sucedido, mas a conexão não.
• Rede. A porta TCP 80 precisa estar aberta entre o seu computador e o Microsoft 365.
• Um caminho de perfil limpo. A Microsoft informa que os comandos de conexão podem falhar se o caminho do perfil do usuário contiver caracteres especiais do PowerShell, como $. Use outra conta, se a sua tiver esse problema.

Você também não precisa alterar nada no WinRM. As conexões atuais usam REST por trás dos panos, então a antiga recomendação de habilitar a autenticação básica no WinRM não se aplica mais.

Como se conectar ao Exchange Online PowerShell passo a passo

Este é o método interativo padrão. Ele funciona da mesma forma no Windows PowerShell 5.1 e no PowerShell 7, com ou sem autenticação multifator.

1. Abra uma nova janela do PowerShell. Uma janela limpa evita conflitos de assemblies com outros módulos que você possa ter carregado antes na sessão.
2. Carregue o módulo com Import-Module ExchangeOnlineManagement. Se o módulo já estiver instalado, a Microsoft diz que normalmente você pode pular esta etapa e ir direto para o comando de conexão, porque o PowerShell carrega o módulo automaticamente.
3. Execute Connect-ExchangeOnline -UserPrincipalName admin@contoso.com, mas com a sua própria conta no formato UPN. Em algumas organizações você pode omitir -UserPrincipalName e o comando solicitará a informação. Se isso falhar, adicione o parâmetro.
4. Digite sua senha na janela de login e selecione Entrar.
5. Se a sua conta usar MFA, digite o código de verificação e selecione Verificar. O código é enviado pelo método configurado, por exemplo uma mensagem de texto ou o Microsoft Authenticator. No PowerShell 7, o login usa o navegador por padrão.
6. Aguarde o banner. Se não houver erro, significa que você está conectado.

É isso. O mesmo cmdlet conecta você às sessões do PowerShell para o Microsoft 365 GCC sem parâmetros extras. Somente as outras nuvens precisam de uma configuração, que veremos a seguir.

Se você não quiser o banner de boas-vindas em um log de script, adicione -ShowBanner:$false. Se quiser que o Get-Help mostre a ajuda dos cmdlets do Exchange Online, adicione -LoadCmdletHelp. A partir da versão 3.7.0 do módulo, essa ajuda deixou de ser carregada por padrão, o que surpreende quem atualiza o módulo e depois vê o Get-Help retornando quase nada.

Outras formas de se conectar: PowerShell 7, parceiros e nuvens

A documentação lista várias variações. Escolha a que corresponde à sua situação.

PowerShell 7 sem navegador. Execute Connect-ExchangeOnline -Device. O comando exibe uma mensagem pedindo para você abrir https://microsoft.com/devicelogin e digitar um código. Você faz isso em qualquer outro dispositivo, faz o login, confirma, e a sessão original termina de se conectar. Funciona com e sem MFA e é útil em servidores ou máquinas Linux sem interface gráfica.

PowerShell 7 com credenciais inline. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -InlineCredential funciona para contas sem MFA. A maioria das organizações exige MFA para administradores, então você vai usar isso raramente.

Windows PowerShell 5.1 com um objeto de credencial. Para contas sem MFA, você pode executar primeiro $Credential = Get-Credential e depois Connect-ExchangeOnline -Credential $Credential. A Microsoft observa que, se isso falhar, você deve usar -UserPrincipalName em seu lugar.

Locatários de clientes como parceiro. Parceiros do programa Cloud Solution Provider e administradores convidados adicionam -DelegatedOrganization, por exemplo Connect-ExchangeOnline -UserPrincipalName admin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com. A página da Microsoft se refere ao programa Cloud Solution Provider e aos privilégios granulares de administrador delegado (GDAP) para o lado das permissões.

Nuvens governamentais e regionais. -ExchangeEnvironmentName seleciona o ambiente. O padrão é O365Default, que abrange o Microsoft 365 e o GCC. Os valores documentados para as outras são O365USGovGCCHigh, O365USGovDoD, O365GermanyCloud e O365China.

Scripts sem interação. Não armazene uma senha de administrador em um script. A Microsoft documenta duas opções melhores. Uma identidade gerenciada, por exemplo Connect-ExchangeOnline -ManagedIdentity -Organization "contoso.onmicrosoft.com", é indicada para scripts executados no Azure. A autenticação somente de aplicativo com certificado é indicada para todos os outros casos. O parâmetro de impressão digital do certificado é compatível somente com o Windows. A configuração envolve um registro de aplicativo no Microsoft Entra ID, a permissão de aplicativo Exchange.ManageAsApp com consentimento de administrador, um certificado e uma função compatível, como Administrador do Exchange, atribuída ao aplicativo. A Microsoft recomenda o princípio do privilégio mínimo, então não atribua ao aplicativo a função de Administrador Global, a menos que não exista outra alternativa. Siga o artigo separado da Microsoft sobre autenticação somente de aplicativo, em vez de uma versão resumida dele.

Em um serviço do Windows, adicione -SkipLoadingFormatData para evitar erros. Se aparecerem erros que mencionam o Web Account Manager, o módulo na versão 3.7.2 ou posterior tem a opção -DisableWAM para isso.

Mantenha os scripts enxutos: limite o que você importa

Normalmente, uma conexão importa os cmdlets do Exchange Online que você tem permissão para usar. Isso é aceitável para uma verificação rápida de uma caixa de correio, mas um script que precisa de três comandos não precisa de todos eles. A página do módulo da Microsoft traz uma dica específica sobre isso. Chamadas frequentes de Connect-ExchangeOnline e Disconnect-ExchangeOnline na mesma sessão podem causar vazamento de memória. A solução é conectar uma vez por script e usar o parâmetro -CommandName para importar apenas os cmdlets de que você precisa.

Um script que apenas lê estatísticas de caixas de correio, por exemplo, precisa de apenas esse comando. Liste os poucos comandos, conecte uma vez no início, faça o trabalho e desconecte uma vez no final. Scripts escritos dessa forma são mais fáceis de revisar, porque a linha de conexão informa ao leitor quais comandos o script usa.

Duas outras práticas ajudam em ambientes de equipe. Primeiro, mantenha a linha de conexão em um único lugar, como uma pequena função, para que uma mudança no método de autenticação aconteça uma vez e não em vinte scripts. Segundo, registre no log a conta ou o nome do aplicativo que executou o script, nunca o segredo. Quando algo inesperado muda em uma caixa de correio, essa linha de log pode economizar horas de trabalho.

Verifique a conexão e a desconexão corretamente

Uma conexão sem erro é um bom sinal, mas teste-a com um comando de leitura inofensivo. Get-AcceptedDomain lista os domínios da sua organização e leva um segundo para ser executado. Se os domínios aparecerem, sua sessão está funcionando e sua conta tem pelo menos acesso de leitura.

Para ver detalhes sobre suas conexões, use Get-ConnectionInformation. A página do módulo da Microsoft aponta que Get-PSSession não retorna nada útil para essas conexões baseadas em REST, então scripts antigos que verificam Get-PSSession precisam ser alterados.

Ao terminar, execute Disconnect-ExchangeOnline. Adicione -Confirm:$false nos scripts para não exibir a solicitação de confirmação. O artigo de conexão da Microsoft alerta que fechar a janela sem desconectar pode esgotar as sessões disponíveis, e então você precisa esperar até que elas expirem.

Corrija os erros de conexão mais comuns

A maioria das falhas vem de uma pequena lista de causas. Verifique-as de cima para baixo.

• Nome de usuário ou senha incorretos. Refaça as etapas e confira os dois. Parece trivial, mas verifique primeiro o formato do UPN.
• O acesso ao PowerShell está desativado para a conta. Um administrador pode habilitá-lo. A Microsoft tem um artigo separado sobre como habilitar ou desabilitar o acesso ao PowerShell do Exchange Online.
• A porta 80 está bloqueada. Peça à sua equipe de rede que libere a porta TCP 80 para o Microsoft 365.
• Conta federada com um provedor de identidade inacessível. Se o seu IDP ou STS não estiver disponível publicamente, a Microsoft sugere usar uma conta não federada no Microsoft 365 para a conexão.
• "The term 'Update-ModuleManifest' is not recognized". A conexão precisa do PowerShellGet e de sua dependência, o PackageManagement. Atualize os dois e reinicie o PowerShell.
• "Could not load file or assembly 'System.IdentityModel.Tokens.Jwt'". O módulo entra em conflito com outro módulo na mesma sessão. Conecte-se em uma nova janela do Windows PowerShell antes de importar qualquer outra coisa.
• Erros em uma janela aberta por um serviço ou por uma tarefa agendada. Tente -SkipLoadingFormatData.

Se nenhuma dessas situações se aplicar, a versão do módulo é o próximo suspeito. Execute Update-Module -Name ExchangeOnlineManagement no mesmo escopo em que você o instalou e tente novamente em uma nova janela.

Erros comuns

• Usar autenticação básica ou New-PSSession. A Microsoft os lista apenas como referência histórica e informa que não são mais suportados. Um script que ainda cria sessão dessa forma precisa migrar para Connect-ExchangeOnline.
• Fechar a janela em vez de desconectar. Isso pode esgotar as suas sessões. Faça de Disconnect-ExchangeOnline a última linha de todo script.
• Colocar uma senha em texto simples dentro de um script. Use uma identidade gerenciada ou um certificado.
• Importar outros módulos antes. Um conflito com outro módulo pode quebrar o logon. Conecte-se primeiro ao Exchange Online ou use uma nova janela.
• Presumir que conexão significa permissão. Se um cmdlet for exibido como "não reconhecido" depois que você se conecta, a sua função não inclui esse cmdlet. Isso é uma questão de RBAC, não um problema de conexão.

Tópicos relacionados para explorar

• Instale e atualize o módulo: a conexão depende do módulo e da versão do PowerShell corretos, então leia os requisitos do módulo do Exchange Online PowerShell antes de implantá-lo para uma equipe.
• Descubra as permissões de um cmdlet: a Microsoft explica como consultar qual função um cmdlet específico do Exchange exige.
• Conecte-se ao Security & Compliance PowerShell: o mesmo módulo oferece Connect-IPPSSession, que não está disponível no PowerShell 7 em Linux ou macOS.
• Automação sem supervisão: a autenticação somente com aplicativo e as identidades gerenciadas são a forma segura de executar scripts agendados do Exchange.
• Grandes operações em lote: os cmdlets baseados em REST têm um tempo limite de 15 minutos, então divida atualizações grandes de membros em lotes.

Próximo passo

Para se conectar de forma confiável ao Exchange Online PowerShell, comece com uma nova janela, execute Connect-ExchangeOnline -UserPrincipalName com a sua conta de administrador, teste com Get-AcceptedDomain e desconecte quando terminar. Depois, planeje seus scripts sem supervisão com base em uma identidade gerenciada ou um certificado, para que ninguém precise digitar ou armazenar uma senha.