?
Solved

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

Posted on 2014-10-21
12
Medium Priority
?
307 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
Office 365 Training for Admins - 7 Day Trial

Learn how to provision tenants, synchronize on-premise Active Directory, implement Single Sign-On, customize Office deployment, and protect your organization with eDiscovery and DLP policies.  Only from Platform Scholar.

 
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 1336 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 664 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 1336 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

Are your AD admin tools letting you down?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

Question has a verified solution.

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

Uncontrolled local administrators groups within any organization pose a huge security risk. Because these groups are locally managed it becomes difficult to audit and maintain them.
This article will help to fix the below errors for MS Exchange Server 2013 I. Certificate error "name on the security certificate is invalid or does not match the name of the site" II. Out of Office not working III. Make Internal URLs and Externa…
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…
how to add IIS SMTP to handle application/Scanner relays into office 365.
Suggested Courses
Course of the Month13 days, 8 hours left to enroll

801 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