Governança do Teams: quem cria equipe e quando ela expira

Em resumo

• A TI define quem cria equipe com um grupo de segurança e uma configuração de grupos do diretório feita no PowerShell do Microsoft Graph, e define quando a equipe expira com a política de expiração de grupos do Microsoft 365 no Entra ID.
• Só existe uma política de expiração para toda a organização, e o Entra ID renova sozinho os grupos com uso recente em Outlook, SharePoint, Teams e Viva Engage, então o que expira é o que ficou parado.
• A expiração exige licenças Entra ID P1 ou P2 para os membros dos grupos alcançados, e o grupo que o dono não renova é excluído junto com a equipe, com restauração em até 30 dias segundo a documentação atual.
• A restrição de criação vale para todo serviço que depende de grupo do Microsoft 365, não só para o Teams, e por isso as áreas precisam ser avisadas antes de ela ser ligada.
• Em ambiente pequeno, com equipes de dono claro, o melhor é não ligar nada, porque a posição padrão da Microsoft é manter a criação aberta.

Como definir quem cria equipe no Teams e quando ela expira?

Quem cria equipe é definido restringindo a criação de grupos do Microsoft 365 a um grupo de segurança, o que se configura no objeto de configurações de grupos do diretório pelo PowerShell do Microsoft Graph. A validade é definida na política de expiração de grupos do Entra ID, que renova automaticamente o grupo com atividade recente e exclui o que ninguém usa nem renova.

As duas configurações são independentes, e a segunda é a que mais assusta as áreas, porque a documentação do Entra ID sobre expiração de grupos deixa claro que o grupo não renovado é excluído, e a equipe do Teams é um grupo do Microsoft 365 com uma camada de canais por cima. Numa herança de algumas centenas de equipes, boa parte foi criada para um projeto que acabou, e uma parcela não tem proprietário porque a pessoa saiu da empresa. O roteiro abaixo mede esse legado primeiro, depois fecha a porta de entrada, depois põe validade no que já existe, e só então monta o caminho oficial para pedir equipe nova.

Há um caso em que o roteiro inteiro é exagero: ambiente pequeno, com equipes de dono claro e poucos criadores. A documentação sobre quem pode criar grupos do Microsoft 365 trata a criação aberta como a posição padrão recomendada para a maioria das organizações, e restringir sem necessidade só troca autonomia por fila de atendimento na TI. A restrição passa a compensar quando o inventário mostra equipes duplicadas, nomes sem padrão e proprietários ausentes em volume que ninguém consegue acompanhar.

O que você precisa antes de começar

• Licença: a política de expiração exige possuir, sem necessidade de atribuir, licenças Microsoft Entra ID P1 ou P2 para os membros de todos os grupos aos quais a política se aplica, conforme a página de expiração de grupos do Entra ID. Com a política em "todos os grupos", a conta de licenças cobre o tenant inteiro; com grupos selecionados, só os membros deles.
• Papel no tenant: Groups Administrator ou User Administrator para configurar a expiração, de acordo com a mesma página. Quem ajusta as configurações de grupos do diretório precisa consentir o escopo Directory.ReadWrite.All no Graph, então combine antes com quem administra o consentimento.
• Ferramenta: o SDK do Microsoft Graph PowerShell com os módulos Microsoft.Graph e Microsoft.Graph.Beta. Os módulos AzureAD e MSOnline estão descontinuados desde 30 de março de 2024, então não use scripts antigos que dependem deles.
• Uma caixa compartilhada monitorada pela TI para receber os avisos dos grupos sem proprietário, e uma lista no SharePoint para o pedido de equipe nova.

Passo a passo

A ordem importa porque a restrição de criação é a única etapa que o usuário percebe no mesmo dia, então ela vem depois do inventário e do aviso às áreas, e não antes. A validade só entra quando já se sabe quais grupos vão ser alcançados, o que evita que alguma equipe em uso expire por surpresa para quem depende dela.

