OU placement for VDI

[jazcuy]

I know that using standard Sysprep methods, it is possible to automatically place new machines in a specific OU, but is anyone able to do this using just the VC Template and Configuration Wizard in conjunction with VDM?

Thanks

[admin]

Hi,

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.

Thanks,

Christoph

Was this answer helpful for you? Please use the correct/helpful buttons!

[lourensprinsloo]

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.

[Evileye]

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.

Using GPMC:

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.

[TomHowarth]

Thread moved to the more appropiate VDM forum

Tom Howarth

VMware Communities User Moderator

[jonathanvm]

Problem

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.

Solution

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.

Caveat

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.

Runonce (sanitized)

cmd.exe /c dsmove -u account@domain.com 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.

-Jonathan Butz

jbutz at arrayasolutions.com

VCP/MCSE/CCNA/CCA

[admin]

This was perfect. Thanks. Just what I was looking for.,

[snantel]

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...

[jpratt_at_norwi]

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 :smileycool:

thank you!

jamie

[stoltz]

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 , 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.

[stoltz]

You can omit the last post, I have it working with the runas command.

Thanks

[admin]

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.

[stoltz]

Okay to clarify things.

The runas command wouldn't work since you can't pass through a password. So I put psexec.exe () into the system32 folder along with dsmove.exe, and from the runonce I have:

C:\windows\system32\psexec.exe
%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.

[jpratt_at_norwi]

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...

[thickclouds]

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?

http://communities.vmware.com/blogs/chuckgman

[thickclouds]

after tons of testing, I can use run once to do about anything but dsmove. anyone know why run once would not execute the dsmove or how to log dsmove/run once failure?

http://communities.vmware.com/blogs/chuckgman

[thickclouds]

use -d domainname.com to tell dsmove the domain name to use since you are logged in as a local admin.

http://communities.vmware.com/blogs/chuckgman

[thickclouds]

did you have trouble getting it to run as the runonce? dsmove just won't run for us using run once. any ideas?

http://communities.vmware.com/blogs/chuckgman

[stoltz]

Sorry for the delayed response.

Did the computer join to the domain?

Does the account your using for the dsmove have the proper permission to move computers in AD? ( I use a domain admin but i just wanted it to work first before I get specific with permissions)

Here is the exact runonce command i'm using and it seems to work perfect:

C:\windows\system32\psexec.exe
%computername% -u domain\user -p Password cmd.exe /k dsmove CN=%computername%,CN=Computers,DC=com, -newparent OU=vdi-computers,dc=com & cmd.exe /c shutdown -r -t 03

stoltz

[thickclouds]

We gave up on it and so did VMware actually. We ended up calling a batch file locally on the machine through the runonce which seemed to work. Thanks for the reponse.

http://communities.vmware.com/blogs/chuckgman