4

Part of my job is to make sure that for computers in a specific OU, whats Actually in use = whats listed in AD = whats listed in SCCM. This is for an environment with 250k PCs, but i specifically care about one department's 70k. Its pretty easy to compare AD with SCCM, but its more difficult to keep track of computers that don't really exist. I'm trying to think of creative ways to figure this out.

my question is: Would a good way to find non-existent machines to query AD with Powershell for computers that haven't logged in in X amount of days?

I thought about a much more complicated task in powershell as follows: Pull dnshostnames from AD Ping all hosts in my OU and for success, remove them from the list. Run this say every 6 hours for a week, continuing to remove machines that have had ping success. Laptops I would have to handle differently.

Any other ideas, suggestions etc.?

mcudm001
  • 41
  • 1

3 Answers3

3

On a variation of Patricks comprehensive suggestion, I would use the replicated LastLogontimeStamp attribute to narrow down the search:

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}

$oldComps will then hold all computers that has not logged on in at least 30 days.

It's a bit counterintuitive with a threshold of 44 days, but to prevent a flood of replication updates to the LastLogontimeStamp, the attribute is only updated if its value is older than 9 days. If the value is between 9 and 14 days out of date, a randomized process determines whether to update it or not.

Here is a great explanation: http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

Mathias R. Jessen
  • 25,161
  • 4
  • 63
  • 95
  • LastLogonTimeStemp is replicated!? Bugger. That would have saved me some time a few months back :) – Patrick Jun 10 '13 at 13:54
1

It sounds like you need something like oldcmp: http://www.joeware.net/freetools/tools/oldcmp/

This searches the domain or Organisational Unit specified for machines which have not logged in for the last x days, and provides you with reporting or the facility to disable those computer accounts.

The tool and representation in Active Directory is only representing what the domain knows about, so you still need to build a reporting process external to the Active Directory environment to enable you to track the machines which report as having not been used to verify they have actually left the organisation and should be removed. A prime example here is indeed laptops: the tools may report a laptop as being out-of-use when really this is hiding the fact the laptop is simply in-use offline.

Similar approaches are available involving reports in SCCM to investigate the time when a machine was last able to give a heartbeat; provided the machines have functioning SCCM clients, this would arguably be a better approach than pulling a report and attempting to ping them - a technique which would be incredibly labour intensive and prone to false positive results.

Cosmic Ossifrage
  • 1,640
  • 14
  • 23
  • 1
    In the end, the reason we are going through this process is to improve SCCM client health, so I'll end up utilizing SCCM heartbeats to troubleshoot further, but I wanted to narrow the list of machines down first. Thanks for the oldcmp link, that looks like it could have some value. – mcudm001 May 20 '13 at 13:07
1

A computers AD object has a LastLogon time stamp, which gives you a useful indicator of a computer current state.

If you are able to install thrid party cmdlets then the Quest Active Directory cmdlets are incredibly helpful.

$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 will list all your computers in the specified OU and their last logon date like this :

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$

You would need to run this against all DC's that this computer may logon against. An organisation your size this is probably impractical.

As an alternate measure. The object property 'whenChanged' on your Computer AD objects is the Machine Account Password. This automatically updates after 30 days (default in Win 2K and later, usually. Checking the default domain group policy object can confirm this).

If you find computer accounts where 'whenChanged' is older than 30 days then these are machines that have not logged on in this period. This works well for larger multi DC networks as this figure is replicated where 'lastLogon' is not.

Simply amend the line in the script above to remove '.lastLogon' and replace it with '.whenChanged'

If you can't get Quest AD installed you will need to use a machine with RSAT installed (or a DC) and use the Get-ADComputer cmdlet (type 'Import-Module ActiveDirectory').

A third option for tracking future use would be to use a logon script. I did this at a clients a few years back and it worked well, although we were on a couple of hundered machines, not ~70K.

At the time our logon script was a .BAT file. Create a new .BAT in NETLOGON with the following line (eg LogonTrack.BAT)

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

and at the end of any of the logon batch file that may be used by your 70K users add a line

call LogonTrack.BAT

This creates a file with the name of the computer, and the file date is the last logon in the mapped location.

I wouldn't recommend this but you could audit eventlogs for this information, although I generally avoid log diving where possible. You would need Event 4624.

Finally, I also use LANSweeper at a clients which is great. That has great reporting on old computers. However as a paid product requiring a separate install and a server so may not be any good for you. Plus for 250K systems you'd need a fairly powerful backend, not a repurposed VM that was lying around.

Patrick
  • 1,280
  • 1
  • 15
  • 36
  • Be aware that the Lastlogon attribute has the 0x1 Systemflag set in the AD schema, meaning that it's not replicated. If Computers use different DC's as logon servers, you'll need to be able to query all Domain Controllers and use the latest results for each computer account - which is a bit cumbersome – Mathias R. Jessen Jun 10 '13 at 10:24
  • Yes, I did mention that. The 'whenChanged' value avoids this issue, although its not as clear a result as the lastLogon date. – Patrick Jun 10 '13 at 11:34