A restrição de criação (passo 4) é a que o usuário sente no mesmo dia e vale para todo serviço que cria grupo, por isso o aviso às áreas vem antes dela.

1. Meça o que você herdou

Antes de mudar qualquer regra, exporte os grupos do Microsoft 365 que não têm proprietário e marque quais têm equipe. Esse arquivo vira a lista de trabalho da TI e também o argumento para as áreas, porque mostra de forma objetiva quanta coisa está sem responsável. O script abaixo percorre os grupos do tipo Unified, que é como o Entra ID chama o grupo do Microsoft 365, consulta os proprietários de cada um e grava um CSV. Em ambiente com muitos grupos ele demora, e é normal rodá-lo fora do horário.

Connect-MgGraph -Scopes "Group.Read.All"

# Todos os grupos do Microsoft 365, com a marca que indica se há equipe
$grupos = Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'Unified')" `
  -Property Id,DisplayName,CreatedDateTime,ResourceProvisioningOptions

$semDono = foreach ($g in $grupos) {
    $donos = Get-MgGroupOwner -GroupId $g.Id -All
    if (-not $donos) {
        [pscustomobject]@{
            Id        = $g.Id
            Nome      = $g.DisplayName
            Criado    = $g.CreatedDateTime
            TemEquipe = ($g.ResourceProvisioningOptions -contains "Team")
        }
    }
}

$semDono | Export-Csv -Path .\grupos-sem-dono.csv -NoTypeInformation -Encoding UTF8

2. Crie o grupo de segurança de quem pode criar equipe

No centro de administração do Microsoft Entra, vá em Identity > Groups > All groups > New group, escolha o tipo Security e dê um nome que diga a função, como SG-Criadores-de-Equipes. O rótulo dos menus aparece traduzido na interface em português, e o caminho pode variar um pouco conforme o tenant. Coloque no grupo só quem realmente precisa criar equipe fora do fluxo de pedido, que na prática é a equipe da TI e a conta de serviço que o fluxo do passo 7 vai usar. Inclua os membros diretamente no grupo, sem aninhar outros grupos, para não depender de como cada serviço trata herança.

3. Avise as áreas antes de ligar

Mande o comunicado antes do passo 4, com o que muda e quando. As áreas precisam saber cinco coisas: a partir de qual data só quem está no grupo cria equipe, por onde se pede uma equipe nova e em quanto tempo ela sai, que a mudança vale para todos os serviços que criam grupo e não só para o Teams, que a equipe sem uso passará a expirar com aviso por e-mail e no feed de proprietários do Teams, e que o proprietário precisa ser alguém que continue na área. Um proprietário só é frágil, então peça dois nomes em cada equipe.

O ponto que mais gera ruído é o segundo, porque a documentação sobre criação de grupos lembra que vários serviços dependem de grupo do Microsoft 365, entre eles o Planner, o Outlook, o Viva Engage e os sites do SharePoint ligados a grupo. Quem hoje cria um plano ou um site de equipe sozinho vai esbarrar na mesma restrição, e se o aviso só falar de Teams, o chamado chega dizendo que o Planner quebrou. Se a permissão do site depende de quem é membro do grupo, o nosso texto sobre Gerenciamento de permissões no SharePoint explica o que muda quando a equipe expira ou troca de dono.

4. Restrinja a criação de grupos pelo PowerShell do Graph

A documentação que descrevia esse procedimento foi movida para o conteúdo de versões anteriores e o caminho no centro de administração do Entra mudou, então não amarre o roteiro a um menu: o que vale é o estado do diretório, e o passo de validação abaixo o confere. A configuração se faz no objeto de configurações de grupos (Group.Unified), com duas propriedades: EnableGroupCreation em false e GroupCreationAllowedGroupId com o identificador do grupo de segurança do passo 2.

