SharePoint Online · Microsoft Teams · OneDrive for Business · Microsoft 365 · Governança · PowerShell

SharePoint Online e Microsoft Teams para Administradores em 2026: Guia PME?

✎ Duarte Spínola  |  2026-07-14

A administração de SharePoint Online e Microsoft Teams continua a ser uma das áreas onde as PME acumulam mais dívida técnica: sites criados sem template, permissões herdadas caoticamente, partilha externa aberta por defeito e equipas sem qualquer política de retenção ou naming. Em 2026, com a consolidação do Copilot for Microsoft 365 e a integração cada vez mais profunda entre Teams, SharePoint e Grupos do Microsoft 365, um administrador que não domine estes serviços deixa simplesmente de conseguir garantir compliance básica. Este artigo — Dia 4 de uma série de 6 — cobre os blocos fundamentais que um administrador M365 de uma PME precisa de dominar: templates de site SharePoint, permissões e grupos, partilha externa, conditional access, OneDrive for Business (quotas, sync client, Known Folder Move), criação e governança de Teams, teams policies (messaging, meeting, calling), guest access, compliance (retention e eDiscovery) e a automação de tudo isto via PowerShell. Todos os cmdlets apresentados têm sintaxe verificada contra a documentação oficial da Microsoft (Microsoft Learn — SharePoint, Microsoft Learn — Teams).

1. SharePoint Online — Templates de Site: Communication Site, Team Site e Hub Site

O SharePoint Online oferece três tipos de site fundamentais que servem propósitos distintos. Compreender quando usar cada um é o primeiro passo para evitar a proliferação de sites sem estrutura que caracteriza tenants mal administrados.

Team Site é o template predefinido quando se cria uma equipa no Microsoft Teams ou um Grupo do Microsoft 365. Cada Team Site é suportado por um grupo do Microsoft 365, o que significa que tem automaticamente uma caixa de correio de grupo, um calendário, um bloco de notas OneNote e um plano Planner associados. O Team Site é a escolha correcta para colaboração bidirecional num grupo de trabalho: todos os membros podem contribuir com conteúdo (Microsoft Learn — SharePoint Introduction).

Communication Site é pensado para comunicação unidirecional: uma equipa pequena publica conteúdo para uma audiência larga. Exemplos típicos em PME: intranet corporativa, portal de RH, portal de IT com FAQs e tutoriais. O Communication Site não é suportado por um grupo do Microsoft 365 por defeito, o que simplifica a governança — não cria grupo, não cria caixa de correio partilhada, não cria equipa no Teams. A criação pode ser feita via SharePoint admin center ou via PowerShell (Microsoft Learn — Create a communication site).

Hub Site é um template de governança que permite agregar vários Team Sites e Communication Sites sob uma estrutura comum de navegação, branding e pesquisa. O Hub Site não substitui os sites individuais — funciona como um contentor lógico. Em PME típicas, um Hub Site pode agrupar todos os sites do departamento financeiro, ou todos os sites de um projecto transversal. A associação de sites a um hub pode ser feita no SharePoint admin center ou via PowerShell com o cmdlet Register-SPOSiteCollectionHubSite (Microsoft Learn — Planning hub sites, Microsoft Learn — Create a hub site).

A decisão entre Team Site e Communication Site deve ser tomada antes da criação. Converter um Communication Site num Team Site (ou vice-versa) não é trivial e frequentemente envolve migração de conteúdo. A regra prática: se precisam de um canal no Teams associado, criem um Team Site; se precisam de publicar conteúdo para consumo passivo, criem um Communication Site.

2. Permissões e Grupos de SharePoint

O modelo de permissões do SharePoint Online assenta em três camadas: SharePoint groups, permission levels e herança. A violação sistemática deste modelo é a causa mais frequente de problemas de acesso em tenants mal administrados.

SharePoint Groups são conjuntos de utilizadores que recebem um nível de permissão sobre um site. Por defeito, cada site cria três grupos: Owners (controlo total), Members (edição) e Visitors (leitura). Estes grupos são distintos dos grupos do Microsoft 365 — não devem ser confundidos (Microsoft Learn — Default SharePoint groups).

Permission Levels definem o que um utilizador pode fazer: Read, Contribute, Edit, Design, Full Control. É possível criar níveis personalizados, mas em PME isto raramente é necessário e introduz complexidade de manutenção (Microsoft Learn — Understanding permission levels).

Herança é o mecanismo pelo qual um subsite (ou biblioteca, ou lista) herda as permissões do site pai. A quebra de herança (breaking permissions) deve ser uma excepção deliberada, não a regra. Cada quebra cria um fardo de manutenção: o administrador passa a ter de gerir permissões manualmente nesse objecto, e o site deixa de reflectir mudanças de grupo no site pai (Microsoft Learn — Site permissions).

