vElemental

Who ever said VDI Admins can’t script?  Well at this point I can understand why they haven’t even tried.  Recently we (EMC vSpecialist rockstars @andreleibovici @chrishorn), and others have been focused on creating a next-gen lab environment and View has been the focal point for what I would term demand management.  The core concept that we are working to deliver is essentially “desktop as a service” for lab environments.  DaaS in our case is an extreme version where we are second by second removing and adding View desktops into already existing pools linked in a way to an active lab vApp.  With this is mind our requirements are pushing the limits of VMware View’s capabilities out of the shoot, so we really had to work overtime on developing methods that allow for the automation of a product with little to no operational hooks.

In previous posts that I have made around VMware View you can see some of this work progressing.  The good news is that we have accomplished exactly what we set out for.  The bad news is that we have had to go outside the normal acceptable methods that View provides in order to do so.  With this as always, what we post if meant for educational purposes and not meant for production environments as it may affect your supportability. 

Powershell and Adobe AMF3

Automating VMware View Pool Membership

Permanent Link to Installing VMware View Agent remotely using PowerCLI

How to Access Windows 2K8 Server via PCoIP with VMware View (@andreleibovici)

Please read on!

 

The most recent challenge for us has been around how to get proper information for capacity reporting out of View.  For example, what we wanted was to be able to see the current desktops in use and available in a certain pool along with the status of agents.  Unfortunately, using the current GA VMware View cmdlets there was only information about desktops that hadn’t been added to pools yet.  The idea that I sort of got what I wanted provided me some hope so I decided to start digging..

If you are looking for what is currently supported, see Alan Renouf’s site for some previous information that shows the GA cmdlets for View.  That native cmdlets have good information, but unfortunately are limited due to lack of remote capabilities (without remoting turned on), don’t receive piped objects in all cases, and are lacking the information we needed.

http://www.virtu-al.net/2010/09/14/vmware-view-4-5-more-powershell-cmdlets/

 

What I found was very interesting.  There are currently three methods that I know of to programatically interface with View.  The first being the public supported method of VMware View cmdlets included with a connection server install.  The second being an undocumented ability to leverage the message bus locally per VMware View connection server in order to inject commands.  And the third being my most favorite undocumented option being leveraging Adobe AMF (action message format) messaging.  I continued on this third method and developed a very cool scalable method for anyone to leverage AMF remoting with Powershell.

The AMF method is an awesome way to quickly profile a client GUI and transpose those calls into CLI.  See (Powershell and Adobe AMF3).  For scripts that I will be linking to at the bottom of this post I used the following method, which you don’t really need to know but cool enough to describe..

• Open Wireshark (configured to sniff SSL)
• Open VMware View Client GUI
• Do an operation
• Grab Hex from Wireshark of HTTP POST (AMF call)
• Deserialize the Hex into a powershell AMF psobject packet (Java Bean, Method, Parameters)
• Export this object as a xml file to be later used (check psobject.xml/ directory)
• Duplicate a generic function in my advanced Powershell functions
• Test and ensure parameters met what was built as expected from template
• Run cmdlet

 

Anyways, a very cool project that required about 99% of the time in creating an AMF serialization/deserialization process, and the other 1% enjoying the work and creating these “advanced” cmdlets.  Consider what is being displayed here as a v1 and a completely read-only version.  Who knows, you may see some of this work repeated for other cool things that are Flex/Flash based! And as always hopefully this becomes irrelevant sometimes soon =)

Here are some of the basic specs of what is currently available under the Avanced VMware View Powershell Cmdlets.

• Access View Connection servers remotely (without Powershell remoting)
• Built using Adobe AMF remoting
• All information displayed in View GUI is available
• PowerCLI style connection persistence (Connect-ViewConnServer)
• Currently Read-only access
• Powershell Advanced Functions to create cmdlets (@alanrenouf will be pleased) =)
• Plenty of stuff that isn’t available under the standard VMware View cmdlets

 

