Como gerir utilizadores, grupos e mailboxes no Microsoft 365 em 2026?

✎ Duarte Spínola | 2026-07-14

A gestão de identidades no Microsoft 365 é uma das responsabilidades mais frequentes e críticas de qualquer administrador. Em 2026, com a consolidação do Microsoft Graph PowerShell SDK como interface principal de administração e a evolução das funcionalidades de governança Entra ID, o conjunto de ferramentas e boas práticas para criar, licenciar, agrupar e desactivar utilizadores mudou substancialmente face aos primeiros anos do M365. Este artigo — Dia 2 de uma série de 6 dedicada a dotar um recurso com capacidades de administração M365 — percorre de forma prática toda a cadeia de vida do utilizador: desde a criação individual ou em massa, passando por grupos, mailboxes partilhadas, contactos externos, passwords, licenciamento, guest users B2B e, finalmente, o offboarding.

Criar e gerir utilizadores: individual e em massa via CSV

A criação de utilizadores no Microsoft 365 pode ser feita de três formas principais: através do Centro de Administração Microsoft 365 (portal web), via Microsoft Graph PowerShell SDK, ou através de operações em massa (bulk) usando ficheiros CSV.

Para criar um único utilizador no portal, navega-se para Centro de Administração > Utilizadores > Utilizadores activos > Adicionar um utilizador. O assistente solicita nome, nome de utilizador (UPN), domínio, licença e propriedades opcionais. Contudo, para ambientes com dezenas ou centenas de criações, o PowerShell é significativamente mais eficiente.

Criação individual via PowerShell

# Ligação ao Microsoft Graph com permissões necessárias

Connect-MgGraph -Scopes “User.ReadWrite.All”,”Organization.Read.All”,”Directory.ReadWrite.All”
# Definir o usage location (obrigatório antes de atribuir licenças)

New-MgUser -DisplayName “Ana Costa” `

  -GivenName “Ana” `

  -Surname “Costa” `

  -UserPrincipalName “[email protected]” `

  -MailNickname “ana.costa” `

  -PasswordProfile @{

      Password = “C0mplexa!2026”

      ForceChangePasswordNextSignIn = $true

  } `

  -AccountEnabled `

  -UsageLocation “PT”

A propriedade UsageLocation é obrigatória antes de atribuir qualquer licença, pois o Microsoft 365 valida a disponibilidade de serviços por região (código ISO de dois caracteres, ex.: PT para Portugal).

Criação em massa via CSV

Para importar múltiplos utilizadores, prepara-se um ficheiro CSV com colunas como DisplayName, UPN, Department, UsageLocation, Password:

$users = Import-Csv -Path “C:\Scripts\novos_utilizadores.csv”
foreach ($u in $users) {

    $passwordProfile = @{

        Password = $u.Password

        ForceChangePasswordNextSignIn = $true

    }
    New-MgUser -DisplayName $u.DisplayName `

      -UserPrincipalName $u.UPN `

      -MailNickname ($u.UPN -split ‘@’)[0] `

      -PasswordProfile $passwordProfile `

      -AccountEnabled `

      -UsageLocation $u.UsageLocation `

      -Department $u.Department

}

O portal também oferece um assistente de upload CSV em Utilizadores > Utilizadores activos > Adicionar utilizadores em massa, que gera um modelo descarregável e valida o ficheiro antes da importação. A vantagem do PowerShell reside no controlo programático, validação prévia e integração com pipelines de provisionamento.

Propriedades do utilizador: UPN, display name, department, usage location

Cada utilizador no Microsoft 365 possui um conjunto de propriedades que determinam a sua identidade, aparência no directório e elegibilidade para serviços. As mais relevantes para a administração diária são:

Propriedade	Descrição	Notas
UserPrincipalName (UPN)	Identificador único de autenticação (ex.: `[email protected]`)	Deve corresponder ao endereço de email principal sempre que possível; alterar o UPN exige cuidado com sincronização Entra Connect
DisplayName	Nome apresentado em toda a suite (Outlook, Teams, SharePoint)	Actualizável a qualquer momento
GivenName / Surname	Nome próprio e apelido	Usados para ordenação e listas de endereços
Department	Departamento organizacional	Usado em grupos dinâmicos e relatórios
UsageLocation	País/região (ISO 3166)	Obrigatório para atribuição de licenças
JobTitle	Cargo profissional	Opcional mas útil para GAL
Mail / MailNickname	Endereço e alias de email	O Mail é preenchido automaticamente com o UPN em tenant-only
AccountEnabled	Estado da conta (activa/bloqueada)	`true` para activa, `false` para bloquear signIn

Actualizar propriedades via PowerShell

# Actualizar departamento e cargo de um utilizador

Set-MgUser -UserId “[email protected]” `

  -Department “Financeiro” `

  -JobTitle “Controller” `

  -UsageLocation “PT”
