Sc@-tt3r-ed Thoughts

VMWare View 4, though great when it’s working, is a real pain when it’s not working or something is broken. I am constantly learning new things with it, and sometimes have to take riskier steps than others, especially that VMware support is less than useful most of the times.

Today’s issue is related to creating a pool of machines, where one of the machine exists in vCenter, and in the Composer DB, but for some reason, it does not get listed within the pool. At this point, the pool trying to create that VMs conflicts with the actual VM that exists in vCenter, as well as the database entries that exist in the ComposerDB.

Disclaimer: the following steps involve messing with the VMWare Composer database. I take no responsibility if you end up messing your Composer DB. BACKUP, and proceed at your own risk!

Now that the disclaimer is out of the way. Let’s look at the steps to bring your pool back to life.

1. Delete the VM from the datastore, or from within vCenter, “Delete from Disk”
2. Go to the Active Directory OU where your pool workstations exist, and delete the computer object from there
3. Open up the Composer DB database with SQL Management Studio, and you need to delete some entries related to that VM:
   - SVI_VM_NAME where NAME is the deployed VM name
   - SVI_VM_COMPUTER_NAME where NAME is the deployed VM name
   - SVI_SIM_CLONE where VM_NAME is the deployed VM name.
   Before you perform this last query, there are 3 other rows to delete, as they have constraints on them:
   - SVI_SC_BASE_DISK_KEYS where PARENT_ID is the ID from SVI_SIM_CLONE
   - SVI_TASK_STATE where SIM_CLONE_ID is the ID from SVI_SIM_CLONE
   - SVI_SC_PDISK_INFO where PARENT_ID is the ID from SVI_SIM_CLONE

After you perform the above steps, check out your provisioning, or re-enable it if it had been disabled due to the error, and things should continue along without a problem.

Today, I was working on creating a script that updates some of our Student Information System core files on some workstations, and since my whole environment is based on VMWare View, I had to find a way to get the constantly changing VM numbers to be reported to the script which is supposed to update these files.

My method was to write a PowerShell script using the vSphere PowerCLI tools to get all my VMs and format them to get the total number of powered on VMs in a specific resource pool, as well as which workstations are actually available.

(Since I’m using VMWare View in a non-peristent pool, and having the VMs destroyed after the first log off, it’s hard to keep track what is on, and off, and the sequence of the workstation names is not necessarily always in order. )

Well, the script was simple:

   1:  Add-PSSnapin VMware.VimAutomation.Core

   2:  Connect-VIServer -Server do-vsphere

   3:  Get-ResourcePool "Aeries View Devel" | Get-VM | grep -c -i "AeriesCS-SB-*" \

   4:  | Out-File "\\do-tech\vmlogs$\AeriesVMCount.txt"

   5:  $VMArray = Get-ResourcePool "Aeries View Devel" | Get-VM | grep -i "AeriesCS-SB*" |sort

   6:  

   7:  foreach ($VM in $VMArray)

   8:  {

   9:      $VM = $VM.substring(0, 15)

  10:      $VM = $VM.substring($VM.Length - 3, 3)

  11:      $VM | Out-File -append "\\do-tech\vmlogs$\AeriesVMCount.txt"

  12:  }

In opening the results of this file in a KIXtart script, the results were very sporadic, having weird characters, and never returned the expected data. By the way, The ‘Out-File’ in its current form above seems to have the same output effect as a regular DOS redirect command, within the Powershell environment: i.e: $VM > “\\do-tech\vmlogs$\AeriesVMCount.txt”

Since there is no point in listing all the different things I have done, I will tell you exactly what the problem is in this scenario:

Out-File apparently does not, by default output text in ASCII encoding, and therefore, the resulting text is usually un-interpretable by other scripts. In order to fix this, a small modification to the Out-File command would be required, so line 11 would look like this:

$VM | Out-File - append "\\do-tech\vmlogs$\AeriesVMCount.txt" -encoding ASCII

Adding this small addition to the Out-File resolved the problem of incorrect encoding. I spent about 3 hours trying to figure out why my redirection weren’t working until I found the solution. So hopefully this will help someone who is a PowerShell novice like me, who may face the same problem.

I’m in the process of trying to get rid of any thick clients that I currently work on to convert solely to Virtual Machines, and clear out my desk space.
Well, I thought the best way to do this was to move my Precision 690 to the lab, install ESXi on it, and have a my VM on there.

As I tried to add the VM that resides on this ESXi server (which is not part of vCenter), I could not add it as an individual desktop.  I then remembered that I needed to have the View agent installed for this to work. After installing the View Agent, I was hopeful, but alas, the VM still didn’t show up. On Step 3 of adding the machine, it would supposedly give a list of available VMs to add and a find option, but nothing could be found. .. continue reading ..

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

Well, since I’ve just spent the past 6 hours trying to figure out how the heck to get USB Redirection to work on HP T5545 , I thought I would write up some instructions on how to set it up, and all the gotchas to avoid.

For the record, I only set this device up because I got stuck with 50 of them for one of my schools, and for anyone who doesn’t want headaches, I would recommend they go with XPe (no, not WinCE), I’m pretty sure, the additional premium you will pay for the device itself will be saved in time trying to configure/troubleshoot, and update it. This recommendation is based on my usage with VMWare View (formerly VDI), and where USB Redirection is absolutely needed. For any other purposes (ie: terminal services, ICA, RDP, etc..) , I cannot vouch for it, but I would suspect it would work just fine if you’re on a lower budget. .. continue reading ..

So, here I am sitting at my office trying to get VMWare View to work on an HP T5540 thin client. Had no idea where to get the client for. the 11Mb file that you get from VMWare is entirely too big to be intalled on that client. This is a Win CE operating system, which is so horrible to deal with anyway.

Google searches failed me left and right, everywhere I looked. People said that the T5540 can only be used in a remote desktop environment, which, of course, will lose out on the capability of VDI, dynamic provisioning, multiple desktop availability, Multimedia, and USB. Essentially, all the advantages of VDI would’ve gone down the drain. so that was not an option for me.

Some mentioned JRE version for Win CE, on which the VDI client will run. I had 2 problems with this one:

1. I couldn’t easily find a free JRE client for WinCE
2. For the life of me, I could not figure out how to get VDI Manager to use JRE.

So, I went ahead with my research, until I stumbled upon something called the VDI Broker Add-On for Microsoft Windows CE.  That can be found here: http://bit.ly/16M38p

If you look closely at the description of this download, however, you will find that it says this:

"This is an Altiris package that contains the VDM Broker Agent for the supported thin client models running a supported operating system.”

Hmm.. I thought I’d try it anyway. Downloading the file wasn’t a problem. Running the file, however, was. It just plain wouldn’t run from the T5540.

So poking around some more, I finally got the solution. Unzip the EXE that is supposedly designed for Altiris, and you will find a little file (145Kb)  called VDMClient.cab, which will do the trick. Now, copy this to your T5540, and run it, and you shall have your VDI client available.

This took me about an hour of research to figure out, since there is absolutely no documentation I could find about it anywhere!. 

Hopefully this will help someone that may be having the same problem.