Printing has, and is, a traditionally well-known challenge in Server Based Computing environments. Print-IT is one of the first products that Provision Networks (well before became a member of the Quest family) offered that addressed this problem. When Provision Networks started doing VDI in 2005, we immediately recognized that printing would pose some of the same problems in VDI environments so Print-IT became an integral part of our VDI solution as well, thus providing a seamless printing experience across SBC, VDI and even Blade PCs.

Originally being one of the first products by Provision Networks, Print-IT is an extremely mature universal printing solution. In fact, universal printing as a description doesn’t do Print-IT enough justice. There’s a lot more to Print-IT then that. And since a lot of our customers are amazed at the versatility of Print-IT that comes as an integral part with any Virtual Access Suite license, I decided that it might be worth giving you a quick heads-up on the current feature set of Print-IT:

Read the rest of this post »

One of the core design goals of the Virtual Access Suite is to enable the seamless deployment of an application, desktop or content regardless of the application delivery concept used. So whether the application delivery concept is VDI, SBC or Blade PCs, the Virtual Access Suite can do it all. From one console. With one license. One Database.

Anyway, you get the idea. We think it is critical to have a single pane of glass whilst still having the flexibility to deploy applications and desktops in the way you want to. To make getting started with the Virtual Access suite easier there are a number of guides available. Because of our hypervisor agnostic nature there are guides to getting started with VMware, Hyper-V and Parallels Virtuozzo Containers. SBC should not be forgotten of course, so in this post I wanted to point out that there is a similar guide for getting started with the Virtual Access Suite in a Terminal Server environment.

The guide describes the requirements,the installation and the configuration steps to test the Terminal Server enhancements of Quest Software’s Provision Networks Virtual Access Suite 5.10. It takes you through the following steps:

• Downloading the Provision Networks Virtual Access Suite 5.10 Software
• Installing the Connection Broker
• Entering Customer Information
• Meeting the Terminal Server Requirements
• Installing the VAS Terminal Server Enhancements
• Publishing a Terminal Server Resource: Creating a Managed Application
• Using Evaluation Licenses
• Installing the Provision Networks Virtual Access Suite Client
• Configuring AppPortal
• Using AppPortal to connect to a Terminal Server application

Download the Getting Started Guide for Virtual Access Suite 5.10 in a Terminal Server Environment.

Creating a well thought out and well tuned Windows XP Template is important for a successful VDI implementation.  My intent for this whitepaper is that it will guide you in developing a solid VDI Desktop standard for your organization.  Included in this whitepaper is information to assist in reducing your Windows XP footprint and to apply best practices to the Windows XP configuration for improved performance, manageability, and reliability of your VDI environment.  Since computer environments can vary from one organization to another, it is recommended that all best practices listed in this document be tested in your test VDI environment to ensure that it is helps and not hinder your VDI solution.

Download the whitepaper here: Creating a VDI Windows XP Template.

IMPORTANT: This guide applies to version 5.10. The most current version of this guide that applies to vWorkspace 6.0 is located here.

As you probably know the Virtual Access Suite supports a broad selection of leading hypervisors. Among the supported hypervisors is VMware ESX (more specifically VMware Virtual Infrastructure). To make it very easy for you to evaluate the Virtual Access Suite in a VMware Virtual Infrastructure we have created a “getting started guide” which details all the steps you need to take to be able to start evaluating all the cool features in the Virtual Access Suite.

The guide will describe the requirements and the installation and configuration steps to the Virtual Access Suite 5.10 in a VMware VI 3.x Environment. The following procedures are detailed:

• Downloading the Provision Networks Virtual Access Suite 5.10 Software
• Installing the Connection Broker
• Entering Customer Information
• Adding a VMware Virtual Infrastructure
• Importing VMware Datacenters
• Creating Virtual Desktops from a template in the Managed Computer Group
• Installing PNtools
• Using Evaluation Licenses
• Installing the Provision Networks Virtual Access Suite Client
• Configuring AppPortal
• Launching AppPortal

Download the guide here: Getting Started With Virtual Access Suite in a Vmware Virtual Infrastructure Environment.

Here at Quest we are (not surprisingly) very excited about our products. We are sure you will be as well, as soon as you have tried our products for yourself. To that end we have made it very easy to download an evaluation copy of the Virtual Access Suite (5.10) and to even generate your own evaluation licenses.

Sometimes we still get questions, so to make sure that your evaluation experience is as smooth as possible, we have created a document that discusses exactly what steps you need to take to start evaluating the Virtual Access Suite: Obtaining Virtual Access Suite Evaluation Software and Licenses.

Happy evaluating!

When a managed desktop (virtual or physical) is added to a managed desktop group, the Provision Networks Data Collector Service must be installed to allow the managed desktop to communicate properly with Provision Networks Connection Brokers. The process that accomplishes this is called the Initialize Computer task and is one of the responsibilities of the Connection Broker.

