What’s in the View AD-LDS ?

For those that are working with VMware View it is probably common knowledge that View stores information about the virtual desktop infrastructure configuration in an AD-LDS (Active Directory Lightweight Directory Service) on the Connection Servers. An AD-LDS, previously known as ADAM, is an embedded LDAP directory.

Since the current PowerShell snapin that comes with VMware View is seriously lacking functionality, and doesn’t integrate too well with the PowerCLI snapin, there are several View administrators out there, that look at this AD-LDS to help them manage their View environment.

I will list a number of existing scripts that use the AD-LDS to retrieve View related information. But most of the time these scripts go for only part of the available information.

These are just a few examples of such scripts.

In this function I aimed at getting all the information that View keeps in the AD LDS.

That way:

  • you don’t need no to use something like AdsiEdit to explore what is there
  • it will give you a way to have a backup of the View AD-LDS content
  • it will allow you to perform an audit of your View environment, and discover which recent change is causing problems

This script was shown during our VMworld 2012 presentation as an example of how to integrate with different VMware products from PowerShell.

Note: the following functions were tested against View 5.1. I can’t guarantee their proper functioning against earlier View releases.


While I was thinking of writing this function to extract all the View information from the AD-LDS partition, there were a couple of decisions to be made.

The View Schema

The View AD-LDS partition contains multiple types of records. The layout of these records can not be retrieved from the actual AD-LDS partition, because some of the attributes on these records are OPTIONAL. In other words, the attribute is not necessarily present in a record you retrieve from the AD-LDS partition.

The easiest solution I found was to use the vdiSchema.ldf file that is used when you install VMware View to create the AD-LDS partition.

From that .ldf file it was rather easy to extract the layout of each record used by View and containing all the possible attributes, also the optional ones.

Since this file, and consequently the View AD-LDS schema, only potentially changes when there is a new View version, or in some rare cases when there are View patches, you will only need to read this .ldf file once for each View build.

The .ldf file can be found in %ProgramFiles%\VMware\VMware View\Server\LDAP\ldif on any of your View Connection servers.

The View AD-LDS Records

The View AD-LDS partition uses different type of records (see the previous section).

As a consequence, I couldn’t export the content of the records to a single CSV file. As a solution I decided to use an XLS file, where I could place each type of record in a separate worksheet.

For that I use the Export-Xls function from my Beyond Export-Csv: Export-Xls post.

The Schema Export Script


Line 16: With the $VDISchema parameter you specify the path to the .ldf file that is used to define the records in the View AD-LDS partition.

Line 19-21: Some RegEx expression that are later in the script to analyse the entries in the .ldf file. Note the 2 RegEx expressions that will bring out the obligatory and optional attributes

Line 33-43: This part of the script extracts the class information from the .ldf file. The script only handles the classes that start with pae-. These are actually the classes in the AD LDS partition that will hold View related information.

Line 44-52: The code that handles the required attributes.

Line 53-61: The code that handles the optional attributes.

The AD-LDS Export Script


Line 21: The start node in the AD LDS partition where the function should start. The View partition root node is called “dc=vdi,dc=vmware,dc=int

Line 23: The hash table that contains the View classes that were retrieved by the Get-VDILDSSchema function from the .ldf file.

Line 27-53: An internal helper function that actually reads the records and their attributes. This helper function is called by the main process at each node.

Line 36: If the script encounters a record that is described in the hash table, it will extract the required info, and place the created object in the pipeline. Remember we only look at records that start with pae-.

Line 43: For each View related record the script finds, it only looks at the attributes that start with pae-. These are the View related attributed and avoid that the script looses time by looking at all the other attributes.

Line 56-62: The main routine of the function. Note that the script calls itself recursively for each of the children at a node. And at each node, the internal helper function is called to retrieve the records and their attributes at the node.

Sample Usage

Both functions can be used separately. You can first read the .ldf file and store the extracted class information in a XML file.

But you can bring a bit more intelligence in a script.

In the following example the script checks if the XML file is present, and if not it will create it. Then the script continues by extracting all the records from the View partition. So in this case you only need to provide the .ldf file.

To make your life easier, the following download link allows you to get a .ps1 file that holds all the functions and the main logic. You just have to provide it with the path to the .ldf file, the path to the .xml file and the name of the .xls file.

View AD LDS dump to XLS
View AD LDS dump to XLS
Version: 1.0
9.9 KiB

And to give you an idea of what is contained in the .xls file, some screenshots.

A worksheet per available recordtype

Each View record attribute in a column.

And of course the values.

In a follow-up post I will show you how you can use this .xls file to retrieve the information that some of the scripts I mentioned in the beginning of this post were using.

Enjoy !

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.