What are we trying to do?

Many admins who like to update our Active Directory computer objects with a description field so that we know exactly what our servers or workstations are used for. If you don’t already do this, I highly recommend it.

What we want to do is get this information into our vCenter guests though because that is where a significant amount of our administration happens. Once the object is created we don’t go back to Active Directory Users and Computers (ADUC) as much. This is where we can use our Annotations field in vCenter. As you can see, it starts off empty:

How will we do it?

Luckily the content that we are looking for is easily accessible from the properties of the guest objects in both AD and vCenter. We want to go through our vCenter to find VMs, then query Active Directory for the object. From there we query the AD object for a Description field and then feed that content back to the VM guest into the Notes area as the Description field there.

Let’s get to the script!

SPECIAL THANK YOU: Thanks to Stevo (see comments section) for adding to the script to fix up issues where I wasn’t clearing the variable which could cause some problems.

Our script is pretty simple, but has a few prerequisites needed in order to run. For our environment, we need:

AD CmdLets – These are installed with the Remote Server Administration Tools (RSAT)

Once we meet those needs, create a .PS1 file using the following code:

# Import the Active Directory module for Get-ADComputer CmdLet

Import-Module ActiveDirectory

# Connect to vCenter

Connect-VIServer YOURVCENTERSERVERHERE

# Pull your VMs into an array

$Guests = Get-VM

# Loop through the array to read the AD Description field to set the Annotation in vCenter

ForEach ($Guest in $Guests) {

# Clear the variable just in case there is no match. It may keep the previous value.
Clear-Variable Description
Clear-Variable ADComputer

$ADComputer = Get-ADComputer “$Guest” -Properties Description

$Description = $ADComputer.Description

Set-VM -VM $Guest -Notes $Description -Confirm:$false

}

A quick note about this script is that it requires that your VM object name is the same as the computer name in Active Directory. Secondly, we are doing no error handling in the script, but if the machine isn’t found in AD it just errors out and moves to the next object.

Once we run the script, you can check your vCenter object on the Summary tab and as if by magic, there it is:

So now that we have the script, we should take the next step and configure this process to run regularly. I’m all about automation wherever possible, and this is a perfect candidate for a batch process.

Running PowerCLI as a Scheduled Task

Because PowerCLI requires loading PowerShell with some environment wrapped around it we can’t just load the modules using Import-Module like we can with the RSAT extensions.

So now you will have a nightly load of your Active Directory computer object content into your vCenter. You can adjust the machines that are being queried in the vCenter environment by adding some parameters to your Get-VM query. It’s just that easy 🙂

Thanks to Phoummala for the inspiration, and to Magnus (@magander3) for the great post on Windows Scheduled Tasks using PowerCLI. I hope that you all find this helpful!

Comments 13

Very interesting article. I went ahead with the intention of doing this at work, unfortunately we cannot install AD Web Services on any of our DC’s due to security concerns. Is there a way around this with some inventive scripting? 🙂

You will only need to be running the PowerCLI and the RSAT (Remote Server Administration Tools) from a member server or workstation to run this. Luckily the AD DC doesn’t need to perform the task so you can keep it more lean without batches and tasks there.

That will be a limitation based on running the 2003 forest. I should have added that these are CmdLets that run against 2008/2008R2/2012 but I didn’t test against a 2003 domain. Thanks for the heads up on this issue!

I just got back around to testing this script again in our environment. Unfortunately if the script cannot find a server matching the name of the VM it just seems to assign a description to it by the next nearest match. Is there any way to make the script bypass any VM that it doesn’t find a match for?

Ultimately I intend to run this against our vCenter server with over 2000 VM’s across multiple domains……should be interesting!

Hi Eric, thanks again for you help with this. Unfortunately I still get the same issue where VM’s with no hit in AD get a description from another server. I tried to use “clear-variable Description” as an alternative way to clear the variable, but I get the same result. Any ideas? 🙂