O script parte da lógica da documentação, mas lê os valores que já existem no objeto e os reenvia junto com os dois ajustes, para não zerar nenhuma outra opção que o tenant use, como a lista de palavras bloqueadas. Os cmdlets de configuração de diretório estão no módulo Beta, então teste primeiro num tenant de desenvolvimento, porque o comportamento pode mudar entre versões.

Connect-MgGraph -Scopes "Directory.ReadWrite.All","Group.Read.All"

$nomeGrupo = "SG-Criadores-de-Equipes"
$grupoId = (Get-MgGroup -Filter "displayName eq '$nomeGrupo'").Id

# Procura o objeto de configurações de grupos do tenant
$config = Get-MgBetaDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" }

# Se ainda não existir, cria a partir do modelo, com os valores padrão
if (-not $config) {
    $modelo = Get-MgBetaDirectorySettingTemplate | Where-Object { $_.DisplayName -eq "Group.Unified" }
    $padrao = @($modelo.Values | ForEach-Object { @{ name = $_.Name; value = $_.DefaultValue } })
    $config = New-MgBetaDirectorySetting -BodyParameter @{ templateId = $modelo.Id; values = $padrao }
}

# Mantém o que já existia e troca só as duas propriedades
$valores = @{}
foreach ($v in $config.Values) { $valores[$v.Name] = $v.Value }
$valores["EnableGroupCreation"] = "false"
$valores["GroupCreationAllowedGroupId"] = $grupoId

$corpo = @{
    values = @($valores.GetEnumerator() | ForEach-Object { @{ name = $_.Key; value = $_.Value } })
}
Update-MgBetaDirectorySetting -DirectorySettingId $config.Id -BodyParameter $corpo

Administradores com função privilegiada no diretório continuam podendo criar grupos mesmo sem estar no grupo de segurança, de acordo com a mesma documentação, então a TI não se tranca para fora. A mudança leva um tempo para propagar, e o usuário que ainda vê o botão de criar equipe logo depois do script não indica falha.

5. Defina a validade e a renovação por uso

No centro de administração do Entra, abra Identity > Groups > All groups > Expiration. Na página, o Group lifetime (in days) aceita valores predefinidos ou personalizados, com mínimo de 30 dias. A opção Enable expiration for these Microsoft 365 groups aceita All, Selected ou None, e a página de expiração de grupos deixa claro que hoje só é possível ter uma política para todos os grupos do Microsoft 365 da organização. Não existe prazo diferente por departamento nem por tipo de equipe.

A renovação automática é o que torna a política suportável: o Entra ID renova o grupo com atividade recente, cerca de 35 dias antes do vencimento e sem aviso ao proprietário, com base em ações como enviar e-mail ao grupo no Outlook, abrir ou enviar arquivos no SharePoint, visitar um canal no Teams e ver uma publicação no Viva Engage. No Teams a documentação cita a visita a um canal, então não presuma que qualquer outro uso renove. A renovação também não é instantânea: a atividade deixa uma marca no grupo, e a renovação acontece em até 24 horas quando o vencimento está perto.

O risco de largada é o que mais pesa no aviso às áreas. Ao ligar a política pela primeira vez, os grupos mais antigos que o prazo escolhido recebem 35 dias até expirar, a menos que sejam renovados por atividade ou pelo proprietário, então um prazo de 365 dias ligado de uma vez pode excluir, em pouco mais de um mês, as equipes paradas há mais de um ano. Por isso vale começar com Selected, limitado a 500 grupos na lista, e só depois passar para All, que não tem esse limite. O piloto também reduz o alcance da conta de licenças Entra ID P1 ou P2 durante o teste.

6. Aponte o e-mail para os grupos sem proprietário

Na mesma página de expiração, preencha o campo de e-mail que recebe os avisos de renovação e expiração dos grupos sem proprietário, usando a caixa compartilhada da TI e não o e-mail de uma pessoa. Na tela os dois passos se salvam juntos, e o script abaixo faz o mesmo: cria a política em modo piloto, adiciona um grupo e depois estende a todos.

