Acompanhando desktops corporativos

Acompanhando desktops corporativos

Parte do meu trabalho é garantir que, para computadores em uma UO específica, o que está realmente em uso = o que está listado no AD = o que está listado no SCCM. Isso é para um ambiente com 250 mil PCs, mas me preocupo especificamente com os 70 mil de um departamento. É muito fácil comparar o AD com o SCCM, mas é mais difícil controlar computadores que realmente não existem. Estou tentando pensar em maneiras criativas de descobrir isso.

minha pergunta é: seria uma boa maneira de encontrar máquinas inexistentes para consultar o AD com Powershell para computadores que não fazem login há X dias?

Pensei em uma tarefa muito mais complicada no PowerShell da seguinte forma: Extrair dnshostnames do AD Faça ping em todos os hosts em minha UO e, para ter sucesso, remova-os da lista. Execute isso a cada 6 horas durante uma semana, continuando a remover máquinas que tiveram ping bem-sucedido. Laptops eu teria que lidar de forma diferente.

Alguma outra idéia, sugestão etc.?

Responder1

Em uma variação da sugestão abrangente de Patrick, eu usaria o LastLogontimeStampatributo replicado para restringir a pesquisa:

Import-Module ActiveDirectory
$threshold = (Get-Date).AddDays(-44)
$computers Get-ADComputer -Filter * -SearchBase "ou=desiredou,dc=domain,dc=tld" -Properties LastLogontimeStamp
$oldComps = $computers | where {[Date.Time]::FromFileTime($_.lastlogontimestamp) -lt $threshold}

$oldCompsirá então manter todos os computadores que não fizeram logon por pelo menos 30 dias.

É um pouco contra-intuitivo com um limite de 44 dias, mas para evitar uma enxurrada de atualizações de replicação no LastLogontimeStamp, o atributo só será atualizado se seu valor tiver mais de 9 dias. Se o valor estiver desatualizado entre 9 e 14 dias, um processo aleatório determina se deve ser atualizado ou não.

Aqui está uma ótima explicação:http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

Responder2

Parece que você precisa de algo comovelhocmp:http://www.joeware.net/freetools/tools/oldcmp/

Isso pesquisa o domínio ou unidade organizacional especificado para máquinas que não fizeram login pela última vez.xdias e fornece relatórios ou a possibilidade de desabilitar essas contas de computador.

A ferramenta e a representação no Active Directory representam apenas o que o domínio conhece, portanto, você ainda precisa criar um processo de relatórioexternoao ambiente do Active Directory para permitir que você rastreie as máquinas que relatam que não foram usadas para verificar se realmente deixaram a organização e devem ser removidas. Um excelente exemplo aqui são os laptops: as ferramentas podem relatar que um laptop está fora de uso, quando na verdade isso esconde o fato de que o laptop está simplesmente em uso off-line.

Abordagens semelhantes estão disponíveis envolvendo relatórios no SCCM para investigar o momento em que uma máquina foi capaz de emitir um batimento cardíaco pela última vez; desde que as máquinas tenham clientes SCCM funcionais, esta seria sem dúvida uma abordagem melhor do que extrair um relatório e tentar fazer ping neles - uma técnica que seria incrivelmente trabalhosa e propensa a resultados falsos positivos.

Responder3

Um objeto AD de computador possui um carimbo de data/hora LastLogon, que fornece um indicador útil do estado atual do computador.

Se você conseguir instalar cmdlets de terceiros, então oDiretório Ativo da Questcmdlets são incrivelmente úteis.

$result = @()
$OU = "DC=ncp,DC=co,DC=uk"
Foreach($computer in (Get-QADComputer -SearchRoot "$ou" -sizelimit 0))
    {
    $result += "$((Get-QADComputer $computer -IncludeAllProperties).lastLogon), $computer"
    }

$result listará todos os seus computadores na UO especificada e a data do último logon assim:

06/10/2013 08:48:25, NATTHN21$
05/13/2011 14:54:04, NATTHN02$
06/10/2013 08:42:51, NATRHN01$
06/10/2013 08:45:38, NCPHON01$

Você precisaria executar isso em todos os controladores de domínio nos quais este computador possa fazer logon. Para uma organização do seu tamanho, isso provavelmente é impraticável.

Como medida alternativa. A propriedade do objeto 'whenChanged' nos objetos AD do seu computador é a senha da conta da máquina. Isso é atualizado automaticamente após 30 dias (padrão no Win 2K e posterior, normalmente. Verificar o objeto de política de grupo de domínio padrão pode confirmar isso).

Se você encontrar contas de computador onde 'whenChanged' tem mais de 30 dias, então essas são máquinas que não fizeram logon nesse período. Isso funciona bem para redes multi DC maiores, pois esse valor é replicado onde 'lastLogon' não é.

Simplesmente altere a linha no script acima para remover '.lastLogon' e substitua-o por '.whenChanged'

Se não conseguir instalar o Quest AD, você precisará usar uma máquina com RSAT instalado (ou um DC) e usar o cmdlet Get-ADComputer (digite 'Import-Module ActiveDirectory').

Uma terceira opção para rastrear o uso futuro seria usar um script de logon. Eu fiz isso em alguns clientes há alguns anos e funcionou bem, embora estivéssemos em algumas máquinas pesadas, não em ~ 70K.

Na época, nosso script de logon era um arquivo .BAT. Crie um novo .BAT em NETLOGON com a seguinte linha (por exemplo, LogonTrack.BAT)

::LogonTrack.BAT
ECHO %date% >Z:\%computername%

e no final de qualquer arquivo em lote de logon que possa ser usado por seus 70 mil usuários, adicione uma linha

call LogonTrack.BAT

Isso cria um arquivo com o nome do computador e a data do arquivo é o último logon no local mapeado.

Eu não recomendaria isso, mas você poderia auditar os logs de eventos para obter essas informações, embora eu geralmente evite mergulhar nos registros sempre que possível. Você precisariaEvento 4624.

Finalmente, eu também usoLANSweeperem um cliente, o que é ótimo. Isso traz ótimos relatórios em computadores antigos. No entanto, como um produto pago que requer uma instalação separada e um servidor, pode não ser bom para você. Além disso, para sistemas de 250K, você precisaria de um back-end bastante poderoso, não de uma VM adaptada que estivesse por aí.

informação relacionada