# Desactivar uma conta (bloquear signIn sem eliminar)

Set-MgUser -UserId “[email protected]” -AccountEnabled:$false
# Consultar todas as propriedades

Get-MgUser -UserId “[email protected]” | Format-List DisplayName, UserPrincipalName, Department, UsageLocation, AccountEnabled

Uma atenção particular deve ser dada ao UPN: em ambientes com sincronização Entra Connect (híbrido), o UPN é definido no Active Directory on-premises e sincronizado para a nuvem. Alterar o UPN directamente na nuvem sem coordenar com o AD local resulta em inconsistências e potencial perda de acesso.

Tipos de grupos: Microsoft 365 Groups, Security Groups, Distribution Lists e Mail-enabled Security Groups

O Microsoft 365 oferece quatro tipos principais de grupos, cada um com um propósito distinto. Compreender as diferenças é essencial para não criar estruturas de governance incorrectas.

Microsoft 365 Groups

Os Microsoft 365 Groups (anteriormente “Office 365 Groups”) são o modelo de colaboração padrão. Cada grupo cria automaticamente:

Uma mailbox de grupo partilhada
Um site SharePoint
Um notebook OneNote
Um planner
Uma equipa Microsoft Teams (opcional, mediante conversão)

São ideais para projectos, equipas e colaboração transversal. O membership pode ser estático ou dinâmico.

Security Groups

Security Groups servem para atribuir permissões a recursos — SharePoint, Azure, aplicações, políticas de acesso condicional. Não têm mailbox nem funcionalidades de colaboração. São a base do controlo de acesso baseado em grupos (RBAC) no ecossistema M365.

Distribution Lists (Listas de Distribuição)

Listas de distribuição são grupos com finalidade exclusivamente de email. Permitem enviar mensagens a múltiplos destinatários através de um único endereço. Não suportam colaboração nem atribuição de permissões a recursos. Em 2026, a Microsoft recomenda a migração gradual para Microsoft 365 Groups, que oferecem superconjunto de funcionalidades.

Mail-enabled Security Groups

Combinação de Security Group com capacidade de envio/recepção de email. Úteis quando se precisa de atribuir permissões a um recurso e simultaneamente permitir que o grupo receba email (ex.: [email protected] que recebe alertas e tem acesso a um site SharePoint restrito).

Característica	M365 Group	Security Group	Distribution List	Mail-enabled Security
Mailbox de grupo	Sim	Não	Sim (apenas distribuição)	Sim
Site SharePoint	Sim	Não	Não	Não
Teams	Sim (opcional)	Não	Não	Não
Atribuir permissões	Limitado	Sim	Não	Sim
Membership dinâmico	Sim	Sim	Não	Não
Criação por utilizadores	Configurável	Não	Não	Não

Criar grupos via PowerShell

# Microsoft 365 Group

New-MgGroup -DisplayName “Equipa Projecto Atlas” `

  -Description “Colaboração do Projecto Atlas” `

  -MailEnabled:$true `

  -SecurityEnabled:$true `

  -MailNickname “proj-atlas” `

  -GroupTypes @(“Unified”)
# Security Group

New-MgGroup -DisplayName “Administradores SharePoint” `

  -Description “Acesso administrativo a sites SharePoint” `

  -MailEnabled:$false `

  -SecurityEnabled:$true
