Where I Go Spelunking into the Horizon View LDAP Database–Part 2

In Part 1 of this series, I shared some of the resources that are currently available in the greater VMware View community that work directly with the View LDAP database.  Overall, there are some great things being done with these scripts, but they barely scratch the surface of what is in the LDAP database.

Connecting to the View LDAP Database

Connecting to the VIew LDAP database has been covered a few times, and VMware has a knowledgebase article that covers the steps to use ADSI edit on Windows Server. 

Any scripting language with an LDAP provider can also access the database.  Although they’re not View specific, there are a number of resources for using scripting languages, such as PowerShell or Python, with an LDAP database.

Top-Level LDAP Organizational Units

LDAP OUs

Like Active Directory or any other LDAP database, there are a number of top-level OUs where all the objects are stored.  Unlike many LDAP databases, though, the naming of these OUs doesn’t make it easy to navigate and find the objects that you’re looking for.

The OUs that are in the View LDAP Database are:

Organizational Unit Name

Purpose

Applications Pool, Application, and ThinApp settings
Data Disks Persistent Desktop Data Disks
Hosts ?? Possibly Terminal Server or Manual Pool members
Groups View Folders and Security Groups/Roles
ForeignSecurityPrincipals Active Directory SIDs used with View
Packages ?? Possibly ThinApp repositories or packages
People ??
Polices Various system properties stored in child container attributes
Properties VDM properties, child OU contains event strings
Roles Built-in security?
Servers Desktops
Server Groups Desktop Pools

You may notice that a few of the OUs have question marks under their purpose.  I wasn’t able to figure out what those OUs were used for based on how I had set up my home lab.  I normally don’t work with Terminal Server or Manual pools or ThinApp, and I suspect that the OUs that aren’t defined relate to those areas.

This series is going to continue at a slower pace over the next couple of months as I shift the focus to writing scripts against the LDAP database.

Where I Go Spelunking into the Horizon View LDAP Database–Part 1

Note: The items and techniques discussed in this post are not supported by VMware.  Before using it in a production VMware View environment, please be sure to test it in a non-production environment. 

Like many of the other product offerings, VMware includes a set of PowerCLI cmdlets that can be used with VMware View.  However, unlike the other PowerCLI cmdlets, there are some significant limits to what can be done with these cmdlets, including:

  • They can only be used on the View Connection Server*
  • They are feature-limited
  • They haven’t been upgraded with the rest of View, so features like View Storage Accelerator/Content-Based Read Cache and VMware Blast cannot be managed from PowerShell

*Note: Scripts utilizing the View PowerCLI commands can be executed via PowerShell Remoting or tools like PSEXEC.  However, the script still needs to be locally stored on the Connection Server.

But there is still one option for working with View.  Although the API for View isn’t as robust as other mainstream VMware products, the primary database is based is LDAP.  This opens up a whole new world of possibilities when trying to automate against VMware View.

Exploring the View LDAP Database

VMware doesn’t provide a lot of information about the View LDAP database in their support documents, and in almost all cases, directly editing entries in LDAP is not supported.  But there is information out there.

A few months ago, I posted a script that worked directly against the View LDAP database to find and remediate desktops that were using the wrong snapshot as a base image.  Other bloggers and community members have put together some scripts that work directly against the LDAP database.  Some of those resources are:

The link to Luc Dekens’ blog contained a very surprising revelation – VMware includes an entire copy of the schema on the Connection Servers.  This can provide a good starting point for working with View’s LDAP database as it does include a description of what each field does.  Some of the descriptions also include accepted and/or default values.

With a default install of VIew, the schema file is located at %ProgramFiles%\VMware\VMware View\Server\LDAP\ldif, and it can be opened with any text editor program.

The existence of this file has already saved me a lot of time.  My initial plan was to actually dive in and map attributes to feature sets by trial-and-error.  I may have to do that for some items, such as the pae-CitrixXMLServicePort attribute, but this provides a rough map of the LDAP layout and what the different attributes control.

This only scratches the surface of what can be done with the LDAP database.  And like a large cave system that has multiple branches and tunnels, the View LDAP database has several containers, entities, and attributes that need to be explored.