Diferente de outros exames “900”, que costumam ser a porta de entrada para iniciantes, o AB-900 faz algo estratégico: ele une a base sólida de administração do Microsoft 365 com a nova camada de governança de IA e Agentes. Se você já é Admin de M365 no dia a dia, isso é território familiar, mas com uma dimensão nova que está mudando como gerenciamos ambientes produtivos.

Como analista sênior lidando com Exchange Online, SharePoint e Teams todos os dias, decidi documentar como saí do zero até a aprovação. Confira o que funcionou para mim.

O que é o AB-900 e por que ele importa agora?

O exame Microsoft 365 Certified: Copilot and Agent Administration Fundamentals foi lançado em beta no final de 2025 e chegou à disponibilidade geral em fevereiro de 2026. Ele valida se você entende não apenas como usar o Copilot, mas como administrá-lo com segurança e controle.

Estrutura do exame AB-900

Meu Plano de Estudo (1 Semana)

Com a ajuda do NotebookLM e a experiência prévia que eu já tinha, precisei de aproximadamente uma semana de foco total para realizar o exame.

1. Revisão da Base (Domínio 1)

Para quem opera Exchange e SharePoint, essa é a “zona de conforto”. Usei o NotebookLM para gerar resumos focados em detalhes que a prova cobra, como: diferenças cruciais entre tipos de grupos, configurações de domínio no tenant e políticas de compartilhamento (sharing policies).

2. O Coração da Prova: Purview e Segurança (Domínio 2)

Aqui o exame exige atenção redobrada. O foco é como a segurança tradicional se aplica ao contexto de IA:

• Microsoft Purview: Políticas de DLP e Sensitivity Labels (essenciais para o Copilot respeitar dados sensíveis).
• Microsoft Entra: Acesso Condicional e troubleshooting de sign-in.
• Zero Trust: Como os três princípios se aplicam a permissões no contexto de IA.

3. Copilot e Agentes na Prática (Domínio 3)

A parte mais “fresca” da prova. Foquei em:

• Licenciamento: Diferença entre assinatura mensal tradicional e o modelo pay-as-you-go.
• Copilot Studio: Ciclo de vida dos agentes (criação, publicação e monitoramento no Power Platform Admin Center).
• Monitoramento de Uso: Relatórios no M365 Admin Center e insights operacionais.

Recursos que Recomendo (de verdade!)

1. Study Guide Oficial: É o seu mapa obrigatório. Ele lista exatamente os tópicos cobertos.
2. Microsoft Learn (Curso AB-900T00-A): Gratuito, estruturado e totalmente alinhado ao exame.
3. Exam Sandbox da Microsoft: Use para se acostumar com as questões de hotspot e drag-and-drop antes do dia oficial.
4. NotebookLM: Usei para processar a documentação oficial e gerar áudios e cards de revisão.
5. Tenant de Testes: Nada substitui o hands-on. Explore o Copilot Admin Center e as configurações do Power Platform.

Dica de Prova: O exame é muito orientado a cenários. Espere perguntas do tipo: “Uma organização quer garantir que o Copilot não acesse documentos confidenciais. Qual recurso você configura?”. A resposta exige saber o papel das Sensitivity Labels na prática.

Conclusão

O AB-900 chegou no momento certo. A onda de Copilot nas empresas está criando uma demanda real por profissionais que saibam administrar com segurança e governança. Se você já domina o ecossistema M365, você já está a meio caminho da certificação.

Fui, estudei e passei. Valeu cada minuto investido.

E você, já está estudando para o AB-900 ou tem alguma dúvida sobre a preparação? Deixa aqui nos comentários! E se você já fez a prova, conta como foi a sua experiência.

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:

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?

Recentemente, recebi mensagens de profissionais que reclamam sobre como é difícil controlar essas licenças e evitar gastos desnecessários. A boa notícia? Dá para automatizar isso com PowerShell, e eu vou mostrar como.

Antes de começar, já vou avisar que não é algo super simples, mas é totalmente possível e vai te ajudar demais, especialmente se você não quer perder tempo fazendo isso tudo na mão, todo mês.

Por que identificar licenças ociosas é importante?

Você já parou para pensar quantas licenças do Microsoft 365 sua empresa paga e que não estão sendo usadas? Isso pode representar um gasto enorme todo mês, porque essas licenças ficam ativas mesmo sem uso.

Se o financeiro souber quais licenças estão paradas, pode cancelar essas assinaturas e economizar um bom dinheiro. Além disso, ajuda na segurança, porque menos contas ativas significam menos riscos.

O poder do PowerShell para resolver isso

Com PowerShell, você pode consultar o Microsoft 365, identificar quais usuários têm licença e não acessaram nada nos últimos 90 dias (ou outro período que desejar). Depois, gerar um relatório fácil de entender, em HTML, para mostrar para o financeiro ou seu gestor.