# Listar membros de um grupo

Get-MgGroupMember -GroupId (Get-MgGroup -Filter “displayName eq ‘Equipa Projecto Atlas'”).Id

Grupos dinâmicos vs estáticos: regras de membership

Um dos avanços mais úteis na gestão de identidades M365 é o membership dinâmico de grupos. Em vez de adicionar e remover membros manualmente, as regras de membership dinâmico avaliam automaticamente as propriedades de cada utilizador e incluem ou excluem membros conforme essas regras.

Grupos estáticos

Os membros são adicionados e removidos manualmente (via portal ou PowerShell). Adequados para pequenas equipas fixas ou grupos onde a associação não segue um padrão automatizável.

# Adicionar membro a um grupo estático

$user = Get-MgUser -UserId “[email protected]”

$group = Get-MgGroup -Filter “displayName eq ‘Administradores SharePoint'”
New-MgGroupMember -GroupId $group.Id -DirectoryObjectId $user.Id

Grupos dinâmicos

As regras são escritas numa sintaxe própria baseada em propriedades do utilizador ou dispositivo. Por exemplo, um grupo dinâmico que inclua automaticamente todos os utilizadores do departamento Financeiro com conta activa:

user.department -eq “Financeiro” -and user.accountEnabled -eq true

Para criar um grupo dinâmico via PowerShell:

New-MgGroup -DisplayName “Financeiro – Dinamico” `

  -Description “Todos os utilizadores do Financeiro” `

  -MailEnabled:$false `

  -SecurityEnabled:$true `

  -GroupTypes @(“DynamicMembership”) `

  -MembershipRule ‘user.department -eq “Financeiro” -and user.accountEnabled -eq true’ `

  -MembershipRuleProcessingState “On”

Exemplos de regras de membership dinâmico

Cenário	Regra
Todos do departamento TI	`user.department -eq "IT"`
Utilizadores em Portugal	`user.usageLocation -eq "PT"`
Gestores com conta activa	`user.jobTitle -startsWith "Gestor" -and user.accountEnabled -eq true`
Membros de um país OU departamento	`user.country -eq "Portugal" -or user.department -eq "Vendas"`
Todos excepto contractors	`user.userType -ne "Guest" -and user.employeeType -ne "Contractor"`

Os grupos dinâmicos exigem licença Entra ID Premium P1 (incluída no Microsoft 365 E3/E5 ou como licença standalone). O processamento de regras pode demorar alguns minutos após a criação ou alteração da regra. Uma limitação importante: os Microsoft 365 Groups suportam membership dinâmico apenas para utilizadores (não dispositivos), enquanto Security Groups suportam ambos.

Shared mailboxes: criar, permissões e converter para user mailbox

Shared mailboxes são mailboxes partilhadas por múltiplos utilizadores, sem necessidade de licença individual (até 50 GB sem licença, ou 100 GB com licença Exchange Online Plan 2). São usadas para endereços genéricos como info@, suporte@, rh@.

Criar uma shared mailbox

No portal: Centro de Administração > Equipas e grupos > Mailboxes partilhadas > Adicionar uma mailbox.

Via PowerShell (Exchange Online):

# Ligação ao Exchange Online

Connect-ExchangeOnline
# Criar shared mailbox

New-Mailbox -Shared -Name “Apoio ao Cliente” `

  -DisplayName “Apoio ao Cliente” `

  -Alias “apoio”
# Atribuir permissões Full Access e Send As

Add-MailboxPermission -Identity “[email protected]” `

  -User “[email protected]” `

  -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity “[email protected]” `

  -Trustee “[email protected]” `

  -AccessRights SendAs -Confirm:$false

A permissão Full Access permite ao utilizador abrir a mailbox e ler/enviar email. A permissão Send As permite enviar em nome do endereço da shared mailbox. Ambas são normalmente atribuídas em conjunto.

Para mais detalhes sobre criação e configuração de shared mailboxes, consultar a documentação oficial da Microsoft sobre criar shared mailboxes.

Converter uma user mailbox em shared mailbox

Cenário típico durante offboarding: preservar o email de um colaborador que sai sem manter uma licença activa.

# Converter user mailbox em shared mailbox

Set-Mailbox -Identity “[email protected]” -Type Shared
# Remover licença do utilizador (após conversão)

Set-MgUserLicense -UserId “[email protected]” -RemoveLicenses @(“contoso:SPE_E3”)

Converter uma shared mailbox em user mailbox

Se for necessário restabelecer o acesso individual:

Set-Mailbox -Identity “[email protected]” -Type Regular

Após a conversão, é obrigatório atribuir uma licença Exchange Online ao utilizador, caso contrário a mailbox fica inacessível após 30 dias. Para contexto sobre planos de mailbox e requisitos de licenciamento, consultar a documentação sobre mailbox plans no Exchange Online.

Resource mailboxes: salas e equipamentos

Resource mailboxes representam espaços físicos (salas de reunião) ou equipamentos (projectores, viaturas) que podem ser reservados via Outlook. Existem dois tipos:

Room mailboxes: salas de reunião, auditórios, espaços físicos.
Equipment mailboxes: equipamentos partilhados com calendário de reservas.

Criar uma room mailbox

# Criar mailbox de sala

New-Mailbox -Room -Name “Sala Lisboa” `

  -DisplayName “Sala Lisboa (Capacidade 12)” `

  -Alias “sala-lisboa”
# Configurar propriedades da sala

Set-Mailbox -Identity “[email protected]” `

  -ResourceCapacity 12 `

  -MailTip “Esta sala requer reserva aprovada para reuniões com mais de 8 pessoas.”
# Configurar processamento de pedidos de reunião

Set-CalendarProcessing -Identity “[email protected]” `

  -AutomateProcessing AutoAccept `

  -MaximumDurationInMinutes 240 `

  -AllowRecurringMeetings $true `

  -ScheduleOnlyDuringWorkHours $true

Criar uma equipment mailbox

New-Mailbox -Equipment -Name “Projector Portatil 01” `

  -DisplayName “Projector Portatil 01” `

  -Alias “proj-01”
Set-CalendarProcessing -Identity “[email protected]” `

  -AutomateProcessing AutoAccept

As resource mailboxes não consomem licenças individualmente, mas devem ser criadas e geridas via Exchange Online PowerShell ou o Centro de Administração do Exchange. Em 2026, a integração com Microsoft Teams e o add-on Teams Premium permite reservas inteligentes de salas com verificação de disponibilidade em tempo real e regras de distanciamento ou preferências de piso.

Contactos externos e mail users

O Microsoft 365 distingue dois tipos de identidades externas no directório, e a diferença é importante:

Mail Contacts

Contactos que representam pessoas externas à organização. Têm um endereço de email externo e aparecem na Global Address List (GAL). Não têm mailbox nem capacidade de autenticação no tenant. Úteis para manter contactos recorrentes (fornecedores, parceiros) no directório.

New-MgContact -DisplayName “Carlos Mendes (Fornecedor)” `

  -GivenName “Carlos” `

  -Surname “Mendes” `

  -Mail “[email protected]” `

  -CompanyName “TechPartner Lda”

Mail Users

Utilizadores de email que têm credenciais no tenant (podem autenticar-se) mas cujo email é entregue num endereço externo. São usados quando uma pessoa precisa de aceder a recursos internos (ex.: SharePoint) mas mantém a sua mailbox fora do tenant. Consomem uma licença se acederem a serviços pagos.

New-MgUser -DisplayName “Sofia Pereira (Consultora)” `

  -UserPrincipalName “[email protected]” `

  -MailNickname “sofia.pereira_ext” `

  -Mail “[email protected]” `

  -PasswordProfile @{ Password = “Temp!2026”; ForceChangePasswordNextSignIn = $true } `

  -AccountEnabled `

  -UsageLocation “PT” `

  -UserType “Member”

Característica	Mail Contact	Mail User
Aparece na GAL	Sim	Sim
Tem credenciais	Não	Sim
Pode aceder a recursos	Não	Sim
Mailbox no tenant	Não	Não (email externo)
Consome licença	Não	Depende dos serviços acedidos

Gestão de passwords: reset, SSPR e password writeback

A gestão de passwords permanece uma das áreas mais operacionais da administração M365. Em 2026, a Microsoft unificou ainda mais a experiência de reset entre Entra ID e Active Directory on-premises através do password writeback.

Reset de password administrativo

# Reset de password via Microsoft Graph

Set-MgUserPassword -UserId “[email protected]” `

  -CurrentPassword $null `

  -NewPassword “NovaC0mplexa!2026”

Para ambientes sem sincronização on-premises, o reset é imediato. Com Entra Connect e password writeback activo, a alteração propaga-se ao AD local em segundos.

Self-Service Password Reset (SSPR)

O SSPR permite que os utilizadores recuperem as suas próprias passwords sem intervenção do helpdesk. A configuração é feita no portal Entra ID:

Navegar para Entra ID > Password reset.
Activar Self-service password reset enabled para todos os utilizadores ou grupo seleccionado.
Configurar métodos de autenticação: Mobile app notification, Mobile app code, Email, Mobile phone, Office phone, Security questions.
Definir número de métodos necessários (recomendado: 2).
Activar Password writeback se existir Entra Connect.

O password writeback sincroniza as alterações de password feitas na nuvem de volta ao AD on-premises, permitindo que utilizadores sincronizados façam SSPR na nuvem e actualizem a password local simultaneamente. Requer Entra Connect versão 1.1.558.0 ou superior e conta com permissões de escrita no AD.

Verificar estado do SSPR via PowerShell

# Verificar configuração de SSPR

Get-MgPolicyAuthenticationMethodPolicy | Select-Object DisplayName, RegistrationInconclusivePageState

Boas práticas de passwords em 2026

Exigir pelo menos 2 métodos de autenticação para SSPR.
Combinar SSPR com Autenticação Multifactor (MFA) para uma governa robusta.
Desactivar security questions em ambientes de alta segurança (respostas adivinháveis).
Auditar resets de password regularmente via logs do Entra ID.
Definir políticas de expiração de passwords apenas quando há requisitos regulatórios — a Microsoft recomenda não expirar passwords por defeito.

Licenças por utilizador

O licenciamento no Microsoft 365 é atribuído por utilizador e determina quais serviços ficam disponíveis. Cada SKU (Stock Keeping Unit) corresponde a um plano de licenciamento (ex.: Microsoft 365 E3, E5, Business Premium).

Consultar SKUs disponíveis no tenant

# Listar SKUs disponíveis

Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits, PrepaidUnits

Atribuir licença a um utilizador

# Obter o ID do SKU

$sku = Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -eq “SPE_E3” }
# Atribuir licença