Without further ado, here are the scripts!  Most likely the best use case at this point is around generating reports of configuration and reporting on status for services and desktops.  Anything is possible since we are now hooked into AMF, but I am still debating outside of the reporting use case what else we need to be able to do via Cmdlets remotely.  Making them read-write is all about knowing the java beans, methods, and parameters that are required for posting.

 

• Connect-ViewConnServer
• Get-AccessSettings
• Get-Administrators
• Get-Desktops
• Get-EventConfiguration
• Get-Folders
• Get-ImageRepositoryDetails
• Get-LocalSessions
• Get-PersistentDisks
• Get-Policies
• Get-Pools
• Get-RemoteSessions
• Get-Roles
• Get-SecurityServers
• Get-Servers
• Get-ThinAppRepositories
• Get-ThinApps
• Get-TransferServers
• Get-UsageList
• Get-UsersGroups
• Get-VDMServers
• Get-ViewDashboard
• Get-ViewGlobalSettings
• Get-ViewStatus

Current Available Cmdlets

 

Instructions are very simple.  Download the zip, unzip ensuring that you keep the xml files in their respective directory, and then run an “import-module uadv_vmware_view.psm1”.  From there you have access to all of the cmdlets listed above.  You can issue get-help before cmdlets to see the available parameters.  For the most part the cmdlets are very bare since we are doing read-only operations and you can manipulate the data after the fact using Powershell standard methods (ft, sort, where, etc).

Begin by issuing a “Connect-ViewConnServer -user administrator -password xx -domain domain -viewConnServer 192.168.1.112”  From there you it should look like below, and you should be able to issue a command like “get-Desktops”.

A successful login, and then a get-desktops command formatted as a table.

 

 

Enjoy!!

Before I begin this post I want to make sure there is a pretty sharp warning attached.  What I am going to be discussing is a method in which you can programmatically adjust the members of VMware View Pools.  As far as I know this functionality does not exist via Powershell cmdlets or via a published API.  The methods in which I accomplish this task should serve solely as an example and for lab use only.  As always I hope the concept in practice can drive open some doors that previously were closed.  However, consider this method a complete divergence to existing VMware View managed desktops.

Now to continue the post.  The use cases here are interesting.  I have my own personal reasons for creating this functionality and you might have your own, so I am interested to hear your feedback since it would make the case stronger to release this through a published API. 

One of the first use cases I can provide would have to do with leveraging array based snapshots (NFS or block) and publish these new desktops to a specific pool.  This use case is very similar to what VMware View accomplishes today with composer and desktop refreshes/recomposes.  However, instead of linked clones we would be off-loading these tasks to the storage array for creating efficient linked virtual disks that serve as fresh desktops.  There are other things that Composer brings to the table which I am ignoring for this post (more to come).

A second use case I can think of would fall in the domain of Deskop as a Service offerings.  In order to keep efficient levels of desktops of certain types available at all times the current option is to over-provision and add desktops manually when the time comes for their demand.  Leveraging automation to dynamically adjust types of desktops would allow for the most efficient DaaS environment.

The third use case I can highlight I need to be a bit silent about since it is something that is an ongoing project.  I’m afraid you are going to have to wait for this one, but no doubt it will be worth it.  Let’s just say I am able to link VMware View with another VMware product using this method which traditionally would require some complicated databases to track the relationships.

Ok, so enough of the use cases, let’s dive into the details. 

 

We will be splitting the post up as follows.

• VMware View 5.0 Configuration Database (LDAP)
• Script in Action (custom_vmware_view.ps1)

 

VMware View Configuration Database (LDAP)

Before diving into the details it is important to understand some of the basics behind how the View Connection brokers maintain their configuration.  As far as I can tell there is only one area that I have found that holds configuration information.  This being an LDAP database on the View Connection brokers.  I hadn’t leveraged LDAP as a replicated database prior but after digging deeply into how LDAP here is used it is a very simple and cool use case.  One of the big benefits of using LDAP is the ability to leverage Microsoft ADAM to perform synchronization among multiple connection brokers to allow for front end redundancy. 