Connect-MgGraph -Scopes "Directory.ReadWrite.All"

# Piloto: só os grupos adicionados entram na política
$politica = New-MgGroupLifecyclePolicy -GroupLifetimeInDays 365 `
  -ManagedGroupTypes "Selected" `
  -AlternateNotificationEmails "governanca-m365@contoso.com"

Add-MgGroupToLifecyclePolicy -GroupLifecyclePolicyId $politica.Id -GroupId "ID-DO-GRUPO-PILOTO"

# Quando o piloto passar, estende a política para todos os grupos
Update-MgGroupLifecyclePolicy -GroupLifecyclePolicyId $politica.Id `
  -GroupLifetimeInDays 365 -ManagedGroupTypes "All" `
  -AlternateNotificationEmails "governanca-m365@contoso.com"

Há uma pegadinha que a caixa compartilhada sozinha não resolve: o grupo ativo e sem proprietário é renovado automaticamente pelo uso e nunca dispara aviso, então ele continua órfão indefinidamente. Quem recebe o e-mail só vê o grupo parado. O inventário do passo 1 precisa ser repetido de tempos em tempos, e a correção de um órfão com uso é nomear um proprietário:

Connect-MgGraph -Scopes "Group.ReadWrite.All"

New-MgGroupOwnerByRef -GroupId "ID-DO-GRUPO" `
  -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/ID-DO-USUARIO"

7. Monte o pedido de equipe nova

Com a criação fechada, a TI precisa de um caminho oficial que não vire gargalo. Uma lista do SharePoint com fluxo do Power Automate resolve, e a escolha de desenho que mais pesa é quem cria a equipe: se o fluxo colocar o solicitante no grupo de segurança, ele passa a poder criar equipe à vontade, e a restrição perde o sentido. O desenho mais seguro é o fluxo criar a equipe com uma conta de serviço que está no grupo, definindo o solicitante como proprietário. Os campos da lista:

• Nome da equipe, seguindo o padrão de nomenclatura que a TI definir.
• Finalidade, em uma frase, e a data prevista de término quando for um projeto.
• Proprietário principal e segundo proprietário, ambos do tipo Pessoa e obrigatórios.
• Status do pedido e, depois da criação, o identificador da equipe, que alimenta o inventário.

O fluxo segue a ordem abaixo, que parte do pedido registrado na lista e termina com a equipe criada e o solicitante definido como proprietário, de modo que ele nunca precise entrar no grupo de segurança para receber a equipe que pediu:

1. Gatilho do SharePoint quando um item é criado na lista.
2. Ação de aprovação, enviada ao gestor da área ou à TI, conforme a regra da empresa.
3. Se aprovado, a ação do Teams para criar a equipe, com o proprietário principal vindo do item, e a inclusão do segundo proprietário.
4. Atualização do item com o status e o identificador da equipe, e aviso ao solicitante.

A ação do Teams roda com a identidade da conexão, então use uma conta de serviço dedicada, que esteja no grupo de segurança e não dependa de uma pessoa que pode sair da empresa. Confira no seu tenant as exigências de licença da conta e dos conectores antes de publicar, porque isso muda conforme o licenciamento do Power Automate que a organização tem.

Como validar que deu certo

Comece pelo diretório, porque é nele que a restrição de criação fica configurada, e o comando abaixo mostra os dois valores dela. O esperado é EnableGroupCreation igual a false e GroupCreationAllowedGroupId com o identificador do grupo do passo 2, o que confirma que só quem está nesse grupo consegue criar equipe.

Get-MgBetaDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" } |
  Select-Object -ExpandProperty Values |
  Where-Object { $_.Name -in "EnableGroupCreation","GroupCreationAllowedGroupId" }

Get-MgGroupLifecyclePolicy

O segundo comando deve devolver uma única política, com GroupLifetimeInDays, ManagedGroupTypes e AlternateNotificationEmails iguais ao que você configurou. Depois, faça o teste de uso com duas contas: uma fora do grupo de segurança, que não deve conseguir criar equipe, e uma dentro, que deve. Dê um tempo para a propagação antes de concluir que algo falhou. Para ver quando um grupo do piloto expira, a propriedade expirationDateTime está disponível no Graph Beta:

$uri = "https://graph.microsoft.com/beta/groups/ID-DO-GRUPO" + '?$select=expirationDateTime'
Invoke-MgGraphRequest -Method GET -Uri $uri

Os grupos renovados automaticamente aparecem nos logs de auditoria do Entra ID, e é neles que você confere, depois de algumas semanas, se a atividade real das equipes está renovando o que deveria, porque é essa atividade que mantém vivo o grupo em uso e deixa expirar só o que ficou parado.

Erros comuns

• A consulta das configurações volta vazia. O tenant nunca teve o objeto Group.Unified criado, e o script do passo 4 cobre isso criando-o a partir do modelo. A mensagem exata varia com a versão do módulo, mas o sintoma é o Update falhar por não achar o identificador da configuração.
• Falha de permissão ao conectar ou ao atualizar. O escopo Directory.ReadWrite.All não foi consentido para a conta que roda o script, ou a conta não tem função suficiente no diretório.
• A criação da política falha. Só existe uma política de expiração por organização, então se alguém já criou uma, use Get-MgGroupLifecyclePolicy para achar o identificador e Update-MgGroupLifecyclePolicy para alterá-la.
• Usuário no grupo de segurança continua sem conseguir criar. Quase sempre é propagação, e quando não é, confira se a pessoa é membro direto e se o identificador gravado na configuração é o do grupo certo.
• Uma equipe sumiu. Provavelmente expirou. A documentação atual informa que o grupo é excluído um dia depois da data de expiração e que os proprietários ou o administrador podem restaurá-lo em até 30 dias, prazo que não é configurável. A página de restauração de grupos excluídos traz o procedimento, e a restauração de um grupo com sites e documentos pode levar até 24 horas. Confirme o prazo nessas páginas no dia em que for comunicar as áreas, porque ele é o número que elas mais vão citar.
• Grupo dinâmico restaurado volta vazio. Ele é tratado como grupo novo e se repovoa pela regra de associação, o que pode levar até 24 horas.
• Retenção e bloqueio legal. Se a organização usa política de retenção ou bloqueio legal, o conteúdo excluído não some de imediato: a política de retenção guarda conversas e arquivos pelo prazo definido, e a caixa em bloqueio legal é preservada. Alinhe com quem cuida de conformidade antes de ligar a expiração para todos.

O que levar para quem aprova

Depois de pronto, só quem está no grupo de segurança cria equipe fora do fluxo de pedido, as equipes sem uso passam a expirar com aviso aos proprietários, e a TI recebe numa caixa compartilhada o que ficou sem dono, o que muda a conversa de "quantas equipes temos" para "quais têm responsável". O custo está na licença Entra ID P1 ou P2 para os membros dos grupos alcançados (que precisa ser conferida contra o que o tenant já tem), na manutenção do script de inventário e do fluxo de pedido, e em algum atendimento extra no primeiro mês. O risco fica sob controle porque o piloto com grupos selecionados mostra quem seria alcançado antes de ligar para todos, a exclusão tem janela de restauração documentada de 30 dias, e a configuração e a política ficam no Entra ID, administradas pela TI mesmo depois que o fornecedor sai.

Se ajudar, a Trinapse pode entregar o modelo do comunicado às áreas e o desenho da lista de pedido de equipe, com os campos e o fluxo já montados, de modo que você só precise adaptar tudo ao seu padrão de nomenclatura.