Set-MgUserLicense -UserId “[email protected]” `

  -AddLicenses @(@{ SkuId = $sku.SkuId }) `

  -RemoveLicenses @()

Atribuir licença com planos de serviço desactivados

Por vezes pretende-se atribuir uma licença mas desactivar serviços específicos (ex.: desactivar Yammer ou Sway):

$sku = Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -eq “SPE_E3” }
# Identificar os service plans a desactivar

$disabledPlans = $sku.ServicePlans | Where-Object {

    $_.ServicePlanName -in @(“YAMMER_ENTERPRISE”,”SWAY”)

} | Select-Object -ExpandProperty ServicePlanId
Set-MgUserLicense -UserId “[email protected]” `

  -AddLicenses @(@{

      SkuId = $sku.SkuId

      DisabledPlans = $disabledPlans

  }) `

  -RemoveLicenses @()

Licenciamento baseado em grupos

Uma abordagem mais escalável é atribuir licenças a grupos em vez de utilizadores individuais. Quando um utilizador entra num grupo licenciado, recebe automaticamente a licença; ao sair, a licença é removida. Isto integra-se naturalmente com grupos dinâmicos — por exemplo, um grupo dinâmico “Todos os utilizadores em Portugal” com licença E3 atribuída garante que qualquer novo utilizador com UsageLocation = PT recebe automaticamente a licença correcta.

