Fala Pessoal, tudo bem com vocês? Hoje vou falar um pouco sobre como criar relatórios preditivos no Exchange Online combinando PowerShell, MCP e GitHub Copilot para você sair do modo reativo e começar a antecipar problemas de mailbox antes que o usuário perceba.
Você já chegou numa segunda-feira de manhã e descobriu que a cota de mailbox de um usuário estourou no final de semana? Ou recebeu uma ligação furiosa porque o fluxo de e-mails de um departamento inteiro ficou represado por um problema de throttling que ninguém viu vir?
Quem administra Exchange Online no dia a dia sabe como isso acontece. A plataforma é robusta, mas os problemas aparecem depois que o estrago está feito. Os relatórios nativos do Microsoft 365 Admin Center mostram o passado e o passado não te ajuda a agir antes.
Então fui atrás de uma forma de mudar isso. Combinando PowerShell, Microsoft Graph API, MCP e o GitHub Copilot em Agent Mode no VS Code, montei um fluxo que coleta os dados do ambiente, identifica padrões e gera um relatório de risco antes do incidente acontecer sem precisar de nenhuma chave de API externa. Vou mostrar tudo aqui, do zero.
O Problema com os Relatórios Tradicionais
O Exchange Online tem bastante coisa disponível para quem quer monitorar o ambiente: relatórios no Admin Center, dados via PowerShell com o módulo ExchangeOnlineManagement, endpoints na Microsoft Graph. Para auditoria e compliance, funcionam bem.
O problema é que todos eles são descritivos. Te dizem o que aconteceu. Não te dizem o que vai acontecer.
Pensa num cenário real: você tem 800 usuários, e 40 deles estão com a cota de mailbox entre 85% e 95%. Você extrai esse dado hoje com PowerShell. E aí? Manda e-mail manual para cada um? Abre chamado para o suporte tratar caso a caso? Fica verificando todo dia?
O que eu queria era diferente: coletar esses dados automaticamente, estimar em quantos dias cada mailbox vai estourar, gerar um relatório priorizado com os casos mais urgentes e sugestões de ação sem precisar escrever uma linha de análise na mão. É exatamente isso que o MCP combinado com o Copilot permite construir.
O Que é o MCP e Por Que Usei Ele Aqui
O MCP (Model Context Protocol) é um protocolo aberto da Anthropic que padroniza como modelos de IA se conectam a fontes de dados e ferramentas externas. Em vez de montar integrações separadas para cada coisa, você expõe funções via MCP e o modelo sabe quando e como chamá-las.
No nosso caso, o MCP age como uma ponte entre o PowerShell que conhece o Exchange Online de perto e o GitHub Copilot, que vai fazer a análise. Você define as ferramentas disponíveis, como “buscar mailboxes próximas do limite” ou “verificar o fluxo de e-mail dos últimos dias”, e o Copilot decide o que consultar para responder o que você pediu.
O ponto que me convenceu a usar essa abordagem é que você não precisa preparar os dados na mão antes de jogar para IA. O modelo faz as chamadas, interpreta e devolve o relatório formatado. Isso muda bastante a dinâmica do trabalho.
Arquitetura da Solução
Antes de entrar no código, vale ver a estrutura que montei. O diagrama abaixo mostra as quatro camadas e como elas se conectam:
Cada camada tem um papel bem definido. O PowerShell vai na fonte conecta no Exchange Online, puxa os dados e gera o JSON. O MCP Server transforma essas funções em ferramentas que o Copilot pode chamar. O Copilot em Agent Mode usa essas ferramentas para montar o relatório, sem precisar de nenhuma API key extra.
Pré-requisitos
Antes de começar, garanta que você tem:
- Módulo ExchangeOnlineManagement instalado (Install-Module ExchangeOnlineManagement)
- App Registration no Entra ID configurado com as permissões mínimas (detalhes na próxima seção)
- Certificado X.509 gerado e associado ao App Registration sem client secret
- Node.js 18+ para rodar o MCP Server
- VS Code com a extensão GitHub Copilot (plano Free já funciona)
- PowerShell 7.x recomendado para compatibilidade com o MCP SDK
Autenticação App Registration com Certificado
Esse é o ponto que separa uma automação feita para durar de uma gambiarra que quebra na primeira rotação de senha. Usar App Registration com certificado resolve três problemas de uma vez: não tem credencial de usuário no script, o MFA não bloqueia a execução agendada e não tem client secret para rotacionar de tempos em tempos.
Permissões mínimas necessárias
Configure o App Registration com as seguintes permissões de Aplicativo não delegadas, porque o script roda sem usuário logado:
| API | Permissão |
| Microsoft Graph | Mail.Read |
| Microsoft Graph | MailboxSettings.Read |
| Microsoft Graph | Reports.Read.All |
| Office 365 Exchange Online | Exchange.ManageAsApp |
Role obrigatória: depois de conceder Exchange.ManageAsApp, atribua a role Global Reader ao Service Principal do app no portal do Entra ID → Roles and Administrators. Sem essa role, o Connect-ExchangeOnline retorna acesso negado mesmo com a permissão consentida já caí nessa antes.
Admin consent: permissões de Aplicativo precisam de consentimento de um Global Administrator no Entra ID. Sem isso, nada funciona.
Gerando o certificado autoassinado
Em produção, prefira um certificado emitido pela CA interna. Para lab ou ambientes sem CA disponível, o PowerShell resolve em segundos:
$certParams = @{
Subject = "CN=ExchangeMCPApp"
CertStoreLocation = "Cert:CurrentUserMy"
KeyExportPolicy = "Exportable"
KeySpec = "Signature"
KeyLength = 2048
HashAlgorithm = "SHA256"
NotAfter = (Get-Date).AddYears(2)
}
$cert = New-SelfSignedCertificate @certParams
Export-Certificate -Cert $cert -FilePath "C:tempExchangeMCPApp.cer" | Out-Null
$pfxPassword = Read-Host "Senha do PFX" -AsSecureString
Export-PfxCertificate -Cert $cert -FilePath "C:tempExchangeMCPApp.pfx" -Password $pfxPassword | Out-Null
Write-Host "Thumbprint: $($cert.Thumbprint)"
Write-Host "Arquivos gerados em C:temp"
Depois de gerar, faça o upload do .cer no App Registration → Certificates & secrets → Certificates. Anote o Thumbprint ele vai substituir qualquer client secret no script.
Etapa 1 — Coletando os Dados do Exchange Online
Com o App Registration e o certificado no lugar, a conexão usa o CertificateThumbprint direto sem usuário, sem MFA, sem janela de login aparecendo pra quebrar o agendamento às 3 da manhã.
$AppId = "" # Application (client) ID
$TenantId = "" # Directory (tenantName)
$CertThumbprint = "" # Thumbprint do certificado
Connect-ExchangeOnline `
-AppId $AppId `
-CertificateThumbprint $CertThumbprint `
-Organization "$TenantId.onmicrosoft.com" `
-ShowBanner:$false
function Get-MailboxUsageReport {
param(
[int]$QuotaWarningPercent = 80
)
$mailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox |
Select-Object DisplayName, UserPrincipalName, ProhibitSendQuota, ProhibitSendReceiveQuota
$report = foreach ($mbx in $mailboxes) {
$stats = Get-MailboxStatistics -Identity $mbx.UserPrincipalName -ErrorAction SilentlyContinue
if ($null -eq $stats) { continue }
$sizeStr = $stats.TotalItemSize.Value.ToString()
$totalSizeBytes = [regex]::Match($sizeStr, '((d+) bytes)').Groups[1].Value
if ([string]::IsNullOrEmpty($totalSizeBytes)) {
$totalSizeBytes = 0
}
$limitStr = $mbx.ProhibitSendReceiveQuota.ToString()
if ($limitStr -eq "Unlimited") {
$limitBytes = 107374182400 # 100 GB como fallback
} else {
$limitMatch = [regex]::Match($limitStr, '((d+) bytes)')
if ($limitMatch.Success) {
$limitBytes = [int64]$limitMatch.Groups[1].Value
} else {
$limitBytes = 107374182400 # 100 GB como fallback
}
}
$percentUsed = if ($limitBytes -gt 0) {
[math]::Round(([int64]$totalSizeBytes / $limitBytes) * 100, 2)
} else {
0
}
[PSCustomObject]@{
DisplayName = $mbx.DisplayName
UPN = $mbx.UserPrincipalName
TotalSizeGB = [math]::Round($totalSizeBytes / 1GB, 3)
LimitGB = [math]::Round($limitBytes / 1GB, 3)
PercentUsed = $percentUsed
ItemCount = $stats.ItemCount
LastLogonTime = $stats.LastLogonTime
AlertLevel = if ($percentUsed -ge 95) { "CRÍTICO" }
elseif ($percentUsed -ge $QuotaWarningPercent) { "ATENÇÃO" }
else { "OK" }
}
}
return $report | Sort-Object PercentUsed -Descending
}
$usageData = Get-MailboxUsageReport -QuotaWarningPercent 80
$usageData | ConvertTo-Json -Depth 3 | Out-File "$env:TEMPexchange_usage.json" -Encoding UTF8
Write-Host "Coleta concluída. Total de mailboxes: $($usageData.Count)"
Write-Host "Críticos: $(($usageData | Where-Object AlertLevel -eq 'CRÍTICO').Count)"
Write-Host "Em atenção: $(($usageData | Where-Object AlertLevel -eq 'ATENÇÃO').Count)"
Esse script classifica cada mailbox por nível de alerta e salva tudo em JSON. É esse arquivo que o MCP Server vai ler na próxima etapa.
Etapa 2 — Construindo o MCP Server
O MCP Server é a peça central da integração. É ele que transforma as funções de coleta em ferramentas que o Copilot pode chamar durante a análise sem você precisar preparar nada na mão.
Irei deixar o link do projeto no github para download.
https://github.com/paulocostatipe/MCP-Exchange
No arquivo README você vai encontrar como configurar o MCP
Depois de realizar o readme para um teste você pode pedir direto no agente do copilot no github para iniciar o MCP e começar as fazer algumas consultas
Exemplos:
Solicitei agora uma previsão baseado nesses 10 dias de quando essa caixa pode ficar lotada
Conclusão
A diferença entre um ambiente que funciona bem e um que vive apagando incêndio geralmente não é a tecnologia é a visibilidade. Com esse fluxo, você tem clareza sobre o que vai acontecer antes de acontecer, e tempo suficiente pra agir. Com isso você pode adaptar para realizar diversas consultas, aqui é só um exemplo bem basico em um laboratorio.
PowerShell cuida da coleta, MCP conecta tudo, Copilot faz a análise.
Esse é um ponto de partida. Dá pra expandir com análise de regras de transporte, detecção de padrões de spoofing, crescimento de grupos do Teams. A estrutura já está montada é só ir adicionando as ferramentas que fazem sentido pro seu ambiente.
Gostou do conteúdo?
Se esse artigo te ajudou, compartilha com alguém da área. Deixa nos comentários quais outros relatórios você quer ver com essa abordagem DLP, auditoria de acessos, crescimento de grupos?
