Enterprise Admins.org

Last week I had the opportunity to present a PowerCLI self paced lab along with Jake Robinson and Ryan Birk. We presented this same lab a few months ago, but this event at the Greater Cincinnati VMware Users Group (GCVMUG) event added a slight twist. Our previous lab provided consisted of a vApp containing a vCenter and two ESXi hosts per student. Each student would then login to their vCenter using RDP. The twist in the GCVMUG event was due to the zero clients provided supported — they supported VMware View PCoIP connections only and didn’t provide an RDP option.

To work around this twist, we built a VMware View 4.6 environment inside of a vCloud Director environment at Bluelock. We went with View 4.6 because the zero clients were specifically certified with that version — the client would have likely worked with View 5.0, but we wanted to guarantee the lab would work, so we stuck with certified versions. This was an interesting twist and I learned a lot from it. Over the next few blog posts I plan to share some of the lessons learned.

The first additional requirement of this new twist was building Active Directory. VMware View leverages Active Directory authentication and authorization, so it was required to get this lab off the ground. I built a Windows 2008 R2 server and promoted it to a domain controller for the VIEWLAB.LOCAL domain. I then manually created an organizational unit for the View Lab users. I wanted to create unique user accounts for each lab station. Since we were going to have twenty stations I didn’t want to do this manually. The following code was used to create Active Directory users in the viewlab.local domain:

[cc lang=”powershell”]
$baseOU=”OU=View Lab,DC=viewlab,DC=local”

for ($i = 0; $i -le 25; $i++) {
$user = “Student”+$(“{0:D2}” -f $i)

Write-Host “Creating User for $user”
$usersOU = [ADSI] “LDAP://$baseOU”
$newUser = $usersOU.Create(“user”,”CN=$user”)
$newUser.put(“sAMAccountName”,$user)
$newUser.put(“givenName”,$user)
$newUser.put(“sn”,$user)
$newUser.put(“userPrincipalName”,”$user@viewlab.local)
$newUser.SetInfo()

$newUser.psbase.invoke(“SetPassword”,$user)
$newUser.psbase.CommitChanges()
}
[/cc]

Each account is created in a disabled state. I could have scripted changed the userAccountControl attribute to enable the account, but I simply used the Active Directory Users and Computers interface to multi-select the users in this organizational unit and then bulk enabled them.

I have a couple other ideas for posts on this project…I hope to have them posted in the next few weeks.

Todays update includes two new sections to the general reporting section of the report. These sections are not configuration issues/problems, just additional information about your environment.

# Version 5.47- bwuch: Added memory per cluster check provided by Ed
# Version 5.46- bwuch: Added vRAM check using @LucD function

5.46 – Added @LucD’s function Get-vRAMInfo from http://www.lucd.info/2011/07/13/query-vram/. This function checks vRAM allocations against vSphere 5 licensing allocations. This check includes version all hosts — even those not running version 5.0. It is important to note the new licensing does not take effect until/unless you upgrade. This check is included for planning purposes.
5.47 – Added code provided by a reader named Ed in the comments for the vCheck 5.40 post. It shows the amount of allocated RAM per MB of physical RAM in a cluster. His comments are available here.

You can download the updated version here: vcheck5.47.ps1

When composing a View Composer desktop there are a handful of tasks that need completed. I created a script to help me keep this quick and consistent:

[cc lang=”dos”]
REM Cleanup temp/log files
del /s %temp%\*.* /q
del “C:\Documents and Settings\All Users\Application Data\VMware\VDM\*.*” /q

REM Blank out the bginfo.bmp image while leaving permissions in tact
echo > C:\WINDOWS\bginfo.bmp

REM Delete the McAfee GUID…a new one will be issued at boot up
reg delete “HKLM\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent” /v AgentGUID /f

REM Release the IP address
ipconfig /release

REM Shutdown the workstation
shutdown -s -t 5
[/cc]

Please leave a comment if there are any other ideas or additions you can think of!

I’ve had an ongoing love/hate relationship with security for years. Today it was heavy on the hate. I rarely have a need to copy/paste between my desktop and a VM console. I normally use some other method to connect to a VM (ssh, Remote Desktop, etc) but today I was testing some Powershell code in an isolated lab environment. The only way to see what is going on is through the console, as there is no IP connectivity between me and the lab. I wanted to write code in the script editor on my desktop and paste it into the VM console, and that’s where I started to run into problems:

Clipboard Copy and Paste does not work in vSphere Client 4.1 and later http://kb.vmware.com/kb/1026437

The solution listed in the code works, but modifying those settings inside the GUI requires the VM to be powered off. Who wants to do that? Not me.

Instead I re-used some previously written PowerCLI code and a stun/unstun operation (i.e. power on/off, suspend/resume, create/delete snapshot/storage VMotion) to achieve the same thing.

[cc lang=”Powershell”]
#Clipboard Copy and Paste does not work in vSphere Client 4.1 and later
#http://kb.vmware.com/kb/1026437

$copy = New-Object VMware.Vim.optionvalue
$copy.Key=”isolation.tools.copy.disable”
$copy.Value=”FALSE”

$paste = New-Object VMware.Vim.optionvalue
$paste.Key=”isolation.tools.paste.disable”
$paste.Value=”FALSE”

#Create a Machine Config Spec using the three option values specified above
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.extraconfig += $copy
$vmConfigSpec.extraconfig += $paste

#Get a VM View collection of all the VMs that need to have these options
$vms = get-view -viewtype virtualmachine |where {$_.name -eq “lab-dc01”}
foreach($vm in $vms){
$vm.ReconfigVM($vmConfigSpec)
}
[/cc]

This code creates a ReconfigVM specification that includes the values required for both copy and paste operations into the vSphere client. It then applies it to a VM named lab-dc01. (If you wanted, you could change the -eq (equals) to -like or -match to get more than just one VM.)

After running the code you just need to complete a stun/un-stun operation (in my case, I did a storage VMotion as I needed to move the VM to a different datastore anyway) and now we are in business.

Oh, and to keep the security people happy, I should mention that you need to change the FALSE values to TRUE and run the script again when you are complete. We wouldn’t want to allow future copy/paste operations now, would we?