How Can I Prompt for a Computer Name and Then Delete That Computer Account From Active Directory?

How Can I Prompt for a Computer Name and Then Delete That Computer Account From Active Directory?

  • Comments 5
  • Likes
Hey, Scripting Guy! Question

Hey, Scripting Guy! How can I write a script that prompts the user for a computer name, then goes out and deletes that computer account from Active Directory?

-- PH

SpacerHey, Scripting Guy! AnswerScript Center

Hey, PH. As a general rule, technical writers never experience writer’s block. Why not? Well, writer’s block usually comes about because you can’t figure out how to get started; once you start writing you’re usually fine. Technical writers never experience writer’s block because technical writers never have any problem getting started. Are you writing about Active Directory? No problem; just start out by saying, “Active Directory is a technology that ….” Writing about Terminal Services? Here’s an opening sentence for you: “Terminal Services is a technology that …” Writing about Group Policy? “Group Policy is a technology – “ well, you get the idea.

For better or worse, however, the Scripting Guys aren’t like other technical writers. Instead of starting every column off by saying, “System administration scripting is a technology that …,” the Scripting Guys try to thrill and excite their readers by talking about fascinating subjects like Turducken Bowls and Scripting Dogs. That’s fine, except that, after awhile (this being, by unofficial count, the 718thHey, Scripting Guy! ever written), you run out of things to talk about.

Unless, of course, you happen to drive the Scripting Car.

OK, good point: at the moment nobody actually drives the Scripting Car; the Scripting Car just sits around like a big, dumb blob. (We’ve long heard that pets resemble their owners, but we had no idea that cars resemble their owners.) Two days ago the Scripting Car was toast. Yesterday the Scripting Car was alive and well. Today – well, you can probably guess where we stand today.

“It has to be a short somewhere,” said the mechanic after the Scripting Car was towed to the shop for the second time this week. “We just can’t figure out where. Let’s just hope it’s not in the injectors, though. You don’t want it to be in the injectors.”

He’s right: we definitely don’t want it to be in the injectors.

At the rate things are going, we’re likely to have enough Scripting Car stories to keep us in business for a long time to come. But how do you transition from a story about a broken Scripting Car to a script that can locate and delete a computer account in Active Directory? As it turns out, you don’t; you just show the script and call it good:

Const ADS_SCOPE_SUBTREE = 2

strComputer = InputBox("Please enter the computer name:", "Delete Computer Account")

If strComputer = "" Then
    Wscript.Quit
End If

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"

Set objCommand.ActiveConnection = objConnection
objCommand.CommandText = "Select ADsPath From " & _
    "'LDAP://DC=fabrikam,DC=com' Where objectClass='computer'" & _
        " and Name = '" & strComputer & "'"  
objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE 
Set objRecordSet = objCommand.Execute
objRecordSet.MoveFirst

Do Until objRecordSet.EOF
    Set objComputer = GetObject(objRecordSet.Fields("ADsPath").Value)
    objComputer.DeleteObject (0)
    objRecordSet.MoveNext
Loop

Barring any more shorts (particularly one in the injectors, which we don’t want) we’ll try to explain how this script works. As PH noted, he’d like the script to prompt the user to enter the name of a computer. No problem; after defining a constant named ADS_SCOPE_SUBTREE we use this line of code to prompt the user to enter the name of a computer:

strComputer = InputBox("Please enter the computer name:", "Delete Computer Account")

As you can see, there’s nothing particularly fancy about that line of code. All we’re doing is calling the InputBox function and asking it to display an input box on the screen. This particular input box features the message Please enter the computer name: and the caption Delete Computer Account. Assuming the user types in a name and then clicks OK the typed-in name will be stored in the variable strComputer. If the user clicks Cancel strComputer will be equal to an empty string (“”); in turn, that triggers this block of code, which causes the script to terminate:

If strComputer = "" Then
    Wscript.Quit
End If

Once we know the name of the computer account to be deleted our next step is to search Active Directory and locate the account in question. As usual, we won’t discuss the ins and outs of Active Directory search scripts in any detail today; that’s what our two-part Tales from the Script series is for. However, we will take a quick peek at the SQL query used to search for this computer:

objCommand.CommandText = "Select ADsPath From " & _
    "'LDAP://DC=fabrikam,DC=com' Where objectClass='computer'" & _
        " and Name = '" & strComputer & "'"