Remover licença

$sku = Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -eq “SPE_E3” }
Set-MgUserLicense -UserId “[email protected]” `

  -AddLicenses @() `

  -RemoveLicenses @($sku.SkuId)

Sempre que se remove uma licença, os dados associados aos serviços (mailbox, OneDrive, Teams) entram num período de graça de 30 dias antes da remoção definitiva. Este comportamento deve ser coordenado com o processo de offboarding.

Gestão de guest users (B2B)

O Microsoft Entra B2B (Business-to-Business) permite convidar utilizadores externos para aceder a recursos do tenant sem criar contas locais com credenciais próprias. Os guest users autenticam-se no seu próprio tenant (ou num provedor de identidade externo como Google, Facebook ou email OTP) e recebem acesso aos recursos partilhados.

Convidar um guest user

# Criar convite B2B

New-MgInvitation -InvitedUserEmailAddress “[email protected]” `

  -InviteRedirectUrl “https://myapps.microsoft.com” `

  -SendInvitationMessage:$true

O utilizador externo recebe um email de convite e, após aceitação, é adicionado ao directório com UserType = Guest. O UPN de um guest inclui o domínio do tenant anfitrião com o prefixo #EXT# (ex.: parceiro_empresa-parceira.com#EXT#@contoso.pt).

Gerir permissões de guest users

