A boa notícia? Todas essas mudanças tornam o Exchange mais seguro. A má notícia? Se você não se preparar agora, vai descobrir na pior hora possível.

Neste artigo, vou detalhar cada uma dessas mudanças, explicar o impacto real na sua rotina de administrador e o mais importante mostrar exatamente o que fazer para se proteger antes dos deadlines.

1. Graph API: Seus Apps Não Vão Mais Poder Editar E-mails Recebidos

A mudança mais impactante para desenvolvedores chegou em 24 de março de 2026: a Microsoft anunciou que aplicações que usam a Graph API para modificar propriedades sensíveis de e-mails recebidos (assunto, corpo, destinatários) terão acesso bloqueado.

O que muda na prática?

Hoje, qualquer app com permissão `Mail.ReadWrite` pode alterar e-mails que já foram entregues na caixa de entrada. Isso era usado para classificações automáticas, limpeza de dados e integrações de CRM. A partir de 31 de dezembro de 2026, essas operações exigirão uma permissão específica e mais restritiva: `Mail-Advanced.ReadWrite`.

Por que a Microsoft está fazendo isso?

O conceito é imutabilidade de mensagens. E-mails recebidos são registros que muitas vezes servem como evidência legal ou compliance. Permitir que apps modifiquem esses e-mails silenciosamente cria riscos sérios de integridade de dados.

O que você precisa fazer agora

