In order to use the virtual machines in Lab Manager on a domain you have to do some customization.

For starters - the templates themselves can *NOT* be on a domain, LM Tools will not install on a machine already joined to a domain.

If you already have a custom ISO created in Lab Manager, delete it. On the VMware Lab Manager server edit the sysprep.inf file here: C:\Program Files\VMware\VMware Lab Manager Server\Tools\LMTools\Sysprep\Win2k3

Remove the line that says “ComputerName” - this is added automatically by LM Tools when the machine is deployed. If you do not remove this line you may end up with 2 seperate ComputerName fields and only the first one will be used which may cause the machine to be named something unexpected(There is a VMware KB regarding this).

Under “Identification” remove the line that mentions workgroup and add 3 new lines:

JoinDomain=domainname
DomainAdmin=domain\user
DomainAdminPassword=password

Save the file and then recreate the custom LM Tools ISO in Lab Manager. Once that is done boot up the template and if LM Tools were already installed, un-install them, reboot and then re-install the LM Tools so that the updated sysprep.inf file will be used.

Note: This method is if you want all machines to use the same sysprep.inf file, if you only want certain (or a single) template to join to a domain you can disregard editing the sysprep.inf on the Lab Manager server, as well as deleting and re-creating the LM Tools ISO and instead edit the sysprep.inf directly on the template instead. Installing LM Tools on the template is what copies the sysprep files from the Custom LM Tools ISO which is copied from the Lab Manager server at the time the LM Tools ISO is created.

Finally!

Grab it here

I recently ran into a problem where a user accidently reverted to a snapshot within Lab Manager, they didn’t realize this at first and by the time they did I had upgrade Lab Manager to the latest version (2.5.3). This ended up being a bit of a pain so I thought I would document the steps I took.

My first thought was I could fire up the snapshot version of the Lab Manager server, consolidate the disk on the VM in question and then import it into the current environment.

I knew the directory ID of the machine after it was reverted to snapshot (1133). However on the SAN snapshot this directory ID did not exist, I tried booting up the snapshot copy of the Lab Manager server but since it couldn’t contact the managed ESX hosts. Since it couldn’t connect to the hosts I couldn’t even view the properties of the machine to see what the directory ID was at that point.

So at this point all I knew was the machine name, but since Lab Manager stores all VMs but a numbered folder I had no idea where it was. I ran a search in the SAN snapshot looking in all .vmx files for the name of the machine, the command I used was:

find <path to SAN snapshot> -name *.vmx -exec grep -q “<machine name>” ‘{}’ \; -print

That returned 2 directories, just to test it I ran that command in the current SAN volume used by Lab Manager and it returned 3 directories. So now I knew the directory but wasn’t exactly sure how to get it into the existing Lab Manager configuration. Since the user didn’t want the current version of the VM, I went into that directory (1133) and made a backup of all files in it and then removed all of them. I copied everything from the directory I found on the SAN snapshot into the 1133 directory, and renamed the .vmx file to match the one that was in the before (for the 1133 VM). After I did that I was able to deploy the machine from within Lab Manager like normal.

If you use VMware Lab Manager and Virtual Center you have probably noticed a lot of orphaned virtual machines within your VI Client.

VMware has a tool you can install on your Lab Manager server to automatically clean up these orphans.

• Download the tool from here (you will need to rename the extension to .msi) and install it on the Lab Manager server.
• Open a command prompt and change your current working path to C:\Program Files\VMware\VMware Lab Manager Server\Tools\RemoveOrphanedVMs
• Run the following: removeorphanedvms -h <virtualcenterserver>:<port 443 is the default> -u <username> -p <password> -t -v
• Note the with the -t option it won’t actually remove any machines, it will print out to the screen the names of the machines it thought were orphans and the total amount it found.
• Setup a scheduled task to have this run automatically in your environment if preferred.

This seems to be a lesser known option, but if you want to pass through your domain credentials to the Virtual Center server add the following at the end of the VI Client shortcut.

-passthroughAuth -s <vcservername>

Having a lot of space on my home file server and using XBMC, I prefer to keep all my DVD’s as ISO’s on my network so I can stream them.  Most of the time after I rip them I’m left with the VIDEO_TS directory, on Windows I would use something like DVD Shrink to make them into an ISO so I was looking for something similar on my Mac.  After looking around I found I didn’t need any software, I can do it natively.  Open up a terminal and navigate to the folder level just below the VIDEO_TS folder.

hdiutil makehybrid -udf -udf-volume-name <Movie Name> -o <Movie Name>.iso <folder name>

I guess this is a little old but I had been using Jungle Disk as a front end for Amazon S3 but didn’t want to fork out the cash after the trial period for a Mac and Windows version.  I already use Transmit daily for FTP/SFTP (I personally prefer Transmit over Cyber Duck).  In the latest version they have added support for connecting to S3, works perfect for me as I wasn’t looking for any type of automated backup to S3.  I only use S3 to upload some documents to occasionally that I want off site.  I did like that Jungle Disk could mount my S3 bucket as a drive, I’ve also noticed that Jungle Disk seemed to handle the files I uploaded in a unique way, there seems to be 2 copies of every file I uploaded with a .dir and a .attr extension to them.

Recently I have setup a NLB IIS site with 2 VM’s in a DRS/HA cluster.  Because of this using unicast mode was not an option (we need to be able to vMotion the virtual machines).  Multicast is also the way VMware recommends setting it up.  From VMware’s site:

Note: VMware recommends configuring the cluster to use NLB multicast mode even though NLB unicast mode should function correctly if you complete these steps. This recommendation is based on the possibility that the settings described in these steps might affect VMotion operations on virtual machines. Also, unicast mode forces the physical switches on the LAN to broadcast all NLB cluster traffic to every machine on the LAN. If you plan to use NLB unicast mode, you must run all members of the NLB cluster on the same virtual switch.

The other problem with unicast mode is you have to disable RARP for either the virtual switch or the port group:

The other thing you need to do if using multicast mode, is add a static ARP entry in your switch for the MAC address of the NLB cluster, which is found under the cluster properties in NLB manager.  For a Cisco switch, from config mode:

arp <ip of nlb cluster> <mac of nlb cluster> arpa

I’ve been playing around a little recently with Thinstall (which was recently acquired by VMware).  Basically it will take an application and turn it into a self-contained single EXE that doesn’t require an install.

It’s extremely easy to use, I setup a fresh install of XP in VMware Workstation, created a snapshot then you run the setup capture program.  It will do a pre-install scan as shown below.

At this point (below) the scan is complete, and you leave this window up and install your application.

I am installing a trial version of SecureCRT which I use quite a bit for SSH connections.

After you run the post-install scan if should find the new EXE, click Continue.  It It will save the output to the Thinstall\Captures directory, run the build.bat file located in there to build the app.

Output after running the build.bat file:

As you can see below, after I ran build.bat I uninstalled SecureCRT  The single EXE is in the Thinstall\Captures\<software name>\bin folder

Execute the EXE to run the program on whatever machine you like with no install.

If you make a lot of these, I’ve found it is nice setting a snapshot right after XP is installed, then I revert back after each app I create.