Solved

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

Posted on 2014-10-21
12
297 Views
Last Modified: 2014-10-22
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
Comment
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 5
  • 2
12 Comments
 
LVL 29

Expert Comment

by:becraig
ID: 40396220
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
 
LVL 8

Author Comment

by:Senior IT System Engineer
ID: 40396239
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
 
LVL 29

Expert Comment

by:becraig
ID: 40396260
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
Online Training Solution

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action. Forget about retraining and skyrocket knowledge retention rates.

 
LVL 29

Expert Comment

by:becraig
ID: 40396269
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
 
LVL 8

Author Comment

by:Senior IT System Engineer
ID: 40396279
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
 
LVL 29

Assisted Solution

by:becraig
becraig earned 334 total points
ID: 40396296
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
 
LVL 40

Assisted Solution

by:footech
footech earned 166 total points
ID: 40397945
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
 
LVL 8

Author Comment

by:Senior IT System Engineer
ID: 40398220
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
 
LVL 29

Accepted Solution

by:
becraig earned 334 total points
ID: 40398232
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
 
LVL 8

Author Comment

by:Senior IT System Engineer
ID: 40398238
Thanks Craig,
0
 
LVL 8

Author Closing Comment

by:Senior IT System Engineer
ID: 40398239
thank you guys.
0
 
LVL 40

Expert Comment

by:footech
ID: 40398250
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

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A recent project that involved parsing Tableau Desktop and Server log files to extract reusable user queries for use in other systems. I chose to use PowerShell to gather the data, and SharePoint to present it...
My attempt to use PowerShell and other great resources found online to simplify the deployment of Office 365 ProPlus client components to any workstation that needs it, regardless of existing Office components that may be needing attention.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

734 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question