1. Audite seus apps — No [Azure AD App Registrations](https://entra.microsoft.com/), liste todos os apps com permissão `Mail.ReadWrite` e verifique se algum modifica e-mails recebidos

2. Solicite a nova permissão — Adicione `Mail-Advanced.ReadWrite` aos apps que realmente precisam editar e-mails entregues

3. Teste antes do enforcement — O período de transição vai até 31/12/2026. Não espere dezembro para descobrir que algo quebrou

 Fonte: [Upcoming Breaking Changes to Modifying Sensitive Email Properties via Graph API](https://techcommunity.microsoft.com/blog/exchange/upcoming-breaking-changes-to-modifying-sensitive-email-properties-via-graph-api/4505227) — Exchange Team Blog, 24/Mar/2026

2. PowerShell: O Parâmetro -Credential Vai Deixar de Funcionar

Se você administra Exchange Online via PowerShell, provavelmente já usou algo assim:

$cred = Get-Credential

Connect-ExchangeOnline -Credential $cred

Esse padrão está com os dias contados. A Microsoft anunciou a deprecação do parâmetro -Credential no módulo Exchange Online PowerShell. A autenticação básica com credenciais armazenadas simplesmente vai parar de funcionar.

Por que isso importa tanto?

Muitos administradores têm scripts agendados (scheduled tasks, Azure Automation runbooks, pipelines CI/CD) que usam `-Credential` para se conectar automaticamente ao Exchange Online. Quando o parâmetro for removido, todos esses scripts vão falhar silenciosamente.

Como migrar

A solução é migrar para autenticação moderna usando certificados ou managed identities:

# Autenticação via certificado (recomendado para scripts)
Connect-ExchangeOnline `
  -CertificateThumbprint "SEU_THUMBPRINT" `
  -AppId "SEU_APP_ID" `
  -Organization "seudominio.onmicrosoft.com"

# Autenticação interativa (para uso manual)
Connect-ExchangeOnline -UserPrincipalName admin@seudominio.com

Checklist de migração

• [ ] Liste todos os scripts que usam `Connect-ExchangeOnline -Credential`

• [ ] Crie um App Registration no Entra ID com permissões de Exchange

• [ ] Gere e instale um certificado para autenticação

• [ ] Atualize cada script para usar `-CertificateThumbprint`

• [ ] Teste em ambiente de homologação antes de substituir em produção

Fonte: [Deprecation of the -Credential Parameter in Exchange Online PowerShell](https://techcommunity.microsoft.com/blog/exchange/deprecation-of-the–credential-parameter-in-exchange-online-powershell/4494584) — Exchange Team Blog, Fev/2026

3. EWS Está Sendo Aposentado: Se Você Ainda Usa, É Hora de Correr

O Exchange Web Services (EWS) foi por anos a API principal para integrar com o Exchange. Calendários, e-mails, contatos tudo passava pelo EWS. Mas a Microsoft já vem sinalizando sua aposentadoria há algum tempo, e agora publicou um guia prático de remediação para ajudar organizações a se desligarem do EWS antes do fim.

O risco real

O problema não é seus scripts. O problema é que você pode nem saber que usa EWS. Muitas aplicações de terceiros como sistemas de helpdesk, CRM, backup e assinatura de e-mail usam EWS nos bastidores. Quando o EWS for desativado, essas integrações vão parar.

Como descobrir o que usa EWS no seu tenant

A Microsoft publicou orientações detalhadas de como encontrar e remediar o uso de EWS no seu ambiente. O processo envolve:

1. Verificar logs no Entra ID — Procure sign-ins com o resource “Office 365 Exchange Online” que usam EWS como protocolo

2. Usar o relatório de uso de apps — No Exchange Admin Center, verifique quais aplicações estão fazendo chamadas EWS

3. Contactar fornecedores — Para apps de terceiros, pergunte ao fornecedor se já migraram para a Graph API

4. Migrar código próprio — Substitua chamadas EWS pela [Microsoft Graph API](https://learn.microsoft.com/graph/api/resources/mail-api-overview), que é o sucessor oficial

Não espere o último dia

A tendência é clara: EWS não vai receber novas funcionalidades e a Microsoft está ativamente guiando todos para a Graph API. Quanto antes você fizer o inventário, menor o risco de surpresas.

Fonte: [Notes from the Field: Finding and Remediating EWS App Usage Before Retirement](https://techcommunity.microsoft.com/blog/exchange/notes-from-the-field-finding-and-remediating-ews-app-usage-before-retirement/4496469) — Exchange Team Blog, Fev/2026

4. SMTP DANE e MTA-STS: Segurança de Transporte com Controle Granular

Nem toda mudança é sobre coisas quebrando. Algumas são sobre o Exchange ficando genuinamente mais seguro. Em 10 de março de 2026, a Microsoft anunciou suporte a modos configuráveis de SMTP DANE (DNS-based Authentication of Named Entities) e MTA-STS (Mail Transfer Agent Strict Transport Security) em conectores outbound.

O que isso significa para você?

Antes, o Exchange Online usava criptografia oportunista por padrão: tentava TLS, mas se o servidor destino não suportasse, enviava em texto plano. Agora, você pode escolher entre três modos por conector:

Na prática

Se você tem parceiros de negócio com quem troca informações sensíveis (jurídico, financeiro, saúde), agora pode criar um conector específico para esses domínios com modo Mandatory, garantindo que os e-mails nunca sejam transmitidos sem criptografia verificada.

Para o restante do tráfego, manter Opportunistic é o caminho mais seguro sem impactar a entrega.

Fonte: [Announcing SMTP DANE & MTA-STS Connector Modes in Exchange Online](https://techcommunity.microsoft.com/blog/exchange/announcing-smtp-dane–mta-sts-connector-modes-in-exchange-online/4501005) — Exchange Team Blog, 10/Mar/2026

5. O Que Mais Está Chegando: IA e Compliance

Além das mudanças que exigem ação imediata, a Microsoft está investindo em duas áreas que vão mudar a forma como administramos o Exchange:

Troubleshooting com IA para Purview

O novo AI-Powered Troubleshooter para Microsoft Purview Data Lifecycle Management usa inteligência artificial para diagnosticar problemas de retenção e compliance automaticamente. Em vez de você vasculhar logs manualmente, a IA identifica a causa raiz e sugere ações corretivas. Isso é especialmente útil para organizações que enfrentam auditorias regulares.

Priority Cleanup V2

A Microsoft está desenvolvendo a segunda versão do Priority Cleanup ferramenta para exclusão urgente de conteúdo em mailboxes (data spillage, conteúdo sensível vazado). O V2 promete velocidade significativamente maior, workflow de aprovação melhorado e experiência de administrador simplificada. A Microsoft está ativamente pedindo feedback da comunidade para priorizar melhorias.

Seu Plano de Ação: O Que Fazer Esta Semana

• [ ] Audite seus scripts PowerShell — Procure por `-Credential` no seu repositório de scripts

• [ ] Verifique uso de EWS — Consulte os logs do Entra ID para saber quais apps usam EWS

Este mês

• [ ] Inventarie apps com Graph API — Liste quais usam `Mail.ReadWrite` e modificam e-mails recebidos

• [ ] Inicie migração do -Credential — Crie o App Registration e certificado para autenticação moderna

Até o fim do semestre

• [ ] Configure SMTP DANE — Defina modo Mandatory para parceiros de alta segurança

• [ ] Solicite `Mail-Advanced.ReadWrite` — Para apps que precisam continuar editando e-mails (deadline: 31/12/2026)

• [ ] Elimine dependências de EWS — Migre ou substitua todas as integrações que ainda usam EWS

Conclusão

O Exchange Online em 2026 está mais seguro, mais controlado e mais alinhado com padrões modernos de autenticação e criptografia. Mas segurança vem com responsabilidade: se você não atualizar seus scripts, permissões e integrações, eles vão quebrar.

A boa notícia é que nenhuma dessas mudanças é surpresa. A Microsoft está dando prazos claros e documentação detalhada. O que falta é você bloquear algumas horas na agenda e fazer o inventário.

Comece hoje pelo mais simples: abra seu repositório de scripts e procure por `-Credential`. Se encontrar, você já tem trabalho pela frente.

Fontes

1. [Upcoming Breaking Changes to Modifying Sensitive Email Properties via Graph API](https://techcommunity.microsoft.com/blog/exchange/upcoming-breaking-changes-to-modifying-sensitive-email-properties-via-graph-api/4505227) — Exchange Team Blog, 24/Mar/2026

2. [Deprecation of the -Credential Parameter in Exchange Online PowerShell](https://techcommunity.microsoft.com/blog/exchange/deprecation-of-the–credential-parameter-in-exchange-online-powershell/4494584) — Exchange Team Blog, Fev/2026

3. [Notes from the Field: Finding and Remediating EWS App Usage Before Retirement](https://techcommunity.microsoft.com/blog/exchange/notes-from-the-field-finding-and-remediating-ews-app-usage-before-retirement/4496469) — Exchange Team Blog, Fev/2026

4. [Announcing SMTP DANE & MTA-STS Connector Modes in Exchange Online](https://techcommunity.microsoft.com/blog/exchange/announcing-smtp-dane–mta-sts-connector-modes-in-exchange-online/4501005) — Exchange Team Blog, 10/Mar/2026

5. [AI-Powered Troubleshooting for Microsoft Purview DLM](https://techcommunity.microsoft.com/blog/exchange/ai-powered-troubleshooting-for-microsoft-purview-data-lifecycle-management-now-a/4502744) — Exchange Team Blog, Mar/2026

6. [Give Us Feedback on Faster, Simpler Data Purging for Exchange Online](https://techcommunity.microsoft.com/blog/exchange/give-us-feedback-on-faster-simpler-data-purging-for-exchange-online/4503905) — Exchange Team Blog, 19/Mar/2026

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?