Como bombardear um GPO com bomba-relógio?

Estou trabalhando muito no ensino superior, onde é um requisito bastante comum reconfigurar vários membros do domínio do Windows (por exemplo, PCs em sala de aula) durante um curso ou evento específico e ter essa configuração desfeita posteriormente.

Como a maioria das alterações de configuração solicitadas pode ser feita por meio dos Objetos de Diretiva de Grupo e essas alterações são revertidas automaticamente quando o GPO é desvinculado ou desativado no nível da OU, é uma rota muito confortável a seguir.

A única desvantagem é que a vinculação e desassociação manual repetida de GPOs nas UOs precisa de muitos lembretes e equipe de TI de plantão antes do início e após o término dos cursos - algo que a equipe de operações não pode garantir o tempo todo.

Existe uma maneira de especificar um prazo para a validade de um GPO específico?

active-directory group-policy

— o wabbit
fonte

Isso pode ser feito por meio da filtragem WMI . O cliente da diretiva de grupo executaria a consulta WQL a partir de um filtro WMI conectado e só aplicaria o GPO se a consulta retornasse um número diferente de zero de linhas. Portanto, criando um filtro WMI, verificando se a hora atual do sistema está dentro de um determinado intervalo de tempo e vinculando esse filtro WMI ao GPO que você deseja obter, você obtém exatamente o que deseja.

A classe W32 win32_operatingsystem possui um atributo localdatetime que pode ser comparado a uma determinada data de sequência no formato 'aaaammdd hh: nn: ss', portanto, usando a sequência WQL como

select * from win32_operatingsystem where localdatetime >= '20150220 00:00:00' and localdatetime <= '20150223 15:00:00'

no root\CIMv2namespace garantiria que o GPO fosse aplicado apenas aos sistemas em que a hora local é entre 20 de fevereiro de 2015 00:00:00 e 23 de fevereiro de 2015 15:00:00:

configurar filtro WMI com string WQL

Verifique se você vinculou o filtro WMI ao GPO desejado:

vincular o filtro WMI ao GPO

Coisas para manter em mente:

o WQL está avaliando a data e hora local no cliente, que podem ou não estar sincronizadas com a fonte de tempo que você deseja usar. O tempo do cliente não será muito adiantado ou atrasado em relação ao tempo do controlador de domínio; caso contrário, a autenticação Kerberos será interrompida, mas pode haver pequenos desvios, mas considere-os
o cliente da diretiva de grupo verificará alterações no GPO e as aplicará com pouca frequência por padrão:

Por padrão, a Diretiva de Grupo do computador é atualizada em segundo plano a cada 90 minutos, com um deslocamento aleatório de 0 a 30 minutos.

Portanto, as configurações padrão permitirão apenas uma precisão de +2 horas. O intervalo de atualização pode ser alterado por (outra) configuração de diretiva de grupo, se necessário.
sua política precisa poder reverter todas as alterações quando não for mais aplicada. Esse é o caso por padrão para todos os modelos administrativos gerenciados. As configurações de Preferências de Diretiva de Grupo podem precisar ser explicitamente definidas para "remover este item quando não for mais aplicado" :

— o wabbit
fonte

Muito esperto, parabéns a você.

— Massimo

Da minha experiência, existem algumas políticas em Modelos Administrativos que não reverter as alterações que fizeram, então é melhor fazer alguns testes primeiro ... Também, o que Massimo disse ...

— EliadTech

Acordado, todas as configurações que o direito ao registro, não basta voltar ao padrão quando desvinculado, ou mesmo definido como "Não configurado"

— mortenya

Adicione uma tarefa agendada para acionar um GPupdate nos horários de início e término e você poderá (?) Obter um pouco mais de precisão sem precisar ajustar o intervalo de atualização?

— Get-HomeByFiveOClock

@mortenya a parte "gerenciada" dos Modelos Administrativos garante que as configurações sejam realmente feitas em outra subárvore da seção do registro - por exemplo, HKLM\Software\Policiesou HKCU\Software\Policies. Esses locais de "política" serão limpos se o objeto de política que define a chave não se aplicar mais ou se a propriedade estiver definida como "Não configurado". Para modelos ADM de estilo antigo que estão gravando no registro, você está certo, eles são "tatuados" no registro do cliente e não são removidos posteriormente. Relacionados: serverfault.com/questions/566180

— o wabbit