Install Admin

2010 Quest Software, Inc.
ALL RIGHTS RESERVED.

This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or
nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide
may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose
other than the purchasers personal use without the written permission of Quest Software, Inc.
The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any
intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S
TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY
WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE,
SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy
or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time
without notice. Quest does not make any commitment to update the information contained in this document.
If you have any questions regarding your potential use of this material, contact:
Quest Software World Headquarters
LEGAL Dept
5 Polaris Way
Aliso Viejo, CA 92656
www.quest.com
email: legal@quest.com
Refer to our Web site for regional and international office information.
This software includes the following third-party software:
Software developed by the Apache Software Foundation (www.apache.org). Copyright 2001-2004 The Apache Software Foundation. Licensed
under the Apache License, Version 2.0, a copy of which is included on the software media.
ViewerX VNC ActiveX Control version 2.9.5.4. Copyright 2003-2009 SmartCode Solutions.
OpenSSL 0.9.8. Copyright (c) 1998-2008 The OpenSSL Project. All rights reserved. This product includes software developed by the OpenSSL
Project for use in the OpenSSL Toolkit (http://www.openssl.org/).
Net::SSLeay Copyright (c) 1996-2002 Sampo Kellomaki <sampo@symlabs.com> Copyright (c) 2005 Florian Ragwitz <rafl@debian.org> Copyright (c) 2005 Mike McCauley <mikem@open.com.au> All Rights Reserved. Distribution and use of this module is under the same terms as the
OpenSSL package itself (i.e. free, but mandatory attribution; NO
WARRANTY). Please consult LICENSE file in the root of the OpenSSL distribution.
Snmp Sharp net version 0.7.8 Copyright Milan Sinadinovic 2008, GNU LESSER GENERAL PUBLIC
LICENSE Version 3, 29 June 2007, Copyright 2007 Free Software Foundation, Inc.
NHibernate version 1.0.4.0 GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, Feb 1999. Copyright (C) 1991, 1999 Free Software Foundation, Inc. For full license text, see http://www.quest.com/legal/third-party-licenses.aspx.
ISC DHCP Daemon, version 4.1.1. Copyright 2004-2010 by Internet Systems Consortium, Inc. ("ISC"). For full
license text, see http://www.quest.com/legal/third-party-licenses.aspx.
PuTTY is copyright 1997-2009. For full license text, see http://www.quest.com/legal/third-party-licenses.aspx.
Perl Kit, Version 5.8 Copyright 1989-1999, Larry Wall, licensed under GNU Library GPL 2.0 or Perl Artistic License.
Mono Terminal 1.0. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following
conditions:Copyright (c) 2008 Novell, Inc.
Patents
Protected by U.S. Patent numbers 6,880,002, 6,990,666, 7,257,584, 7,287,186, 7,643,484, and 7,769,004; additional
patents pending.
Trademarks
Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, Benchmark Factory, Big Brother, BridgeAccess,
BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight, ChangeAuditor, CI Discovery, Cloud Automation Platform, Defender, DeployDirector, Desktop Authority, Directory Analyzer, Directory Troubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk Authority, Imceda, IntelliProfile, InTrust, Invirtus, iToken, JClass, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin, MessageStats, Monosphere,
NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point, Click, Done!, Quest vToolkit, Quest vWorkSpace, ReportADmin,
RestoreADmin, ScriptLogic, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World, vAutomator, vConverter, vEcoShell, VESI, vFoglight, vPackager,
vRanger Pro, vSpotlight, vStream, vToad, Vintela, Virtual DBA, VizionCore, Vizioncore vAutomation Suite, Vizioncore vEssentials, Vizioncore
vWorkflow, WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of
America and other countries. Other trademarks and registered trademarks are property of their respective owners.
Contents
Target Audience
Release Notes
About This Book
Documentation
Contact Information
Typeface Conventions
Acronyms and Abbreviations
1 Introduction
Architecture Overview
Components and Solutions
Solution Licensing
2 Before You Start

Determining the Scope of Your Installation
System Requirements
Additional Considerations
Network Communication
Configuring IIS V. 7 on Windows 2008 R2
Configuring Remotely Managed Hosts
About Partner Extensions
Security And Encryption
Choosing a Windows Account for the Agent Service (Altiris)
Using the vcsadmin Utility
3 Product Installation
Installation Scenario Overview
Installing the Core Services
Installing the Agent Services
Installing the Web Application and Solutions
Installing the SOAP API
Installing the Advanced Enterprise Pack (Optional)
Installing the Quest CAP Agent (Altiris)
About the CAP SOAP API Client
Launching the CAP Web Interface
4 Remote Access
Universal Remote Access
Web Browser and Connectivity Test
Classroom Readiness Test
Remote Access Solution System Requirements
Conducting Web Browser and Connectivity Test and CRT
Troubleshooting
v
v
v
vi
vi
vii
vii
1
2
3
8
9
10
11
18
22
25
26
33
36
38
38
41
42
43
50
55
59
62
63
70
71
73
74
80
80
82
119
124
5 Advanced
Installation and Administration Guide
Networking129
Networking Overview
NAIL Overview
Configuring NAIL Server Advanced Mode
Using VLAN-isolated DHCP Networks
Using Network Switch Automation
NAIL Server Troubleshooting
NAIL Diagnostics Error Message
Using NAIL Driver
Masquerading
Migrating From NAIL Driver to NAIL Server
6 Configuration and
Administration
Moving an Existing Library Location
Migrating the Agent Services and RSM
Configuring Storage and Shared Access
Managing Virtualization Hosts
Recovering and Managing Missing Items
Using the Dashboard
Using High Availability with VMware vSphere
Physical Provisioning
Installation for a Secure IIS Service Account
Installing the Add-In for HP Quality Center
Editing Advanced Configuration Settings
7 Troubleshooting
General Troubleshooting First Steps
High I/O and CPU Rates
Log In Failures with RDP Access
Altiris Deployment Server, Suspended Scripts
Error While Adding Host to Pool
Install Microsoft IIS Before .NET Framework
Installation Error Messages
Dashboard: Enabling SSL
8 Image Management
Image File Types
Duplicating Image Files
Creating New Images
Preparing Images
Agentless Images
Converting Hardware Versions for .vmdk Files
Using NAIL Driver on Windows Images
9 Physical and Network Resources

Overview of Resources
Resource Pools
Network Resources
System Library Locations
ii
130
135
137
141
143
144
146
147
148
148
151
152
153
155
161
164
166
170
176
178
178
178
181
182
183
183
183
184
185
186
188
189
190
193
194
195
201
201
202
207
208
208
209
210
File Caches and File Cache Locations

Virtualization Hosts
Virtual Machines
10 System Library Objects

Library Objects Overview
Image Files
Deployment Action Files
Hardware Profiles
Server Configurations
Application Configurations
Snapshots
Catalogs
Managing System Library Objects
211
214
215
217
218
219
220
220
220
222
223
223
223
11 Deploying and Managing Sessions
225
Prerequisites to Deployment
Scheduling a Session Reservation
Deploying a Session
Deploying a Session As a Service
Reservations Requiring Approval
Deploying a Session in Debug Mode
Deploying a Session in Persistent Mode
Deployment Actions
Managing Sessions
226
226
227
228
229
230
230
231
235
12 Access Control
Overview
Privileges
Privilege Sets
Groups
Users
Manually Changing Access to Objects
237
238
239
239
241
243
243
13 User Management
245
Organizations
Creating User Accounts
Creating Groups
Quotas
Personas
Authentication Methods
246
249
250
250
253
262
14 System Monitoring
265
Monitoring Log Files

Viewing Audit Log Information
System Notifications
Monitoring Components Using E-mail
SNMP Event Broadcasting
Monitoring Components Using Syslog
Monitoring Scripts
265
267
267
267
268
268
269
iii
15 Reports
Report Types
Managing Reports
Customizing Reports
Setting Access for Individual Reports
A Syslog Settings
Syslog Handler Settings
Syslog Facilities
Severity Levels
Setting Up Filters and Scripts
iv
271
272
274
274
275
277
277
278
279
281
Preface
Preface
The Quest Cloud Automation Platform Installation and Administration Guide provides information to
assist you with the process of installing and configuring a Cloud Automation Platform (CAP)
environment.
After you complete the installation, see the online Help for information about using the CAP web
interface to create, manage, and configure the Cloud Automation Platform users and objects.
Target Audience
The target audience for this book includes the individual responsible for installing the Cloud
Automation Platform and performing the initial configuration required to begin using the product on a
day-to-day basis. Typically, these users are system administrators. Additionally, Organization
Administrators who are responsible for creating new users and populating the library should read this
guide.
Release Notes
Before installing the product, review the Release Notes. Information about the Quest Cloud Automation
Platform, the QA/Test Solution, Demo Solution, and Training Solution are included in the Release
Notes. The Release Notes contain the most current information about the products and should be used
in conjunction with other Cloud Automation Platform documents.
About This Book

This book provides the information you need to install and configure Cloud Automation Platform
components during the initial deployment of an environment. It is not intended to provide a complete
description of the features and capabilities of the Cloud Automation Platform and web interface.
The Installation and Administration Guide consists of the following sections:
Chapter 1, Introduction, on page 1
Chapter 2, Before You Start, on page 9
Chapter 3, Product Installation, on page 41
Chapter 4, Remote Access, on page 73
Chapter 5, Advanced Networking, on page 129
Chapter 6, Configuration and Administration, on page 151
Chapter 7, Troubleshooting, on page 181
Chapter 8, Image Management, on page 189
Chapter 9, Physical and Network Resources, on page 207
Chapter 10, System Library Objects, on page 217
Chapter 11, Deploying and Managing Sessions, on page 225
Chapter 12, Access Control, on page 237
Chapter 13, User Management, on page 245
Chapter 14, System Monitoring, on page 265
Chapter 15, Reports, on page 271
Appendix 16, Syslog Settings, on page 277
Preface
Documentation
The following documentation is available in support of this release:
Quest Cloud Automation Platform Release Notes
Quest Cloud Automation Platform Installation and Administration Guide
Quest Cloud Automation Platform Data Dictionary
Quest Cloud Automation Platform Upgrade Documentation
Quest CAP Add-In for HP Quality Center Guide
Online Help for the Quest Cloud Automation Platform web interface
SOAP API .chm files
Contact Information
To contact Quest Customer Support, use the Support Web page available on our Web site: https://
support.quest.com/ContactSupport.aspx.
vi
Preface
Typeface Conventions
The following typeface conventions are used in this book:
Component
Convention
Window and dialog names
Title caps, default font
Emphasis
Italic
File or directory names
Courier
Examples, including code
Courier
UI commands within a procedure when a

specific action is taken
Bold
New terms
Bold italic
Typed user input
Bold Courier
Variables
<server_name>
Acronyms and Abbreviations

The following acronyms and abbreviations are used in this book:
Acronym or
Abbreviation
Definition
API
Application Programming Interface
CAP
Cloud Automation Platform
CD-ROM
Compact Disc Read Only Memory
CPU
Central Processing Unit
DNS
Domain Name System
EPU
Effective Processor Units
GB
Gigabyte
GUI
Graphical User Interface
GUID
Globally Unique Identifier
HBA
Host Bus Adapter
HTTP
Hypertext Transfer Protocol
ICA
Independent Computing Architecture
ICMP
Internet Control Message Protocol
IDE
Integrated Drive Electronics
vii
viii
Preface
Acronym or
Abbreviation
Definition
IIS
Internet Information Service
IP
Internet Protocol
LLP
Local Listening Proxy
MAC
Media Access Control
MDAC
Microsoft Data Access Components
MB
Megabytes
NAIL
Network Abstraction and Isolation Layer
NAT
Network Address Translation
NFS
Network File System
NIC
Network Interface Card
OS
Operating System
PSA
Path Signature Analysis
RAM
Random Access Memory
RSM
Remote Server Manager
RDP
Remote Desktop Protocol
SCSI
Small Computer System Interface
SE
Sales Engineer
SMTP
Simple Mail Transfer Protocol
SQL
Structured Query Language
SSL
Secure Socket Layer
SSPI
(Microsoft) Security Support Provider Interface
TCP/IP
Transmission Control Protocol/Internet Protocol
UI
User Interface
UNC
Universal Naming Convention
URA
URL
Uniform Resource Locator
VM
Virtual Machine
VNC
Virtual Network Control
VR
Virtual Resource
This chapter provides an overview of the Cloud Automation Platform architecture

and components.
1 Introduction
Introduction
For comprehensive information and procedural instructions for using the CAP web interface to
accomplish both administrative and end-user tasks, refer to the Cloud Automation Platform online Help
system. For an overview of the workflow and setup tasks to create a basic environment, see the Getting
Started section of the online Help system.
The following topics are discussed in this chapter:
Architecture Overview on page 2
Components and Solutions on page 3
The CAP Core on page 5
CAP Core Objects on page 6
Reporting Database on page 6
Operations Database on page 6
Solution Licensing on page 8
The method of installing the Cloud Automation Platform components varies depending on the type of
environment you have, your choices for storage volumes, and many other details. The following two
diagrams illustrate the common architecture layout for a VMware ESX environment and for a Microsoft
Hyper-V R2 environment. Many environments are heterogeneous, and contain both Hyper-V R2 and
ESX hosts, as well as physical computers hosting either image-based or externally provisioned server
configurations. The Cloud Automation Platform architecture is flexible and can accommodate a wide
range of environments.
The following installation scenario depicts an environment using VMware ESX virtualization hosts.
The CAP Core components, the CAP web interface, the QA/Test Solution, and the Demo Solution are
installed on three different servers. All of the platform components can be installed on a single server,
but as a best practice, Quest Software recommends at least installing the Agent Services component on
a separate server.
Figure 1 Example installation configuration with VMware ESX hosts
1 Introduction
Architecture Overview
1 Introduction
The following diagram illustrates a typical environment using Hyper-V R2 hosts, which requires the use
of a SAN (Storage Area Network) for the system Library.
Figure 2 Example installation configuration with Hyper-V R2 hosts
The use of the URA Gateway is optional; refer to Remote Access on page 73 for detailed information
about installing and configuring the Cloud Automation Platform remote access components.
Components and Solutions

The following components are essential to the Cloud Automation Platform environment:
CAP Core Typically installed on multiple virtual machines (VMs) or physical servers. Depending
on the size of the deployment, however, the CAP Core can be installed on a single VM or physical
server.
The CAP Core consists of the following pieces, which provide the capabilities required by all Cloud
Automation Platform applications:
Core services Provides the services and capabilities that enable the Cloud Automation
Platform applications to create and manage virtual and physical resources. Key services include
the control service, the reservation service, deployment service, and the engine service.
Agent Services Includes the following agent services:
Agent message forwarder Receives all agent responses and status data and delivers those
documents to the agent message processor.
Agent message processor Processes documents submitted by Cloud Automation Platform

agents, updates the operations database, and relays agent responses. This service is only
intended to be called by the agent message forwarder on behalf of agents.
Remote Server Manager (RSM) Manages remote virtualization hosts and library servers.
For more information about using the RSM, refer to Configuring Remotely Managed
Hosts on page 26.
Web Application Functions as the interface to the CAP Core. Through the CAP web interface,
the administrator can perform the tasks that are necessary to define and maintain the Cloud
Automation Platform environment, including the creation and maintenance of users,
organizations, virtual resources, and software images.
SOAP APIs Provides the capability to extend, integrate with, or externally automate the CAP
Core and, optionally, with the Training Solution.
Cloud Automation Platform Solutions The following solutions are available with Cloud
Automation Platform:
Note: The QA/Test Solution, Demo Solution, and Training solution are included in the Cloud
Automation Platform, and are automatically installed with the CAP Core. Users access both the
administrative functions of the CAP Core and the Solutions through the CAP web interface.
QA/Test Solution Automates test lab environments for software organizations. The QA/Test
Solution orchestrates the allocation, scheduling, provisioning, configuration, and
deprovisioning of test environments for developers and quality assurance (QA) engineers, as
well as testing of new configurations by information technology organizations (IT Operations).
By providing self-service capabilities to groups and individuals who desire access to automated
test lab environments, the QA/Test Solution enables software organizations to increase
repeatability in the test process while optimizing test lab resources, reducing development and
test cycles, increasing the productivity of developers and QA engineers, and eliminating errors.
Demo Solution Provides software-demonstration capabilities that result in the faster and more
reliable presentation of a product to potential customers. These enhancements, in turn, generate
additional leads and shorten sales cycles.
Training Solution Enables training organizations to reduce delivery costs, shorten cycles,
and increase reach by delivering live, hands-on, technical software training to anyone, anytime,
anywhere. When using the Training Solution, customers, partners, and employees experience
the full benefits of interacting with real training labs as part of instructor-led and self-paced
courses.
System library Contains a collection of such system resources as base images, ISO images, and
snapshots. The system library also includes the templates directory and snapshots directory in
which the various files are stored, and a DeploymentActions directory that stores deployment
action files. The file-storage device that you use as the system library must have enough capacity
to store many large files.
Operations database Houses the configuration and state information for all of the physical and
virtual resources. Created on an existing structured query language (SQL) server, the database also
stores information about users, their roles and privileges, and their authentication policies.
Reporting database Serves as a repository for historical data. Logically distinct from the
operations database, the reporting database can be installed either as an independent database on the
same server that the operations database is on, or on a different server altogether.
Cloud Automation Platform application server A physical server or VM on which the Cloud
Automation Platform web application or Cloud Automation Platform Solutions are installed. End
users and application administrators access these applications through a Web browser.
1 Introduction
1 Introduction
File cache Contains copies of images from the system library and allows multiple VMs to share
the same image. When an image changes in the system library, the updated image is sent to the file
cache upon the next deployment of the application configuration. Multiple caches are supported,
with each cache consisting of one or more file cache locations.
Virtualization host The computer on which VMs are created and their configuration files stored.
Physical Computer A computer that is managed by a provisioning system and is used by Cloud
Automation Platform to host deployed physical servers. Refer to the online Help for additional
information about using provisioned physical computers.
Quest CAP Agent Handles communication between Altiris Deployment Servers and the CAP
Core server. Quest CAP agents are installed on any supported Windows system that hosts an Altiris
Deployment Server and system library location or a file cache location with Altiris physical
machine images.
The CAP Core

The CAP Core provides the building blocks for the creation and deployment of sessions for Cloud
Automation Platform users. A session is a software environment that can be deployed on-demand for
demos, training, or testing purposes. Demo Solution, Training Solution, and QA/Test Solution users
access sessions for software demonstrations and evaluations, hands-on software training, or for software
testing.
The CAP Core automates the setup, provisioning, deployment, teardown, and re-deployment of
sessions. The CAP Core also provides access control and reports.
Before you begin using the Cloud Automation Platform, make sure that the required physical and
network resources have been created. Physical resources include virtualization hosts, possibly physical
provisioning servers, physical computers, and Active Directory computer accounts (AD-CAs).
Network resources include MAC addresses, IP addresses, DHCP network ranges, and VLAN IDs.
The CAP web interface is the graphical user interface to the product. After the required resources are in
place, you can use the CAP web interface to perform the tasks required to create, define, and maintain
the platform objects tailored to your virtual environments requirements.
In the CAP web interface, create the objects that comprise a session by creating objects in the system
library. The objects that display in the system library are the elements that build the server and software
for a session. It helps to think of the system library objects as recipes for sessions. A recipe, in the
traditional sense, contains a list of ingredients as well as a set of instructions. In the system library, the
objects required to create a session are the list of ingredients and the instructions for how each object
should be deployed and configured are included in the definition of the object.
To create a Session or Training Lab, create and maintain the following CAP Core objects:
Images An image is a virtualized representation of a computers disk drive.

You can add images that you have created in your own environment, or you can create your own
images using the CAP web interface. Either way, Quest recommends that you use the Cloud
Automation Platform image preparation process to prepare any images that will be used in the
Cloud Automation Platform environment.
Hardware profiles The hardware profile of each server configuration defines the RAM
requirements, the CPU cores, target deployment (physical or virtual), required computing capacity
(measured by Effective Processor Units, or EPUs) if any, and any constraints.
Server configurations All the information and image file references needed to create a fully
functioning server. Cloud Automation Platform supports both virtual server configurations and
physical server configurations.
Virtual server configurations are used to create VMs.
Physical server configurations are deployed to a physical computer to create deployed physical
servers.
Application configuration All the resources needed to create a single session. One or more server
configurations are grouped into an application configuration.
Session An application configuration that has any additional collateral or material attached to it.
A session is what you deploy to create and access the virtual environment.
After the physical and network resources are in place and the platform objects are ready for deployment,
use the CAP web interface to make sessions available to users. Additional administrator tasks include
creating and maintaining user accounts and organizations, running reports, system monitoring, and
managing images, physical and network resources, and the system library.
Each remaining chapter in this manual provides more detail about the CAP Core objects and the
administrators role with those objects.
Reporting Database
The reporting database is available to all platform services. Its primary purpose is to save historical data.
The reporting database acts as a data warehouse and can be used with Cloud Automation Platformprovided report generators or with third-party reporting tools. For more information, see Reports on
page 271.
Operations Database
The operations database contains the configuration and state information for physical and virtual
resources. It also stores information about users, their privilege sets and privileges, and their
1 Introduction
CAP Core Objects
1 Introduction
authentication policies. The operations database is the primary source of data accessed by the Cloud
Automation Platform application program interface (API).
Solution licensing controls the user experience in the CAP web interface. Users will be able to access
the features and functionality of the Solutions for which they have a valid license. The solution-level
licensing provides several features:
Limit access to groups of workflows, personas and functionality that are grouped together as
Solutions.
Monitor the number of concurrent user logins per solution (determined by assigned persona).
Monitor the number of host machines/CPU sockets that can be pooled.
Monitor the total amount of RAM that can be pooled.
Provide a built-in license expiration for installations used for evaluation purposes.
There are three types of licenses: CAP Core, Demo Solution, and Training Solution. The QA/Test
Solution is licensed by the CAP Core license. The optional limits on pooled RAM and CPUs will be
part of the CAP Core license. The RAM will be licensed in whole GB units.
The optional limits on the concurrent logins for Users using Personas associated with a given solution
are part of the Solution licenses. The CAP Core license, which includes the QA/Test Solution, always
allows unlimited concurrent users. If limits are exceeded, usage is not interrupted. However, users are
prompted to enter a valid license when using the CAP web interface.
1 Introduction
Solution Licensing
This chapter discusses the system requirements and other objectives and conditions
that must be considered while planning an installation.
2 Before You Start
Before You Start
The following sections address these issues and provide instructions for ensuring that you are fully
prepared to complete a Cloud Automation Platform installation.
Determining the Scope of Your Installation on page 10
System Requirements on page 11
Additional Considerations on page 18
Network Communication on page 22
Configuring IIS V. 7 on Windows 2008 R2 on page 25
Configuring Remotely Managed Hosts on page 26
About Partner Extensions on page 33
External Provisioning with HP Server Automation on page 34
Security And Encryption on page 36
Choosing a Windows Account for the Agent Service (Altiris) on page 38
Using the vcsadmin Utility on page 38
Because the Cloud Automation Platform is highly scalable, the components and Solutions can be
installed on a single server or distributed across multiple servers. If you are installing Cloud Automation
Platform within the confines of a relatively small environment, for example, you can install the
complete Cloud Automation Platform on the same server that hosts your databases and system library.
If your installation is slated for a larger environment, installing some of the CAP Core components on
one server and the remaining components on a second server can help you maximize the efficiency of
your solution. Databases, Solutions, and the system library can also be set up on separate servers as
needed.
The following criteria can be useful when determining which approach to use:
10
The number of sessions to be deployed and serviced. A session is a complete software environment
(operating system, required software, etc.) that can be deployed on demand for demonstration,
testing, or training purposes. Users of Cloud Automation Platform Solutions can access sessions for
software demonstrations and evaluations, software testing, and hands-on software training.
The diversity of your lab images, including the number of different images, the size and content of
each image, and their hosting requirements.
Your reporting needs, as determined by the amount and type of data you expect to save, as well as
the number of reports you expect to generate.
2 Before You Start
Determining the Scope of Your Installation
In the typical installation scenario, the Cloud Automation Platform components are divided on multiple
servers, with the database on a separate database server.
For diagrams of typical Cloud Automation Platform installations, refer to Architecture Overview on
page 2.
System Requirements
The hardware and software requirements are detailed in the following section.
General Considerations
Review the following general information:
The disk space required by the library location depends upon the number and size of the images
(labs, demos, classes) that are stored.
Using NAIL Server in advanced mode requires at least two (2) 1 GB Ethernet cards in all
virtualization hosts. For more information about NAIL Server in advanced mode, see Configuring
NAIL Server Advanced Mode on page 137. For instructions, refer to the CAP web interfaces
online Help.
The Active X controls used by Cloud Automation Platform require 32-bit Internet Explorer (default
browser) when running on 64-bit Windows (x64) platforms. Both 32-bit Internet Explorer and 64bit Internet Explorer are installed with Windows x64. The combination of Firefox 3.x and Sun Java
J2SE 1.6 also works on Windows x64.
The Platform server and all virtualization hosts should reside on the same Local Area Network
(LAN).
(Dashboard only) If you want to use the HTTPS (SSL) protocol to access the application server
(Web Appplications component), you will need to follow these steps before accessing the
Dashboard:
First, enable SSL for the web site
Then, edit the web.config file (in <install_dir>/Platform/Web) to remove comments

around the all HTTPS endpoint entries.
To locate HTTPS endpoints that are commented out, look for the following text:
<!-- NOTE: Uncomment this to enable the HTTPS endpoint(SSL must be
enabled for the web site first)
Remove the above line and the end comment tag to enable SSL.
Save the web.config file and restart the browser.
11
2 Before You Start
Installation Scenario
Microsoft IIS version 7, the web server on Microsoft Windows Server 2008 R2, requires additional
configuration prior to installing Cloud Automation Platform. Refer to Configuring IIS V. 7 on
Windows 2008 R2 on page 25 for detailed instructions.
System Requirements
Review the following system requirements for a typical installation scenario. See Figure 1 and Figure
2 on page 3 for diagrams of two typical configurations.
Note: Installation of the Cloud Automation Platform components requires that both Microsoft IIS and
.NET Framework 3.5 SP1 are installed on the CAP Core server before installing the CAP Core.
Be aware that IIS must be installed before .NET Framework on the CAP Core server. See the
troubleshooting topic Install Microsoft IIS Before .NET Framework on page 185 if IIS was
not installed first.
Computer
CAP Core
server
12
Cloud
Automation
Platform
Components
General requirements for the four
main components
of the CAP Core
server:
-Core Services
-Agent Services
-Web Applications
-SOAP API.
System Requirements
Physical server or VM with the following specifications:

English version of one of the following operating
systems:
Microsoft Windows Server 2008 SP1 (Standard,
Enterprise, Datacenter )
Microsoft Windows Server 2008 R2 (Standard,
Microsoft Windows Server 2003 R2 SP2
(Standard, Enterprise, Web Editions, or x64)
Enterprise, Web), x86 or x64 editions supported
2 GB RAM
Free disk space:
10 GB free disk space if CAP-supplied images
are stored on a network attached storage
(NAS) device
40 GB free disk space if images are stored on a
local disk
Microsoft .NET Framework 3.5 SP1
Microsoft Internet Information Services (IIS) 6.x, 7.x
ASP.NET Application Server installed and enabled
Note: (Windows 2003 only) IIS must be installed
before .NET Framework.
2 Before You Start
Library
Server
System Library
(all computers,
excluding Altiris
DS, that host the
Library must use
the Remote
Server Manager to
manage the
library, and so
must be registered
with the Cloud
Automation Platform.)
2 Before You Start
Computer
Cloud
Automation
Platform
Components
System Requirements
ESX
VMware ESX 3.5 Update 4, ESXi 3.5 Update 5, ESX
4.0 Update 1, ESXi 4.0 Update 1, ESX 4.1, ESXi 4.1
Library locations storage volume required to be on
NFS or VMFS-3 volumes (for locations larger than 2 TB,

NFS is strongly recommended)
Hyper-V
Windows Server 2008 R2 (required for Hyper-V and
Cluster Shared Volume library content)

Library locations storage volume required on Cluster
Shared Volume (CSV) on a SAN
Altiris Deployment Solution

Windows Server 2003 R2 SP2, x86 or x64
Windows Server 2008 SP1 or SP2, x86 or x64
Quest CAP Agent installed
Common
500 GB free disk space minimum (The amount of
required disk space depends on the size of the disk
images.)
Library Server computer registered with Cloud
Automation Platform (excluding Altiris).
Database
server
Operational and
Reporting database
One of the following databases:

Microsoft SQL Server 2005, SP2
Microsoft SQL Server 2005 Express
Microsoft SQL Server 2005 x64
Microsoft SQL Server 2005 Express x64
Microsoft SQL Server 2008 SP1
Microsoft SQL Server 2008 R2
Mixed Mode Authentication must be enabled
Remote connections using TCP/IP must be enabled
13
14
System Requirements
Application
server
In a distributed
installation, the
Web Applications
component can be
installed on a
different
computer than the
other Platform
components.The
Application server
hosts the
Platform web
interface and any
additional
web interface
installations.
Physical server or VM with the following specifications:

English version of one of the following operating
systems:
Microsoft Windows Server 2008 SP1(Standard,
Microsoft Windows Server 2008 R2
(Standard, Enterprise, Web), or x64
2 GB RAM minimum, 4 GB recommended
6 GB free space
Microsoft Internet Information Services (IIS) 6.x, 7.x
ASP.NET Application Server installed and enabled
Notes:
(Windows 2003 only) IIS must be installed
before .NET Framework.
Do not install on a computer that uses a WAN or
the Internet to connect to the Platform Server.
Virtualization Host
(content host
for VMs)
This is the server,

running a VMware
or Microsoft virtualization product,
on which the
Cloud Automation
Platform manages the virtual
resources. A typical environment
consists of multiple host servers
whose aggregate
capacity is pooled
and allocated.
One of the following virtualization products:

VMware ESX 3.5 Update 5, ESXi 3 Update 5,
ESX 4.0 Update 1, ESXi 4.0 Update 1, ESX
4.1, ESXi 4.1
Microsoft Windows 2008 R2 with Hyper-V
Server (Must use Clustered Shared Volume
configuration.)
NOTE: All virtualization platforms (except ESX 3.5)
require x64 architecture with Intel VT-x/AMD-V support.
4 GB RAM (supports approximately 6 virtual
machines with 512 MB RAM each)
10 GB free disk space (library provisioning) or 40 GB
(dedicated cache location)
Host must be registered with Remote Server
Manager (RSM).
(ESX and ESXi only) SSH must be enabled for the
user account with which the ESX host is registered with
the Remote Server Manager.
All VMware ESX images that will run on ESX 3.5
must be in the double-file, hardware version 4 VMDK
format. For ESX 4 hosts, the hardware version can be 4
or 7. See Converting Hardware Versions for .vmdk
Files on page 201 for instructions to use a vcsadmin
script to convert .vmdk files to a later level file format.
2 Before You Start
Computer
Cloud
Automation
Platform
Components
Guest VM
(If your VM
image does
not contain a
Cloud Automation Platform Guest
Agent, these
requirements
are not applicable.)
Cloud Automation
Platform Guest
Agent
These are the
requirements of
the guest VM in
order for the
Guest Agent to
function properly.
2 Before You Start
Computer
Cloud
Automation
Platform
Components
System Requirements
One of the following 32-bit operating systems:

Windows Server 2003 R2 SP2, Windows XP,
Windows 2008 SP1, or Windows Vista SP1
Business edition or higher, Windows Server
2008 R2, Windows 7, Professional and higher
Red Hat Enterprise Linux Server (RHEL) 5.x
Novell SUSE Enterprise Linux Server 10.3 or
11.0
OR
One of the following 64-bit operating systems:
Windows XP 64 or Windows Server 2003 R2
SP2 x64
Red Hat Enterprise Linux Server (RHEL) 5.x
Novell SUSE Enterprise Linux Server 11.0 and
above
Microsoft Framework 2.0 or 3.5 SP1 (Windows only)
Windows Server 2008 Hyper-V R2 Hosts

only:
Windows XP SP3, 32-bit only
Windows Vista SP1 Business edition or higher, x86
or x64
Microsoft Windows Server 2003 R2 (Standard,

Enterprise, Web Editions, or x64)
Microsoft Windows Server 2003 (Standard,

Windows Server 2008, x86 or x64

Windows Server 2008 R2, x64 only
Note: VMs created from an image prepped with the

CAP Image Tool include a Guest Agent.
Active Directory Server
One of the following operating systems:

Microsoft Windows Server 2008 (Standard,
Microsoft Windows Server 2008 SP1
Microsoft Windows Server 2003 R2 SP2 (Standard,
Enterprise, Web) x86 or x64 editions supported
15
16
Client computer
(Application
users)
none
Utility Host
A utility host is any

server running
supported virtualization software
that also supports
NAIL Server, and
is used by HyperV hosts for network translation
services.
This is the computer used by IT

operations and lab
management personnel to administer the application
and by end-users
to request and
access lab environments
System Requirements
English version of one of the following operating systems:

Microsoft Windows XP SP3
Microsoft Windows Vista SP1 Business edition or
higher (no console access with Vista)
Microsoft Windows 7 (no console access on ESX
3.5, ESX 4 allows console access)
SUSE Linux Enterprise Server 10.2 and 11
Apple Mac OS X 10.5 or 10.6 with Firefox browser;
remote access methods supported are Citrix ICA
and Java RDP.
One of the following web browsers:
Microsoft Internet Explorer 7.0 or 8.0 with
cookies enabled (only 32-bit version of IE)
Mozilla Firefox 3.5 or 3.6 with cookies enabled
(Optional) The installation of Microsoft Silverlight 3
enables the Infrastructure Dashboard, a visual
management view of the environment.
(Optional) PowerShell 2.0 is required for use of the
CAP CLI Client component.
Note: Web browser must be configured for either:
Microsoft ActiveX controls
Sun Java Plug-in JRE version 1.6 on Windows
platforms
Sun Java Plug-in JRE version 1.6 for Mozilla
Firefox on Linux
Apple Java for Mac OS X version 1.6 for Mozilla
Firefox
VMware ESX utility host:
VMware ESX 3.5 Update 5, ESXi 3 Update 5, ESX
4.0 Update 1, ESXi 4.0 Update 1, ESX 4.1 , ESXi 4.1
(Foundation, Standard, or Enterprise)
ESX server must be registered with RSM (Remote
Server Manager).
SSH must be enabled for the user account with
which the ESX host is registered with the Remote
Server
Manager.
Advanced Mode for the NAIL server must be
implemented
2 Before You Start
Computer
Cloud
Automation
Platform
Components
Partner
Extension
System Requirements
Altiris Deployment Server
Altiris Deployment server 6.8 SP2, 6.9, 6.9 SP1, or 6.9
2 Before You Start
Partner Extension System Requirements
SP2
Network communication: Use either a static IP address

in the .img file or use the legacy NAIL Driver.
The Altiris Deployment server agent must be installed on

the target server against which an Altiris Job is run.
Cloud Automation Platform Administrators must have full

access to all Altiris Jobs and to the Altiris Deployment
Server.
The Cloud Automation Platform Agent must be installed.
HP Server Automation
HP Server Automation 7.5

A Cloud Automation Platform guest agent must be
installed in all images that will run HP Software Policies as
deployment actions. However, a guest agent is not required
nor supported for external provisioning (OS or physical
provisioning) with HP SA.
The server configurations network adapters cannot use
NAIL 3 network adapters; the adapter must be set to either
DHCP or static.
If your environment uses both isolated networks and
physical computers managed by HP SA, you must configure
network switch automation. See Using Network Switch
Automation on page 143.
HP Network Automation 7.5 (network switch
automation): supported physical switches are Cisco IOS
(e.g. 3750) and Cisco Catalyst OS (e.g. 2948). Support for
other switch types can be provided by Quest, as long as
switch is supported by HP NA 7.5.
SPARC architecture is not supported.
Note: In order to be able to run administrative-level commands via the Remote Shell, the user with which the HP SA
core was registered must have the "Run Command On
Server" privilege with sufficient scope, as both the "root" user
and the "Administrator" user (root for Linux/UNIX systems,
and Administrator for Windows).
VMware Vcenter
VMware vCenter 2.5 Update 5, VMware vCenter 4.0

Update 1, vCenter 4.1
Network communication: Static IP Address in all VMs
For more information regarding partner integrations in Cloud Automation Platform, see About Partner
Extensions on page 33. For detailed information about how to register partner extensions (provisioning
and automation systems) in the CAP web interface, refer to the online Help.
17
Depending on the configuration of your network and the needs of your customers, the following
variables can also affect how you set up the Cloud Automation Platform environment:
Whether you anticipate any remote access requirements
Whether you intend to implement a file cache system to help maximize network efficiency
Whether you intend to use a VMFS volume on a SAN (storage area network) for a library location
Whether you have any address translation needs
The following sections examine these variables in more detail and provide the information necessary
for you to address any potential challenges.
Remote Access
To address your potential remote access needs, Cloud Automation Platform provides the following
solutions:
Universal remote access (URA) Enables communication from a remote computer to a Cloud
Automation Platform VM located behind a firewall.
Classroom readiness test (CRT) Measures a networks bandwidth and latency and compares them
with established ranges to determine whether they are appropriate for your classroom needs.
Web Browser and Connectivity Test, or the User Readiness Test (URT) Used in conjunction with
the Demo, Training, and QA/Test Solutions to determine if a remote users computer and the
computers current location meet the requirements to successfully connect to a Cloud Automation
Platform VM.
These solutions are described in greater detail in Chapter 4, Remote Access, on page 73. To utilize
URA, you must install a URA gateway. Similarly, to take advantage of CRT, you must install a CRT
server.
Note: The URA gateway and CRT server must not be installed on the same machine.
For more information about the system requirements for the URA gateway see Installing and
Configuring the URA Gateway Server on page 94.
For more information about the system requirements for the CRT server, see System Requirements
on page 11.
18
2 Before You Start
Images in Hyper-V environments are provisioned to destination VMs from Cluster Shared Volumes
(CSV) on the Storage Area Network (SAN) server. For more information, see Using Clustered Shared
Volumes for Hyper-V R2 Hosts on page 159.
VMware ESX hosts can access images directly from a system library when the system library server
supports NFS or VMFS access protocols. See Using NFS In a Network-Attached Storage
Configuration on page 157 or Using VMWare VMFS in a SAN-based Configuration on page 155.
For image provisioning from a system library to be successful, the following conditions must be met:
All Windows system libraries must reside within the same Windows domain.
The agent that manages a Windows system library cannot run as Local System account. Instead,
it must run as a domain user in the machines Administrators group.
ESX hosts that use a library location on a SAN VMFS volume must be configured before installing
Cloud Automation Platform. See Configuring the ESX Host and SAN Server on page 156.
When a session is deployed under these conditions, the VM uses images that remain in the system
library location. Files are not copied to the virtualization host, which reduces the time required to deploy
sessions.
Situations exist, however, when provisioning from the system library is not optimal or possible. For
instance, a very large number of VMs with heavy usage can cause excessive load on the library server.
For these situations, Cloud Automation Platform uses file caches and file cache locations. A file cache
location describes any physical location on a server to which an image and its related files are copied.
If your environment requires a large number of simultaneously accessible VMs, file cache locations
provide load balancing across multiple servers.
Whenever an application configuration is deployed, any file that is part of the server configuration,
including the .vhd, .vmdk, .img, and .iso files, is copied to a file cache location and attached to the
appropriate VM or VMs. Upon termination of the application configuration session, the image and all
of its related files remain in the file cache location, where they can be attached to other VMs during
future deployments.
Cloud Automation Platform supports the following types of file cache locations:
Dedicated file cache locations are created on each VM host server. Dedicated file cache locations
are supported by Hyper-V and VMware ESX.
Note: Hyper-V hosts must use a Cluster Shared Volume (CSV) on a SAN for library or file cache
location. In addition, all VM home directories must be in a local directory. No UNC paths or
CIFS can be used.
Shared file cache locations are accessible by all the virtualization hosts in a specified resource pool.
For VMware ESX, the shared cache locations can either use NFS and VMFS. See Using NFS In a
Network-Attached Storage Configuration on page 157 or Using VMWare VMFS in a SAN-based
19
2 Before You Start
Image Provisioning and File Cache Locations
With shared file cache locations, you have the option of setting up cache locations that are all
managed by an existing Quest CAP Agent on another server. Regardless of whether your shared
cache locations are remote or local, the Hyper-V hosts and Windows system libraries must reside
within the same Windows domain, and the managing agent must run as a domain user in the
Administrators group.
When planning the optimal solution for your network configuration, it is important to remember the
following points:
Each VM must have direct read/write access to a file cache location.
A single physical host server can support multiple file cache locations, provided the locations exist
on different volumes.
The size of a shared file cache location is configurable. If you do not specify a size, the entire disk
is used.
File cache locations can be set up on servers that are on remote servers accessible by a either a managed
server or by the Remote Server Manager. If you define more than one shared cache location, the system
determines which location to use during a deployment by identifying the following criteria:
a location that already has the files cached
a location that has enough space (without deleting any existing files)
a location with the most space that has unused files that can be purged to make space
If the required image exists in a cache location, then that cache location is used. If the image is not
currently cached it is copied to the location with the most available space, purging unused files if
necessary to make space for the new images
The online help provides detailed instructions for creating file cache locations.
Address Translation and Virtual Networking

Note: Refer to Networking Overview on page 130 for detailed information about Cloud
Automation Platform networking, including typical network topologies, configuring the NAIL
Server, using VLAN-isolated DHCP networks, and NAIL troubleshooting details.
The repeated cloning of a small number of VMs provides a fast, efficient method to create a large pool
of identical VMs. In a Cloud Automation Platform environment, many of the VMs that represent or
comprise viable application configurations are clones of one or more original VMs.
Unfortunately, cloned VMs share the following identifiers with the original VM as well as with each
other:
20
Machine name Duplicate machine names cause conflicts with network shares. For example, an
OS like Windows 2000 or Windows 2003 disables a clones network connection when it detects a
2 Before You Start
Configuration on page 155. Also refer to the CAP web interface online Help topic Adding a
Shared File Cache Location.
Security identifier (SID) Redundant SIDs generate authentication issues. Although SIDs can be
changed, the process is a time-consuming effort that requires a system restart for each VM. Further,
changing a VMs SID can result in software problems that affect licensing codes, Windows
authentication, Windows Shares, and IIS Services.
Static IP address The duplication of IP addresses, each of which must be unique to every VM on
a network, renders the original VM and all of its clones incapable of communicating over the same
network. Although an administrator can change the IP address of each VM, this change can also
disrupt Web services, databases, special protocol drivers, firewall rules, tuned applications, and
other servers that still use the previous IP address.
The Cloud Automation Platform solves the problem of duplicate IP addresses by utilizing a network
abstraction and isolation layer (NAIL). If the necessary components are installed and configured, the
NAIL Server is created automatically when the virtualization hosts are pooled.
The appropriate IP addresses and MAC addresses are configured using the CAP web interface.
Note: Be aware that the IP configuration (including the subnet mask and gateway) that is defined
within the image must match the subnet mask defined in the server configuration that you create
in the CAP web interface.
As shown in Figure 1, NAIL Server uses network address translation (NAT) to provide a unique IP
address for each VM on a network.
Figure 1 Cloned VMs with Unique External IP Addresses
21
2 Before You Start
duplicate machine name. Changing the machine name of each VM is a time-consuming effort that
requires a restart of each VM. Additionally, changing a machine name can break licensing codes,
configuration files, registry entries, and certificates.
Review the following section for information about the various types of network resources that you will
need to create. Additionally, see the matrix of ports on page 24 for a list of port numbers that Cloud
Automation Platform requires for communication between the CAP Core server and other components.
Network Requirements
You will need to define network resources for the application configurations that you want to deploy.
The appropriate IP addresses, MAC addresses, DHCP networks, and VLAN IDs are defined using the
CAP web interface. Refer to the online Help for detailed instructions to create network resources.
Quest recommends that you verify the accuracy of all values that you enter. A small error when entering
a range of addresses can result in the creation of thousands of unwanted address records in the Cloud
Automation Platform database.
Resource
MAC
Address
Ranges
IP Address
Ranges
Description
Requirements
This is the most widely used of

the network resources because
every VM NIC (network interface
card) will consume an ethernet
MAC address while the VM is
deployed, regardless of how the
interface is configured within the
VM guest operating system, and
regardless of whether multiple
clones of the VM are simultaneously deployed.
Values should fall within the VMware
NAIL uses IP address resources

to prevent conflicts and provide
a unique IP address for each
VM whose network interfaces
are configured with static IP
addresses within the VM guest
operating systems.
These IP addresses cannot overlap with

addresses assigned by any DHCP server.
Plan to dedicate one additional IP address
per VM host, plus one for each VM per test
configuration that will be configured for NAIL
cloning, up to the maximum number of concurrent VMs across all VM hosts. The size
and values of this range can be changed at
any time.
Organizationally Unique Identifier (OUI)

range of 00:50:56:00:00:0000:50:56:3F:FF:FF.
The size and values of this range can be
changed at any time.
Plan to use at least one MAC address for
each VM per test configuration, up to the
maximum number of concurrent VMs across
all VM hosts.
Note: Consult your network administrator

to determine a range of IP addresses valid
for your local network that can be dedicated to your installation.
22
2 Before You Start
Network Communication
Description
Requirements
VLAN ID
Ranges
NAIL also uses a virtual LAN

(VLAN) for VMs that require
grouping, as is the case when
multiple server configurations
comprise a single application
configuration. NAIL Server uses
IEEE 802.1q VLANs to isolate
application configurations from
one another and prevent duplicate host name or IP address
errors while simultaneously
deploying clones of VMs.
You must use IDs within the range of 2 -
For physical and virtual servers

that require both network isolation and the use of DHCP, create one or more DHCP network
ranges. Externally-provisioned
servers that rely on the PXE network boot process and are
included in multi-server deployments can use isolated DHCP
networks.
Two configurations support VLAN-isolated

DHCP networks:
OSPF (Open Shortest Path First): this
widely used protocol must be enabled on the
physical switch that is used to provide
routing for external users to the virtualization
hosts. Additionally, Cloud Automation
Platform requires credentials on the OSPF
routers.
If OSPF cannot be used in your
environment, the physical switch on the
broadcast network can be set to provide
DHCP addressing services. For this
scenario, NAIL Server must use advanced
mode.
DHCP
Network
Range
For details about using VLANisolated DHCP networks, see

Using VLAN-isolated DHCP
Networks on page 141.
2 Before You Start
Resource
4095, inclusive.
If you are implementing NAIL Server in

the advanced mode, you should work with
your network administrator to select the
appropriate network adapters, switches, and
VLAN IDs that are compatible with your
physical network environment.
As a general guideline, plan for 1-2
VLAN IDs per concurrent test configuration,
depending on the complexity of the test
configuration. The VLAN ID range selected
should be dedicated for use by the Cloud
Automation Platform.
23
The following table lists the ports or port ranges required by Cloud Automation Platform. All ports are
TCP unless otherwise specified. Ping is open in some cases to facilitate connectivity testing, not for
server communications. This matrix does not include Windows networking ports.
To Platform
To
DBs
To App
To Lib
To
Hosts
To VMs
To
URA
GW
Servera
To Syslog
To
To CRT
LDAP Server
From
Platform
server
29951433
2999
(includes
RSM)
1024-4999 4277
>32767
ICMP Ping
4277
22 (for
SSH)
4277
ICMP Ping
None UDP
514
389
None
From
DBs
None
N/A
None
None
None
None
None None
None
None
From
App
2995-
1433
N/A
4277
4277
10244999
>32767
None
None UDP
514
389
None
1024-4999
>32767
None None
None
None
2999
80/443
ICMP
Ping
From
Lib
80/443
None
80/443
N/A
From
Hosts
80/443
None
80/443
1024N/A
4999
>32767
None
None UDP
514
None
None
From
VMs
80/443
None
None
None
None
N/A
None None
None
None
None
None
None
5900
902
3389
(RDP)
5901
(VNC)
1494
(Citrix)
N/A
None
9999
(default)
3389
(requires
port
address
translation)
From
2995URAGW 2999
10244999
>32767
22 (SSH)
None
From
Syslog
None
None
None
None
None
None
None N/A
None
None
From
LDAP
None
None
None
None
None
None
None None
N/A
None
a. The Web Application component uses port 2995. The Remote Server Manager (RSM), part of Agent
Services, uses port 2996. Service Host, in the Services Container, uses port 2997. The EngineService,
part of Core Services, uses port 2998. Control Service, part of Core Services, uses port 2999.
b. An ephemeral port is opened briefly during installation.
24
2 Before You Start
Ports Used by Cloud Automation Platform
If your environment will use Windows Server 2008 R2, install and configure Microsoft IIS version 7
web server prior to installing the Web Application component. IIS version 7 is the default web server
on Windows Server 2008 R2.
Note: Use the following instructions to install and configure IIS version 7 on any Windows Server
2008 R2 on which you will install any of the four Platform components. Follow the same
instructions for any servers on which you install the Web Applications component.
To install and configure IIS version 7 for the Cloud Automation Platform environment, perform the
following steps:
1. Open the Server Manager console.
2. In the left pane, click Roles and then click the Add Roles link in the window on the right.
The Add Roles Wizard appears.
A. On the Before You Begin page, click Next.
B. On the Select Server Roles page, select the Web Server (IIS) role and then click Next.
C. On the Web Server (IIS) page, click Next.
D. On the Select Role Services page, select Application Development and then click Next.
E. On the Confirm Installation Selections page, click Install.
The Installation Progress page appears.
F. When the Installation Results page appears, review the information and then click Close.
3. In the left pane of the Server Manager, click Features and then click the Add Features link in the
window on the right.
The Add Features Wizard appears.
A. On the Select Features page, select .NET Framework 3.5.1 Features.
B. Dismiss the popup by clicking Add Required Features.
C. Expand .NET Framework 3.5.1 Features and verify that the WCF Activation check box is
selected.
D. On the Select Features page, click Next.
E. On the Confirm Installation Selections page, click Install.
The Installation Progress page appears.
F. When the Installation Results page appears, click Close.
25
2 Before You Start
Configuring IIS V. 7 on Windows 2008 R2
5. In the left pane, expand the node with the computer's name, then expand the Sites node, and then
select the Default Web Site.
6. Double-click the Handler Mappings icon in the pane on the right.
7. In the list of application mappings, verify that each ISAP-2.0.svc file (look under the Path
column for the .svc extension) has an entry of IsapiModule in the Handler column. Alternatively,
right-click on each .svc file and select Edit..., and then verify that the file is mapped to the
aspnet_isapi.dll.
If there are no entries for ISAP-2.0.svc files, you will need to add them. If you are using any 64bit computers to host IIS, you will need to also add an entry for the 64-bit framework.
To add the .svc files, perform the following steps:
A. Click Add Script Map.
B. In the Request path field, enter *.svc.
C. In the Executable field, navigate to one of the following directories and select the
aspnet_isapi.dll:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
(for 64-bit computers)
C:\Windows\Microsoft.NET\Framework\v2.0.50727
(for 32-bit computers)
Configuring Remotely Managed Hosts

The Remote Server Manager (RSM), installed with the Agent Services component of the Platform,
manages all virtualization hosts and library servers. The RSM is used to remotely manage the following
types of hosts:
Microsoft Windows Server 2008 Hyper-V R2 hosts
VMware ESX Server 3.5
VMware ESXi 3.5
VMware ESX Server 4.0
VMware ESXi 4.0
The use of RSM not only greatly reduces installation and upgrade efforts, it also provides performance
enhancements and a simplified architecture.
For important information about configuring the hosts before creating your Cloud Automation Platform
environment, see:
26
2 Before You Start
4. Open a command prompt window and type start inetmgr to open the Internet Information
Services (IIS) MMC snap-in.
ESX Hosts on page 27
Hyper-V R2 Hosts on page 28
2 Before You Start
Note: For information about the supported library locations and file cache locations, and how to
configure hosts for file access and library management, refer to Configuring Storage and
Shared Access on page 155.
ESX Hosts
Review the following sections if your environment includes VMware ESX hosts.
Configuring ESX Hosts

To configure the Cloud Automation Platform environment for using remotely managed ESX 3.5, ESX
4.0, and ESXi hosts, follow these procedures before registering the hosts in the CAP web interface:
Enable SSH for the user account of the ESX host. The authentication credentials, used when
registering the ESX host to be managed by RSM, must have remote SSH access enabled
before registering the host.
Verify that the user account on the ESX host has the same privileges as a local administrator.
Create a storage location for the images and files. Cloud Automation Platform requires that all
images are in either the Hardware Version 4 or version 7 double-file VMDK format. See
Converting Hardware Versions for .vmdk Files on page 201 for instructions to use a vcsadmin
script to convert .vmdk files to a later version file format.
27
Configure a default network for NAIL Server. If you are using NAIL Server in advanced mode,
configure both a trunked network and a default network. See Configuring NAIL Server Advanced
Mode on page 137.
(ESX 3.5 and 4.0 only, not ESXi) Quest Software recommends the following Best Practice. Using
the VMware Infrastructure Client that is installed on the ESX host, configure the amount of memory
that is allocated to the ESX service console to the maximum amount, 800 MBs. The RSM interacts
with the service console to perform tasks for the Cloud Automation Platform environment. Failing
to set the memory allocation to 800 MB will cause the service console to perform poorly.
Hyper-V R2 Hosts
Review the following sections if your environment includes Hyper-V R2 hosts.
Considerations
Review the following considerations when using the Remote Server Manager and Hyper-V R2 hosts:
28
No firewalls can exist between the computer on which the Agent Services is installed and the
Hyper-V R2 host(s).
For successful promotion of snapshots from Hyper-V hosts, constrained delegation must be enabled
for the user account that the Remote Server Manager uses to remotely manage the Hyper-V host.
The RSM is configured with only one user account that it uses to manage all Hyper-V R2 hosts. The
Hyper-V host must be able to open virtual hard disks (.vhd files) on the CIFS server (i.e., in the
system library on a NAS device) for exclusive read/write access, and because the Remote Server
Manager is delegating the credentials to open the virtual hard disk file on the Hyper-V host
accessing the CIFS server, that delegation must be authorized. For the authorization to occur, the
user account of the RSM and the Computer Name of the CIFS server must both be in a common
Active Directory server where constrained delegation of the RSM user to access the CIFS share
through third-party hosts (Hyper-V) is allowed.
In order for Hyper-V to host VMs with NAIL Server defined as the Ethernet Device type, a NAIL
Server on another virtualization host or on a utility host must be used. See Using NAIL Server with
Hyper-V R2 Hosts (Utility Hosts) on page 31 for more information about using utility hosts.
The password rules for the user account must be configured to never expire.
Hyper-V R2 hosts and the Remote Server Manager should not be isolated by a network address
translation (NAT) layer. See Using NAIL Server with Hyper-V R2 Hosts (Utility Hosts) on page
31 for information about using network address translation with Hyper-V hosts.
DHCP addressing should not be used by Hyper-V R2 hosts unless it is an infinite DHCP
reservation.
2 Before You Start
Note: If the host will be integrated with a VMware vCenter environment, you must define the storage
locations and register the host with vCenter before you register the host with the CAP web
interface. After installation is complete, refer to the online Help for additional prerequisites and
information about registering ESX hosts for vCenter integration.
The Hyper-V R2 host must have 64-bit architecture and have a DVD drive.
Configuring Hyper-V R2 Hosts

Note: If your environment requires the use of the NAIL Server for network address translation (NAT)
for VMs on a Hyper-V R2 host, refer to Using NAIL Server with Hyper-V R2 Hosts (Utility
Hosts) on page 31.
To configure the environment for using remotely managed Hyper-V R2 hosts, follow these steps:
1. Before installing Cloud Automation Platform, create a domain user account for the specific use of
communication between the Remote Server Manager and the Hyper-V hosts.
The domain user account must be a member of the Administrators group for the server with Agent
Services installed and on each Hyper-V host that is going to be managed remotely by the Remote
Server Manager Additionally, the domain user account should have full privileges to the Windows
Administrative shares (C$, D$, IPC$) and the ability to access the Hyper-V host file system with
full read/write access.
The following computers must all be in the same domain:
The computer on which you install the platform Agent Services (which includes the Remote
Server Manager)
The Hyper-V host(s)
(if applicable) Any file systems of the Hyper-V host that are external to the Hyper-V host itself
and are used to store the Cloud Automation Platform virtualization configuration files
2. Install the Platform components. During the installation of the Agent Services (part of the
Platform), you are prompted to enter the user name and password for the Remote Server Manager.
Enter the user name and password of the user account defined in step 1. See page 50 in Chapter 3,
Product Installation. for more information.
3. Configure each Hyper-V host to be managed remotely by ensuring the domain user account
created for this purpose is a member of the local Administrators group. For security reasons, it is
recommended for this domain user account not to be a member of the Domain Administrators
group.
4. On each Hyper-V host, use the following steps to configure the Authorization Manager policy:
A. Open the Authorization Manager MMC by using the Run command prompt to run azman.msc.
B. In the Authorization Manager interface, right-click and choose Open Authorization Store
from the list.
C. On the Open Authorization Store window, select the XML File radio button and use the Browse
option to navigate to the following directory:
C:\ProgramData\Microsoft\Windows\Hyper-V
D. Select InitialStore.xml and click Open.

29
2 Before You Start
F. In the Authorization Manager interface, expand the tree to open the Hyper-V Services\Role
Assignments\Administrator folder.
G. Select Administrator.
H. In the right pane, right-click and select Assign Users and Groups => From Windows and
Active Directory....
I.
Add the new user that you created in step 1.
J. Exit the Authorization Manager.

K. Reboot your Hyper-V server to effect the changes.
5. On each Hyper-V host, use the following steps to configure the Ethernet NIC driver.
Broadcom
A. Verify that the driver version is 4.4.15 or later.
B. Add a registry setting to preserve VLAN tags. This registry value needs to be added to the
configuration parameters for each of the Broadcom network interfaces on the computer:
i.
Run the Registry Editor (regedit).
ii. Search for "PriorityVLANTag" under HKLM\SYSTEM\ControlSet001\Control\Class.

iii. Add the DWORD value "PreserveVlanInfoInRxPacket" with value 1 to the top level key.
Intel
Add the following registry setting:

MonitorModeEnabled = 1
The Hyper-V R2 hosts are now ready to serve as virtualization hosts in the Cloud Automation Platform
environment.
Next Steps
In the Platform web interface, register and pool the host.
Note: If the VMs on the Hyper-V R2 host require network translation (i.e. will be on dedicated
VLANs rather than on the default network), refer to Using NAIL Server with Hyper-V R2
Hosts (Utility Hosts) on page 31.
Refer to the online Help for instructions to register the remote Hyper-V R2 hosts with the Platform.
After the remote hosts are registered and assigned to a resource pool, the Remote Server Manager will
manage the VMs and their configuration files on the registered remote hosts.
30
2 Before You Start
E. On the Open Authorization Store window, click OK.
The image for a VM that runs on a Hyper-V R2 host must include the Integration Services. Follow the
Microsoft Hyper-V documentation for installing the Integration Services in your image.
After the Hyper-V VM has the Integration Services installed, copy the .vhd file into the Library and use
the Surgient_Image_Tool.iso to prepare the image. Refer to the online Help for instructions to add
the images to the Library and prepare it for use in the Cloud Automation Platform environment.
Using NAIL Server with Hyper-V R2 Hosts (Utility Hosts)

Cloud Automation Platform uses NAIL servers to provide network address translation in an
environment in which a single image (and thus a single IP address) might be duplicated or cloned, and
used in multiple VMs in the environment. In such an environment, network address translation is
required to prevent network conflicts; NAIL server translates the IP Address contained in the image to
a unique address that is used only within the Cloud Automation Platform environment.
Microsoft Hyper-V does not support VLAN trunking from a NIC to a virtual machine, so NAIL servers
cannot be used on a Hyper-V host. However, network address translation can be accomplished in an all
Hyper-V or a heterogeneous environment with the use of a utility host. A utility host is any server
running supported virtualization software that also supports NAIL server, and is used by Hyper-V hosts
for network translation services. ESX3.5, ESX 3i, ESX 4, and ESXi 4 can function as the utility host
platform.
Note: In order for Hyper-V R2 to host multi-server sessions that require network address translation
(i.e. cloned images are used), NAIL Server must be run in advanced mode. See Configuring
NAIL Server Advanced Mode on page 137.
Hyper-V R2 hosts that do not run server configurations using NAIL server can continue to be pooled in
standard or advanced mode, and images that use DHCP/static IP Addresses do not require external
NAIL server access. But in standard mode, or advanced without an accessible NAIL server on a utility
host, sessions using NAIL server-designated content are not supported.
Creating a Utility Host on an ESX Server
Note: For a server to act as a utility host, the environment must use NAIL Server in advanced mode.
For information about using NAIL Server in advanced mode, see Configuring NAIL Server
Advanced Mode on page 137.
To create a utility host on an ESX server, follow these steps:
1. Register the ESX server in the Cloud Automation Platform environment. For detailed instructions,
see the online Help topic Registering a Remotely Managed Host.
2. Pool the utility hosts RAM only (not the RAM of any of the hosted VMs). Additionally, define the
computing capacity (EPUs) for the host. This must be done before pooling Hyper-V content hosts;
otherwise there will be an error when you pool the Hyper-V content hosts.
31
2 Before You Start
Image Preparation for Hyper-V R2 Hosts
32
2 Before You Start
3. Pool the content host(s) that will be using the utility host. This causes the Nail Server VM to be
started on the utility host.
Cloud Automation Platform supports integrations with Data Center Automation and virtualization
management systems such as Symantec Altiris Deployment Solution, HP Server Automation (formerly
Opsware Server Automation), and VMware vCenter Server.
Note: For detailed information about how to use the CAP web interface to register and implement
Partner Extensions, see the online Help. Information about configuration that needs to be done
either before installation or before accessing the CAP web interface is included in this
installation guide.
Integration with the following products enables several Cloud Automation Platform features:
Deployment Actions -- Running HP SA Software, Audit, and Patch policies against sessions in
the Cloud Automation Platform environment.
External Provisioning -- HP SA uses OS provisioning to deploy server configurations. Server

configurations that are intended to be externally provisioned by HP SA are created using OS
Sequences. This server configuration, when deployed, installs the specified operating system
and any additional software or data included in the sequence. OS sequences can be deployed to
either a virtual machine or to a physical computer that is provisioned by HP SA. See External
Provisioning with HP Server Automation on page 34 for more information.
Provisioning to Virtual Machines -- By default, sessions based on OS sequences are

provisioned to virtual machines. Provisioning details, such as whether the server
configuration is deployed to a VM or to a physical computer, are determined by the
hardware profile that is selected when creating the server configuration.
Physical Provisioning -- Physical computers that are managed by HP Server Automation

can be added to the Cloud Automation Platform resource pools and used as targets for OS
sequence-based sessions. For more information about physical provisioning, see Physical
Provisioning on page 176.
Note: If your environment requires the use of isolated DHCP networks and physical provisioning to
HP Server Automation-managed physical computers, you must configure network switch
automation. See Using Network Switch Automation on page 143.
VMware vCenter Server
vCenter Templates -- Import/Export of vCenter Server virtual machine templates.
Dual management -- An ESX or ESXi virtualization host can be registered with both Cloud
Automation Platform and VMware, enabling features in both products to be leveraged without
interference.
High Availability -- Integration with VMware vCenter allows users to specify selected
virtualization hosts as highly available, meaning that if the host computer fails, any VMs on the
33
2 Before You Start
About Partner Extensions
Symantec Altiris Deployment Solution
Deployment Actions -- Running Altiris jobs against sessions in the Cloud Automation Platform
environment.
Physical Provisioning -- Using Altiris to manage the use of physical computers in the lab
environment. For more information about physical provisioning, see Physical Provisioning
on page 176.
Note: Integration with Altiris requires the installation of the Quest CAP Agent on the Altiris server.
In order to implement the integrations, a partner extension is registered with Cloud Automation
Platform.
Note: Instead of using the Register feature on the Partner Extensions table page, integrations with
Altiris are automatically registered with the Cloud Automation Platform environment when the
Quest CAP Agent (installed on the Altiris Deployment Server) checks in with the Platform
server.
External Provisioning with HP Server Automation

To implement external provisioning with HP SA, use the following workflow summary as a guideline.
Refer to HP Server Automation on page 177 for information about using HP SA to provision physical
servers. Refer to the online Help for instructions to use the CAP web interface to implement external
provisioning with HP SA.
Workflow Summary
Verify that Wake on LAN and PXE is enabled for the primary NIC on each HP SA-managed
physical computer.
Register the HP Server Automation core server in the CAP web interface, using the Partner
Extensions node in the left navigation pane. Refer to the online Help for detailed instructions.
If the PXE boot server is not on the HP SA core server, but rather on a satellite server, you will
need to specify the PXE server IP address after registering the physical computer. Edit the
Physical Provisioning server Details page to specify the PXE boot server address; refer to the
online Help for detailed instructions.
Note: The user account used to register the HP SA core server must have broad Run Command on
Server privileges, and must have both Admin and root privileges (for both Windows and Linux
servers).
34
Register any HP SA-managed physical computers that you want to use in the Cloud Automation
Platform environment, using the Physical Provisioning node in the navigation pane. Refer to the
online Help for instructions to register a physical computer.
2 Before You Start
host computer will be migrated to another, functional host computer. See Using High
Availability with VMware vSphere on page 170 for more information.
If NIC 0 (as reported by HP SA) is not the primary NIC (i.e. is not the interface enabled for PXE
boot and Wake on LAN) you must use the Physical Provisioning server Details page to explicitly
designate the primary NIC.
If using VLAN-isolated DHCP networks, configure these DHCP networks. See Using VLANisolated DHCP Networks on page 141.
If using VLAN-isolated DHCP networks and physical computers provisioned by HP SA, you must
configure network switch automation. See Using Network Switch Automation on page 143.
Create a new server configuration using an OS Sequence. Any OS Sequences that are on the SA
Core server when the core server is registered with Cloud Automation Platform will appear in a
drop-down list when creating a new server configuration. (Select External Provisioning to see list
of OS Sequences.) Refer to the online Help for detailed instructions to create a server configuration
using OS Sequences.
When creating the server configuration, use the Hardware Profile to determine whether the server
configuration will be deployed to a physical computer or virtual machine, and other deployment
details.
From one or more OS Sequence-based server configurations, create an application configuration

and session.
Note: If any step in the overall process of provisioning and deploying the OS Sequence fails, the entire
deployment will fail and the user will be notified.
35
2 Before You Start
Note: The physical computer must have been provisioned by HP SA at least once prior to registering
with Cloud Automation Platform. Servers that have not previously been provisioned by HP SA
will not display in the list of servers to register in Cloud Automation Platform.
Cloud Automation Platform provides support for increased security to meet standards and requirements
of IT departments and large enterprises.
Cloud Automation Platform security features include:
Increased security for passwords (key lengths and encoding)
Support for 2-way secure communication between agents and platform
Support for encrypted SQL connections (specify during installation)
Obfuscate identifiers in web request resources
Optional regular expression entries to generate query string input validation error
Hidden password entry on vcsadmin login
Review the following sections for information about configuring certain security options.
Configuring 2-way Secure Communication

To configure the Cloud Automation Platform environment to use 2-way secure communication (SSL),
follow these steps:
1. Install the Platform components. See Product Installation on page 41 for details.
Note: (Altiris only) During an upgrade (but not during a fresh installation) of the Agent Services
component of the platform, you are prompted to upgrade all Windows Agents in the
environment. After upgrading the Windows Agents on any Altiris Deployment Servers, resume
the platform upgrade.
Additionally, any Windows and Linux guest agents in Altiris physical images must be
upgraded.
2. Configure IIS for secure communication on the computer running the Agent Services (agent
message forwarder):
Enable SSL port for the Default Web Site
Configure the Default Web Site with a certificate
3. Before pooling any hosts, use vcsadmin to set the configuration setting DefaultMsgRoute to
specify the https scheme. For example: https://IP_Address/ingress/mailbox.aspx
4. In the Windows Agent configuration file, set the MyMailbox configuration value to specify the
https scheme.
5. Restart all Quest CAP Agents.
36
2 Before You Start
Security And Encryption
6. Upgrade Altiris Guest Agents: If your environment includes Altiris physical images (.img), you
will need to upgrade the guest agents in each image:
A. Start the physical image.
Deploy an application using the physical image using the Cloud Automation Platform
system.
Use Altiris DS directly to start the image.
B. Upgrade the physical agent.
Linux: rpm U linux-phy-agent-7.5.0-<build#>.i386.rpm
Windows: Surgient_Image_Tool.exe
C. (Linux and Windows images) In the Agent configuration file, set the my_mailbox/MyMailbox
configuration value to specify the https scheme.
D. Start the agent.
E. Save the updated image.
Perform a Save As on the session and then copy the saved image file to its permanent
location in a library.
Use Altiris DS directly to save the image to its permanent location in a library.
Validating Query Strings

Optionally, Cloud Automation Platform can validate query string inputs to check against XSS (crosssite scripting) vulnerabilities.
To configure the validation properties, open the web.config file, which by default is installed in the
following location:
C:\Program Files\Quest Software\CAP\Web\web.config
RequestValidation.Enabled
Strings included in the URL of the Cloud Automation Platform web application and entered into the
fields on the pages of the web application are validated if the RequestValidation.Enabled
configuration is set to true. By default, it is set to false.
RequestValidation.GetRegEx
The RequestValidation.GetRegEx configuration setting can be used to define a pattern that,

if matched with any patterns in the URL, will display an error page.
37
2 Before You Start
Note: For an upgrade or for a time period after a fresh install, schedule a maintenance window for all
hosts that have NAIL Servers and follow step 3. and step 4. Restart the Agents and the NAIL
Servers.
RequestValidation.PostRegEx
The RequestValidation.PostRegEx configuration setting can be used to validate strings

entered in the fields on the web application pages.
Choosing a Windows Account for the Agent Service

(Altiris)
Each Altiris Deployment Solution server must have a Quest CAP Agent installed. The agent runs as a
service, displayed in the Services panel as Quest Software Service Agent for Altiris
Deployment Solution.
Considerations
Review the following considerations when determining which account to use for the Agent service:
If the computer on which you install the Quest CAP Agent is a member of a domain, the user name
and password should be for a domain account.
For computers that are not in a domain, the same Windows user account must exist with the same
password on every server/host where you install the agent.
Every agent service must be configured to run under the same account.
The account must have read/write access to the System Library location.
The account must be a member of the local Administrators group (not necessarily Domain
Administrators). A Domain User that is in the local Administrators group is preferred.
The password rules for the account must be configured to never expire.
Using the vcsadmin Utility

The vcsadmin utility is a command line tool used to modify the Platform settings.
1. Launch the vcsadmin utility by double-clicking the vcsadmin.exe file in the installation
directory on the CAP Core server. By default, this directory is:
Program Files/Quest Software/CAP/Platform
2. When the vcsadmin utility opens, log on by typing the following and then pressing Enter:
login <username> <password>
OR
login -o <organization> <username> <password>
By default, the username is admin. The password is the administrator password that was defined
during the Platform installation.
38
2 Before You Start
For example:
login <username>
OR
login -o <organization> <username>
3. After logging on, type the appropriate command and then press Enter. Typically, if you are setting
an advanced configuration setting, the syntax is as follows:
configset Name.Of.ConfigurationSetting=<x>
where x is the value that you want to set.

To view all of the configuration settings and possible values, use the configlist command or open
the CAP web interface and click Configuration under System Settings in the left navigation pane.
When in vcsadmin, type help and press Enter to display a list and description of all commands.
To get the list of available commands that start with a prefix, type help <prefix> where prefix is
the first part of the command. For example, type help appsession to get all the commands that start
with appsession.
To get help on a specific command, type help <command> where command is the name of the specific
command for which you want Help. For example, type help appsessionlist to get more
information about the command appsessionlist.
39
2 Before You Start
Note: If you do not want to type out your password in clear text, you enter only your user name and
press Enter. You will then be prompted to type your password, but it will not be displayed on
the screen.
2 Before You Start
40
Product Installation
This chapter provides instructions for installing the Cloud Automation Platform.
Installation Scenario Overview on page 42
Installing the Core Services on page 43
Installing the Agent Services on page 50
Installing the Web Application and Solutions on page 55
Installing the SOAP API on page 59
Installing the Advanced Enterprise Pack (Optional) on page 62
Installing the Quest CAP Agent (Altiris) on page 63
Installing the CAP SOAP API CLI on page 70
Launching the CAP Web Interface on page 71
41
After using the information and checklist in the previous chapter to define and set up your network, use
the instructions in this chapter to install each of the following:
CAP Core components:
Core Services: Platform server and main services
Agent Services: Agent Message Forwarder, Remote Server Manager Service, Agent Message
Processor
Web Applications: CAP web interface, QA/Test Solution
SOAP APIs (required for integration with certain third-party products.)
NAIL Server (Optional, used for network address translation, cloning of image, and advanced
networking capabilities)
Quest CAP Agent (Optional, required on Altiris server if implementing physical provisioning)
The four main components of the CAP Core are all included in a single installation file, Setup.exe.
The CAP Core components include the main functionality of Cloud Automation Platform; optional
additional installations include a TightVNC component, Quest CAP Agent (for Altiris), and the URA
Gateway Server. (For more information about the URA Gateway, see Installing and Configuring the
URA Gateway Server on page 94.)
VNC can be used, with Firefox on Windows or Linux, or with IE with ActiveX disabled, to enable access
from the URA to the remote desktop of the running VM. To use VNC for remote access, run the
AdvancedEnterprisePack.exe installation program (see Installing the Advanced Enterprise Pack
(Optional) on page 62).
Note: The following sections provide instructions for installing each CAP Core component
separately, in support of a scenario in which one or more components are installed separately,
on different physical or virtual computers.
Alternatively, you can install all four CAP Core components on the same computer, if your
environment is small enough (less than 16 hosts). To install all components on a single
computer, select Standard as the installation type, and then select all of the components that
you want to install.
By default, the Cloud Automation Platform software is installed in c:\Program Files\Quest
Software\CAP\Platform. You can choose a different destination directory during the install
process. Platform log files are written to the \logs subdirectory in the destination directory.
Once you have completed the installation, see the online Help for information about using the System
Diagnostic Test to verify your installation.
Note: For information about supporting a custom configuration of Microsoft IIS, see Installation for
a Secure IIS Service Account on page 178.
42
Installation Scenario Overview
The following steps provide an overview of setting up your Cloud Automation Platform environment:
1. Install the CAP Core components on one or more servers. See page 43 for installation instructions.
2. (Optionally, if using VNC for remote access with Firefox on Windows or Linux, or with IE with
ActiveX disabled) Run the AdvancedEnterprisePack.exe installation program. See page 62
for installation instructions.
3. (Optionally, if using Altiris for physical provisioning) Install a Quest CAP Agent on the Altiris
Deployment Server. For more information, see Installing the Quest CAP Agent (Altiris) on page
63.
4. (Optionally, if VMware vCenter integration is planned) refer to Additional Considerations on
page 18.
Installing the Core Services

Note: The Core Services must be installed first, before any of the other CAP Core components.
To install the Core Services component, perform the following steps:
1. From the installation media, double-click Setup.exe to launch the Platform Installer.
Note: If an Open File Security Warning message appears, click Run.

2. Click Next to view the License Agreement page.
43
Workflow Summary
3. Read the end user license agreement (EULA).

To print a copy of the agreement, click Print.
4. Click I accept the terms of the license agreement.
5. Click Next to view the Installation Type page.
6. Click Standard.
44
7. Click Next to view the Components To Install page.
The amount of disk space required for the installation and the amount of space available on the
currently selected disk are both shown. To view the amount of space available on your other disks
or to specify a different disk for the installation, click Disk Space.
8. Ensure that Core Services is the only selected check box.
Note: If you are installing multiple components on this computer, select all components that you want
to install. For environments larger than 16 hosts, Quest Software recommends that the Agent
Services component and the Core Services component are installed on a different servers.
9. Optional: To specify a destination folder other than the default folder of C:\Program
Files\Quest Software\CAP\Platform, click Browse.
45
10. Click Next to view the Operational Database page.
The operational database stores information associated with real-time processes and functions.
11. Specify the following information for the operational database:
A unique name for the database
The DSN name of the server that will act as the database server.To select a server from a list of
available servers, click Browse.
The authentication method to use while connecting to the database.
46
To use SQL Server authentication, specify a logon ID and password.
To use Windows authentication, check Use Windows authentication.
Whether to encrypt communication traffic between the platform server and the database. A
certificate must already be in place.
12. Click Next to view the Reporting Database page, which is automatically populated with values
derived from the information specified on the Operational Database page.
The reporting database captures historical information to be used when generating reports.
13. Specify the following information for the reporting database:
A unique name for the database.
The DSN name of the server that will act as the database server.To select a server from a list of
available servers, click Browse.
The authentication method to use while connecting to the database.
To use SQL Server authentication, specify a logon ID and password.
To use Windows authentication, check Use Windows authentication.
Whether to encrypt communication traffic between the platform server and the database. A
certificate must already be in place.
14. Click Next to view the Database User Credentials page.
47
15. Optionally, specify a login ID and password for the Control Services to use when connecting to the
database. Leave blank to use the default credentials. These credentials are used internally and will
not be requested when using the product.
Note: If the database password changes after the Cloud Automation Platform is installed, a CAP
Platform Administrator will need to run the following command to change, encrypt, and store
the updated password.
1) Log into the platform server
2) In a command shell, change directory to the <install_directory>/Platform location
3) Run db-config-manager.exe -cleartextpassword <password>
If the password for the reporting database is different from the operational database, use the configkey option to specify updates to the appropriate data source connection strings. For
example, to update the password for the operational database, run the command db-configmanager.exe -cleartextpassword <password> -configkey DSN. (ReportingDSN
is the option for connections to the reporting database).
16. Click Next to view the Platform Administrator Password page.
48
17. Type a password for the platform administrator.

Be sure to record the password; it will be required later in the installation process and when using
the product.
18. Confirm the password by retyping it.
19. Click Next to view the Email Settings page.
49
20. Specify the following information:
The DSN name of the mail server, such as mail.mycompany.com.
The e-mail address to which messages will be sent.
21. Click Next to view the Start Copying Files page.
22. Verify that the appropriate components will be installed according to your specifications.
To make a correction, click Back until you return to the appropriate page.
23. Click Next to install the Core Services.
When the installation is finished, the Complete page opens.
24. Click Finish to quit the installer.
Installing the Agent Services

Note: For environments larger than 16 hosts, Quest Software recommends that the Agent Services
component and the Core Services component are installed on a different servers.
Additionally, be aware that the Core Services must be installed first, before any of the other
Platform components.
50
The information specified on this page defines who will receive the appropriate e-mail message
when an error occurs.
1. Double-click Setup.exe to launch the Platform Installer.

If you install a second component on a single computer, you will be prompted by the Setup
Maintenance program. Select Modify to continue the install process. In this case, go to step
7.
4. Click I accept the terms of the license agreement.
6. Click Standard as the installation type.
8. Ensure that Agent Services is the only selected check box.
51
To install the Agent Services component, perform the following steps:
10. Click Next to view the System Information page.
The name or IP address of the computer on which you have installed the Core Services.
The platform administrator password that was specified during the Core Services installation.
12. Click Next to view the Service Configuration page.
52
13. (Hyper-V only) Type a user name and password of the domain account under which the Remote
Server Manager will run as a Windows service. This domain account must be a member of the
Administrators group on both the computer on which the Agent Services component is installed
and on the Hyper-V servers.
At a later point, if needed, you can change the credentials. To do so, open the Services panel on the
computer where you installed the Agent Services (which includes the RSM) and edit the Log On
information for the Quest Software Remote Server Manager service.
Note: Before using the Remote Server Manager it is important that you read the pre-installation
information in Additional Considerations on page 18.
14. Click Next to view the Library Configuration page.
15. Enter the path to the Images directory in the installation media.
16. Click Next to view the IP Address Selection page.
53
The Service Configuration page defines the authentication credentials that are used by the Remote
Server Manager (included in the Agent Services component) to communicate with and manage
Hyper-V virtualization file systems and hosts.
17. Type or select the IP address of the agent message forwarder, or mailbox. The agent message
forwarder is installed with the Agent Services component of the platform, so this value is normally
the IP address of the machine on which you are currently installing the Agent Services.
Communications addressed to the mailbox will use this IP address.
18. Click Done to view the Start Copying Files page.
20. Click Next to install the Agent Services.
21. Click Finish to quit the Platform Installer.
54
The CAP web interface (accessed by entering a URL in a web browser) serves both as the
administrators interface to the Cloud Automation Platform, and as the portal for the Solution end-users.
(See Launching the CAP Web Interface on page 71 for details about opening the web interface after
installation.)
If your environment is such that the CAP web interface users do not easily have network access to the
CAP Core server, then you should install the web application component on a separate server. An
environment can have multiple installations of the CAP web interface.
To install the web application, perform the following steps:
1. Double-click Setup.exe to launch the Platform Installer.
If you install a second component on a single computer, you will be prompted by the Setup
Maintenance program. Select Modify to continue the install process. In this case, go to step
7.
4. Select I accept the terms of the license agreement.
6. Select Standard as the installation type.
55
Installing the Web Application and Solutions
8. Ensure that Web Applications is the only selected check box.
56
The name or IP address of the computer on which you have installed the CAP Core server. If
you have distributed the CAP Core server across multiple servers, specify the name or IP
address of the one on which the Core Services component is installed.
If you are installing the Web Application component on the same computer as the CAP Core
server, type the name or IP address of the computer that you are logged on to.
The platform administrator password that was specified during the CAP Core server
installation.
12. Click Next to view the URA Gateway Information page.
57
13. Optional: If you are installing the CAP web interface in an environment that utilizes a firewall,
specify the host name or IP address of the Universal Remote Access (URA) gateway.
For more information on the URA gateway, see Universal Remote Access on page 104.
15. Verify that the CAP web interface will be installed according to your specifications.
58
16. Click Next to install the CAP web interface.

The Setup Status page displays the installation progress.
When the installation is finished, the Complete page appears.
17. Click Finish to complete the Platform installation.
Installing the SOAP API

The SOAP API is a server-side component that is required for several Cloud Automation Platform
integration products, such as the Add-In for HP Quality Center.
The SOAP API is installed using the CAP Core installation program (Setup.exe).
To install the SOAP API component, perform the following steps:
1. From the installation media, double-click Setup.exe to launch the Platform Installer.
4. Select I accept the terms of the license agreement.
6. Select Standard.
59
8. Ensure that SOAP APIs is the only selected check box.
60
The name or IP address of the computer on which you installed the Core Services component.
14. Click Next to install the SOAP API.
The Setup Status page displays the installation progress.
15. Click Finish to quit the Platform Installer.
61
Use the AdvancedEnterprisePack.exe installation program to install an optional Tight VNC

component. Tight VNC is used, in a VNC environment, to enable access from the URA to the remote
desktop of the running VM.
Important Considerations:
Before running the AdvancedEnterprisePack.exe program, verify that the following file has
been placed on the computer where you are installing the Advanced Enterprise Pack.
Java viewer for TightVNC 1.3 (vncviewer.jar)
Run the Advanced Enterprise Pack installation program on the same computer where you have
already installed the Agent Services component and on all computers where you have installed the
Web Applications component.
To install the Advanced Enterprise Pack components, perform the following steps:
1. From the installation media, double-click AdvancedEnterprisePack.exe.
2. Click Next to view the Choose JavaVNC Optional Component Location page.
3. Enter or browse to the directory containing the vncviewer.jar file.
4. Click Next to view the Ready to Install page.
5. Click Install to being the installation.
When the installation is finished, the Complete page appears.
62
Installing the Advanced Enterprise Pack (Optional)
A Cloud Automation Platform agent must be installed on any Symantec Altiris Deployment Server if
the server is used to manage virtualization hosts in the Cloud Automation Platform environment.
Note: The Cloud Automation Platform agent on virtualization hosts and library servers is no longer
required nor supported. All hosts and library servers must be managed by the Remote Server
Manager. Refer to the Upgrade Documentation and the Release Notes for additional
information.
The following section describes how to install the agent on an Altiris server.
Note: Before installing the agent, review Choosing a Windows Account for the Agent Service
(Altiris) on page 38 for important information about selecting an account for the agent service
to run as.
Installing the Agent to Manage an Altiris Server

To install the agent on a server running the Altiris Deployment Server, perform the following steps.
1. From the directory containing the distribution files, double-click WindowsAgent.exe to launch
the Agent installer.
Note: If a File Download message appears, click Open.
2. Click Next to view the Agent Configuration page.
63
Installing the Quest CAP Agent (Altiris)
4. Click Next to view the Setup Folder page.
5. Review the Destination Folder in which to install the agent.

To specify a destination folder other than the default folder of C:\Program Files\Quest
Software\CAP\Agent, click Browse.
64
3. For the Agent Message Forwarder, specify the name or IP address of the computer on which you
have installed the Agent Services component of the Platform.
6. Click Next to view the Altiris eXpress Deployment Server Database page.
Enter the Database Name and the Database Server of the database that the Altiris Deployment
Solution uses.
By default, the name of the database is express. For the name of the server, if the database is on the
same computer as the Deployment Server, enter or browse to (local).
7. Click Next to view the Pre-Boot Linux OS File Path page.
Note: If you previously installed the Cloud Automation Platform agent, and did not delete the Altiris
Deployment Database that is created by the Platform, you will be prompted to reset the existing
database for use with the new agent installation.
65
8. Enter the directory path to the appropriate pre-boot file (.frm) that is included with the installation
media in the /Images directory.
For Altiris Deployment Solution version 6.8, navigate to this file:

BDCgpl_6.8.8397.frm
For Altiris Deployment Solution version 6.9, navigate to this file:

BDCgpl_6.9.8853.frm
9. Click Next to download the file and install the pre-boot program.
66
After the file has been downloaded and installed, the Library Configuration page appears.
A library location that contains Altiris files (.img) requires a Cloud Automation Platform agent to
manage the use of the library images and files, as well as to facilitate communication between the
CAP Core server, the web application, and any client computers. (Libraries for VMware and HyperV files are remotely managed by the Remote Server Manager.)
10. Provide the following information:
Location to create the library: enter the path to connect to the server that will serve as the library
location host (where the Altiris images and files will reside).
Note: The library location must be on a server to which all virtualization hosts that will use images
from the library have access.
Location of the Images directory: the Images directory is located on installation media, and
contains images and files that are necessary for the configuration of the Cloud Automation Platform
environment. When you enter the location of the Images directory, the installation program copies
the required files into the library location that you defined in the previous step.
11. Click Next to view the Service Configuration page.
67
12. Type a user name and password of a domain account under which the agent communicate with the
Altiris Deployment Solution.
If the Altiris Deployment Share is on the same computer as the Deployment Server (where you are
installing the Quest CAP Agent), you can leave these fields blank and run as the Local System
account.
13. Click Next.
The Ready to Install page appears.
68
14. Click Install to begin the installation program.

The Setup Status page appears.
15. When the installation is finished, the Complete page opens.

16. Click Finish to conclude the agent installation.
69
The Cloud Automation Platform API includes both a server component and a client-side command line
interface component.
The CAP SOAP API command line interface is an optional component (based on PowerShell) that
allows users to issue commands and run scripts on the CAP platform from their remote computer
through the CAP SOAP API web service.
The SOAP API is a web service that allows users to issue commands and run scripts on the CAP
platform, using either the CAP SOAP API command line interface or any programming language
supporting web services integration.
Note: The SOAP API must be installed on the CAP Core server before you can use the CAP SOAP
API command line interface. Use the Quest Cloud Automation Platform installation program
(Setup.exe) to install the SOAP API. See Installing the SOAP API on page 59 for details.
Installing the CAP SOAP API CLI

To install the CAP SOAP API command line interface component on a Windows computer, navigate to
the installation media, and double-click QuestCAPSoapApiPowershell.exe to launch the
installation wizard. During the installation process, you will be prompted to enter the IP address of the
computer where you installed the SOAP API component. Optionally, when prompted, enter the
following information:
User ID: Enter the ID that was defined during the installation of the CAP Core. By default, this user
is admin.
Password: Enter the password for the user.
Org: Enter the Organization to which the user belongs.

By default, the command line interface application and all supporting files are written to the following
directory:
C:\Program\Quest Software\CAP\SOAPAPIPowerShell
The sub-directory Examples under the above directory includes several utility and example scripts,
to help you get started automating the environment.
Note: To view documentation for using the SOAP API, copy the SOAPAPIHelp.chm file in the
installation directory above to your desktop, and double-click to open.
To launch the the CAP SOAP API command line interface, select Start => Quest Software => SOAP
API Power Shell.
70
About the CAP SOAP API Client
Launching the CAP Web Interface

After you install Cloud Automation Platform, begin the setup process by logging on to the CAP web
interface
Note: (Altiris only) Verify that the Quest CAP Agent that you installed on any Altiris Deployment
Server is running. To do so, view the Services panel to confirm that the agent is started (the
service name is Quest CAP Agent).
To access the CAP web interface in Microsoft Internet Explorer or Mozilla Firefox, type the following
URL in the web browser address bar:
http://<server>/QuestCAP
where <server> is the name or IP address of the server on which you installed the Core Services of
the CAP Core. See Installing the Core Services on page 43.
When the Log On panel opens, enter the user name (by default the user name is admin) and the platform
administrator password that you created during the Platform installation process.
Note: Before clicking Log On to open the CAP web interface for the first time, see the Testing Your
Web Browser on page 71.
Figure 2 Log On Panel
Testing Your Web Browser

Before logging on to the CAP web interface, Quest Software recommends that you test your web
browser. To do so, click the Is your browser ready? link on the Log On panel.
71
72
The Web Browser and Connectivity Test launches and runs several tests. As each of the tests are
completed, a message displays with the success or failure status. If all tests are successful, close the Test
browser window and return to the Lon On panel for the CAP web interface. If any test failed, review
the diagnostic information and make the required fixes.
Cloud Automation Platform Solutions allow software companies to simplify and

automate the delivery of prepared software demonstrations and online software
evaluations as well as online training labs and virtual test sessions. These solutions
enable communication from a remote computer to a Cloud Automation Platform deployed virtual
machine (VM) located behind a firewall.
This chapter contains detailed information on connecting to a deployed Cloud Automation Platform VM
using a URA Gateway server. It also includes descriptions and typical workflows of the Web Browser
and Connectivity Test and the Classroom Readiness Test.
Universal Remote Access on page 74
Web Browser and Connectivity Test on page 80
Classroom Readiness Test on page 80
73
4 Remote Access
Remote Access
Universal remote access (URA) enables communication from a remote computer to a Cloud
Automation Platform deployed VM located behind a firewall, using the following remote access
protocols:
Microsofts remote desktop protocol (RDP)
Linuxs virtual network computing (VNC)
Citrix Independent Computing Architecture (ICA)
Console access
The available remote access types are determined by the method specified when creating the server
configuration. If you specify multiple remote access methods for a server configuration, an application
user can then select the method with which to connect to the remote desktop of the VM.
URA bypasses firewall-imposed restrictions by transforming the Cloud Automation Platforms remote
packets into viable HTTP or HTTPS traffic. Once the packets have passed through the URA Gateway
server, they are returned to their original state and forwarded to their destination without compromising
the security of the network.
The following components enable this process:
A local listening proxy (LLP) that is available in ActiveX and Java formats. As the origination
endpoint of the URA tunnel, the LLP transforms the remote protocol packets as they leave or return
to the workstation.
A URA terminal client for RDP, VNC, or Citrix environments, available in ActiveX and Java
formats.
A URA Gateway server that complements the LLP, receiving the data required to establish
connections to the appropriate destination server from the information embedded in the initiating
requests. Functioning as the termination endpoint of the tunnel, the URA Gateway server returns
the packets to their original state as RDP, VNC, Citrix, or Console packets.
When a user establishes a terminal or desktop connection to a Cloud Automation Platform VM from
within a Cloud Automation Platform application, URA determines if the users workstation is
configured to use ActiveX or Java. The appropriate LLP and URA terminal client are automatically
downloaded to and installed on a remote workstation. However, you must install the URA Gateway
server -- either manually on a server that remote users can access by way of HTTP(S) or directly, using
the appropriate URA terminal clients ports (for example, 3389 for RDP, 5901 for VNC, and so on). For
information on ports, see Figure 5.
If complications prevent the LLP or URA terminal client from installing automatically on a remote
workstation, they can also be installed manually. For details on installing the URA terminal client
manually, see Installing the URA Terminal Client on page 102.
74
4 Remote Access
Figure 3 URA Communication Paths
For the ActiveX components to function properly, ActiveX must be enabled in the users browser
settings. Similarly, Java must be enabled before the Java components can function correctly.
75
4 Remote Access
Note: If you install the LLP or URA terminal client manually, future upgrades to the downloadable
content will not take place automatically. To upgrade content to an LLP or a URA terminal
client that was installed manually, you must uninstall the proxy or client and then reinstall it.
Microsoft RDP in a Windows environment
A supported VNC server installed in a Linux or Windows environment
A licensed Citrix server
Figure 4 shows the URA components installed on the end users Windows or Linux workstation, the
URA Gateway server, and on the VMs running a Windows or Linux image:
CAP RDP
(ms-rdp.ocx)
WebRDP
or
Smartcode
VNC
or
End user
computers
Citrix
or
TightVNC
Applet
or
Citrix
ActiveX
Java (MSJVM/Sun JRE)
URA Gateway Server
Windows server with

- Windows RDP enabled or
- TightVNC Server or
- Citrix installed
Virtual
Machines
Linux server with

- Native VNC or
- TightVNC Server
Figure 4 URA Components

The LLP is a signed, self-installing, and self-activating component that is downloaded, along with the
URA terminal client, from the Cloud Automation Platform application server to the end users
workstation. Its main functions include:
Converting RDP, VNC, or Citrix packets to traffic that can pass through the firewall
Transforming packets coming into the workstation back to the original RDP, VNC, or Citrix packets
Depending on the capabilities of the web browser on the end users workstation, the LLP can be
implemented as either an ActiveX control or a Java applet. URA automatically tests the configuration
76
4 Remote Access
At that point, the URA components are ready for communication between the workstation and the
destination VM. The destination VM must also be set up for the appropriate communication. The server
image must have one of the following installed or enabled, depending on the chosen remote technology:
The LLP can also support HTTP over SSL, which provides server-side authentication as well as
message integrity and confidentiality. Before such support can be realized, however, a commonly issued
commercial certificate that enables SSL must be installed on the gateway.
URA Terminal Client

The URA terminal client is automatically downloaded along with the LLP to the end users workstation.
Cloud Automation Platform provides URA terminal clients for RDP, VNC, and Citrix environments.
These clients are available in ActiveX and Java format.
In RDP environments with ActiveX enabled, URA uses the Microsoft Remote Desktop Client. When
ActiveX is disabled, Cloud Automation Platform provides a Java RDP (WebRDP) client that enables
many of the same capabilities seen in the ActiveX terminal client. VNC can also be used when Active
X is disabled (on Firefox on Windows or Linux, or IE on Windows) if the Java Viewer for TightVNC
is installed. (See Installing the Advanced Enterprise Pack (Optional) on page 62.) Note that whichever
remote access method you chose to use, that type must be enabled in the server configuration.
77
4 Remote Access
of the users machine to determine which implementation to use. The configuration settings determine
which remote technology is to be used and the order in which URA tests the users configuration.
Citrix environments also have an ActiveX and a Java terminal client available for remote connections.
Both Citrix clients support full color.
For installation instructions, see Installing the URA Terminal Client on page 102.
URA Gateway Server

As shown in Figure 4, the URA Gateway server brokers the data transmitted between the LLP and the
destination VM. It accomplishes this task by transforming the packets that arrive from the LLP and
forwarding them to the appropriate destination VM. Conversely, the URA Gateway server also
transforms all returning traffic sent from a destination VM and forwards it to the LLP.
The URA Gateway server can receive hundreds of concurrent requestssome coming in from the end
user and some going out from the destination VM. To facilitate this level of traffic, the URA Gateway
server utilizes the following pair of directional channels:
An upstream channel that delivers keyboard and mouse commands from the user to the destination
VM.
A downstream channel that carries the video traffic returning from a destination VM to the end user.
To set or change the URA Gateway servers IP address, use the vcsadmin tool to modify the
Ura.GatewayServerIp configuration value. See Using the vcsadmin Utility on page 38.
For installation instructions, see Installing and Configuring the URA Gateway Server on page 94.
Accessing a Deployed VM
There are four methods from which an end user can choose to connect to a deployed Cloud Automation
Platform VM using the URA Gateway server. Cloud Automation Platform employs a failover
mechanism that opts for each method in the following order:
1. Direct access - The fastest connectivity option, direct access bypasses the URA Gateway server. Of
the four connectivity methods, direct access offers the highest performance. Typically, direct access
is employed when end user machines reside in the same physical location as and inside the firewall
of the deployed VM. Occasionally, an end user chooses direct access for a machine outside the
firewall of the deployed VM; such a connection requires all RDP traffic be allowed through the
firewall.
2. Socket proxy - The second fastest connectivity option, a socket proxy connection is a port socket
redirect by the URA Gateway server that passes packets from the client computer to the Cloud
Automation Platform deployed resource. Socket proxy requires either using port address
translation (PAT) on the firewall or setting up the normal port for the connectivity method. Socket
proxy can service other destination ports for multiple remote access types (such as VNC, Citirix
and ESX console). However, for socket proxy to support more than one connectivity method at a
time, port redirects are required.
78
4 Remote Access
In a VNC environment, URA uses a Smartcode VNC component if ActiveX is enabled or a TightVNC
applet for Java support. Color support is determined by configuration of the VNC server or by the
display properties of the Linux workstation.
Since socket proxy use does not incur the overhead involved in HTTP/HTTPS tunnels, it is a
preferred connection method for both bandwith- and latency-constrained connections. In some
companies, HTTP/HTTPS tunneling is not allowed, or the local web proxies cannot handle the
long-term, high-bandwidth RDP tunnels. In many cases, network administrators do not block
outgoing remote access ports when you use the correct port for that protocol, such as 3389 for
Remote Desktop Protocol (RDP).
3. HTTP tunneling - The third fastest connectivity option, HTTP tunneling over port 80 offers a
conduit for remote access protocols to traverse firewalls using the web.
4. HTTPS tunneling - The slowest connectivity option, HTTPS tunneling over port 443 offers the
same conduit as HTTP tunneling with the confidentiality of Transport Layer Security (TLS).
Note: Functioning as the termination endpoint of the tunnel, the URA Gateway server returns the
packets to their original state as RDP, VNC, Citrix, or Console packets, regardless of which
connectivity method is used.
Figure 5 Cloud Automation Platform End User Connectivity
79
4 Remote Access
The actual connection starts with the Cloud Automation Platform LLP on the client machine. (See
Universal Remote Access on p. 104.) This LLP creates a connection to the socket proxy server
on the target port. In the recommended configuration, the firewall translates the incoming
connection from the target port to port 9999 and sends the packets off to the URA server. Once the
LLP connects to the socket proxy, the LLP requests that the socket proxy create a connection to the
target resource IP. Once the connection is created, the remote control utility is hooked up to the
connection to allow access to the Cloud Automation Platform.
The Web Browser and Connectivity Test (formerly named URT) verifies whether a Web browser is
configured to utilize the URA solution. When a user logs on to a Solution or the CAP web interface, he
or she has the option of clicking the Is Your Browser Ready? link that appears on the Log On panel.
Note: The Is Your Browser Ready? link can also be featured on a Web site, included in an e-mail
message, or delivered by any other method you deem appropriate.
If a user clicks this link, a test is conducted on the browser. When a browser passes the test, a message
informs the user that the browser is configured to successfully use URA. Conversely, when a tested
browser is not configured to utilize URA, the user is provided with the steps necessary to remedy the
situation.
The Web Browser and Connectivity Test also measures a networks bandwidth and compares it with a
set of defined performance ranges. If the amount of available bandwidth is high enough to fall within
the passing range, the network passes the test. If the measurement falls within the range that is
associated with failing, the network fails the test.
The Web Browser and Connectivity Test requires no installation. However, you might need to set or
change some of its configuration settings. See Editing Web Browser and Connectivity Test
Configuration Settings on page 111.
For instructor-led sessions and other scheduled events, the Web Browser and Connectivity Test must
be run in advance on all participating machines. For on-demand events, however, the Web Browser and
Connectivity Test can be either run in advance or integrated with the user registration and sign-up
processes. Such on-demand events include activities like self-paced training and online product
evaluations.
The typical workflow for a user readiness test is as follows:
1. The Platform administrator configures the Web Browser and Connectivity Test to make it available
to the appropriate users.
2. The user conducts the connectivity test and returns the results to the Platform administrator.
3. The Platform administrator analyzes the test results.
Note: The Web Browser and Connectivity Test must be re-run on a users computer whenever the
computer configuration, network connection, or location changes (for instance, if a student uses
his laptop at work and home).
Classroom Readiness Test

The CRT works with the Training Solution to measure the connectivity and performance characteristics
of a physical classroom where hands-on training is scheduled to occur. More precisely, CRT measures
the bandwidth and latency values of the classrooms network and compares them with established
80
4 Remote Access
Web Browser and Connectivity Test
The CRT application is automatically installed on the application server when the Training Solution is
installed, and testers connect to the CRT application by way of a URL that the Platform administrator
or class instructor provides. After a tester connects to the CRT application by way of this link, he or she
specifies the following information:
The number of students expected to participate in the class
The desired quality of the classroom sessions
While the CRT Load Test server uses this information to generate bandwidth load, the CRT client is
automatically downloaded to the workstation, where it measures the bandwidth and conducts tests on
network latency.
Upon completion of the readiness test, the tester can send the results to a Platform administrator by way
of an e-mail message from the test page.
Note: Test results can be sent in an e-mail message only if a value for the
CRT.Email.DefaultAddresses configuration setting has been specified in the Platform.
This procedure is performed using the vcsadmin command-line utility. See Editing CRT
If the test passes, the classroom is declared ready for use. If the classroom does not pass the test, the
Platform administrator analyzes the results and recommends a solution.
Note: A URA Gateway server and a CRT Load Test server must not be installed on the same machine
because load testing can interfere with interactive users accessing virtual machines. See
Installing the CRT Load Test Server on page 113 for installation directions.
If complications prevent the CRT application from installing itself automatically on a testers
workstation, you can install the CRT application manually. See Installing the CRT Application on
page 115 for instructions.
The typical workflow for the classroom readiness test includes the following:
1. The Platform administrator installs and configures CRT and then delivers the CRT web address to
the classroom tester.
Ideally, the person who runs CRT has access to information about the network path to the Internet
that the classroom machines take, including any routers, firewalls, or proxy servers that are in place.
2. The tester conducts the readiness test and e-mails the results to the Platform administrator.
3. If the test passes, the classroom is ready. If the classroom does not pass the test, the Platform
administrator analyzes the CRT results and recommends a solution.
81
4 Remote Access
ranges to determine whether they are favorable, unfavorable, or merely adequate for your classroom
needs.
Depending on the configuration of your network and the needs of your customers, remote access
solution system requirements can affect how you set up a Cloud Automation Platform environment. The
following sections discuss these requirements as well as other objectives and conditions that must be
considered while planning an installation of Cloud Automation Platform Solutions that requires remote
access. The following sections provide instructions for ensuring that you are fully prepared to address
any potential challenges:
Universal Remote Access (URA) Gateway Server Prerequisites on page 82
Web Browser and Connectivity Test Prerequisites on page 82
Classroom Readiness Test (CRT) Prerequisites on page 90
Socket Proxy Gateway Server Prerequisites on page 93
Universal Remote Access (URA) Gateway Server

Prerequisites
The minimum hardware and software requirements for the URA Gateway server are as follows:
1 GHz Pentium 4
1 GB RAM
Microsoft Windows Server 2003 SP2 (Enterprise, Standard, or Web)
Microsoft IIS 6.x or 7.x with ASP.NET enabled
Note: The URA Gateway server and CRT Load Test server must not be installed on the same machine
because load testing can interfere with interactive users accessing virtual machines.
For more information about the system requirements for the CRT Load Test server, see CRT Load Test
Server Minimum Requirements on page 90.
Web Browser and Connectivity Test Prerequisites

The requirements for a successful session are as follows:
One of the following browsers:
82
Microsoft Internet Explorer 7.0 or 8.0 with cookies enabled. On

64-bit Windows operating systems, you must use the 32-bit version of Internet Explorer, which
is the default browser on these systems.
4 Remote Access
Remote Access Solution System Requirements
4 Remote Access
Mozilla Firefox 3.0 or 3.5 with cookies enabled
Browser support for frames
Enabled pop-ups and cookies
Enabled JavaScript and VB Script
Enabled Java Applets and/or Microsofts ActiveX controls
Java 2 Platform Standard Edition (J2SE) version 1.4.2_06 - 1.6 (available from http://
www.java.com) for Microsoft Windows
Java 2 Platform Standard Edition (J2SE) version 1.5 - 1.6 (available from http://www.java.com) for
Linux
Java 2 Platform Standard Edition (J2SE) version 1.5 (included in Mac OS X)
Network bandwidth exceeds 80 KB/s per machine
83
Testing Your Web Browser

If the Web browser test fails, ensure that you are using Internet Explorer 7.0 or 8.0, or Mozilla Firefox
3.0 or 3.5.
Note: If you are using Internet Explorer, and the connection to a Citrix server fails, you might need to
add the Citrix server to Internet Explorers Trusted Sites zone. See Adding an Entry to Your
Trusted Sites Zone on page 88.
Verifying Support of Frames

The frames test verifies whether your Web browser supports HTML frames. If this test fails, you are
most likely using a Web browser that does not support HTML frames. Upgrade to Internet Explorer 7.0
or 8.0, or Mozilla Firefox 3.0 or 3.5.
Disabling Pop-Up Blockers

Performing the Web Browser and Connectivity Test requires that you disable all pop-up blockers.
Disable pop-up blocking in any third party extensions to your browser, such as Yahoo!, Google, or
Windows Live toolbars.
To disable the Internet Explorer pop-up blocker, perform the following steps:
1. Click Tools => Internet Options...
2. Click the Privacy tab.
3. Under Pop-up Blocker, ensure that the Turn on Pop-up Blocker check box is unchecked.
4. Click OK.
To disable the Mozilla Firefox pop-up blocker, perform the following steps:
1. Click Tools => Options...
2. Click the Content icon and ensure that the Block Popup Windows check box is unchecked.
3. Click OK.
84
4 Remote Access
The following topics provide more detailed information on the Web Browser and Connectivity Test
requirements.
The scripting test verifies whether your Web browser has Javascript and other active scripting options
enabled. If this test fails, ensure that your browser has Javascript (or other active scripting options)
enabled.
To enable Javascript/VBscript in Internet Explorer, perform the following steps:
2. Click the Security tab.
3. Under Security level for this zone, click Custom Level...
4. Under Scripting, ensure that the following options are enabled:
Active scripting
Scripting of Java applets
5. Click OK.
6. Click OK.
To enable Javascript in Mozilla Firefox, perform the following steps:
2. Click the Content icon and select the Enable Javascript check box.
3. Click OK.
85
4 Remote Access
Enabling Active Scripting
If the cookies test fails, ensure that your Web browser supports the setting of cookies.
To enable cookies in Internet Explorer, perform the following steps:
2. Click the Privacy tab.
3. Under Settings, click Sites.
4. In the Address of Website field, type the URL for the host of your solution (for example,
*.demoservers.com).
5. Click Allow.
6. Click OK.
7. Click OK.
To enable cookies in Mozilla Firefox, perform the following steps:
2. Click the Privacy icon.
3. Under Cookies, select the Accept cookies from sites check box.
4. Click OK.
86
4 Remote Access
Ensuring Your Browser Supports Setting of Cookies
Embedded content includes Microsoft's ActiveX controls and Java Applets. If this test fails, enable your
Web browser's ActiveX or Java options as instructed below. In some cases, you might need to contact
your administrator to change these settings.
To enable the appropriate ActiveX controls and plug-ins in Internet Explorer, perform the following
steps:
4. Under ActiveX controls and plug-ins, set the value for Download signed ActiveX controls to
Prompt.
5. In the same section, ActiveX controls and plug-ins, ensure that the following options are enabled:
Run ActiveX controls and plug-ins
Script ActiveX controls marked safe for scripting
6. Click OK.
Note: If a message asks you to confirm the change in security settings for this zone, click Yes.
7. Click OK.
To enable Java in Internet Explorer, perform the following steps:
2. Click the Advanced tab.
3. Under Java (Sun), select Use Java 2/JRE vx.x.x for <applet> (requires restart).
4. Click OK.
87
4 Remote Access
Enabling ActiveX or Java for Embedded Content

2. Click the Content icon and select the Enable Java check box.
3. Click OK.
Determining the Best Connection Type

The connection test uses different remote-access methods to determine whether ActiveX or Java is the
connection type better suited for your computer and Internet connection.
During this test, your Web browser will download several pieces of embedded content. These pieces
are safe and cannot interfere with any part of your computer or browser. You will need to read and
accept the security notifications during this process.
If your connection test fails and network restrictions prevent you from downloading the requisite
ActiveX control or Java applet, you will be unable to access the application. Contact your administrator
to obtain permission to download either the ActiveX control or the Java applet.
Measuring Bandwidth
The bandwidth test measures the amount of data that can be transmitted within a set amount of time. A
high bandwidth indicates a fast connection, which helps create a more satisfying user experience. A low
bandwidth, however, indicates a slow connection that can result in a sluggish performance, delays, and
a frustrating overall experience. A minimum bandwidth value of 25 KB/sec is required to successfully
pass the test.
Test results indicate Slow, Acceptable, or Preferred bandwidth. The ranges are as follows:
Minimum Bandwidth = 25 KB/sec
Acceptable Bandwidth = 26 - 99 KB/sec
Preferred Bandwidth = 100 KB/sec and above
If the bandwidth test fails because your connection is slow, use a different computer, Web browser, or
network to connect to the Internet. After you successfully establish a connection, access the Web
Browser and Connectivity Test page and run the test again.
Adding an Entry to Your Trusted Sites Zone

It might be necessary to add an entry to the Trusted Sites zone, informing your Web browser that the
site to which you are attempting to connect can be trusted not to harm your system.
To add an entry to your browser's Trusted Sites zone in Internet Explorer, perform the following steps:
88
4 Remote Access
To enable Java in Mozilla Firefox, perform the following steps:
3. Click Trusted sites.

4. Click Sites.
5. In the Add this Website to the zone field, type the URL for the host of your solution (for example,
*.demoservers.com).
6. Ensure that Require server verification (https:) for all sites in this zone is unchecked.
7. Click Add.
8. Click OK.
9. Click OK.
89
4 Remote Access
Cloud Automation Platform Solutions support Java 2 Platform Standard Edition (J2SE) version
1.4.2_06 - 1.6 for Microsoft Windows, version 1.5 - 1.6 for Linux, and version 1.5 for Mac OS X.
Classroom Readiness Test (CRT) Prerequisites

Note: If you intend to run the CRT, you must install the CRT Load Test server. Although a URA
Gateway server must also be installed on your network, it cannot reside on the same machine
as the CRT Load Test server because load testing can interfere with interactive users accessing
virtual machines.
It is recommended that you identify the DNS name and IP address of the server that you intend to use
as the CRT Load Test server and record these values.These values are necessary when you install the
CRT application.
CRT Load Test Server Minimum Requirements

The minimum hardware and software requirements for the CRT Load Test server are as follows:
1 GB RAM
Microsoft Windows 2003 Server SP2 (Standard, Enterprise, or Web)

Note: Because a URA Gateway server can receive hundreds of concurrent requests and load
testing can interfere with interactive users accessing virtual machines, a URA Gateway
server must not be installed on the same machine that hosts a CRT Load Test server.
CRT Requirements
The requirements for a successful classroom simulation are as follows:
Internet Explorer 7.0 or 8.0 on Windows XP or later.

Cloud Automation Platform applications support Internet Explorer and Mozilla Firefox. However,
the CRT runs on Internet Explorer only.
Access to the same network environment in which the class is going to be conducted
Ideally, you would run the CRT from the classroom where the class will be conducted, at the same
time of day that the class is scheduled to occur.
90
4 Remote Access
Java Platform
If you cannot run CRT from a student machine, run the test from a 2 GHz or better machine or an
equivalent laptop that meets the following criteria.
connected on the same LAN and configured to use the same routing, firewalls, and proxy
servers as the classroom machines
can sufficiently process the network load of the student lab against the virtual machine network
Note: The requirements for the CRT test machine are not related to the requirements for the student
machines. The network load being generated from the computer that runs CRT simulates the
network load generated by a classroom of student systems. If the system from which the test is
conducted is not fast enough to generate the required network load, the test results may falsely
report a test failure.
Note: For CRT testing, it is recommended that you do not use a laptop with a wireless connection if
the classroom utilizes desktop computers with wired connections. The purpose of the test is to
measure the classroom experience under the same conditions and network demands as a live
class.
91
4 Remote Access
CRT requires enabled ActiveX controls to establish the test connection. If your Internet Explorer
Security settings are set to High or have been customized, you might need to install the ActiveX
control manually.
To enable the appropriate ActiveX controls and plug-ins in IE, perform the following steps:
1. Select Tools => Internet Options.
4. Under ActiveX controls and plug-ins, set the value for Download signed ActiveX controls
to Prompt.
5. In the ActiveX controls and plug-ins section, ensure that the following options are enabled:
Run ActiveX controls and plug-ins
Script ActiveX controls marked safe for scripting
6. Click OK.
Note: If a message asks you to confirm the change in security settings for this zone, click Yes.
7. Click OK.
92
4 Remote Access
The minimum hardware and software requirements for the socket proxy Gateway server are as follows:
1 GHz Pentium 4
512 MB RAM (note the amount of RAM per expected connection)
Microsoft Windows Server 2003 SP2 (Enterprise, Standard, or Web)
Microsoft Windows Server 2008 (Data Center, Enterprise, or Standard)
Microsoft IIS 6.x or 7.x with ASP.NET enabled
93
4 Remote Access
Socket Proxy Gateway Server Prerequisites
For system requirements, see Universal Remote Access (URA) Gateway Server Prerequisites on page
82. For more detailed information about the URA Gateway, see Universal Remote Access on page 74.
The URA Gateway server brokers the data that is transmitted between the LLP and the destination
Cloud Automation Platform VM. It accomplishes this task by transforming the packets that arrive from
the LLP and forwarding them to the appropriate destination VM. Conversely, the URA Gateway server
also transforms all returning traffic sent from a destination VM and forwards it to the LLP.
Note: Because a URA Gateway server can receive hundreds of concurrent requests and load testing
can interfere with interactive users accessing virtual machines, a URA gateway server must
not be installed on the same machine that hosts a CRT Load Test server.
Note: The URA Gateway server must be accessible externally by Cloud Automation Platform users.
Note: By default, when Cloud Automation Platform administrators install the URA Gateway server,
the socket proxy component is also installed.The default path for socket proxy installation and
configuration files is C:\Program Files\Quest
Software\CAP\URAGateway\SocketGateway.
94
4 Remote Access
Installing and Configuring the URA Gateway Server
4 Remote Access
To install and configure the URA Gateway server, perform the following steps:
1. From the installation media, navigate to the RemoteAccess directory, which is located in the
DiskImage directory. Double-click URAGateway.exe to launch the Install URA Gateway
Wizard.

2. Click Next to view the Setup Type page.
95
Named For environments with multiple, locale-specific gateways. Using named gateways,
each user can specifiy a preference for a particular gateway. For example, all users in Australia
could be configured to use a gateway in Sydney.
If you select Named, you are prompted to provide the Platform password that was defined
during the Platform installation.
Note: If you define Named gateways, you will need to use the Platform web interface to modify
each user account to specify which Gateway the user accesses. This should be done after
installing the gateway but before users access the named URA Gateway. Refer to the online
Help topic called Editing a User Account.
Typical If your environment only has one gateway (the default gateway defined during the
Platform installation), select Typical.
If you select Typical, skip to step 8.
4. (Named Gateway option only) If you selected Named, click Next to view the System
Information page.
5. (Named Gateway option only) Specify the following information:
The name or IP address of the computer on which you have installed the Core Services (Core
Services is a component of the Platform). Refer to Installing the Core Services on page 43 for
more information.)
6. (Named Gateway option only) Click Next.
96
4 Remote Access
3. Select either Named or Typical as the setup type.
8. Click Next to view the Choose Destination Location page.
Files\Quest Software\CAP\URAGateway, click Browse.
97
4 Remote Access
7. (Named Gateway option only) On the URA Gateway Name page, enter the name for this gateway.
This defines and creates the new named gateway.
4 Remote Access
11. Verify that the URA Gateway server will be installed according to your specifications.
12. Click Next to install the URA Gateway server.
The Setup Status page appears.
13. On the Complete page of the Install URA Gateway Wizard, click Finish.
After the URA Gateway server installation is complete, the URA Gateway Configuration dialog
box opens.
98
4 Remote Access
Note: The URA Gateway server configuration consists of a list of approved servers. Approved
servers are remote servers with which the URA Gateway server will broker a connection
for Cloud Automation Platform user communication.
99
The following identifiers can be used to specify a server:
Host name You can use regular expressions (regexes) wildcards to specify more than one host
name. For example, to describe a host whose exact name is system, specify a host name of
system. To describe every host whose name contains the string system, specify a host name
of .*system.*.
The following table lists some of the more common regex operators.
Regex Operator
100
Matches...
Any one character
The preceding element zero times or one time
The preceding element zero or more times
The preceding element one or more times
At the start of the line
At the end of the line
IP address range To grant a range of IP addresses access to the URA Gateway server, specify
the first and last addresses in the range.
IP subnet
Unique IP address To grant a virtualization host access to the URA Gateway server, specify
that consoles IP address. This tab is also where you must add your CRT Load Test server and
your Web Browser and Connectivity Test target.
4 Remote Access
14. Add to the list of approved servers each remote server with which the URA Gateway server will
broker a connection.
4 Remote Access
Warning:Saving changes to the list of approved servers disconnects all HTTP/HTTPS

tunneled users.
To add a server to the list of approved servers, perform the following steps:
a. Click the tab that corresponds to the appropriate identifier.
For example, if you plan to identify a server by specifying its unique IP address, click the By
IP Address tab.
B. Type the appropriate value or range of values, depending on the tab that you clicked.
C. Click Add.
Note: To revoke a systems ability to receive traffic from the URA Gateway server, select it from
the list of approved servers and click Remove.
15. After you list all the servers to which the URA Gateway server can establish a connection, click
OK to close the URA Gateway Configuration dialog box.
Note: For information on URA Gateway server configuration settings, see Editing URA
Gateway Server Configuration Settings on page 105.
101
If it becomes necessary to change the destination access control or otherwise reconfigure the URA
Gateway, administrators can access a configuration utility from the Start menu.
Installing the URA Terminal Client

Before you install the URA Terminal Client, see Installing and Configuring the URA Gateway Server
on page 94.
In a typical scenario, the URA terminal client is installed automatically on a remote workstation when
a user establishes a desktop connection to a Cloud Automation Platform VM from within a Cloud
Automation Platform application. Sometimes, however, the client is not installed successfully. In such
instances, it can be installed manually on a workstation.
Note: If you install the URA terminal client manually, future upgrades to the downloadable content
will not take place automatically. To upgrade content to a URA terminal client that was installed
manually, you must uninstall the client and then reinstall it.
To install the URA terminal client manually, perform the following steps:
1. From the installation media or CD, navigate to the RemoteAccess directory and double-click
URAClient.msi to launch the Install URA Client Wizard.

2. Click Next to view the Destination Folder page.
102
4 Remote Access
The URA Gateway server is installed in the directory that you specified. Make certain to configure the
external firewall to allow HTTP and HTTPS connectivity to the URA Gateway server through ports 80
and 443, respectively.
4 Remote Access
Files\Quest Software\CAP\URAClient, click Change.
4. Click Next to view the Ready To Install page.
Note: To change the destination folder, click Back to return to the Destination Folder page.
5. Click Install to install the URA client.
103
4 Remote Access
6. Click Finish.
104
There are several URA-specific configuration settings in the Platform. All Platform configuration
settings can be viewed in the CAP web interface by clicking Configuration in the left pane.
When Cloud Automation Platform is installed, the ability to edit advanced configuration settings is, by
default, disabled. However, you can edit individual advanced configuration settings using the
vcsadmin command-line utility and the appropriate commands.
Note: To prevent unnecessary and potentially disruptive modifications to the settings, Quest Software
recommends editing select configuration values only after discussing the needs and possible
impact with Quest Software Support.
To access the vcsadmin command-line utility to perform edits to URA Gateway server configuration
settings, navigate to the Cloud Automation Platform installation directory, open the Platform directory,
and double-click vcsadmin.exe. Log in to the vcsadmin command-line utility using the following
syntax:
login <user_name defined_during_CAP_Core_install> <password defined
during install>
To edit a URA Gateway server configuration setting using the vcsadmin utility, use the following
syntax:
configset <setting>=<value>
105
4 Remote Access
Editing URA Gateway Server Configuration Settings
Ura.GatewayServerIp (required)
Note: Once the URA Gateway server installation is complete, it is required that you set a new
configuration value for URA.GatewayServerIP.
Ura.TunnelConfigs
Ura.AllowConsoleAccess
Ura.ControlPlatforms
Ura.SocketGateway.Port
Defining URA Gateway Server IP or Hostname

The Ura.GatewayServerIp configuration setting communicates to the Cloud Automation Platform
view of the remote desktop (also known as the Chrome) the URA Gateway server for which you will
be tunnelling traffic. Set the value for Ura.GatewayServerIp to be either the external IP address of
the URA Gateway server that the end user would contact or a resolvable DNS name that resolves on the
client side.
You can add new hostnames or a new IP address for socket proxy, as needed, at a later time. To add
more approved servers, log in to the socket proxy server and then select Start => Quest Software =>
URA Gateway => Launch GatewayConfig.exe. Then, you must communicate such changes to the
Chrome, using the Ura.GatewayServerIp configuration setting.
106
4 Remote Access
The following topics discuss the functionality of five URA-specific configuration settings as well as
how to edit them using the vcsadmin utility:
4 Remote Access
Establishing Sequence of URA Tunnel Configurations

Cloud Automation Platform offers four methods for connecting to a deployed Cloud Automation
Platform VM via the URA Gateway server. The Cloud Automation Platforms default failover
mechanism opts for each of these methods in the following order:
1. Direct access (also known as NoOpTunnel)
2. Socket proxy
3. HTTP tunneling
4. HTTPS tunneling
For more information on these connectivity options, see Accessing a Deployed VM on page 78.
The Ura.TunnelConfigs configuration setting establishes the sequence in which the URA selects the
protocol for tunneling to the active deployment. By default, the URA attempts to connect the user to the
active deployment using the following list of protocols from left to right.
NoOpTunnel,SocketProxy,HTTPTunnel,HTTPSTunnel
Once you have decided on the prioritization of your URA connectivity options, you can use the
Ura.TunnelConfigs configuration setting to establish their new sequence from left to right. This
newly assigned order will override Cloud Automation Platforms default failover mechanism.
Sample URA Tunnel Configs Modification
To edit the Ura.TunnelConfigs configuration setting, use the vcsadmin command and list the
protocols from left to right.
To modify the order that the URA attempts connectivity to start with socket proxy, use the following
syntax:
configset Ura.TunnelConfigs=HTTPTunnel,HTTPSTunnel
This establishes a Ura.TunnelConfigs sequence of:

1. HTTP Tunneling
2. HTTPS Tunneling
107
If the Ura.AllowConsoleAccess configuration setting is set to 'true', it enables remote access via the
console to virtual machines. If the Ura.AllowConsoleAccess configuration setting is set to 'false', it
disables this connection type. The default for this configuration setting is 'true'.
To edit the Ura.AllowConsoleAccess configuration setting to disable remote access via the console
to virtual machines, use the following syntax:
configset Ura.AllowConsoleAccess=false
To edit the Ura.AllowConsoleAccess configuration setting back to the 'true' value, thereby enabling
remote access via the console to virtual machines, use the following syntax:
configset Ura.AllowConsoleAccess=true
Note: The remote access port for ESX Console is 902.
Establishing Sequence of URA Client Platforms

The Ura.ControlPlatforms configuration setting establishes the order in which URA attempts
supported client platforms. The default setting of the Ura.ControlPlatforms configuration setting
is: ActiveX,Applet.
To edit the order in which URA attempts supported client platforms, use the following syntax:
configset Ura.ControlPlatforms=Applet,ActiveX
108
4 Remote Access
Enabling and Disabling Remote Access Via the Console
The default port that the socket proxy executable listens on is 9999. To edit the value that the socket
proxy executable listens on, use the following syntax:
configset Ura.SocketGateway.Port=<value>
After you have changed the value to a user-defined port, restart the socket proxy service:
Note: The socket proxy is installed and configured as a Window service. To stop, start, or restart the
socket proxy service, open up the Windows Services applet and select Quest URA Socket
Gateway.
If you change the default port on the socket proxy gateway server, you must also contact your network
administrator to make the same port address translation (PAT) change on the network devices.
Note: Now that you have installed the URA Gateway server and set the configuration settings, it is
recommended that you test your connectivity. For instructions to test your URA Gateway
servers local and external connectivity, see Troubleshooting on page 124.
109
4 Remote Access
Changing Socket Proxy Gateway Servers Default Port
The default socket proxy listen port is 9999, and its remote access traffic is forwarded to the deployed
VM. However, in order to administer and correctly configure socket proxy, you must set the data center
firewall for port address translation of inbound connections.
Enabling and Configuring the Network Device
Cloud Automation Platform Administrators must notify the network administrators to set up the port
translation configurations for the required remote connectivity methods:
Examples:
RDP
ura.demoservers.com:3389 = ura.demoservers.com:9999
VNC
Citrix
110
4 Remote Access
Recommended Socket Proxy Network Configuration (Required for

Multiple Connection Types)
In some cases, port address translation is either not available or inconvenient to set up. In such cases,
you can set up the socket proxy gateway server to listen on the normal port for a remote connectivity
method. This requires that the firewall allow direct inbound connections to the URA Gateway server on
the normal port for that method. If the URA Gateway server is being remotely managed by that same
connectivity method, you must reconfigure the remote access server to use a different port. Since this
configuration is limited to one connection type and can interfere with local management, Quest
Software does not recommend using this configuration unless absolutely necessary.
The following instructions assume that RDP is in use for both remote connectivity into the Cloud
Automation Platform system and remote management of the URA Gateway server.
Enabling and Configuring the Operating System Default RDP Port
Because we will enable socket proxy, administrators cannot RDP into the socket proxy server without
changing the Terminal Services default port when using Remote Desktop Connection application.
Use the following Microsoft Knowledge Base article to change the default listen port. Make sure to back
up the Windows Registry and be careful when making any changes to the Windows Registry.
http://support.microsoft.com/kb/187623
1. Start Registry Editor.
2. Locate the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\
TerminalServer\WinStations\RDP-Tcp\PortNumber
3. Click the registry subkey.

Note: The above registry key is one path, which was wrapped for readability.
4. Select Edit => Modify => Decimal.
5. Type the new port number (3390) and then click OK.
6. Quit Registry Editor.
7. Restart Terminal Server.
Now, Administrators must access the socket proxy server using the new port number (for example,
ura.demoservers.com:3390).
Editing Web Browser and Connectivity Test Configuration Settings

For system requirements, see Web Browser and Connectivity Test Prerequisites on page 82. For more
detailed information about the Web Browser and Connectivity Test, see Web Browser and
Connectivity Test on page 80.
111
4 Remote Access
Simple Socket Proxy Network Configuration
vcsadmin command-line utility and the appropriate commands.
impact with Quest Software support.
To access the vcsadmin utility to perform edits to Web Browser and Connectivity Test configuration
settings, navigate to the Cloud Automation Platform installation directory, open the Platform directory,
and double-click vcsadmin.exe. Log in to the vcsadmin utility using the following syntax:
login <user_name_defined_during_CAP_Core_install> <password defined
during install>
To edit a Web Browser and Connectivity Test configuration setting using the vcsadmin utility, use the
following syntax:
For most scenarios, editing the default values is not necessary for the user readiness test to run. The
following topics discuss the functionality of three specific Web Browser and Connectivity Test
configuration settings as well as how to edit them using the vcsadmin utility:
Urt.RunConnectionTest
Urt.RdpServerIp
Urt.Email.DefaultAddresses
Enabling the Web Browser and Connectivity Test

The Urt.RunConnectionTest configuration setting enables/disables the Web Browser and
Connectivity Test. The default value is 'false'.
Note: The Web Browser and Connectivity Test will not attempt to test your connection to a VM
unless you set the value for Urt.RunConnectionTest to 'true'. You can only set the
Urt.RunConnectionTest configuration setting to 'true' if you have a test target. See
Defining Servers as Test Targets on page 112.
Defining Servers as Test Targets

In some situations, it might be required to test connectivity and browser configurations before any VM
hosts are created in a Cloud Automation Platform environment. In this case, where a VM cannot be used
as a test target for the Web Browser and Connectivity Test, it is necessary to create a test infrastructure
with servers designated as test targets for the Web Browser and Connectivity Test.
112
4 Remote Access
There are several configuration settings in the Platform that are specific to the Web Browser and
Connectivity Test. All Platform configuration settings can be viewed in the CAP web interface by
clicking Configuration in the left pane.
For instance, if your labs use Citrix, install a Citrix server or VM in the same LAN where the VMs will
deploy and, using vcsadmin, configure the Urt.CitrixServerIp and Urt.CitrixServerPort
values to reference your Citrix server. Or if your environment will use RDP or VNC, set the equivalent
values. To find the relative configuration values for each type of remote access, view the list of settings
in the CAP web interface by clicking Configuration in the left pane, and then use the Search feature to
find the appropriate setting.
Defining the Web Browser and Connectivity Test RDP Server

The Urt.RdpServerIp configuration setting contains the IP address or hostname of the Web Browser
and Connectivity Test RDP server. To edit the Urt.RdpServerIp configuration setting, use the
vcsadmin command-line utility.
Defining Additional E-mail Recipients

By default, the test results of the Web Browser and Connectivity Test are sent only to the e-mail address
designated in the To Email Address field of the Web Browser and Connectivity Test page, which
appears when you click the Is Your Browser Ready? link that appears on the Log On panel.
If you want to add additional email addresses, such as your IT administrator or whomever is responsible
for connectivity issues, use the vcsadmin utility to edit the Urt.Email.DefaultAddresses
configuration setting.
Note: This list of recipients email addresses is semicolon delimited.
Installing the CRT Load Test Server

For system requirements, see Classroom Readiness Test (CRT) Prerequisites on page 90. For more
detailed information about the CRT, see Classroom Readiness Test on page 80.
Note: If you intend to use CRT, you must install the CRT Load Test server. The URA Gateway server
must also be installed on your network. However, since the URA Gateway server can receive
hundreds of concurrent requests and load testing can interfere with interactive users accessing
virtual machines, a URA Gateway server must not be installed on the same machine that hosts
a CRT Load Test server.
113
4 Remote Access
For each remote access method used by your labs, you must install a test server or VM that uses the
appropriate protocol in the same LAN where the VMs will deploy. Also, you must configure the Web
Browser and Connectivity Test with the IP address and port number of each test server.
1. From the installation media, double-click CRTServer.exe to launch the Install CRT Server
Wizard.
Files\Quest Software\CAP\CRTServer, click Change.
5. Click Install to install the CRT Load Test server.
6. Click Finish.
114
4 Remote Access
To install the CRT Load Test server, perform the following steps:
Before you install the CRT application, see Installing the CRT Load Test Server on page 113.
Although the CRT application is installed automatically when the Training Solution is installed, you
might need to install CRT on a different server. To install the CRT application, perform the following
steps:
1. From the installation media, double-click CRT.exe to launch the Install CRT Wizard.
The name or IP address of the computer on which you have installed the Core Services
component of the Platform.
The Platform administrator password that was specified during the installation of the Platform
Core Services.
4. Click Next to view the CRT Server Information page.

5. Type the host name or IP address of the CRT Load Test server.
6. Click Next to view the Choose Destination Location page.
Files\Quest Software\CAP\CRT, click Browse.
9. Verify that the CRT application will be installed according to your specifications.
10. Click Next to install the CRT application.
11. Click Finish.
Although the CRT can be run at this time, you must specify a value for the CRT.Email.
DefaultAddresses configuration setting before the test results can be sent in an e-mail message.
115
4 Remote Access
Installing the CRT Application
Before you install the CRT client, see Installing the CRT Load Test Server on page 113 and Installing
the CRT Application on page 115.
You can manually install the CRT client if browser settings prevent the clients automatic installation.
To install the CRT client on a workstation, perform the following steps:
1. From the installation media, double-click CRTClient.msi to launch the Install CRT Client
Wizard.
Files\Quest Software\CAP\CRTClient, click Change.
5. Click Install to install the CRT client.
6. Click Finish.
116
4 Remote Access
Installing the CRT Client
There are several CRT-specific configuration settings in the Platform. All Platform configuration
settings can be viewed in the CAP web interface by clicking Configuration in the left pane.
vcsadmin utility and the appropriate commands.
impact with Quest Software support.
To access the vcsadmin command-line utility to perform edits to CRT configuration settings, navigate
to the Cloud Automation Platform installation directory, open the Platform directory, and double-click
vcsadmin.exe. Log in to the vcsadmin utility using the following syntax:
login <user_name_defined_during_CAP_Core_install>
<admin_password_defined_during_install>
To edit a CRT configuration setting using the vcsadmin utility, use the following syntax:
The following topics discuss the functionality of four CRT-specific configuration settings as well as how
to edit them using the vcsadmin utility:
Crt.Email.DefaultAddresses
Crt.Email.DefaultSubject
Crt.NetTest.ServerIP (required)
Crt.NetTest.ServerPort (required)
Note: Before you run the CRT, it is required that you first set a new configuration value for
Crt.NetTest.ServerIP and Crt.NetTest.ServerPort.
Defining Additional E-mail Recipients

CRT results can be sent to a Cloud Automation Platform administrator in an e-mail message only if you
specify the administrators e-mail address as a value for the CRT.Email.DefaultAddresses
configuration setting. Use the vcsadmin utility to edit the CRT.Email.DefaultAddresses
configuration setting.
Note: If you include additional recipients email addresses in the CRT.Email.DefaultAddresses
configuration setting, keep in mind that this list is semicolon delimited.
117
4 Remote Access
Editing CRT Configuration Settings
The Crt.Email.DefaultSubject configuration setting contains the subject line for CRT test results
e-mails. The default value is:
Surgient Classroom Readiness Test Results
To edit the Crt.Email.DefaultSubject configuration setting, use the vcsadmin utility.
Defining CRT NetTest Server IP or Hostname

Crt.NetTest.ServerIP.
The Crt.NetTest.ServerIP configuration setting contains the IP address or hostname of the CRT
NetTest Server. The default value is 0.0.0.0. To edit the Crt.NetTest.ServerIP configuration
setting, use the vcsadmin utility.
118
4 Remote Access
Defining E-mail Subject Line
Crt.NetTest.ServerPort.
The Crt.NetTest.ServerPort configuration setting contains the port number of the CRT NetTest
Server. The default value is 9999. To edit the Crt.NetTest.ServerPort configuration setting, use
the vcsadmin utility.
If you want to edit CRT configuration settings that, by default, cannot be edited, contact Support to
request the enabling of this feature.
Conducting Web Browser and Connectivity Test and CRT

The following sections detail how to conduct the Web Browser and Connectivity Test and the CRT.
Conducting the Web Browser and Connectivity Test on page 119
Conducting the Classroom Readiness Test on page 121
Conducting the Web Browser and Connectivity Test

For Web Browser and Connectivity Test System Requirements, see Web Browser and Connectivity
Test Prerequisites on page 82. For more information, see Editing Web Browser and Connectivity Test
Note: The Web Browser and Connectivity Test will not attempt to test your connection to a VM
unless you set the value for Urt.RunConnectionTest to 'true'. See Enabling the Web
Browser and Connectivity Test on page 112.
Ideally, this test is run from the machine where the class will be conducted at the same time of day when
the virtual class is scheduled to occur.
To conduct the Web Browser and Connectivity Test, perform the following steps:
1. Navigate to the application Log On page.
For example, the address might be http://10.1.1.1/QuestCAPTraining or
http://10.1.1.1/QuestCAPDemos.
2. Click the Is your browser ready? link.
Follow any onscreen instructions or click the Help link on the Web Browser and Connectivity Test
window for more information.
119
4 Remote Access
Defining CRT NetTest Server Port
By default, the results are sent to the addresses specified by the Web Browser and Connectivity Test
administrator. Enter the requested information in all fields, except for the Comments field and then
click Send Results.
Note: If you are using Internet Explorer, and the connection to a Citrix server fails, you might need to
add the Citrix server to Internet Explorers Trusted Sites zone. See Adding an Entry to Your
Trusted Sites Zone on page 88.
120
4 Remote Access
3. If the Web Browser and Connectivity Test fails or if Support requests your test results, complete
the form in the Email Results area of the Web Browser and Connectivity Test window.
For CRT System Requirements, see Classroom Readiness Test (CRT) Prerequisites on page 90. For
CRT installation instructions, see Installing the CRT Load Test Server on page 113, Installing the
CRT Application on page 115, and Installing the CRT Client on page 116.
It is recommended that you run CRT as far in advance as possible. Ideally, you would run the test when
the class is scheduled or a request has been made for on-site training, but no later than one week before
the class is delivered. This would give you the necessary visibility to make alternate arrangements in
case the location is deemed unacceptable.
Before Running the CRT

1. Before you run the CRT, you must set a new configuration value for Crt.NetTest.ServerIP and
Crt.NetTest.ServerPort. See Defining CRT NetTest Server IP or Hostname on page 118
and Defining CRT NetTest Server Port on page 119.
2. Run the Web Browser and Connectivity Test on the machine that will be used to conduct the CRT.
The Web Browser and Connectivity Test determines if a computer and the computers current
location meet the requirements to successfully connect to the Cloud Automation Platform
application. When the machine passes the test, continue with the CRT.
For instructions on running the Web Browser and Connectivity Test, see Conducting the Web
Browser and Connectivity Test on page 119.
121
4 Remote Access
Conducting the Classroom Readiness Test
To conduct the classroom readiness test, perform the following steps:

Note: Do not run any applications or CPU-consuming services while the CRT is running. For
instance, if a personal firewall or virus software that actively monitors network activity is
running, temporarily disable it until the test completes. Any unnecessary processor activity
might skew the test results.
1. Using the CRT web application address provided by the Platform administrator, navigate to the
Classroom Readiness Test page.
When you navigate to the CRT web page, ActiveX components are installed.
2. From the Classroom Readiness Test page, type 2 in the number of participants field.
3. Choose a performance profile.
The performance profile determines the bandwidth and latency values for the CRT. Default profiles
include:
Intensive Graphics Lab Use for classes where students open and close many windows and
perform graphics-intensive exercises. For example, choose this profile for classes where
students use applications such as Powerpoint or view animated graphics or Flash demos.
Minimal Graphics Lab Use for classes where labs involve minimal graphics and a nominal
amount of scrolling, mouse movement, and data entry. The bandwidth test measures the amount
of data that can be transmitted within a set amount of time. The following table illustrates the
default ranges for the bandwidth test in bytes per second.
Connection Profile
Preferred
Acceptable
Intensive Graphics Lab
40000
15000
Minimal Graphics Lab
15000
5000
The latency test measures the amount of time it takes for data to travel from the source to the
destination. The following table illustrates the default ranges for the latency test in
milliseconds.
Connection Profile
122
Bandwidth ranges in bytes/second
Latency ranges in bytes/second

Preferred
Acceptable
Intensive Graphics Lab
110
300
Minimal Graphics Lab
110
300
4 Remote Access
Running the CRT
4. Click Start the test now.

The test can take several minutes to complete.
5. In the Submit test results section, type the appropriate values in the fields.
The value specified in the E-mail address field displays as the From address in the results e-mail.
By default, the results are sent to the addresses specified in the web.config file set by the web
application administrator. However, you can send the results to additional classroom contacts by
adding values to the Results will be copied to the following e-mail addresses field. Specify
multiple e-mail addresses by inserting a space, comma, semicolon, line break, or bar ( | ) between
e-mail addresses.
All fields are required except for the Additional Notes field.
6. Click Send test results.
The e-mail content contains the classroom configuration values as well as all the sample data
returned by the test. Repeat steps 2 6, using 10 students. Then, if the class size exceeds 10 students,
repeat steps 2 6, typing the expected class size in the number of participants field.
7. Optional: If CRT is from a 2 GHz machine outside of the classroom or with a laptop, use a
classroom machine to run a test for 2 students to verify that the network path works.
If the tests pass, the classroom is ready. If the classroom does not pass the test, the administrator
analyzes the CRT results and recommends a solution.
8. Run the Web Browser and Connectivity Test on every machine in the classroom to ensure that all
the student machines can connect to the Cloud Automation Platform application.
123
4 Remote Access
Note: Additional profiles might be included in your list of profiles. Select the profile and click View
or edit profile details to see the range of values that are tested.
This section provides tips for troubleshooting URA Gateway connectivity issues.
Note: Once the URA Gateway installation is complete, it is required that you set a new configuration
value for URA.GatewayServerIP. See Editing URA Gateway Server Configuration Settings
on page 105.
Testing the URA Gateway Server Locally

Immediately after you install the URA Gateway server, it is recommended that you test your local
access to it. Using Internet Explorer or Mozilla Firefox, enter the following, using the URL of the local
machine:
Note: HTGateway is the Installation/web folder.
http://<ura_gateway_server>/htgateway
Entering this URL prompts the Windows web server, Internet Information Server (IIS), to compile the
ASP.NET application and render a URA Gateway Statistics page. If you get errors during this test, that
indicates that something went wrong either with the installation or with the automated configuration of
IIS on that machine. See Troubleshooting a URA Gateway Server Test Error on page 126.
Testing the URA Gateway Server Externally

Once you establish that you can access the URA Gateway server locally and the Gateway Statistics is
displayed, it is recommended that you test your external connectivity. Using Internet Explorer or
Mozilla Firefox, enter the following, using the external IP address of the URA Gateway server:
http://<ura_gateway_server>/htgateway
Testing Connectivity from URA to Your Approved

Server IPs
After you have confirmed that you can access the URA Gateway server locally and externally, it is
recommended that you test your connectivity directly from the URA Gateway server to your approved
server IPs. Within Cloud Automation Platform, deploy a virtual machine (VM). Then, perform a
manual RDP connection using Microsoft Remote Desktop Client to the IP address of the deployed
virtual machine.
A successful RDP connection to an active and accessible VM in the Cloud Automation Platform
environment confirms that URA is actually communicating on the network with the deployed VM.
124
4 Remote Access
Troubleshooting
Note: If you contact Quest Software support regarding testing your URA Gateway connectivity using
HTTP tunneling, your support representative might perform the following steps. This procedure
might not work with Microsoft Vista or Mac OS X.
After confirming that you can access the URA Gateway server locally and externally and successfully
connecting directly from the URA Gateway server to your approved server IPs, use the following steps
to confirm that the URA Gateway server connects to the deployed VM using HTTP tunneling:
1. If you are using ActiveX control, in Internet Explorer enter the following, using the external IP
address of the URA Gateway server:
http://<ura_gateway_server>/htgateway/testcontrol.html
If you are using the Java applet, in Internet Explorer or Mozilla Firefox, enter the following, using
the external IP address of the URA Gateway server:
http://<ura_gateway_server>/htgateway/testapplet.html
2. On the Local Proxy ActiveX Control Test Page, type the protocol you are using, followed by the
IP address of the deployed VM in the Proxy connection to destination | URL field (for example,
rdp://IP address).
You can test various protocols (for example, RDP, Citrix, or VMX for the Console) by changing the
protocol entry in that field
3. Make sure that the start terminal window automatically (must disable pop-up blocker) check
box is checked.
4. Under Settings | Tunnel mechanism, select the Tunnel through
HTTP/HTTPS (via HTTP Gateway) radio button.
5. Click the Start button under Proxy connection to destination.
A pop-up window is displayed, and the connection commences, using the HTTP/HTTPS (via HTTP
Gateway) tunnel mechanism.
If you receive an error message, proceed to the following topic, Troubleshooting a URA Gateway
Server Test Error on page 126.
125
4 Remote Access
Testing URA Gateway Connectivity Using HTTP

Tunneling
If any of the following situations occur, an error message is displayed on the ActiveX Control Test page,
stating that an error occurred while establishing a connection to the remote server through the URA
Gateway server:
URA is unable to connect to the actual gateway address;
you did not set the configuration setting with the gateway address;
you entered an incorrect gateway address in the configuration setting;
you have a networking issue;
To resolve this connectivity issue, perform the following steps:

1. Click OK to close the error message.
2. On the Local Proxy ActiveX Control Test Page, type the protocol you are using, followed by the
IP address of the deployed VM in the Proxy connection to destination | URL field (for example,
rdp://IP address).
You can test various protocols (for example, RDP, Citrix, or VMX for the Console) by changing the
protocol entry in that field
3. Make sure that the start terminal window automatically (must disable pop-up blocker) check
box is checked.
4. Under Settings | Tunnel mechanism, select the radio button that corresponds to the type of
connection that you want to test.
5. Click the Start button under Proxy connection to destination.
A pop-up window is displayed, and the connection commences, using the tunnel mechanism that
you chose.
6. In the srdp.cab Security Warning dialog, asking if you want to install this software, click Install to
download the control.
The ActiveX RDP Client Start Page opens, showing that you have successfully connected to your
destination VM using the URA Gateway server.
Addressing a Non-Responsive URA Gateway Server

Each time your URA Gateway connections use HTTP(S) or socket proxy, separate log files are created
under the Install directory (C:\Program Files\Quest Software\CAP\Logs is the default
location). These files are named HTGateway.log and SocketGateway.log, respectively. These log
files contain information about your connections as well as any errors that might have occurred. If your
URA Gateway server becomes non-responsive, use the pertinent log file to troubleshoot your HT
Gateway or socket proxy connections.
126
4 Remote Access
Troubleshooting a URA Gateway Server Test Error
If you are using Internet Explorer, and the connection to a Citrix server fails, you might need to add the
Citrix server to Internet Explorers Trusted Sites zone. See Adding an Entry to Your Trusted Sites
Zone on page 88.
Locating Socket Proxy Server Log Files

The socket proxy server log files are located in the following directory:
C:\Program Files\Quest Software\CAP\Logs
\SocketGateway.log
Testing Socket Proxy Server Connectivity

To debug end users connectivity, run the Web Browser and Connectivity Test (formerly named URT).
The link to this test can be found on the Cloud Automation Platform Login Page.
If the Web Browser and Connectivity Test fails, perform the following steps:
1. Create a C:\TEMP directory.
2. Run the Web Browser and Connectivity Test again.
3. Inspect the log files.
Active X:
Surgient_SocketProxyActiveXTunnelConfig.log
Java Applet:
Surgient_SocketProxyAppletTunnelConfig.log
Successful Socket Proxy Server Connections

2009-04-15 23:50:37.945 [3824] Testing connection to
rdp://10.12.125.133:3389
2009-04-15 23:50:37.945 [3824] Trying connection class SocketProxyConnection
2009-04-15 23:50:38.070 [3824] Connection tests OK using class SocketProxyConnection
2009-04-15 23:50:38.070 [3824] Listening on 127.0.0.1:3455
127
4 Remote Access
Connection to Citrix Server Fails
2009-04-15 23:55:00.649 [4652] Testing connection to rdp://10.12.125.133:3389

2009-04-15 23:55:00.649 [4652] Trying connection class SocketProxyConnection
2009-04-15 23:55:02.149 [4276] Thread::Join: Wait timed out
2009-04-15 23:55:21.711 [4652] .\SocketProxyConnection.cpp:98 Exception in
SocketProxyConnection::TestConnect: Exception thrown at .\Socket.cpp:99: Socket
connect failed in system connect(ura.demoservers.com:3389): A socket operation was
attempted to an unreachable host.
2009-04-15 23:55:21.711 [4652] .\SocketProxyConnection.cpp:130 Exception: An error
occurred while trying to establish a connection to the Gateway server
2009-04-15 23:55:21.711 [4652] Unable to connect using SocketProxyConnection,
exception: An error occurred while trying to establish a connection to the Gateway
server
2009-04-15 23:55:21.711 [4652] .\ProxyConnection.cpp:185 Exception: An error occurred
while trying to establish a connection to the Gateway server
2009-04-15 23:55:21.711 [4652] .\ProxyConnection.cpp:246 Exception: An error occurred
while trying to establish a connection to the Gateway server
2009-04-15 23:55:21.711 [4652] Exception in StartThread: An error occurred while
trying to establish a connection to the Gateway server
2009-04-15 23:55:21.711 [4652] Thread Thread-4 about to terminate ( Thread Id:4652)
128
4 Remote Access
Failed Socket Proxy Server Connections
This chapter discusses NAIL (Network Abstraction and Isolation Layer) and advanced networking for
more complex environments.
Networking Overview on page 130
NAIL Overview on page 135
Configuring NAIL Server Advanced Mode on page 137
Using VLAN-isolated DHCP Networks on page 141
Using Network Switch Automation on page 143
NAIL Server Troubleshooting on page 144
NAIL Diagnostics Error Message on page 146
Using NAIL Driver on page 147
Migrating From NAIL Driver to NAIL Server on page 148
129
5 Advanced Networking
Advanced
Networking
Establishing the physical and virtual networking configuration for the Cloud Automation Platform
environment requires considerations and decisions on several issues.
Considerations
Before deciding how to configure the networking for your environment, you should consider several
environmental and resource issues, including the following:
Number and size of virtualization hosts for example, if you have many small virtualization hosts
that will not host many VMs, a single application configuration might need to span several of these
small hosts. If this is the case, NAIL server in advanced mode might be required. Or if you only
have two very large virtualization hosts that can each host a large number of VMs, your multi-server
application configurations can probably reside on a single host.
Images Are your images configured for DHCP, or do they have a static IP address? Do you have
heterogeneous images (ESX and Hyper-V)? How will these images be used in the server
configurations of an application configuration (i.e. will the various types of images be mixed in a
single application configuration)? If you are using physical server images, and plan to deploy a
single image to multiple computers, you must either configure the images for DHCP or use the
legacy NAIL driver. (See NAIL Overview on page 135 for more information.)
Typical Networking Configurations

You must set up a network connection or the host server, a TCP/IP gateway, IP addresses, and most
likely a URA gateway. These values must be compatible, which means that the IP addresses that you
assign to the resource pool, must not include the IP address of the TCP/IP gateway, URA gateway, or
the host server network. Otherwise, resource pooling errors will occur.
For example, if your external network connection NIC uses External Network (Intel(R) PRO_1000 MT
Dual Port Server Adapter), 10.5.12.20, your TCP/IP gateway address uses 10.5.12.1, and your URA
gateway server address uses 10.5.100.1, ensure that 10.5.12.1, 10.5.12.20, and 10.5.100.1 are not
included in the list of IP addresses assigned to the resource pool.
Additionally, if there is a requirement for network address translation, the server configurations need to
be defined to use NAIL Server. If no NATing is required, but isolation is, VLAN-isolated DHCP
networks might be appropriate.
Depending on the type and complexity of the virtual network that you require, you can configure your
networking in a number of ways. Some of the options are:
130
An isolated, private virtual network
A launchpad configuration in which all VMs are on a single host using a virtual network, but only
one VM uses Nail Server to connect to the public, external network
A single NAIL Server virtual network on a single host
Networking Overview
An application configuration that has multiple server configurations that span several hosts
Multiple application configurations on multiple hosts with several NAIL Servers:
If network address translation is needed, specify NAIL 3 as the ethernet device type on the
server configurations so that the NAIL Server does the NATing.
If network address translation is not needed (i.e. DHCP or Static IP Addresses), but VLAN
isolation is desired, specify DHCP as the ethernet device type on the server configurations, and
create DHCP networks.
A combination environment with virtual machines using NAIL Server and physical computers
using NAIL Driver
The following diagrams illustrate four common network topologies:

Default Network
This network configuration has the following characteristics:
Static or DHCP IP addresses are used in all VMs and deployed physical servers
Open to all broadcast network traffic; no network isolation
No NAIL Server, thus no network address translation
1.
Figure 1 Typical topology using the default network
131
NAIL Server, Standard Mode

DHCP or Static IP addresses
Network address translation provided by NAIL Server
2.
Figure 2 Using NAIL Server (Standard mode) to provide network translation
132
NAIL Server, Advanced Mode

Network address translation provided by NAIL Server
A single application configuration can have server configurations on different physical hosts.
For information about using NAIL Server in advanced mode, see Configuring NAIL Server Advanced
Mode on page 137.
3.
Figure 3 Using NAIL Server (Advanced mode) to provide network translation
VLAN-isolated DHCP Networks (Using OSPF)

No network translation; IP Addresses assigned and routed by NAIL Server
NAIL Server mode can be either Standard or Advanced (use Advanced if a single application
configuration spans physical hosts)
OSPF must be enabled, and Cloud Automation Platform must have proper credentials on OSPF
router
For more information about using VLAN-isolated DHCP Networks see Using VLAN-isolated DHCP
133
Figure 4 Typical topology using VLAN-isolated DHCP Networks,

with the NAIL Server acting as the gateway
VLAN-isolated DHCP Networks (Using Switch to route IP Addresses)

No network translation; IP Addresses assigned by NAIL Server
NAIL Server must be in advanced mode
For more information about using VLAN-isolated DHCP Networks see Using VLAN-isolated DHCP
134
4.
Figure 5 Typical topology using VLAN-isolated DHCP Networks,

with the switch acting as the gateway
NAIL Overview
Virtual machines (VMs) are incapable of communicating over a network if certain identifiers are not
unique for each VM. When a VM is cloned, some identifiers are always duplicated, including the
machine name, security identifier (SID), and IP configuration.
To solve the problem of duplicate IP addresses, the Cloud Automation Platform network abstraction and
isolation layer (NAIL) uses network address translation (NAT) to provide a unique IP address for each
cloned VM on a network. With NAIL, an entire operating system (OS) stack and application, including
groups of applications, can be imaged and moved from one VM to another and from one environment
to another without any changes to the image itself.
Use NAIL if any of the following conditions is true:
Multiple copies of the same server configuration are deployed on a network and the server
configurations are not using DHCP
An isolated network is required
NAIL also uses virtual LANs (VLANs) for VMs that require grouping, as is the case when multiple
server configurations comprise a single application configuration. NAIL Server uses IEEE 802.1q
VLANs to isolate application configurations from one another and prevent duplicate host name or IP
135
Note: In version 5.3, NAIL Driver was deprecated and replaced by NAIL Server. In the
documentation, NAIL Driver is sometimes referred to as Legacy NAIL. The NAIL Driver is
required if you want to deploy a single physical server image to multiple computers and the
images are not configured to use DHCP.
By default, NAIL Server is installed in Standard mode. The standard mode is for environments where
all VMs within a application configuration are on the same physical host. If the VMs that are included
in an application configuration are spread out over multiple physical hosts, then use NAIL Server
Advanced mode. If you are implementing NAIL Server in the advanced mode, you should work with
your network administrator to select the appropriate network adapters, switches, and VLAN IDs that
are compatible with your physical network environment.
Note: In environments where a DHCP server is used for allocation of IP addresses to VMs, it is
important to ensure that the pooled IP addresses used in the Cloud Automation Platform
environment do not duplicate those used by the DHCP server.
If your platform is in a non-US time zone, then the NAIL servers will log at US/Central time
zone by default. In order to override this, before pooling your hosts, change the
NailServer.Timezone advanced configuration setting to make the nail server log in the
appropriate time zone.
136
address errors while simultaneously deploying clones of VMs. You must use VLAN IDs within the
range of 2 - 4095, inclusive.
In environments where a single application configuration will include servers that are located on
different physical computers, the NAIL Server must be configured to run in advanced mode.
NAIL (Network Abstraction and Isolation Layer) uses network address translation (NAT) to provide a
unique IP address for each cloned VM on a network. With NAIL, an entire operating system (OS) stack
and application, including groups of applications, can be imaged and moved from one VM to another
and from one environment to another without any changes to the image itself.
By default, NAIL Server is installed in standard mode. The standard mode is suitable for environments
where all VMs within a single application configuration are on the same host (i.e., the same physical
computer). Using NAIL Server in standard mode requires relatively simple networking and switch
configuration.
However, if the VMs that are included in an application configuration must be deployed over multiple
physical computers, then use NAIL Server advanced mode. In advanced mode, NAIL Server uses
VLANs to isolate application configuration instances from one another. If you are implementing NAIL
Server in the advanced mode, you should work with your network administrator to select the appropriate
network adapters, switches, and VLAN IDs that are compatible with your physical network
environment. The VLANs used must be defined as network resources and pooled in the CAP web
interface.
Note: Microsoft Hyper-V does not support VLAN trunking from a NIC to a virtual machine, so NAIL
servers cannot be used on a Hyper-V host. However, network address translation can be
accomplished in an all Hyper-V or a heterogeneous environment with the use of a utility host.
A utility host is any server running supported virtualization software that also supports NAIL
server, and is used by Hyper-V hosts for network translation services. See Using NAIL Server
with Hyper-V R2 Hosts (Utility Hosts) on page 31 for more information about utility hosts.
To implement NAIL Server Advanced Mode

Review the following steps for implementing NAIL Server in advanced mode.
Note: The following instructions assume that you have successfully installed and are running NAIL
Server in standard mode. If you are running in standard mode, then you already have defined a
default network, and you simply need to add a trunked network. However, instructions to create
the default network are still provided below. If your installation is already running in standard
mode, ignore the steps below to create the default network and follow those to create the trunked
network.
1. Configure the physical network infrastructure (i.e. the system of switches and cables used by the
virtualization hosts)
The physical network switches must allow traffic that is tagged with VLAN IDs.
See NAIL Server Advanced Mode: Physical Cabling on page 139 for detailed information
and diagrams about configuring the switches and cables.
137
Configuring NAIL Server Advanced Mode
One adapter or NIC must be cabled to a network switch port that allows access to the CAP Core
server computer and to external assets (file servers, web servers, the Internet, etc.).
The second adapter must be cabled to a trunked port on the switch that allows VLAN tagged
traffic.
3. Create two virtual networks that connect to the physical network adapters or NICs (Network
Interface Cards) on the host.
Use VMware ESX to create the two virtual networks, one for each of the following purposes:
Default network: this is the network that will be used to access external assets.
Trunked network: this is the network that will be used for VLAN traffic between the VM hosts.
Note: Make note of the exact names of the two networks, as you will need to select the appropriate
network when assigning the hosts to a resource pool in the CAP web interface.
For detailed instructions about creating these two required virtual networks, see NAIL Server
Advanced Mode: Creating Required Virtual Networks (ESX) on page 139
4. After creating the two virtual networks, alert the Quest CAP Agent on the host to the fact that two
new virtual switches have been created.
To do so, open the vcsadmin tool on the CAP Core server host, login, and run the following
command for each host:
commandrun name_of_host poll
Alternatively, you can wait for the poll cycle to occur, during which the Quest CAP Agent
communicates with the CAP Core server.
5. Unpool all hosts in the Cloud Automation Platform environment. Consider using the Maintenance
Mode feature to prevent deployments from occurring while you are changing to Advanced mode.
See Performing Maintenance on Hosts on page 162 for more information.
6. Change the Advanced Configuration setting to advanced. To change the mode to advanced,
open the CAP web interface and click System Settings in the left pane. On the System Settings
page, view the System Environment Properties area in the right pane. In the System
Environment Properties area, click the current setting for the NAIL Server Mode option, and
change to Advanced.
7. Edit each hosts details so that the new virtual networks are selected.
To do so, open the CAP web interface and click Hosts in the left pane to view the list of all hosts.
Click the name of the host from the list and on the Details page, click Edit. On the Edit a Host page,
under the Properties area, select from the Trunked Network list the new virtual network that you
defined for VLAN traffic.
8. Re-assign all hosts to their appropriate pools, and stop the Maintenance Window, if it was started.
138
2. Connect the physical host (where the VMs reside) to the physical network switch.
Physical hosts are cabled as shown in the diagram below. Configuring the physical network
infrastructure as described here is the first step in implementing NAIL Server in advanced mode.
For an overview of all required steps, see To implement NAIL Server Advanced Mode on page 137.
The following diagram shows the configuration for a two-port host (VMware or Microsoft Virtual
Server (MSVS).
9.
In addition to using the cabling descriptions above, the following steps must be done to configure the
port on the physical switch that will be used for the trunked network:
Create the required VLANs on the switch. These VLAN IDs must match the VLAN ID ranges that
are defined as network resources in the CAP web interface.
Set the allowed VLAN IDs for the port. Again, these IDs must match those defined as network
resources in the CAP web interface. Furthermore, be sure to exclude any VLAN IDs that are used
as native VLANs on the default networks.
Enable BPDU filtering on all ports that the trunked NIC will connect to.
Enable 802.1q trunking on the port.
Set the bridge priority to a value less than 32999 (which is the NAIL server's bridge priority).
NAIL Server Advanced Mode: Creating Required

Virtual Networks (ESX)
Using NAIL Server in advanced mode requires the existence of two virtual networks, a default network
for external communication and a trunked network for VLAN-tagged traffic between virtual machines
within a deployed application configuration. Use the following instructions for creating these networks
in VMware ESX 3.5 or 4.x.
Note: If your environment uses DVS (Distributed Virtual Switch), refer to the Workflow Summary
on page 173 about configuring vCenter and creating the default and trunked networks using
DVS. DVS is required if you implement High Availability.
139
NAIL Server Advanced Mode: Physical Cabling
To create the default network

1. Open the VMware client (Virtual Infrastructure Client for 3.5 or vSphere client for VMware 4).
2. Select the VMware ESX server that you want to configure in the left pane.
3. Click the Configuration tab.
4. In the Hardware area, click the Network Adapters link. View the network adapters and
determine which vmnic is connected to the default network on the physical switch.
5. In the Hardware area, click the Networking link.
6. The Network Configuration displays on the right.
7. To create the new default network, click the Add Networking... link.
The Add Network Wizard appears.
8. In the Add Network Wizard, under the Connection Type area, select Virtual Machine, and then
click Next.
9. Select Create a virtual switch and select the vmnic that is connected to the default network.
10. Click Next.
11. Under Port Group Properties, define the Network Label. This is the name of the default virtual
network that will appear in the CAP web interface when you pool the VM host.
Note: Leave the VLAN ID field blank. Do not assign a VLAN ID to this port group.
12. Click Next.
13. On the Ready to Complete page, review the Summary and click Finish.
To create the trunked network

1. Open VMware Virtual Infrastructure Client.
2. Select the VMware ESX server that you want to configure in the left pane.
3. Click the Configuration tab.
4. In the Hardware area, click the Network Adapters link. View the network adapters and determine
which vmnic is connected to the trunked network on the physical switch.
5. In the Hardware area, click the Networking link.
The Network Configuration displays on the right.
To create the new trunked network, click the Add Networking...link.
140
For an overview of all steps required to implement NAIL Server in advanced mode, see Configuring
NAIL Server Advanced Mode on page 137.
6. In the Add Network Wizard, under the Connection Type area, select Virtual Machine, and then
click Next.
7. Under Create a virtual switch, select the vmnic that is connected to the physical adapter for the
trunked network.
8. Click Next.
9. Under Port Group Properties, define the Network Label. This is the name of the trunked virtual
network that will appear in the CAP web interface when you pool the VM host. Quest Software
recommends that you name the network Trunked Network.
10. In the VLAN ID field, enter 4095. This value causes the network to accept all VLAN IDs, which is
required by NAIL Server in advanced mode.
11. Click Next.
12. On the Ready to Complete page, review the Summary and click Finish.
After completing the above steps, the two new virtual networks that you created are shown in the
networking diagram on the Configuration tab of the Virtual Infrastructure Client.
Next Step: Return to step 4 of Configuring NAIL Server Advanced Mode on page 137.
Using VLAN-isolated DHCP Networks

Using VLAN-isolated DHCP networks are recommended or required for several scenarios.
Servers (physical or virtual) that are externally provisioned by HP Server Automation require
DHCP for the initial network boot process (PXE). Using isolated DHCP networks would normally
prevent the VMs and physical servers on that network from receiving broadcast traffic, including
the netboot traffic. With Cloud Automation Platforms VLAN-isolated DHCP networks, the
Platform performs the role of managing IP addressing and routing traffic between servers that are
outside of the isolated network and the servers on the isolated network.
Additionally, in an environment using virtual images with non-static, DHCP addresses, you might
want to use an isolated DHCP network. This allows the servers included in the application
configuration to communicate with one another on a dedicated, isolated network without
interference from servers that are in other deployments, nor from broadcast network traffic.
When using isolated DHCP networks, use the CAP web interface to create one or more DHCP networks,
a type of network resource, such as DHCP networks, IP address ranges, and VLAN ID ranges. The
DHCP networks must be pooled, just as other network resources are, before they can be used. For more
information about creating network resources see Chapter 9, Physical and Network Resources, on
page 207.
Implementing VLAN-isolated DHCP Networks

There are two ways to configure isolated DHCP networks:
141
The Add Network Wizard appears.
Dynamic/OSPF: Using OSPF (Open Shortest Path First) and enabling Cloud Automation Platform
to perform both the DHCP addressing and network routing.
Static/Switch: Using the physical switch to provide network routing, while Cloud Automation
Platform provides DHCP addressing services for the isolated DHCP network.
Using OSPF (Dynamic/OSPF Option)

To implement VLAN-isolated DHCP networks using OSPF, use the following procedure:
1. Enable OSPF on the switch that is used to connect external users to the virtualization hosts on the
network.
2. Verify that the Advanced Configuration Nail.DhcpGatewayMode setting uses the value
nailserver, not switch.
3. The default network needs to be in the OSPF backbone area (Area 0).
4. In the CAP web interface, create one DHCP network range (the NAIL Server will divide the range
into subnets as needed). Ensure that the network range is large enough to accommodate the three
IP Addresses that are required for the address network, the broadcast address, and the gateway
server, in addition to an IP address for each VM or physical server on the network.
5. Create at least one VLAN ID range.
6. Configure one Trunked network if using Advanced mode for the NAIL Server. For more
information, see Configuring NAIL Server Advanced Mode on page 137.
Using the Switch as a Gateway (Static/Switch Option)

In this scenario, OSPF is not enabled, the physical switch provides the network routing services, and
Cloud Automation Platform still provides the DHCP addressing services.
While performance is typically faster with this scenario, much more detailed pre-deployment
configuration is required, because all required network ranges and VLAN IDs will need to be created
in advance. Quest Software recommends using this implementation only if your environment cannot
use OSPF.
To implement VLAN-isolated DHCP networks in an environment where OSPF is not used, use the
following procedure:
1. Verify that the Advanced Configuration Nail.DhcpGatewayMode setting uses the value switch,
not nailserver.
2. Configure one Trunked network (NAIL Server Advanced mode is required to use the Static/
Switch option). For more information, see Configuring NAIL Server Advanced Mode on page
137.
3. Create one VLAN ID range.
142
The first IP address immediately following the network address in each DHCP range must be
assigned to the Gateway. This is true no matter which way the DHCP networks are implemented.
When pooling network resources (see Chapter 9, Physical and Network Resources, on page 207),
be aware that a single pool can either use isolated DHCP networks or use NAIL Server for normal
network translation.
When using the OSPF option, the default network needs to be in the OSPF backbone area (Area 0).
If this requirement cannot be met, then the following steps will need to be performed (contact Quest
Support for more details):
Pool all the content hosts first
Note down the IP address assigned by the platform to each pooled NAIL server
For each of these IP addresses, set up virtual links on the backbone router to the dynamically
configured networks on the NAIL server, using the default network as the transit area. Use the
NAIL server IP address as the router-id of these dynamic networks (i.e., the networks that come
and go when a deployment is setup/torn down, respectively). Consult your switch vendor's
documentation on OSPF to accomplish this. The following example shows how this may be
done on a Cisco 3750:
area <default-network-area-id> virtual-link <nail-server-ip>
Edit the ospfd.conf.vm template file under the Platform\Templates directory on the
machine where the ServiceHost.exe is installed to add virtual links from the dynamically
configured networks to the backbone area via the default network as the transit area. Under the
"router ospf" section, add the following line:
area <default-network-area-id> virtual-link <area-0-router-id>
If OSPF authentication is desired, then contact Quest Customer Support for additional
assistance
Using Network Switch Automation

If your environment will use VLAN-isolated DHCP networks and physical provisioning to HP Server
Automation-managed physical computers, you must configure network switch automation.
Note: To use network switch automation, the NAIL Server must be running in advanced mode. See
Configuring NAIL Server Advanced Mode on page 137.
1. In the HP Network Automation (HP NA) user interface, register the switches (add the devices) to
be managed. (Skip this step if already done.)
143
4. In the CAP web interface, create one DHCP network for each VLAN that is configured on the
switch
3. In the CAP web interface, describe the cabling and networking topology by defining the physical
server NIC properties Switch Address and Switch Port. See the online Help for detailed
instructions to define these NIC properties on the Physical Provisioning Details page for the
server.
If any of the server configurations included in an application configuration have an ethernet device
defined but that is not connected to a network (on the server config, you selected Not Connected
in the Virtual Network list for an ethernet devices virtual network), then those network adaptors
are, by default, connected to VLAN 1. To specify a different VLAN ID, use the vcsadmin to set a
new ID for the advanced configuration setting
PhysicalServer.NetworkAutomation.ParkedVlan. See Using the vcsadmin Utility on
page 38 for more information about using vcsadmin.
Refer to System Requirements on page 11 for details about the physical switches supported by
Cloud Automation Platforms network switch automation feature.
NAIL Server Troubleshooting

The following diagnostics charts address two possible errors you might encounter when using the NAIL
server:
Host cannot be added to a resource pool
The guest agent on a VM doesnt register with the Platform server
Unable to Add a Host to a Pool

The following errors related to pooling a host could occur:
144
An error stating that the NAIL server agent on a host has not registered with the Platform server
after 600 seconds, it is most often the result of one of the following two problems:
The NAIL server's assigned pooled IP address is incompatible with its host's default network
(if the 'Use Pooled IP Address' option was chosen when the host was added to the pool).
The NAIL server was not able to obtain an IP address from a DHCP server (if the 'DHCP' option
was chosen when the host was added to the pool).
The STP (spanning tree protocol) configuration for a host in advanced mode is incorrectly inactive;
thereby disabling the bridge interface
The STP state of the NAIL server host has an incorrect root bridge; check that the switch is properly
configured to pass BPDUs for using the advanced mode of NAIL.
2. Using the vcsadmin utility, run the vcsadmin command networkautomationenable to enable
HP NA switch automation for Cloud Automation Platform. See Using the vcsadmin Utility on
page 38 for more information about running vcsadmin commands.
Refer to the following diagnostics workflow to troubleshoot the error.
Figure 6 Diagnostic workflow for unsuccessful pooling issue
Guest Agent Does Not Register

If an error occurs stating that the VM was successfully started, but that the guest agent of the VM did
not register with the Platform server after 600 seconds, refer to the diagnostics workflow below.
145
4.
Figure 7 Diagnostic workflow for guest registration issue
NAIL Diagnostics Error Message

For sessions using NAIL Server, a post-deployment process is automatically enacted to determine if any
networking issues occur, and to collect NAIL server logs, deployment group and app/server config
details upon failures.
Some of the common issues that would be diagnosed automatically include:
146
Incorrect image preparation (e.g., network adapters still configured for legacy NAIL driver even
though it is set to NAIL Server in the server configuration)
Server configuration mis-configuration (e.g., setting the internal IP address of network adapter 1 in
the server config to be 172.16.10.10 when it is actually 192.168.10.10 in the image)
Trunked network not connected to the trunked port on a physical switch in NAIL advanced mode
Application configuration networking is incorrect
NAIL server network adapters not starting in the correct order when rebooted
The NAIL diagnostics tool is controlled by an advanced configuration setting,

Nail.RunNetworkDiagnostics. The log file that is generated as a result of the diagnostics is
NailDiagnosticsDeploymentGroup-{0}, where {0} is the deployment group ID
Using NAIL Driver

If your environment includes physical server images that will be deployed to multiple physical
computers using the Altiris Deployment Solution, and the images are not configured for DHCP, you will
need to use NAIL Driver to avoid network conflicts. That is, if a single physical server image that is not
DHCP-configured is deployed to multiple computers simultaneously, NAIL Driver is required to
translate the IP address of each image to a unique address that can be used externally.
Note: NAIL Server (or NAIL 3) is not supported with physical server images.
For detailed networking information about configurations for using NAIL Driver, refer to the
Cloud Automation Platform online Help.
The NAIL Driver runs on Windows 2003 or Windows XP, 32-bit platform. Additionally, the
network connection on the NAIL Driver host must be named Local Area Connection.
During the process of creating a physical server configuration, you must select NAIL 2 in order to use
NAIL for IP address translation. (NAIL Driver is also referred to as NAIL 2.) If you select DHCP, be
sure that the image is configured for DHCP.
For detailed instructions to create a physical server configuration, refer to the Cloud Automation
Platform online Help.
To populate the physical server configuration creation page with the choice of NAIL 2, you must have
first set the NAIL.EnableLegacyMode advanced configuration setting to true.
Use the following instructions to do so:
1. Launch the vcsadmin utility by double-clicking the vcsadmin.exe file in the installation directory
on the Platform server. By default, this directory is Program Files/Quest Software/
Platform.
login <userid> <password>
By default, the user ID is admin. The password is the Cloud Automation Platform administrator
password that was defined during the Platform installation.
147
configset NAIL.EnableLegacyMode=true
Masquerading
Server configurations can be created with MAC address masquerading enabled. When a server
configuration with masquerading is reserved, a fixed, user-assigned MAC address is configured within
the guest OS on the VM. Masquerading enables one or more VMs to use the same internal MAC
address. Externally, the network sees the actual virtual MAC address, which is uniquely assigned to
each cloned VM. While internally within a guest VM, each clone sees the masqueraded MAC address.
Note: To use masquerading, the deprecated legacy NAIL Driver must be included in the images.
When an application configuration is bound to a fixed MAC address, you can use MAC masquerading
to ensure that all deployed VMs use the same, fixed MAC address. When you enable MAC
masquerading, the new or disguised MAC address is seen by the OS network stack and used when
commands like ipconfig are run. For example, if your VM uses an application that assigns a MAC
address to trace the number of installed licenses, assign a MAC masquerade value that matches the
MAC address assigned by the application.
Migrating From NAIL Driver to NAIL Server

This section discusses the essential steps required to remove NAIL driver from an application
configuration, then adjust the configuration to work with NAIL server.
Note: Be aware that if a server configuration with NAIL driver is using MAC masquerading,
migrating to NAIL server might break the configuration.
There are three phases to the process of migrating from NAIL driver to NAIL server:
Preparation
Optimization
Integration
Phase 1: Preparation
Before you update any application configurations, verify that the Surgient_Image_Tool.iso file is
in the system library. This is the same .iso that is used to prepare images for use in the Cloud Automation
Platform environment.
If the Surgient_Image_Tool.iso file is not already in the /Images/Templates directory in the
library, copy it into the library from the Cloud Automation Platform media that you used to install the
product.
148
3. After logging on, enter the following command and then press Enter:
Phase 2: Optimization
Now that the Surgient_Image_Tool.iso is in place, you can start updating the images and
application configurations. The last upgrade you did, as long as it was 5.3 or later, automatically
populated your new installation with your previous application and server configurations that used
NAIL Driver. While these configurations will still deploy, they will need to be updated to take advantage
of NAIL Server.
To begin, select an application configuration which needs to be updated and create a session for it.
Deploy the session normally. Once the reservation is available, check to insure console access is enabled
for all virtual machines deployed with this session.
Once console access is enabled, launch the console page for the VM and log in normally:
Finally, use the Attach Media option to attach the Surgient_Image_Tool.iso. Run the
appropriate optimizer ISO image (Windows or Linux, virtual or physical). This is the same process as
preparing images. See Preparing Images on page 195 for detailed instructions.
The Image Optimizer Express tool should automatically launch once the ISO image is attached. If it
doesnt, youll need to navigate to the Surgient_Image_Tool.iso, and manually start
Express.exe, which is included in the .iso file.
Once the optimization process completes, the express runtime will display a compact HTML report
using Internet Explorer.
Most tasks should succeed. Obvious exceptions are steps which uninstall a particular piece of software
(which a later step re-installs).
Once youve reviewed the report, close Internet Explorer. The express runtime should now launch the
Disk Inspector.
The tool reports a variety of interesting facts about the current system. take special note of the network
configuration. Youll want to write these values down, or take a screen shot. Once youve recorded the
network information, stop the VM.
If there are multiple virtual machines in the application configuration, repeat the optimization process
on each of them. When all the images are complete, use the CAP web interface to save the new
configurations. Click Sessions in the left pane. On the Sessions Details page click Active Reservation
Actions... and select Save As from the menu.
Select names for the new application and server configurations. Monitor the reservation details screen,
and wait for the save process to complete.
149
In the CAP web interface, click Images in the left pane (the Navigation pane). The Images area displays
a table of all images in all library locations. Verify that the Surgient_Image_Tool.iso is shown in
the list. If not, click the Re-Sync button to refresh the library contents.
Now that the updated disk images are stored in the system library, you can begin updating the related
configurations.
Find the newly-created application configuration. Write down (or take a screen shot of) the component
server configurations.
For each of the server configurations, edit the network configuration. To do so, click Server
Configurations in the left navigation pane, and then in the list of server configurations, click the blue
menu icon beside the name of the server configuration and select Edit.
If the original server configuration used NAIL driver, the Ethernet Device 0 checkbox under Network
Adaptors area will display NAIL 2.
Select NAIL 3 instead. In the IP Configuration area, enter the IP address information you recorded from
the Disk Inspector.
Add and configure any additional network adapters. When youre done, save the updated server
configuration.
The Save As process will have automatically created a new application configuration. Add the updated
server configurations, and save.
Once youve successfully deployed and tested the new application configuration, you can safely delete
the original configurations.
Note: Any client snapshots and sessions that were created previously will still refer to the original
configurations.
150
Phase 3: Integration
This chapter addresses the following topics:
Moving an Existing Library Location on page 152
Migrating the Agent Services and RSM on page 153
Configuring Storage and Shared Access on page 155
Managing Virtualization Hosts on page 161
Performing Maintenance on Hosts on page 162
Recovering and Managing Missing Items on page 164
Using the Dashboard on page 166
Recommendation-Based Migrations on page 169
Manually Migrating an Active VM on page 169
Using High Availability with VMware vSphere on page 170
Physical Provisioning on page 176
Installation for a Secure IIS Service Account on page 178
Editing Advanced Configuration Settings on page 178
151
6 Configuration and Administration
Configuration and
Administration
The vcsadmin command librarymove can be used to move library content from one location to
another. The main purpose of this command is to support the ability to move the library location that
was defined during the original installation (now possibly too small ) into a larger directory.
Moving library content includes physically copying files from the source location to the destination
location, then adjusting all affected server configurations and snapshots to point to the new files at the
destination location. The librarymove command can optionally delete source library files and/or the
source library itself after everything has been successfully moved to the destination. The move
operation involves copying very large files, so it could take hours or even days depending upon the size
of the library in the source location.
Note: The destination location is not created as part of the move operation; it must first be created in
the CAP web interface. Refer to the online Help topic Adding a New Library Location.
Because moving a library can take a long time, it is not required that activity on the CAP Core server
cease while file copying is in progress. The source library is fully functional until the very end of the
move operation, when the script begins modifying objects in the database. Because CAP Core server
activity is continuing during the move, it is possible that the move script will encounter circumstances
that prevent it from completely finishing the move. In that case an email is sent describing the problem.
To recover, the user need only a) remove the blocking circumstance (e.g., cancelling a reservation) and
b) run the same move operation again. The move script will resume where it left off without duplicating
any file copying or other work that was completed during the first invocation.
Deployments that are in the "Available" state are allowed and will continue to work normally during
and after a library move. However, if any deployment is in an active phase (e.g., provisioning,
deprovisioning, saving a snapshot, etc) the script will exit to prevent unexpected deployment failures.
Using the librarymovestatus command, it should be possible to predict with some accuracy the
time at which the copy procedure will finish and the script enters into its critical database update phase.
As a best practice Quest Software recommends that Cloud Automation Platform administrators try to
ensure that no active deployment automation occurs during this last phase of a move.
To use vcsadmin to move a library location, follow these steps:
on the CAP Core server . By default, this directory is Program Files/Quest Software/
Platform.
2. When the vcsadmin utility opens, log on by typing the following and pressing Enter:
By default, the user ID is admin. The password is the Cloud Automation Platform administrator
password that was defined during the installation.
3. After logging on, use the following syntax (providing the name of the server where the library is
currently, the directory path of current library, the server name of the new library location, and the
exact directory path):
152
Moving an Existing Library Location
The following vcsadmin commands support this feature:
librarymove: starts the operation, which is performed in the background by an automation script.
When the move is complete, an email is sent to the user that requested the move.
librarymovestatus: use to monitor the progress of the move operation.
librarymovecancel: use to cancel an in-progress move operation.
librarylist: use to show a list of all existing library locations.
To see additional information about any of the library commands, enter help <name_of_command>.
Migrating the Agent Services and RSM

In some cases, the Agent Services component of the platform needs to be migrated to another server.
For example, if you installed all components of the platform on a single computer, you might later
decide to move the Agent Services component to another computer in order to increase throughput and
handle more virtualization hosts.
Note: The Agent Services component includes the Remote Server Manager (RSM), the Agent
message forwarder, which functions as the mailbox for the CAP Core server, and the Agent
message processor, which parses agent documents.
To migrate the Agent Services component from one computer to another, perform the following steps:
1. Uninstall Agent Services on the computer where it is currently installed:
a. Open the Control Panel and start Add or Remove Programs.
B. Click on Change for Quest Cloud Automation Platform.
C. In the Installshield Wizard, select Modify and click Next.
D. Uncheck the Agent Services feature and click Next.
E. Enter the Control Service information and click Next.
F. Click Next in the following panel to uninstall the Agent Services.
2. After uninstalling the Agent Services on the first computer, you should immediately use the
following procedure to create a redirecting Mailbox location on the same computer (where the
Agent Services was originally installed).
To redirect the Mailbox location, you can either run the SAR.exe file that is included in the
installation media, or perform the following steps to manually redirect the location:
A. Start the Internet Information Services (IIS) Manager on the first computer
153
librarymove <options> <sourceServerName> <sourcePath>

<destinationServerName> <destinationPath>
C. In the Virtual Directory Creation Wizard, click Next.

D. Enter the value ingress for Virtual Directory Alias and click Next.
E. Enter the directory C:\Inetpub\wwwroot for the web site path and click Next.
F. Accept the default Permissions and click Next.
G. Click Finish in the final pane.
H. Right-click on the new virtual directory named ingress and select Properties.
I.
Select A redirection to a URL under the Virtual Directory tab.
J. Enter http://<IP_address>/ingress/Mailbox.aspx in the Redirect to... box where

<IP_address> is the address of the target computer, where you will next install the Agent
Services.
K. Click OK to save the changes.
3. Install the Agent Services on the target computer.
a. Run the Setup.exe installer.
B. Select the Standard installation type.
C. Clear all features except for Agent Services.
D. Enter the IP address of the machine the Control Service is running on (the first computer where
Agent Services was installed).
E. Enter the username and password of the user account that will run the Agent Services.
F. Click Next in the following dialog boxes to complete the installation.
154
B. Right click on Default Web Site and select New -> Virtual Directory.
Depending on the storage and network access architecture used in your environment, and the type of
images and library content, there are several different ways to configure the storage and shared access
for your environment.
Refer to the following sections for detailed information about the various supported configurations.
Note: The next three sections outline the suggested practices for storing and sharing content in
environments in which the content type (.vmdk, .vhd. ,img, etc.) will be stored and accessed
from the same type of host; a homogeneous environment. For options in a heterogeneous
environment, in which the image types and files for an ESX host might be stored on a Hyper-V
server, or vice versa, see Using Heterogeneous Host and Storage Types on page 160.
Using VMWare VMFS in a SAN-based Configuration

Cloud Automation Platform enables a shared, SAN-based VMFS file system to serve as a library
location for VMware ESX hosts. All hosts that have direct access to the VMFS LUN will be able to run
images directly from the library without requiring NFS. Using a shared library location on a SAN-based
VMFS file system reduces VM deployment times by eliminating the need to copy files locally to the
virtualization host. Existing investments that customers have made in Fibre Channel or ISCSI networks
can be utilized directly.
As a suggested best practice, separate storage areas (local VMFS, a separate LUN on the SAN, or a
unique directory on the shared VMFS LUN) for each virtualization host can still be used to store redo
files and snapshots for each host.
Considerations
Review these notes about using VMFS:
If your environment does not include a SAN, you can select an NFS-enabled server as the library
location. For more information, see Using NFS In a Network-Attached Storage Configuration on
page 157
All ESX 3.5 and ESXi 3.5 servers that use iSCSI must be configured to support the VMkernel Port
(see Configuring the VMkernel Port on page 158).
The maximum number of hosts that can connect to a single VMFS volume is 32.
The LUN on which the VMFS volume resides cannot be larger than 2 TB nor can the volume span
LUNs.
Cloud Automation Platform requires Hardware Version 4 or version 7 double-file VMDK format
for all .vmdk files. Refer to Converting Hardware Versions for .vmdk Files on page 201 for
instructions to use a vcsadmin script to convert files.
155
Configuring Storage and Shared Access
A VMFS directory can also be used as a shared file cache location on the SAN. All of the
considerations noted for defining the library location on the SAN also apply to creating a shared file
cache. For additional information, see the CAP web interface online Help topic Adding New File
Cache Location.
To use a VMFS volume on a SAN as the library location, perform the following steps:
Before installing the Platform:
1. Create the volume on the SAN server that you want to use as the library location.
2. Verify that SSH access is enabled for the ESX host.See Configuring ESX Hosts on page 27.
3. Select which virtualization host will be the library server.
4. Configure the selected ESX host to connect to the SAN server. See Configuring the ESX Host
and SAN Server on page 156.
After installing the Platform:
5. If the ESX host that will be the library server has not already been registered with Cloud
Automation Platform, register the server as a remotely managed host. Refer to Registering a
Remotely Managed Host in the online Help for detailed instructions.
6. If the host will be used as both a library server and a virtualization host, use the CAP web interface
to edit the host configuration to perform the following tasks. If not, and the host will only be used
a library server, skip to step 7.
Specify the Default Network and the Trunked Network.
Select the Dedicated File Cache Volume.
Specify the Root VM Volumes directory where the VM configuration files and redo files will
be created. This directory could be on a local disk or on a dedicated VMFS volume on the SAN.
Refer to the online Help for detailed instructions about editing a host.
7. Create the new library location. Refer to the online Help for detailed instructions.
Configuring the ESX Host and SAN Server

Before using the CAP web interface to add a library location or file cache location on a VMFS volume
of a SAN (storage area network), the VMware ESX or ESXi host needs to be configured to connect with
the SAN server.
Note: The following section outlines the basic steps required, and refers to the use of iSCSI protocol
for communication between the ESX server and the SAN. The specific steps required in your
environment might be different.
156
2. Log on to the SAN server management interface and add the ESX host as a client.
3. Using the SAN server management interface, map the ESX host to a volume on the SAN server.
Note: When using a SAN VMFS volume as a library location, a single volume is shared by multiple
ESX hosts (maximum of 32). Be aware that the LUN on which the volume resides cannot be
larger than 2 TB nor can the volume span LUNs. Using a shared library location reduces VM
deployment times by eliminating the need to copy files locally to the ESX server.
4. On the ESX host, scan for new VMFS volumes. This process should be done whenever changes
are made to the volumes available to your ESX server.
a. Login to ESX server using the VI Client or vSphere Client.
B. In the Configuration tab, click Storage Adapters in the Hardware list.
C. Right-Click the iSCSI Software Adapter item and select Rescan.
D. In the Configuration tab, click Storage in the Hardware list.
E. Click the Refresh link to see the new VMFS volume.
If you are connecting to a volume that has not been formatted, do the following steps:
a. Click the Add Storage... link to add the LUN
B. Select Disk/LUN for the type of storage
C. Follow the prompts to format the volume with the VMFS file system
Warning:
Do not Remove the datastore from the Storage locations. This permanently deletes all
of the files on the volume which makes them unavailable to the other servers that are
sharing the volume. If you want to disconnect the ESX server from the SAN server,
disable the Storage Adapter.
Using NFS In a Network-Attached Storage

Configuration
A storage device that is selected to act as an NFS system library or shared file cache must support the
NFS access protocol. The Remote Server Manager and ESX hosts access the device through an NFS
exported path.
For ESX servers to remotely access the NFS server, the following conditions must be met:
The NFS volume used for the file cache or library location must be exported by the NFS server.
157
1. Log on to ESX server using the VI Client or vSphere Client and enable the iSCSI Software Adapter
on the ESX host. This process adds the IP address of the SAN server to the ESX hosts list of
connected storage devices, so that the ESX host is aware of the SAN server.
Access permissions on the NFS server must be set so that the library location or file cache location
is accessible by the ESX host server.
All ESX 3.5 and ESXi 3.5 servers must be configured to support the VMkernel Port (see
Configuring the VMkernel Port on page 158).
For a detailed list of supported NFS platforms, refer to the VMware ESX documentation.
ESX Storage Access Permissions

The NFS client username and UNIX uid presented to the NFS server is root/uid:0. Be aware that
VMware does not support changing the NFS client userid and uid used to connect to an NFS server.
Configuring the VMkernel Port

Any ESX 3.5 or ESXi 3.5 host servers that will access a remote file cache or system library location on
a SAN or NAS over iSCSI must be configured to support the VMkernel Port. Configuring these hosts
is best done using the VMware Infrastructure Client.
Note: This procedure does not need to be done for ESX 4 or ESXi 4 hosts.
To download and install the Client, use the following procedure:
1. In a Web browser, type the IP address of the ESX host.
2. Click Download the VMware Infrastructure Client.
3. Run the downloaded installer and accept all default settings.
To configure the ESX server, use the following procedure:
1. From the Start menu on your local machine, select Programs -> VMware -> VMware Virtual
Infrastructure Client
2. Log in to the ESX server.
3. In the tree view on the left, highlight the server.
4. Click the Configuration tab on the right.
5. In the Hardware panel, click Networking.
6. Click Add Networking in the upper right corner to open the Add Network Wizard.
7. Select the VMkernel radio button and click Next.
8. In the Network Access window, you can choose to create a new virtual switch or use an existing
switch, then click Next.
9. Enter a routable IP address, subnet mask, and gateway address, then click Next.
10. Verify the connection settings and click Finish.
158
Hyper-V R2 hosts use Cluster Shared Volumes (CSV) on a SAN (Storage Area Network). Using SAN
for image and file storage requires the Failover Cluster technology of Hyper-V. All Hyper-V R2 hosts
are added as nodes to the failover cluster.
Additionally, after the cluster is defined and the hosts are specified, add the shared volume on the SAN
as a cluster shared volume. This shared volume must be accessible from every Hyper-V R2 host in the
failover cluster. This shared volume is used to define system library locations and shared file cache
locations in the CAP web interface. For more information about defining library locations, refer to the
online Help.
Note: The user account that was used to install the system library and the remote credentials used to
manage the Hyper-V hosts must have read/write permission on the shared volume.
When adding a library or shared file cache location on a Windows Server 2008 R2 computer,
you cannot select a witness disk as the library location. Volumes that are eligible for
locations, that are of the type "NTFS (Cluster Shared Volume)", must begin with the path:
"C:\ClusterStorage".
As a best practice, Quest Software recommends that if you use a single computer to act as both
a virtualization host and a library server, you should pool less RAM for running VMs. Estimate
the amount of RAM required for the library server role, taking into consideration the number of
files, frequency of snapshots, etc., and subtract that amount from the total server capacity. Also
subtract enough for the servers operating system and normal functions. Pool the resulting
amount.
Hardware Requirements
Hyper-V R2
At least 3 network adapters:
One dedicated to access to the SAN (the storage network)
One dedicated to managing the host (the host network)
One dedicated for the VMs (the default network)
One trunked network if running in advanced mode (the trunked network)
SAN subsystem
Domain controller that is compatible with the Hyper-V R2 hosts (at least Windows Server 2003)
Software Requirements
Microsoft iSCSI Initiator, if using iSCSI (available by default on Windows Server 2008 and later)
159
Using Clustered Shared Volumes for Hyper-V R2

Hosts
Following Roles:
File Server
File Server Resource Manager
Following Features:
Fail Over Clustering
Multi-path IO
Remote Server Administration Tools (File Server Resource Manager Tools and Fail Over
Clustering Tools)
Using Heterogeneous Host and Storage Types

In some situations, if your environment includes both Hyper-V and ESX hosts, you might need to use
a more complex architecture. Using mixed host and storage types is not the recommended option, but
does allow for a flexible heterogeneous configuration.
Be aware that while using a heterogeneous environment can increase flexibility, there are costs, such as
increased time to copy files between dissimilar server types.
The following table illustrates how the different types of library content can be stored and accessed in
a heterogeneous environment.
File Cache
Location
Library Content
Library Location
Hyper-V (.vhd files)
ESX host with VMFS or

NFS
Local (on the virtualization host) or on CSV to

which the Hyper-V host
has access.
ESX (.vmdk files)
Hyper-V with CSV
ESX host with VMFS or

NFS
Altiris (.img files)
Windows Library on local

storage or on a remote
CIFS share
N/A
Note: Altiris .img files cannot be managed on a library location on an ESX host or a remotelymanaged Hyper-V host.
160
After the initial setup of the Cloud Automation Platform environment, you might need to add or modify
virtualization hosts. This section explains how to manage changes to virtualization hosts.
There are several options for reconfiguring virtualization hosts. Using the CAP web interface, you can
make the following changes:
Change the default network on page 161
Pool or unpool the host on page 161
Test Communication on page 161
Change the maximum number of VMs for a host on page 161
Change RAM allocation on page 162
Modify the amount of Pooled EPUs on page 162
Performing Maintenance on Hosts on page 162
Change the default network

You can modify which NIC the VMs are routed through by changing the default network setting for the
host. The default network setting ensures that VMs bind to the correct network adapter, usually one with
external connectivity.
Pool or unpool the host

Virtualization hosts (including their RAM, VMs, and EPUs) must be added to a resource pool before
the host can be used in the Cloud Automation Platform environment.
Test Communication
Use the Test Communication feature to verify that communication between the virtualization host and
the CAP Core server is successful. See the online Help for detailed instructions.
Change the maximum number of VMs for a host

When pooling a host, you can specify the number of VMs that can be created on that host. If you increase
RAM allocation from a host, or if you change the hardware profile for an application configuration,
change the maximum number of VMs for that host. To calculate the maximum number of VMs, divide
the total pooled RAM for the host by the minimum hardware profile size (256 MB). For example, if the
amount of pooled RAM for the host is 3072 MB, and the minimal hardware profile is 256 MB of RAM,
then the number of VMs that this host would contribute to the pool is 12.
161
Managing Virtualization Hosts
Change RAM allocation

You can edit the amount of RAM allocated for VMs in a pool. To do so, use the Manage Pooling feature
to modify the Pooled RAM value.
Note: If you change the RAM allocation, also change the maximum number of VMs for a host server.
Otherwise, you might artificially limit the number of VMs for that server. For instance, if you
initially specify a hardware profile that uses 512 MB of RAM, the maximum number of VMs
available on your host that has 1024MB of RAM is two. If you change the server to use 2 GB
of RAM, your host can now support a maximum of four VMs. However, unless you edit this
value, the host will create only two VMs.
Modify the amount of Pooled EPUs

When you assign a host to a pool, you are required to specify how much computing capacity the host
can contribute to the pool. Effective Processor Units (EPUs - EPU pronounced like CPU) are a
computational value which governs the overall computing capacity of a Host, Physical Computer, or
Server Configuration. The default value for these units are derived with the following formula:
EPUs = Speed of CPU(s) in GHz * the number of cores * 100
For example, 2.5 GHz Quad-core host would have 1000 EPUs (2.5 * 4 * 100 = 1000 EPUs).
Note: There is an option on each hardware profile to forcibly cap the computing capacity that can be
used by the server configuration. Unless the Forcibly Cap Computing Capacity check box is
selected, the system will allow occasional fluctuations above the number of EPUs that are
specified for the Pooled Computing Capacity.
Performing Maintenance on Hosts

You can perform maintenance on virtualization hosts or physical computers on a scheduled basis by
taking the system out of circulation, upgrading it, and returning it to circulation without disrupting
existing reservations. Typically, this operation is performed for hosts or physical computers that require
upgrades or basic maintenance on the OS, virtualization software, or the drivers.
Refer to the Cloud Automation Platform online Help for detailed instructions about using these features.
Note: It is not necessary to unpool a host or physical computer before scheduling it for a maintenance
window.
162
Note: If you edit the maximum number of VMs for a virtualization host and then later change the
hardware profile, you might artificially limit the number of VMs for that virtualization host. For
instance, if you initially specify a hardware profile that uses 512MB of RAM, the maximum
number of VMs available on your host that has 1024MB of RAM is two. If you change the
hardware profile to use 256MB of RAM, your host can now support a maximum of four VMs.
However, unless you edit this value, the host will allow only two VMs.
Maintenance Windows (host-specific): one or more hosts are selected for a specified maintenance
window. When a host is targeted for maintenance, the host is reserved for the period of time that you
specify. No sessions or snapshots can be deployed to the host during that time. Essentially, the
virtualization host is not available in the resource pool for the duration of the maintenance window.
When an administrator creates a maintenance window, the system checks to see if there are any
conflicting reservations; that is, if any sessions are scheduled to start or still be running during the
requested maintenance window. If there are conflicting sessions scheduled, the administrator must
choose how to manage these conflicts. (Refer to the online Help for details about resolving
conflicts.) After any conflicts have been resolved, the host is reserved for the requested maintenance
time period and no sessions or snapshots are deployed to that server during that time. If the time
period that was requested is not available, the system suggests alternate, available times.
For detailed information about creating a maintenance window for virtualization hosts, see the
online Help topic Adding a Maintenance Window for A Host.
For detailed information about creating a maintenance window for physical computers, see the
online Help topic Adding a Maintenance Window for A Physical Computer.
If your environment uses High Availability, review Using High Availability with VMware
vSphere on page 170.
For conceptual information about creating a maintenance window and using High Availability
to migrate all VMs from a host that is a member of a HA pool, refer to Creating a Maintenance
Window for High Availability Hosts on page 175.
Finally, refer to the online Help for detailed instructions about how to create a maintenance
window.
Maintenance Mode (with optional Pause Mode): A platform administrator can use the
maintenance mode to provide a system-wide period during which no sessions can be deployed.
When the Cloud Automation Platform environment is placed in maintenance mode, users are
temporarily disallowed from logging on to the system. The regular login panel is replaced with a
notice that the platform is undergoing maintenance and the expected time the system will be
available again. Non-administrative users who are already logged in the system at the time the
maintenance mode is started can continue to access their sessions, and can take actions such as
snapshots, migrations, etc. Non-administrative users cannot deploy sessions immediately (Start
Now), though sessions can be scheduled for a future time after the maintenance mode has
completed. Non-administrative users cannot extend a session. If a session is canceled,
deprovisioning does not occur until after the Maintenance Mode has ended.
Platform Administrators retain full functionality, and can start a session immediately (Start Now)
or can schedule a session to start at any time. Platform administrators can also make snapshots,
promote snapshots, initiate migrations, etc.
With the optional Pause Mode (which is set using the check box on the Maintenance Mode dialog
box) all of the above about Maintenance Mode still applies, with the additional fact that nonadministrative users cannot do actions such as snapshots, promotions, or migrations. Notifications
are displayed if there are any deployments in Pending or Available state when the Pause Mode
starts.
163
The following features support maintenance of hosts:
Upgrade Window (system-wide): a platform administrator can create a system wide upgrade
window that places all pooled hosts into a maintenance window. If there are any conflicts with
scheduled or active deployments, the administrator is prompted to resolve each. When an upgrade
window is created, the system is also automatically placed in maintenance mode. When creating the
upgrade window, the administrator can specify that the system exit maintenance mode when the
upgrade window is completed. However, the upgrade window is independent of the maintenance
mode; the administrator might choose to have the upgrade window complete but leave the
maintenance mode in place, meaning that new users will not be able to log on but current users will
have access to hosts.
Recovering and Managing Missing Items

Due to hardware or infrastructure outages, items such as virtual networks, VMs, files, or storage
volumes are sometimes inaccessible from the Cloud Automation Platform environment. The Platform
considers such items as missing. The missing resource might have been literally removed (a file was
purposefully deleted outside of the Cloud Automation Platform environment) or a resource appears to
the Cloud Automation Platform system to have been deleted but was not really (for example, a VM was
migrated using vCenter, in which case Cloud Automation Platform is unaware of the VMs new
location, and thus considers it to be missing). Another example is if connectivity is lost to an iSCSI
volume; all files on that volume would be reported as missing by Cloud Automation Platform, and
would appear listed on the Item Recovery page.
The primary purpose of this feature is to alert administrators to any items that are no longer accessible
by Cloud Automation Platform, but are required for successful deployment and management of the
environment. Administrators can view the Item Recovery page to see a list of all items that Cloud
Automation Platform considers missing, including such information as type (image, virtual network,
VM, or volume), the exact name of the item, and the host that managed the item. Additionally, any lists
or tables elsewhere in the CAP web interface that reference the missing object display an alert icon
beside the missing items name.
Important Considerations
164
Missing items can be handled in one of several ways through the CAP web interface and in your
infrastructure. A file that was deleted accidentally can be restored to the file system using tools
outside of Cloud Automation Platform. Missing volumes can be remounted (again, outside of Cloud
Automation Platform). Other infrastructure objects that the Platform considers as missing might be
remedied in a number of ways outside of Cloud Automation Platform.
Quest Software strongly recommends that before deleting an item using the Delete option on the
Item Recovery page, you fully research the item and determine if the object was purposefully
deleted outside of Cloud Automation Platform, and if deleting the item will cause an adverse impact
to scheduled deployments or resource allocation. For example, if an image that is used by an
upcoming reservation is shown as missing, and you delete the item through the CAP web interface
rather than trying to recover the object, the reservation will fail, as will all subsequent deployments
that use the image.
If you chose to delete items, remember to resynchronize the library afterwards. If an item is been
Refer to the online Help for detailed directions for using Pause Mode.
When an item is recovered instead of deleted, and Cloud Automation Platform is again aware of and
can access the item, the item is no longer listed as missing and deployments using the item are
successful.
After restoring a file or other missing item, use the Re-Sync option on any of the applicable
resources:
Images To resynchronize the library objects, click Images in the left pane, under Library,
then on the Images page click Re-Sync.
Hosts To resynchronize a host that might have been impacted by a missing item such as a
VM, click Hosts in the left pane, and then select Re-Sync Host from the drop-down menu
beside the host name.
Partner extension servers (HP-SA, Altiris, vCenter) To resynchronize partner extension

servers, click Partner Extensions in the left pane, and then select Re-Sync Extension Server
from the drop-down menu beside the host name. For example, if a virtual network is considered
missing and is then re-established, re-synchronizing the partner extension server could recover
the network.
A single file in a library on shared storage will have separate entries in the Item Recovery table for
each host that shares the storage. Be aware that if you delete a file from the Item Recovery page,
the entries for the other hosts still remain. For instance, if three hosts share the same storage that
holds an image, and the image file is marked as missing by Cloud Automation Platform, the Item
Recovery page will display three entries for that image, one for each host. To delete the file from
the Item Recovery page, each entry in the table must be deleted separately, and the library
resynchronized.
When an item is listed as missing on the Item Recovery page, some procedures in Cloud
Automation Platform can continue as normal. For example, if you are modifying a server
configuration that uses a missing image file as the boot source, you can edit attributes of the
configuration (excluding the image file that Cloud Automation Platform considers to be missing)
and save the changes. However, there are certain actions that cannot be done on a missing item.
The most significant impact of missing items is that deployments and future reservations might not
succeed.
The following actions cannot be done on missing items:
Virtual Machines
Not available for reservation or deployment binding
Most deployment actions not available for an active deployment based on the Virtual
Machine
Files
Cannot be used for creating / editing Server Configurations
165
deleted using the Item Recovery page, cleanup operations are completed and any internal references
to the item are removed (server configuration references are removed, etc.).
Cannot be used for Post-Deployment actions
Will not be used by a file cache
Volumes
Cannot be used for library or file cache locations
Cannot be specified as a VM root directory location
Using the Dashboard

Using the Infrastructure Dashboard, administrators can manage and view graphic representations of
resource pools, virtualization hosts, physical computers, VMs, NAIL Servers, and other components of
the Cloud Automation Platform environment. The Dashboard allows users to quickly understand the
overall usage pattern of the cloud at various levels of detail as well as provide tools to search and isolate
workloads based on a variety of parameters.
Additionally, the Dashboard provides the ability to initiate VM migrations from one host to another
while graphically depicting the impact on other scheduled workloads. Migrations can either be
manually initiated (see Manually Migrating an Active VM on page 169), or an administrator can
approve and initiate migrations that are recommended by an external system such as VMwares
Distributed Resource Scheduler (DRS). See Recommendation-Based Migrations on page 169.
Figure 8 Infrastructure Dashboard
Only Platform Administrators and Organization Administrators can access the Dashboard. Nonadministrative users will not see the Dashboard entry in the navigation pane.
Review the following information about using the Dashboard:
166
In order to view the Dashboard, you must have Microsoft Silverlight installed.
Recommendation-based migrations are supported only on ESX vSphere hosts.
Hosts that have no assets pooled (RAM, VMs, EPU, etc.) do not appear in the Dashboard.
The results of VM migrations (recommendation-based or manual) are recorded in the Cloud

Automation Platform reporting database, allowing for the creation of migration reports.
Navigating the Dashboard

Access the Dashboard from the CAP web interface in the same way other Cloud Automation Platform
features are, from the navigation pane on the left of the product interface.
The objects (resource pools, hosts, VMs, etc.) that are displayed in the Dashboard are organized in
levels. The top level, displayed when the Dashboard first opens, is the Cloud, which displays all
resource pools in the environment. The next layer displays the hosts that are assigned to the selected
pool, and then the final layer shows the VMs and NAIL Servers on each host.
Review the following important tips about navigating within the Dashboard. For comprehensive
instructions, refer to the online Help system.
Breadcrumbs At the top of the Dashboard, a breadcrumbs feature allows you to easily see
where you are, and to navigate backwards one or more levels by clicking on the level name. You
can also use the Back icon to navigate up the levels.
Menu icon in upper right of each object Each object displayed in the Dashboard has a context
menu icon (
) in the upper right. Click this icon to access a menu of all tasks related to the
object. For example, if you click the menu icon of a virtualization host, and select Explore Host,
all of the VMs and NAIL Servers that are active on that host appear.
Drilling down by clicking object name Clicking the name of the pool or host at the upper left of
the object also drills down a level. For example, click the name of a host to display all of the VMs
and NAIL Servers that are active on that host.
Sorting Use the Sort feature at the top of each Dashboard panel to display the objects (at any level)
based on such attributes as name, RAM, and number of VMs and EPUs, and then sort the items in
ascending or descending order.
Search The Search feature at the top of each Dashboard panel allows you to search for deployed
VMs, Physical Servers, and NAIL Servers. Additionally, an administrator can use the context menu
on a VM or NAIL Server to do a Quick Search for related VMs and NAIL Servers; for example, all
VMs and NAIL Servers that are active within the same active session, or all VMs that are supported
by the a specific NAIL Server.
Viewing utilization graphs At all levels, from the resource pool down to individual VMs, you
can view utilization graphs based on amount pooled and amount used for such assets as RAM, VMs,
and EPUs. If a host is overcommitted because of resource allocations made outside of the Cloud
Automation Platform environment, the usage bars for RAM and VMs are red.
167
Tasks outside of the Dashboard Some menu options and links within the Dashboard open pages
outside of the Dashboard. For example, selecting Go to Details Page from a hosts menu will open
the Host Details page in the CAP web interface, outside of the Dashboard. You can easily return to
the Dashboard by clicking Back in the browser.
Dashboard Tasks
The following list shows the administrative tasks that one can do in the Dashboard. For comprehensive
instructions for each task refer to the online Help system.
View all resource pools in the environment (the Cloud level)
View details for each resource pool

Pool Inspector Displays high-level information for each host.
Go To Details Page Opens the Host Details page outside of the Dashboard; shows more
detailed information.
View all hosts in a resource pool
View details for each host
168
Inspector Displays high-level information for each host.
Go To Details Page Opens the Host Details page outside of the Dashboard; shows more
Search for:
All deployed VMs, physical servers, and NAIL Servers
Quick Search: Session Displays all VMs and any Nail Server that comprise a session. The
VMs and NAIL Server might be distributed across different hosts.
Quick Search: NAIL Server If accessed from a VM, displays the NAIL Server that serves that
VM and all VMs, on any host, that are managed by the NAIL Server. If accessed from a NAIL
Server, shows the NAIL Server and all VMs that it serves, on any host.
Quick Search: Lab Displays all VMs and any Nail Server that comprise a lab. The VMs and
NAIL Server might be distributed across different hosts.
Quick Search: Deployed Service Displays all VMs and any Nail Server that comprise a
deployed service. The VMs and NAIL Server might be distributed across different hosts.
View utilization graphs for a resource pool, a host, a VM, or a physical server. At any level of the
Cloud, click the green buttons at top to view graphs representing how much RAM, EPUs, and how
many VMs (at the host level) are in use.
View migration recommendations View and approve or cancel migrations that are recommended
by an external system such as VMwares Distributed Resource Scheduler (DRS). See
Recommendation-Based Migrations on page 169.
View a list of reservations that conflict with recommended migrations, and select resolutions
for each.
Migrate VMs Manually migrate VMs to another host, or approve migrations recommended by the
system. See Manually Migrating an Active VM on page 169 for more information.
Manage virtualization hosts and individual VMs:
Test communications between hosts and the CAP Core server.
Create a new maintenance window for a host.
For VMs, perform a rollback, restart, start/stop, or suspend.
Recommendation-Based Migrations
Integration with VMware vSphere enables the Cloud Automation Platform to recognize and implement
VM migration recommendations from other virtualization products, such as VMwares Distributed
Resource Scheduler (DRS). Using the Infrastructure Dashboard, administrators can view and manage
VM migrations, as well as perform other administrative tasks.
When a migration is recommended, you can verify that the migration will not adversely affect any
scheduled or active reservations by clicking the Check Recommendation button. If there is a session
conflict, or any other reason for the Cloud Automation Platform system to counter the recommendation,
that information is displayed.
Cloud Automation Platform can operate in two modes for handling migration recommendations,
Automatic or Manual. To specify which mode the Cloud Automation Platform system uses, open the
CAP web interface and edit the Migration Recommendation Mode setting on the Pools Details page.
Automatic, in which migrations that are recommended by services such as DRS are automatically
implemented by Cloud Automation Platform, with no interaction with an administrator needed.
Manual, also referred to as Gatekeeping mode. The manual mode requires that a Cloud Automation
Platform administrator review each recommendation, and either approve or reject one.
To enable Cloud Automation Platform Manual mode, use the vSphere Client to set the DRS
Automation Level for the cluster to Manual.
Note: For more information about configuring the DRS automation mode in see Workflow
Summary on page 173.
Manually Migrating an Active VM

You can also manually migrate an active VM, outside of the Recommendations window. To do so, drill
down to the VM level in the Dashboard, click the menu icon on the VM, and select Migrate from the
context menu.
169
Refer to the online Help system in the CAP web interface for detailed instructions.
Using High Availability with VMware vSphere

Integration with VMware vSphere allows users to specify selected virtualization hosts as belonging
to a High Availability (HA) resource pool. This ability provides extended management of the Cloud
Automation Platform environment, especially in the area of failovers and migrations of VMs and host
resources.
Review the following sections about Cloud Automation Platform High Availability:
Failing Over to Another Host on page 170
Important Considerations on page 171
High Availability Host Requirements on page 172
Failover Host Requirements on page 173
Workflow Summary on page 173
Creating a Maintenance Window for High Availability Hosts on page 175
Note: For information about migration of specific VMs based on recommendations of other products,
such as VMwares Distributed Resource Scheduler (DRS), see Physical Provisioning on page
176.
Failing Over to Another Host

Using the Cloud Automation Platform High Availability feature, vSphere hosts are assigned to a
resource pool that is specifically for HA hosts. If the host computer fails, or is scheduled for a
maintenance window, any VMs on the host computer are migrated to another, functional host computer.
Cloud Automation Platform uses VMware vMotion technology to perform live migration of
running VMs.
Note: Be aware that all VMs on the host are migrated to the failover, or standby, host. Additionally,
the VMs are migrated to a single failover host, and cannot be distributed to multiple failover
hosts.
170
When an administrator requests to migrate a VM from within the Dashboard, the Migration View is
displayed, with a list of possible target hosts. The target hosts that are available display a green check
mark beside them.
Manually, by using the CAP web interface to modify the Host Details page. Refer to the online Help
for details.
As part of a scheduled maintenance window. (See Creating a Maintenance Window for High
Availability Hosts on page 175.)
Using an external tool that calls the SOAP API to automatically invoke the failover process. For
example, an external tool determines that a host in the Cloud Automation Platform High
Availability pool is no longer functional. The tool can then instruct Cloud Automation Platform to
initiate failover. See Using the SOAP API To Manage Failovers on page 176.
When a failover occurs, the failover host assumes that all of the roles of the host that failed; any active
and scheduled reservations are moved to the failover host, and the pooled capacity of the failed host is
adopted by the failover host. In a maintenance window scenario, an administrator can specify that when
the failed host is again functional, it is automatically pooled as a failover host for future failovers.
If the failover attempt using vMotion technology is not successful with the first VM, the live migration
is aborted. A cold migration is then attempted, in which the VMs are powered off, migrated to the
failover host, and then restarted. If both live and cold migrations of the first VM fail, the entire
migration effort is stopped.
If the first VM migrates successfully (either live or cold), but the second or any subsequent VMs fail to
migrate, a replacement VM, basically an empty slot, is put on the failover host in order to retain the
allocated resources. In this scenario, any changes to the image that were made to redo files, etc., are lost.
For additional important information about configuring vCenter to support Cloud Automation Platform
High Availability and about vMotion compatibility with Cloud Automation Platform, refer also to
Workflow Summary on page 173.
Only ESX 4 or 4.1 and ESXi 4 or 4.1 hosts that are managed by vCenter 4 can be used as High
Availability hosts.
To use the High Availability feature in Cloud Automation Platform, the NAIL Server mode must be
Advanced, not Standard. See Configuring NAIL Server Advanced Mode on page 137 for detailed
information.
When a virtualization host is added to a Cloud Automation Platform High Availability resource
pool, its assets (RAM, VMs, and EPU) can only be added to a single pool. Partial pooling is not
supported for High Availability pools. See Resource Pools on page 208 for more information
about partial pooling.
An administrator must ensure that there are a sufficient number of failover, or standby, hosts.To
create a failover host, open the hosts Pool Host page by click Manage Pooling. Select the Pool for
High Availability check box. Then select the Is Failover check box. Refer to the online Help for
detailed instructions.
171
Failover can be initiated in three ways:
A Cloud Automation Platform resource pool can span multiple VMware clusters, but there must be
at least one failover host from each cluster.
Every host in the High Availability pool must be HA-compatible. See High Availability Host
Requirements on page 172.
If both the HA host and the failover host are powered on and accessible, VMs are migrated live
to the failover host. If the high availability host is not functional, the VMs are shut down and
restarted on the failover host, and the Cloud Automation Platform administrator will receive an
email when the VM is again available.
Failover hosts cannot be used for deployments; they are essentially on standby waiting to be used
if failover is initiated. Thus, when pooling a failover host, you cannot pool any of the assets for the
host, because they are reserved for use in a failover scenario.
A Failover host cannot be used to manage a shared file cache location nor a library location.
If a host that is placed in a maintenance window also serves as a library host or manages a file cache,
you can select whether to migrate the library or file cache to the failover host along with the VMs,
or to another host.
Physical computers (managed by Cloud Automation Platform, Altiris, or HP SA) can be assigned
to a High Availability pool, but cannot be designated as a failover host nor as a highly available host.
The support of physical computers in HA pools allows for application configurations that might
include both virtualization hosts and physical hosts. An example of such an application
configuration is one with a database server hosted on a physical computer plus two VMs (both
hosted on ESX 4 using High Availability): a software application running on one VM and a web
server running on the other VM.
When assigning a host to a High Availability pool, and using the Required Computing Capacity/
EPU feature, be cognizant of CPU differences in an HA pool. Specifically, verify that a CPU
reservation on a pooled HA host can be satisfied on any of the failover HA hosts.That is, the core
speed of the failover hosts needs to be sufficient to host the largest possible CPU reservation granted
on a pooled host, and the maximum aggregate reservations on a pooled HA host need to be
satisfiable on any failover HA hosts.
High Availability Host Requirements
172
Each host must be:
A member of a VMware cluster that also has at least one host that is designated in Cloud
Automation Platform as a failover host
In a Cloud Automation Platform resource pool that is designated as High Availability
CPU compatible with the failover host as required by vMotion or other virtualization vendor.
Cloud Automation Platform storage must be shared by all hosts in the cluster:
VM root directories
Dedicated file cache locations
Library and shared file cache locations
Note: The file cache and library locations must be on a shared VMFS or NFS volume.
The Default and Trunked networks must be on a Distributed Virtual Switch (DVS) shared by all
hosts in the cluster.
The Host must have a VMware Enterprise Plus license (required for DVS support).
No virtual device on any VM (e.g. one of its virtual CD-ROM drives) can be connected to a physical
device on the host (e.g. the actual CD-ROM device on the host).
These requirements are validated by the Cloud Automation Platform, and appropriate messages are
displayed in the CAP web interface.
Failover Host Requirements
The computer that will act as the failover, or standby, host must be:
In the same High Availability pool as the hosts it is intended to support.
In the same VMware cluster as the hosts it is intended to support.
CPU compatible with the host(s) in the same pool.
Failover hosts should have at least as many cores as the maximum number of vCPUs called
for by hardware profiles deployed to the HA pool in question.
Failover hosts should have fast enough clock speeds such that the largest EPU hardware
profiles divided into the clock speeds of the fastest non-HA hosts are still supportable on
the failover hosts.
The failover host cannot have any shared file cache locations nor library locations on any of its
volumes.
Workflow Summary
The following steps must be taken to implement High Availability in Cloud Automation Platform:
Configure vCenter:
Create a Data Center if not already extant.
Create and configure vCenter clusters.
173
VMware Distributed Resource Scheduler (DRS) should be configured for Cloud

Automation Platform-managed VMs in a manner that supports how you will use the
Recommendation-based Migrations feature in the CAP web interface:
To review and approve all DRS-recommended migrations through the CAP web
interface, set DRS to Manual.
To review and approve all DRS-recommended migrations through the CAP web
interface, and to allow DPM to power automatically relocate VMs at power-on time, set
DRS mode to Partially Automated.
To allow DRS migrations to occur without receiving any notifications via the CAP web
interface, set DRS mode to Fully Automated.
Settings such as Isolation Response can be configured according to administrator
preference. Cloud Automation Platform will disable the specific VMs that are Platformmanaged.
Configure the Power Management (DPM) setting in the DRS cluster to Off. Alternatively,
if you set DPM to Manual or Automatic for the cluster, you can override the DPM setting
for any hosts that are included in the Cloud Automation Platform environment. If your
environment requires using DPM, contact Quest Software about possible product
extensions that allow DPM implementation.
Configure the cluster Swapfile Location to store the swapfile in the same directory as the
VM.
The vCenter registered host name must match the hostname used to register with Cloud
Automation Platform (fully-qualified domain names in vCenter are fine).
Edit cluster settings to enable EVC for Intel/AMD as necessary, and set EVC to a level
compatible with all hosts in that cluster. If the host CPUs are identical, EVC may not be
necessary. Consult vMotion documentation for more details.
Add your hosts to the vCenter cluster.
Configure networking:
Note: Cloud Automation Platform requires 2 NICs, one for the Default network and one for the
Trunked network. The vMotion, Management, and storage requirements can be configured
as desired.
174
Create a VMkernel port that is enabled for vMotion.
Must have unused host NICs (1 per host per DVS) available. (Verify that there is no
vSwitch using the NIC, delete it if so.)
Create two Distributed Virtual Switches (DVS); one for the default network and one for the
trunked network. Use the Inventory->Networking view.
Rename the port groups created (dvPortGroup). Quest Software recommends that the
names include default and trunked, as appropriate. These name will appear in Cloud
Automation Platform as options for the trunked network and the default network.
For the trunked port group, set the VLAN Trunking as necessary.
Configure shared storage (this can be configured through vCenter or Cloud Automation Platform).
All hosts must have access to all VM images and other required files.
In the CAP web interface, register the vCenter server with Cloud Automation Platform, using the
Partner Extensions node in the left navigation pane. Refer to the online Help for detailed
instructions.
After registering the vCenter server, the Edit Partner Extensions page for the vCenter server is
displayed. Under the Clusters area, specify the Default Network and the Trunked Network. These
two networks were defined earlier in the vSphere client Hosts inherit Default/Trunked from their
Cluster, unless a different network is defined.
In the CAP web interface, register each vCenter-managed host, using the Register option on the
Hosts table. This registers the host with the Remote Server Manager (RSM), and enables Cloud
Automation Platform to communicate with the host. See Additional Considerations on page 18
for additional information about the RSM.
After registering each host, the Edit Host page for the host appears.
Under the Properties area, for Root VM Volumes, select the shared volume to which all
hosts have access.
For Default Network and Trunked Network, click the Auto-Select Networks
Compatible with High Availability option to use the distributed networks created earlier
in the vSphere Client. Refer to the online Help for detailed instructions.
Add virtualization and failover hosts to Cloud Automation Platform HA resource pools. Refer to
the online Help for detailed instructions.
Create and schedule the session for deployment using a High Availability resource pool. Refer to
the online Help for detailed instructions.
Creating a Maintenance Window for High Availability

Hosts
When you schedule a maintenance window for a host that is a member of a High Availability pool, you
can specify that when the maintenance window begins, the VMs on the host will be migrated to a
failover host in the same pool and the same cluster. See Performing Maintenance on Hosts on page
162 for a high-level description of maintenance windows.
On the Hosts list page, select the host(s) for which you want to schedule a maintenance window, and
then click New Maintenance Window.To implement the High Availability option, select the Use
Failover check box by each host that you want to fail over. For detailed instructions to create a
maintenance window, refer to the online Help.
175
When scheduling a maintenance window, Cloud Automation Platform checks to determine if there are
any reservations or active sessions that conflict with the specified time period of the maintenance
window. If conflicts are found, you can specify what to do with the session:
Cancel
Suspend
Migrate active VMs to the next available and compatible host
Save the session and end early
Discard changes and end early.
(If host is a member of a High Availability pool) Leave any active VMs running. The Leave
Running option designates that when the maintenance window starts and the failover occurs, the
VMs are live migrated to the failover host using vMotion.
Using the SOAP API To Manage Failovers

The SOAP API can be used to integrate with an external monitoring system to determine if a host is
inaccessible, has failed, or is in danger of failing and initiate failover of VMs for High Availability hosts.
The SOAP API requires identification of the host to be immediately failed-over and has optional inputs
for the source of the command and the reason. The following method is used:
FailoverHost(VcsRequestContext ctx, VcsHost host)
For additional information, go to:

http://<CAP_Core_Server>/QuestCAPAPI/Services/
SoapAdapter.asmx?op=FailoverHost
Physical Provisioning
Cloud Automation Platform supports the integration of the server automation products such as HP
Server Automation and Symantec Altiris Deployment Solution to manage the use of physical computers
in the lab environment. (Refer to About Partner Extensions on page 33 for information about all of
the partner extensions that Cloud Automation Platform supports.)
HP Server Automation integrates with Cloud Automation Platform to allow OS Provisioning; users can
deploy OS Sequence-based sessions to physical computers that are managed by HP Server Automation.
Use the CAP web interface to search for and register the HP SA core server(s), and then register each
physical computer managed by that core server. Then add these computers to one or more resource
pools. See External Provisioning with HP Server Automation on page 34.
176
Note: There must be at least one host designated as a failover host in order for the check box to appear,
and in order for High Availability to function.
Once a physical provisioning server is identified by the platform, you can then register any physical
computers that you want to manage through the Cloud Automation Platform environment. These
physical computers can then be pooled into a resource pool just as the VMs are, and utilized as part of
your Cloud Automation Platform environment.
Review the workflow summary under External Provisioning with HP Server Automation on page 34.
The requirements for provisioning physical computers using HP SA are included in this workflow.
If your environment uses both isolated networks and physical computers managed by HP SA, you
must configure network switch automation. See Using Network Switch Automation on page 143.
Refer to Partner Extension System Requirements on page 17 for important information.
Deployment actions cannot be run on servers that are provisioned by HP Server Automation,
because Cloud Automation Platform Guest Agents are not supported on HP SA-provisioned
servers. However, on server configurations that are not provisioned by HP SA, and against which
you want to run HP-SA Policies as deployment actions, a Cloud Automation Platform Guest Agent
must be installed on the server configuration. For more information about Deployment Actions, see
Deployment Actions on page 231.
When you provision a server (virtual or physical) using external provisioning with HP SA, you
cannot take a snapshot of the session.
To designate that an OS Sequence-based server configuration is deployed to a physical computer,

and not to a VM, select a hardware profile that species deployment to a physical computer.
Also, when creating the server configuration, select Provisioning Automation from the Assign...
list under the Boot Source area.
Symantec Altiris Deployment Solution

To deploy sessions to a physical computer that is managed by Altiris, the following tasks must have
been accomplished:
Prepare and create the physical server image (.img) using the appropriate image preparation tool.
See Preparing Physical Server Images on page 199 for detailed information.
Add the physical server image to the system library. Refer to the online Help for detailed
instructions.
177
Altiris Deployment Solution physical provisioning servers that have a Quest CAP Agent installed will
automatically identify themselves to the Platform, and display in the CAP web interface under the list
of Physical Provisioning systems.
Create a physical server configuration based on the physical server image (.img file), an application
configuration using the physical server image, and finally a session. Refer to the online Help for
detailed instructions.
Refer to the online Help for detailed information about registering, or importing, physical computers
into the Cloud Automation Platform environment and adding them to resource pools.
Installation for a Secure IIS Service Account

If you use a custom configuration of Microsoft Internet Information Services (IIS), special
consideration might need to be taken during installation of the Platform.
To employ a secure IIS configuration, you must install the Platform Core Services on a computer
separate from where the Agent Services, SOAP API and Web Application components are installed.
In this scenario, the Platform Core Services are installed under the normal Program Files directory
(or any other directory) and the remaining components (Agent Services, SOAP API, Web Applications)
are installed on a different computer under InetPub\wwwroot for the secured version of IIS.
Installing the Add-In for HP Quality Center

For detailed information about installing and using the Add-In for HP Quality Center, access the AddIn for HP Quality Center manual by clicking the Quality Center link under Documentation and
Support on the CAP web interface Workbench page.
Note: The SOAP API must be installed on the CAP Core server before you can use the Add-In for HP
Quality Center. By default, the \ SOAP API is installed with the Platform. Refer to Installing
the SOAP API on page 59 for more information.
Editing Advanced Configuration Settings

default, disabled. Quest Software recommends that the editing function not be enabled without first
contacting Quest Customer Support and discussing the needs.
To Enable Editing
on the CAP Core server. By default, this directory is Program Files/Quest Software/
Platform.
2. When the vcsadmin utility opens, log on by typing the following and pressing Enter:
login <userid>
By default, the user ID is admin.

3. Type the password, and then press Enter.
178
4. After logging on, enter the following command and press Enter:
configset AdvancedConfiguration.AllowEditing=true
5. Open the CAP web interface and in the left pane click Configuration, under System Settings.
6. On the Configuration page, verify that the Edit option appears when you click a menu icon (
in the Menu column.
To change an Advanced Configuration setting, click the menu icon beside the name of the specific
configuration that you want to edit, and then select Edit.
Note: Certain configuration settings are editable even if the
AdvancedConfiguration.AllowEditing configuration is set to False. Editable
configurations have a menu icon (
) beside the name.
179
The password is the platform administrator password that was defined during the Cloud Automation
Platform installation.
180
This chapter addresses the following troubleshooting topics:
General Troubleshooting First Steps on page 182
High I/O and CPU Rates on page 183
Log In Failures with RDP Access on page 183
Altiris Deployment Server, Suspended Scripts on page 183
Error While Adding Host to Pool on page 184
Install Microsoft IIS Before .NET Framework on page 185
Installation Error Messages on page 186
181
7 Troubleshooting
Troubleshooting
Take the following steps if you encounter problems and do not have an immediate diagnosis or
workaround.
1. Verify that the following three services are running on the Platform host where you installed the
Core Services component of the CAP Core (see page 42 for more information):
Quest CAP Control Service
Quest CAP Engine Service
Quest CAP Services Container
2. Run the Test Communication test in the CAP web interface to verify that all agents are responding
to and communicating with the CAP Core server.
3. If you plan to contact Quest Support, we recommend that you first create a .zip file of all relevant
logs. This .zip file can be very useful to the support team in diagnosing any issues. The customer
database is also automatically exported to the zip file.
To create the .zip file, perform the following steps:
a. On the computer where the CAP Core components are installed, open a command prompt
window.
B. Type the following command, with any additional parameters as needed, and press Enter.
surgient-support.exe
Optional parameters:
-numhours <number_of_hours>
Use this parameter to retrieve log data recorded since the number of hours in the past that
you enter as the numhours value. By default, the compression file includes the past 24 hours
of data.
-server <server_name>
Use this parameter to include agent logs from the specified server(s). Can be specified
multiple times.
-database
This parameter causes an export of the entire contents of the operational database in XML
format to be included in the .zip archive.
outdir <directory_name>
Specify the name of the directory where the output .zip file will be placed. The default is
the working directory.
The output file is called SurgientLogs, and includes the date and time stamp.
182
7 Troubleshooting
General Troubleshooting First Steps
High I/O and CPU Rates

If there is anti-virus software installed on the image, disable automatic full-disk scan. A full-disk scan
at boot-up or any other time once the image is in the environment can potentially cause performance and
deployment issues.
Quest Software recommends that if a full-disk scan is required, run it when building the image. Once
the image is in the Cloud Automation Platform environment, on-access scanning can be done, but be
aware that it might impact performance. Additionally, consider generating a checksum hash to verify
that the image is not modified between creation and delivery for deployment.
Log In Failures with RDP Access

Be aware that when creating an image to be imported into the Cloud Automation Platform environment,
and the image:
was created outside of the Cloud Automation Platform environment
will be used in a server configuration with Active Directory Registration enabled
will use auto-generated accounts to access the VM's remote desktop the last login must have been
to a local computer account.
This is because the server's login screen defaults to the last domain used to login, so if it was a domain
instead of the local machine it causes the auto-generated accounts to fail to login.
If this issue does occur, the workaround is to connect using console access and manually log into a local
account. Be sure to log out using a local account so that the next login using RDP will work.
Altiris Deployment Server, Suspended Scripts

The Altiris Deployment Server can be in a state in which it is not able to extract values out of the Cloud
Automation Platform-Altiris integration database (a.k.a., the token data source) and the Cloud
Automation Platform scripts with tokens in them are suspended. If this issue occurs, deployments to a
computer managed by Altiris will fail with a message such as Error 1 during script execution
from the Altiris agent. The error message will appear in the CAP web interface in the Alerts area of the
Sessions Details page.
To resolve this issue, reconfigure the Altiris Express Database system DSN (Data Source Name)
through Administrative Tools -> Data Sources (ODBC).Click on Configure and verify that all the
database settings are accurate and that the connection to the data source is valid.
183
7 Troubleshooting
For example: SurgientLogs_2010_7_17_14_49_23.zip, which corresponds to July 17,

2010 at 2:49.43 PM.
Review the following information if you receive this error message, or a similar one, while adding a
host to a pool:
Command 'Engine.Script.initialize-nail-vm' did not complete successfully
This error message occurs for a variety of reasons, including the following:
The Default Network selected when assigning the host to the pool might not have connectivity to
the network on which the CAP Core server is located.
Verify that there is not a firewall between the CAP Core server and the Default Network.
The IP Address range defined as a network resource for the pool is not valid for the Default Network
selected when assigning the host to the pool.
Modify either the IP Address range or select a different network.
If you selected DHCP for the NAIL Server Address when assigning the host to a pool, and there
is no DHCP server on the Default Network, select the Use Pooled IP Address option.
Spanning Tree Protocol (STP) is disabled for the access port on the switch into which the VM host
network adapter (associated with the Default Network) is connected.
Consult your network administrator to enable STP for the switch port.
184
7 Troubleshooting
Error While Adding Host to Pool
Installation of the CAP Core components requires that both IIS and .NET Framework are installed on
the computer before you install Cloud Automation Platform. Be sure to install IIS before installing .NET
Framework.
If IIS is installed after .NET Framework, the CAP Core components can be installed but the Agent
Message Forwarder (the Mailbox) will not run correctly. Whenever an agent attempts to access the
Mailbox web site, the following error occurs:
The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write
access to 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
Files'.
The solution for this problem is to run the Repair operation on the .NET Framework installer.
Windows 2003
1. Run the Add or Remove Programs tool on the CAP Core server.
2. Select Microsoft .NET Framework from the list of installed applications.
3. Click Change/Remove.
4. When the .NET Framework installer appears, check the Repair option and click Next.
5. Wait for the operation to complete and reboot the machine when prompted.
6. From a Windows command prompt, run
c:\WINDOWS\Microsoft.Net\Framework\v2.0.50727\aspnet_regiis.exe -i enable
Note: For 64-bit windows, run:

c:\WINDOWS\Microsoft.Net\Framework64\v2.0.50727\aspnet_regiis.exe -i
-enable
Windows 2008
1. Open the Server Manager. To do so, click Start Menu -> All Programs -> Administrative Tools
-> Server Manager
2. In the left pane of the Server Manager, click Roles.
3. In the right pane, click Add Roles.
4. In the Add Roles wizard, click Next.
5. In the list of roles, select Web Server (IIS).
The Add Roles wizard prompts for additional information.
6. Click Add Required Role Services.
7. On the Select Server Roles page, click Next to continue.
185
7 Troubleshooting
Install Microsoft IIS Before .NET Framework
9. On the Select Role Services page, click Install.

10. If prompted, click Add Required Role Services.
11. On the Confirm Installation Options page, click Install.
12. From a Windows command prompt, run
c:\WINDOWS\Microsoft.Net\Framework\v2.0.50727\aspnet_regiis.exe -i enable
Note: For 64-bit Windows, run:

c:\WINDOWS\Microsoft.Net\Framework64\v2.0.50727\aspnet_regiis.exe -i
-enable
Installation Error Messages

Review the following installation errors and solutions.
Read/Write Access to the System Library Location

Review the following information if you receive this error message, or a similar one, during the
installation process:
User does not have proper permissions to manage library or wrong password
entered.
Verify the following permissions for the user account under which the Quest CAP Agent service runs:
a. Directory permissions for the local directory on the CAP Core server
or
B. Directory and share permissions for the remote volume UNC location
Refer to Choosing a Windows Account for the Agent Service (Altiris) on page 38 for detailed
information.
186
7 Troubleshooting
8. On the Web Server (IIS) page, review the information and then click Next.
Review the following information if you receive this error message, or a similar one, during the
installation process:
Error accessing Agent Message Forwarder site: http://10.252.1.22/ingress
This is likely due to a misconfiguration of IIS or ASPNET.
Correct these issues then install again.
To resolve this issue, take the following steps:
Verify the Default Web Site in IIS. The home directory must exist and must be configured with the
proper permissions.
Run the Repair operation on the .NET Framework 2.0 installer (see instructions on page 185).
Verify that ASP.NET 2.0 is enabled. To do so, open the IIS Manager and select Web Services
Extensions, and then verify that ASP.NET v2.0 is set to Allowed.
Required Components Not Installed

If you receive the following error messages, cancel the installation and install the required software, then
install again. For information about prerequisites, see System Requirements on page 11.
Examples of error messages:
Install requires that your computer is running Windows Server 2003
Install needs .NET 3.5 to continue
Install needs IIS to continue
To install IIS, follow these steps:

Open the Add/Remove Programs panel. In the far left pane, click Add/Remove Windows
Components to launch the Windows Components Wizard. Select the checkbox for Application
Server, and then click Details. In the Application Server panel, select the checkbox for Internet
Information Services (IIS).
Install needs ASPNET to continue
This error occurs when the ASP.NET subcomponent of IIS is not enabled. To enable ASP.NET,
open the Add/Remove Programs panel. In the far left pane, click Add/Remove Windows
Components to launch the Windows Components Wizard. Select the checkbox for Application
Server, and then click Details. In the Application Server panel, select the checkbox for ASP.NET.
187
7 Troubleshooting
Error Accessing Agent Message Forwarder
(Dashboard only) If you want to use the HTTPS (SSL) protocol to access the application server (Web
Appplications component), and you will need to follow these steps before accessing the Dashboard:
1. First, enable SSL for the web site
2. Then, edit the web.config file (in <install_dir>/Platform/Web) to remove comments
around the all HTTPS endpoint entries.
To locate HTTPS endpoints that are commented out, look for the following text:
<!-- NOTE: Uncomment this to enable the HTTPS endpoint(SSL must be enabled
for the web site first)
Remove the above line and the end comment tag to enable SSL.
3. Save the web.config file and restart the browser.
If you attempt to use HTTPS and access the dashboard without following the above steps to enable the
HTTPS endpoints, you will see an AsyncCallback exception error.
188
7 Troubleshooting
Dashboard: Enabling SSL
This chapter details the file types and locations involved in image management and
explains the function of images in the Cloud Automation Platform environment.
Additionally, this chapter discusses the process of creating new images and
preparing the images for use in the Cloud Automation Platform environment.
Image File Types on page 190
Duplicating Image Files on page 193
Creating New Images on page 194
Preparing Images on page 195
Agentless Images on page 201
Converting Hardware Versions for .vmdk Files on page 201
Using NAIL Driver on Windows Images on page 202
189
8 Image Management
Image Management
Both virtual machine images and physical server images can be used in the Cloud Automation Platform
environment. Virtual machine images are used to create the VMs in the environment. Physical
server images are used to create server configurations that run on physical computers managed by a
physical provisioning system.
Note: For information about using HP Server Automation OS Sequences to create VMs, instead of
images, see External Provisioning with HP Server Automation on page 34.
Physical Server Images

A physical server image is a capture, or image, of the physical computer, both hardware and software,
from which the image was created. A physical server image does not use undo files to capture changes
made to the deployed physical server. If a user wants to rollback to the original state of the server, the
physical server image that is stored in the system library is used to recreate the original state.
Supported physical server image types are physical server images, Linux or Windows, that are created
by Altiris Deployment Solution(.img)
Virtual Machine Images

A virtual machine image is a virtual hard disk; a virtualized representation of a computers disk drive,
CD-ROM, floppy disk, or other storage device. Virtual machine images act as disk drives for virtual
machines (VMs). When a computer has multiple disk drives, multiple image files are required to recreate the machine.
A virtual machine image can include either a solitary base image or a base image plus undo files, which
capture only the changes made to the base image.
Supported image types include:
VMware ESX virtual disk (.vmdk)
Note: Cloud Automation Platform requires Hardware Version 4 or version 7 double-file VMDK
format for all .vmdk files. Refer to Converting Hardware Versions for .vmdk Files on page
201 for instructions to use a vcsadmin script to convert files.
Microsoft Windows Server 2008 Hyper-V virtual disk (.vhd)
Note: For Hyper-V images, the latest Integration Services must be installed.
The following types of files are used in conjunction with virtual machine images:
190
Base Images
Undo Files, Redo Files, and Differencing Disks
8 Image Management
Image File Types
Snapshots
ISO image files
Base Images
A base image is a file directly representing the initial state of a virtual disk drive in a VM. A single,
virtual disk drive is represented by a single base image. A base image provides the fundamental software
image for a session.
The same image can be used in multiple contexts. For instance, the same base image might be used for
several different sessions that require the same guest operating system. If the base image is an
installation of a companys newest software release, the Training department might use that image for
customer training. The same image can also be used by the Sales department to create customer
demonstrations of the software. Furthermore, the Test/QA department can use the same image as
Training and Sales to create a test environment.
Base images are stored in the system librarys templates directory in read-only mode.
During use, each base image is typically paired with a redo or undo file, which records all changes made
to the virtual drive.
Undo Files, Redo Files, and Differencing Disks

An undo file (also known as a differencing disk or redo file) is chained to a base image and records all
changes made to the virtual drive during use. The creation and contents of these files is a basic capability
of the underlying virtualization platform.
Each time an application configuration is deployed to a VM, the VM is placed in undoable or append
mode, and a new undo file is created for each virtual hard drive in the associated server configurations.
Undo files are saved on the VMs host server.
When work with a VM is completed, the recorded changes can be saved, discarded, or merged with the
base image. If the user does not save the changes from his session, the corresponding undo file is
deleted. Saved undo files are stored in the system librarys snapshots directory in read-only mode.
Cloud Automation Platform provides additional file management capabilities for snapshots.
Snapshots
A snapshot saves the changes that occur during a single user session by saving the users undo file and
a link to the original base image.
A user can save a snapshot to easily capture a specific environment, such as an OS with his applications
installed and configured. For instance, a user might want to save a snapshot before he installs a service
pack or a new software program. If a problem occurs, he can easily end the session without saving any
changes to revert to his initial environment.
Any data saved to disk or configuration settings that a user makes after a snapshot is saved will not be
restored when he reverts to the snapshot. He must save the snapshot again to preserve changes.
191
8 Image Management
When an application user saves a snapshot, it is saved from the virtualization host to the snapshots
directory on the system library.
When an application user schedules a session with a snapshot to resume his or her work in a session,
his snapshot and the image to which it is chained are deployed. The base image is attached to the VM
from the corresponding file cache location or the system library and the undo file is copied from the
system library to the virtualization host to complete the image.
Consider a test engineer conducting a software test. Once the necessary software is installed on the first
test machine, a base image is created. This image can be used to create the remaining servers for the
test. However, to more effectively test the material in the test plan, the test engineer wants to install
some additional software. The test engineer saves a snapshot, which chains the undo file that contains
the software to the base image. The test engineer can deploy a session with his snapshot, which specifies
both the base image and undo file. Once the test engineer creates and saves the final test configuration,
you can promote the base and undo images to the system library as a single, merged image file.
You can promote a snapshot using the CAP web interface. When you promote a snapshot, a new image
is created based on the original image and includes the changes from the users undo file. If the snapshot
is based on multiple server configurations, a new base image is created for each server configuration.
Server configurations and application configuration are also created. The new images, server
configurations, and application configuration are available in the system library. New images are saved
to the templates directory on the system library.
The following figure shows the platform objects and images before and after an snapshot is promoted.
User environment
with a snapshot
Newly created platform

objects and images
after promotion
Application
configuration
#1
New application
configuration
New server
configurations
that are linked to
the corresponding
base images
Server
configuration
#1 and #2
Base image
#1 and #2
New base
images that
merge base #1
with snapshot #1
and base #2 with
snapshot #2
Snapshot
#1 and #2
Figure 1 Promoting a Snapshot on Platform Objects and Images
192
8 Image Management
Note: If a user saves a session and then saves the session again, the initial snapshot is overwritten.
Whether or not a user can save a snapshot is determined by the persona associated with the user. You
can also set the maximum space allowed for snapshots per user and per organization. For details, see
Quotas on page 250.
ISO Image Files

An ISO image is a virtualized copy of a physical CD or DVD media disk and can contain many file
systems. An ISO file is stored in the templates directory in the system library and can be mounted to
a VM as part of the application configuration.
Using the CAP web interface, you can use the Attach Media option to mount an ISO file. Additionally,
an application administrator can mount an ISO file from the file repository. You can mount ISO images
to update disk images at any time.
Note: Attaching ISO images is not supported for physical servers.
Using the CAP web interface, you can select a deployed session and then attach media to that VM. This
attaches a CD-ROM, DVD, or ISO device to the deployed VM and the user can access the files on that
drive. For more information, see Managing Sessions on page 235.
Alternatively, instead of attaching the ISO to a server configuration, you can include the ISO in a library
to which users have access. A user accesses the file repository, copies the ISO locally and mounts the
ISO as a virtual CD or DVD driver (at which point it displays as a CD or DVD drive).
Duplicating Image Files

When an image (either a virtual machine image or a physical server image with a static IP Address) is
cloned, some identifiers are always duplicated, including the machine name, security identifier (SID),
and IP address.
To solve the problem of duplicate IP addresses causing network conflicts, the Cloud Automation
Platform network abstraction and isolation layer (NAIL) uses network address translation (NAT) to
provide a unique IP address for each cloned VM or physical server image on a network. With the NAIL
Server managing the network translation, an entire operating system (OS) stack and application,
including groups of applications, can be imaged and moved from one VM or physical computer to
another and from one environment to another without any changes to the image itself.
For detailed information about NAIL, see Chapter 5, Advanced Networking, on page 129.
Dynamic Host Configuration Protocol (DHCP) prevents IP address conflicts by dynamically
configuring non-conflicting IP addresses to DHCP-enabled VMs and deployed physical servers.
193
8 Image Management
Additionally, you can view, delete, and deploy sessions with snapshots using the CAP web interface.
For details on performing these procedures, refer to the online help.
You can also specify a virtual network range or masquerade properties for an image to simplify the
creation of multiple VMs from a single image file on a network.
Creating New Images

The processes for creating and preparing images are different for virtual machine images and physical
server images. Refer to the following sections for more information:
Creating Virtual Machine Images on page 194
Creating Physical Server Images on page 195
Creating Virtual Machine Images

There are several different options for creating the images that will be used in the Cloud Automation
Platform environment. Quest Software Professional Services provides image creation, conversion, and
management for many customers. Or, your company can leverage your ISO images to create images for
the Cloud Automation Platform environment. Finally, you can use the CAP web interface to create new
virtual machine images. (Refer to the online Help for detailed instructions.)
Note: The appropriate virtual machine tools must be installed on the image. Install Microsoft's
Integration Services on all images that will use a Microsoft Hyper-V host server and install
VMware Tools on all images that will use a VMware ESX host server.
When you create a virtual machine image using the CAP web interface, you create a blank application
configuration, and the corresponding image and server configuration. You must specify mount points,
a hardware profile, optional image files, application configuration name and description, and server
configuration name and description.
After you create a blank application configuration and then create a session, deploy the session and use
the Session Details page to connect to the remote console of the VM using Console access.
From the remote console, install an OS and any software that you want to include in the image. To add
an OS or software to the blank disk, you must access an ISO file. You can attach an ISO file by using
the Attach Media option or you can include an ISO file in the server configuration that you create.
Note: Quest Software recommends that you save the image after you install the OS but before adding
any software. Using the Save As command on an active session enables you to create a new
server configuration, application configuration, and session that reference the newly saved
image file. Saving an OS without any applications provides an image file that can be used as
the starting point for additional image creation.
194
8 Image Management
Note: In configurations where a DHCP server is used for allocation of IP addresses to VMs and
deployed physical servers, it is important to ensure that the pooled IP addresses used in the
Cloud Automation Platform environment do not duplicate those used by the DHCP server. For
more information about configuring images, refer to the online help.
NewDisk-<n>
For instance, if you create a blank application configuration with a single disk, the image created is
named NewDisk-0.
To create additional new images, you can re-use the original blank application configuration or create
new blank application configurations that specify any additional disk size or ISO requirements.
Creating Physical Server Images

Physical server images are used to create server configurations that run on physical computers
managed by a physical provisioning system, such as Altiris Deployment Solution.
The workflow for creating physical server images is different from that of creating virtual machine
images. The primary difference is that the image must be prepared in advance for use in the Cloud
Automation Platform environment, before creating it and adding it to the system library.
To create a physical server image, configure the physical computer exactly as you want the image to be.
Then use the Surgient_Image_Tool.exe to prepare the images configuration for use in the Cloud
Automation Platform environment. Finally, create an image (.img) of the physical server using the
physical provisioning tool. For details about preparing a physical server image for Windows or Linux,
see Preparing Physical Server Images on page 199.
Note: The Altiris physical server images must have an extension of .img, with all lowercase letters.
Otherwise the image will not deploy in the Cloud Automation Platform environment.
Preparing Images
Both virtual machine images and physical server images can be used in the Cloud Automation Platform
environment. Virtual machine images are used to create the VMs in the environment. Physical
server images are used to create server configurations that run on physical computers managed by a
physical provisioning system.
Any images, virtual or physical, that will be used in the Cloud Automation Platform environment should
(with a few exceptions) be prepared, or optimized, using the CAP-provided optimization tool. Quest
Software recommends that you create a resource pool in which all image creation and preparation is
performed.
For virtual images, attach the Surgient_Image_Tool.iso media and select the appropriate
scripts to run. See Preparing Virtual Machine Images on page 196.
For physical server images, run the Surgient_Image_Tool.exe. See Preparing Physical
Server Images on page 199.
195
8 Image Management
The newly saved image is saved to the Templates directory of the system library. Images created with
the CAP web interface use the following naming convention:
Warning:
Be aware that when creating an image to be imported into the Cloud Automation
Platform environment, and the image:
was created outside of the Cloud Automation Platform environment,
will be used in a server configuration with Active Directory Registration enabled,
and
will use auto-generated accounts to access the VM's remote desktop,
then the last login must have been to a local computer account.
This is because the server's login screen defaults to the last domain used to login, so if
it was a domain instead of the local machine it causes the auto-generated accounts to
fail to login.
If this issue occurs, the workaround is to connect using console access and manually
log into a local machine account. Afterwards the RDP sessions will connect normally.
Warning:
Verify that if there is anti-virus software installed on the image, the software is not
configured to automatically perform a full-disk scan. A full-disk scan at boot-up or any
other time once the image is in the environment can potentially cause performance and
deployment issues. Quest Software recommends that if a full-disk scan is required, run
it when building the image. Once the image is in the Cloud Automation Platform
environment, on-access scanning can be done, but be aware that it might impact
performance. Additionally, consider generating a checksum hash to verify that the
image is not modified between creation and delivery for deployment.
Preparing Virtual Machine Images

For detailed instructions to prepare a virtual machine image, see:
Preparing Windows Virtual Machine Images on page 197
Preparing Linux Virtual Images on page 198
To use virtual images in to your Cloud Automation Platform environment, you can either:
196
Import existing images that were created outside of the Cloud Automation Platform environment,
using virtualization software. See the Warning below for important information about images
creating outside of the Cloud Automation Platform environment.
Create an image using the CAP web interface. Cloud Automation Platform uses the underlying
virtualization software to create an image in the softwares supported format.
8 Image Management
Before you begin preparing a .vhd, .vmdk, or .img image for use in your Cloud Automation Platform
environment, it is helpful to know how many images you need, the amount of RAM required for each
image, and other related information.
After the virtual images are imported into the Cloud Automation Platform environment, the workflow
for preparing virtual images is as follows (refer to the online Help for exact instructions for each step):
1. Add the image(s) to the Library.
2. Create a server configuration using the image.
3. Create a single-server application configuration.
4. Create a session from the application configuration.
5. Access the console of the deployed VM (created from the image).
6. Prepare the image for use in the Cloud Automation Platform environment, using the
Surgient_Image_Tool.iso file.
7. Save the modified server as a new image.
Considerations:
If an image will be included in a configuration that enables Active Directory, review the Warning
on page 196.
If you do not want to include the Quest CAP Agent in the image as a guest agent, see Agentless
Images on page 201. When creating a the server configuration with an image does not have a guest
agent, deselect the Has Agent check box under the Remote Access Types area on the New Server
Configuration page.
The appropriate virtual machine tools must be installed on the image. Hyper-V host server and
install VMware Tools on all images that will use a VMware ESX host server.
Preparing Windows Virtual Machine Images

To prepare a Windows virtual machine image for use in a Cloud Automation Platform environment and
add the Quest CAP Agent, run the Express.exe file that is included in the
Surgient_Image_tool.iso.
The Express.exe executable prepares the image by:
adding the Quest CAP Agent
enabling and configuring Remote Desktop connectivity
disabling automatic updates
changing the last CD-ROM Drive Letter to S
installing .NET Framework 2.0
Note: If you do not want to add the Quest CAP Agent to the image, do not follow the steps below.
Instead, see Agentless Images on page 201.
197
8 Image Management
Workflow Summary
2. Verify that the image was created from a fully licensed Windows operating system. Because the
Express.exe program attempts to detect a volume-licensed copy of Windows for activation
detection, it does not work with an image that does not have a permanent product key (license key)
entered.
3. Establish a terminal session by opening the console of the VM.
4. Mount the Surgient_Image_tool.iso file on the VM host.
5. If auto-start is enabled, the Image Optimizer Express dialog opens after the .iso has been
successfully mounted.
If the dialog box does not open, navigate to the Express.exe file and double-click it.
Note: If an Open File - Security Warning message appears, click Run.
6. Enter the Username, Password, and Domain. For Vista, Windows 7 and Windows 2008 Server,
this must be the local Administrator account. For versions of Windows prior to Vista, an account
in the local Administrator's group is sufficient.
7. Click Start.
The Executing Task... dialog box appears and displays progress information.
After the program has completed, a web browser launches and displays the Image Update and
Analysis Report. This information describes the changes made to the image.
(Optional) If you plan to access this image using VNC, install and configure TightVNC Server.
After you successfully prepared your Windows image for use in a Cloud Automation Platform
environment, add the image to the system library.
Preparing Linux Virtual Images

To prepare a Linux virtual machine image for use in a Cloud Automation Platform environment and add
the Quest CAP Agent, run the linux-agent-*.i386.rpm file that is included in the
Surgient_Image_tool.iso.
The linux-agent-*.i386.rpm prepares the image by adding the Quest CAP Agent.
Note: If you do not want to add the Quest CAP Agent as a guest agent to the image, do not follow the
steps below. Instead, see Agentless Images on page 201.
1. Verify that the appropriate virtual machine tools were installed on the image.
3. Create a temporary directory by entering the following command:
mkdir /<temp>
198
8 Image Management
4. Copy the following file from the Cloud Automation Platform installation distribution files to the
temporary directory that you created in step 3:
linux-agent-*.i386.rpm
5. Install and configure the agent by performing the following steps:

A. Navigate to the temporary directory that you created in step 3.
B. Type the following command and press Enter.
rpm -iv /dir_path_of_iso/linux-agent-*.i386.rpm
C. After the system finishes setting up the appropriate files, modify the agents CDDEVICE
variable, as follows:
i.
Navigate to /etc/init.d.
ii. Open surgientagent in a text editor.

iii. Set the CDDEVICE variable to /dev/scd0.
iv. Save surgientagent and quit the text editor.
6. After you successfully prepared your Linux image for use in a Cloud Automation Platform
environment, save the image as a new configuration.
Preparing Physical Server Images

Any physical images that will be used in the Cloud Automation Platform environment should, with a
few exceptions, be optimized by using the appropriate Cloud Automation Platform image preparation
tool.
Note: Physical server images must be prepared for use in the Cloud Automation Platform
environment before they are added to the system library.
Physical server images cannot use NAIL Server; the legacy NAIL Driver must be used instead.
For more information, see Using NAIL Driver on Windows Images on page 202.
For detailed instructions to prepare a physical server image, see:
Preparing Windows Physical Server Images on page 200
Preparing Linux Physical Images on page 200
Workflow Summary
Follow the directions below to prepare, create, and import physical server images:
1. Log on to the physical computer from which you want to make the image.
199
8 Image Management
Where <temp> is the name of the temporary directory.
Windows Surgient_Image_Tool.exe
Linux rpm -i linux-phy-agent-v.0.0-*.i386.rpm
3. Using the provisioning system, such as Altiris, create an image of the server.
4. Add the image(s) to the Library.
Preparing Windows Physical Server Images

To prepare a Windows physical server image for use in a Cloud Automation Platform environment and
add the Quest CAP Agent, use the Surgient_Image_Tool.exe file that is included in the Cloud
Automation Platform distribution media (CD or download).
Instead, see Agentless Images on page 201.
1. Copy the Surgient_Image_Tool.exe file to the physical computer from which you want to
create a physical server image.
2. Double-click the Surgient_Image_Tool.exe file.
3. When prompted, enter the local administrator's login ID and password.
The computer will reboot several times to complete the preparation process.
4. After the Surgient_Image_Tool.exe file has finished running, create an image (a .img file) of
the physical server using the physical provisioning tool.
Note: The Altiris physical server images must have an extension of .img, with all lowercase letters.
5. Add the image to the system library.
Preparing Linux Physical Images

To prepare a Linux physical image for use in a Cloud Automation Platform environment and add the
Quest CAP Agent, perform the following steps:
Instead, see Agentless Images on page 201
1. Copy the linux-phy-agent-6.0.0-*.i386.rpm file to the physical computer from which you
want to create a physical server image.
2. Use the following command to run the .rpm file and prepare the server.
200
8 Image Management
2. Prepare the server for the Cloud Automation Platform environment using the appropriate tool (on
installation media):
8 Image Management
3. When the .rpm file has finished preparing the server, make an image of the server using the
physical provisioning tool.
4. Add the image to the system library.
5. After you successfully prepared and created your Linux physical image for use in a Cloud
Automation Platform environment, create a physical server configuration, an application
configuration, a session, and then save the image as a new configuration.
Note: The physical server image must have an extension of .img, with all lowercase letters.
Agentless Images
An image used in the Cloud Automation Platform environment typically includes a Quest CAP Guest
Agent that communicates with the CAP Core server and runs commands issued to it from the CAP Core
server.
However, there are some situations in which installing the guest agent is not desired or allowed. For
example, your environment may prohibit, for security reasons, the installation of third-party software.
In summary:
Agentless Windows images that will run in ESX require that you run the
ESX_networking_fix.reg file that is included in the Surgient_Image_Tool.iso.
Agentless Window images that will run in Hyper-V do not require additional preparation.
Linux images do not require additional preparation, either.
Note: Be aware that provisioning a virtual server without the Agent will limit your remote access to
native console access. For physical server images created by Altiris, there will be no remote
access to the deployed virtual server possible from the CAP web interface without the guest
agent. In addition, your server should boot and shutdown unattended without any interactive
prompts. If the virtualization guest tools can not properly shutdown your server, saving changes
through snapshots and promotions may lead to data loss.
When creating a server configuration with an image that does not have an Agent, clear the Has
Agent check box under the Remote Access Types area on the New Server Configuration page.
Converting Hardware Versions for .vmdk Files

Cloud Automation Platform requires that all VMware ESX images are in the Version 4 or Version 7
double-file VMDK format.
For ESX 3.5 hosts all .vmdk files must be hardware version 4.
201
ESX 4 hosts can use files in the hardware version 4 or 7.
To convert .vmdk files, perform the following steps:

on the CAP Core server. By default, this directory is Program Files/Quest Software/
CAP/Platform.
By default, the user ID is admin. The password is the administrator password that was defined
during the Cloud Automation Platform installation.
3. After logging on, use one of the following commands and then press Enter:
To convert one specific file in the system Library directory:

imageconvert image <image_name.vmdk> <library_path> VMDKx VMDKy
Where x is the version number of the source and y is the version to which you want to convert.
Example: imageconvert \library VMDK3 VMDK7
To convert all files in the system Library directory:

imageconvert <library_path> VMDKx VMDKy
Where x is the version number of the source and y is the version to which you want to convert.
Note: To determine your library path, run the librarylist command in vcsadmin. If the file is in
a sub-directory beneath the default Templates directory, add the subdirectory name in front
of the image name value. For example:
imageconvert image <subdirectory_name\image_name.vmdk>
<library_path> VMDK3 VMDK4
Using NAIL Driver on Windows Images

When preparing either virtual server images that will run on Hyper-V or physical server images, and
you plan to use the legacy NAIL driver (deprecated in version 5.x), please review the following
information and procedures.
Physical Server Images and NAIL Driver
To prepare Windows physical server images to use the NAIL driver for cloning, complete the following
steps:
1. Log on to the physical computer from which you want to make a physical server image.
2. Copy the following files from the installation media to the physical computer on which you want
to create the image:
202
8 Image Management
ImagePreparation\Surgient_Image_Tool.exe
ImagePreparation\ImagePrep.exe
8 Image Management
3. Set the IP Address to a static IP Address:

A. In the Control Panel, double-click Network Connections.
B. On the Network Connections dialog box, double-click Local Area Connection.
C. In the Local Area Network Status dialog box, on the General tab, click Properties.
D. In the Local Area Network Properties dialog box, on the General tab, select Internet Protocol
(TCP/IP) entry and click Properties.
E. In the Internet Protocol (TCP/ Properties dialog box, select Use the Following IP Address
radio button. Provide a static IP Address that is not on the network where the image will be
deployed.
F. Click OK and close dialog boxes.
4. Double-click the Surgient_Image_Tool.exe file to start running the image preparation tool for
physical server images.
A. When prompted, enter the local administrator's log in ID and password.
The computer will reboot several times to complete the preparation process.
B. After the above process is complete, double-click the ImagePrep.exe file.
C. Select Standard for the type of installation, and on the next panel, select only NAIL and
Terminal Services.
Note: Be sure to clear Guest Agent, since an Agent was already installed by the
Surgient_Image_Tool.exe file.
D. Click Next through rest of the ImagePrep program, and then click Finish.
E. After both .exe files have completed their processes, create an image (.img) of the physical
server using the physical provisioning tool.
F. Add the physical server image to the system Library.
Note: The Altiris physical server images must have an extension of .img, with all lowercase letters,
and no spaces in the name. Otherwise the image will not deploy in the Cloud Automation
203
To prepare a Windows virtual machine image for deployment on a Hyper-V host and to install the NAIL
driver (which enables the simultaneous deployment of multiple, cloned VM configurations), use the
following procedures:
2. Verify that the image was created from a fully licensed Windows operating system. Because the
Express.exe program attempts to detect a volume-licensed copy of Windows for activation
detection, it does not work with an image that does not have a permanent product key (license key)
entered. The Windows operating system must be either Windows 2003 or Windows XP, and be a
32-bit platform. The network connection in the virtual machine must be named Local Area
Connection (Windows only).
4. Mount the Surgient_Image_tool.iso file from the VM host.
5. If auto-start is enabled, the Image Optimizer Express dialog opens after the .iso has been
successfully mounted.
6. If the dialog box does not open, navigate to the directory where the
Surgient_Image_Tool.iso is mounted, and double-click the Express.exe file.
7. Enter the Username, Password, and Domain.
8. Click Start.
9. The Executing Task... dialog box appears and displays progress information. After the program
has completed, a web browser launches and displays the Image Update and Analysis Report. This
information describes the changes made to the image.
10. Set the IP Address of the image to a static IP Address that is not on the network where the image
will be deployed. (For detailed steps, see step 3. on page 203).
11. Navigate to the directory where the Surgient_Image_Tool.iso is mounted, and double-click
the ImagePrep.exe file.
12. Select Standard for the type of installation, and on the next panel, select only NAIL and
Terminal Services.
Note: Be sure to deselect Guest Agent, since an Agent was installed by the Express.exe
file.
Optional: If you plan to access this image using VNC, you can select the VNC option
to install and configure TightVNC Server.
13. Click Next through the rest of ImagePrep program, and then click Finish.
14. After you successfully prepared your Windows image for use in a Cloud Automation Platform
environment, add the image to the system library.
204
8 Image Management
Virtual Machine Images and NAIL Driver
8 Image Management
205
8 Image Management
206
This chapter explains how the physical and network resources interact in the Cloud Automation
Overview of Resources on page 208
Resource Pools on page 208
Network Resources on page 209
System Library Locations on page 210
File Caches and File Cache Locations on page 211
Virtualization Hosts on page 214
Virtual Machines on page 215
207
Physical and Network Resources
Before you begin using the Cloud Automation Platform environment, make sure physical and network
resources are available for use. Physical resources include system library locations, file cache locations,
virtualization hosts, and optionally, physical computers and physical provisioning servers. Network
resources include MAC addresses, DHCP network ranges, IP addresses, VLAN ID ranges, and,
optionally, NAIL virtual network ranges (for legacy NAIL Driver support).
After the physical and network resources have been made available, use the CAP web interface to define
the resources for Cloud Automation Platform.
All virtualization hosts, physical computers, and network resources must be assigned to a resource pool,
which contains the physical and network resources that determine capacity for the Cloud Automation
Platform environment. Resources must be allocated to resource pools before they can be used by Cloud
Automation Platform applications. The resources of a single host can be divided among several pools,
unless the pool is a High Availability pool. Refer to the online Help topic Assigning a Host to a Pool
for details. For more information about High Availability pools, see Using High Availability with
VMware vSphere on page 170.
Resource Pools
A resource pool contains the host and network resources that determine capacity for the Cloud
Automation Platform environment. A resource pool contains computing resources such as RAM, IP
addresses, MAC addresses, virtual network prefixes, virtualization hosts, and physical computers.
Resources must be assigned to resource pools before they can be used by Cloud Automation Platform
applications.
Manage resources and resource pools using the CAP web interface. You can add, change, assign, or
unassign a host or network resource to or from a resource pool. If you try to unassign a resource that is
scheduled for use and no other resource is available in its place, the resource cannot be unassigned from
the resource pool. You can also associate each resource pool with a file cache.
To use the Cloud Automation Platform High Availability (HA) feature, assign the required assets to an
HA pool. For more information about High Availability, see Using High Availability with VMware
vSphere on page 170. Also refer to the online Help for instructions about pooling hosts and other
assets.
A single resource pool can fulfill multiple heterogeneous resource requirements. For example, an
application configuration that requires 512 MB of RAM might be deployed into the same resource pool
as an application configuration that requires 2 GB of RAM.
A single resource pool can be shared, which allows multiple organizations to use the same network and
host resources. Shared resource pools enable the most effective use of limited resources. Resource
pooling and sharing balance resource requests and provides high availability of resources. However, it
is possible for some users to monopolize the majority of the resources.
Ultimately, you must monitor the fair allocation and utilization of resources. Using the CAP web
interface, configure restrictions for resource allocations, snapshots, and reservations to prevent resource
monopolization. For more information, see Quotas on page 250.
208
Overview of Resources
Network Resources
Network resources are used to create a working network on VMs. Network resources are required when
multiple copies of the same application configuration are deployed or when an isolated network is
required.
Determine which network resources are required for your environment and then use the CAP web
interface to define those resources.
Network resources include:
MAC addresses Ethernet MAC addresses uniquely identify network adapters as nodes on a
network. Each network adapter of a VM deployed by the CAP Core is assigned a MAC address from
the pool of network resources. MAC address resources should be added in blocks of sequential
addresses that begin with the virtualization vendors Organizationally Unique Identifier (OUI). For
example, when deploying to VMware hosts, the MAC addresses should be in the form
00:50:56:xx:xx:xx.
IP addresses Pooled IP addresses are used for TCP/IP communication between VMs, deployed
physical servers, and the CAP Core. IP addresses added to a Cloud Automation Platform pool must
be within the network range defined by that pools gateway and netmask. VM network interfaces
that are configured for NAIL have static internal IP addresses, and NAIL servers perform network
address translation (NAT) that maps these internal IP addresses to external IP addresses taken
from the pool of network resources. VM network interfaces that are configured for VLAN-isolated
DHCP will also be assigned one of these pooled addresses from the NAIL server, which acts as that
VMs DHCP server. You must pool some IP addresses even if you will not be using NAIL or
VLAN-isolated DHCP, since they are required by other platform components.
NAIL Driver network range Allow servers within the same application configuration to
communicate with each other using an internal IP addresses. If you are specifying a NAIL Driver
Network Range (legacy) it is recommended that you specify a range of Class B IP addresses that
falls within the larger range of 172.16.0.0 to 172.31.255.255. If you specify a range of Class B IP
addresses for the virtual network pool, ensure that the internal subnet masks of the corresponding
VMs support a Class B network, such as 255.255.0.0. Similarly, if you specify a range of Class C
addresses, ensure that the internal subnet masks of the corresponding VMs support a Class C
network, like 255.255.255.0.
Best Practice: When you define the NAIL Driver network range, use the third octet of the IP address
range for the second octet of the NAIL virtual network range. For example, if your IP address range
begins with 10.5.35.x, the NAIL driver network range should be 172.35.x.0. This helps the NAIL
driver network ranges remain unique.
VLAN ID range A session deployment creates the networks, as defined in that deployments
application configuration, that are required between the deployed VMs. Each network that is created
in a deployment is assigned a VLAN ID from the pool of network resources. If the NAIL Server
Mode is set to Standard Mode, VLAN tagged network traffic never leaves the hosts, so you can
209
You can also limit access to a resource pool to a specific user group or organization. For example, if
your environment hosts a training solution with both self-paced and instructor-led labs, you might want
to assign all resources for the self-paced labs to a specific pool and all instructor-led lab resources to
another pool. For more information about access control, see Access Control on page 237.
Plan for one VLAN ID per virtual network for each deployment of an application configuration; so
for each test configuration that will be scheduled, define a VLAN ID. As a best practice, creating
extra VLAN IDs is better than having too few. The IDs created should be unique and not used
anywhere else.
DHCP network range For physical servers and virtual images that require both network isolation
and the use of DHCP, create one or more DHCP network ranges. For details about using VLANisolated DHCP networks, see Using VLAN-isolated DHCP Networks on page 141.
If you use a mixed environment where some server configurations use non-VLAN-isolated DHCP and
others do not, at a minimum, ensure that the IP addresses provided by your DHCP server are excluded
from the IP address range specified in the Cloud Automation Platform network resources.
Note: Some DHCP servers require that you add the MAC addresses created for Cloud Automation
Platform to the DHCP configuration table.
NAIL enables several VMs to use a single image file by providing each VM with a unique MAC
address, IP address, and VLAN ID range if it is required. For more information about NAIL, see
Chapter 5, Advanced Networking, on page 129.
After you specify network resources, assign them to a resource pool. When a session is provisioned,
network resources are assigned automatically to VMs and deployed physical servers.
System Library Locations

A system library location acts as a physical repository for base image files, snapshots, and deployment
action files.
Each system library server location contains three directories, a Templates directory, a Snapshots
directory, and a DeploymentActions directory. The Templates directory can contain virtual
machine images (virtual hard drives), physical server images, ISO files, and virtual configuration files.
The Snapshots directory contains the individual undo or redo log files on which snapshots are based.
The DeploymentActions directory contains files used for post-deployment actions (see Deployment
Actions on page 231).
Cloud Automation Platform system libraries are managed by the Remote Server Manager (RSM),
which requires that the library server is registered with the Cloud Automation Platform environment.
For detailed instructions to register the host, refer to the online Help topic Registering a Remotely
Managed Host.
Library location and file cache location directories can be either on VMFS, CSV, or NFS volumes.
210
choose to pool any VLAN IDs in the range 2 through 4094, excluding the VLAN ID that your
network is using as its Default VLAN. If the CAP Core is operating in NAIL Server Advanced
Mode, VLAN tagged traffic will be passed between switches in your environment, so you must
work with your network administrator to make certain that you only pool VLAN IDs that are
supported by your switch configuration, and which are not already in use in other parts of your
network.
Note: For information about the supported library locations and file cache locations, and how to
configure hosts for file access and library management, refer to Configuring Storage and
Shared Access on page 155.
Hosts can access images directly from the system library when the library server is on either:
An ESX host that supports NFS or VMFS. ESX hosts that use a library location on a SAN VMFS
volume must be configured before installing Cloud Automation Platform. Refer to Using VMWare
VMFS in a SAN-based Configuration on page 155.
OR
A Hyper-V host that accesses a CSV on a SAN.
Use the CAP web interface to define the system library location for the Cloud Automation Platform
environment. In the CAP web interface, click Library in the Navigation pane on the left, and then in
the Library Locations area click New. Cloud Automation Platform automatically creates Templates,
snapshots, and DeploymentActions directories in the library root directory.
Note: As a best practice, Quest Software recommends that virtualization hosts with system library
locations be pooled with less RAM or fewer effective processor units (EPUs) contributed to a
pool. Using the library server to host VMs may negatively impact system performance and may
need tuning to minimize resource conflicts.
Note: As a best practice, when populating the system library, first copy the image files into the library
root directory and then move the files into the Templates subdirectory. This prevents users
from deploying an application configuration that references an image that is not fully copied.
To view the images in the system library, using the CAP web interface, click Images in the Navigation
pane to the left. Click Re-Sync to view the most up-to-date list of files. If you have added files to the
library, but they do not appear in the list, click Re-Sync. If files do not appear after Re-Sync, ensure that
file permissions allow the RSM to access the files.
File Caches and File Cache Locations

A file cache is a logical collection of one or more file cache locations that can store files being used by
a deployed application. File caches should be created before creating pools or assigning hosts to a pool
(See Note below.) File caches can help with scalability and load balancing in your environment. For
example, instead of having 50 deployments use the same base image from the same place, create
multiple file caches (perhaps one per pool) and have duplicates of the image in each file cache location.
This way, the image is accessed only by the hosts of a specific pool, instead of by all hosts in the
environment.
211
Note: Altiris physical server images are only supported in a library location that is managed by a
Windows Agent, and must be in a local or remote SMB share (optionally configured with SMB
credentials for security). Altiris physical server images cannot be accessed from a file cache
location; i.e. any images created with Altiris will be provisioned directly from the library.
A file cache location is a physical area of storage to which base images are copied when an image is
deployed to a virtual machine. Any image file (.vhd, .vmdk, .iso, and so on) that is part of a server
configuration might be copied to a file cache location when an application configuration is deployed.
The two types of Cloud Automation Platform file cache locations are dedicated and shared.
All pooled hosts have a dedicated file cache location, which must be specified when the host is
registered. When an application cannot be deployed by directly accessing its image files from a remote
system library location, a location (dedicated or shared) in the file cache is used to store a copy of the
image file while the application is deployed.
Using the CAP web interface, an administrator can also create or delete optional shared file cache
locations, which are used to provide faster access by remote servers. Using shared file cache locations
is recommended for any organization that has virtualization hosts some distance apart and where
network time impacts the VM performance. If all shared file cache locations are full, VMs that require
cached files will use the dedicated file cache location on the VM's host.
If you add a file cache location, make sure that the associated file cache is assigned to a resource pool.
Otherwise, the file cache location will not be used. Using the CAP web interface, click Pools in the left
pane, and then edit the pool to assign a file cache to a pool. The associated file cache is used for all
deployments to that resource pool.
Note: A shared file cache location cannot be added to the same volume that already has a library
location.
After the application configuration session finishes, the image and any other related files remain in the
file cache location. When a file cache location reaches full capacity, the least recently used images and
files are purged automatically when space is needed in that file cache location. If a cached image is
connected to a VM the file is considered in use and cannot be purged. When a shared file cache location
is deleted, all contents that are not being used in an active session are purged. However, in a dedicated
file cache, the location is removed from the system only when the corresponding server is deleted.
Note: Altiris physical server images cannot be cached. Any images created with Altiris will always
be provisioned directly from the library.
File Cache Location Types

Cloud Automation Platform supports two types of file cache locations:
212
Dedicated file cache location
Shared file cache location
Note: When creating a new file cache and subsequently associating that file cache with a pool,
consider what type of hosts (ESX or Hyper-V) will access the locations of the file cache. If the
hosts are ESX, the file cache location must contain shared locations on either VMFS volumes
or NFS-accessible directories. If the hosts are Hyper-V, the file cache locations must be located
on a SAN-based CSV.
For Hyper-V hosts, the dedicated file cache location is created in:
<drive>:\surgientdfcl.<#>
For VMware ESX hosts, the dedicated file cache is created in the subdirectory under a vmfs volume:
surgientdfcl.<#>
where # is the Cloud Automation Platform generated sequence number.

If no shared file cache location is defined when an application configuration is deployed with a method
of Use File Cache, Cloud Automation Platform automatically creates a dedicated file cache location
on each virtualization host used in the deployment.
By default, the volume or drive with the most space available is used for the dedicated file cache location
to support High Availability.The volume on which the dedicated file cache location is located can be
selected by the user by editing the host properties.
If all shared file cache locations are full, then the host's dedicated file cache location is used. Also, there
are certain image types, such as NAIL Server images, that must be accessed from a dedicated file cache
location.
You can also create one or more shared cache locations. A shared cache location can reside on a volume
on a CAP-managed server or a remote volume accessible from a CAP-managed server.
Note: A shared file cache location cannot be added to the same volume that already has a library
location.
For CIFS remote volumes (supported only for Altiris), the directory hosting the cache location must
exist, the location must be configured with the proper export path, and access privileges must be set up
manually.
Note: Be aware of the following host requirements:
For VMware ESX hosts, shared cache locations must be accessible using NFS or stored on
a VMFS volume on a SAN. For ESX hosts that are added to a High Availability pool, the hosts
dedicated file cache location must be on a shared volume.
For Hyper-V hosts, either the shared file cache location or the library location on the
Clustered Shared Volume must be used. In addition, all VM home directories must be in a local
directory. No UNC paths or CIFS-based locations can be used.
A single virtualization host can support multiple file cache locations if the locations are on different
volumes. For instance, a single file cache might have multiple file cache locations that correspond with
different volumes on a single NFS system.
If the size of the location is not specified during creation, the entire volume will be used.
A shared cache location can be used by any virtualization hosts in the resource pool through networkattached storage, while a dedicated cache services a single host. For a shared file cache location to be
used, at least one virtualization host in that pool must have direct access to the shared file cache location.
213
A dedicated file cache location is created locally on a virtualization host. Depending on the host server,
the dedicated file cache location is created in the following location:
A virtualization host is the physical server on which the virtualization technology runs and on which
virtual machines are created. It is the computer that hosts the VMs.
Before the Cloud Automation Platform environment can recognize a virtualization host, the host must
be registered so that the Remote Server Manager can manage it. After the host is registered, a host
displays as an available host resource in the CAP web interface. Assign the host to a resource pool to
use it for deployments.
A host can belong to a single resource pool, or the resources of a host can be divided across multiple
pools (excluding hosts that are added to a High Availability pool). A virtualization host can contribute
RAM, maximum concurrent VM capability, and EPUs (Effective Processor Units) to the pools
available capacity. For example, a pool might contain 8 GB of RAM from virtualization host A and 10
GB of RAM from virtualization host B. Therefore the pool has the capacity to provide 18 GB of RAM.
This capacity is used for the creation of VMs.
Note: Hosts that are assigned to a High Availability pool cannot divide their resources. For more
information about using High Availability in Cloud Automation Platform, see Using High
Availability with VMware vSphere on page 170.
Utility hosts, which are Hyper-V R2 hosts that require NAIL Servers for network translation,
can contribute only RAM to a pool. For more information about utility hosts, see Using NAIL
Server with Hyper-V R2 Hosts (Utility Hosts) on page 31.)
When a virtualization host is added to a resource pool, you specify the amount of each resource type
that the host will contribute to the pool. For instance, if you know an application configuration is CPUintensive, you might want to limit the maximum number of VMs that can be created on that host. In this
case, even though enough RAM exists on the host to deploy additional VMs, limiting the number of
VMs ensures that the system performs optimally. For more information, see Managing Virtualization
Hosts on page 161.
Note: Since some RAM must be used to run services on the virtualization host, do not allocate all the
RAM for VM utilization. However, you can contribute all of a single hosts EPUs to the pool.
Before you add a host to a resource pool, you must edit the host details and specify the default network
and the trunked network connections. ESX network connection names display in a drop-down list that
includes all the physical network names followed by the NIC name. For High Availability pools, you
must select distributed switches for the default and trunked network connections.
The default network connection setting ensures that VMs bind to the correct network adapter, usually
one with external connectivity. For instance, if your physical machine has two network interface cards
(NICs), but only one NIC port is used to connect application users through a firewall to the VM, specify
that NIC port as the default network connection. Typically, the default network connection acts as a
virtual layer 2 network switch that communicates to a network on a cabled physical NIC port. If the
environment requires using NAIL Server in Advanced mode, a trunked network is also required.
Note: As a best practice, Quest Software recommends that virtualization hosts with system library
locations be pooled with less RAM or less effective processor units (EPUs) contributed to a
214
Virtualization Hosts
Virtual Machines
Each virtualization host can support several VMs running different guest operating systems. A VM
appears to a session user as computer hardware and software that is completely dedicated to that user.
In reality, a VM is a small portion of a virtualization host that is temporarily allocated to a session user.
Cloud Automation Platform automatically creates VMs as needed at deployment time. The number of
VMs created is determined by the size of the smallest hardware profile. For instance, if you specify a
host server that has 1024 MB of available RAM and the smallest hardware profile uses 256 MB of
RAM, Cloud Automation Platform creates four VMs on the host.
Note: Remotely creating and deleting VMs directly on the host server using the virtualization
software is not recommended. Use the CAP web interface to ensure that VMs are deployed and
configured correctly.
When an application configuration is deployed to a resource pool, the existing VM or VMs are
reconfigured to the specifications defined in the deployed hardware profile and image file. For more
information about deployment, see Chapter 11, Deploying and Managing Sessions, on page 225.
You can change the number of VMs that can be created on a specific host server. For more informations,
see Virtualization Hosts on page 214.
You can monitor deployed VMs, or sessions, from the CAP web interface. For more information, see
Managing Sessions on page 235.
215
pool. Using the library server to host VMs may negatively impact system performance and may
need tuning to minimize resource conflicts.
216
10
This chapter details the objects that comprise the Cloud Automation Platform system library and
describes the relationships between these components.
Library Objects Overview on page 218
Image Files on page 219
Deployment Action Files on page 220
Hardware Profiles on page 220
Server Configurations on page 220
Application Configurations on page 222
Snapshots on page 223
Catalogs on page 223
Managing System Library Objects on page 223
217
System Library
Objects
The system library serves as a logical repository for the CAP Core objects that are used for reserving
resources for deployments to create a session. These objects define the list of resource requirements as
well as how each object should be deployed and configured. Ultimately, the objects in the system library
provide the ingredients and instructions to create a session.
Use the CAP web interface to create and manage the platform objects that are used for reserving
resources for deployments.
The system library includes the following platform objects:
Object
Description
Images
An image is a representation of a computers disk

drive, CD-ROM, floppy disk, or other storage device,
plus any software installed when the image was created.
A deployment actions file is a file, normally a script

or other executable, that is selected to run on a
CAP-deployed server, either immediately after a
session starts or at any time during the session.
Hardware profiles
The definition of the RAM requirements, target hardware type (physical or virtual) CPU requirements,
and required computing capacity.
Server configurations
All the resource requirements and file references

needed to create a fully functioning server.
Application configurations
All the information needed to deploy a single session. One or more server configurations are grouped
into an application configuration, optionally along
with additional files such as deployment action files
or material.
Catalogs
The classification mechanism for elements in the

system library. Catalogs are solely for categorization.
Review templates
Reviews templates are used to enable users to convey their level of satisfaction with a session and
summarize their overall experience. Users can only
write reviews after completing a session.
The system library also acts as a physical repository for image files and snapshots, which is discussed
in System Library Locations on page 210.
Note: Images, deployment action files, snapshots, and review templates display in the system library
and are core ingredients in deployments. They are actual, physical files. In contrast, the other
items in the system library are only relevant to the CAP Core.
218
Library Objects Overview
The objects in the system library are building blocks for one another. To create the platform objects for
your environment, perform the following steps:
1. Determine if Professional Services will provide images for your environment or if you will create
them using the CAP web interface.
For more information about images, see Chapter 8, Image Management, on page 189.
2. If you will be creating images for your environment, create a blank disk application configuration.
This type of application configuration automatically creates corresponding server configurations
and enables you to create new images.
For more information, see Creating New Images on page 194.
3. Review the default hardware profiles and determine if the profiles meet your RAM requirements
or if you must create new hardware profiles.
For more information, see Hardware Profiles on page 220.
4. After all the image files are created, prepared, and moved into the library, you are ready to build
server configurations that reference a hardware profile and one or more image files. Then, build
application configurations that reference one or more server configurations. Optionally, create
review templates that an application configuration can reference, and attach one or more
deployment action files to an application configuration. Finally create a session from an
application configuration, and deploy the session.
For more information, see Server Configurations on page 220, Application Configurations on
page 222, and Snapshots on page 223.
Image Files
Image files are representations of a computers disk drive. Images can be manually copied into the
system library or created using the CAP web interface. Both virtual machine images and physical server
images can be used in the Cloud Automation Platform environment.Virtual machine images are used
to create the VMs in the environment. Physical server images are used to create server
configurations that run on physical computers managed by certain physical provisioning systems.
Note: For more information about images, see Chapter 8, Image Management, on page 189.
For important information about .vmdk file format and conversion, see Converting Hardware
Versions for .vmdk Files on page 201.
219
Workflow Summary
Deployment Actions Files are files, normally scripts of some type, that are selected to run on a Cloud
Automation Platform environment immediately after a session starts.
Deployment Actions Files are stored in the system library, and are added to library using the CAP web
interface.
Note: See Deployment Actions on page 231 for information about running deployment actions.
Actions are run against a particular server configuration within an application configuration. The action
is not persistently attached to the server configuration itself. The same server configuration may be used
within a different application configuration and be deployed with a different action.
Hardware Profiles
Hardware profiles define the hardware requirements for individual server configurations. RAM, target
hardware (physical or virtual), CPU requirements, and required computing capacity is specified in a
hardware profile. The default hardware profile has 1GB RAM. You can create additional hardware
profiles if necessary. Typically, a system library contains only a few hardware profiles.
Server Configurations
A server configuration is a record of all the information and file references needed to create a fully
functioning server. Server configurations include a hardware profile, networking information, at least
one boot source (image or provisioning automation), as well as other configuration settings.
A server configuration includes the following information:
Boot source:
Image To create a new server configuration using an image, select Image from the Assign...
drop-down list in the Boot Source area. Then select the primary image file. You can add
additional files or images to a server configuration based on the number of drives the VM or
physical computer requires. Available image types include Hyper-V virtual disk, ESX virtual
disk, a physical server image, ISO image, and floppy image.
To provide access to an ISO or floppy image, attach the ISO or floppy image as part of a server
configuration. When the user starts the session, the image displays as a CD or floppy drive and
the user can access the files on that drive. For instance, if a user needs to install new software,
include the ISO file in the server configuration so he can access the CD drive and install the
software.
220
Provisioning Automation A provisioned boot source, such as an HP Server Automation OS

Sequence, can be used to create a server configuration. To create a new server configuration,
select Provisioning Automation from the Assign... drop-down list in the Boot Source area. For
more information about external provisioning, see External Provisioning with HP Server
Automation on page 34.
Mount point Each image is attached to the server configuration at a mount point.
Available device types include IDE or SCSI.
Note: Cloud Automation Platform reserves mount point IDE 1:1 for VM management.
Associated hardware profile A server configuration is linked to a hardware profile, which

defines several hardware requirements (RAM, CPU, etc.) for the VM or physical computer.
When a server configuration is created, a hardware profile must be specified.
Active Directory Registration Type Specifies whether the server configuration will join
an Active Directory domain. An Active Directory server must already be defined and
enabled for at least one resource pool. If the exact computer account on the domain that the
VM or physical computer needs to use does not matter, Dynamic is specified. If the VM
will use a specific computer account on the domain, Selected is the appropriate choice. A
computer account must already be defined in Cloud Automation Platform with the same
name as the computer account known to the Active Directory server.
Bus type For VMware ESX you must specify BusLogic, LsiLogicSAS, or LsiLogic or
problems will result. Earlier versions of VMware use BusLogic, while newer versions use
LsiLogic as the SCSI device type. To determine the bus type of your initial image template,
in the VMs configuration file (.vmx), find the line that begins with scsi0.virtualDev
and note the associated value. Alternatively, view the Disk Controller Type displayed in the
VMware client.
Network Adaptors This setting defines the number and types of network adaptors required by the
server configuration.
Ethernet Device Specifies whether the ethernet device is configured for NAIL 3 (use if
network address translation is required), DHCP, or Static. When NAIL is selected, the IP
address, the Subnet Mask, and the IP Address of the Gateway for each ethernet device must be
specified. If the server configuration will be used in a VLAN-isolated DHCP network, you must
create the network resource called DHCP network range.
NAIL enables several VMs to use a single image file that contains a static IP Address in it by
providing each VM with a unique IP address, via network address translation (NAT). When
using NAIL, a unique IP address is reserved when pooled computing capacity is reserved. For
more information, see Duplicating Image Files on page 193.
Network Card Type For VMware ESX, correct network card type selection prevents TCP/IP
conflicts and image duplication errors. The vmxnet driver installs automatically with VMware
and provides better networking performance. However, several other options are available;
refer to your hypervisors documentation for guidance.
Remote Access Configuration Identifies which methods of remote access are available to users
for each server configuration. Supported types include: RDP, Citrix, VNC, and the virtualization
console.
221
After the boot source is selected, further configurations (based on the selected type of boot source)
are defined, such as the mount point, the hardware profile, and the bus type. Refer to the online Help
for detailed information about the configuration settings.
Ultimately, a server configuration is associated with an application configuration. Server configurations

cannot be deployed directly to a physical host. They must be associated with an application
configuration, which is then deployed as needed.
Application Configurations
An application configuration defines all the resources needed to create a single session.
An application configuration includes the following information:
Properties The basic information about the application configuration, including the name ,
description, default duration of a session deployed from this configuration, the deployment method
(from where images will be provisioned), and whether or not the application configuration is
locked.
Associated server configurations One or more server configurations are grouped into an
application configuration. Server configurations provide all the information and file references
needed to create fully functioning VMs or deployed physical servers.
Session References A session is an application users session-specific reference to an application

configuration. The session references area shows what sessions are using the application
configuration.
Notes, Materials, and Catalogs A session contains information such as notes, material, and reviews
(Demo Solution only). An application configuration can be added to a specific catalog. Refer to the
CAP web interface online Help for additional information.
When application configurations are deployed to resource pools, a VM or physical computer is

provisioned for each server configuration associated with the application configuration.
Specifying Server Configuration Boot Order

If an application configuration contains multiple server configurations, you can specify the order in
which the server configurations start. You can specify whether server configurations boot concurrently,
serially, or use a mixture of both. For example, if your application configuration contains four server
configurations, you can specify that the DHCP server configuration boots first and the server
configuration that contains the domain controller boots second. You can assign the two remaining
server configurations the same boot order number to start them concurrently. To do so, edit the
application configuration, and set the boot order for each server configuration.
If no boot order is specified and multiple server configurations exist within the application
configuration, the server configurations boot simultaneously.
222
If you specify multiple remote access methods for a server configuration, an application user can
then select the method with which to connect to the resource. For information about configuring
universal remote access (URA) to enable communication from a remote computer to a Cloud
Automation Platform VM, see Universal Remote Access on page 74. Use the Authentication
Type to select the type of user authentication used by the server (VM or physical computer) and
credentials, if required.
A snapshot captures the changes that occur to a base image during a single user session. If the user
chooses to save a snapshot, the undo file is saved to the Snapshots directory in the system library and
is chained to the original base image. For information about snapshots and image files, see Chapter 8,
Image Management, on page 189.
Using the CAP web interface, you can deploy a snapshot and its linked base image, delete a snapshot,
promote a snapshot to a base image, and save a deployed application configuration as a snapshot. For
details about each of these tasks, refer to the CAP web interface online help.
Catalogs
Catalogs serve as a classification tool for objects in the system library. Application configurations,
server configurations, deployment action files, and image files can be included in catalogs. Catalogs
enable administrators to create categories for internal or public use. Entities can belong to multiple
catalogs. For example, you might create three catalogs Pending, Enterprise, and New Labs. The New
Labs catalog might contain application configurations that also exist in the Enterprise catalog as well
as application configurations that only exist in the New Labs catalog. While the Pending catalog might
contain only application configurations that are not ready for release.
From within the CAP web interface, you can create catalogs and edit catalog content.
Managing System Library Objects

Using the CAP web interface, you can create, delete, edit and otherwise manage the system library
objects. To view more information about specific library objects, click the object type in the Navigation
pane to the left, and then click the name of the specific object that you want to manage. Review the
properties and details about the object, and use the menu or buttons at the top of the page to manage the
object.
223
Snapshots
224
11
This chapter discusses reserving resources for deployments, including the prerequisites for deployment,
and the provisioning, deployment, teardown, and re-deployment of sessions. Deploying sessions also
involves file caching, managing deployed VMs and physical servers, and optionally customizing
resource deployments and staging deployments in advance.
Prerequisites to Deployment on page 226
Scheduling a Session Reservation on page 226
Deploying a Session on page 227
Deploying a Session As a Service on page 228
Deploying a Session in Debug Mode on page 230
Deploying a Session in Persistent Mode on page 230
Reservations Requiring Approval on page 229
Deployment Actions on page 231
Managing Sessions on page 235
225
Deploying and
Managing Sessions
Before an application configuration can be deployed as an active session, perform the following steps:
1. Define the physical and network resources that will be used to create the environment. For more
information, see Chapter 9, Physical and Network Resources, on page 207.
2. Make sure the images that your sessions require are in the system library. For more information
about images, see Chapter 8, Image Management, on page 189.
3. Determine whether the default hardware profile values are adequate or create hardware profiles to
meet your requirements for resource deployment. For more information, see Hardware Profiles
on page 220.
4. Create server configurations by grouping one or more images based on the number of drives the
VM or deployed physical server requires. When the server configuration is created, it is linked to a
hardware profile. For more information, see Server Configurations on page 220.
5. Create an application configuration, which defines the resources needed to deploy a session and
the server configurations to which it is linked. For more information, see Application
Configurations on page 222.
6. Create a session, which is based on a single application configuration, and might include materials
and/or be shared with another user. For more information, see Snapshots on page 223.
A session can either be deployed as a standalone session, or it can be joined to other sessions to
create a deployed service, in which multiple application configurations are joined and deployed
simultaneously. For more information about deployed services, see Deploying a Session on page
227.
Typically, an application user schedules a session, which triggers resource deployment. For details
about how to create and deploy a session, refer to the CAP web interface online Help.
Scheduling a Session Reservation

A session can be started immediately or scheduled for a specified time period in future.
A reservation is a set of pooled assets held for a specific amount of time for a specific user in a target
resource pool. Using a date range, a target resource pool, and a session, the Cloud Automation Platform
environment reserves the required host and network resources necessary to deploy the specified session.
These assets are reserved for the specified date range.
A reservation links the following components and events:
226
Resource pool The container for the resources to be deployed and the link to the file cache of
images.
Reserved resources The reservable, pooled computing assets that consist of network and physical
resources such as RAM, host servers, and VMs. A reserved resource is a reservation for computing
capacity.
Prerequisites to Deployment
Scheduled deployment of the reserved resources A scheduled deployment, or reservation, reserves

system library objects, defines how the resources are configured, and defines how users can access
the deployment remotely.
For information about application configurations, sessions, and the system library, see Chapter 10,
System Library Objects, on page 217.
Using the CAP web interface, you can create, view, change, or cancel session reservations. When you
change or cancel a reservation that you did not create, the owner of the reservation is sent a notification.
To create a test deployment, use the CAP web interface to deploy a session. No application users have
access to this deployment, but you can monitor the stages of the deployment. Any errors can be
addressed before application users begin creating reservations.
If a scheduled session cannot occur as scheduled because of a resource issue, an event is logged. Using
event monitoring, you can address resource issues before a deployment is impacted in most cases. For
details, see Monitoring Components Using Syslog on page 268.
Occasionally, you might want to reserve a resource without scheduling a deployment. You can schedule
a maintenance window for a virtualization host or a physical computer to accomplish this. For details,
see Performing Maintenance on Hosts on page 162.
Optionally, an administrator can configure a session to have a reservation expiration notice; when a
session reaches a defined time before the end of the scheduled reservation, a notification will be created.
Refer to the online Help system for details about configuring reservation expiration notifications.
Deploying a Session
A session can be started immediately or scheduled for a specified time period in the future. The
following section discusses the deployment of the session, whether scheduled or started immediately.
Before a session is deployed, Cloud Automation Platform checks the availability of virtualization host
(or physical computer) resources for the total amount of time for which those resources are required.
The required amount of time includes the length of the users reservation plus any setup and teardown
time. For instance, a session that runs for one hour might take 10 minutes to provision the resource and
another 15 minutes to deprovision the resource. Therefore, the total amount of time that the resources
are required is one hour and 25 minutes.
Note: The setup and teardown times affect the quota for reservation maximum duration. If the total
time requirement exceeds the quota, the reservation cannot be scheduled. For details, see
Quotas on page 250.
When a resource is reserved, a set of deployment directives defines how the resource is configured, and
a set of remote access instructions defines how a user can access the scheduled resources.
By default, resource deployment is based on load balancing. For server configurations based on virtual
machine images, the host with the greatest amount of available RAM is chosen at fulfillment time,
which spreads VM load across the infrastructure. However, if a file cache location already has the
227
For more information about resources, see Chapter 9, Physical and Network Resources, on page
207.
For sessions using server configurations that are based on a physical server images, a single physical
computer is provisioned for each server configuration.
When a session is deployed, the assigned resource pool provides the virtualization host or physical
computer and defines the file cache locations. Deployment configures a VM or physical computer for
each server configuration associated with the application configuration. The associated images are
copied to the file cache locations as necessary and are then attached to the available VMs or the
designated physical computers. For instance, if a server configuration contains ISO files and hard drive
files, both are copied to the file cache location when an application configuration is deployed and both
are attached to the corresponding VM or physical computer.
The following figure shows the deployment workflow for a session with two server configurations.
Figure 1 Deployment Workflow
Later, when the same session is reserved, Cloud Automation Platform determines if the images stored
in the file cache location have changed, indicating that new copies need to be provisioned from the
system library.
You can monitor deployed VMs and deployed physical servers from the CAP web interface.
Administrators can use the Sessions table to monitor and modify deployments. The table of sessions can
be searched by name, or filtered to show only sessions owned by the user or all sessions. Additionally,
a user can select to show only sessions with snapshots. For more information about other available
commands, see Managing Sessions on page 235.
Deploying a Session As a Service

Cloud Automation Platform provides the ability to join multiple sessions (each based on a single
application configuration) together to create a Service. By building a stack of related sessions, IT
228
appropriate image cached and a VM linked to that cache location with sufficient capacity is available
that VM is used.
To specify that a session should be deployed as a Service, schedule the session (or an application
configuration) and under Advanced Options, select Joinable Service as the Deployment Mode.
Designating a session as a Joinable Service means that other sessions can be added to it to create a
service. After the first session has been created as a joinable service, other sessions or application
configurations are added to it by scheduling them and selecting Join Existing Service as the
Deployment Mode. For detailed instructions to schedule an application configuration or session as a
Service, refer to the online Help.
After a Service has been deployed, the Service can then be saved as a new application configuration.
This new application configuration contains the full stack of all the server configurations included
in each of the sessions deployed by the Service.
When scheduling a session as a Joinable Service, and the session (known as the base session) uses
DHCP and a public broadcast network, you can specify the expected number of servers that can be
joined to the base session to create a Service. This allows the system to reserve the required number
of network resources for all the sessions that are included in the Service. Be aware that any joining
services utilize the network resources that are reserved by the base session (Joinable Service); they
do not have their own resources.
When joining a session to an existing Service, be sure to select the name of the Service that you
want to join. By default, the first Service created is shown in the To Service field.
Any sessions that you join to the base session must use a network type that is also used by the base
session. For example, if the base session uses DHCP for IP addresses, you can only add a DHCP
session, but not a session that uses NAIL 3. However, if the base session contains two server
configurations, one of which uses DHCP and the other NAIL 3, you can join either type of session
to that base session.
By default, the privileges to create a Service (DeployedService.Create) and delete a Service

(DeployedService.Delete) are granted to the Admin privilege set, and thus to members of the
Administrators group. Members of the Users group are by default granted the privilege
DeployedService.Join, which allows the user to add a session to an existing Service.
Reservations Requiring Approval

Users who do not have the Self Service privilege set can request a reservation, but the session is not
deployed until an administrator with the Reservation Approver privilege set grants approval.
In the CAP web interface, you can view all sessions that are waiting to be approved for deployment. In
the left pane, click Pending Approvals. From the Reservations Pending Approval page, an administrator
can Approve or deny the reservation request.
229
Operations and other organizations can use Services to create a single deployment that provides
multiple, concurrent purposes. The individual sessions can still be deployed as a standalone session, or
joined with other sessions to create a Service.
Deploying a Session in Debug Mode

When scheduling a session, users with the required privileges can expand the Advanced Options and
select Debug Mode under Deployment Options. Using debug mode sets the deployment automation to
allow deployment even if there are VM (or physical server) start failures and Quest CAP Agent checkin failures. Neither of those conditions will cause the reservation to be canceled or any de-provisioning
actions to take place. However, if either of these conditions exists for a VM or physical server within
the deployment, both the server and session are shown to be in the state Available with Errors rather
than Available. Once a session is deployed in debug mode, that session will by default continue to
deploy in Debug Mode, unless the option is deselected.
Note: Debug mode is not available for Training Labs.
For detailed instructions to implement Debug mode, refer to the online Help.
Deploying a Session in Persistent Mode

Certain types of sessions can be very read/write intensive, and long-running sessions can sometimes
create large redo files, or differencing disks, which are expensive both in storage and read/write activity.
Cloud Automation Platform offers the deployment option of running the session in persistent mode.
When running in the persistent mode, a session does not use a redo file, to store changes made during
the session to the base image. Instead, a copy of the base image is made at deployment time, and changes
made during the session are written to that copy, instead of to a redo file.
For detailed instructions to implement persistent mode, refer to the online Help.
Important considerations:
230
The default mode for new server configurations made from an empty boot disk is persistent mode,
and the default for non-empty boot disk is to use a redo file. With non-empty disks, the mode is
inherited by the new server configuration.
An administrator can override the default mode by editing the settings for the server configuration
from the application configuration edit page.
VMs running in persistent mode will support the same set of operations as VMs running with a
difference disk: snapshots, promote, etc.
For an overview about reservation approval, refer to the online Help topic About the Reservation
Approval Process. For detailed information about creating users who require approval to deploy a
session, refer to the online Help topic Creating a User without Self-Service Privileges.
A Deployment Action is a file, normally a script of some type, or an externally defined job, such as
an Altiris job, that is associated with a specific server configuration and then run on the VM or
deployed physical server either immediately after a session starts, or when manually selected to run.
Three different types of deployments actions are supported:
Guest Agent Actions
HP Server Automation Policies (Audit, Patch, and Software)
Altiris Deployment Server Jobs
Deployment Action files are stored in the system library, and are added to the library using the CAP web
interface.
Actions are run against a particular server configuration within an application configuration. The action
is not persistently attached to the server configuration itself. The same server configuration may be used
within a different application configuration and be deployed with a different action or with no action.
Guest agent actions can only be executed on server configurations (VM or physical) that have a guest
agent installed. Results of an action are collected and saved with the session; each server configuration
stores the results of whichever deployment action was run on it. To view the results, open the Sessions
table, and then click the blue menu icon beside the name of the session for which you want to view
deployment actions. From the menu list, select View Deployment Actions.
When the deployment action is added to the application configuration, the Run Mode is selected. The
Run Once mode causes the deployment action to run only the first time that the session starts. Run
Always causes the deployment action to run every time that a session using the server starts. The Manual
mode allows you to later choose whether and when to run the deployment action on an active session,
using the Run Deployment Action process.
Note: The manual process of running a deployment action can be used no matter which Run Mode
was selected when the deployment action was originally added. For example, you might select
Run Always mode when you add the action, meaning that the action will run every time that the
sessions starts, but also run the action manually multiple times during the session.
Running Deployment Actions

Note: Refer to the online Help for additional information about using deployment actions.
The method for manually running a deployment action for a guest agent action, an HP Server
Automation action, or an Altiris job are the same. However, the configuration and prerequisites for each
are different.
To run a guest agent action, the following steps must have been already accomplished:
1. Add a deployment action file to the system library
231
Deployment Actions
3. Start the session of the application configuration containing the deployment action.
Before running an HP Server Automation action, verify that the required setup steps have been
already accomplished. See About Running HP Server Automation Policies on page 233 for more
Before running an Altiris Deployment Server Job, verify that the required setup steps have been
already accomplished. See About Running Altiris Jobs on page 234 for more information.
When the deployment action is initially added to the application configuration, the Run Mode is
selected. The Run Once mode causes the deployment action to run only the first time that the session
starts. Run Always causes the deployment action to run every time that a session using the server
configuration starts. The Manual mode allows you to later choose whether and when to run the
deployment action on an active session, using the Run Deployment Action process described below.
Note: The manual process of running a deployment action can be used no matter which Run Mode
was selected when the deployment action was originally added. For example, you might select
Run Always mode when you add the action, meaning that the action will run every time that
the session starts, and then you can also run the action manually multiple times during the
session.
To run a deployment action on a server in an active session, perform the following steps:
1. In the left pane, click Sessions.
The table of existing sessions appears.
2. In the table in the right pane, click the name of the active session that contains the server
configuration against which you want to run the deployment action.
The session must have been started and in an Available state to run a deployment action on it.
3. On the Sessions Details page, click Run Actions.
The Run Session Actions page appears.
4. On the Run Session Actions page, in the Deployment Actions area, click Run All Actions. If there
are multiple servers in the session with actions, you can select each server individually or run all
actions .
232
2. Add a deployment action to an application configuration that contains the server configuration
against which you want to run the deployment action.
Cloud Automation Platform integration with HP Server Automation allows you to run HP-SA Software,
Audit, and Patch policies against sessions in the Cloud Automation Platform environment.
For specific instructions to run an HP Server Automation policy against a VM in the Cloud Automation
Platform environment, see Adding a Deployment Action and Running a Deployment Action.
The HP Server Automation core server must be configured to enable automatic installation of the
HP Server Agent on the HP Server Automation core server when an HP Server Automation policy
is run. The HP Server Agent is automatically removed from the core server when the session is
finished. See Configuring HP Server Automation Core Server on page 233.
A Quest CAP Guest Agent must be installed on the VM against which the HP SA policy is run.
There is no option to stop an HP SA policy once it has started.
The guest operating system of the server configuration to which the policy is associated must be
supported by HP SA.
To run an HP Server Automation action, the following steps must have been already accomplished:
1. In the HP-SA environment, create the appropriate Policy (Software, Patch, or Audit Policy).
2. (Audit Policy only) Create an HP-SA Archived Snapshot to serve as the source against which to
compare to the target server (Cloud Automation Platform VM or physical computer). The name of
the Audit Policy must match exactly the name of the Audit Policy, with the pre-fix "Audit Source:"
3. In the CAP web interface, register your HP Server Automation as a Partner Extension. Refer to the
online Help for exact directions.
4. In the CAP web interface, add the policy (as a deployment action) to an application configuration
that contains the server configuration against which you want to run the deployment action. Refer
to the online Help for exact directions.
5. Start the session of the application configuration containing the deployment action. Refer to the
online Help for exact directions.
Configuring HP Server Automation Core Server
To run an HP Server Automation policy, configure the HP Server Automation core server to enable
automatic installation of the HP Server Agent on the core server. To enable automated installation, the
location on the SA Core that contains the Server Agent installers needs to be made available in readonly fashion over both NFS and CIFS. This is accomplished by modifying the SAMBA configuration,
the NFS configuration, and making the installers themselves executable.
1. On the HP SA core server, export /var/opt/opsware/agent_installers via CIFS:
A. Add the following to /etc/opt/opsware/samba/smb.conf:
233
About Running HP Server Automation Policies
path = /var/opt/opsware/agent_installers
read only = yes>
B. Restart the Samba services:

opt/opsware/samba/sbin/samba restart
2. Export the same directory via NFS using the following command on the HP SA Core server.
A. Add the following line to /etc/exports:
/var/opt/opsware/agent_installers *(ro)
B. Restart the NFS services:

/etc/init.d/nfs restart
3. Make the installers executable:

chmod +x /var/opt/opsware/agent_installers/*
About Running Altiris Jobs

Cloud Automation Platform integration with Symantec Altiris Deployment Solution allows you to run
Altiris jobs against sessions in the Cloud Automation Platform environment.
For specific instructions to run an Altiris job against a VM in the Cloud Automation Platform
environment, see the online Help topics Adding a Deployment Action and Running a Deployment
Action.
The Altiris Deployment server agent must be installed on the VM against which the Altiris Job is
run.
A Guest Agent is not required to be installed on the VM against which the Altiris Job is run.
Cloud Automation Platform Administrators must have full access to all Altiris Jobs and to the
Altiris Deployment Server.
Before running an Altiris Deployment Server Job, the following steps must have been already
accomplished:
1. Verify that the Altiris Deployment Server agent is installed and running on the Altiris server.
2. On the Altiris Deployment Server, create the Altiris Job(s).
3. In the CAP web interface, add the job (as a deployment action) to an application configuration that
contains the server configuration against which you want to run the deployment action.
4. Start the session of the application configuration containing the deployment action.
234
[hpsa-installers]
You can manage the resources for a scheduled deployment before and during session deployment.
Using the Sessions table in the CAP web interface, you can view, modify, and cancel unscheduled,
pending and deployed sessions.
Refer to the CAP web interface online Help for exact instructions for each of these tasks.
You can perform the following commands for every server configuration or for a specific server
configuration in a session. Some of these tasks can only be performed on an active session, using the
Session Commands menu on the Sessions Details page.
Edit Edit the details of the session.
Delete Delete the session.
Cancel Reservation Cancels the reservation.
Schedule Schedule when the session should deploy.
Start Now Starts the session immediately, if the required resources are available.
Duplicate A user to whom a session is shared can duplicate, or make a copy of, a session, thereby
creating a version of that session for which they are the owner.
Promote When you promote a snapshot, a new application configuration, server configuration,
and image file is created based on the existing snapshot.
View Deployment Actions Any deployment actions that are associated with a server configuration
in the session can be viewed.
Run Deployment Actions Runs any deployment actions that are associated with a server
configuration in the session.
View Resource Utilization The Resource Utilization dialog box displays the list of Asset Types
(MAC Address, IP Address, RAM, Virtual Machine, etc.), the Server Configuration that contains
the asset, the Amount of each asset, and the Source of the asset.
Extend Extends the reservation deployment time.
Rollback Discards the changes made to an image and returns the VM to its last saved image state.
Snapshot Saves the current state of all VMs in a session so you can restore the VMs to the state
preserved in that snapshot.
Save as Saves a new application configuration, server configuration, and image based on the
currently deployed VM.
Suspend all / Suspend Saves the current state of all VMs or a specific VM temporarily, so you can
continue work later from the same state. You cannot restore a VM using this command. Use the
Suspend command in combination with the Run command.
Stop all / Stop Stops all the VMs or a specific VM.
235
Managing Sessions
Run Starts all the VMs that were stopped or suspended.
Additional available actions for a specific VM include:
Restart Restarts a VM that is currently running.
Change RAM Changes the amount of RAM allocated to a VM after an application configuration
is deployed.
Note: A VM must be stopped before you can change its RAM allocation.
236
Attach media Attaches a CD-ROM, DVD, or ISO device to a deployed VM.
Console / RDP / VNC / Citrix Connects to a remote desktop session for the selected VM.
12
This chapter explains the components that govern access control within the Cloud Automation Platform
environment and changes that can be made to access control using the CAP web interface.
Overview on page 238
Privileges on page 239
Privilege Sets on page 239
Groups on page 241
Users on page 243
Manually Changing Access to Objects on page 243
237
12 Access Control
Access Control
Cloud Automation Platform uses the access control list (ACL) model to enforce access control. As a
result, access control governs almost every object in the Cloud Automation Platform.
Cloud Automation Platform assigns privilege sets to user groups to provide access control. Access
control dictates which groups can create, delete, view, or edit content. Access control combines the
following elements:
Privileges A privilege is the basic unit in access control. For instance, create account is a
privilege.
Privilege sets A privilege set is a collection of privileges, which can be assigned to a group or user.
Groups A group combines user accounts in a single collection. A group is assigned a privilege set,
which dictates the objects to which the group has access.
Users A user account belongs to a group and inherits access control from that group. A user also
has direct privileges on any object that he creates.
Access control objects An access control object is a Cloud Automation Platform object (i.e. an
image, a server configuration) on which a privilege can be granted. A user or a group can be granted
privileges directly for a specific object.
A groups access rights are determined by the privilege set assigned to it and the objects on which the
privileges act. Additionally, privilege sets can be assigned for a specific object; you can select certain
users or groups (and define their privilege sets) that have privileges on the object. The following graphic
illustrates the relationship between users, a group, privilege set, and an access control object. In this
example, the Users group is assigned the user privilege set and then acts on the application configuration
access control object.
Group: Users
Sue Normal
Access controlled
object
John Quo
Application
configuration
Trent Smith
Privilege set: User

AppConfig.View
AppSession.View
Figure 1 Relationships Between a Group, Privilege Set, and Access Controlled Object
238
12 Access Control
Overview
Access control is closely aligned with organizations and user management. Those concepts are
discussed in detail in the following chapter, Chapter 13, User Management, on page 245.
Privileges
A privilege is the basic unit in access control. Privileges are defined by Cloud Automation Platform and
are enforced in the Cloud Automation Platform code. Privileges are associated with a privilege set. A
platform administrator can associate privileges with a privilege set, but he cannot create new privileges.
Each privilege is linked to a specific type of object. For example, for the Catalog object, there are
privileges such as Catalog.Create, Catalog.Delete, Catalog.Edit, and Catalog.View.
In general, privileges for access control objects are of the following types:
View A user can view an access control object and run reports that include data from this object.
Edit A user can view an access control object and change settings that include this object.
Create A user can create the specified access control object within his organization.
Delete A user can delete the specified access control object.
Use A user can use image files from the file cache or resources in a resource pool.
Manage A user can manage a range of IP addresses, MAC addresses, or virtual network addresses
for a resource pool.
Execute A user can execute agent and script commands.
To view the privileges assigned to a privilege set, click Settings in the left pane (the Navigation pane)
of the CAP web interface. Click the blue menu icon beside the name of the privilege set and then select
Edit.
Privilege Sets
Privilege sets are a collection of privileges that are assigned to groups or user accounts. Privilege sets
group similar privileges to provide a single unit to assign to a group or user, which simplifies access
control management. The default Cloud Automation Platform privilege sets include:
Platform administrator Users with this privilege set can create, view, edit, delete, and access all
portions of the Cloud Automation Platform environment.
239
12 Access Control
Typically, the Cloud Automation Platform environment uses organization-wide access control. Groups
provide a method for easily assigning default behavior. A user who belongs to the Users group has the
User privilege set on every object in the organization. However, occasionally you may want to grant
access control on a specific object basis. For more information, see Manually Changing Access to
Objects on page 243.
Administrator Groups with this privilege set can create, view, and modify access-controlled
objects within their organization. Users who require the administrator privilege set generally
include sales engineer administrators, technical instructors, and test administrators. Members of the
Administrators group are assigned this privilege set by default.
Suborganization administrator Users with this privilege set can modify child organization quotas
and delete organizations. Users can also view information about all parent organizations by default.
This privilege set is used in combination with other privilege sets and is automatically assigned to
users who create child organizations and to members of the Administrators group.
User Groups with this privilege set typically include Training, Demo, or QA/Test Solution users
(sales engineers, instructors, or testers) who require scheduling privileges. Members of the User
group are assigned this privilege set by default.
Restricted Groups with this privilege set typically include evaluation users and students who
require view-only privileges. Members of the Restricted group are assigned this privilege set by
default.
Report Viewer Groups with this privilege can review reports created from the Cloud Automation
Platform reporting database.
Reservation Approver Partial role granted to users that approve or deny reservation requests.
Self Service User Partial role granted to users that are allowed to deploy sessions without
approval. Refer to the online Help topic About the Reservation Approval Process for detailed
information.
Session Viewer Groups with this privilege set include evaluation users and students who require
view-only privileges for sessions. This privilege set is used in combination with the Restricted
privilege set and is automatically assigned to users who require view-only privileges for sessions.
This privilege set enables users to view a session and its deployment.
Although the default privilege sets are sufficient for most environments, privilege sets can be edited and
customized if necessary. Only a platform administrator can modify the privileges associated with
privilege sets. Any changes made to a privilege set affects all the groups that use that privilege set. A
platform administrator can also delete default privilege sets, but it is not recommended.
A platform administrator can add a new privilege set or duplicate an existing privilege set. When a
privilege set is created, it has no privileges. They must be assigned manually. When a privilege set is
duplicated, it is based on an existing privilege set and its privileges. For example, to create a privilege
set that uses nearly the same privileges as the user privilege set, duplicate the user privilege set and then
add or remove privileges to modify the new privilege set.
The easiest way to change a specific users privilege set is to change the users group assignment. You
can remove a user from one group and assign the user to another group, which changes the users
privilege set. Alternatively, you can modify the objects to which the user has access. For more
information, see Chapter 12, Manually Changing Access to Objects, on page 243.
240
12 Access Control
A group combines user accounts in a single collection. Groups are assigned a default privilege set which
determines the level of access group members have to objects within their organization. When you add
a user to a group, the user inherits the privilege set assigned to that group.
The default Cloud Automation Platform groups include:
Administrators Users who require Administrator group membership generally include sales
engineer administrators, technical instructors, test administrators, and organization managers. The
administrator privilege set is automatically assigned to all members of the Administrators group.
Users Typically, users who are sales engineers, instructors, or testers belong to the Users group.
The user privilege set is automatically assigned to all members of the Users group.
Restricted Users Typically, all demo users, evaluation users, and students belong to this group.
The restricted user privilege set is automatically assigned to all members of the Restricted User
group.
Note: Be aware that all new users are added by default to the Internal organizations Restricted User
group. This group has the Self Service privilege set, so users of the group have, by default, the
ability to start or schedule any session to which they have access. For detailed information about
creating users who do not have the Self Service privilege set, refer to the online Help topic
Creating a User without Self-Service Privileges.
Whenever an organization is created, the preceding groups are automatically added to the organization.
When a group belongs to a child organization, the organization name displays before the default group
name. For instance, the group names for the Training organization are Training Administrators,
Training Users, and Training Restricted Users. For more information about organizations, see
Organizations on page 246.
Group membership is determined when a user account is created. When a user account is created in the
CAP web interface, you select either a group, or if you save the new user without selecting a group, one
will be automatically assigned based on the users persona. For instance, if the user account is assigned
the Instructor persona, the account is assigned to the Users group. For more information about personas,
see Personas on page 253.
When a user self-registers using an application, a group is automatically assigned to the user account
based on the organization default value. In most cases, the default group for an organization is the
Restricted Users group. Using the CAP web interface, you can change a users group membership if
necessary.
Creating Groups
Note: The information in this section is only relevant if you want to customize the default access
control settings for an application. Typically, the default groups are the only groups an
organization requires.
241
12 Access Control
Groups
In the following graphic, a member of the Users group also belongs to the Reporting group. The
Reporting group has a custom privilege set, Reporting, which provides access to additional reporting
privileges.
Group: Users
Tim Sill
Privilege set: Users
Mary Brown
Gus Noun
Group: Reporting
Privilege set:
Reporting
Tim Sill
Access controlled objects

Reviews
Files
Accounts
Pools

Reports
Figure 2 Example of a Group with a Custom Privilege Set
Using the CAP web interface, you can create groups. When you create a group, specify one of the
following default access behaviors:
Automatic The groups assigned privilege set is automatically assigned to newly created objects,
which gives group members immediate access to new objects.
Manual The group must be manually assigned to each newly created object. Therefore, members
of the group have no access to objects until you manually change access permissions for the objects.
For more information, see Manually Changing Access to Objects on page 243.
If you select the Automatic option, you must then select one or more default privilege sets on newly
created objects for each organization.
Access control is not retroactive. If a groups privilege set is modified after objects have been created,
you must manually edit the permissions on existing objects to include the group. For instance, if you
create several application configurations, members of the Administrators group automatically have
access to those objects. If you modify the Users group privilege set to include application configuration
privileges, you must manually edit permissions on existing application configurations to include the
Users group. Any new application configurations automatically include the Users group as a permitted
group.
242
12 Access Control
Create groups to easily distribute custom access control to specific users. For instance, you might add
a user to multiple groups so the user inherits access to the privilege set closest to his needs and then
inherits an additional group assignment with the custom access that he requires. For instance, if you
create a Reporting group to enable specific users to run reports, you might assign those users to the
default Users group also. Since the Reporting group members only inherit access to reports, the users
also require the Users group membership.
A users access to and permissions on objects are controlled by the users group membership. Users
belong to one or more groups, which have been granted access to objects in the environment. The
privilege set assigned to the group dictates the permissions that group members have on these objects.
Users have additional privileges on objects that they create, known as account-owned objects. The
owner is given an explicit administrator privilege set on these objects, in addition to the privilege set
assigned to the users group. For instance, snapshots and reviews are owned by the user who creates
them. If that users group membership changes, the user can still view, use, and manage the objects that
he created even after being moved to a different group with a different privilege set. For more
information about privilege sets, see Privilege Sets on page 239.
The following graphic shows an example of account owned objects associated with a single user
account. Tim belongs to the Users group and has the user privilege set on all access control objects in
the Cloud Automation Platform. Tim has administrator privileges on the snapshots that he creates. Other
members of the Users group have the user privilege set on the objects that Tim creates.
Group: Users
Privilege set: User
Tim Sill

Accounts
Mary Brown
Gus Noun
Snapshots
Reviews
Privilege set: Admin
Account owned objects
Tim Sill
Snapshot...n
Figure 3 Example of User Access Control Privileges
For more information about a users access to and permissions on objects, see Groups on page 241.
Manually Changing Access to Objects

Using the CAP web interface, you can manually assign groups or users access to individual objects
including:
Hardware profiles
Server configurations
Application configurations
Catalogs
Images and files
243
12 Access Control
Users
Resource pools
Network resources
File caches
Organizations
Groups
Users
Reports
12 Access Control
Optionally, you can also change a groups privilege set on those objects. For details on how to change
access permissions for a specific object, refer to the CAP web interface online help.
In the following graphic, a Users group is assigned the administrator privilege set, which is then applied
to the specific application configuration selected in the system library. For instance, if a group is
assigned the default user privilege set, but needs additional privileges to create, edit, and delete a
specific application configuration, the administrator privilege set must be associated with that group for
that application configuration. The privilege set assignment and object access enables a group to
perform the task.
Administrator
privilege set
OR
Assigned
Applied to
Individual
application
configuration
Users group
Figure 4 Relationships Between a Group, Privilege Set, and Library Object
244
13
This chapter explains the components involved in managing user accounts including organizations, user
accounts, user groups, quotas, and personas.
In the Cloud Automation Platform environment, user management is linked to access control. Before
you create an organization or add users to an organization, make sure the access control that your
environment requires is in place. For more information about privilege sets, user groups, and access
control, see Access Control on page 237.
Organizations on page 246
Creating User Accounts on page 249
Creating Groups on page 250
Quotas on page 250
Personas on page 253
Authentication Methods on page 262
245
13 User Management
User Management
An organization is a collection of users and objects with a common business objective. The objects that
belong to an organization include:
Child organizations When an organization adds a suborganization, that child organization belongs
to the parent organization.
User groups When an organization is created, it is automatically populated with default groups.
These groups belong to the organization. For more information, see Creating Groups on page 250.
User accounts A user account belongs to the organization in which it is created.
Cloud Automation Platform objects When a Cloud Automation Platform object (application
configuration, server configuration, hardware profile, and so on) is added, it belongs to the
organization in which it is created.
Organizations dictate the user experience, set limits on capacity, and facilitate reporting. Organizations
also provide a way to capture product customizations in clearly labeled files and directories. For
example, if your company provides self-paced training and instructor-led training using the Training
Solution, you can set up two organizations, one for the self-paced training, and another for the
instructor-led training. Then, you can define the appropriate quotas for each organization. For instance,
you can set the maximum number of user accounts for the self-paced training class to 25 and the
maximum number of user accounts for the instructor-led training to 10. Using Cloud Automation
Platform reports, you can review data about each organization. For details about reports, see Chapter
15, Reports, on page 271.
The Cloud Automation Platform environment supports hierarchical organizations.You can create as
many organizations as needed for your environment.You can also create suborganizations for those
organizations. As a best practice, create at least one suborganization. Sibling organizations cannot see
each other. However, sibling organizations can both use the same system library objects if necessary.
Additionally, a single resource pool can be shared, which allows multiple organizations to use the same
network and host resources. Using a single resource pool enables the most effective use of limited
resources by balancing resource requests and providing high availability of resources.
A default organization, Internal, is automatically set up when the CAP Core server is installed. The
Internal organization sets the quotas for the organization hierarchy and the platform administrator user
account (the super user) belongs to this organization. This organization cannot be deleted. If your
Cloud Automation Platform environment is hosted by the Cloud Automation Platform data center,
Cloud Automation Platform maintains the Internal organization. If your environment is not hosted by
the Cloud Automation Platform data center, your company must appoint a platform administrator and
set the quotas for the organization hierarchy.
Each organization can have customized skins that provide a specific look and feel for the application
UI. Child organizations inherit customizations from their parent organization. Although, specific child
customizations can override parent customizations if necessary.
Figure 1 illustrates an example organization structure. The main organization is called Training.
Suborganizations include Self-Led and Instructor-Led. You can create additional suborganizations for
each of these suborganizations if necessary. For instance, you might want to create suborganizations in
246
13 User Management
Organizations
In the following graphic, the Internal organization sets quotas for the suborganizations in the hierarchy.
The Training organization sets additional quotas for its child organizations, Self-Led and Instructor-Led.
For additional details, see Quotas on page 250.
Internal
Organization
Parent organization
Training
Child to Internal
organization
Parent to Self-Led
and Instructor-Led
Self-Led
Instructor-Led
Children to
Internal
and
Training
Figure 1 Example of an Organization Hierarchy
A single user account in an organization is identified as the organizations contact point, called the
Organization Manager. The Organization Manager belongs to the Administrators group. For instance,
you might identify your organizations IT Manager as the person to contact since any issues with the
organization might be funneled to her. The user assigned to be the organizations contact can be
changed.
Organization settings determine an accounts persona (and thus group membership) when a user self
registers. You can create organizations to enable different self-registration options per organization. For
more information, see Personas on page 253.
Relationship Between Organizations and Access

Control
Since users and groups are subject to access control rules and yet belong to an organization,
organizations are closely related to access control.
The following figure illustrates a possible access control environment based on group access and
privilege set assignment and how it relates to the organization hierarchy. The following points are
illustrated:
The platform administrator sets the quotas for the entire organization hierarchy. The platform
administrator privilege set is only available in the Internal organization.
Members of the Administrator group can edit quotas for suborganizations that they create.
Members of the Users group can view other members of the same organization only.
247
13 User Management
the Self-Led organization based on branding and snapshot capability. Accounts in both organizations can
utilize the same courses, but use different branding and snapshot settings.
Members of a suborganization are also included in the parent organizations Restricted Users group.
This provides suborganization users with view privileges on application configurations by default.
Members of the Restricted Users groups cannot view any organization hierarchy or user
information. Members of this group can view only the evaluations or labs to which they are
assigned.
If any of the default Cloud Automation Platform privilege sets are changed at any level of the
organization hierarchy, the change is applied to every organization within the hierarchy.
Internal Organization
Sets quotas for the
organization hierarchy and
has access to all organizations.
Cannot be modified or deleted.
Platform
Admin
Training Organization
Group: Users
Group members
can view other
members of
this organization
User 1
Group: Admin
Suborganization
Admin
User 2
Created the Self-Led

and Instructor-Led
Organizations and
sets quotas for those
organizations
Group members cannot

view users in sibling Sub-orgs
Self-Led Organization
Group: Restricted
Restricted User 1
Restricted User 2
Group: Admin
Organization
Admin
Instructor-Led organization
Group: Restricted
Restricted User 1
Group: Admin
Organization
Admin
Restricted User 2
Figure 2 Example User Access Control Scenario in a Organization Hierarchy
In the following graphic, Chris Cay is assigned to the Administrators group with the administrator
privilege set. As a member of the Training organization, Chris can view both the Self-Led Training and
the Instructor-Led Training organizations as well as the Training organization. Both Mary Smith and
June Park are also assigned to the Administrators group with the administrator privilege set. Neither can
view any information about the others organization. Both are members of the Restricted Users group
on the Training organization and both have view privileges on application configurations in the Training
organization by default.
248
13 User Management
Chris Cay
13 User Management
Training Organization
Chris Cay can view

the child organizations,
Self-Led and InstructorLed Training because
he has administrator
privileges.
Self-Led Training
Organization
Mary Smith
Instructor-Led Training
Organization
The child organization

administrators cannot
see information from
other sibling
organizations.
June Park
Figure 3 Example of Multiple Organizations and Implications of Privilege Sets
For more information, see Privilege Sets on page 239.
Creating User Accounts

The organization in which a user account is created is considered the users home organization. Even
if a user account can access suborganizations, the user account only belongs to a single organization.
For instance, in Figure 3, Chris Cay belongs to the Training organization, but he can access components
in the Self-Led Training and the Instructor-Led Training organizations as well.
Using the CAP web interface, a user who belongs to the Administrators group can create, edit, and
delete user accounts. When a user account is created, the administrator specifies the persona for the user
account, and the user is automatically assigned to the corresponding user group. The administrator also
specifies general account information, such as e-mail address and password. The user can edit the
general account information. However, only userss in the Administrator group can change the user
persona. For details about personas, see Personas on page 253.
If a student or an evaluation participant registers for a class or product demonstration, a user account is
automatically created. The user account is assigned a default persona, which is defined by the
organization. By default, any user account that is created in a suborganization of Internal is assigned to
the Internal Restricted Users group. A member of the Administrator group can change user account
information if necessary.
When a user is added to a group, he inherits the groups assigned privilege set. A member of a
suborganization is automatically added to the parent organizations Restricted Users group. As a
member of the parent organizations Restricted Users group, a user has view privileges on any
application configurations created in the parent organization.
249
Creating Groups
The Cloud Automation Platform environment provides the following default groups in suborganization:
Administrators
Users
Restricted Users
For more information, see Groups on page 241.

Typically, a user account is assigned to one of the default groups, depending on the persona assigned to
the account. However, an administrator can create a new group to grant custom permissions or more
selective access to objects. For instance, if your company wants to group instructors by region or by
speciality and then grant those users additional privileges, a new group might be the best solution. As a
result, you might create a group for East Coast or a group for Enterprise Software. Then, if you want
East Coast instructors to modify specific application configurations, you can ensure that only that group
can edit those configurations.
A group belongs to the organization in which it is created (i.e. . When a group is created, the default
access type is specified. Default access types include:
Automatic If automatic is specified, the group automatically has the specified privilege set on all
new objects.
Manual If manual is specified, members of the group will not have access to newly created objects
unless access is explicitly granted.
For details about manually assigning objects to a group, see Manually Changing Access to Objects
on page 243.
An alternate means of controlling user access and permissions is to create a suborganization. The
suborganization inherits all the groups and privileges of the parent. You can also limit group privileges
to meet the requirements for the suborganization. A suborganization can also contain groups.
Quotas
Every environment has a limited amount of computing and storage capacity. This limit can be increased
or decreased by adding or removing additional host servers or disk space. However, there is always a
limit on the amount of capacity that an organization can use.
Hierarchical organizations must share capacity. To prevent monopolization, each organization has a set
of limits, or quotas, on capacity. Quotas restrict an organizations peak usage for reservations,
snapshots, user accounts, reserved resources, and published application configurations.
250
13 User Management
Note: For information about creating users who require administrative approval for reservations, refer
to the online Help topic Creating a User without Self-Service Privileges..
General Sets user account, application configuration, and library quotas.
Maximum number of accounts Specifies the maximum number of users in the organization.
Maximum unlocked applications Specifies the maximum number of available application

configurations.
Maximum library space Specifies the maximum amount of storage capacity that is permitted
for images and snapshots per organization.
Reservations Sets restrictions for reservations.
Advanced scheduling Specifies the maximum number of days in advance that a user can
schedule a reservation.
Note: The reservation must be completed before the maximum number of days is reached.
Maximum deployment duration Specifies the maximum number of days that a reservation can
occur.
Snapshots Sets quotas for snapshots.
Maximum space allowed Sets the maximum amount of storage capacity permitted for
snapshots per organization.
Maximum space per user Restricts the amount of storage that a user can consume for snapshot
storage. If the maximum space limit is exceeded, an error message displays. An administrator
can remove unnecessary or outdated snapshots in order to create space to save new snapshots.
Resources Sets quotas for reserved resources.
Maximum concurrent servers Sets the number of VMs (or physical server configurations) that
can be deployed at the same time across the entire organization. For instance, if a user deploys
an application configuration that includes a Web server, database, and application server, the
application configuration uses three VMs. If the maximum concurrent value is set to two, the
deployment will fail. For the Training solution, this quota must account for the number of
students per class also. For instance, if an instructor schedules a class of 25 students and each
lab requires 4 VMs, the maximum concurrent value must be greater than 100.
Maximum total servers per user Sets the number of VMs or physical servers that any one user
can schedule. For instance, if a limit of two exists and Chris schedules two single-server demos
to start immediately, he cannot schedule another demo until one of the deployed demos finishes.
For the Training solution, this quota must account for the number of students per class also.
Since the quota is the same for all users in the organization, the instructor must have a large
enough quota to account for himself and all of the students in the class he leads. For instance,
if the quota is set to four and Joe schedules a class for eight students, an error message displays.
251
13 User Management
Quotas include:
Maximum number of accounts
Maximum number of concurrent servers
Maximum space allowed for snapshots (MB)
Maximum library space
For these settings, the parent organization is also affected by the settings of its child organizations. For
instance, if the Internal organizations number of accounts quota specifies 100 user accounts and its
child organizations uses 100 accounts, then no user accounts can be added to the Internal organization.
To increase quotas, a platform administrator must increase the quota for all parent organizations first.
For instance, if a parent organizations maximum space allowed is 100 TB and its suborganization needs
150 TB, to make more space available, the platform administrator must increase the parent
organizations quota and then increase the suborganizations quota.
To decrease quotas, a platform administrator must decrease the quota for all the child organizations first.
This only applies when a platform administrator is trying to decrease the quota to a value that is less
than the total sum of the child organizations. For instance, if a parent organizations maximum space
allowed is 100 TB and its suborganizations quota are 25 TB and 50 TB for two different child
organizations, then the platform administrator is allowed to decrease the parent organizations
maximum space allowed down to only 75 TB. If he wishes to decrease it lower than 75 TB, then the
platform administrator must decrease one or more of the child organizations quota first and then
decrease the parent organizations quota.
Quotas are imposed at the organization level. If your environment requires strict capacity limits,
creating multiple organizations rather than a single organization with several groups may be the best
solution.
Administrators and Organization Quotas

In the Cloud Automation Platform environment, the platform administrator can create, edit, and view
the quotas for all organizations. An organization administrator can view the quotas for the organization
to which he belongs but can only edit a limited set of the quotas. For instance, if an administrator is a
member of Training organization and creates the Self-Led child organization, he can edit all the quotas
for the Self-Led child organization but only a limited number of quotas for the Training organization.
252
13 User Management
For the following quota settings, the sum of the child organization limits cannot exceed the parents
organization limit:
13 User Management
The following table shows the privilege set and quota privileges that each administrator has.
Privilege Set
Parent
Organization
Child Organization
Platform administrator
Create, edit, view
Create, delete, edit, view
Suborganization
administrator
View
Delete, privileged edit for its

organization (can edit quotas)
Administrator
View
Create, unprivileged edit

(cannot edit quotas), view
Table 1 Administrator Privilege Sets and Quota Privileges
Note: Typically, the Organization Manager cannot edit all the quotas for the organization that he
manages. If the Organization Manager did not create the organization, he does not have the
suborganization administrator privilege set.
For more information about privilege sets, see Privilege Sets on page 239.
Personas
The persona that is assigned to a user account determines the users experience in the product interface;
the users persona regulates which options in the navigation pane (left pane) are displayed to the user,
which determines the content that a user can view.
For example, a user with the persona of Instructor will see very limited options in the navigation pane,
with no links or buttons to access such features as user management or system settings. A user with a
persona of Organization Administrator, however, will see all options. See Figure 4 and Figure 5.
Figure 4 Navigation Pane Displayed for Instructor Persona
253
13 User Management
Figure 5 Navigation Pane Displayed for Organization Administrator
The persona associated with a user account depends on the nature of the users duties and
responsibilities. For example, if a users job description includes scheduling online training sessions for
students, then the content requirements for that user are different from the content required by a student
in an instructor-led training lab.
To change an existing user's persona, you must edit the user account and assign the persona you want
that user to have to that account. The persona assigned to a user account determines the group to which
the user account is added by default, and the groups to which the user belongs determines what
privileges the user has on objects such as application configurations.
New user accounts are assigned a default persona, which is specified when you create a new
organization. You can change the default persona for the organization if necessary. The organization
settings determine a users persona and, therefore, the group membership.
Personas are defined by Cloud Automation Platform and cannot be created, modified, or deleted. The
available personas are driven by the Solutions that are installed.
254
13 User Management
Platform Persona
The following table lists the persona type for the CAP Core and CAP web interface
Persona
Related User or Group
Access and Capabilities
Organization
administrator
Platform administratora
or
Administrators group
Manages the platform including

organizations, quotas, resources,
platform settings, and system library
objects; also can access the application
if necessary.
Table 2 Persona Types
a. The platform administrator is a user account that has full privileges on every object
in the Cloud Automation Platform.
Solutions Personas
Assign the organization administrator persona to users who will serve as platform and system
administrators. If a user will spend the majority of time using one of the Solutions, assign a solution
persona to that user.
Demo Solution
The Demo Solution has the following personas:
SE Administrator: Manages the systems review templates and demo configurations; can also perform
the same tasks as a Sales Engineer.
Demo Library Manager: The primary role of the Demo Library Manager is to manage the library
objects that are used for building demos. The Library Manager is typically responsible for creating and
managing the images and configurations, but not creating or managing users. By default, the Demo
Library Manager persona is a member of the Administrators group
Sales Engineer: The Sales Engineer (SE) schedules and starts demos, writes reviews, creates links to
related material, and invites people to participate in online product evaluations.By default, the Sales
Engineer persona is a member of the Restricted Users group.
Evaluation User: Individuals whom the Sales Engineer has invited to an online product evaluation.
When an evaluation user logs on, he has access only to the demos that have been specified by the SE.
Self-guided evaluation users have their own account and can schedule demos at their convenience. By
default, the Evaluation User persona is a member of the Restricted Users group.
Restricted Evaluation User: Users who have access to a single demo but cannot schedule reservations.
Restricted evaluation users can only start demos manually.
255
SE
Administrator
Demo Library
Manager
Sales
Engineer
Create new
sessions (start
immediately or
schedule)
Evaluation
User
Restricted
Eval
User
(Can start
immediately; cannot
schedule.)
Stop and delete

sessions
View all active
hosts and their
status
Create and
manage library
objects such as
application and
server
configurations,
images,
hardware
profiles, and
deployment
action files.
Create and
manage users,
groups, and
organizations
(Creates
Eval
Users)
Approve or
deny
reservation
requests for
non-Self
Service users
View detailed
information
about pools and
resource
utilization for
each
View library
capacity and
snapshot
capacity
Table 3 Demo Solution Persona Types
256
13 User Management
The following table lists the persona types for Demo Solution.
Demo Library
Manager
Sales
Engineer
Evaluation
User
13 User Management
SE
Administrator
Restricted
Eval
User
Create and
manage review
templates
View
application
configuration
details
Create links to
related material
Run and
manage reports
Share sessions
with other users
Table 3 Demo Solution Persona Types (Continued)
257
The Training Solution has the following personas:

Training Administrator: Equivalent to an Organization Administrator. Manages the system as a
whole; creates and manages organizations, groups, and users. Creates and maintains the Cloud
Automation Platform environment, including resources, pools, review templates, images, server and
application configurations, and sessions. By default, the Training Administrator persona is a member
of the Administrators group.
Training Library Manager: The primary role of the Training Library Manager is to manage the library
objects that are used for building sessions and labs. The Library Manager is typically responsible for
creating and managing the images and configurations, but not creating or managing users. By default,
the Training Library Manager persona is a member of the Administrators group.
Registrar: The Registrar persona typically schedules labs, registers students for labs, creates and
manages users as needed, and runs reports. By default, the Registrar persona is a member of the
Administrators group.
Instructor: Schedules and starts labs, creates links to related material, and invites people to participate
in instructor-led labs. Instructors can read reviews written about the labs they instructed. By default, the
Instructor persona is a member of the Users group
Student User: Individuals whom the instructor or registrar has registered for an online course. When a
student logs on, he has access only to the labs that have been specified by the instructor. Self-paced
students have their own account and can schedule sessions at their convenience. By default, the Student
User persona is a member of the Restricted Users group.
The following table lists the persona types and which tasks each persona can accomplish.
Training
Administrator
Training
Library
Manager
Create new labs

and sessions (start
immediately or
schedule)
Registrar
Instructor
Student
User
Labs only
Labs only
Sessions
only
Only own
labs.
Only own
sessions
Cancel and delete

labs
View all active

hosts and their
status
Table 4 Training Solution Persona Types
258
13 User Management
Training Solution
Training
Library
Manager
Registrar
Instructor
13 User Management
Training
Administrator
Student
User
Create and
manage library
objects such as
application and
server
configurations,
images, hardware
profiles, and
deployment action
files.
Create and
manage users,
groups, and
organizations
Users only
Register new or
existing students
Approve or deny
reservation
requests for nonSelf Service users
View detailed
information about
pools and resource
utilization for each
View library
capacity and
snapshot capacity
Create and
manage review
templates
Create a review of
the class
Read a review of
the class
Create links to
related material
Run and manage
reports
Share sessions
with other users
Table 4 Training Solution Persona Types (Continued)
259
The QA/Test Solution has the following personas:

Test Administrator: Manages the systems test configurations; can create, schedule, and instantiate
personal test environments; also can create links to related items and invite others to access deployed
sessions.
Test Library Manager: The primary role of the Test Library Manager is to manage the library objects
that are used for building sessions. The Library Manager is typically responsible for creating and
managing the images and configurations, but not creating or managing users. By default, the Training
Library Manager persona is a member of the Administrators group.
Tester: Creates, schedules, and instantiates personal test environments; also can create links to related
items and invite others to access deployed sessions.
The following table lists the persona types for QA/Test Solution.
Test Administrator
Test Library
Manager
Tester
Create new
sessions (start
immediately, or
schedule)
Stop and delete
sessions
Cancel
Reservations
Create and manage
users, groups, and
organizations
View all active hosts
and their status
View application
configuration details
Duplicate
application
configuration
Approve or deny
reservation requests
for non-Self Service
users
Table 5 QA/Test Solution Persona Types
260
13 User Management
QA/Test Solution
Test Library
Manager
13 User Management
Test Administrator
Tester
Create and manage

library objects such
as application and
server
configurations,
images, hardware
profiles, and
deployment action
files.
View detailed
information about
pools and resource
utilization for each
View library capacity
and snapshot
capacity
Create links to
related material
Run and manage
reports
Share sessions with
other users
Table 5 QA/Test Solution Persona Types (Continued)
261
Authentication allows user access to the CAP web interface based on the verification of the users name
and password. Cloud Automation Platform supports two authentication methods:
Internal Account authentication is performed using account information from the Cloud
Automation Platform database.
LDAP Account authentication is performed using account information from your Lightweight
Directory Access Protocol (LDAP) server.
By default, Internal authentication is used. However, for each user account, an administrator can specify
which account authority to use.
If your company uses Internal authentication, user names and encrypted passwords are stored in the
Cloud Automation Platform database. When a user logs on to an application, the Cloud Automation
Platform user name and password must be entered for authentication.
If your company uses an LDAP server, you can link the server to the Cloud Automation Platform
environment. Using the CAP web interface, define the LDAP server, and then choose how existing
users should be authenticated. For a user who is already a member of an LDAP domain to have access
to Cloud Automation Platform, one of two options can be configured:
First create Cloud Automation Platform accounts An LDAP account authority is defined and
then a user account must be created in the CAP web interface. A user logging onto the CAP web
interface must use these Cloud Automation Platform credentials.This prevents random LDAP users
from accessing Cloud Automation Platform. For instance, if a user tries to access Demo Solution
but a corresponding user account has not been added by a Demo Solution administrator, the
authentication fails.
Auto-Registration An LDAP account authority is defined through Cloud Automation Platform,

but the CAP administrator does not need to manually create user accounts in Cloud Automation
Platform. Instead, when defining the LDAP server properties, select Allow Auto-Registration. In
this option, any member of the LDAP domain can log onto CAP web interface using his or her
LDAP credentials. After the users initial logon using the LDAP credentials a CAP account (name
only) is automatically created, using the LDAP password. This enables users to log on to CAP web
interface using the same user name and password that they use for other applications that use the
company's LDAP server. The Cloud Automation Platform environment uses the Cloud Automation
Platform user name and the LDAP search base location to validate user accounts.
Note: To create an LDAP account authority and corresponding LDAP configurations, click Security
(under System Settings) in the left pane of the CAP web interface, and then click Add LDAP
Server in the Account Authorities area. Refer to the online Help for detailed instructions.
If you want to enter specific user account credentials for querying the LDAP server for account
information, consult the LDAP documentation for your version and ensure that the LDAP
account (for example, Windows Domain account for Active Directory) that is used to access
the LDAP server from CAP has sufficient permissions to enable LDAP queries. To enter these
credentials in the CAP web interface, use the Advanced Properties area on the Authentication
Method detail page, either when first defining the LDAP server or when editing the details for
262
13 User Management
Authentication Methods
13 User Management
an LDAP server. If Basic or NTML is selected as the Search Authentication Type, the User
Name and Password fields appear under Distinguished Name Search Credentials.
263
13 User Management
264
14
This chapter explains how to monitor the Cloud Automation Platform environment. You can monitor
the environment using any of the following methods:
Information logs
Audit trail
System notifications
E-mail notifications
Syslog file
Engine Manager
Reports
For details about reports, see Chapter 15, Reports, on page 271.
Application monitoring enables administrators to detect and resolve potential problems before
application users encounter them. Using application monitoring, administrators can determine the
performance level of an application, determine if a problem is application or equipment-related, and
proactively correct potential problems before they become critical.
Cloud Automation Platform uses a logging framework. Messages and events that are logged by the
components in Cloud Automation Platform (such as the web application, or user interface) are sent to
the framework. The messages are filtered based on the logging level that is specified on the system
Settings page of the CAP web interface. Based upon the logging configuration settings, the framework
then determines how the log message should be disseminated. For example, the log message could be
sent to the appropriate Cloud Automation Platform log file, via email to a specified recipient, to a
SYSLOG file, or broadcast as an SNMP event. By default, log files are always enabled and receive all
log messages (subject to the logging level filter).
Monitoring Log Files

Using Cloud Automation Platform logs, a user can retrieve text for any given exception. Log entries
include any automation errors or script exceptions. When a log file reaches the system-specified size
limit, it is archived in the same directory.
Internal exceptions are parsed into error messages. To see more detail about error messages that occur
in applications, review the UI log.
265
System Monitoring
Administrators can use the CAP web interface to review and edit the log configuration values.
To view and modify the log levels (Trace, Debug, etc.) for each endpoint, perform the following steps:
1. In the left pane, click System Settings.
On the right pane, the details of the Cloud Automation Platform system settings appear.
2. In the Endpoint Log Levels area, you can view and change the log level for each defined
endpoint.
By default, the following logs are located on the CAP Core server in c:\Program Files\Quest
Software\CAP\Platform\Logs:
ControlService.log - Monitors communication over the message bus. Review this log when
encountering installation problems or communications problems between Cloud Automation

Platform components.
URA.log - This log file is created each time that the User Readiness Test (URT) is run as well as
when a browser connection failure occurs.
RemoteServerManagement.log - Review this log to monitor communication about the Quest
CAP Agent that manages remote hosts.
SurgientAPI.log - Review this log to monitor information about the CAP SOAP API.
Messaging.log - Review this log to monitor communications between the Agent Message
Forwarder and the VM host server, system library, and file cache locations.
Scripting.log - Review this log to monitor deployment automation. Messages are sent to this
file with a tag identifying the script that generated the message.
ServiceHost.log - Review this log to monitor resource deployments and reporting
information. Audit trail information (modifications such as changes to passwords, user accounts,
object privileges) are written to this log if the ServiceHost endpoint log level is set to Debug.
UI.log - Review this log to monitor the CAP web interface and the Cloud Automation Platform
Solutions.
Surgient.Platform.Persistence.log - Review this log to monitor the status of
transactions on the CAP Core.
Surgient.Platform.log - Review this log to monitor the status of CAP Core services.
DBInstall.log -- this log contains the output produced during the database creation, useful if the
install encounters an error creating the database.
InstallLog.txt -- contains the configuration and set-up values that were defined during the
product installation.
name_of_vm_guestagentlog.txt -- Each VM also has a guest agent log located within each
VM directory.
266
Viewing Log Files
SocketGateway.log -- If the URA Gateway installed, this log file is found on the Gateway host
in \Quest Software\CAP\Platform\Logs\.
Note: If you do not have access to the physical server locations, consider configuring system
messaging options to send e-mail notification to your account whenever errors occur.
Viewing Audit Log Information

In environments where multiple departments use Cloud Automation Platform to manage and deploy
sessions, audit information is often important. The Audit logging capability maintains a record of all
changes to users, permissions, and resource access. Changes to sessions and snapshots are also logged.
This information can be used to provide a clear picture of the fundamentals of auditing: who did what,
and when, in the system.The act of turning Audit logging on or off also triggers a log entry.
Audit information is written to the Cloud Automation Platform Reporting database. Custom reports can
be created to capture the audit information. See the Data Dictionary for details about custom reports.
The Audit data is also written to the ServiceHost.log file if the ServiceHost endpoint log level is set
to Debug.
Note: Quest Software recommends that the Audit logging is turned off after (set the
Auditing.Enabled configuration to False) immediately after installation and turned back
on once the system has been initially configured (all new users created, permissions set, etc.).
Upgrades to newer versions of the product could also cause a significant amount of audit log
activity, so consider turning off audit logging during the upgrade.
User actions that trigger Audit logging are captured whether the event is initiated in the CAP web
interface or through using the vcsadmin utility.
System Notifications
System events are communicated to users through notifications displayed at the top of each CAP web
interface page, beside the email icon. The exact notifications that appear are filtered based on the user
who is logged on to the CAP web interface. For example, an administrator sees messages about
deployment failures, pooling events, when a host is registered, and other platform events. A user with
fewer privileges would be notified of events specific to sessions or objects that the user owns or shares.
Monitoring Components Using E-mail

You can set up the CAP web interface to send e-mail to an account whenever a message is logged. You
can also specify what level of message triggers an e-mail delivery.
Use the CAP web interface to specify the e-mail error logging level. In the left pane, click System
Messaging. On the System Settings page, in the Notification Details area, click Edit. You can modify
the email addresses as needed. For more information, refer to the CAP web interface online help.
267
The CAP Core can be configured to send selected SNMP events to an SNMP server, which can then
display the events in an SNMP console or otherwise broadcast them. Use the System Settings page of
the CAP web interface to set threshold values for events such as number of pooled IP Addresses,
percentage of used RAM, percentage of used VMs, database connections, and several other thresholds.
To configure the Cloud Automation Platform environment to send SNMP events, enter the IP Address
of the SNMP server in the System Settings page, provide the port number, the SNMP version, the
SNMP community, and the event level (Warning) at which events should be broadcast. Finally, enter
the threshold values. If a threshold is reached, the SNMP event is broadcast. If viewed in the SNMP
Console, a message will state which exact threshold has been exceeded, by how much, and what the
current level is, or that a current value is less than the set threshold, and the value of the defined
threshold.
For detailed instructions about configuring SNMP event broadcasting, refer to the online Help.
Note: Quest Software recommends that, when specifying the Event Broadcasting properties in the
CAP web interface, you select the default Event Level of Warning. If the Event Level is set
to Critical or Severe, the thresholds that you supplied values for on the Event Broadcasting
Properties page will not be broadcast to the SNMP Console, as they are not consider to be of
critical or severe nature.
Monitoring Components Using Syslog

Syslog enables you to monitor all the Cloud Automation Platform log files using one syslog file.
In addition to the platform logging handlers, a syslog handler for processing logging records is
available. By default, CAP Core components send syslog messages and the syslog handler collects all
the platform log information in a single log file. However, a syslog server and daemon must be in place
in order to use the syslog functionality.
For effective monitoring within the hosted environment, use the events recorded in the syslog file.
Syslog is a standard UNIX facility for event logging derived from sendmails original logging system.
Syslog messages are sent connectionless over a UDP transport on port 514.
The syslog file uses error levels to distinguish the type of event recorded. Errors from all Cloud
Automation Platform components are recorded in the syslog file including errors from the database,
CAP Core server, Quest CAP Agent, user interface, universal remote access (URA) gateway, and
automation or scripting events.
The syslog server type determines the syslog file location. The log file is located in c:\Program
Files\Syslogd\Logs.
Syslog is a standard component of Linux distributions. On Linux, the syslog file writes to /var/log.
After you set up the syslog server daemon, use the CAP web interface to specify the error logging level.
In the left pane, click System Messaging. In the Endpoint Log Levels area, specify the settings. You
268
can also change the syslog port, text format, or the syslog server IP address. For details about
configuring syslog, see Syslog Settings on page 277.
Monitoring Scripts
The Script Monitor enables you to monitor the progress of background tasks that are running in the
script engine.
Any actions that are performed by a script can be monitored from the Script Monitor in the CAP web
interface. The following are a few examples of script-based tasks:
Deploying application configurations
Provisioning VMs
Deleting VMs
To manage background tasks using the Script Monitor open the CAP web interface, and then click
Script Monitor in the left pane.
269
270
15
Using the CAP web interface, you can create, modify, duplicate, or view reports. You can also change
group access permissions for individual reports. For details on how to perform these procedures, refer
to the CAP web interface online help.
Reports can be run from the CAP web interface. In addition to standard reports, the CAP web interface
enables the user to edit or define custom reports. Report results can be exported to Microsoft Excel and
Adobe Acrobat PDF formats.
The Cloud Automation Platform reporting database acts as a data warehouse for saving historical data.
The reporting database is logically distinct from the Cloud Automation Platform operations database.
The reporting database can be located on a physically separate server from the operations database or
as an independent database on the same server as the operations database.
Additionally, Cloud Automation Platform supports third-party report integration. Third-party reporting
tools can point to the reporting database for custom report creation.
271
15 Reports
Reports
The following default report types are provided by Cloud Automation Platform.
Account Creation History Displays the user accounts created during the time period specified
when the report is run. Results include account name, account ID, full name, persona, enabled
status, expiration date, creation date, account that created this account, e-mail address, title, address,
telephone number, time zone, and organization.
Account Usage Stats Displays individual user account usage information for users who were
logged in during the time period specified when the report is run. Results include account name, email address, number of logins, and average time logged on.
Application Configuration Activity Summarizes individual user account usage of application

configurations that were available to the user during the time period specified when the report is
run. Summary results include application configuration name, average session duration, and
average remote access duration.
Application Configuration Use Displays the number of times that an application

configuration was available during the time period specified when the report is run.
Application Deployment History Displays the frequency and duration of the application
configurations that were available during the time period specified when the report is run. Results
include organization name, application configuration name, date deployed, number of reservations
fulfilled, and average, minimum, and maximum duration for each application configuration.
Chargeback Shows the asset usage based on either application configurations or user accounts.
The summary report displays the total VM, RAM and EPU hours consumed by a user account,
grouped by organization.
The detail report displays the use of assets based on each application configuration, grouped by
organization and user, including the number of times the configuration was deployed, the total time
in hours that the configuration was deployed, and the average RAM, EPU, and software license
usage per deployment of the application configuration.Failed deployments are not included in
report data.
For both the summary and detail reports, the results are derived from the application configurations
that were available during the during the time period specified when the report is run. In addition,
the reports include data only for days within the report date range that are in the past.
272
Deployment Action Results Displays the results of deployment actions that were started during
the time period specified when the report is run.
High Availability Host Events Displays alarms and forced failures for any hosts that are assigned
to a High Availability resource pool.
High Availability VM Events Displays recovery events for VMs on High Availability hosts.
Image File Use Displays the image files used by application configurations that were available
during the time period specified when the report is run. Results include the frequency that each
image file is used.
15 Reports
Report Types
15 Reports
Licensed Software Usage Shows the licensed software usage by a daily, weekly, or monthly
period. Cloud Automation Platform's Licensed Software feature enables administrators to track
licensing requirements for third-party software installed in the Cloud Automation Platform
environment.
Peak EPU Utilization The Peak EPU Utilization reports are bar-chart reports that depict the peak
utilization level of EPUs as compared to the total available EPUs within a time period over a date
range. The Hourly graph also displays a line-graph of a Calculated Series (Average) based on the
EPU usage series. The report data can be filtered by date range, pool, and organization. There are
three reports in total for this group, based on different aggregate ranges: Hourly, Daily, and Monthly.
Peak RAM Utilization The Peak RAM Utilization reports are bar-chart reports that depict the peak
utilization level of RAM as compared to the total available RAM within a time period over a date
RAM usage series. The report data can be filtered by date range, pool, and organization. There are
Peak VM Utilization The Peak VM Utilization reports are bar-chart reports that depict the peak
utilization level of VMs as compared to the total available VMs within a time period over a date
VM usage series. The report data can be filtered by date range, pool, and organization. There are
Platform Maintenance Windows Displays info about maintenance windows that were open during
the time period specified when the report is run.
Platform Maintenance Windows (Pause Mode) Displays info about maintenance windows that
were open, and had Pause Mode applied, during the time period specified when the report is run.
Quota Utilization History Compares utilization levels with assigned quota levels per hour, day,
week, or month. To prevent monopolization, each organization has a set of limits, or quotas, on
capacity. Quotas restrict an organizations peak usage for reservations, snapshots, user accounts,
reserved resources, and published application configurations.
Reservation Fulfillment Summary Displays the number of attempted and successful reservations.
Results include organization name, total number of failures, total number of successful reservations,
and the percentage of successful reservations for reservations that were scheduled to become
available within the time period specified when the report is run.
Reservation Requests Displays information about reservation requests submitted during the time
period specified when the report is run, including the user account making the request, date of
request, user account approving or denying the request, and whether request was approved or
denied.
Resource Capacity Utilization The Resource Capacity Utilization reports are line-graph reports
that depict the utilization levels of each type of resource. The report data can be filtered by date
range, pool, and organization. There are three reports in total for this group, based on different
aggregate ranges: Hourly, Daily, and Monthly.
Review Report Displays customer reviews that were submitted during the time period specified
when the report is run. Results include the user who submitted the review, the instructor, and the
application configuration and session that were reviewed.
273
Training Deployments By Student Displays all scheduled labs for each student that became
available during the time period specified when the report is run. Results include the student name,
organization, application configuration, deployment start and end dates, and deployment duration.
Training Instructor Schedule Displays all scheduled labs, per instructor, that became available
during the time period specified when the report is run. Results include the lab name, lab status,
course name, instructor, class size, number of confirmed students, and start date.
Training Master Schedule Displays all scheduled labs that became available during the time
period specified when the report is run. Results include lab name, lab status, course name,
instructor, class size, number of confirmed students, and start date.
User Activity Shows details of user account access to application configurations that were
available during the time period specified when the report is run. Detailed results include
organization, user name, session duration, remote duration, application configuration name,
deployment group ID, server IP address, remote access type (RDP, VNC, Citrix), session start and
stop time, remote access start and stop time, client address, and remote access port.
User Deployments Summarizes each application configuration that was available during the time
period specified when the report is run, per user. Results include account name, organization,
application configuration, deployment duration, and deployment start and end date.
Managing Reports
Administrators can manage reports using the CAP web interface. Reports use data supplied by the
reporting database, which houses historical data. For more information, see Reporting Database on
page 6.
Reports are a named platform object compromised of a user-defined view type and a SQL SELECT
statement that retrieves data for the report from the reporting database. A report also has optional filters
that can be applied to the report when it is run: Date Range, Organization, Pool, Localized Date Group,
and Instructor. Optionally, the report might also contain Report Definition Language (RDL) XML with
rules for the structure and presentation of the report.
When editing a report, you can edit the report name, description, SQL query, view type, report filters,
or RDL. You can also upload an RDL file rather than editing the RDL in the CAP web interface.
Customizing Reports
Report Definition Language (RDL) XML enables administrators to control the report layout with a high
degree of flexibility. If the RDL for a report is customized, the customization persists along with its SQL
query.
Using RDL leverages the full capabilities of the Report Viewer including charting and so on. Also, RDL
enables the use of third-party report designers such as Visual Studio .NET 2008 and Report Builder 1.0
and 2.0.
274
15 Reports
You can set access permissions on individual reports from the Reports pane in the CAP web interface.
Select the report and then click Change Permissions to specify which groups have access to the report.
Optionally, you can also change a groups privilege set on the report. For more information about access
control, see Access Control on page 237.
275
15 Reports
Setting Access for Individual Reports
15 Reports
276
Syslog enables you to monitor all the Cloud Automation Platform log files using one syslog file.
This appendix details the configuration settings for using syslog in the Cloud Automation Platform
environment. This appendix also explains how to use filters and scripts with syslog.
Note: By default, CAP Core components send syslog messages and the syslog handler collects all the
platform log information in a single log file. However, a syslog server and daemon must be in
place in order to use the syslog functionality.
Syslog Handler Settings

You can change the syslog handler settings to meet the needs of your environment. For instance, you
might want to change the IP address of the syslog server. The syslog settings and default values are
included in Table 1 on page 277.
The syslog protocol limits the total length of the UDP datagram containing a syslog message to 1024
bytes. Any message longer than 1024 bytes is truncated. However, Kiwis syslog allows messages up
to 4Kb (4096 bytes) to be received. You can change the syslog handler
syslogNonStandardMaxLength setting to increase the maximum length if you are using Kiwis
implementation of syslog.
Syslog requirements are listed in RFC 3164 - The BSD Syslog Protocol available at http://
www.faqs.org/rfcs/rfc3164.html.
To set syslog configuration values, use the Advanced Configuration settings in the CAP web interface.
To set:
Change this value:
Default setting:
Formatter used for

Syslog messages
Logger.Logging.Syslog
Handler.formatter
Logging.TextFo
rmatter
Logging level for

Syslog logging
Handler.level
Severe
Syslog
MessageTag to this
value, e.g.
Customer name
Handler.syslogCustom
MessageTag
none
Table 1 Syslog Configuration Settings
277
16 Syslog Settings
16
Syslog Settings
Change this value:
Default setting:
Syslog Facility ID
for messages
Handler.syslogFacility
ID
1 (user-level
messages)
A numeric IP
address instead of
a host name
Handler.syslogForce
NumericIP
false
Message length
that possibly
exceeds the RFC
3164 limit
Logger.Logging.SyslogH
andler.syslogNonStanda
rdMaxLength
1024
UDP port of the

Syslog Server
Handler.syslogPort
514
IP address of the
Syslog Server
Logger.Logging.SyslogH
andler.syslogServer
none
Table 1 Syslog Configuration Settings
Syslog Facilities
In lieu of a structured source name, syslog defines an enumeration for specific sources called facilities.
User is the default facility for Cloud Automation Platform logging.
You can configure the facility used by each Cloud Automation Platform component. You can assign the
local use facilities or the user-level facility to processes and daemons that have not been explicitly
assigned a facility. The following table shows the default facilities for the Cloud Automation Platform
environment.
Numerical
Code
Facility
kernel messages
user-level messages
mail system
system daemons
security/authorization messages
messages generated internally by syslogd
line printer subsystem
network news subsystem
UUCP subsystem
Table 2 Facilities for the Cloud Automation Platform Environment
278
16 Syslog Settings
To set:
Facility
clock daemon
10
security/authorization messages
11
FTP daemon
12
NTP subsystem
13
log audit
14
log alert
15
clock daemon
16
local use 0 (local0) CAP Core server
17
local use 1 (local1) Agent Message

Forwarder
18
local use 2 (local2) CAP Web Application
19
local use 3 (local3) Database
20
local use 4 (local4) Quest CAP Agent
21
local use 5 (local5) CAP Domain API
22
local use 6 (local6)
23
local use 7 (local7)
16 Syslog Settings
Numerical
Code
Table 2 Facilities for the Cloud Automation Platform Environment
For more information about facilities, refer to RFC 3164 - The BSD Syslog Protocol at http://
www.faqs.org/rfcs/rfc3164.html.
Severity Levels
Syslog defines a set of severity levels for errors while Cloud Automation Platform defines logging
levels.
279
Logging
Level
Syslog
Severity
n/a
Emergency
This level is not used by

CAP logging
n/a
Alert
This level is not used by

CAP logging
Critical
Critical
Severe
Error
Warning
Warning
Config
Notice
Info
Informational
Comm
Debug
Debug
Debug
Trace
Debug
Additional Notes
Table 3 Logging Level Translation to Syslog Severity Errors
280
16 Syslog Settings
The mapping translation for Cloud Automation Platform in common logging is static and nonconfigurable. The following mapping illustrates how the CAP Core translates errors to syslogs severity
levels.
You can configure syslog servers to send alerts for specific message types and to write messages to the
logging database. Use filters and scripts to accomplish these tasks. Filters designate the messages that
come from a specific deployment and the type of messages for which to send alerts. Scripts instruct the
system how to respond to messages that match your filter criteria. For example, you might write a filter
to find all CompanyX messages with an emergency severity level. Then, when any CompanyX
emergency messages are written to the logging database, you might execute a script to automatically
e-mail Quest Support to address the problem immediately.
Each deployment requires a minimum of two filters, one for logging events to the database and one for
alerting support. You can create filters based on:
Timestamp Base the filter on the time of day.
A specific deployment Use one of the following methods:
Host name Base the filter on the hostname of the source. The hostname is obtained either from
the host providing the name or it is resolved by reverse DNS or host table lookup.
Source IP Base the filter on the source IP of the system.
Flags and counters Base the filter on the system or alerting thresholds being exceeded. (This is not
effective in clustered syslog deployments. Use database methods in clustered syslog deployments.)
281
16 Syslog Settings
Setting Up Filters and Scripts
16 Syslog Settings
282
Index
A
access control
automatic 242
changing 242
for catalogs 223
manual 242
objects 238
overview 238
relationship to organizations 247
ActiveX
disabled, using VNC to access remote desktops 42
additional considerations 18
administrator
privilege set 240
administrators group 241
advanced mode
NAIL Server 23
agent
guest 197
agent message
forwarder 51, 59, 62, 64, 153
processor 153
agent message forwarder 3
agent message processor 3
agents 63
application configurations
concurrent 251
deploying 228
overview 222
quotas 251
setting boot order 222
application servers 4
applications
overview 4
attach media 236
Audit logging 267
Audit trail information
ServiceHost.log 266
authentication methods 262
automatic access 242
Auto-Registration 262
283
B
base images 191
boot order, setting 222
C
caches 5, 19, 157
canceling reservations 235
CAP
components 3
components, installing 42
CAP Core server 3
CAP web interface 4
logging on 71
catalogs
access control 223
overview 223
CD-ROM, mounting 236
child organizations 246, 247
Citrix 74, 7678, 79, 113, 125, 126, 221, 236
remote access 84, 120, 127
classroom readiness test. See CRT
cloning images 193
cloning network settings 221
component services 43
components 3
conducting the CRT 121
conducting the Web Browser and Connectivity Test 119
Configuration Settings
enabling editing of 178
configuration settings
viewing all 39
Console 236
console, remote access 221
copying images 193
core services 3, 43
creating virtual machines 215
CRT
application 81, 115
client 81, 116
installing 80, 90, 113
Load Test server 81, 90
server 113, 115
typical workflow 81
custom reports 271
D
Dashboard
284
navigating 167
overview 166
searching 167
sorting 167
databases 46
operations 4
reporting 4
dedicated file cache locations 19
default groups 241
default network connection 214
default organization 246
deploying resources
scheduling 227
deploying sessions
overview 227
determining scope of installation 10
DHCP Network
Range 23
DHCP Networks
VLAN-isolated 141
differencing disks
See undo files
Disabling remote access via the console 108
disks, creating 194
Distributed Resource Scheduler (DRS) . See DRS
DPM (Distributed Power Management)
configuring for CAP 174
DRS (Distributed Resource Scheduler) 166, 168, 174
duplicating images 193
DVD, mounting 236
DVS (Distributed Virtual Switch)
creating required networks 174
creating required networks for NAIL Server in advanced mode 139
Dynamic/OSPF 142
E
e-mail error messages 267
e-mail settings 49
empty disks, creating 194
enable editing
advanced configuration settings 178
Enabling remote access via the console 108
EPU (Effective Processor Units)
pooling 214
error messages 267
EULA 44, 51, 55, 59
extending reservations 235
285
F
file caches 5, 19, 157
workflow 228
Firefox
using VNC for remote access 42
firewalls 18, 74, 76, 78, 79, 81, 91, 102, 122
forwarders. See agent message forwarder
G
gateway 210
groups
changing privileges 242
creating 242, 250
default 241, 250
definition 238
naming conventions 241
overview 241, 242
relationship to organizations 246, 250
guest agent 197
H
hardware profiles
changing 162
overview 220
host servers 5
agent requirements 214
assigning to a pool 214
scheduling maintenance for 162
hosts
Hyper-V, configuring 28
using remotely managed hosts 26
HP Network Automation 143
HP Quality Center 178
HTTP 74, 77, 79, 101, 102, 125, 126
HTTPS
enabling 11, 188
Hyper-V 190
CIFS, constrained delegation 28
I
IDE drives 221
IIS (Internet Information Services)
version 7, configuring 25
image provisioning 19
images
creating 194
definition 190, 218
diversity 10
286
duplicating 193
image preparation for Hyper-V hosts 31
provisioning 228
recover missing files 164
saving 191, 223
types 191
using 191
using in multiple contexts 191
installation 18
product installation 42
scenario 11
installing
Agent Services 51
agents 63
CAP components 42
CAP Core components 43
Core Services 43
CRT 80
CRT application 115
CRT client 116
CRT Load Test server 90
CRT server 113
preparations 9, 10, 82
Quest CAP Agent 63
SOAP API 59
URA Gateway server 94
URA terminal client 102
Web Application and Solutions 55
internal organization 246
IP addresses 53, 100
duplicate 193
setting 210, 221
ISO files
mounting 193, 236
isolated network
DHCP 141
L
LDAP 262
libraries 4
library
resynchronize files and images 164
library location
moving 152
SAN 155
limiting capacity 250
limiting virtual machine creation 214
287
LLP 74, 76, 78, 94

local listening proxy. See LLP.
log files
ServiceHost.log 266
logging
Audit information 267
logging on
CAP web interface 71
M
MAC addresses
masquerading 148
setting 209
machine names 20
maintenance
maintenance mode 163
maintenance windows 163
performing on hosts 162
upgrade window 164
maintenance mode
Pause Mode 163
managing
virtualization hosts 161
manual access 242
masquerading 148
missing items 164
mount point 221
mounting drives 236
mounting ISO images 193
N
NAIL Driver 209
NAIL Driver network range 209
NAIL Server
Advanced mode 142
advanced mode 23
advanced mode, physical cabling 139
description 21
duplicating image files 193
using with Hyper-V Hosts 31
network connection 214
network resources
changing 161
cloning 221
configuring 221
network switch automation 17, 143
NFS support
288
set permissions 158

NIC 214
notifications
reservation expiration 227
O
operations database 4, 46
organization administrator 247, 253
organizations
definition 246
home 249
inheritance 250
overview 246
privilege set changes 248
quotas 250
relationship to access control 247
relationship with groups 250
sharing resource pools 208
OSPF (Open Shortest Path First) protocol 23, 142
overlay images
See undo files
P
passwords 49, 57, 115
pause mode 163
planning
additional considerations 18
installations 9, 10
planning installations 82
Platform
e-mail settings 49
platform administrator
privilege set 239
setting quotas 247
platform administrators 49, 57
pool See resource pools
ports 24, 79, 102, 113
privilege sets
changing 242
copying 240
definition 238
overview 239
privileges
definition 238
inheriting 250
overview 239
processors. See agent message processors
289
promoting snapshots 193

provisioning 19
provisioning images 228
Q
QA/Test Solution 4
Quest CAP agent
using with host servers 214
quotas
editing 247
overview 250
setting 247
R
RAM
changing 162, 236
RDP 74, 76, 78, 112, 113, 124126, 221, 236
recovery of missing items 164
redo files 191
remote access
Citrix 84, 120, 127
solutions 18
remote access methods 221
remote access solutions 82
remote desktop protocol. See RDP.
remote desktop session, starting 236
Remote Server Manager 29
configuring hosts for 26
migrating installation of 153
Report Definition Language (RDL) 274
reporting 10
reporting database 4, 47
database
reporting 271
reports
customizing 274
managing 274
overview 271
types 272
reservations
approval required 250
canceling 235
deploying 227
expiration notification 227
extending 235
overview 226
quotas 251
290
restricting 208
resuming 235
stopping 235
suspending 235
resource pools
allocating usage 208
assigning host servers 214
host server requirements 214
overview 208
resources
fulfillment 227
recover missing resources 164
scheduling maintenance for 162
restart command 236
restricted
privilege set 240
users group 241
resynchronize, library files and images 164
reviews, ownership 243
rollback command 235
run command 236
S
SAN
configuring ESX servers 156
library location 155
saving snapshots 223
scheduling
quotas 251
resource maintenance 162
resources 227
scripts
syslog 281
SCSI drives 221
Search
Dashboard 167
security
catalog-level 223
overview 238
security identifiers 21
Self-Service privilege
creating a user without 250
server configurations
boot order 222
network settings 148
overview 220
Service
291
deploying as a Service 228

services
Core Services overview 3
installing Core Services 43
session images 191, 223
sessions
deploying 227
setting permission on NFS servers 158
shared file cache locations 19
snapshots
directory 210
maximum number of 251
maximum size 251
overview 191, 223
ownership 243
promoting 193
quotas 251
saving 235
settings for 191
SOAP API 4, 59
socket proxy 126
restarting 109
starting 109
stopping 109
solutions
overview 4
remote access 18
Static IP addresses 21
Static/Switch 142
stop all command 235
subnetworks 100
suborganization administrator
privilege set 240
suborganizations 246, 247
suspending reservations 235
Swapfile Location 174
syslog
filters and scripts 281
overview 268
system
library 4, 157
system library
overview 218
relationship to file cache 228
T
templates directory 210
292
terminal client. See URA terminal client.

tests 18
CRT 121
Web Browser and Connectivity 119
U
undo files 191, 223
universal remote access. See URA
URA 18, 74, 76, 80, 124
URA gateway 57
URA Gateway Server
Defining IP or Hostname 106
URA Gateway server 73, 74, 76, 7879, 81, 105, 106, 113, 124126
installing 94
requirements 82, 90
URA terminal client 74, 77, 102, 108
installing 102
URA Tunnel Configurations
establishing sequence 107
URT 18
user accounts
creating 243, 249
definition 238
limiting number of 251
managing 245
organization membership 246
user experience 246
user privilege set 240
users group 241
utility host 31
creating 31
utility hosts
resource allocation to pools 214
V
vhd files 190
virtual hard disks 190, 218
virtual machines
creating 214, 215
managing 215
using 215
virtual network computing
See VNC.
virtualization host 214
virtualization hosts
modifying 161
VLAN-isolated DHCP Networks
293
configuring 141
VMFS 155
VNC 74, 7678, 79, 113, 221, 236
W
Web application component 4
Web Browser and Connectivity Test 80, 82, 100, 111, 112, 113, 120, 123
294

Install Admin

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Install Admin

Uploaded by

Copyright:

Available Formats

2010 Quest Software, Inc.

ALL RIGHTS RESERVED.

2 Before You Start

9 Physical and Network Resources

Installation and Administration Guide

File Caches and File Cache Locations

10 System Library Objects

11 Deploying and Managing Sessions

Monitoring Log Files

Installation and Administration Guide

Installation and Administration Guide

About This Book

Chapter 1, Introduction, on page 1

Chapter 2, Before You Start, on page 9

Chapter 3, Product Installation, on page 41

Chapter 4, Remote Access, on page 73

Chapter 5, Advanced Networking, on page 129

Chapter 6, Configuration and Administration, on page 151

Chapter 7, Troubleshooting, on page 181

Chapter 8, Image Management, on page 189

Installation and Administration Guide

Chapter 9, Physical and Network Resources, on page 207

Chapter 10, System Library Objects, on page 217

Chapter 11, Deploying and Managing Sessions, on page 225

Chapter 12, Access Control, on page 237

Chapter 13, User Management, on page 245

Chapter 14, System Monitoring, on page 265

Chapter 15, Reports, on page 271

Appendix 16, Syslog Settings, on page 277

Quest Cloud Automation Platform Release Notes

Quest Cloud Automation Platform Installation and Administration Guide

Quest Cloud Automation Platform Data Dictionary

Quest Cloud Automation Platform Upgrade Documentation

Quest CAP Add-In for HP Quality Center Guide

SOAP API .chm files

Installation and Administration Guide

Window and dialog names

Title caps, default font

File or directory names

Examples, including code

UI commands within a procedure when a

Typed user input

Acronyms and Abbreviations

Application Programming Interface

Cloud Automation Platform

Compact Disc Read Only Memory

Central Processing Unit

Domain Name System

Effective Processor Units

Graphical User Interface

Globally Unique Identifier

Host Bus Adapter

Hypertext Transfer Protocol

Independent Computing Architecture

Internet Control Message Protocol

Integrated Drive Electronics

Installation and Administration Guide

Internet Information Service

Local Listening Proxy

Media Access Control

Microsoft Data Access Components

Network Abstraction and Isolation Layer

Network Address Translation

Network File System