Práticas recomendadas para PME:

• Usar sempre os grupos SharePoint predefinidos (Owners, Members, Visitors) em vez de atribuir permissões a utilizadores individuais.
• Adicionar utilizadores aos grupos, não atribuir permission levels directamente.
• Evitar quebrar herança excepto quando há um requisito de confidencialidade claro (ex.: pasta de auditoria, documentos de RH).
• Em Team Sites conectados a Grupos M365, gerir a adesão via o grupo (no Entra ID ou M365 admin center), não directamente nos grupos SharePoint — caso contrário, os membros ficam dessincronizados entre Teams, SharePoint, Grupo e Planner.

3. Partilha Externa e Policies de Acesso em SharePoint

A partilha externa é uma das funcionalidades mais úteis e mais arriscadas do SharePoint Online. A Microsoft oferece cinco níveis de partilha externa configuráveis ao nível do tenant e ao nível de cada site (Microsoft Learn — External sharing overview):

A configuração ao nível do tenant define o máximo permitido; a configuração ao nível do site pode ser mais restritiva, mas nunca mais permissiva. Isto significa que se o tenant estiver em “New and existing guests”, um site pode ser configurado para “Only people in your organization” — mas o inverso não é possível (Microsoft Learn — Turn external sharing on or off).

Conditional Access complementa as políticas de partilha ao controlar como e de onde os utilizadores acedem ao SharePoint. As policies de conditional access são configuradas no Entra ID (não no SharePoint admin center) e podem exigir MFA, restringir acessos a IPs autorizados ou bloquear acessos de dispositivos não geridos (Microsoft Learn — Conditional Access overview).

Para SharePoint especificamente, uma política comum em PME é exigir MFA para todos os acessos externos ao range de IPs da sede. O SharePoint suporta também políticas de acesso a partir de dispositivos não geridos: pode-se exigir browser-only (sem download) ou bloquear completamente (Microsoft Learn — Control access from unmanaged devices).

4. OneDrive for Business — Quotas, Sync Client e Known Folder Move

O OneDrive for Business é o armazenamento pessoal na nuvem de cada utilizador M365. Embora pareça simples, tem três áreas de configuração que o administrador precisa de dominar: quotas de armazenamento, sync client e Known Folder Move.

Quotas de armazenamento. A quota predefinida por utilizador depende do plano de licenciamento: planos com Microsoft 365 Business Standard/Business Premium oferecem 1 TB por utilizador; planos Enterprise F3 oferecem 2 TB. O administrador pode alterar a quota predefinida para todos os utilizadores ou ajustar individualmente (Microsoft Learn — Manage site collection storage limits).

Sync client. O OneDrive sync client (também conhecido como Next Gen Sync Client ou NGSC) é a aplicação instalada localmente que sincroniza ficheiros entre o dispositivo e a nuvem. Em ambientes geridos, o administrador configura o sync client via GPO (Group Policy Object) ou Intune. As configurações mais importantes incluem: limite de upload, bloqueio de sync em domínios não geridos, exigência de “Files On-Demand” e configuração de redes CDN (Microsoft Learn — Sync client update process).

Known Folder Move (KFM). O KFM redirecciona automaticamente as pastas Desktop, Documents e Pictures do utilizador para o OneDrive. Isto garante que os ficheiros mais importantes do utilizador são sempre sincronizados e protegidos. O KFM pode ser activado silenciosamente via GPO, Intune ou PowerShell, sem qualquer interacção do utilizador (Microsoft Learn — Redirect known folders).

Alternativamente, via GPO/Intune, a política “Silently move Windows known folders to OneDrive” garante a activação sem prompts. Para PME com dispositivos geridos, o KFM via Intune é a abordagem recomendada — elimina a possibilidade do utilizador optar por não sincronizar pastas críticas.

5. Teams — Criação de Equipas e Canais

Cada equipa no Microsoft Teams é suportada por um Grupo do Microsoft 365, que por sua vez aprovisiona automaticamente um site SharePoint, uma caixa de correio de grupo, um Planner e outros recursos. Esta interligação é o que torna a governança de Teams crítica: cada equipa criada gera uma série de artefactos que persistem mesmo depois de a equipa ser arquivada (Microsoft Learn — Teams and Microsoft 365 Groups).

Criação de equipas. Por defeito, todos os utilizadores com uma licença M365 podem criar equipas. Em PME, isto rapidamente gera dezenas de equipas órfãs. A melhor prática é restringir a criação de equipas a um grupo de administradores ou utilizadores designados, e usar um processo de requisição (ex.: via Forms + Power Automate) para criação de novas equipas (Microsoft Learn — Manage Teams overview).