Again, this is pretty straightforward: all we’re doing is searching the fabrikam.com domain for all items that have an objectClass equal to computer and a Name equal to the value of the variable strComputer. Because computer Names must be unique in a domain, this query lets us locate the very account that we want to delete.

Because we’re using a search script, any accounts that meet our criteria will be returned as part of a recordset; that’s true even though there can be, at most, only one such account. Because of that, we need to set up a Do Until loop that runs until we’ve looked at each and every item in the recordset. Or, as we high-tech types like to say, until the recordset’s EOF (end-of-file) property is True:

Do Until objRecordSet.EOF

So what exactly do we do inside this loop? To begin with, we take the value of the item’s ADsPath property and use it (and the GetObject method) to bind to the actual computer account in Active Directory:

Set objComputer = GetObject(objRecordSet.Fields("ADsPath").Value)

And yes, you’re right: this works because the ADsPath attribute represents the computer’s “address” within Active Directory. For example:

LDAP://CN=atl-fs-01, CN=Computers, dc=fabrikam, dc=COM

After we make the connection we then call the DeleteObject method and delete the account:

objComputer.DeleteObject (0)

Note. Why is the (0) parameter tacked on to the end of the DeleteObject method? Well, that’s a required parameter even though, at the moment at least, 0 is the only allowed value. The parameter is still required, however, because additional values might be allowed “in the future.” If you ever find yourself musing, “I wonder if the future has arrived yet,” just check to see if DeleteObject accepts any values other than 0. If it does, then the future has arrived.

One important thing to keep in mind here: the moment you call DeleteObject the computer account will be deleted. There’s no prompting on the order of “Are you sure you want to delete this account?”, although you could easily add that code in yourself if you so desire.

How could you add in that code? Well, here’s one way:

intAnswer =  Msgbox("Are you sure you want to delete this computer?", _
    vbYesNo, "Delete Computer")

If intAnswer = vbYes Then
   objComputer.DeleteObject (0)
End If

After deleting the account we then call the MoveNext method to move to the next item in the recordset. Because there won’t be a next item in the recordset that means the EOF property will be True and we’ll automatically exit the Do Until loop.

And that should do it, PH. We wish we had a snappier ending for today’s column other than, “And that should do it, PH.” Unfortunately, we’re having problems bringing things to a close lately. We seem to have no trouble with beginnings; endings are a different story.

That said, let’s just hope that this story doesn’t end with, “Bad news, Scripting Guy who writes this column: this is in the injectors. That’s something you don’t want.” No, we definitely don’t want that.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi can u make this script to work with alternate credential. I want to run this from a machine that is not part of domain and I am logged on to that machine as a admin to the local machine. I would appreciate if some one can do this for me. I tried with some others scritps a and getting error like "Set objRecordSet = objCommand.Execute"  

    I found this and tried did not work:

    strUserID="userid"

    strUserDomain = "domain"

    strPassword = "password"

    Set objConnection = CreateObject("ADODB.Connection")

    Set objCommand =   CreateObject("ADODB.Command")

    objConnection.Provider = "ADsDSOObject"

    objConnection.Properties("User ID") = strUserDomain & "\" & strUserID

    objConnection.Properties("Password") = strPassword

    objConnection.Properties("Encrypt Password") = True

    objConnection.Properties("ADSI Flag") = &H201 'ADS_SERVER_BIND Or ADS_SECURE_AUTHENTICATION

    objConnection.Open "Active Directory Provider"

  • @del

    By default the AD servers are not optioned to allow that form of authentication.  Se you domain admins to see if they will allow it to be enabled.

  • @jrv

    I have access to AD. I can run the script if I log on to the computer using my domain account and it works. I am trying to run it using my domain account in the script so I do not have to log in to the computer to do that. Hope I am clear on this.

  • @Del - As I posted.  It is a different authenticationmethod which is not enabled by default.

    When logged in you are trusted in an AD domain.  Authentication is a result of supplying a token to AD and AD validating your token.  If you are not logged into the domain you cannot do this and must supply credentials.  AD needs to be set to allow this.  Ask your AD administrator to explain how this works and if they can alter it for you - it is likely that they will not.

    You can also research  this by searching for AD authentication on MSDN or TechNet.

  • @Del - here is long article explain how this works mostly.

    technet.microsoft.com/.../cc780332(v=ws.10).aspx

    You can see that if you are not logged into the domain then you cannot gain access to its resources. easily.

    YOU must be logged in in some way and AD must allow your source to authenticate either via Kerberos (the usual way) or allow other types of login (not available by default).