• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 322
  • Last Modified:

How to determine which AD Computer objects can be safely deleted without causing any problem ?

Hi,

in a Windows Server 2003 domain functionality level, how can I safely delete or clean up the old AD computer objects that is no longer in used or accessed in greater than 90 days ?

Any idea and suggestion using powershell would also be greatly appreciated.

Thanks
0
Senior IT System Engineer
Asked:
Senior IT System Engineer
  • 5
  • 5
  • 2
3 Solutions
 
becraigCommented:
Tombstone value should be 90 days + 14 days (windows default windows)

We can simply script out a check for all computers matching that timeline and do a remove computer.
#imports the AD module so we can query information in the AD
import-module activedirectory
#Sets the time we use for calling a server inactive (104 days)
$time = (Get-Date).Adddays(-104)
#this checks the entire AD
Get-ADComputer -Filter * -Properties LastlogonTimeStamp | select-object Name | where { [DateTime]::FromFileTime($_.lastLogonTimestamp) -gt $time } | %  { Remove-ADComputer -Identity $_ -WhatIf }

Open in new window


I added the whatif so you can validate before actually removing any computers.
0
 
Senior IT System EngineerIT ProfessionalAuthor Commented:
Thanks Craig,

Somehow thescriptdoesn't work, I can only see the following result when executing the script:

Get-ADComputer -Filter * -Properties LastlogonTimeStamp | select-object Name, LastlogonTimeStamp

Open in new window


Name            LastlogonTimeStamp                                                                                                
----            ------------------                                                                                                
CDG-2KS-DC01                  
CDG-2KS-DC01                  
CDG-2KS-DC01                  
CDG-2K3-DC01    130578583665781250                                                                                                
PRODDC1         130579115032107105                                                                                                
WGL-2K3-DC01    130579475361552241                                                                                                
JKT2K3DC01      130579507506562500                                                                                                
USEC2K3DC01     130058668887446250  
WS4000123
WS4000456
WS3000347        

why is that the workstation does not have the value in LastlogonTimeStamp but the domain controllers and some servers got it ?

also the date time stamp doesn't seems to be in human readable format.
0
 
becraigCommented:
I will have to take a look on my end to see why this might be.

On the second note:
If you notice in the script I cast that lastlogon timestamp value
[DateTime]::FromFileTime($_.lastLogonTimestamp)

That is based on the fact the format is not easily readable but we can convert it for output if need be.
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

 
becraigCommented:
MS has another method using password last set:

$lastSetdate = [DateTime]::Now - [TimeSpan]::Parse("45")
Get-ADComputer -Filter {PasswordLastSet -le $lastSetdate} -Properties passwordLastSet -ResultSetSize $null | FT samaccountname,PasswordLastSet

Open in new window


http://technet.microsoft.com/en-us/library/dd391949%28v=ws.10%29.aspx


Some additional reading on using last logon timestamp:
http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx
0
 
Senior IT System EngineerIT ProfessionalAuthor Commented:
yes Craig,

I can see the result when executing your script above. So how reliable is that Password Last Set timestamp to be used as the point to determine if the object is no longer in used after X amounts of days ?

and how to integrate that into the script ?
0
 
becraigCommented:
Once you have not disabled nor modified this in your environment it should be 30 days by default :

http://technet.microsoft.com/en-us/library/cc781050%28v=ws.10%29.aspx
script modified:


#imports the AD module so we can query information in the AD
import-module activedirectory
#Sets the time we use for calling a server inactive (104 days)
$lastSetdate = [DateTime]::Now - [TimeSpan]::Parse("45")
#this checks the entire AD
Get-ADComputer -Filter { PasswordLastSet -le $lastSetdate } -Properties passwordLastSet -ResultSetSize $null | %  { Remove-ADComputer -Identity $_.Name -WhatIf }

Open in new window

0
 
footechCommented:
The only time I've seen where queries using the AD cmdlets don't return all the attributes/properties that should be there are when I'm running the command on a DC.  What I've observed is running in an elevated session corrects this sometimes, but querying a remote DC seems to always work.  That's the only reason I can think of that the lastlogontimestamp would be blank (you should be able to see a value for the attribute if you look at the object using ADSI Edit).

I'll typically use Search-ADAccount for this type of task.  Also, you can use LastLogonDate property instead of LastLogonTimestamp to get a human readable format.
Search-ADAccount -AccountInactive -ComputersOnly -TimeSpan "90" | Select Name,LastLogonDate

Open in new window

0
 
Senior IT System EngineerIT ProfessionalAuthor Commented:
Thanks for the clarification guys.

What are the difference between the following two scripts ?

$lastSetdate = [DateTime]::Now - [TimeSpan]::Parse("104")
Get-ADComputer -Filter { PasswordLastSet -le $lastSetdate } -Properties passwordLastSet -ResultSetSize $null | Export-Csv C:\Inactive104-Get-ADComputer.csv

Open in new window

The script above returns 1795 results

Search-ADAccount -AccountInactive -ComputersOnly -TimeSpan "104" | Select Name,LastLogonDate | Export-Csv C:\Inactive104-Search-ADAccount.csv

Open in new window

The script above returns 1688 results

because somehow the result is slightly different eventhough the parameters is 104 days.
0
 
becraigCommented:
PasswordLastSet  indicates computers that have not reset their machine account password in X days

AccountInactive  indicates computers which have not logged in within the specified window.
   -AccountInactive [-DateTime DateTime] [-TimeSpan TimeSpan]
       Search for accounts that have not logged in within a given time period
       or since a specified time.  n.b. This requires the domain to be at
       'Windows Server 2003 Domain' Functional Level.
0
 
Senior IT System EngineerIT ProfessionalAuthor Commented:
Thanks Craig,
0
 
Senior IT System EngineerIT ProfessionalAuthor Commented:
thank you guys.
0
 
footechCommented:
One's looking at the PasswordLastSet property, the other is looking at the LastLogonDate property.  There's also some funkiness in how Search-ADAccount deals with the time it's given, so I don't treat the number of days as a hard rule.
http://windowsitpro.com/systems-management/search-adaccount-and-missing-15-days

To really see the difference you would have to compare the results.
0

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

  • 5
  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now