Blog V7A
Mantenha-se atualizado com as últimas novidades, dicas e tendências do mundo da tecnologia e cloud computing.
Break Glass Accounts no Azure: porque passei a incluir contas de emergência em cada entrega
Break Glass Accounts no Azure: quem abre a porta quando os administradores ficam de fora? Há uma pergunta que merece fazer parte de qualquer entrega de um ambiente cloud: se amanhã todos os administradores perderem o acesso, como recuperamos o controlo? Podemos ter a arquitectura documentada, permissões atribuídas e políticas de segurança implementadas. Mas a entrega continua incompleta se ninguém souber responder a essa pergunta. É precisamente aqui que entram as Break Glass Accounts, ou contas de acesso de emergência. Uma situação que nos obriga a repensar a entrega Imagina uma intervenção para reforçar a segurança de um tenant. A equipa activa uma política de Acesso Condicional que exige um dispositivo em conformidade para aceder aos portais administrativos. A intenção é legítima. Contudo, os equipamentos utilizados pelos administradores ainda não cumprem esse requisito. No próximo início de sessão, o acesso é bloqueado. Outro administrador tenta entrar e encontra a mesma restrição. Há pessoas com permissões para corrigir a configuração, mas nenhuma consegue chegar ao local onde precisa de a alterar. Este cenário demonstra por que razão a Microsoft recomenda planear as exclusões de emergência e testar as políticas, incluindo através do modo report-only, antes da sua aplicação efectiva. Microsoft Learn — Planear o Acesso Condicional A pergunta deixa então de ser «quem tem permissões?» e passa a ser: «quem consegue entrar para resolver?» O que são as Break Glass Accounts? São contas administrativas reservadas para recuperar o acesso quando as contas habituais não podem ser utilizadas. No contexto do Azure e do Microsoft 365, são configuradas no Microsoft Entra ID. A expressão significa «quebrar o vidro em caso de emergência»: um recurso preparado antecipadamente para uma situação excepcional. Microsoft Learn — Contas de acesso de emergência O que deve fazer parte da configuração As orientações da Microsoft incluem: Componente Configuração recomendada Redundância Pelo menos duas contas. Independência Contas exclusivamente cloud, com domínio onmicrosoft.com, sem sincronização ou federação local. Privilégios Global Administrator permanentemente activo, sem depender de activação no PIM. Autenticação Resistente a phishing, preferencialmente FIDO2, com dependências diferentes das contas habituais. Acesso Condicional Exclusão das políticas que bloqueiam ou restringem o início de sessão. Custódia Credenciais guardadas em locais seguros e separados, acessíveis a pessoas autorizadas. Monitorização Alertas de utilização e revisão dos registos de auditoria. Validação Testes, pelo menos, a cada 90 dias. A exclusão do Acesso Condicional não dispensa autenticação forte nem elimina os requisitos obrigatórios de MFA. Estas contas devem ser utilizadas apenas em emergências e testes controlados. Microsoft Learn — Requisitos e validação E o acesso às subscrições Azure? Existe uma distinção técnica que merece atenção: Global Administrator no Entra ID não concede automaticamente acesso aos recursos de todas as subscrições Azure. A administração do directório e as permissões sobre os recursos Azure são controladas separadamente. Quando necessário, um Global Administrator pode elevar o acesso e obter a função User Access Administrator no âmbito raiz. Isso permite gerir atribuições de acesso nas subscrições e grupos de gestão associados ao tenant. A elevação deve ser removida após a intervenção. Microsoft Learn — Elevar o acesso às subscrições Azure Por isso, um procedimento de emergência deve prever tanto a recuperação do acesso ao directório como os passos necessários para recuperar a administração dos recursos. O que considero uma entrega completa Na minha perspectiva, este tema deve aparecer logo no desenho da solução e acompanhar a passagem de conhecimento à equipa do cliente. A entrega deve permitir responder, sem improvisação, a cinco perguntas: Quem está autorizado a utilizar as contas? Onde estão guardados os meios de autenticação? Como se realiza e documenta o acesso de emergência? Quem recebe o alerta de utilização? Quando foi efectuado o último teste? Uma conta criada e esquecida oferece pouca confiança operacional. O que interessa é conseguir demonstrar que o procedimento funciona e que a equipa sabe executá-lo. A pergunta que vale a pena levar para a próxima reunião Ao rever um ambiente Azure ou Microsoft 365, proponho este exercício: assumir que as contas administrativas habituais ficaram indisponíveis e pedir à equipa que explique como recuperaria o controlo. Se a resposta depender de uma única pessoa, de um telemóvel pessoal ou de permissões que ninguém consegue activar, há trabalho por fazer. A capacidade de recuperar o acesso administrativo também deve fazer parte da entrega.
Windows 11 24H2 e Windows 10 LTSB 2016: actualizações terminam em 13 de Outubro
Windows 11 24H2 e Windows 10 LTSB 2016: actualizações terminam em 13 de Outubro de 2026 A Microsoft emitiu um novo alerta de ciclo de vida para duas versões do Windows que ainda podem estar presentes em ambientes domésticos e empresariais. A partir de 13 de Outubro de 2026: O Windows 11, versão 24H2, nas edições Home e Pro, deixará de receber actualizações mensais de segurança e qualidade; O Windows 10 Enterprise LTSB 2016 também chegará ao fim das actualizações; Os dispositivos afectados deixarão de receber novas protecções contra vulnerabilidades e ameaças de segurança; Problemas de compatibilidade, estabilidade e desempenho poderão deixar de ser corrigidos pela Microsoft. Atenção à diferença entre as edições O fim das actualizações do Windows 11 24H2 em Outubro de 2026 aplica-se apenas às edições Home e Pro. As edições Windows 11 24H2 Enterprise e Education permanecem suportadas até 12 de Outubro de 2027. Esta distinção é importante para evitar avaliações incorrectas do estado de conformidade e suporte dos dispositivos. O que recomenda a Microsoft? Para dispositivos com Windows 11 24H2 Home ou Pro: Actualizar para o Windows 11, versão 25H2, para continuar a receber actualizações mensais de segurança e qualidade. Para dispositivos com Windows 10 Enterprise LTSB 2016: Planear a migração para o Windows 11 Enterprise LTSC 2024, depois de validar os requisitos de hardware, aplicações e periféricos. Para organizações que não consigam concluir a transição dentro do prazo: Avaliar a elegibilidade e os custos das Extended Security Updates — ESU — como medida temporária, e não como substituição de um projecto de modernização. O que as equipas de TI devem fazer agora? Inventariar os dispositivos e identificar as versões e edições instaladas; Confirmar a compatibilidade do hardware com o Windows 11 25H2 ou Windows 11 Enterprise LTSC 2024; Avaliar aplicações críticas, controladores e periféricos; Definir grupos-piloto e executar testes de actualização; Preparar políticas de Microsoft Intune, Windows Autopatch ou outras ferramentas de gestão; Monitorizar falhas, compatibilidade e experiência dos utilizadores; Estabelecer um plano de implementação antes de Outubro. O fim de suporte não significa que o computador deixará de funcionar no dia seguinte. Significa que continuará a funcionar sem receber novas correcções e protecções da Microsoft, aumentando progressivamente o risco operacional e de segurança. Na V7A, ajudamos as organizações a avaliar o parque informático, identificar versões próximas do fim de suporte e planear uma transição controlada para plataformas Windows modernas e suportadas. A sua organização já identificou quantos dispositivos ainda utilizam Windows 11 24H2 Home/Pro ou Windows 10 Enterprise LTSB 2016? Fonte oficial: Microsoft Learn #Windows11 #Windows10 #Microsoft #WindowsUpdate #MicrosoftIntune #WindowsAutopatch #GestãoDeEndpoints #Cibersegurança #Modernização #V7A
Windows Server vNext: Microsoft testa Trusted Launch, recuperação automática e NVMe over Fabrics
Windows Server vNext: segurança, recuperação e armazenamento definem a próxima geração A Microsoft disponibilizou a Windows Server vNext Preview Build 29651, uma nova compilação de avaliação do próximo Windows Server Long-Term Servicing Channel — LTSC. Mais do que o número da build, o anúncio revela algumas das tecnologias que poderão moldar a próxima geração do Windows Server. Entre as principais novidades, destacam-se: Trusted Launch para máquinas virtuais Hyper-V A Microsoft está a testar a criação de máquinas virtuais de Geração 2 com: Secure Boot; vTPM; Protecção do estado do vTPM em repouso; Gestão inicial através de PowerShell. O objectivo é reforçar a protecção das máquinas virtuais contra alterações não autorizadas no processo de arranque e em componentes críticos da plataforma. Nesta fase, ainda não existe suporte para clusters de failover, Hyper-V Replica, migração para outro servidor ou gestão através do Windows Admin Center. Quick Machine Recovery O Quick Machine Recovery permite que o Windows Server procure correcções disponibilizadas através da cloud quando encontra erros críticos que impedem o arranque. Esta capacidade poderá reduzir significativamente o esforço das equipas de TI em incidentes que afectem simultaneamente vários servidores, acelerando a recuperação e diminuindo o tempo de indisponibilidade. NVMe over Fabrics O Windows Server vNext passa também a testar o acesso a armazenamento NVMe remoto através de: NVMe/TCP, utilizando redes Ethernet convencionais; NVMe/RDMA, para ambientes que exigem baixa latência e elevado débito. Esta evolução poderá ser particularmente relevante para centros de dados, plataformas de virtualização, bases de dados e cargas de trabalho que dependem de armazenamento de alto desempenho. Arranque em ReFS O ReFS Boot está activado nas builds Preview do Windows Server vNext. Esta novidade representa mais um passo na evolução do Resilient File System, embora ainda existam limitações relacionadas com a partição do Windows Recovery Environment — WinRE. Importante: não instalar em produção A Build 29651 é software de pré-lançamento, destinado exclusivamente a avaliação e testes através do Windows Server Insider Program. A Microsoft também esclarece que: A identidade visual continua a apresentar “Windows Server 2025”, mas a versão deve ser tratada como Windows Server vNext Preview; Actualizações provenientes de builds anteriores à 29531 não são suportadas; A instalação de uma build 29531 ou posterior deve ser efectuada como nova base; Esta versão Preview expira em 15 de Outubro de 2027; Existem problemas conhecidos, incluindo uma condição associada à negociação TLS híbrida que pode provocar uma falha do processo LSASS. Estas funcionalidades ainda podem ser alteradas, adiadas ou removidas antes da versão final. No entanto, já indicam três prioridades claras da Microsoft para o futuro do Windows Server: Maior protecção das cargas virtualizadas; Recuperação mais automatizada e resiliente; Armazenamento remoto de elevado desempenho. Na V7A, acompanhamos a evolução das tecnologias Microsoft para ajudar as organizações a avaliar novas capacidades, modernizar as suas infra-estruturas e preparar decisões de adopção com segurança. Qual destas novidades poderá ter maior impacto no seu centro de dados: Trusted Launch, Quick Machine Recovery, NVMe over Fabrics ou ReFS Boot? Fonte oficial: Microsoft Techcommunity #WindowsServer #WindowsServerVNext #Microsoft #HyperV #TrustedLaunch #NVMe #ReFS #CyberSecurity #Datacenter #Infraestrutura #V7A
Microsoft Entra Connect Sync: faltam pouco mais de 30 dias para uma actualização obrigatória
A Microsoft confirmou uma atualização obrigatória para todas as organizações que utilizam o Microsoft Entra Connect Sync. A partir de 30 de setembro de 2026, todos os serviços de sincronização deixarão de funcionar nos servidores que estiverem numa versão anterior à 2.5.79.0. A versão 2.5.79.0 introduziu uma alteração no serviço de back-end destinada a reforçar a segurança e a proteção da infraestrutura de sincronização. Na prática, se o ambiente não for atualizado dentro do prazo: A sincronização entre o Active Directory local e o Microsoft Entra ID falhará; Novos utilizadores, grupos e alterações de atributos deixarão de ser sincronizados; Alterações de palavras-passe poderão deixar de chegar à cloud nos ambientes que utilizam Password Hash Synchronization; Os processos de criação, alteração e desativação de identidades poderão ficar desalinhados entre o ambiente local e o Microsoft 365; A sincronização apenas será restabelecida depois da atualização para uma versão suportada. A versão 2.5.79.0 é o requisito mínimo, não necessariamente a versão recomendada para uma nova atualização. A Microsoft identificou limitações nessa versão que foram corrigidas posteriormente. Por isso, as organizações devem avaliar e instalar a versão mais recente suportada, depois de concluídos os testes de compatibilidade e recuperação. O que os administradores devem fazer agora? Confirmar a versão atualmente instalada do Microsoft Entra Connect Sync; Verificar o estado do Auto-Upgrade e confirmar se o servidor é elegível; Validar os requisitos, incluindo .NET Framework 4.7.2 e TLS 1.2; Rever a compatibilidade do sistema operativo, base de dados e componentes instalados; Exportar e documentar a configuração atual; Confirmar backups e um plano de recuperação; Executar a atualização numa janela controlada; Validar, após o upgrade, os ciclos Import, Synchronization e Export; Confirmar no Microsoft Entra Connect Health que não existem erros de sincronização. O instalador do Microsoft Entra Connect Sync está agora disponível exclusivamente no Microsoft Entra Admin Center. Para algumas organizações, este também pode ser o momento adequado para avaliar uma futura migração para o Microsoft Entra Cloud Sync. Contudo, essa decisão deve resultar de um assessment técnico e não ser tomada apenas por causa deste prazo. Na V7A, apoiamos organizações na avaliação, actualização e modernização de ambientes de identidade híbrida, reduzindo o risco de interrupções nos serviços Microsoft 365. Já confirmou qual versão do Microsoft Entra Connect Sync está instalada na sua organização? Não deixe esta validação para os últimos dias de setembro. Fonte oficial: Microsoft #MicrosoftEntra #EntraConnect #Microsoft365 #HybridIdentity #IdentitySecurity #CloudSecurity #ActiveDirectory
Windows 11 melhora o Explorador de Ficheiros e apresenta um menu de contexto personalizável
Windows 11: o Explorador de Ficheiros está a ficar mais rápido, simples e personalizável O Explorador de Ficheiros é uma das ferramentas mais utilizadas no Windows. Por isso, pequenos atrasos ao abrir uma pasta, mudar o nome de um ficheiro ou clicar com o botão direito podem afetar significativamente a experiência diária dos utilizadores. A Microsoft anunciou um conjunto de melhorias focadas no desempenho, fiabilidade e usabilidade do Explorador de Ficheiros do Windows 11. Entre as principais novidades, destacam-se: Abertura mais rápida do Explorador de Ficheiros; Redução de bloqueios, atrasos e atualizações inesperadas durante a navegação; Alteração do nome de ficheiros sem interrupções provocadas pela sincronização em segundo plano; Melhorias na barra de endereço, incluindo suporte para caminhos entre aspas e com barras invertidas duplas; Abertura de pastas num novo separador através do botão central do rato; Apresentação mais clara dos tamanhos dos ficheiros em KB, MB e GB; Painel de detalhes reorganizado para facilitar a consulta das propriedades dos ficheiros. Mas a mudança mais visível está no menu de contexto apresentado ao clicar com o botão direito. O novo menu foi redesenhado para abrir mais rapidamente, reduzir a quantidade de opções apresentadas por defeito e permitir maior personalização. Através de Definições > Personalização, o utilizador poderá: Ativar ou ocultar comandos do Windows, como “Enviar para”, “Criar atalho” e “Imprimir”; Escolher quais extensões das aplicações aparecem no menu principal ou num submenu; Apresentar os comandos Cortar, Copiar, Colar, Mudar o nome, Eliminar e Partilhar como texto, recuperando uma experiência mais próxima do Windows 10; Reorganizar a posição de comandos como “Propriedades”. Estas melhorias mostram que modernizar um sistema operativo não significa apenas adicionar novas funcionalidades. Significa também aperfeiçoar as ações simples que milhões de utilizadores repetem todos os dias. Neste momento, a nova experiência está a ser distribuída gradualmente aos participantes do Windows Insider Program. A Microsoft ainda não anunciou uma data para a sua disponibilização geral no Windows 11. Na V7A, acompanhamos a evolução do ecossistema Microsoft para ajudar as organizações a avaliar, testar e adotar novas funcionalidades de forma controlada — equilibrando produtividade, compatibilidade e estabilidade. Na sua opinião, o novo menu de contexto do Windows 11 será finalmente mais simples do que o atual? Fonte oficial: Microsoft #Windows11 #FileExplorer #WindowsInsider #Microsoft #ModernWork #Produtividade #GestãoDeEndpoints #V7A
Gestão em nuvem dos atributos do Exchange para Remote Mailboxes em ambientes híbridos
Gestão em nuvem dos atributos do Exchange para Remote Mailboxes em ambientes híbridos Se administras um ambiente Exchange híbrido, já conheces a dor de cabeça de teres de manter o teu último servidor Exchange on-premises vivo só para poderes editar atributos de correio das tuas caixas de correio na cloud. A Microsoft acabou de mudar essa realidade: já é possível transferir a Source of Authority (SOA) dos atributos do Exchange para a nuvem, mantendo os atributos de identidade sob controlo do Active Directory on-premises. Neste artigo resumo o que esta funcionalidade faz, como a ativares e os cuidados a ter antes de a ligares — em particular ao nível de todo o tenant, onde um passo em falso pode ser difícil de reverter. O que muda, no fundo Até agora, num ambiente híbrido, qualquer alteração a atributos do Exchange (proxy addresses, custom attributes, etc.) de um utilizador sincronizado tinha de ser feita no Active Directory local através do Set-RemoteMailbox, e só depois replicada para a cloud pelo ciclo de sincronização. Com esta funcionalidade, consegues separar as duas responsabilidades: Atributos do Exchange (proxy addresses, custom attributes, tipo de destinatário, etc.) passam a poder ser geridos diretamente no EXO PowerShell, no Microsoft 365 Admin Center ou no Exchange Admin Center. Atributos de identidade (nome, apelido, departamento, gestor, etc.) continuam a ser geridos exclusivamente no Active Directory on-premises. Importante: isto aplica-se apenas a objetos de utilizador com caixa de correio no Exchange Online. Para grupos com correio ativado ou contactos de correio, a transferência de SOA faz-se separadamente (Group SOA / Contact SOA). As duas fases da funcionalidade Fase 1 — controlo por caixa de correio (GA) Ativa-se e desativa-se a gestão na cloud individualmente, por mailbox, através do parâmetro IsExchangeCloudManaged. Disponível em Commercial (Global), GCCH, DoD e Gallatin. Fase 2 — writeback (GA) Um conjunto definido de atributos do Exchange alterados na cloud passa a ser escrito de volta no Active Directory on-premises através do Microsoft Entra Cloud Sync — por exemplo, uma alteração a proxy addresses feita no Exchange Online reflete-se no AD local. O atributo mail já está incluído no conjunto de writeback. Suporta até 600.000 caixas de correio geridas na cloud por tenant. Os atributos com writeback ativo (13 no total) incluem extensionAttribute1-15 (mapeados para CustomAttribute1-15), mail (mapeado para WindowsEmailAddress), proxyAddresses (mapeado para EmailAddresses e WindowsEmailAddress), msExchRecipientDisplayType, msExchRecipientTypeDetails e msExchExtensionCustomAttribute1-5. Outros atributos do Exchange — como legacyExchangeDN ou msExchArchiveGUID — podem ser editados na cloud, mas não têm writeback. Pré-requisitos Antes de mexeres em produção, confirma: Microsoft Entra Connect na versão 2.5.190.0 ou superior. Verifica com: (Get-ADSyncGlobalSettings).Parameters['Microsoft.Synchronize.ServerConfigurationVersion'] Com uma versão mais antiga, o cliente de sincronização tenta empurrar atributos do Exchange de mailboxes já transferidas para a cloud e falha. Microsoft Entra Cloud Sync, obrigatório para o writeback (Fase 2). Não precisas de desinstalar o Connect Sync — os dois coexistem: o Connect Sync trata da sincronização de diretório e o Cloud Sync fica apenas responsável pelo writeback dos atributos do Exchange. Confirma a versão do agente (mínimo 1.1.1107.0) em C:\Program Files\Microsoft Azure AD Connect Provisioning Agent, e o estado "Active" em Identity > Hybrid management > Microsoft Entra Connect > Cloud Sync > Agents no Entra admin center. Role adequada: Exchange Administrator (recomendado), Hybrid Identity Administrator ou Global Administrator. Como transferir a SOA de uma caixa de correio para a cloud Depois de qualquer atualização feita on-premises com Set-RemoteMailbox, espera pelo ciclo normal de sincronização mais 24 horas antes de ativares a gestão na cloud. Se a tua sincronização demora 6 horas, o total de espera são 30 horas. # Ativar gestão na cloud Set-Mailbox -Identity <User> -IsExchangeCloudManaged $true # Confirmar Get-Mailbox -Identity <User> | Format-List Identity, IsExchangeCloudManaged # A partir daqui, edita diretamente na cloud Set-Mailbox -Identity <User> -CustomAttribute1 "ModificadoNaCloud" Para listares todos os utilizadores já geridos na cloud: Get-Mailbox | Where-Object { $_.IsDirSynced -eq $true -and $_.IsExchangeCloudManaged -eq $true } Como ativar o writeback Requer a role Hybrid Identity Administrator. Inicia sessão no Microsoft Entra admin center. No menu lateral, expande Entra Connect e seleciona Cloud Sync. Em Cloud sync | Configurations, escolhe New configuration > EXO to AD attribute sync (Preview). Confirma que o agente corresponde ao domínio pretendido e seleciona Create (a criação do job pode demorar alguns minutos). Na página Overview, seleciona Start provisioning e confirma com Yes. Depois de iniciado, podes acompanhar o estado na coluna Status, consultar logs de provisionamento e auditoria, colocar o job em pausa ou eliminá-lo. Para forçar uma sincronização imediata em vez de esperar pelo próximo ciclo, usa Provision on demand. Para validar que está a funcionar: # No Exchange Online Set-Mailbox -Identity <User> -CustomAttribute1 "TesteWriteback_$(Get-Date -Format 'yyyyMMdd_HHmmss')" Espera cerca de 20 minutos (ou força com Provision on demand) e confirma no Exchange Management Shell on-premises: Get-RemoteMailbox -Identity <User> | Format-List CustomAttribute1 Nota sobre o atributo mail: configurações criadas a partir de 3 de agosto de 2026 já incluem por defeito o mapeamento Mail → mail. Se ativaste o writeback antes dessa data (durante o Public Preview), tens de o adicionar manualmente: abre a configuração, vai a Attribute mapping e, se o mapeamento direto não existir, usa Restore default mappings. Atenção: isto repõe os mapeamentos por defeito, remove personalizações e filtros de scoping, e reinicia o job — regista a tua configuração atual antes de avançar. Como reverter uma caixa de correio para gestão on-premises Set-Mailbox -Identity <User> -IsExchangeCloudManaged $false Antes de correr este comando, garante que qualquer alteração feita na cloud que precises de manter foi guardada (por exemplo com Get-Mailbox e Get-User), porque o próximo ciclo de sincronização vai sobrepor os atributos na cloud com os valores atuais do on-premises. Isto é especialmente relevante no processo de offboarding: se tentares migrar uma caixa de correio de volta para on-premises com IsExchangeCloudManaged ainda a true, as atualizações vindas do AD local continuam bloqueadas e a sincronização parte-se. Desativa sempre a gestão na cloud antes de iniciar o offboarding. Criar e eliminar caixas de correio Para criar uma nova caixa de correio sem depender do último servidor Exchange local: cria o utilizador no AD on-premises, deixa o Entra Connect Sync sincronizar a identidade, atribui a licença do Exchange Online no Microsoft 365 Admin Center (o que provisiona a caixa de correio) e só depois transfere a SOA com Set-Mailbox -IsExchangeCloudManaged $true. Para eliminar, a remoção continua a ter de ser feita no AD on-premises — mesmo que os atributos estejam geridos na cloud. A remoção sincroniza e a caixa de correio é eliminada na cloud automaticamente. SOA ao nível do tenant: usar com muito cuidado Existe também a opção de tornar IsExchangeCloudManaged = true o valor por defeito para todas as novas caixas de correio do tenant, eliminando por completo a dependência do servidor Exchange local para provisionamento de novas contas. # Ativar Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault # Confirmar Get-OrganizationConfig | Format-List BlockExchangeProvisioningFromOnPremEnabled # Deve devolver: True # Desativar Set-OrganizationConfig -ExchangeAttributesServerManagedByDefault Este é o ponto onde é preciso ter mais atenção. Só deves ativar esta definição depois de teres migrado todas as caixas de correio on-premises para o Exchange Online e de teres deixado de criar recipients Exchange, mail-enabled users ou remote mailboxes no ambiente local. Se ativares isto demasiado cedo: Novos recipients Exchange criados on-premises deixam de sincronizar corretamente. O objeto na cloud é criado como utilizador comum do Microsoft Entra, e não como MailUser. O provisionamento da caixa de correio no Exchange Online falha, porque o MailUser necessário não existe. Não há forma de self-service para reverter a situação — é preciso abrir um caso com o Suporte Microsoft. Além disso, desativar a definição só muda o comportamento para utilizadores futuros; não limpa automaticamente o IsExchangeCloudManaged de quem já foi afetado. Se precisares de criar caixas de correio partilhadas com a SOA de tenant ativa, tens duas opções: criar a shared/equipment mailbox diretamente no Exchange Online sem criar utilizador correspondente on-premises, ou criar e sincronizar o utilizador on-premises, atribuir temporariamente uma licença para provisionar a caixa e depois convertê-la em partilhada ou de equipamento. Como isto se relaciona com a SOA ao nível do objeto É importante não confundir os dois conceitos. Esta funcionalidade transfere apenas a SOA dos atributos do Exchange — o utilizador continua sincronizado por diretório e a SOA de identidade continua no AD local. A transferência de SOA ao nível do objeto (utilizadores, grupos e contactos), que já está em disponibilidade geral, é um passo posterior e mais profundo, tipicamente usado quando o objetivo final é reduzir ou eliminar a dependência do Active Directory on-premises por completo. Conclusão Esta funcionalidade é um passo relevante para quem está a caminhar para o desligamento do último servidor Exchange local sem perder a capacidade de gerir atributos de correio. Vale a pena começar pela Fase 1 (por caixa de correio) num pequeno grupo de teste, confirmar que o writeback está corretamente mapeado — sobretudo se ativaste a funcionalidade antes de 3 de agosto de 2026 — e só considerar a ativação ao nível do tenant depois de teres a certeza absoluta de que já não crias recipients Exchange on-premises. Fonte: Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments — Microsoft Learn
Microsoft Entra Cloud Sync passa a suportar sincronização de dispositivos
Microsoft Entra Cloud Sync passa a suportar sincronização de dispositivos A Microsoft adicionou uma das funcionalidades mais aguardadas ao Microsoft Entra Cloud Sync: a capacidade de sincronizar dispositivos entre o Active Directory local e o Microsoft Entra ID. Até agora, a ausência de sincronização de dispositivos era uma das principais limitações que impediam muitas organizações de substituir completamente o Microsoft Entra Connect Sync pelo Cloud Sync. Com este novo suporte, a migração para uma arquitetura de identidade híbrida mais leve, resiliente e gerida a partir da cloud fica mais próxima. Importante: a sincronização de dispositivos no Microsoft Entra Cloud Sync encontra-se atualmente em versão Preview. A funcionalidade deve ser avaliada e testada antes da utilização em ambientes críticos de produção. O que é a sincronização de dispositivos? A nova funcionalidade permite sincronizar objetos de computador existentes no Active Directory Domain Services - AD DS - para o Microsoft Entra ID. Para realizar essa operação, o Cloud Sync utiliza o job: AD2AADDeviceSync Depois da sincronização do objeto de computador, o dispositivo pode concluir o processo de Microsoft Entra Hybrid Join, passando a estar representado tanto no Active Directory local como no Microsoft Entra ID. A funcionalidade vem desativada por predefinição e precisa de ser habilitada numa configuração existente de Cloud Sync entre o AD e o Microsoft Entra ID. Por que esta novidade é importante? O Microsoft Entra Cloud Sync utiliza agentes de provisionamento leves instalados no ambiente local. A configuração e a gestão são realizadas principalmente a partir da cloud, reduzindo a dependência de um servidor dedicado com todo o mecanismo do Entra Connect Sync. Contudo, as organizações que dependiam do Microsoft Entra Hybrid Join continuavam a precisar do Entra Connect Sync para sincronizar os seus objetos de computador. O suporte a dispositivos começa a remover este bloqueio e oferece benefícios como: Maior viabilidade para migrar do Entra Connect Sync para o Cloud Sync; Redução da infraestrutura de sincronização mantida localmente; Possibilidade de instalar vários agentes para alta disponibilidade; Gestão centralizada no Microsoft Entra Admin Center; Sincronização de utilizadores, grupos e, agora, dispositivos; Provisionamento de dispositivos individuais a pedido; Possibilidade de gestão e automação através do Microsoft Graph. Pré-requisitos Antes de ativar a sincronização de dispositivos, a organização deve cumprir os seguintes requisitos: Requisito Descrição Agente de provisionamento Instalar o Microsoft Entra provisioning agent na versão 1.1.1107 ou posterior Configuração do Cloud Sync Ter uma configuração ativa de sincronização do AD para o Microsoft Entra ID Tenant e domínio Conhecer o Tenant ID e o domínio verificado usado pelos dispositivos Ambientes federados Utilizar um domínio federado Ambientes não federados Utilizar o domínio principal *.onmicrosoft.com Configuração do SCP Ter acesso temporário a uma conta membro de Enterprise Admins em cada floresta, quando necessário Permissão no Entra ID Utilizar uma conta com, no mínimo, a função Hybrid Identity Administrator Sempre que possível, o acesso privilegiado para configurar o Service Connection Point deve ser concedido temporariamente, através de um processo Just-in-Time ou do Microsoft Entra Privileged Identity Management. O papel do Service Connection Point O Service Connection Point, ou SCP, permite que os computadores associados ao domínio descubram automaticamente o tenant Microsoft Entra no qual devem realizar o registo. O SCP deve estar corretamente configurado em cada floresta do Active Directory que contenha computadores associados ao domínio. Antes de alterar essa configuração, a organização deve verificar se já existe um SCP e confirmar os valores atuais de: azureADName; azureADId. Uma configuração incorreta pode direcionar os dispositivos para o tenant errado. Por isso, esta etapa deve ser cuidadosamente validada antes da ativação em produção. Como ativar a sincronização A funcionalidade pode ser habilitada no Microsoft Entra Admin Center: Aceder ao Microsoft Entra Admin Center com a função Hybrid Identity Administrator; Navegar para Entra ID > Entra Connect > Cloud Sync; Selecionar a configuração existente do AD para o Microsoft Entra ID; Abrir Properties; Editar a secção de configurações básicas; Selecionar Enable device sync; Aplicar a alteração. A Microsoft também disponibiliza o provisionamento a pedido, permitindo testar a sincronização de um objeto de computador específico antes de expandir o processo para todo o ambiente. Que atributos são sincronizados? Entre os principais atributos tratados pelo Cloud Sync encontram-se: Atributo no Microsoft Entra Origem no Active Directory AccountEnabled userAccountControl DeviceId objectGUID DeviceOSType operatingSystem DisplayName displayName e dNSHostName OnPremiseSecurityIdentifier objectSid RegisteredOwnerReference mS-DS-CreatorSID SourceAnchor objectGUID UserCertificate userCertificate O valor de DeviceTrustType é definido como ServerAd, identificando o dispositivo como proveniente do Active Directory local. Atenção aos dispositivos eliminados A gestão do ciclo de vida dos dispositivos exige atenção especial. Quando um computador é eliminado no Active Directory, o Cloud Sync pode eliminar o dispositivo correspondente no Microsoft Entra ID. O dispositivo também poderá ser removido quando: For executado dsregcmd /leave; Um administrador o eliminar manualmente no Microsoft Entra Admin Center; O serviço de registo de dispositivos processar a saída do dispositivo. Caso o dispositivo seja eliminado por outro serviço ou por um administrador, o Cloud Sync poderá não o recriar automaticamente no ciclo seguinte, a menos que o objeto correspondente seja alterado no Active Directory. A recuperação poderá exigir a restauração em Deleted devices, uma alteração no objeto do computador no AD ou um novo provisionamento a pedido. Já é possível abandonar o Entra Connect Sync? Ainda não em todos os ambientes. A sincronização de dispositivos remove uma limitação muito importante, mas a decisão de migrar deve considerar todas as funcionalidades utilizadas atualmente, incluindo: Regras de sincronização personalizadas; Filtros de unidades organizacionais e atributos; Topologia de florestas e domínios; Writeback de grupos, utilizadores ou outros objetos; Dependências de Exchange híbrido; Métodos de autenticação; Microsoft Entra Hybrid Join; Windows Hello for Business; Aplicações que dependem de atributos específicos. Além disso, como a funcionalidade ainda está em Preview, não é recomendável desativar imediatamente o Entra Connect Sync num ambiente de produção sem avaliação, piloto, documentação do estado atual e um plano de reversão. Recomendação da V7A A chegada do Device Sync representa um avanço significativo na modernização das identidades híbridas. Contudo, a migração não deve ser tratada apenas como a substituição de uma ferramenta por outra. A V7A recomenda uma abordagem progressiva: Inventariar as funcionalidades utilizadas no Entra Connect Sync; Atualizar e validar os agentes de provisionamento; Rever a configuração do SCP; Criar um grupo piloto de dispositivos; Testar o provisionamento a pedido; Confirmar o estado do Hybrid Join com dsregcmd /status; Monitorizar erros e dispositivos duplicados; Preparar um plano de reversão; Expandir gradualmente após a validação do piloto. Conclusão O suporte à sincronização de dispositivos aproxima o Microsoft Entra Cloud Sync de se tornar uma alternativa mais completa ao tradicional Entra Connect Sync. Para muitas organizações, esta era a última grande dependência técnica que impedia a modernização do modelo de sincronização de identidades. Ainda assim, o recurso encontra-se em Preview e deve ser adotado com planeamento, testes e controlo adequado dos riscos. Mais do que uma simples atualização, esta funcionalidade abre um novo caminho para ambientes de identidade híbrida mais leves, resilientes e orientados para a cloud. Fonte oficial: Configurar a sincronização de dispositivos com o Microsoft Entra Cloud Sync
Microsoft Purview reduz sincronização das políticas DLP para 30 minutos
Microsoft Purview acelera a sincronização das políticas DLP para 30 minutos As organizações poderão aplicar alterações às políticas de prevenção contra perda de dados com muito mais rapidez no Microsoft 365. A Microsoft anunciou uma melhoria importante no serviço de sincronização do Microsoft Purview Data Loss Prevention — DLP. Com esta atualização, as alterações realizadas numa política DLP deverão ser sincronizadas nos serviços suportados do Microsoft 365 em até 30 minutos. Anteriormente, o processo poderia demorar até duas horas, dependendo do serviço e do tipo de política. Esta redução permitirá que as equipas de segurança e conformidade respondam mais rapidamente a novos riscos, incidentes e alterações nos requisitos de proteção da informação. O que é o Microsoft Purview DLP? O Microsoft Purview Data Loss Prevention ajuda as organizações a identificar, monitorizar e proteger informações confidenciais. Através das políticas DLP, uma organização pode, por exemplo: Impedir o envio externo de documentos confidenciais; Detetar números de cartões, dados pessoais ou informações financeiras; Restringir a cópia de ficheiros para dispositivos USB; Bloquear o carregamento de informações sensíveis em serviços cloud não autorizados; Apresentar avisos aos utilizadores antes da partilha de informação; Gerar alertas para as equipas de segurança e conformidade. Estas políticas podem abranger diferentes localizações do Microsoft 365, incluindo Exchange Online, SharePoint Online, OneDrive, Microsoft Teams e dispositivos integrados com o Endpoint DLP. O que vai mudar? O tempo previsto para a sincronização das alterações será reduzido para 30 minutos. Elemento Situação anterior Nova experiência Sincronização de alterações DLP Até 2 horas Até 30 minutos Ativação da melhoria Dependente do serviço Automática Alterações administrativas necessárias — Nenhuma Impacto nos fluxos de administração Possível espera prolongada Mesmo fluxo, menor espera A Microsoft indica que esta melhoria será ativada por defeito. Os administradores continuarão a criar, testar, alterar e publicar as políticas através do Microsoft Purview, sem necessidade de configurar uma nova opção. Quando estará disponível? A disponibilização mundial está prevista para começar no final de agosto de 2026. Por se tratar de uma implementação progressiva, a melhoria poderá não ficar disponível para todas as organizações exactamente no mesmo dia. As datas anunciadas no Microsoft 365 Roadmap e no Centro de Mensagens também podem sofrer alterações. Por que esta redução é importante? Embora a mudança pareça representar apenas uma melhoria de desempenho, ela tem impacto direto na capacidade de resposta das equipas de segurança. Imagine que uma organização identifica o envio indevido de determinado tipo de documento para destinatários externos. A equipa de conformidade altera imediatamente a política DLP para bloquear essa ação. Quanto menor for o tempo de sincronização, menor será a janela durante a qual a informação poderá continuar exposta às condições anteriores. A redução para 30 minutos pode melhorar particularmente os seguintes cenários: Resposta a incidentes de fuga de informação; Correção urgente de uma política mal configurada; Inclusão de novos utilizadores, departamentos ou localizações; Atualização dos tipos de informação confidencial; Aplicação de novas restrições a dispositivos e aplicações; Ajuste rápido de exceções e falsos positivos; Implementação de requisitos de auditoria ou regulamentação. Para ambientes empresariais, esta previsibilidade também facilita o planeamento das janelas de mudança e a validação das políticas. Mais rapidez não elimina a necessidade de testar A melhoria do tempo de sincronização não significa que todas as alterações devam ser aplicadas diretamente em produção. Uma política DLP demasiado restritiva pode bloquear processos legítimos, gerar muitos alertas ou afetar a produtividade dos utilizadores. A Microsoft recomenda a utilização do modo de simulação para avaliar o comportamento de uma política antes da sua aplicação efetiva. Uma abordagem segura deverá considerar: Criar ou duplicar a política; Executá-la em modo de simulação; Analisar correspondências, alertas e falsos positivos; Ajustar condições, exceções e ações; Aplicá-la inicialmente a um grupo-piloto; Expandir gradualmente o âmbito; Monitorizar continuamente os resultados. O modo de simulação permite observar como a política se comportaria sem aplicar imediatamente as ações de bloqueio. Isso reduz o risco de interrupção dos processos de negócio. Sincronização não significa proteção retroativa imediata É importante distinguir três momentos: A alteração é guardada no Microsoft Purview; A política é sincronizada nos serviços abrangidos; O conteúdo ou atividade é avaliado de acordo com a política atualizada. No Endpoint DLP, por exemplo, depois de uma política ser sincronizada, os itens abrangidos podem ser reavaliados quando voltarem a ser acedidos ou modificados. Portanto, o novo SLA de sincronização não deve ser interpretado como garantia de que todo o conteúdo histórico será imediatamente analisado no mesmo período. A efetividade também pode variar conforme a localização, o cliente utilizado, a conectividade do dispositivo e os pré-requisitos técnicos de cada serviço. O que os administradores devem fazer? A atualização será automática e não exige alterações nas políticas existentes. Ainda assim, recomendamos algumas ações de preparação: Informar as equipas de segurança, conformidade e suporte; Atualizar os procedimentos internos que ainda considerem uma espera de duas horas; Rever os testes utilizados para validar alterações DLP; Confirmar os responsáveis pela aprovação de mudanças urgentes; Monitorizar o Centro de Mensagens do Microsoft 365; Verificar regularmente o estado e os alertas das políticas; Manter evidências das alterações para fins de auditoria. As organizações também devem evitar prometer que uma política ficará ativa imediatamente. Mesmo com a melhoria, deve ser considerada uma janela de até 30 minutos para a sincronização. Impacto para as organizações Esta mudança não substitui uma estratégia de proteção de dados bem definida, mas torna a sua execução mais ágil. Para retirar maior valor do Microsoft Purview DLP, a organização deve manter alinhados: A classificação da informação; Os tipos de informação confidencial; As políticas DLP; Os rótulos de confidencialidade; Os processos de resposta a incidentes; A formação e sensibilização dos utilizadores; A monitorização e melhoria contínua. Uma política tecnicamente correta, mas desalinhada com os processos da organização, poderá continuar a produzir falsos positivos ou deixar dados importantes sem proteção. Conclusão A redução do tempo de sincronização das políticas DLP para até 30 minutos representa uma evolução relevante para a segurança e conformidade no Microsoft 365. Sem introduzir novos procedimentos administrativos, a Microsoft permitirá que as alterações de proteção sejam propagadas mais rapidamente. Isso reduz a janela de exposição e melhora a capacidade de resposta perante incidentes e novos requisitos. No entanto, a velocidade de propagação deve ser acompanhada por uma boa governação: simulação, implementação gradual, monitorização e revisão contínua das políticas. Na V7A, apoiamos organizações na implementação e otimização do Microsoft Purview, incluindo classificação da informação, políticas DLP, proteção de endpoints e conformidade no Microsoft 365. Título SEO: Microsoft Purview reduz sincronização das políticas DLP para 30 minutos Meta description: A Microsoft vai reduzir para 30 minutos o tempo de sincronização das políticas DLP no Microsoft Purview. Conheça o impacto e como preparar a organização. Slug sugerido: microsoft-purview-dlp-sincronizacao-30-minutos Palavras-chave: Microsoft Purview, DLP, Data Loss Prevention, Microsoft 365, proteção de dados, conformidade, segurança da informação. Nota editorial: A documentação pública consultada ainda menciona, em alguns cenários, aproximadamente uma hora para uma política entrar em vigor. O prazo de 30 minutos corresponde à melhoria anunciada para implementação a partir do final de agosto de 2026; por isso, a disponibilidade deve ser acompanhada no Centro de Mensagens do tenant. Fontes: Visão geral do Microsoft Purview DLP, Microsoft Purview Endpoint DLP, Modo de simulação das políticas DLP e Microsoft 365 Roadmap.
O que é cibersegurança?
Cibersegurança refere-se a todos os aspectos da proteção de uma organização e dos seus colaboradores e ativos contra ameaças cibernéticas. À medida que os ataques cibernéticos se tornam mais comuns e sofisticados e as redes corporativas se tornam mais complexas, são necessárias diversas soluções de Cibersegurança para mitigar o risco cibernético corporativo. Por que a cibersegurança é importante? Os ataques cibernéticos e o crime cibernético podem perturbar, danificar e destruir empresas, comunidades e vidas. Incidentes de segurança podem levar ao roubo de identidade, extorsão e perda de informações confidenciais, impactos que podem afetar significativamente as empresas e a economia. Segundo estimativas, o crime cibernético custará à economia mundial US$ 10,5 trilhões por ano até 2025.3 Mas uma pergunta mais pertinente pode ser: "Por que a cibersegurança é especialmente importante agora?" Hoje, os cibercriminosos estão usando novas tecnologias a seu favor. Por exemplo, as empresas estão adotando a computação em nuvem para obter eficiência e inovação. Mas os agentes mal-intencionados veem esse avanço como uma superfície de ataque em expansão, pronta para invasão. Agentes mal-intencionados também estão explorando a dark web. De acordo com o IBM X-Force 2025 Threat Intelligence Index, agentes de ameaças sofisticados, incluindo estados-nação, estão usando o anonimato da dark web para adquirir novos recursos. Elas estão demonstrando níveis nunca antes vistos de coordenação, automação e proeza, elevando o risco de violações de dados a interrupções em grande escala.