Canais. Cada equipa tem um canal “General” por defeito e pode ter canais adicionais. Existem dois tipos: standard (visível a todos os membros da equipa) e private (visível apenas a um subconjunto). Os canais privados criam sites SharePoint separados, o que adiciona complexidade de governança — usar com moderação (Microsoft Learn — Teams limits and specifications).

Limites práticos a ter em conta:

A criação de canais deve seguir uma convenção clara. Em PME, recomenda-se: “General” para anúncios, um canal por área de trabalho (ex.: “Desenvolvimento”, “QA”, “Infraestrutura”) e um canal “Reuniões” para actas e follow-ups. Evitar criar canais por projecto temporário — usar tópicos (tags) em vez disso.

6. Teams Policies: Messaging, Meeting e Calling

O Teams admin center oferece três famílias de políticas que controlam o comportamento dos utilizadores: messaging policies, meeting policies e calling policies. Cada política pode ser atribuída individualmente ou a grupos de utilizadores (Microsoft Learn — Assign policies in Teams, Microsoft Learn — Policy assignment overview).

Messaging policies controlam quem pode usar chat, memes, GIFs, editar mensagens, deletar mensagens e usar tradução. Em PME, as configurações mais relevantes são: permitir ou bloquear Giphy/Estêncil/Adesivos, permitir tradução de mensagens e controlar quem pode usar o chat (Microsoft Learn — Teams policies).

Meeting policies controlam quem pode iniciar reuniões, quem pode contornar o lobby, se a transcrição e gravação são permitidas, e quem pode partilhar ecrã. A configuração do lobby é particularmente importante em PME: por defeito, utilizadores autenticados entram directamente, mas convidados externos ficam no lobby. Para reuniões com clientes externos, recomenda-se “Everyone in the lobby” até o organizador admitir (Microsoft Learn — Meeting policies in Teams).

Calling policies controlam funcionalidades de voz: encaminhamento de chamadas, delegação, estacionamento de chamadas e correio de voz. Estas políticas só são relevantes se a PME tiver licenças de Teams Phone ( anteriormente Direct Routing ou Operator Connect) (Microsoft Learn — Get-CsTeamsMeetingPolicy cmdlet).

A atribuição de políticas pode ser feita individualmente (Grant-CsTeamsMeetingPolicy -Identity "[email protected]" -PolicyName "ClienteExterno") ou em massa via batch assignment, que processa até 50.000 utilizadores por batch:

7. Governança de Teams: Naming Policies, Expiry e Criação Restrita

Sem governança, um tenant M365 acumula centenas de equipas órfãs em poucos meses. A governança de Teams assenta em três pilares: naming policies, expiry policies e restrição de criação.

Naming policies aplicam prefixos e sufixos automáticos ao nome das equipas (e dos Grupos M365 subjacentes). São configuradas no Entra ID e aplicam-se a equipas criadas via Teams, Outlook, SharePoint ou Planner. Uma naming policy típica para PME pode exigir o prefixo “GRP-” para identificar visualmente grupos no Entra ID, ou um sufixo com o departamento (Microsoft Learn — Groups naming policy).

A naming policy suporta atributos dinâmicos do Entra ID como [Department] e [Country], que são resolvidos no momento da criação com base no perfil do utilizador que cria o grupo. Palavras bloqueadas (blocked words) impedem a criação de grupos com nomes inadequados.

Expiry policies definem um tempo de vida máximo para equipas/grupos. Quando um grupo expira, o proprietário recebe notificações por e-mail (30, 15 e 1 dia antes) com a opção de renovar. Se não for renovado, o grupo e todos os artefactos associados (site SharePoint, caixa de correio, Planner) são eliminados — mas podem ser restaurados dentro de 30 dias. Em PME, recomenda-se um ciclo de 180 dias para equipas de projecto e 365 dias para equipas departamentais (Microsoft Learn — Team expiration and renewal).

Restrição de criação. Por defeito, todos os utilizadores licenciados podem criar equipas. A restrição é feita ao nível do Entra ID, controlando quem pode criar Grupos M365 — dado que cada equipa é um grupo, restringir a criação de grupos restringe automaticamente a criação de equipas. O processo envolve criar um grupo de segurança no Entra ID com os utilizadores autorizados a criar grupos e configurar o tenant para permitir a criação apenas por membros desse grupo.

A combinação destas três medidas reduz drasticamente a proliferação de equipas órfãs e facilita a auditoria. Uma PME típica com 50-200 utilizadores deve implementar pelo menos naming policy e restrição de criação logo no início do rollout do Teams.