E o melhor: você pode agendar essa verificação para rodar automaticamente, sem precisar lembrar disso todo mês.

Pré-requisitos para rodar o script

Antes de rodar o script que vou mostrar, você precisa ter:

• Uma conta com permissões de administrador no Microsoft 365 (Azure AD).

• PowerShell 7 ou superior instalado na sua máquina.

• O módulo Microsoft.Graph para PowerShell instalado (o script já verifica e instala se não tiver).

• Conexão com a internet ativa.

• Permissão para usar o Microsoft Graph API com o escopo User.Read.All.

O script que faz isso tudo pra você

Abaixo está o script completo. Ele conecta no Microsoft 365, busca os usuários com licenças e que não acessaram os serviços nos últimos 90 dias, e cria um relatório em HTML bem organizado.

<#
.DESCRIPTION
    Script para gerar um relatório de usuários do Microsoft 365 que possuem licenças atribuídas, mas não acessaram a conta nos últimos 90 dias. 
    O relatório é gerado em formato HTML e salvo na pasta atual.
.AUTHOR
    Paulo Costa

.EXAMPLE
   .\relatorio365lic.ps1
    Executa o script para gerar o relatório de usuários inativos com licenças atribuídas.

.PREREQUISITES
    - Módulo Microsoft.Graph instalado.
    - Permissões de leitura de usuários no Microsoft Graph (User.Read.All).
    - PowerShell 7.0 ou superior recomendado.
    - Compatível com PowerShell 5.1, mas com limitações de performance.
#>

if (-not (Get-Module -ListAvailable -Name Microsoft.Graph)) {
    Write-Host "Módulo Microsoft.Graph não encontrado. Instalando..." -ForegroundColor Yellow
    Install-Module Microsoft.Graph -Scope CurrentUser -Force
}

Import-Module Microsoft.Graph

Write-Host "Conectando ao Microsoft Graph..." -ForegroundColor Cyan
Connect-MgGraph -Scopes User.Read.All

$DataCorte = (Get-Date).AddDays(-90)

Write-Host "Buscando usuários com licenças e inativos há mais de 90 dias..." -ForegroundColor Cyan

$usuarios = Get-MgUser -All -Property DisplayName, UserPrincipalName, AssignedLicenses, SignInActivity

$UsuariosInativos = $usuarios | Where-Object {
    $_.AssignedLicenses.Count -gt 0 -and (
        $_.SignInActivity.LastSignInDateTime -eq $null -or 
        [datetime]$_.SignInActivity.LastSignInDateTime -lt $DataCorte
    )
}

if ($UsuariosInativos.Count -eq 0) {
    Write-Host "Nenhum usuário inativo encontrado com licença atribuída." -ForegroundColor Green
    exit
}

