How to install and configure Provision Networks Virtual Access Suite (VAS) Enterprise Edition (Part 3)

If you would like to read the other parts in this article series please go to:

Virtual Access Suite, Desktop Services can connect RDP clients to desktops whether they are standard PCs (XP Pro or Vista), PC Blades, or hosted on a Virtual Infrastructure like VMware, Virtual Iron, SWsoft Virtuozzo, Microsoft Virtual Server, Citrix XenServer…. When used in combination with a system with a centralized management console (Managed Virtual Infrastructure) like VMware Virtual Center or Virtual Iron, Virtual Access Suite uses the Virtual Infrastructure Vendor’s SDK to automate and tasks that could otherwise be accomplished only via the vendor’s management server. Use of an SDK also adds functionality that does not exist in the vendor’s native management console. 


A component called PNTools is installed on each RDP Host, whether virtual or physical, to provide features like Seamless Windows, Universal Printer Driver, USB Handheld Sync and management of the group membership of the Remote Desktop User’s Group. This component installs two services:

  1. Provision Networks Data Collector. This service communicates (tcp port 5203) with the Provision Networks Connection Broker (tcp port 5201) and manages the user assignment to the Remote Desktop Users Group.
  2. Provision Networks Print-IT. This service enables Universal Printing, so users can print, with full functionality, to any printer defined on their Windows Client. This does NOT require installation of any Native Windows Printer Drivers on each Virtual Desktop to support client printing.

If one manually installs PNTools on Windows XP Pro SP2, the installer will automatically configure the Windows Firewall to allow communication on the appropriate ports. If the installation is pushed from the Provision Management Console, the firewall must be manually configured.

Configuring integration with a managed Virtual Infrastructure Server

Ensure that VMware and Virtual Iron Integration was selected during the Virtual Access Suite Connection Broker installation. This can be verified via add/remove programs, select Modify on the Virtual Access Suite installation, expand Connection Broker.

Install .Net Framework 2.0 and Sun Java Runtime 5.0 update 9, 10, or 11 on the Connection Broker. Virtual Access Suite does NOT currently work with Sun Java Runtime Environment 6, but if it is already installed, JRE 5 update 9, 10, or 11 can be installed without uninstalling JRE 6.

Acquiring the SSL Server Certificate from Virtual Center

Logon to a Provision Networks Connection Broker and launch the VDI Preinstall Configurator. This .hta file has the capability to download and install prerequisites like .Net Framework 2.0 and Sun Java Runtime Environment 5 update 9 (updates 10 and 11 also supported). It can also download and install the SSL Server Certificate from the Virtual Center Server and save it to the Java Keystore.

Enter the information required to connect to Virtual Center. The credentials entered need to be able to map a network drive to the Virtual Center Server to download and install the SSL Server Certificate. The user name should be in the format Domain\User. The default password for the VMWare.keystore file is “changeit”

If an account is not available that has such permissions, the SSL Certificate can be downloaded and manually configured. Instructions for this manual configuration are in the referenced Provision Networks Virtual Access Suite Troubleshooting FAQ. When the configurator is complete, the certificate files are written to c:\VMware-Certs.

Verify that files exist, and that the directory name is exactly as listed, as the communication between the Connection Broker and Virtual Center is done via Java, which is case sensitive.

If more than one connection broker is in operation, copy the contents of the “c:\VMware-Certs” directory to each of the servers, or run the configurator on each server. Restart the Provision Networks Connection Broker Service, or restart the server.

Defining Virtual Management Servers in the Provision Management Console

Launch the Provision Management Console and browse to the Desktop Services Node. Right-click and select “Virtual Management Servers”.

Enter the name of the Virtual Center Server and select the Server Type as VMware.

Enter the Server URL to the Virtual Center Server, i.e. https://VirtualCenter/sdk

Enter the credentials for a local or domain account with administrative permissions in Virtual Center. A custom role can be created in Virtual Center with more granular permissions, but that is beyond the scope of this document.

The correct value connection timeout depends on how many objects are defined in Virtual Center. The larger the environment, the longer import operations can take, and the larger the timeout value should be.

The other settings options for each Virtual Management Server define the number of concurrent operations can be sent to the Virtual Management Server by the Provision Networks Connection Broker. The clone operation is the most resource intensive operation, as it requires creating new virtual disk files and spinning up the new virtual machines. These settings can be tailored to one’s environment, i.e. 2 clone operations for an environment with one Virtual Infrastructure Host and connected SAN LUN. If many Virtual Infrastructure Hosts exist in the environment, and the SAN that hosts the virtual disk files is robust, the number of clone operations can be increased accordingly as the load can be simultaneously spread across multiple resource pools, Virtual Infrastructure Hosts and SAN LUNS.

Importing Datacenters into the Provision Management Console

To import one or many Datacenters from Virtual Center to the Provision Management Console, right click on Desktop Services and select Data Centers. At least one datacenter MUST by imported to interact with the Virtual Management Server.

Select the Datacenter Type as VMware.

Select the Virtual Management Server from which the Datacenters should be imported.

