I’ve written several different articles demonstrating a variety of techniques for discovering disabled and inactive Active Directory user accounts with PowerShell. But for the sake of thoroughness, there is one final option. Although the Microsoft Active Directory cmdlets are easy to acquire and use, they do require a more updated infrastructure. Unfortunately, not everyone has access to the latest and greatest tools. If you are running an older version of PowerShell or have older domain controllers, and you don’t want to have to struggle with scripting .NET classes, then you have another option.
Quest Software, now part of Dell, has long offered their set of Active Directory PowerShell cmdlets for free. These cmdlets are designed to support their commercial product, ActiveRoles Server, but can be used even if you are not running that product. The most current version of the PowerShell cmdlets is only available to licensed users of that product. But, you can download the previous version for free, and it should handle most of your needs. Visit Dell’s website to get a copy of the download, and click on the link to download the freeware version of the ActiveRoles Management Shell. ActiveRoles Management Shell download link on Dell. (Image Credit: Dell)
You will need to have a Dell account to download the file. The most current version I could find was 1.60. Download either the 32 or 64 bit version. Extract the files and run the setup on your client. If necessary, reboot.
Open a PowerShell prompt. It doesn’t even have to be an elevated session, but you must be running with a credential that can read and potentially modify Active Directory. There is one major distinction between Microsoft and Quest cmdlets. The former take a web service approach, and the latter follow the traditional LDAP approach. That means that the Quest cmdlets are designed to contact domain controllers over traditional LDAP ports, which means your domain controllers are not in the cloud. On the plus side, you don’t have to install anything on the domain controllers. They don’t even need PowerShell.
Another major difference is that the Quest cmdlets are packaged as a snap-in. You have to install them on any computer you intend to run them. This also means that PowerShell won’t automatically load the snap-in when you attempt to use a Quest cmdlet. To verify the install, get a list of installed snap-ins.
Obtaining a list of snap-ins with windows PowerShell. (Image Credit: Jeff Hicks)
You need to add the snap-in to your session before you can use any commands,. You can specify the name or use a wild card.
Use Get-PSSnapin to see all loaded snap-ins.
Using Get-PSSnapin to obtain list of loaded snap-ins. (Image Credit: Jeff Hicks)
And what do we get for our troubles? Quite a bit.
Get-PSSnapin results. (Image Credit: Jeff Hicks)
These cmdlets have full help and examples. Some of them are designed for use with ActiveRoles Server, which you can ignore. You'll also note that all of their cmdlets have a noun prefix of QAD, so that you can identify them as Quest cmdlets. This helps avoid naming collisions.
Right. Let's get to work. If you look at help for Get-QADUser, then you'll most likely see some easy-to-use parameters.
Using Get-QADuser in Windows PowerShell. (Image Credit: Jeff Hicks)
The cmdlet searches the entire domain by default. We can easily limit the search scope.
Limiting the search scope with the Get-QADuser cmdlet in Windows PowerShell. (Image Credit: Jeff Hicks)
Another difference with these cmdlets compared to the Microsoft equivalent is that you get the full user object back, which makes it easier to retrieve user information.
Displaying disabled accounts with Out-Gridview. (Image Credit: Jeff Hicks)
I'm displaying the results with Out-Gridview, but as I've shown you in earlier articles you could just as easily export to a CSV file.
Before I get too far, let me point out that by default the Quest cmdlets will only return the first 1000 objects. To retrieve everything set the value of the –SizeLimit parameter to 0.
Setting the size limit of Get-QADuser to zero. (Image Credit: Jeff Hicks)
I apparently have exactly 6,200 user accounts in my domain.
Back to the task at hand, what about inactive accounts? Get-QADuser has parameters related to inactivity. You can manually specify a condition based on a number of days using -InactiveFor.
The cmdlet will check any of these condition using the value for -InactiveFor:
The account remains in the expired state for at least the number of days.
The account does not have its password changed for at least the number of days.
The account has not been used to log on for at least the number of days.
I could run an expression like this to find accounts inactive over the last 180 days.
Even better, Get-QADUser has parameters –ExpiredFor, -NotLoggedOnFor, and –PasswordNotChangedFor that let you get more granular. Specify the number of days for one of these parameters to find matching user accounts.
The Quest cmdlets can also use a policy to define what is inactive.
Determining what's inactive with Get-QADInactiveAccountPolicy. (Image Credit: Jeff Hicks)
Use the –Inactive parameter to apply this policy.
The policy is simple enough to modify to meet your requirements:
Modifying the policy. (Image Credit: Jeff Hicks)
The Quest cmdlets are very easy to use and most everything you would want to accomplish is parameterized. It is very important that you read complete help and examples. Best of all, the cmdlets are free and should work with just about any version of PowerShell or Windows.
