1 person found this helpful
there are many ways to do that:
1.) Maybe join them into a new subdomain? http://support.microsoft.com/kb/324949
2.) Write a VBscript, which moves the computer after creation in the right OU. example:
dsmove "CN=virtdesk1,OU=computers,DC=mydomain,DC=de" -newparent "OU=virtualdesktops,DC=mydomain,DC=de"
3.) Don't includes a domain join in the customization specification and run a RunOnce script, adding the computer to the domain and moving it into the right OU. At MSDN you will find some example code.
Was this answer helpful for you? Please use the correct/helpful buttons!
1 person found this helpful
alternatively if your AD forest and domain functional levels are on 2003, you can change the default OU for computers joining the domain (default = 'Computers') with the redircmp.exe command.
I posted this answer in the VDM forum (under another alias that I no longer use)
This method won't customize the OU the VMs are in but if your goal is to apply certain GPO's only to the virtual desktops, then this will work.
The objects remain in the Computers container.
Create a GPO at the Domain level that will apply the settings you want.
Create a WMI Filter to filter objects based on Computer name prefix
Link the WMI filter to the GPO
Here is the WMI query:
Select * From Win32_ComputerSystem Where Name LIKE 'VDM%'
This should catch any computers that start with VDM, you can change VDM to whatever your naming prefix is.
For Different Pools, use a different prefix and create corresponding GPO and WMI filters.
Thread moved to the more appropiate VDM forum
VMware Communities User Moderator
New VDI desktops are automatically provisioned and added to the domain in the default location (cn=computers). Policies required by VDI desktops typically originate in an OU that is not the default location. Neither VDM nor Virtual Center has a satisfactory method to automatically move a new computer to the correct OU.
Add dsmove.exe to c:\windows\system32 on the VDI templates.
Set the following in the Virtual Center Customization Specification used by VDM:
1: Use a runonce command and dsmove to move the computer to the desired OU and reboot.
2: Set the computer to autologon as administrator once so the runonce will occur without intervention once the vm is deployed.
This method requires that there be no group policy pre-logon message defined at the domain level. The message interrupts the runonce command and requires manual intervention to complete the provisioning of a new desktop (it waits for someone to hit 'ok'). Since cn=computers is not an OU, there is no way to override a domain level pre-logon message. By moving pre-logon policy messages to individual OUs, this problem is eliminated.
In a large organization with complex policies, it may be more practical to change the default location for new computer objects to an OU and block the logon message there.
cmd.exe /c dsmove -u firstname.lastname@example.org CN=%computername%,CN=Computers,DC=domain,DC=com -d domain.com -newparent ou=vdi,dc=domain,dc=com -p password & cmd.exe /c shutdown -r -t 00
This should work with any account that has rights to move a computer within AD. Because runonce is automatically removed, there are no scripts or credentials left behind following the execution. They exist only in Virtual Center, and access to them can be controlled through roles and permissions.
jbutz at arrayasolutions.com
This was perfect. Thanks. Just what I was looking for.,
Or you can run a task on your DC that run every 15 minutes and distribute the new added PCs to the OU you want...
In this case, you can use the regular Virtual Center customisation wizard...
SCRIPTMOVECOMPUTER.txt 4.9 K
Let's face it, the 2.1 functionality holes are all terrible, and just lead to all these "ugly" hacks.
Can anyone at VMWare at least give us an idea of when 3.0 will be GA as i heard it was in RC a short time ago and looking forward to the new features and fixes
I know this is a bit late of a reply, but i am having some problems with the dsmove command working.
I cannot execute it as the local admin of the machine it gives me "The specified domain either does not exist or could not be contacted.".
I've tried the -u email@example.com, and the domain\account with the -p at the end and specified the password and i've tried -p * to manually put in the password and it still gives me the "The specified domain either does not exist or could not be contacted.".
If i login to the machine with an account that has athority to to move computers and execute the dsmove command it works no problem, do you have any thoughts or suggestions?
Thanks in advance.
You can omit the last post, I have it working with the runas command.
Good news. Can you list what the problem and resolution was with dsmove not working. I had a similar issue in my environment and ended up using local sysprep method to resid and join to the domain (In a specific OU). I would prefer the runas method to accomplish the same thing because the sysprep method forces me to keep sensitive credentials in a text file on the template machine and newly deployed guests.
Okay to clarify things.
The runas command wouldn't work since you can't pass through a password. So I put psexec.exe (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) into the system32 folder along with dsmove.exe, and from the runonce I have:
%computername% -u domain\user -p password cmd.exe /k dsmove CN=%computername%,CN=Computers,DC=domain,DC=com -newparent ou=vdi,dc=domain,dc=com
Hope this helps.
I heard vdm 3.0 is finally GA on Wednesday 12/2.... Glad i gave up on the broken/vapor-ware 2.1 release... absolutely ridiculous... Nothing like being free beta testers for "release" code...
Very nice post. So - when using login as adminstrator automatically, it won't let me run the dsmove command as it wants me to be logged in with a domain account. any ideas?