Select the Datacenters to be imported. In an enterprise deployment, dedicated datacenters may be defined for VDI, for use for the desktop support engineers.

Creating managed Desktop Groups

A Desktop Group is a set of desktops that contains new desktops that are created from a virtual machine template, or that are imported from the defined datacenter. Typically Desktop Groups are created to organize desktops by Business Unit, i.e. machines that had the same system image on deployment of physical PCs.

Right click on Desktop Services and select New Managed Desktop Group.

Enter a descriptive Group Name, i.e. “Accounting Dept XP Pro Desktops”.

Enter the name of a Desktop Administrative Account (Service/Role Account) that will be used to perform the management functions (installation/upgrade of PNTools, Shutdown, Restart, Logoff, Reset…) from the Provision Management Console. This account MUST be a member of the local administrators group on the desktops. This account could be the local administrator account, or a service account that is created specifically for these management tasks and is added to the local administrators group via Group Policy.

Enter the number of desktops to create (from a virtual machine template that was created in Virtual Center). One could also import existing desktops from Virtual Center. The number of desktops to be created is only limited by the capacity of the Virtual Infrastructure. The recommended maximum number of desktops that can be managed by a single instance of VMware Virtual Center is 1500.

This list is empty the first time this wizard is run, so click “Import” to import the list of available virtual machine templates from Virtual Center. Select the Virtual Machine Template that will be cloned to create the new desktops. This template is created in Virtual Center.

This list is empty the first time this wizard is run, so click “Import” to import the folder structure from Virtual Center. Select the folder in which the new virtual machines should be organized.

This list is empty the first time this wizard is run, so click “Import” to import the list of available Resource Pools/Datastores from Virtual Center.

One can spread the virtual machines across multiple resource pools and datastores. Define how the wizard should distribute the machines across the datastores.

In the example shown, the five desktops being built are spread equally across five different datastores.

Provide a naming convention for the new desktops, or provide a list of names via a text file. In the example above the base name is “XPACCT?”. This will generate the new desktops with names XPACCT1, XPACCT2, XPACCT3, XPACCT4, and XPACCT5. If ten or more desktops were being created, two question marks would be in the base name.

With sysprep customizations, the administrator can apply a new sysprep.inf file to the desktops being built. Click the “New” button to create a new Sysprep Template.

For the sysprep customizations to be applied when the virtual machines boot, the sysprep files MUST exist on the Virtual Center Server in “%SystemRoot%\Documents and Settings\All Users\Application Data\VMware\VMware Virtual Center\sysprep\xp\”. If one is not familiar with Sysprep, these file can be downloaded from Microsoft’s website. When installed they are written to %WinDir%\system32\ Extract the files shown in the picture from the file to the specified directory on the Virtual Center Server.

Assign a meaningful name to the new Sysprep Customizations, i.e. the name of the Managed Desktop Group.

If one already has a completed sysprep.inf file, it can be imported from a file.

Select the Operating System of the new desktops that are being built. The OS selected must match the version of the Sysprep files on Virtual Center.

Enter the registration information for the new desktops.

Enter the Time Zone that will be set.

Enter the Windows Volume License Product Key, or provide a list of Product Keys from a file.

Enter the new local Administrator Password for the desktops.

Specify the Domain or Workgroup. If specifying that the desktops should join a Domain, specify the account that will be used create the computer accounts in Active Directory.

Browse to the Active Directory OU where the new computer accounts should be created. If nothing is specified, the accounts will be created in the default “Computers” OU. Specifying the correct OU allows the machines to receive the correct Group Policy on the first boot after the machine joins the domain.

Use the default regional settings, or select one from the list.

If necessary, select language groups in addition to or other than the default.

One can specify additional commands that should be executed, and which order they should execute.

An Identification String can be inserted into the registry so one can tell which sysprep customizations were used to build the desktop.

Custom Sysprep Entries are any other entries that are supported by sysprep that are not exposed in this GUI.

A Summary is displayed so one may review all of the settings that were entered. Click Finish to save the new sysprep customizations.

Select the newly created Sysprep Customizations and click next.

Back to the Managed Desktop Group Wizard, the Options allow one to start the creation of the virtual machines “immediately”, or one may schedule the operations to be started at a specified date and time, i.e. during a period when the build of the desktops would not adversely affect production.

Review the names of the desktops that will be created, and on which Datastores they will be created. Click finish to submit the jobs into the task list. The jobs are sent to Virtual Center at the scheduled time that was specified.

When the Managed Desktop Group is selected, on the bottom of the console the tasks are listed along with the progress of each and their current status.

When the Managed Desktop Group is selected, from the Desktops Tab, the administrator can right click on a desktop and perform options like Update Power Status (if the console isn’t set to automatically refresh), install/update PNTools, Power On/Off the VM, Reset the VM, Resume a suspended VM, Suspend a running VM, Shut Down the OS, Restart the OS, Logoff the current user, Reset the current user’s session (non-graceful logoff), Cancel the current running task, Remote the VM from the Desktop Group, Delete the VM, View/Edit the policy applied to the Desktop and view the Properties of the Desktop.