8. Guest Access e Compliance em Teams: Retention e eDiscovery

Guest access permite convidar utilizadores externos à organização para colaborar dentro de equipas do Teams. O guest é autenticado no Entra ID como B2B guest user e aparece no Teams com a etiqueta “(Guest)” ao lado do nome. O guest access é controlado ao nível do tenant e pode ser afinado ao nível das equipas individuais (Microsoft Learn — Guest access in Teams).

A configuração do guest access envolve vários níveis: tenant-level (Teams admin center), Entra ID (external collaboration settings) e permissões por equipa. Os níveis de permissão disponíveis para guests incluem: criar canais, actualizar canais, eliminar canais, criar/remover separadores, adicionar apps e enviar mensagens (Microsoft Learn — Manage external access).

Retention policies controlam quanto tempo o conteúdo do Teams é retido ou eliminado. Aplicam-se a: mensagens de canal, chats (1:1 e grupais), ficheiros partilhados em chats e conteúdo de canais partilhados. Uma retention policy pode reter conteúdo por um período fixo (ex.: 3 anos) e depois eliminá-lo automaticamente, ou reter indefinidamente (Microsoft Learn — Retention policies for Teams, Microsoft Learn — Create retention policies).

eDiscovery permite procurar, exportar e colocar em retenção legal conteúdo do Teams para fins de auditoria ou litígio. O conteúdo pesquisável inclui mensagens de canal, chats, ficheiros e metadados. O eDiscovery é gerido via Microsoft Purview compliance portal e suporta pesquisas por palavra-chave, intervalo de datas, remetente, destinatário e tipo de conteúdo (Microsoft Learn — eDiscovery, Microsoft Learn — eDiscovery cases).

Para PME sujeitas a RGPD ou outras obrigações de retenção legal, recomenda-se no mínimo uma retention policy de 3 anos para mensagens de canal e chats. Empresas em sectores regulados (saúde, financeiro) devem consultar o compliance officer antes de definir períodos de retenção.

9. PowerShell para SharePoint Online e Teams

A administração via PowerShell é essencial para qualquer PME com mais de 20 utilizadores — as tarefas repetitivas (atribuir políticas, configurar sites, auditar permissões) tornam-se impraticáveis via interface gráfica. Existem dois módulos principais: SharePoint Online PowerShell e Microsoft Teams PowerShell (Microsoft Learn — Teams PowerShell overview, Microsoft Learn — Teams PowerShell install).

Conexão ao SharePoint Online:

(Microsoft Learn — Connect-SPOService)

Cmdlets SharePoint mais usados:

(Microsoft Learn — Get-SPOSite, Microsoft Learn — Set-SPOSite)

Conexão ao Microsoft Teams:

(Microsoft Learn — Connect-MicrosoftTeams)

Cmdlets Teams mais usados:

(Microsoft Learn — New-Team, Microsoft Learn — Get-Team)

Cmdlets de policies (Teams + Skype for Business Online):

(Microsoft Learn — Get-CsTeamsMeetingPolicy)

Script de auditoria combinado — SharePoint + Teams:

Este script pode ser agendado via Task Scheduler ou Azure Automation para gerar relatórios semanais de governança. Em PME com requisitos de compliance, a geração automática destes relatórios é essencial para demonstrar due diligence.

Checklist Pré-Produção

Antes de aplicar qualquer configuração deste artigo em ambiente produtivo, confirma:

1. Versão dos módulos PowerShell (deve ser a mais recente): Get-Module -Name MicrosoftTeams, Microsoft.Online.SharePoint.PowerShell -ListAvailable
2. Conta de administração com permissões adequadas: SharePoint Administrator ou Teams Administrator (não basta Global Admin — usar least privilege via PIM se disponível)
3. Política de partilha externa do tenant definida antes de configurar sites individuais: Get-SPOTenant | Select-Object SharingCapability
4. Naming policy e restrição de criação de grupos configuradas no Entra ID antes do rollout em massa do Teams
5. Retention policy de Teams criada e validada antes de convidar utilizadores externos (garantir que o conteúdo de guests também fica retido)
6. Backup/exportação do estado actual antes de alterar políticas em massa: executar Get-SPOSite -Limit All e Get-Team e guardar os resultados como baseline

Artigos Relacionados

• M365: Centro de Administração, Funções e Licenças em 2026 (Dia 1)
• M365: Gestão de Utilizadores, Grupos e Mailboxes em 2026 (Dia 2)
• OneDrive for Business: Sincronização e Resolução de Erros
• Administrar Copilot e Copilot for Microsoft 365: Modelos, Plugins, Skills e Segurança
• Browser Corporativo 2026: Edge e Chrome Enterprise