In “Use Get-ADUser to Determine Who Has Never Logged On,” I showed you how to use PowerShell to find all Active Directory (AD) users who meet some criterion—they’re locked out, they haven't logged on in a certain time period, they have first names starting with "J," and so on. In “Doubling Up Active Directory PowerShell Cmdlets,” I showed you the commands that let you do something to those folks, such as unlock their account, disable or enable the account, change an account attribute, and so on. What I haven't tackled yet is account deletion.
If you've read even a few of my previous columns about AD’s PowerShell cmdlets, you've seen that PowerShell cmdlets glue a "verb-ish" word to a particular noun to create commands such as get-aduser, and you know that the relevant noun for AD users is ADuser. You've probably also seen that PowerShell tries to restrict itself to a fairly short list of verb-ish words, and that the big four are new (which creates PowerShell objects), get (which displays PowerShell objects that meet some set of criteria), set (which lets you modify some aspect of an existing PowerShell object), and remove (which is PowerShell's verb for delete). Knowing all that, you've probably already guessed that the command to delete a user account is remove-aduser. The command is quite simple in its most basic form:
In that cmdlet, identity works as you've already seen it work in get-aduser and set-aduser: It will take a DN (cn=AprilJones,CN=users,dc=bigfirm,dc=com), a SID (S-1-5-21-941799636-306785290-3997453140-1106), an object GUID (c5959b71-61f9-4497-81a6-c147639a33b0), or a SAM account name (AprilJones). Remove-aduser is different from most AD cmdlets, however, in that it requires a confirmation. Try deleting someone, and you'll see something like this:
Performing operation "Remove" on Target "CN=AprilJones,CN=Users,DC=bigfirm,DC=com".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Press Enter, and the deed is done. But that's not particularly helpful, because many admins wouldn't use remove-aduser to delete just one user account; instead, you might use it in a one-liner, as in
That command would find all the disabled users and delete their accounts. (Please don’t run this command on your production network!) And if you plan to type that line on a domain with 1,000 disabled accounts, get ready to wear out your Enter key!
To tell remove-aduser not to require a confirmation, you could—well, what could you do? PowerShell is somewhat bipolar about this. PowerShell cmdlets tend to have some sort of Are you sure? prompt built into the “dangerous” commands, and that's a good thing. What's odd, however, is that to inform PowerShell that you know what you’re doing that that you don’t need to press Enter, you sometimes use -force, as in stop-process:
If "SomeService" is a process running under an account that isn't you, as with most services, PowerShell will ask for confirmation, as remove-aduser did. As with remove-aduser, you can tell PowerShell not to ask for that confirmation, but only with -force:
Try adding -force to the end of that remove-aduser command, however, and you'll get the error message A parameter cannot be found that matches parameter name 'force’—which, I have to say, is somewhat clearer than many PowerShell error messages. Instead, you can type the following to perform a deletion without any remonstrations:
Personally, I like this second approach better because it identifies confirm as an internal flag that, when set to $true, tells PowerShell to make a final check with you before doing something, and, when set to $false, tells PowerShell remain mum and just do what you told it to do. So always remember: If -confirm:$false doesn't stop PowerShell confirmations, -force will, and vice versa. (And like most of the "dangerous" commands, remove-aduser has the -whatif parameter, which reports on what it would have done without -whatif.)
How can you be sure that April is gone? Well, a simple
would do the trick, or you could (if you'll pardon the gruesome expression) examine the corpse. As you probably know, deleting a user account in AD doesn't actually erase the user object from AD, but instead clears most of the object's attributes and marks it as deleted, creating a tombstone object that AD keeps around for a number of days (180, by default). To see tombstones, you need a cmdlet that's a bit more powerful than get-aduser. You need get-adaccount. Its syntax is like get-aduser's, but it has an extra parameter, -includedeletedobjects (which can, fortunately, be shortened to -inc), that shows the otherwise-hidden tombstones. Search for April's remains with this:
Run that query, and you'll see that April isn’t quite gone yet, and in fact you might be able to undelete her account to some degree. But that's next month's topic!