PROBLEM: Determining a computer's name can be difficult if you have to rely on user input.
SOLUTION: Add a new property to the built-in Active Directory User object to store the last computer the user logged on to.
REQUIREMENTS:
1. Windows 2003 domain (native, or mixed Windows 2000 mode)
2. Windows XP clients
3. OIDgen.vbs
4. MMC Active Directory Schema snap-in
5. ADSIEdit.msc
6. Text editor (I recommend Notepad++ because it performs keyword highlighting for Visual Basic—
notepad-plus.sourceforge.net/uk/site.htm)
7. Logon scripts UpdateITUserInfo.vbs and DisplayITUserInfo.vbs
DIFFICULTY: 4 out of 5
SOLUTION STEPS:
1. Add a property (e.g., contosocom-LastComputer) to the built-in User object in Active Directory to store the last computer the user logged on to.
2. Add a logon script that updates the property every time the user logs on.
3. Grant all users permission to update the property.
4. Add a context menu to the User object that runs a script to retrieve and display the property.
During all my years of IT support, I can't tell you how many times I've asked a user, "What's your computer name?" only to be greeted with dumbfounded silence. And obtaining the answer to this question can be like pulling teeth. Do you tell the user to right-click My Computer, select Properties, then click the Computer Name tab? Not everyone keeps the My Computer icon on the desktop—and I've talked to many users who don't know what "right-click" means. What about typing ECHO %COMPUTERNAME% at a command prompt? This approach often isn't worth the effort—just getting a user to type cmd in the Run box can be frustrating.
Knowing a user's computer name is important for checking event logs, copying files to the C$ share, or examining the registry. And in a large organization, the faster you can obtain this information—without requiring user input—the better. I figured Active Directory (AD) would be the perfect place to store such information: You could obtain a computer name anytime without having to ask the user.
Of course, extending AD with custom attributes isn't high on any administrator's list of things to do, because you can't delete any class or attribute that you create. However, you can use the Microsoft Management Console (MMC) Active Directory Schema snap-in to disable classes and attributes. Once you disable a class or attribute, it's like it never existed.
In this article I explain how to create custom AD attributes that will let you find useful information. You'll be able to search AD for computer names and return the name of the user who last logged on. In addition, you'll be able to right-click a username in the MMC Active Directory Users and Computers snap-in and open a Computer Management snap-in for the computer the user last logged on to.
Generating the Base OID
Before you can create custom attributes or classes, you need your own Object Identifier (OID). An OID is the unique identifier that will be the base ID of all your attributes and classes. The reason you need your own OID is to make sure no conflicts occur when software packages try to extend the schema. For example, Microsoft Exchange adds numerous classes and objects to AD's schema, each with their own OIDs. If you try to use an OID that Exchange uses, you'll run into problems.