One of the great things about this approach is also the simplicity behind the user interface and the possibilities of manipulating this data.  Before the scripted manipulation portion, let’s dig into the manual methods to see and possibly manipulate the database. 

*Again, what you are seeing below is absolutely not supported by EMC or VMware.  I do not condone the use of what you are going to see other than for informational and educational purposes.*

This method is highly documented across the internet, so nothing new here.  Let’s start by opening an LDAP browser that comes with Microsoft Server 2008.  Go to Start –> Run and type “ADSI edit”.  It should show up in the top left corner of the start menu as follows.

 

In order to open the connection you need to specify a “Distinguished Name” and a Computer as a target.  The distinguished name should be exactly as follows “dc=vdi,dc=vmware,dc=int”.  The domain or server should be the IP or hostname of the connection broker.  If there are problems connecting, make sure you are opening the ADSI Edit application with administrator access to the VIew Connection broker server. 

 

Once you connect you should see the following screen with “Default naming context” appear.  Go ahead and double click this item, and then the “DC=vdi,DC=vmware,DC=int” should appear.  From there you should be able to expand this and start diggging through the Computer Names and Organizational Units.  Some of the important ones that we will be working with are “Servers” which are the desktops, and “Server Groups” which are the Desktop Pools.  You will find that navigating through the information and finding what you’re looking for under servers might be a bit complex due to how this is organized.

 

Just for quick reference, one thing that I’ve found in trying to automate the install of the VMware View agent is that it is easy to verify whether the agent is configured correctly or not by viewing the Agent’s registry settings from the desktop.  Go ahead and open up a desktop and open regedit to the following key HKEY_LOCAL_MACHINE –> Software –> VMware, Inc. –> VMware VDM –> Node Manager.  Notice the Server DN, and the Server Pool DN.  These link directly to what you see in the View LDAP database above.

 

Ok, so as you can see we have a working database via LDAP for the View Connection Broker.  In order to start populating pools dynamically there is a attribute under the “Server Groups” (pools) OU that specifies which desktops Computer Names are a part of the pool.  This is the attribute that we will be manipulating to dynamically bring in and remove desktops from pools.

 

 

The Script in Action

Now let’s start digging into the script and what we are achieving with it.  From what you saw above and what I experienced in digging into this topic it was pretty clear that we needed a script to assist in browsing the View LDAP database which then helps us manipulate it as well. 

Before getting too deep, here is the script..  By downloading you agree that this script is for educational and non-production environments and that the use of scripts will most likely lead to support problems.

In order to leverage the different built in functionality you can leverage the different actions that we have created functions for.

Action – View-Get-Objects – Get all objects from a specified OU or CN

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -ou servers

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -cn roles

 

As you can see we are adding a “ | select -first 1” on the end of the first example above which returns only the first desktop.  One of the great things about the script is that we are outputting all of the information as properly formatted Powershell objects which means we can leverage native cmdlets like Group and Sort.

The following example will show you the amount of desktops in each type of pool.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -ou servers | select “pae-DisplayName”,”pae-MemberDnOf” | group “pae-MemberDNof”

The following will show the desktops within the first pool.  You can switch out the “select –first 1”, with “where {$_.name -match “poolname”}” to pick a certain lab.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -ou servers | select “pae-DisplayName”,”pae-MemberDnOf” | group “pae-MemberDNof” | select –first 1 | %{ $_.group | select “pae-DisplayName” }

 

As you can see below, we substituted the “servers” for “server groups” as the OU parameter and got the desktop pools.  This will work for anything you see in ADSI edit that shows up as an OU, and you can specify CN as a parameter for things in the top level that show up as a CN.

Action – View-Get-Object – Get a specific object

This action is actually called by the next action we are going to specify.  There are three parameters which I can try and write out here to have it make more sense.  In order to get an object we specify the OU in which it lives, we then specify a where clause based on a field and the value is what is contained in that field.

Action – View-Get-Desktop – Get a specific desktop

