netjim66
Enthusiast
Enthusiast

Pool customization using Sysprep - Add machine to specific OU

I know the quickprep adds the machine to an OU, but how do you get the customization using sysprep?

I suppose it writes an unattend.xml somewhere on the quest before sysprep.

Can you add the OU there?

just wondering how to get these machines in another OU besides "Computers"

0 Kudos
5 Replies
netjim66
Enthusiast
Enthusiast

For now, since it's a View Pool, and I know what the machine names are going to be, I'm running Active Directory Users and computers with the same account that adds them to the domain within View.

Then I'm pre-populating AD with like 50 machine names at a time.

In View, when new machines with that name are created, they are already in AD and in the right OU.

0 Kudos
MattDav
Enthusiast
Enthusiast

Are you using a script for this?  Need to put the computers in a specific group or OU in order to apply group policy. On a non-persistent pool I'll have to do as you say and either create 50 computer objects in the computer container and them to a group, or in a pool named OU.

Can't believe there is not a process for putting in the correct OU when the machine is created.

0 Kudos
Zaim33
Enthusiast
Enthusiast

I do this by running a PoSh script located in C:\Windows\Setup\scripts in the master image. The script is then called by a customisation parameter in vCenter and once run the script deletes itself.

Agreed it is a pain when you can specify the OU for a linked clone but not for a full clone.

Script below and all details in the header. The account you use to join to the domain needs creation rights over the OU and rights to add computers to the domain (if this is restricted). Only issue I have is the password is in plain text in the file but as a master image should be secured and the file is deleted this hasn't been a major problem. Save the file as VM-DomainJoin.ps1.

#Adds computer to domain and then deletes the file

#File needs to be placed in C:\Windows\Setup\scripts

#Change parameters in <>

#

#VMware Guest Customization run once parameter:

#C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -command "C:\Windows\Setup\Scripts\VM-DomainJoin.ps1"

#

#***********Ensure Set-ExecutionPolicy Unrestricted is set******************

#

############################################################################

#Set error action

$ErrorActionPreference = 'SilentlyContinue'

#Define variables

$domain = "<FQDN Domain Name>"

$OU = "<Distinguished destination OU name i.e. OU=Workstations,OU=VDI,DC=another,DC=com>"

$password = "<password>" | ConvertTo-SecureString -asPlainText -Force

$username = "<domain username>"

$credential = New-Object System.Management.Automation.PSCredential($username,$password)

#Domain join computer

Add-Computer -DomainName $domain -credential $credential -OUPath $OU

#Delete this file

Remove-Item -path "C:\Windows\Setup\scripts\VM-DomainJoin.ps1" -force

#Reboot computer

Restart-Computer

#End of script

If you find this information useful, please award points for "correct" or "helpful".
0 Kudos
michaelcprice
Enthusiast
Enthusiast

I know this thread is kind of old but I thought I would share another solution which I feel is really simple. You can use the Run Once commands in a Guest Customization Specification to a VM to a domain and place it in a non-default OU. This works great for VMs deployed through View that do not use QuickPrep for whatever reason. If using this with View you would need different customization specs for each OU location you wish to deploy to.


See the example below for specific Guest customization settings you would use to accomplish this:

  • Computer Name settings:
    • Check the "Use virtual machine name" radio button.
  • Administrator Password related settings:
    • Enter a password to be used for the VMs local administrator account.
    • Check the "Automatic Log on as the Administrator" box.
    • Set the number of times to log on automatically to at least 1 time. (See notes below)
  • Run Once settings:  (These must be done In the specific order listed here from top to bottom. Ordering of the commands in the Run Once section is critical!)
    • net.exe start workstation     (This makes sure the network is started)
    • netdom.exe join %COMPUTERNAME% /domain:<DOMAIN_NAME_FQDN_FORMAT> /ou:"<DISTINGUISHED_NAME_OF_AD_OU>" /userd:<ACCOUNT>@<DOMAIN_NAME_FQDN_FORMAT> /passwordd <ACCOUNT_PASSWORD>  
      • Example: netdom.exe join %COMPUTERNAME% /domain:my.lab /ou:"OU=VDI Desktops,DC=my,DC=lab" /userd:myaccount@my.lab /passwordd:mypassword  
    • shutdown.exe /r /t 30   (reboots the VM to finish the domain join process)
  • Workgroup or Domain settings:
    • Make sure the Workgroup radio button is checked.  (You should not be entering any domain join settings here!)
  • Operating System Option settings:
    • "Generate New SID" box should be checked.  (not really required but probably a good idea)

Additional notes:

  • If you need to set the Automatic logon count to more than 1 then you will need to use some type of scripted commands to reboot the VM each time the there is an automatic Administrator logon except for the first time because in this example the shutdown.exe command takes care of rebooting the VM the first time.
  • This method stores a user name a password in the Guest Customization specification. To reduce risk associated with this approach make sure the account being used for the domain join has only the bare minimal permissions required to join computers to the domain and only in the specific OUs you wish to use it with. Since most users don't have access to the Guest Customization specs in vCenter I consider this a reasonable risk. You can also limit vCenter users access to the Guest Customization specs if needed. For me personally I prefer this over storing the account and password in a script file on the VMs type of approach. This also allows me to change the account, password, and OU location without having to make any changes to the VM templates.
  • It is possible to reboot the VM using the netdom.exe command by adding a "/reboot" argument at the end of the line. This example does not show that because I feel it would be better to do the reboot separately so these commands can be combined with other Run Once commands if needed. If you have other Run Once commands you need to run you can insert them anywhere before the shutdown.exe command.

Regards,

Mike

0 Kudos
NoDowt
Contributor
Contributor

Having trouble getting this to work... Trying to use Michaelcprice's method, but the machine is not joining the domain.

If i add an additional runonce item, i can see that it does get run (e.g. cmd /c echo "test" > C:\temp\test.txt); however it seems the net & netdom commands are not working.

This is for a Windows 10 image if it makes any difference.

Cheers

Jason

0 Kudos