Horário de Verão - Updates

A esta altura, quem vive nas áreas sujeitas à mudança de horário de verão no Brasil, já notou que não houve mudança de horário este ano, horário este que iniciaria em outubro de 2019 e terminaria em fevereiro de 2020.

É importante lembrar que, até segunda ordem, não haverá horário de verão em 2020 nem nos anos seguintes no Brasil.

De qualquer maneira, gostaria de compartilhar os KBs da Microsoft que configuram os Windows Server e Windows Client que não haverá mudança de horário no fuso Brasília -3.

Para sistemas:

Windows Server 2012 R2

Windows Server 2012

Windows Server 2008 R2

Windows Server 2008 x86 e x64

Windows 8.1

Windows 8

Windows 7

Utilizar a kb4507704

https://www.catalog.update.microsoft.com/search.aspx?q=kb4507704

Para sistemas Windows 10, os updates são cumulativos.

A atualização que configura o sistema operacional de que não haverá horário de verão saiu no release de 16 de julho de 2019. Portanto, se o Windows estiver em qualquer release mais recente, já terá a atualização de que não haverá horário de verão para 2019 em diante.

https://support.microsoft.com/en-us/help/4505903

Ação Paliativa

Se por algum motivo o update não puder ser instalado, uma ação paliativa é alterar o fuso horário do Windows para "Caiena, Fortaleza", pois este é um fuso que nunca teve horário de verão. Esta não é uma solução definitiva pois o outlook ou outro aplicativo que trabalhe com agendas e compromissos terão problemas para calcular apontamentos que relacionem o fuso Brasília no período que havería horário de verão, nestes sistemas.

Mais informações:

https://support.microsoft.com/en-us/help/4507704/dst-changes-in-windows-for-brazil-and-morocco

Filtrar Sincronização por Atributo no AADConnect

Introdução
=============
Existem cenários em que a sincronização do AADConnect precisa ser filtrada com maior granularidade que a filtragem por Unidade Organizacional.

Neste post irei mostrar como filtrar a sincronização por atributo.

Em nosso exemplo, utilizaremos o atributo msExchExtensionAttribute39 e para que a conta seja sincronizada, o valor Sync deverá estar presente.


Ambiente
============
AADConnect versão 1.4.38.0 instalado em um Windows Server 2012 R2


Passos
============

Iniciar abrindo o Synchronization Rules Editor.

Na Janela "Synchronization Rules Editor" clicar em "Add new rule".

Digitar um nome para a regra;

No campo "Conected System" selecionar o domínio do AD local;

Em "Connected System Object Type" selecionar "user";

Em "Metaverse Object Type" selecionar "person";

Em "Link Type" "Join";

Alterar o "Precedence" para "50" ou outro valor abaixo de "99";

Clicar em "Next".

Em "Scoping Filter" adicionar uma "clause", selecionar o atributo desejado, neste caso é o atributo "msExchExtensionAttribute39", Operator "EQUAL" e valor "Sync".

Em "Join rules" não fazemos alteração e simplesmente clicamos em "next".

Em "Transformations":

Selecionar campo "Constant", "cloudFiltered";

No campo "Source" inserir o valor "false";

Clicar em "Add".

Clicar novamente em "add new rule" para criar uma nova regra.

Escolher o nome da segunda regra;

Inserir as mesmas informações da regra anterior, exceto o campo "Precedence" que deve estar com valor entre regra recém criada e a próxima regra. No caso 99 é um número satisfatório.

Seguir para "Transformations" sem inserir nada em "Scoping filter" nem em "Join rules";

Inserir os mesmos dados da regra anterior, exceto o campo "Source" que terá valor "true";

Clicar em "Add".

Para que as alterações tenham efeito, um full sync será realizado na próxima janela de sincronização.

Lembre-se que a OU ainda deverá estar selecionada, nas configurações do conector, para que os objetos dentro dela sejam sincronizados.

Mais Informações
============

Positive filtering: "only sync these"

https://docs.microsoft.com/pt-br/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering#positive-filtering-only-sync-these

Azure AD Connect sync: Understanding Declarative Provisioning

https://docs.microsoft.com/pt-br/azure/active-directory/hybrid/concept-azure-ad-connect-sync-declarative-provisioning