This Initialize Computer task is very important. When it does not complete successfully the connect broker will consider the desktop unusable and mark it as “offline”, thus making it unavailable to users. The failure to successfully complete the Initialize Computer task can have lots of different causes. Some of the common causes are:

• Firewalls that are blocking the communications between the Connection Broker and the Managed Desktop (read this post for all the ports used in these communications)
• Name resolution issues (the Managed desktop can not resolve the name of the Connection Broker or vice versa)
• Insufficient privileges held on the Managed Desktop. These privileges boil down to being able to connect to the administrator file shares (C$, D$, etc) and the privilege to create a service on the Managed Desktop. A local admin typically has these privileges. The account used here is the “Computer Administrative Account” that is set in the properties of the Computer Group.

Depending on where the cause of the computer initialization failure lies, it might help to enable debug logging. We already showed you how to enable logging on the Connection Broker. You can also enable logging on the Managed Desktop itself. To enable logging, do the following.

• In the registry on the Managed Desktop, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Provision Networks\Provision-IT
• Create a new “String Value” with the name “DCServerLog” (case sensitive) and a value of “C:\DCserverlog.txt”.
• Next restart the Provision Networks Data Collector Service. Either open a command prompt and type net stop pndcsvc followed by net start pndcsvc or, alternatively, use service.msc to restart the service.

After the service has been restarted you will find a file in the root on the C:\ drive called “DCServerlog.txt” that holds all the logging for the Provision Networks Data Collector Service. This log has all the information you will ever need to troubleshoot Provision Networks Data Collector Service issues.

It is important to note that this logging is recommended only for troubleshooting purposes and should be disabled in production environments, when possible.

Configuration of the Wyse Thin OS (WTOS) is completely controlled via DHCP and ini files on the connection broker, so these devices can literally be taken out of the box, plugged in and they will automatically boot, download new firmware (if available), contact a connection broker, then launch a desktop.

So what needs to be configured in DHCP:

DHCP Option 188 is used to list the addresses of each connection broker, and the XML Communication Port. DHCP Option 161 lists the servers that hold updated WTOS Firmware. Since Provision Networks Connection Brokers can do both of these, once may configure either or both options. In the screenshot above, only option 188 is configured.

On the connection broker(s) browse to %ProgramFiles%\Provision Networks\Wyse. Create a sub-directory named “WNOS” (case sensitive). In the WNOS directory, create two sub-directories, “ini” and “bitmap“

Use notepad to create the two ini files listed in the WNOS directory.

wnos.ini contents:

signon=1
autoload=1
autosignoff=yes
privilege=High
Domainlist=YourDomainName

————————————————–

rdp.ini contents:

Fullscreen=yes
Colors=high
Encryption=128
Experience=15
Lowband=no
Autoconnect=1

————————————————–

To update the WTOS Firmware, copy the new firmware (RCA_wnos) to the WNOS directory, and set “autoload=1″ on the wnos.ini file.

At this point, the basic configuration is completed to connect a WTOS Thin Client to a Provision Networks Connection Broker. If one has multiple connection brokers, list them in the DHCP options and copy the contents of the Wyse Directory to each additional connection broker. There are many options available in the ini files, so detailed instructions are in the documents listed below:

Enhanced Support for WYSE Thin OS

WTOS 6.1 Admin Guide

Any successful IT Project follows some sort of methodology. One part of the project methodology should include an investigation phase, where one takes an inventory of the current environment, and brainstorms for anything that may be required or could cause the project to fail. This is also important so valuable time is not wasted performing preparation tasks that could have been accomplished before the consultant/vendor is on site.

VDI deployments typically start with a small POC (Proof of Concept) where one or more connection brokers are put thru the paces to see if they meet the business and technical requirements, and to verify that the product functions as advertised.

Before one starts the POC, there are a lot of things to consider, i.e. Virtual Infrastructure, SAN, Clients, Connection Broker, Network Infrastructure, Peripheral Support, Security Requirements, Licensing, Current Desktop Management Tools….

To ease in this collection of data I’ve created a spreadsheet that attempts to capture the important details. The point of doing this is to make sure the consultant, vendor and customer are aware of the customer’s current environment, requirements and planned deployment size.

vdi_pre-engagement_inventory

P.S. Sheet one of the Excel Workbook is broken down into categories comprised of several related items, where each item is answered by a picklist or manual entry. Sheet two contains the definitions of all of the picklists.

The Virtual Access Suite is a product that contains many different sub products that all communicate with one another. This article discusses all the ports used in the Virtual Access Suite and how they are used. I guess it goes without saying that these ports should be open for smooth sailing. The image below shows what components can exist in a VAS infrastructure and how they interact.

Read the rest of this post »