$htmlReport = @"
<html>
<head>
    <title>Relatório de Licenças Microsoft 365 Inativas</title>
    <style>
        body { font-family: Arial, sans-serif; background-color:#f4f4f4; }
        table { border-collapse: collapse; width: 100%; background-color: #fff; }
        th, td { padding: 12px; border: 1px solid #ddd; text-align: left; }
        th { background-color: #0078d4; color: white; }
        tr:hover { background-color: #e1f5fe; }
    </style>
</head>
<body>
    <h2>Relatório de Licenças Microsoft 365 Inativas (mais de 90 dias)</h2>
    <p><strong>Empresa:</strong> Paulo Costa TI</p>
    <p><strong>Data:</strong> $(Get-Date -Format 'dd/MM/yyyy')</p>
    <p><strong>Gerado por:</strong> $env:USERNAME</p>
    <table>
        <tr>
            <th>Nome</th>
            <th>Email</th>
            <th>Último Login</th>
        </tr>
"@

foreach ($user in $UsuariosInativos) {
    $lastSignIn = if ($user.SignInActivity.LastSignInDateTime) {
        [datetime]$user.SignInActivity.LastSignInDateTime
    } else {
        "Nunca"
    }

    $htmlReport += @"
        <tr>
            <td>$($user.DisplayName)</td>
            <td>$($user.UserPrincipalName)</td>
            <td>$lastSignIn</td>
        </tr>
"@
}

$htmlReport += @"
    </table>
</body>
</html>
"@

$reportPath = Join-Path -Path $PWD -ChildPath "LicencasInativas_$(Get-Date -Format 'yyyyMMdd_HHmmss').html"
$htmlReport | Out-File -FilePath $reportPath -Encoding UTF8

Write-Host "Relatório gerado com sucesso em: $reportPath" -ForegroundColor Green

Exemplo do relatório:

Como usar:

1. Abra o PowerShell 7 ou superior como administrador.

1. Abra o PowerShell 7 ou superior como administrador.
2. Copie e cole o script ou salve num arquivo .ps1.
3. Execute o script. Ele vai pedir para você se conectar no Microsoft 365.
4. Após a conexão, ele vai gerar um relatório HTML na pasta onde você rodou o script.
5. Abra o arquivo HTML no navegador e veja as licenças que estão inativas.

Quer mais scripts prontos e dicas para automatizar seu dia a dia?

Eu tenho uma área especial no meu GitHub onde compartilho scripts PowerShell como esse e outros que vão ajudar muito no seu trabalho, te economizar horas e mostrar seu valor na empresa.

Se liga lá no meu perfil e fique de olho nas novidades. Curte, comenta, compartilha e segue para não perder nada!

Automatizar tarefas com PowerShell é um divisor de águas para quem quer crescer na área de TI e mostrar resultados concretos. Então, bora colocar a mão na massa e parar de perder tempo com tarefas repetitivas?

Hoje vamos falar sobre um processo que todo administrador de TI já passou: o desligamento de um colaborador. E eu não estou falando só de cortar o acesso ao computador, mas de todos os outros serviços que o usuário utiliza no Microsoft 365: e-mail, Teams, OneDrive, licenças e por aí vai.

Você já deve ter passado pela situação de ter que desativar um usuário no Microsoft 365 e fazer isso manualmente: bloquear login, remover licenças, configurar resposta automática, redirecionar e-mails… Tudo isso toma tempo e, na maioria das vezes, envolve alguns passos que podem ser esquecidos.

E se eu te dissesse que dá pra automatizar tudo isso com um simples script em PowerShell?

O que o script vai fazer

Aqui está a magia: com um script simples, vamos:

E, claro, gerar um log local de tudo o que foi feito

• Bloquear o login do usuário

• Remover as licenças do Microsoft 365

• Configurar a mensagem de ausência automática no Outlook

• Redirecionar os e-mails para o gestor

• Desabilitar o MFA (caso o colaborador tenha)

O Script para fazer isso

Aqui está o código que vai fazer todo o trabalho pesado:

param(
    [Parameter(Mandatory)]
    [string]$EmailUsuario,

    [Parameter(Mandatory)]
    [string]$EmailGestor
)

Connect-MgGraph -Scopes "User.ReadWrite.All", "Mail.ReadWrite", "Organization.Read.All"
Update-MgUser -UserId $EmailUsuario -AccountEnabled:$false
$usuario = Get-MgUser -UserId $EmailUsuario
$usuario.AssignedLicenses | ForEach-Object {
    Set-MgUserLicense -UserId $EmailUsuario -RemoveLicenses $_.SkuId -AddLicenses @()
}
#Aqui você pode colocar uma msg de ausencia 
$mensagem = "Este colaborador não faz mais parte da empresa. Em caso de urgência, contate $EmailGestor."
Set-MailboxAutoReplyConfiguration -Identity $EmailUsuario -AutoReplyState Enabled -InternalMessage $mensagem -ExternalMessage $mensagem

#Nessa parte aqui ta redirecionando para o gestor
Set-Mailbox -Identity $EmailUsuario -ForwardingSMTPAddress $EmailGestor -DeliverToMailboxAndForward $false

$authMethods = Get-MgUserAuthenticationMethod -UserId $EmailUsuario
foreach ($method in $authMethods) {
    Remove-MgUserAuthenticationMethod -UserId $EmailUsuario -AuthenticationMethodId $method.Id
}

#aqui fica o log, é sempre importante guardar logs rsrs
$log = "[{0}] Usuário $EmailUsuario desativado, e-mail redirecionado para $EmailGestor" -f (Get-Date)
Add-Content -Path "C:\Temp\Log_Desativacoes.txt" -Value $log

Write-Host "Processo de desativação concluído para $EmailUsuario"

Como usar

Basta salvar o script em um arquivo .ps1 (ex: Desativar-Usuario.ps1) e rodar com os parâmetros necessários:

.\Desativar-Usuario.ps1 -EmailUsuario "zeca@paulocostati.com.br" -EmailGestor "paulo@paulocostati.com.br"

O PowerShell vai realizar todas as etapas automaticamente. Simples assim.

E agora?

Você pode usar esse script de diversas formas:

• CSV em lote: Se tiver vários usuários para desativar, pode criar um CSV com as informações e rodar o script para todos de uma vez.
• Power Automate: Se quiser integrar com o fluxo de trabalho no Microsoft 365, pode disparar o script via Power Automate.
• Ansible: Tem um ambiente mais complexo? Dá para rodar esse PowerShell automaticamente através de Ansible.

Conclusão

E aí, gostou da ideia de automatizar esse processo? O que antes poderia ser um trabalho manual e demorado, agora pode ser feito de forma rápida e sem erro com apenas um clique.

Esse é o tipo de automação que realmente faz a diferença no dia a dia da administração de TI.