I’m in the process of implementing VMWare vSphere 4.0 at work, with an add-on for VMWare View.
I had been working with ESXi for a while, so the switch to ESX 4 wasn’t too hard. On the View side, the learning curve was quite easy as well. There’s little that needs to be done in VDI Manager, and the rest is managed just like it would be managed on a physical machine deployed.
For those techies reading this that haven’t dealt with sysprep yet, it’s a Microsoft utility, which you can install, and it ends up residing in C:\Windows\System32\deploy.cab , unzipping this cab will reveal a set of files required to sysprep a machine.
Essentially, sysprep is used when mass deploying desktops on the same network, this could be problematic, because each computer has a SID which is a long number that identifies the computer on the network. By imaging a hard drive without sysprep at all, there will be conflicts, especially if this machine is part of a domain. Part of sysprep’s job is to strip out these SIDs and regenerate them when the machine is re-imaged. Other things sysprep can do is unattended installations, by automating entering the Windows license key, joining to the domain (which is the main point of this article), setting time zones, IPs, etc … (If there is any interest in speaking in more detail about sysprep, post it in the comments, and I can write up an article dedicated to that.)
For those who ARE very familiar with sysprep, you would know that it’s not the most reliable tool to join the machine to the domain when a workstation is booted up with the mini-setup.
Let’s skip ahead and get into VMWare View world. For VDI Manager to work correctly and create desktop pools, the process of creating machines and provisioning them for users has to be flawless, otherwise, the purpose of VDI manager is in vain. The fact that sysprep wasn’t working, meant that the machines weren’t joined to the domain. One failing step is enough to fail everything.
So I decided to create a solution that will allow me to do so much more than sysprep because it creates a framework of setting up a machine through a script that can be expanded as needed. All this while keeping the number of my templates to a minimum. In my case, for a basic user template, a total of ONE!
Keep in mind, in my environment, I have 3 domains, (forest root, and 2 child domains), Machines that are in the VDI Manager desktop pools have to go to their corresponding locations in Active Directory, and even more broadly, to the correct domain.
I decided to leverage the information in the customization wizard in vCenter to provide the information needed for the script to know what domain to add the machine to, and what OU to place it in.
The customization specification manager looks something like this:
In the settings one of these templates, 2 key screens that need to be setup correctly:
This first screen will tell the virtual machine to call itself by the same name as the VDI pool naming scheme is setup as. So if the VDI pool is setup to name the machine as labmachine- with an increasing sequence, my machines will start to automatically pop up with the names: labmachine-1 , labmachine-2, labmachine-3 , for as many machines that I allow in the pool.
The second screen is very simple, and often overlooked:
The second part in this screen is the one that doesn’t work. The part I want to direct your attention to is the “Workgroup” field. In this screenshot, the workgroup is set to “WORKGROUP” for our purposes, I’m changing this workgroup to the NetBios name of the 3 domains I have. I know this will not join the machines to the domain, but this will be leveraged by the script that will get that name and perform the appropriate actions.
Now that this environment is ready. I create a script with Kixtart (which very much like VB, only more geared towards login scripts).
What this script does is run on the first login after the Virtual Machine has been deployed by VDI Manager and will do the following:
- It will check to see if the machine name starts with a prefix acceptable, in my case, it was either DO for the district office, or a 3 digit number for any of the schools. This means that any of the provisioned VMs have to match this naming convention or an error will be thrown upon login.
- If the machine starts with “do”, then it’s a valid workstation name, next, the script will check for the WORKGROUP that we specified in the customization specification manager, by doing a WMI call to root/cimv2 database, and get the computer workgroup name. This workgroup returned, will correspond to one of the 3 domains. Anything else will fail.
- In the case of DO, not much is required, all machines are dumped into one OU. In the case of the schools, it’s more complicated: in my case, computers sit in different OUs, so in the case of a computer name that starts with a number (corresponding to a school), a database (that I created) query is made that will get me the corresponding OU for the school in question.
- Now that all the information is gathered, the script will continue on to run the Netdom command to join the machine to the domain.
- After this is done, the script will raise a flag to create a file to let the system know that it’s been already setup.
This script is very flexible because it’s being run independently from sysprep. I trigger it from the Programs/All Users/startup.bat, which calls another batch file:
1: @echo off
3: IF EXIST "c:\windows\system32\ready.dat" GOTO DELETEWSSETUP
4: IF EXIST "c:\windows\system32\wssetup.exe" GOTO SETUP
5: GOTO END
8: DEL C:\Windows\system32\wssetup.exe
9: GOTO EXIT
13: GOTO EXIT
16: GOTO EXIT
This script will trigger the main vbscript which is represented as wssetup.exe. I encoded it in an exe, to hide any sensitive information in the script. i.e: database and domain passwords.
The rest of it just monitors the environment to make sure that everything has been ran. Once it has, and it finds the flag specified by the original script. It deletes that original script leaving no trace behind it. At this point the machine is ready to go.
This setup is very flexible, because it allows the adding of any number of functions to run at the setup of the machines prior to the users even touching them. Think, install applications, anti-virus software, customization, etc…