Os guest users devem receber permissões mínimas necessárias. Algumas considerações:

Por defeito, guests têm permissões limitadas no directório (não podem ver outros utilizadores nem grupos).
O acesso a sites SharePoint, Teams e aplicações deve ser concedido explicitamente.
As políticas de acesso condicional podem restringir guests a redes específicas ou exigir MFA.
A colaboração externa pode ser limitada a domínios específicos via Entra ID > External Identities > External collaboration settings.

Limitar criação de guests

Por defeito, todos os membros podem convidar guests. Em ambientes restritos, recomenda-se limitar esta capacidade:

# Actualizar política de colaboração externa

Update-MgPolicyAuthorizationPolicy -GuestUserRoleId “10bd51bd-1514-4705-b2c9-d3545f3a76c7”

# O GUID acima corresponde a “Guest user – limited access”

Offboarding: bloquear acesso, converter mailbox e exportar dados

O offboarding é o processo formal de remoção de um utilizador que abandona a organização. Um offboarding bem executado preserva dados corporativos, revoga acesso atempadamente e mantém conformidade regulatória.

Passo 1: Bloquear acesso (signIn)

# Desactivar conta

Set-MgUser -UserId “[email protected]” -AccountEnabled:$false

Isto revoca imediatamente a capacidade de autenticação. O utilizador continua visível no directório e a mailbox existe durante o período de graça.

Passo 2: Revogar sessões activas

# Invalidar todos os tokens de sessão (refresh tokens e sessões de browser)

Revoke-MgUserSignInSession -UserId “[email protected]”

Este comando força o utilizador a reautenticar-se em todos os dispositivos e aplicações. Combinado com AccountEnabled:$false, garante que o acesso é cortado em minutos.

Passo 3: Remover do(s) grupo(s) dinâmicos/estáticos

Os grupos dinâmicos removem automaticamente o utilizador se as regras deixarem de se aplicar (ex.: accountEnabled -eq false). Para grupos estáticos, a remoção deve ser manual:

$groups = Get-MgUserMemberOf -UserId “[email protected]”

foreach ($g in $groups) {

    Remove-MgGroupMemberByRef -GroupId $g.Id -DirectoryObjectId (Get-MgUser -UserId “[email protected]”).Id

}