HardMatch de Ms-Ds-ConsistencyGuid e ImmutableId

Em uma implantação de AADConnect, me deparei com um tenant do Office 365 que possuía usuários de produção criados na nuvem, no Office 365. E mais, ao colocar somente 1 conta para ser sincronizada com o AADConnect, o SoftMatch não acontecia, ocasionando a criação de uma conta sincronizada, porém diferente da que o usuário já utilizava no Office 365.

Durante a instalação do AADConnect tomei o cuidado de não permitir a sincronização inicial ao final do wizard de configuração. Isto me poupou o trabalho de ter que remover todas as contas duplicadas que teriam sido criadas pela sincronização inicial.

Vemos abaixo um de nossos usuários que já haviam sido criados na nuvem antes da instalação do AADConnect:

Análise do ambiente para aplicar o HardMatch

======================

O AADConnect foi instalado na versão 1.4.38.0 e o SourceAnchor escolhido na instalação foi o campo mS-Ds-ConsistencyGuid.

Caso o SourceAnchor de sua implementação seja diferente, não prossiga com o passo a passo deste blog.

Verificando os usuários de nuvem no Office 365, notei que não possuíam ImmutableID. Isto é normal pois foram criados on-line. Veja abaixo:

Verifiquei também, no Active Directory (AD) local, que as contas que eu queria fazer o HardMatch possuiam o campo Ms-Ds-ConsistencyGuid com valores. Veja abaixo:

Estratégia Adotada

======================

Adotada a seguinte estratégia:

1. Obter a relação de UserPrincipalName e ms-ds-consistencyguid do AD Local.
2. Traduzir o valor obtido no passo anterior para base64 usando Translate_ImmutableID.ps1
3. Usar comando Set-Msoluser -userprincipalname XXX -ImmutableId YYYY
4. No AADConnect, colocar o usuário em uma OU marcada para ser sincronizada pelo AADCnnect e então fazer o delta sync.

Com a estratégia em mente, mãos à obra!

=======================

• Passo 1 - Obter a relação de UserPrincipalName e ms-ds-consistencyguid do AD Local.
• Loguei em um controlador de domínio e abri o powershell
• Executado o comando abaixo para obter o ms-ds-consistencyguid do usuário

Get-ADUser -Filter "UserPrincipalName -eq 'fio@maier.eti.br'" -Properties Ms-Ds-ConsistencyGuid |select userprincipalname,@{name='ms-ds-consistencyguid';expression={[guid]$_.'ms-ds-consistencyguid'}}

• Com o valor do campo em mãos, pude partir para o passo 2, que seria converter este valor para que pudesse ser inserido no campo ImmutableId da conta correspondente no Office 365

• Passo 2 - Traduzir o valor do campo ms-ds-consistencyguid, para o valor correspondente do ImmutableID, utilizando o script Translate_ImmutableID.ps1
• Este versátil script permite converter qualquer uma das bases vindas do campo ms-ds-consistencyguid para o ImmutableId e o contrário também
• Segue exemplo da utilização do script. E observe o valor do ImmutableID

• Obtive este script do site https://blog.jumlin.com/2018/09/powershell-script-convert-immutableid/

• Passo 3 - Usar comando Set-Msoluser -userprincipalname fio@maier.eti.br -ImmutableId YYYY
• Agora que já temos o valor do ImmutableID correspondente ao valor do campo ms-ds-consistencyguid do AD local, vamos inseri-lo à conta do Office 365.

Set-MsolUser -UserPrincipalName fio@maier.eti.br -ImmutableId 0cqchBysdU6a7ZsPodvuoA==

 

• O processo até aqui ficou assim:

Agora que o ms-ds-consistencyguid da conta do AD local está de acordo com o ImmutableId da conta do Office 365, basta colocar o usuário do AD local em uma OU que é sincronizada pelo AADConnect e efetuar um delta sync.

• Passo 4 - No AADConnect, colocar o usuário em uma OU marcada para ser sincronizada pelo AADCnnect e então fazer o delta sync.

 

• Acessando o portal do Office 365, podemos ver que a conta agora aparece como "Sincronizado" e sem duplicatas.

 

Até a próxima,

Daniel Maier