We call the View-Get-Object here with the following parameters ($ou = “servers”, $field=”pae-DisplayName”,$value=”desktop name”).  The parameter you specify with this action is the “name”. 

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action View-Get-Desktop –name desktopName | fl *

 

Action – View-Remove-Desktop – Remove Desktop from Pool

In order to get the desktop out of a pool we actually execute the above actions behind the scenes.  First we get the desktop CN you are looking for, then we find the pool CN.  This is followed by manipulating the pae-MemberDNof to exlude the CN of the desktop specified.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action View-Remove-Desktop -name desktopName

 

Action – View-Add-Desktop – Add Desktop to Pool

This action behind the scenes is very similar to the remove.  However, instead of removing from the pae-MemberDNof, we add it to groups of desktop CNs in that attribute.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action View-Add-Desktop -name desktopName -pool poolName

 

 

That’s all for now!  I am interested to hear some use cases so we can fully understand the usefulness of this type of functionality.  Feel free to add comments.

 

Download the script here.  By downloading you agree that this script is for educational and non-production environments and that the use of scripts will most likely lead to support problems.

If you haven’t noticed yet, PowerCLI gives some amazing capabilities for managing virtual machines that may or may not have access to remote resources. 

Most recently I have been tasked with working with View to see how it can play in an up and coming project we have going within the EMC vSpecialist group.  Over the past few days I have been diving deep into certain areas  trying the squeeze the most out of View from an automation perspective with View Guru,  Andre Leibovici (@andreleibovici).  We have accomplished some very interesting stuff that for the most part isn’t out there that I can find (and may or may not be useful to most), so look for a few cool tidbits coming out.  I can’t guarantee we post everything since some of it isn’t by way of official API channels, possibly some hints here and there =).

The first tidbit to show revolves around the title of the article.  If you have desktops that have been provisioned, and are looking to programmatically install the View Agent and are possibly constrained by networking, here is a useful way to leverage the PowerCLI Invoke-VMScript and Copy-VMGuestFile cmdlets to copy and install the View Agent remotely invidually or possibly en masse.  I will leave the use cases for this up to you!

The following assumes you are logged into PowerCLI and have done a Connect-VIserver to get access to VM resources.

 

 

1) Set all of the variables

$vmname=“VMname”

$agentpath=“\\connserver\install\VMware-viewagent-x86_64-e.x.p-443491.exe”

$file=$agentpath.split(‘\’)[-1]

$destinationpath=“c:\”

$destinationfilepath=“$($desinationpath)$($file)”

$viewConnServer=“connserver”

$viewAdminUser=“administrator”

$viewAdminPassword=“password”

$viewAddLocal=“Core,PCoIP”

$desktopGuestUser=“administrator”

$desktopGuestPassword=“password”

 

2) Attempt to copy the Agent to the remote system

try {

get-item$agentpath|copy-vmguestfile-destination$destinationpath-vm$vmname-guestuser$desktopGuestUser-guestpassword$desktopGuestPassword-localtoguest-eastop

} catch {

    “Failed to copy agent”;$error[0]

}

 

3) Check to make sure VMTools is running

Do{

$status=Get-vm$vmname|%{ $_.guest |%{ $_.extensiondata.toolsrunningstatus } }

} until ($status–eq  “guestToolsRunning”)

 

4) Set the scriptblock with parameters for VMware View Agent installer

$script=‘”‘+$destinationfilepath+‘” /s /v”/qn VDM_VC_MANAGED_AGENT=0 VDM_SERVER_NAME=’+

              $viewConnServer+‘ VDM_SERVER_USERNAME=’+$viewAdminUser+‘ VDM_SERVER_PASSWORD=’+

              $viewAdminPassword+‘ ADDLOCAL=’+$viewAddLocal+‘”‘

 

4) Attempt to remotely start VMware View Agent

 

try {

    Invoke-VMScript-ScriptText$script–VM$vmname-guestuser$desktopGuestUser-guestpassword$desktopGuestPassword-ScriptTypebat-eastop

} catch { if ($error[0]-match“the guest operations agent”) { “View Agent kicked off a reboot”} else { $error[0] } }