Passo 4: Converter mailbox em shared mailbox (opcional)

Se for necessário preservar o histórico de email para acesso por outros membros da equipa:

Set-Mailbox -Identity “[email protected]” -Type Shared

Após conversão, remover a licença do utilizador. A shared mailbox até 50 GB não consome licença.

Passo 5: Exportar dados (OneDrive e mailbox)

Para conformidade ou auditoria, exportar os dados do utilizador antes da remoção definitiva:

# Pesquisar conteúdo da mailbox (Exchange Online)

Get-Mailbox -Identity “[email protected]” | Search-Mailbox -SearchQuery “” -TargetMailbox “[email protected]” -TargetFolder “Export Joao Silva” -DeleteContent:$false

Para OneDrive, o gestor do utilizador pode ser designado como herdeiro do conteúdo via portal SharePoint, ou os dados podem ser exportados via PowerShell e APIs do Graph.

Passo 6: Remover licença

$sku = Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -eq “SPE_E3” }

Set-MgUserLicense -UserId “[email protected]” -AddLicenses @() -RemoveLicenses @($sku.SkuId)

Passo 7: Eliminar ou arquivar a conta

Após confirmar que todos os dados foram preservados ou exportados, a conta pode ser eliminada. A eliminação move o utilizador para utilizadores eliminados (recuperável durante 30 dias):

Remove-MgUser -UserId “[email protected]” -Confirm:$false

Quadro resumo de offboarding

Passo	Acção	Comando / Portal
1	Bloquear signIn	`Set-MgUser -AccountEnabled:$false`
2	Revogar sessões	`Revoke-MgUserSignInSession`
3	Remover de grupos	Manual ou dinâmico automático
4	Converter mailbox	`Set-Mailbox -Type Shared`
5	Exportar dados	Search-Mailbox / SharePoint
6	Remover licença	`Set-MgUserLicense -RemoveLicenses`
7	Eliminar conta	`Remove-MgUser`

Checklist Pré-Produção

Antes de considerar a gestão de utilizadores, grupos e mailboxes pronta para produção, validar todos os pontos seguintes:

[ ] Microsoft Graph PowerShell SDK instalado e autenticado com permissões adequadas (User.ReadWrite.All, Group.ReadWrite.All, Directory.ReadWrite.All).
[ ] Módulo Exchange Online PowerShell instalado para operações de mailbox (Connect-ExchangeOnline).
[ ] Domínio verificado no tenant (não usar o domínio .onmicrosoft.com para UPNs de produção, excepto contas de administração).
[ ] Convenção de nomenclatura de UPNs definida e documentada (ex.: [email protected]).
[ ] Ficheiro CSV de criação em massa validado com colunas mínimas: DisplayName, UPN, Department, UsageLocation, Password.
[ ] UsageLocation definido para todos os utilizadores antes de atribuir licenças.
[ ] Grupos dinâmicos configurados com regras testadas e MembershipRuleProcessingState = On.
[ ] Licenciamento baseado em grupos implementado para reduzir gestão manual.
[ ] Shared mailboxes criadas com permissões Full Access e Send As atribuídas aos responsáveis.
[ ] Resource mailboxes com AutomateProcessing = AutoAccept e regras de capacidade configuradas.
[ ] SSPR activado com pelo menos 2 métodos de autenticação e password writeback funcional (se Entra Connect presente).
[ ] Políticas de acesso condicional aplicadas a guest users (MFA obrigatória, restrição de redes se aplicável).
[ ] Colaboração externa configurada (domínios permitidos, restrição de who-can-invite).
[ ] Procedimento de offboarding documentado e testado end-to-end (bloqueio, revogação, conversão, exportação, remoção).
[ ] Auditoria periódica agendada para contas inactivas, licenças não utilizadas e guests sem acesso recente.
[ ] Backups ou exports de dados críticos validados antes de eliminação definitiva de contas.

Gestão de Utilizadores, Grupos e Mailboxes no Microsoft 365 em 2026

Pesquisa Online