By right clicking on a Desktop Group, one of the options is “Group Policy”. This is unrelated to Active Directory Group Policies, but rather are policy settings that are applied to the Desktop Group.

The User Assignment Tab allows the administrator to specify whether users are temporarily or permanently assigned to the desktop to which the Connection Broker directs them.

When set to Temporary, the Provision Networks Data Collector Service on the Managed Desktop inserts the User’s Account into the Local Remote Desktop User’s Group at logon, and removes it at logoff. This allows the desktop to be dynamically assigned to another user as directed by the Connection Broker.

When set to Permanently, the first time a user is directed to a desktop by the Connection Broker, the desktop is permanently assigned to the desktop, so that user is the only user that can logon to the machine (along with administrators). At subsequent logons the connection broker always directs the user back to the same desktop. The screenshot above shows the permanent assignment on a given desktop.

The Access Timetable tab allows the administrator to define days of the week and hours when logons to the desktops are allowed or denied. Click on the grid to view the Schedule Editor.

The User Privileges tab allows the administrator to specify whether users that are assigned to desktops shall be inserted into the local Power Users or Administrators Group.

The Session Auto-Logoff tab allows the administrator to define a list of applications that shall cause the system to force a logoff, if they are still running after the user closes all published applications, or if the user tries to logoff of their desktop and the logoff process does not complete successfully.

The Inactivity Timeout tab allows the administrator to define whether the VM shall be suspended after a successful logoff, or after the defined inactivity timeout. This helps to conserve resources, but can cause the end user to have to wait for the VM to power on at the next logon.

The Inactivity Timeout is defined in the properties of the root Desktop Services node in the Provision Management Console.

Since PNTools is required to exist on the Desktop OS for the client to connect to the VM via the Connection Broker, it is often best to install PNTools as part of the base system image. The location of PNTools for deployment from the Provision Management Console is defined in the PNTools tab.

To manually install PNTools on a single desktop, multiple desktops or an entire Desktop Group, right click on the object in the Provision Management Console. This will schedule a task to install PNTools and will force a reboot of the VM when the installation is completed. 

Rumor has it that this technology is currently being extended so any MSI based application will be able to scheduled for installation on a VM via the Provision Management Console.

Overriding the Managed Desktop Group Policy

While the Group Policy applied to a Desktop Group is a very convenient method of managing groups of desktops as a whole, there is usually a need to make an exception to a rule.

If the administrator double clicks on a given desktop, each of the Group Policy Tabs can be overridden for that individual desktop.

If a user is currently logged onto the selected desktop, the administrator can permanently assign the user to the desktop. If no user is logged on, the administrator can pre-select a specific user (from Active Directory) that shall be permanently assigned to the desktop.

Managed Applications

As described in the previous article on Terminal Services, the administrator can publish programs, desktops or content. The same holds true for VDI. Unlike other VDI solutions, the Provision Networks Connection Broker can present users with a published desktop or multiple individual applications, regardless of whether the destination system is a Terminal Server, or a single-user Desktop Operating System.

One can publish applications to Managed Desktop Groups from Resources -> Managed Applications, or from the right click menu on a selected Desktop Group.

The steps for publishing applications to Managed Desktop Groups are identical to Publishing Applications to Terminal Services, with a couple exceptions.

Select the ellipses next to the “Path” text box, and then select “Managed Desktop…”

Enter the name of a “Powered On” desktop in the destination Managed Desktop Group.

Select the Drive on which the application exists, and then browse the file system to the program being published. If publishing individual applications, instead of desktops, the assumption is that each desktop in a Managed Desktop Group has the same software installed.

Refer to the part two of this article series for more in depth details on application publishing.

Connecting from Provision Networks Web-IT

One of the connection mechanisms available is a secure web portal, with or without an SSL Reverse Proxy. Configuration of these components will be detailed in a future article in this series.

After authenticating, the user is presented with the applications that have been assigned to them by the administrator.


If the destination computer is not powered on, or is suspended, the user will be presented with the status when the application is selected. The connection broker will send commands to Virtual Center to power on or resume the appropriate Virtual Machine. The status in the window (show above) will be reported back to the client in real time. Once the OS is loaded, the Application or Managed Desktop will be connected.

If the end user has been assigned a published desktop, a standard Windows Desktop will be displayed. If however the user has been assigned multiple individual published applications, the applications will be displayed in Seamless Windows, and will share the same Windows Session, as shown in the screenshot above. If a user were to be allowed the choice of a Published Desktop, or Published Applications, launching a Published Desktop while using Published Applications will simply expose the desktop around the currently running seamless applications.


Clients can be configured to communicate with an unlimited list of communication brokers, which they contact randomly (not in the order listed), to provide redundancy. A future installation of this article series will discuss how to configure the different clients. The following clients exist for use with Virtual Access Suite:

  • Win32 ActiveX Web Client
  • Win32 Desktop Applet / Desktop Integrated Client (AppPortal)
  • Java Web Client
  • Linux Client
  • Wyse Thin OS (WTOS) Client
  • HP Neoware Neolinux Client
  • Windows CE Client
  • Linux-based PXE Boot Client (available soon)


If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top