Update Active Directory Computer Objects with Useful Information


One of the first things I like to do with any Active Directory environment is to implement a logon script which updates all workstation Computer objects with useful information, including:

  • The name of the logged in user
  • The login time of that user’s current session
  • The model of the computer
  • The serial number of the computer
While Configuration Management tools like SCCM (and even the poorer cousins, Zenworks and Kaseya) provide this information in their own way, I’m a bit of an AD purist and figure this information is best if made accessible from the Active Directory Users and Computers MMC snap-in.

 

Delegate Permissions to update Computer objects

As this script will run as a logon script (by necessity, in order to capture the logged on user name), the script will run with the permissions of the user logging in.  By default, a standard user doesn’t have permissions to update computer objects in AD. So, we’ll need to grant them this right. This would enable a user with AD knowledge and access to the ADUC MMC snap-in to enter their own descriptions on all Computer objects, but I’m not too concerned, as the ‘custom’ description would be overwritten on next login.
To grant users permission to update the description on AD Computer Objects, complete the following:
  • Open the ADUC MMC snap-in
  • From the View menu, select the Advanced Features option
  • Locate the OU in which you store your workstations. If you have multiple OU’s per site, select the parent OU.
  • Right click the OU, select Properties and then go to the Security tab
  • On the Security tab, click Advanced
  • Click Add, and enter the security group Authenticated Users. Click OK
  • Click the Properties tab
  • Select the Apply To pull down menu, and set it to Descendant Computer Objects
  • In the permissions section, select the checkbox for Read Description and Write Description. Click OK.

Create your Logon Script

Fire up your favourite text editor, and create the VB script that you wish to use to collate this information. I use the following (edited slightly from original source here), but you can set up the script to capture whatever information you require.

On Error Resume Next
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colcomputersystem = objWMIService.ExecQuery("Select * from Win32_computersystem")
Set colBIOS = objWMIService.ExecQuery("Select * from Win32_BIOS")
For each objcomputersystem in colcomputersystem
   Getcomputersystem = objcomputersystem.Model
   GetComputerManufacturer = objcomputersystem.Manufacturer
Next

For each objBIOS in colBIOS
   GetSerialNumber = objBIOS.SerialNumber
Next

Set objSysInfo = CreateObject("ADSystemInfo")
Set objUser = GetObject("LDAP://" & objSysInfo.UserName)
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
strMessage = objUser.CN & " / Logon Time: " & now & " / " & Getcomputersystem & " / " & GetSerialNumber
objComputer.Description = strMessage
objComputer.SetInfo


Save the script file to an easily accessible temp location as something sensible, like WriteComputerDescription.vbs.

Create a Group Policy Object to apply logon scripts

Next, we’ll need a Group Policy Object to apply to the Computer objects in the OU. A few items to consider however:

  • As this script is a Logon script (not a Startup script), the setting will need to reside in the User Configuration section of the GPO. This means we’ll need to use Group Policy Loopback Processing Mode. What this means is that although the GP Setting is a user setting, the setting directs GP application to still process the user settings from that GPO, effectively allowing us to dictate User policy based on the location of the Computer in AD.
  • Good practice for Group Policy object creation is to group similar or related Group Policy settings together in the one object, and not to dump *all* Group Policy settings together in the one GPO object. What this means is that each GPO encapsulates the related settings that we’ll need to achieve its aim, while not overlapping with any other GPO.

To set up the policy, complete the following:

  • Open the Group Policy Management console (gpmc.msc)
  • Expand your domain until you have located the Group Policy Objects subtree
  • Right click, and choose ‘New’
  • Name the GPO appropriately. I use the naming convention:  – Setting Description – . 
  • In this instance, I’d user Win7 – Logon Script – Write Computer Description – User v1.0.0 (Although it applies to computers, and will have a Computer configuration setting configured, the bulk of the useful settings are in the User configuration, so I direct the attention there).
  • Right click the new GPO and choose Edit
  • Enable the Loopback Policy Processing Mode
    • Click Computer Configuration.
    • Navigate to Administrative Templates > System > Group Policy > User Group Policy loopback processing mode and Enable. When prompted, set to Merge.
  • Configure the Logon Script
    • Click User Configuration
    • Navigate to Windows Settings > Scripts
    • Double click on Logon.
    • Click on Show Files
  • An Explorer window will open. This will be the path to the Logon scripts related to this individual GPO, and will contain the GUID for that GPO, like so: \\davelab.local\SysVol\davelab.local\Policies\{FDF205F8-1C39-442F-94AA-08CB82AD0EAC}\User\Scripts\Logon
  • Paste your vbs script that you created earlier into this directory, and close the Explorer window
  • In the Logon Properties window, click Add.
  • In the Add a Script window, click Browse and you will see the vbs file you created earlier. Select this and click OK
  • Verify that the script is listed in the Logon Properties window. If so, Click OK
  • Close the Group Policy editor window.

Link the GPO to the Workstations OU

While still in the Group Policy Management Console:
  • Locate the OU in which you store your workstations. If you have multiple OU’s per site, select the parent OU.
  • Right click and choose Link an Existing GPO
  • Select the Group Policy Object that you created in the earlier steps, and click OK

For testing purposes, I’d usually limit the security scope of this applied policy to a test machine, and verifying that it works correctly. Once your testing is ok, you can then widen the security scope to Authenticated Users.

Then you can sit back and watch your AD Computer Objects become populated with useful information!

 

Further Refinements

The eagle eyed among you may have noticed that I haven’t talked about applying this to servers, as I like to manually populate the description of Server computer objects with a useful description of the role they play in the network. However, it may still be worthwhile to capture this information and append to the original description. I’ll have a play with this later.

References

Logon script that writes Displayname, computer model and serial number to description on computer object

Geoff Kendal – Automatically fill the computer description field in Active Directory

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: