With this script, you will be able to get a list of inactive user accounts in Active Directory. There are two examples : one of them use the Microsoft Active Directory cmdlets and the other uses the Quest one.
Script (with Microsoft Active Directory module loaded : import-module activedirectory) :
Get-ADUser -ResultSetSize $null -Properties LastLogonTimestamp -Filter * | ? { [datetime]::FromFileTime($_.LastLogonTimestamp) -le (Get-Date).Addmonths(-6) } | % {
$name = $_.name
$time = [datetime]::FromFileTime($_.LastLogonTimestamp)
Write-Host $name " , " $time
}
Script (with Quest Active Directory module) :
Get-QADUser -SizeLimit 0 -IncludedProperties LastLogonTimestamp | where { $_.LastLogonTimestamp -le (Get-Date).Addmonths(-6) } |Format-Table name,LastLogonTimestamp
References :
Detailed Description
The Get-ADUser cmdlet gets a user object or performs a search to retrieve multiple user objects.
The Identity parameter specifies the Active Directory user to get. You can identify a user by its distinguished name (DN), GUID, security identifier (SID), Security Accounts Manager (SAM) account name or name. You can also set the parameter to a user object variable, such as $<localUserObject> or pass a user object through the pipeline to the Identity parameter.
To search for and retrieve more than one user, use the Filter or LDAPFilter parameters. The Filter parameter uses the PowerShell Expression Language to write query strings for Active Directory. PowerShell Expression Language syntax provides rich type conversion support for value types received by the Filter parameter. For more information about the Filter parameter syntax, see about_ActiveDirectory_Filter. If you have existing LDAP query strings, you can use the LDAPFilter parameter.
This cmdlet retrieves a default set of user object properties. To retrieve additional properties use the Properties parameter. For more information about the how to determine the properties for user objects, see the Properties parameter description.
Detailed Description
Use this cmdlet to search an Active Directory domain or container for user accounts that meet certain search criteria, or to bind to a certain user account by DN, SID, GUID, UPN or Domain\UserName. You can search by user attributes or specify your search criteria by using an LDAP search filter.
The output of the cmdlet is a collection of objects, with each object representing one of the user accounts found by the cmdlet. You can pipe the output into another cmdlet, such as Set-QADUser, to make changes to the user accounts returned by this cmdlet.
The cmdlet takes a series of optional, attribute-specific parameters allowing you to search by user attributes. The attribute-specific parameters have effect if SearchRoot is specified whereas Identity is not. If you specify SearchRoot only, then the cmdlet returns all users found in the SearchRoot container.
You can use attribute-specific parameters to search for user accounts that have specific values of certain attributes. Thus, to find all user accounts that have the givenName attribute set to Martin, you may add the following on the command line: “-FirstName Martin”. To search for user accounts that have a certain attribute not set specify (empty string) as the parameter value.
If a given attribute is referred to by both the ObjectAttributes array and an attribute-specific parameter, the ObjectAttributes setting has no effect on that attribute. The cmdlet searches for the attribute value specified by the attribute-specific parameter.
With more than one attribute-specific parameter supplied, the search conditions are combined by using the AND operator, so as to find the user accounts that meet all the specified conditions. Thus, if you supply both the -FirstName and -LastName parameters, the cmdlet searches for the user accounts that have the givenName attribute set to the FirstName parameter value and the sn attribute set to the LastName parameter value.
Each of the attribute-specific parameters accepts the * wildcard character in the parameter value to match zero or more characters (case-insensitive). For instance, a* matches A, ag, Amsterdam, and does not match New York.
The cmdlet has optional parameters that determine the server and the security context for the operation. Normally, the connection parameters could be omitted so far as a connection to a server is established prior to using the cmdlet. In this case, the server and the security context are determined by the Connect-QADService cmdlet.
If you do not use Connect-QADService and have no connection established prior to using a cmdlet, then the connection settings, including the server and the security context, are determined by the connection parameters of the first cmdlet you use. Subsequent cmdlets will use those settings by default.