We are looking at adding VMs to specific AD security groups so that we can manage all VMs using such security groups instead of managing them individually. Challenge here would be, how to maintain this up to date so checking here if anyone has already worked on such methods for any production environments? We have some automation in place for RIS build VMs where we capture the RIS files and run few scripts to add the respective computer accounts in AD groups but we couldn't think of such mechanism for machines built using vmware templates.
I could think of using manufacturer name as a differentiator between physical and virtual machine names but machine need to be online and accessible in network to know the manufacturer details and there won't be any VMware related AD attribute. Let me know if someone could think of a better differentiator or if anything is unclear.
For something similar I used an alarm.
When a VM is powered on (state change) an alarm is triggered (once) and this alarm can start a script.
In the script you can then check if the VM is already in the AD group or not.
See for details on how to start a script from an alarm.
Since the alarm is in VC it will only be triggered for VMs, so I don't think you will need to differentiate between physical and virtual machines in this case.
If you still need a differentiator, I would suggest using the MAC address of the NIC(s).
For VM NICs these MAC addresses always start with 00:50:56.
Good one!!. We have few challenges here as we would like to implement this across Virtual Center which would have other clusters having VM running other OS so how do we restrict this to be run only for XP Guest OS. Also if we deploy a VM from template, it will take some time for the sysprep to create the AD account so we should have it run after some time say 10-15 minutes or try every time its powered on but once its powered on and we have Guest OS being build i guess it will not power off and on again ..how can we make it work in such cases?
The script that will be triggered by the alarm will run on the VC, not on the VM.
So you should be able to test in the script if it concerns an XP OS or another OS.
You could use the "guestos" entry in the VMX file for example. But there are other methods.
You could also use the Notes field or use a Custom Attributes field in your template and i this way every clone will get the same entry.
In the script, on the VC, you can test if the VM, provided it's an XP guest, is already present in AD.
If not, which would mean the sysprep process has not yet created the AD account, you leave the script.
If yes, you check if the guest is already in the correct AD group and eventually add it to the group.
A reboot will not trigger the poweredon state.
So if you can not power off/on the VM anymore after it's deployed, you would need to go for another solution.
Could a Start Script (via a GPO) perhaps be an option ?
Yep, may be something like below.
1. A VM poweron will run the script and create a simple file (.txt) at central location with the name of the VM
2. Another server side scripts runs against the list in the central location and does addition to groups which are defined in the script. We may delete the file just to avoid confusion or leave it as is
This way we will not miss any VMs as the file creation is handled at VC level but need to have little bit of intelligence to handle new VM creation or existing machine power on and power off.