WO2010039993A2 - Automation for virtualized it environments - Google Patents

Abstract

A system automatically builds custom virtual appliances and/or other computing environments and their components, where applicable, based on user requirements and may offer a service for hosting, maintaining, monitoring and managing such appliances remotely. These virtual appliances may be delivered over a network, such as the Internet, and can be run at a customer site or at a hosting provider. Some embodiments of the invention can build these appliances using custom applications developed by customers.

Description

AUTOMATION FOR VIRTUALIZED IT ENVIRONMENTS

Detailed Description

[0001] Usage Scenario according to an embodiment

[0002] The figure below shows the life cycle of the image files from initial conception through modification in production and the virtual test lab according to an embodiment. The numbered links describe the life cycle sequence, as follows:

[0003] 1. The user defines the requirements for the virtual machine image and enters them into the Doyenz VM Generator.

[0004] 2. The Doyenz VM Generator uses the requirements to create the Virtual Machine according to those requirements.

[0005] 3. The Doyenz VM Generator installs both the Doyenz Guest Agent and the Shadow Protect Server Agent into the Virtual Machine.

[0006] 4. When VM configuration is completed, the Doyenz VM Generator tells the Doyenz Guest Agent to make a final full backup of the machine. To do this, the Guest Agent takes the following actions according to an embodiment:

[0007] a. Logs any users out of the system

[0008] b. Shuts down all applications

[0009] c. Shuts down all non-essential services (MSSQL, Exchange, etc.)

[0010] d. Shut down all essential services that are not needed for the full backup (essentially only disk and network services are needed).

[0011] e. Instruct ShadowProtect to make a full backup of the machine (all volumes) [0012] f. Instruct ShadowProtect to make a duplicate of the full backup on the Doyenz storage server

[0013] 5. The full backup that ShadowProtect creates is stored in the Doyenz Storage Server as a .SPF file.

[0014] 6. At deployment time, the .SPF file is moved to the client's location (USB drive, download, direct send) and given to the Doyenz Host Agent running there.

[0015] 7. The Host Agent, previously configured, knows where the local ShadowProtect backup destination is (NAS, SMB, eSATA) and copies or directs the .SPF file to that location.

[0016] 8. The Host Agent then initiates a full restore of the virtual machine from the .SPF file directly into the VM image and boots it.

[0017] 9. As the Virtual Machine is used, ShadowProtect will create incremental backups that record the changes made since the previous full or incremental backup. These are stored as .SPI files on the ShadowProtect backup destination. The .SPI files are much smaller than the .SPF files (Mbytes vs GBytes).

[0018] 10. Each night, the Doyenz Host Agent arranges for the daily incremental file ( SPI) to be moved to the Doyenz Storage Service. The daily incremental file is automatically created by ShadowProtect in the regular course of its processing.

[0019] 11. When the user wants to view the VM image in the Virtual Test Lab, the latest daily incremental (.SPI file) is read by the Storage Craft Recovery Environment .

[0020] 12. The Storage Craft Recovery Environment reconstructs the VM disk images based on the SPI and SPF files being restored.

[0021] 13. The user uses the virtual machine running in the Virtual Test Lab, presumably making changes to the image. Changes may be made manually or through automation. [0022] 14. Any changes made by the user would be captured in a new .SPI file using a process similar or identical to that described in step #4, above.

[0023] 15. The .SPI file resulting from the user's lab changes is transmitted to the client's backup destination. Because this .SPI file is made on a version branch, there is no conflict with any existing .SPI file on the backup destination.

[0024] 16. If desired, the changes could be booted as the new image by restoring it back into the virtual machine using the Storage Craft Recovery Environment locally.

[0026] 3 Design

[0027] The Disaster Recovery design according to an embodiment involves the following

[0028] 4 Implementation Tasks [0029] The design according to an embodiment involves several moving parts each with their own configuration. To make implementation of the design easier, this section provides various details on implementation tasks that need to be accomplished in order for the DR solution to work effectively.

[0030] 4.1. Installing Local Backup Storage

[0031] The DR solution depends on a local backup storage device to which ShadowProtect will write the backup files. ShadowProtect can write to any storage that can normally be accessed from a Windows Server: local and network. This means the following classes of backup devices are acceptable:

[0032] • Internal SATA or SAS hard disk(s) made available via SCSI (SAS)

[0033] • External SATA (eSATA) hard disk

[0034] • NAS devices with CIFS share interface

[0035] • NAS devices with USBoE interface (requires driver install on appliance)

[0036] • NAS devices with NFS interface (requires enablement of

[0037] • Network Share on another computer (preferably a server)

[0038] Potential options that will not work for local backup storage:

[0039] • Any USB drive

[0040] 4.2. Installing ShadowProtect Server

[0041] Each appliance according to an embodiment needs to have the ShadowProtect Server 3.2 software installed into it. This is a straight forward installation from an ISO. Media can be found on the \\zfsdev\tank_ISOs share.

[0042] 4.3. Configuring ShadowProtect Server

[0043]

[0044] 4.4. Creating ZFS DR Storage [0045] The DR files uploaded from client environments need to be stored on a ZFS storage server. This section tells you how to set up that storage. First, you need a pool with many TB of storage available, preferably in a RAID-Z configuration. Assuming you have a large number of storage devices (/dev/dsk/c*) configured, you would want to set up a pool with a command like this:

[0046] zpool create pool raidz cOtOdO c ItOdO c2tθdθ c3tθdθ c4tθdθ c5tθdθ cόtOdO c7tθdθ \

[0047] raidz cOtOdl cltOdl c2tθdl c3tθdl c4tθdl c5tθdl cόtOdl c7tθdl

\

[0048] raidz cθtθd2 cltθd2 c2tθd2 c3tθd2 c4tθd2 c5tθd2 c6tθd2 c8tθd2

[0049]

[0050] Note the pattern in setting up the RAIDZ groups. We have asked for a pool to be created from a strip of 3 raidz groups. Each raidz group contains 8 disks spread across each of 8 controllers. You want to spread the raidz groups across controllers for two reasons: a) to maximize I/O throughput on as many controllers and devices as possible, and b) to minimize the chance that any one failure in a disk or controller leads to an outage. With raidz configuration you can suffer a hardware failure on any one disk or controller and still keep functioning.

[0051] Once the pool is created, you can create a single data set in ZFS to store the DR data:

[0052] zfs create pool/DR -o atime=off compression=gzip devices=off exec=off nbmand=off

[0053]

[0054] Note that this file system should *not* be shared to any clients. The only way to get data on or off this data set is according to an embodiment through rsync (see below). [0055] 4.5. Configuring rsync (server)

[0056] The software used to synchronize the local backup data (at client site) with the Storage Server (Doyenz data center) is rsync. The rsync server needs to have a specific configuration in order for it to be useful with clients.

[0057] 4.5.1. ZFS dataset configuration for DR

[0058] The dataset used to store the DR data should have the following file structure:

[0059] drwx 2 nobody nobody 2 Aug 20 13:53 foo.bar.com

[0060] -rw 1 root root 505 Aug 20 07:05 rsyncd.conf

[0061] -rw 1 root root 25 Aug 18 15:20 secrets

[0062]

[0063] The rsyncd.conf file provides the rsync configuration for the rsync server. The secrets file contains the customer passwords for accessing their backup data (via rsync). For each appliance, there must be a "foo.bar.com" directory to hold the backup data for that appliance. The name of the directory should be the same as the Kaseya machine ID and Group ID, which should be the same as the ComputerName and DomainName fields joined by a period. For example, our SBS server would be: serverOl. doyenz. internal. The permissions and ownership must be as shown (directories with 700 mode and owned by "nobody"). Additionally, the "nobody" user should be prevented from logging in (it has no login shell in /etc/passwd), which is the default.

[0064] 4.5.2. rsyncd.conf

[0065] The configuration of the rsyncd.conf file needs to be set up carefully. It has two parts, a global part and a per-appliance part. The global part should appear first in the file and contain this:

[0066] use chroot = true

[0067] uid = nobody [0068] gid = nobody

[0069] syslog facility = Iocal5

[0070]

[0071] The per-appliance part should contain the following with the underlined portions replaced with appliance specific information:

[0072] [foo.bar.com]

[0073] comment = This is the Disaster Recovery area for bar.com machine foo

[0074] path = /pool/DR/foo.bar.com

[0075] max connections = 5

[0076] read >

[0077] write >

[0078] list = false

[0079] auth users = foo.bar.com

[0080] secrets file = /pool/DR/secrets

[0081] strict modes = true

[0082] hosts allow = 10.10.10.0/24

[0083] timeout = 300

[0084] refuse options = backup update inplace copy-dirlinks hard-links executability wh

[0085] ole-file existing fuzzy

[0086] dont compress = *

[0087] For the hosts allow variable, you should specify the gateway IP address of the customer's production network. That is, we assume the appliance is NAT'd and we don't want the local address but rather the public address. This is a strong and necessary security measure as it will prevent any rsync job coming from anywhere other than the customer's network to fail. [0088] Note that a section like the one shown above must be appended to the rsyncd.conf file for every appliance that utilizes DR. Correspondingly, the path specified with the "path" variable must be created. Finally, an entry must be put into the "secrets" file to provide the password to access this rsync directory.

[0089] For further details see the rsync. d(4) man page.

[0090] 4.5.3. rsync SMF Service

[0091] By default, OpenSolaris does not configure the rsync program to run as an SMF service. To do this you need to import the manifest file on the OpenSolaris server and start the service. The manifest file looks like this (with highlighted portions appropriately replaced):

[0092] <?xml version=" 1.0"?>

[0093] <!DOCTYPE service bundle SYSTEM

7usr/share/lib/xml/dtd/service_bundle.dtd.1 ">

[0094] <service_bundle type="manifest" name="rsync">

[0095] <service name="network/rsync" type=" service" version="4">

[0096] <create_default_instance enabled="false"/>

[0097] <single_instance/>

[0098] <!--

[0099] If there's no network, then there's no point in running

[00100] ->

[00101] dependency

[00102] name="loopback"

[00103] grouping="require_all"

[00104] restart_on="error"

[00105] type="service">

[00106] <service_fmri value="svc:/network/loopback:default"/> [00107] </dependency>

[00108]

[00109] <dependency

[00110] name="physical"

[00111] grouping= " requir e all "

[00112] restart_on="error"

[00113] type="service">

[00114] <service_fmri value="svc:/network/physical:default"/>

[00115] </dependency>

[00116]

[00117] <dependency

[00118] name="fs-local"

[00119] grouping= " requir e all "

[00120] restart_on="none"

[00121] type="service">

[00122] <service_fmri value="svc:/system/filesystem/local"/>

[00123] </dependency>

[00124]

[00125] <exec_method

[00126] type="method"

[00127] name="start"

[00128] exec="/usr/bin/rsync -daemon -config=/path/to/rsync.conf

[00129] timeout_seconds=" 60 "/>

[00130]

[00131] <exec_method

[00132] type="method" [00133] name- stop

[00134] exec=":kill"

[00135] timeout_seconds=" 60 "/>

[00136]

[00137] <exec method

[00138] type="method"

[00139] name="refresh"

[00140] exec=":kill -HUP"

[00141] timeout_seconds=" 60 "/>

[00142]

[00143] <stability value= "Unstable 7>

[00144]

[00145] <template>

[[0000114466]] <common name>

[[0000114477]] <loctext xml:lang="C">RSYNC daemon</loctext> r [00001144881] </common name> [00149] [00150] <documentation> [00151] <manpage title="rsync" section="77> [00152] <doc_link name="rsync.org" uri="http://www.rsync.org/docs/"/> [00153] </documentation>

[00154] </template>

[00155] </service>

[00156] </service_bundle> [00157] [00158] To use this manifest, you issue the following commands as root on OpenSolaris:

[00159] svccfg import /path/to/rsync.xml

[00160] svcadm clear svc:/network/rsync: default

[00161] svcadm restart svc:/network/rsync: default

[00162] svcadm enable svc:/network/rsync: default

[00163]

[00164] Note that the rsync service also depends on the default physical and loopback network services. It won't go "online" unless both these services are also online. You can check their state with:

[00165] svcs -a | grep physical

[00166] svcs -a | grep loopback

[00167]

[00168] You can force them enabled with:

[00169] svcadm enable svc:/network/loopback:default

[00170] svcadm enable svc:/network/physical:default

[00171]

[00172] 4.6. Configuring rsync (client)

[00173] The rsync client software runs on the virtual appliance in the customer's production environment. The

[00174] 4.7. Using Storage Craft Recovery Environment

[00175] 1. Create the virtual machine according to the original specification. In particular it is important to get the disk geometry and partition information of the disks the same as the machine from which the backup was created. Make sure the partitions are not formatted or SCRE will refuse to restore to them.

[00176] 2. Attach the ShadowProtect 3.2 ISO image to the VM' s DVD drive [00177] 3 Boot the VM

[00178] 4 The StorageCraft splash screen appears

[00180] 5 Wait a few seconds

[00181] 6 The StorageCraft Recovery Environment menu appears

[00183] 7. Choose item 1 (keyboard events: 1 <enter>) [00184] 8. Wait a few seconds while Vista boots up. [00185] 9. The prompt for networking will appear:

[00187] 10 Click OK to start networking (keyboard event O) [00188] 11 Wait about a minute for the network drivers to install and for the main window to appear

[00190] 12 Select the Network Configuration Utility (keyboard <Alt-T><Enter>)

[00192] 13 Select the Network Drives Tab (keyboard <Alt-N>)

[00193]

[00194] 14. Select the driver letter (keyboard: N<Enter>)

[00195] 15. Enter the network path, user name and password. Use <Tab> to move the next field and regular characters to type out the path, name and password. It will end looking something like this:

[00197] 16 Click the "Map Drive" button (keyboard <Tab><Space>) [00198] 17 Click the "Close" button (keyboard

<Tab><Tab><Tab><Tab><Tab><Tab><Tab><Tab><Space>)

[00199] 18 Close the Network Configuration Utility (keyboard <Esc>) [00200] 19 Select the Restore Wizard (keyboard <Alt-A><Down><Enter>)

[00201] 20 The Restore Wizard appears

[00202] 21 Select Next (keyboard <space>)

[00203] 22 Type in the path name to the backup file ( SPI) and enter the password

[00205] 24. Wait for the dependent files to be found (may take 1-2 minutes):

[00206] 25. Click Next on the Backup Image Dependencies page (keyboard: <space>):

[00208] Definitions according to an embodiment:

[00209] Work Sequence An XML document containing 1 or more Work Units to be queued and executed as an autonomous operation block by the VM Control Service. This is the data input format to the VM Control Service Execute() interface request defined below.

[00210]

[00211] Work Unit An XML definition for a single operation that can be requested of and performed by the VM Control Service on a Network Environment or Appliance.

[00212] Overview

[00213] This document fully describes the interface according to an embodiment to the Doyenz, Inc. VM Control Service (frequently referred to simply as the Doyenz "Backend"). It is intended to be used by developers writing software that will issue work requests to create, delete, and modify Appliances (i.e. virtual machines) managed by the Doyenz Virtualization Infrastructure.

[00215] VM Control Service Interface [00216] The interface to the Doyenz VM Control Service (i.e. "Backend") may be a [Microsoft] Windows Communication Foundation (WCF) network connection. A control program may use a HTTP type endpoint binding as follows to establish a connection to the Backend: http://hostname:8811NMControlService/execute where hostname is the DNS name or IP address of the computer hosting the Backend service.

[00217]

[00218] C# Code Fragment Example:

[00219]

[00220] using System. ServiceModel;

[00221] using Doyenz. Common;

[00222] using Doyenz. VMControlServicelnterface;

[00223]

[00224] EndpointAddress ep = new

EndpointAddress(@"http://10.10.20.177:8811NMControlService/execute");

[00225] BasicHttpBinding clientBinding = new BasicHttpBinding();

[00226]

[00227] clientBinding. MaxReceivedMessageSize = long.MaxValue;

[00228] clientBinding. TransferMode = TransferMode. Streamed;

[00229]

[00230] VMControlService vmControlService

ChannelFactory<VMControlService>.CreateChannel(clientBinding, ep);

[00231] Network Environment [Version] References

[00232] All network environment [version] references are currently composed of exactly three numerical (base 10) sections each separated by single period ('.') character, and have the following format/meaning:

[00233] [00234] networkEnvironmentld.versionNumber.instanceNumber

[00235] Where:

[00236] networkEnvironmentld Network Environment identifier number.

[00237] versionNumber Version number for the Network

Environment/ Appliance.

[00238] instanceNumber Instance identifier number for the execution run (i.e. Run Number).

[00239]

[00240] Execution Status

[00241] The [Work Sequence/Work Unit] Execution Status value returned by some of the interface functions specified below can have the following values/Meanings:

[00242]

[00243] public enum ExecutionStatus

[00244] {

[00245] DoesNotExist = 0, // Backend: Returned by

GetWorkSequenceStatus() and GetWorkUnitStatus()

[00246]

[00247] ExecutionRequested = 1, // Frontend: Initial operation request

[00248] QueuedForExecution = 2, // Backend: Operation request accepted

[00249] Executing = 3, // Backend: Operation in progress

[00250] ExecutionError = 4, // Backend: Operation aborted in failure

[00251] Completed = 5, // Backend: Operation finished successfully

[00252]

[00253] CancellationRequested = 6, // Frontend: Initial operation request

[00254] QueuedForCancellation = 7, // Backend: Operation request accepted

[00255] Cancelling = 8, // Backend: Operation in progress [00256] CancellationError = 9Jl Backend: Operation aborted in failure

[00257] Cancelled = 10, // Backend: Operation finished successfully

[00258] }

[00259] Appliance Status

[00260] The Appliance [Run] Status value returned by some of the interface functions specified below can have the following values/Meanings: [00261]

[00262] public enum ApplianceStatus [00263] {

[00264] DoesNotExist = 0, // Backend: Returned by GetApplianceStatusQ [00265] [00266] Startlnitiated = 1, // Backend: Operation initiated [00267] Starting = 3, // Backend: Operation in progress [00268] ErrorStarting = 4, // Backend: Operation aborted in failure [00269] Running = 5, // Backend: Operation finished successfully [00270] [00271] Stoplnitiated = 6, // Backend: Operation initiated [00272] Stopping = 8, // Backend: Operation in progress [00273] ErrorStopping = 9, // Backend: Operation aborted in failure [00274] Stopped = 10, // Backend: Operation finished successfully

[00275] }

[00276] (Backend) Interface Functions [00277] Execution Control Requests [00278] void Execute(string workSequenceXml);

[00279] Directs the Backend to execute an XML Work Sequence of Work Units on a virtual machine. During the execution status can be acquired by referring to the id of the Work Sequence, or the id of any of the Work Units in the sequence. After the execution is done, a versioned snapshot of the entire Work Sequence output image will be taken as requested by the outputVersion="" attribute. Also a work log for each Work Unit will be stored in a directory named to match its id.

[00280]

[00281] An XML Work Sequence request has the following basic structure:

[00282]

[00283] <?xml version="1.0" encoding="utf-8"?>

[00284] <WorkSequence id="" input Version="" output Version="" save="">

[00285] <{workUnitCommandName} id="">

[00286] {workUnitDataField}

[00287]

[00288]

[00289]

[00290] </{workUnitCommandName}>

[00291]

[00292]

[00293]

[00294] </WorkSequence>

[00295] Where:

[00296] id=""

[00297] A Globally Unique Identifier (GUID) for the Work Sequence or Work Unit of the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx or {xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxxx} where x are hexadecimal digits (0-9a-fA-F). This identifier value must be unique for each and every Work Sequence and Work Unit and they must never be repeated (even in different Work Sequences). [00298] input Version=""

[00299] Input version reference of an existing Network Environment image. If there is no existing version, as this is a Network Environment creation work sequence, then this field should be either completely omitted or the string data for it should be empty. If a version reference is specified and it does not exist then the execution request will fail with an error.

[00300] outputVersion=""

[00301] Output version reference of a new Network Environment image to be created. The output version reference must always be specified, except for DeleteNetworkEnvironment (always omitted) and StopNetworkEnvironment (usually omitted). The output version reference cannot be the same reference as the input version reference, and no Network Environment image may already exist for the output version reference.

[00302] save=""

[00303] Indicates whether the output of the Work Sequence should be saved or not. Set to True to save the output, or to False to discard the output. If this attribute is not specified at all, Save Output is usually assumed where applicable.

[00304]

[00305] void CancelExecution(Guid workSequenceld);

[00306] Cancel the execution of the requested Work Sequence. This sequence way be currently executing or may still be in the pending queue waiting to start executing. Either way it will be immediately terminated and any in-progress work will be purged from the system versioning rolled back as if the Work Sequence have never been requested.

[00307]

[00308] Work Sequence/Unit Execution Status Requests [00309] WorkSequenceStatus GetWorkSequenceStatus(long networkEnvironmentld, Guid workSequenceld);

[00310] Get the overall execution status of the requested Work Sequence (status of the current Work Unit in the sequence if one is executing). This work units for this work sequence way be currently executing or may still be in the pending queue waiting to start executing.

[00311]

[00312] Note: This function can return the "live" state of active Work Sequences being processed by the VM Control Service, and historical state for completed Work Sequences.

[00313]

[00314] public class WorkSequenceStatus

[00315] {

[00316] public ExecutionStatus ExecutionStatus;

[00317] public int TotalSteps;

[00318] public int StepsCompleted;

[00319]

[00320] public Guid CurrentWorkUnitld;

[00321] public string Current StepName; // Internal mnemonic (Note: Not for

UI display purposes)

[00322] }

[00323]

[00324] ExecutionStatus GetWorkUnitStatus(long networkEnvironmentld, Guid workUnitld); [00325] Get the execution status of the requested Work Unit in a sequence. This work unit way be currently executing or may still be in the pending queue waiting to start executing.

[00326]

[00327] Note: This function can return the "live" state of active Work Units being processed by the VM Control Service, and historical state for completed Work Units.

[00328]

[00329] Stream GetWorkUnitExecutionLog(long networkEnvironmentld, Guid workUnitld);

[00330] Gets a stream for reading the execution log for a Work Unit. A stream will be returned for completed work units and for in-progress work units. If no log currently exists for a work unit then null will be returned.

[00331]

[00332] Note: This function can return the log of an active Work Unit being processed by the VM Control Service, and a historical log for a completed Work Unit.

[00333] Appliance Requests

[00334] ApplianceStatus GetApplianceStatus(string networkEnvironmentReference, long applianceld);

[00335] Get the current [run] status of the requested Appliance.

[00336]

[00337] string Get VNCReference( string networkEnvironmentReference, long applianceld);

[00338] Get a reference to a VNC port number that will allow access to the Appliance's Console UI for visual monitoring of operation progress.

[00339]

[00340] Note: Only valid while an Appliance in running. [00341] Warning: This value may change each time an Appliance is restarted.

[00342]

[00343] string GetExternalIPAddress(string networkEnvironmentReference, long applianceld);

[00344] Get the external IP address for an Appliance at a specific image version.

[00345]

[00346] Note: Only valid while an Appliance in running.

[00347] Warning: This value may change each time an Appliance is restarted.

[00348] (Backend) Service Status Requests

[00349] List<WorkSequenceState> GetServiceAllWorkSequenceState();

[00350] WorkSequenceState GetServiceWorkSequenceState(Guid workSequenceld);

[00351] Get the complete state for all Work Sequences or a single specific Work Sequence currently being processed by the VM Control Service (i.e. Backend). Each requested queued or in-progress Work Sequence (with current state information), and their Work Units (with current state information) will be returned. Note that this information will include internally added Work Units that were not part of the Work Unit list directly specified by the user in a Work Sequence.

[00352]

[00353] Note: These functions only return the "live" state of Work Sequences being processed by the VM Control Service, no historical information will be returned for completed Work Sequences.

[00354]

[00355] public class WorkSequenceState

[00356] {

[00357] public Guid WorkSequenceld; [00358] public string Input Version;

[00359] public string Output Version;

[00360]

[00361] public WorkSequenceStatus WorkSequenceStatus;

[00362]

[00363] public List<WorkUnitState> WorkUnitStateList;

[00364] }

[00365]

[00366] public class WorkUnitState

[00367] {

[00368] public Guid WorkUnitld;

[00369] public ExecutionStatus ExecutionStatus;

[00370] }

[00371] Execute() XML Work Sequence (Operation) Requests

[00372] The command as specified above can execute several different types of operation requests on a Network Environment/Appliance. The currently supported operations that may be requested are described below.

[00373]

[00374] Create SBS Server Appliance

[00375] This operation request allows the creation on a Small Business System (SBS) Server appliance. This operation may only be requested a single time for any one appliance.

[00376]

[00377] The Work Units shown below can be sent in a single Work Sequence as shown, or may be broken up into separate Work Sequences. If broken into separate sequences the relative order shown below must be preserved (CreateNetworkEnvironment then CreateSB S Server then DriveSBSWizard).

[00378]

[00379] If all three Work Units are specified together then an Input Version cannot be specified and an Output Version must be specified. However if specified in separate Work Sequences then only CreateNetworkEnvironment has this limitation, and the sequences with CreateSB S Server and DriveSBSWizard must specify both Input and Output Versions.

[00380]

[00381] <?xml version="1.0" encoding="utf-8"?>

[00382] <WorkSequence id="" input Version="" output Version="" save="">

[00383]

[00384] <CreateNetworkEnvironment id=" "> [00385] <Description></Description> [00386] [00387] <SubnetMask></SubnetMask> [00388] <Gateway></Gateway> [00389] [00390] <Dnsl></Dnsl> [00391] <Dns2></Dns2> [00392] </CreateNetworkEnvironment> [00393] [00394] <CreateSBSServer id=""> [00395] <ApplianceId></ApplianceId> [00396] [00397] <Name></Name> [00398] <Organization></Organization> [00399] <LicenseKey></LicenseKey>

[00400] <ComputerName></ComputerName>

[00401] <UserName></UserName>

[00402] <AdminPassword></AdminPassword>

[00403] <LanguageGroup></LanguageGroup>

[00404] <RegionalLanguage></RegionalLanguage>

[00405] <TAPIAreaCodeX/TAPIAreaCode>

[00406] <TAPICountryCode></TAPICountryCode>

[00407] <TimeZone></TimeZone>

[00408]

[00409] <NumNICs></NumNICs>

[00410] <AdapterlUseDHCPx/AdapterlUseDHCP>

[00411] < Adapter 1 IP Address></ Adapter 1 IP Address>

[00412] <Adapterl SubnetMaskx/ Adapter 1 SubnetMask>

[00413] < Adapter 1 DefaultGatewayX/ Adapter 1 DefaultGateway>

[00414]

[00415] <WINSServerListx/WINSServerList>

[00416] <Domain JoinKindx/Domain JoinKind>

[00417] <DomainJoinName></DomainJoinName>

[00418] <DomainJoinUserName></DomainJoinUserName>

[00419] <DomainJoinPassword></DomainJoinPassword>

[00420] <ExternalDNS> 1 </ExternalDNS>

[00421] <ScreenResolution></ScreenResolution>

[00422] <InstallPartitionX/InstallPartition>

[00423] <PartitionType></PartitionType>

[00424] </CreateSBSServer> [00425] [00426] <DriveSB S Wizard id=""> [00427] <ApplianceId></ApplianceId> [00428] [00429] <PhoneNumber></PhoneNumber> [00430] <FaxNumber></FaxNumber> [00431] [00432] < Address 1 ></ Address 1 > [00433] <Address2></Address2> [00434] <City></City> [00435] <StateOrProvince></StateOrProvince> [00436] <ZipOrPostal></ZipOrPostal> [00437] <CountryOrRegion></CountryOrRegion> [00438] [00439] <InternalDNS></InternalDNS> [00440] <NetBIO SDomainX/NetBIO SDomain> [00441] <ComputerName></ComputerName> [00442] <IPAddress></IPAddress> [00443] <SubnetMask></SubnetMask> [00444] <DefaultGateway></DefaultGateway> [00445] <UserName></UserName> [00446] <AdminPassword></AdminPassword> [00447] <NetworkAdapter></NetworkAdapter> [00448] <UseSB SDHCPx/UseSB SDHCP> [00449] [00450] <ServerToolsPath></ServerToolsPath> [00451] <ExchangeServerPath></ExchangeServerPath>

[00452] <MSDataEnginePath></MSDataEnginePath>

[00453] <UsersSharedFoldersPath></UsersSharedFoldersPath>

[00454] <ClientApplicationsPath></ClientApplicationsPath>

[00455] <SentFaxesPath></SentFaxesPath>

[00456] <ExchangeStorePath></ExchangeStorePath>

[00457] <ExchangeTxnLogsPathx/ExchangeTxnLogsPath>

[00458] </DriveSBSWizard>

[00459]

[00460] </WorkSequence>

[00461] Add User to a SBS Server Appliance

[00462] This operation request allows the ability to add User Accounts to an existing Small Business System (SBS) Server appliance. This request may be made any number of times specifying from 1 to 5 user account definitions per run. It must have an Input Version and an Output Version specified.

[00463]

[00464] Note that the User2 through User5 fields may be omitted in part or in whole if not needed.

[00465]

[00466] <?xml version="1.0" encoding="utf-8"?>

[00467] <WorkSequence id="" input Version="" output Version="" save="">

[00468]

[00469] <AddUsersToSBS id=""> [00470] <ApplianceId></ApplianceId> [00471] [00472] < TemplateName></TemplateName> [00473] <UserName></UserName> [00474] <AdminPassword></AdminPassword> [00475] [00476] <NumberOfUsersToAdd></NumberOfUsersToAdd> [00477] [00478] <User 1 FirstName></User 1 FirstName> [00479] <User 1 LastName></User 1 LastName> [00480] <User 1 LogonName></User 1 LogonName> [00481] <User 1 Email Aliasx/User 1 Email Alias> [00482] <User 1 Telephonex/User 1 Telephone> [00483] <User 1 Passwordx/User 1 Password> [00484] [00485] <User2FirstName></User2FirstName> [00486] <User2LastName></User2LastName> [00487] <User2LogonName></User2LogonName> [00488] <User2EmailAlias></User2EmailAlias> [00489] <User2Telephone></User2Telephone> [00490] <User2Password></User2Password> [00491] [00492] <User3FirstName></User3FirstName> [00493] <User3LastName></User3LastName> [00494] <User3 LogonName></User3 LogonName> [00495] <User3EmailAlias></User3EmailAlias> [00496] <User3 Telephone></User3 Telephone> [00497] <User3Password></User3Password> [00498] [00499] <User4FirstName></User4FirstName> [00500] <User4LastName></User4LastName> [00501] <User4LogonName></User4LogonName> [00502] <User4EmailAlias></User4EmailAlias> [00503] <User4Telephone></User4Telephone> [00504] <User4Password></User4Password> [00505] [00506] <User5FirstName></User5FirstName> [00507] <User5LastName></User5LastName> [00508] <User5LogonName></User5LogonName> [00509] <User5EmailAlias></User5EmailAlias> [00510] <User5 Telephone></User5 Telephone> [00511] <User5Password></User5Password> [00512] [00513] <SetUpComputersNow></SetUpComputersNow> [00514] [00515] <NewComputer 1 ></NewComputer 1 > [00516] <NewComputer2></NewComputer2> [00517] <NewComputer3 ></NewComputer3 > [00518] <NewComputer4></NewComputer4> [00519] <NewComputer5></NewComputer5> [00520] [00521] <InstallClientOSServicePacks></InstallClientOSServicePacks> [00522] <InstallIE60></InstallIE60> [00523] <InstallOutlook2003></InstallOutlook2003> [00524] <InstallSharedFaxClient></InstallSharedFaxClient> [00525]

<AllowApplicationsToBeModified></ Allow ApplicationsToBeModified>

[00526] <LogOffAfterSetupX/LogOffAfterSetup>

[00527] <InstallConnectionMgr></InstallConnectionMgr>

[00528] <Install ActiveSync38></Install ActiveSync38>

[00529] </AddUsersToSBS>

[00530]

[00531] </WorkSequence>

[00532] Clone (i.e. Copy) Network Environment

[00533] This operation request allows the cloning (or copying) of a Network Environment (and all appliances in it) to a new network environment with a different Id and Version. This request may only be requested a single time per Work Sequence. The new Network Environment Id and version must not already exist. This request must have an Input Version and an Output Version specified.

[00534]

[00535] <?xml version="1.0" encoding="utf-8"?>

[00536] <WorkSequence id="" input Version="" output Version="" save="">

[00537]

[00538] <CloneNetworkEnvironment id="" />

[00539]

[00540] </WorkSequence>

[00541] Delete Network Environment

[00542] Allows for the deletion of an existing Network Environment (and all appliances in it). This operation may only be requested a single time per Work Sequence. If an appliance is requested to be deleted that does not exist, the operation will complete successfully, no error will be signaled for this condition. This request must have an Input Version and cannot have an Output Version specified (the save="" option must be False or be omitted entirely).

[00543]

[00544] <?xml version="1.0" encoding="utf-8"?>

[00545] <WorkSequence id="" input Version="" >

[00546]

[00547] <DeleteNetworkEnvironment id="" />

[00548]

[00549] </WorkSequence>

[00550]

[00551] Start Network Environment

[00552] Starts all appliances in a single Network Environment executing. This operation may only be requested a single time per Work Sequence. This request must have an Input Version and an Output Version specified. The save="" option should be False or be omitted entirely.

[00553]

[00554] <?xml version="1.0" encoding="utf-8"?>

[00555] <WorkSequence id="" input Version="" outputVersion="">

[00556]

[00557] <StartNetworkEnvironment id="" />

[00558]

[00559] </WorkSequence>

[00560] Stop Network Environment

[00561] Stops all running appliances in a single Network Environment from executing. This operation may only be requested a single time per Work Sequence. This request must have an Input Version and can have an optional Output Version specified. [00562]

[00563] <?xml version="1.0" encoding="utf-8"?>

[00564] <WorkSequence id="" input Version="" output Version="" save="">

[00565]

[00566] <StopNetworkEnvironment id="" />

[00567]

[00568] </WorkSequence>

[00569]

[00570] Start Appliances

[00571] Starts one or more specific appliances in a single Network Environment executing (all other appliances in that network environment are unaffected). This request may be made as many times as desired in the same Work Sequence or in different Work Sequences. This request must have an Input Version and can have an optional Output Version specified.

[00572]

[00573] <?xml version="1.0" encoding="utf-8"?>

[00574] <WorkSequence id="" input Version="" output Version="" save="">

[00575]

[00576] <StartAppliances id="">

[00577] <ApplianceId></ApplianceId>

[00578]

[00579]

[00580]

[00581] </StartAppliances>

[00582]

[00583] </WorkSequence> [00584] Stop Appliances

[00585] Stops one or more specific running appliances in a single Network Environment from executing (all other appliances in that network environment are unaffected). This request may be made as many times as desired in the same Work Sequence or in different Work Sequences. This request must have an Input Version and can have an optional Output Version specified.

[00586]

[00587] <?xml version="1.0" encoding="utf-8"?>

[00588] <WorkSequence id="" input Version="" output Version="" save="">

[00589]

[00590] <StopAppliances id="">

[00591] <ApplianceId></ApplianceId>

[00592]

[00593]

[00594]

[00595] </StopAppliances>

[00596]

[00597] </WorkSequence>

[00598] 1.1. Kaseya Background

[00599] Doyenz may derive most of its monitoring & management functions from a tool named Kaseya according to an embodiment. It has both a Server and an Agent component. The Agent is installed on each VM image that Doyenz produces. The Agent communicates status and events to the Server as well as taking various maintenance actions. The Server provides a web interface, a Web Services API and a set of database views that can be queried.

[00600] 1.2. Integration Points

[00601] There are several points of integration that we can use with Kaseya. Each of these will be discussed in further detail below:

[00602] • Account Integration - Access to Kaseya information is specified with accounts, roles, group access and Machine Group IDs. These need to correspond to the similar Doyenz notions.

[00603] • Agent Installation - In order to use Kaseya, their Agent must be installed by our VM image generation facility.

[00604] • GUI Customization - The Kaseya web GUI can be completely customized so that it looks like it is Doyenz branded.

[00605] • Web Services API - Kaseya has a limited WS API that can be used to retrieve information about trouble tickets, monitoring events, and machine details.

[00606] • Database Views - Kaseya has a number of database views that can be used to access the information in its database with standard SQL queries.

[00607] • Systems Management Integration - Kaseya can run scripts of various sorts to do standard maintenance and management tasks automatically. Execution of these needs to be integrated into our web application. Generally these are scheduled.

[00608] 2. Demo Integration (For Pune Team)

[00609] 2.1. Overview [00610] This initial integration will address only the following integration points:

[00611] • GUI Customization - already done

[00612] • Agent Installation - to be done manually by Bellevue Team

[00613] • Web Services API - we will use the Kaseya Web Services API to display the following information on the dashboard:

[00614] o Basic Machine & Operating System Info (GetMachine WS call)

[00615] o List of Alarms associated with the machine (GetAlarmList WS call)

[00616] o List of Trouble Tickets associated with the machine (GetTicketList WS call)

[00617] • Machine Management:

[00618] o A link to a page that allows monitoring & management of an individual machine

[00619] • Automated Login - Avoid forcing the user to log in to Kaseya separately.

[00620] 2.2. Kaseya Server Access

[00621] We have set up a Kaseya server. It is available at this URL: http://ks.doyenz.com/. To log in, use ID "demo" and password "At#2Dg#6Rq!4" (without the quotes).

[00622] 2.3.1. Create VSA Web Services Client

[00623] Visual Studio Team Suite has a wizard for creating a C# class that proxies between C# method calls and a web service. Use this wizard to create a C# class named VSAWebServicesClient. FYI, VSA stands for "Virtual System Administration", the name of Kaseya' s product. To create this class, the wizard will ask for the URL of the web services definition. Use the "WSDL" URL above.

[00624] This class will be used to access Kaseya VSA data via its web services API as described at this URL: https://ks. doyenz.com/vsaWS/KaseyaWS.asmx [00625] You should add code to this class that does the authentication upon instantiation and caches the session token. See the Authenticate WS method for details. Use the password details given in section 2.2

[00626] 2.3.2. Associate Appliance with Agent GUID

[00627] There is a one-to-one relationship between an Appliance and a Kaseya Agent. Each Agent has a GUID that can be obtained from the VSAWebServicesClient.GetMachineList call. In several of the following tasks, we need to be able to determine the Agent GUID associated with an Appliance in order to properly filter or request results from Kaseya Web Services. The result of the GetMachineList call is documented here : http ://help . kaseya. com/WebHelp/en-US/5000000/3465. htm

[00628] The result will contain this kind of information:

[00629] <?xml version="1.0" encoding="utf-16"?>

[00630] <GetMachineListResponse xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

[00631] <Machines>

[00632] <Machine>

[00633] <Machine_GroupID>mv-w2k3 - 64. doy enz . internal</Machine_GroupID>

[00634] <IpAddress>10.10.10.134</IpAddress>

[00635] <MacAddr>00-0 A-CD- 16-54-25</Mac Addr>

[00636] <groupName>doyenz. internal</groupName>

[00637] <firstCheckin>2008-08- 11 T 11 :23 : 14.937-07 : 00</firstCheckin>

[00638] <agentGuid>27610872551390003160033799</agentGuid>

[00639] </Machine>

[00640] </Machines> [00641] <Method>GetMachineList</Method>

[00642] <TransactionID> 10</TransactionID>

[00643] <ErrorMessage />

[00644] <ErrorLocation />

[00645] </GetMachineListResponse>

[00646]

[00647] The association is fairly simple. You should know from the Appliance database what the MAC address is for each appliance. Simply find that address in the MacAddr field (yellow) and then the agentGuid field (green) is the correct GUID for that appliance. You will also need the groupName field (cyan) for some of the subsequent WS calls.

[00648] You will use groupName and agentGUID field in many places in the following tasks so the code that does this should be in a library, accessible from many contexts. You might also want to just cache these values or possibly add groupName and agentGUID to the Appliance table in the database. It's your choice.

[00649] 2.3.3. Machine Management Link

[00650] An embodiment includes a single button or link that says "Manage". That link needs to open this URL:

[00651] https://ks.doyenz.com/AgentTab/singleMachineFrame.asp?acctGuid=XXX X

[00652] in a new browser window. Replace the XXXX with the agentGUID of the Appliance you want to manage.

[00653] This opens a Kaseya window that allows the user to perform many management functions such as getting basic information, seeing installed applications, applying patches, gaining remote control, reviewing logs, etc.

[00654] 2.3.4. System Info on Dashboard [00655] Currently we display static information about the operating system on the dashboard. This may be replaced with live data from Kaseya. Issue a call to VSAWebServicesClient.GetMachine to retrieve the information to be displayed. The call is documented at http://help.kaseya.com/WebHelp/en-US/5000000/3437.htm and it returns a large number of results. However, the only fields of interest for the purpose of this task are:

[00656] ComputerName string Name of the Computer

[00657] OsType string String contains OS type, such as 95, 98, NT4, 2000, NT3.51, or WIN32S. Derived from portions of MajorVersion, MinorVersion, and Platformld.

[00658] Oslnfo string String contains additional OS info, such as Build 1381

Service Pack 3. Derived from portions of BuildNumber and CsdVersion.

[00659] MajorVersion decimal Major version number from

GetVersionEx() Windows function call.

[00660] MinorVersion string Minor version number from GetVersionEx()

Windows function call. If Platformld is Win32 for Windows, then a 0 MinorVersion indicates Windows 95. If Platformld is Win32 for Windows, then then a MinorVersion > 0 indicates Windows 98.

[00661] currentUser string login name of the currently logged in user. Blank if no one logged in at this time

[00662] lastReboot dateTime timestamp when this system was last rebooted

[00663]

[00664] Simply retrieve this information and display it under the name of the Appliance.

[00665] Notes:

[00666] • When you issue this call you must provide the groupName that the appliance belongs to as the value of the Machine GroupID parameter. The call will return info on all machines in that group. Traverse the returned list and find the machine that has the same agentGUID value as the Appliance you want to display on the dashboard.

[00667] ^»2.3.5. Alarm List on Dashboard

[00668] The dashboard currently has a static list of alarms and two actions, "Act" and "Del" that can be taken. These need to be replaced with actual alarm information for the Appliance. To get that information you need to call VSAWebServicesClient.GetAlarmList, which is documented here:

[00669] http ://help . kaseya. com/WebHelp/en- US/5000000/index.htm?toc.htm?2167.htm.

[00670] This call is a little weird. You should call it once with ReturnAllRecords set to "true" and cache the result. Then, periodically (e.g. each page load of the dashboard) call it again with ReturnAllRecords set to "false". It will then return only the new alarms since the last call. In this way you can keep a rolling cache of the alarms.

[00671] The GetAlarmList call returns alarms for *all* machines. You will need to filter the result in order to find the alarms that apply to the Appliance at hand. To do that, you will simply match the agentGUID field returned from the call with the same value associated with the Appliance.

[00672] Please note the following:

[00673] • You should display no more than 4 alarms on the Appliance dashboard.

[00674] • If possible, please show the highest priority alerts first, then sort by date (descending). Priority can be

[00675] • If no alarms are returned by the WS call, replace the whole table with a nice message, centered in the area saying "No Alarms For This Appliance" (or something like that)

[00676] • The only data to show on the [00677] 2.3.6. Trouble Tickets on Dashboard

[00678] This task is very similar to the previous one. The dashboard needs to show a list of trouble tickets entered against a given Appliance. To get that information you need to call VSAWebServicesClient.GetTicketList, which is documented here:

[00679] http://help.kaseya.com/WebHelp/en-US/5000000/3466.htm

[00680] The result provides the following information:

[00681] TicketID int unique trouble ticket ID number

[00682] Machine GroupID string A concatenated representation of the machine id and the group id it is associated with.

[00683] agentGuid decimal A globally unique identifier for a machine

ID. group ID account and its corresponding agent.

[00684] TicketSummary string summary string briefly describing the ticket

[00685]

[00686] The only thing you need to show on the dashboard is the TicketID and the TicketSummary. As in previous tasks, you need to filter the list result for the agentGuid that corresponds to the Appliance you are displaying.

[00687] 2.3.7. Automated Login

[00688] In order to do anything with Kaseya, a user has to be logged in.

[00689] • Use JavaScript to open an undisplayed browser window in the background and drive the login through JavaScript. You would have to go to https://ks. doyenz.com/ and then fill in the form fields and submit the form.

[00690] • Alternatively, you could just capture the login form submitted from the login page and issue a similar HTTPS request to the Kaseya server. However, that has to be done from the browser context, probably with JavaScript.

[00691] • Once the browser is logged in, the only thing you have to watch for is timeout. You should have some kind of heart beat the checks the login every few minutes. Either that or go to the home page each time you need to do something with kasey and detect whether you got the home page or the login page. If you get the login page, login again.

[00692] 3. Longer Term Integration

[00693] 3.1. Kaseya Server: Doyenz vs. Rinksys

[00694] It is recommended that Doyenz run its own Kaseya Server within its data center rather than utilize the Rinksys Kaseya Server. This is recommended because:

[00695] • Rinksys probably won't allow us to customize the GUI interface to our own specifications as it would affect their other users.

[00696] • Using the Web Services API over the WAN, while technically possible, will lead to a poor user experience for Doyenz customers. The WS API is somewhat chatty and multiple round trips per page view (e.g. dashboard) might be required leading to many second page loads. Furthermore, this is bandwidth that both Rinksys and Doyenz would have to pay for and will scale with the number of end clients accessing the system.

[00697] • Accessing the Database Views will likely be impossible. Doing distributed secured SQL queries over the WAN is not easy and suffers from the same kind of performance and bandwidth issues as the WS API. Furthermore, it is unlikely that Rinksys would open the port to all their customer data because of the security implications.

[00698] Using our own Kaseya Server would not have any of the preceding issues, but:

[00699] • Rinksys could still manage all our customers by simply logging in to our server instead of their own.

[00700] • It may still be possible to have Rinksys completely manage our Kaseya Server remotely.

[00701] • 3.2. Account Integration [00702] Kaseya has its own database of accounts, machine IDs and group IDs. These need to be synchronized with the Doyenz database. To do the integration, the Kaseya web application will need to be automated. Here's what you need to do:

[00703] 3.2.1. Create Partner Machine Group ID

[00704] Each Partner (VAR) gets a new Group ID. This is simply an alphanumeric name for the Partner. For example, "TSGTechs" or "ISOutsource". With this group, the Partner will be able to get summaries and reports for all the monitored machines for all his clients.

[00705] To create a new Partner Group ID, you need to automate the following:

[00706] • Log in to http://ks. doyenz. internal/ as the Doyenz Master Administrator

[00707] • Click on the "System" link in the navigation toolbar at the top. This takes you to http://ks. doyenz. internal/SystemTab/mainSystem. asp

[00708] • Click on the "Create/Delete" link under "Machine Groups". Unfortunately, the URL does not change or you could have gone there directly.

[00709] • Fill in the text box with the name of the Partner

[00710] • Make sure "<New Root Group>" is selected in the drop down.

[00711] • Push the "Create" button.

[00712] • Wait (can talk 20 seconds)

[00714] 3.2.2. Create Client Machine Group ID

[00715] Each Client gets a new Group ID as well. These are subgroups under the Partner group ID. So, if TSG Techs had a client named Spencer Law Firm, the group for Spencer Law would be: "TSGTechs.SpencerLaw".

[00716] To create a new Client Group ID, you need to automate the following:

[00717] • Log in to http://ks.doyenz. internal/ as the Doyenz Master Administrator

[00718] • Click on the "System" link in the navigation toolbar at the top. This takes you to http://ks. doyenz. internal/SystemTab/mainSystem. asp

[00719] • Click on the "Create/Delete" link under "Machine Groups". Unfortunately, the URL does not change or you could have gone there directly.

[00720] • Fill in the text box with the name of the Client (e.g. "Spencer Law")

[00721] • Make sure Partner's group ID is selected in the drop down list (e.g. "TSGTechs")

[00722] • Push the "Create" button.

[00723] • Wait (can talk 20 seconds)

[00724] 3.2.3. Create Admin Role [00725] Doyenz users can access a certain group of Clients associated with their Partner. In Kaseya, we need to define an "Admin Role" to represent the group of Clients that can be accessed. The form below needs to be automated.

[00726]

[00727] 3.2.4. Admin Role Group Access

[00728] Once an admin role is created, you need to specify the Machine Group IDs to which that role has access. This is how the set of clients associated with the role is specified. The form below needs to be automated.

[00729]

[00730] 3.2.5. Create Admin Account [00731] Finally, for each user that can administer a set of clients, a Kaseya Admin account needs to be created. The form below needs to be automated. Note that the Admin Role (drop down list) is associated with the user in this form.

[00733] 3.3. Agent Installation

[00734] Whenever a new VM image is produced by Doyenz it should be equipped with the Kaseya Agent for monitoring. In order for the Agent to report data correctly back to the Kaseya Server, the Agent needs to be configured with various pieces of information:

[00735] • GroupID - A valid group ID previously configured in Kaseya Server. For example, all our internal servers would use "doyenz. internal" which demo images would use "doyenz. demo". The GroupID for a given customer would have two parts: VAR name and CLIENT name. So, for example, TSGTechs has a client named Spencer Law. The Group ID for any machines at Spencer Law would be: "TSGTechs. SpencerLaw"

[00736] • MachineID - This identifies the specific machine. Generally it is the name of the computer but we probably want to append the VM Image GUID to this for identification purposes. The name can contain alphanumeric characters and dot (period).

[00737] To install the agent in a VM, do this: [00738] 1. Make sure the GroupID you are going to use already exists. Group IDs are created through the Kaseya web application at this URL: http://ks.doyenz.internal/SystemTab/mainSystem.asp.

[00739] They only need to be set up once per client.

[00740] 2. Obtain the generic Agent code from this URL: http://ks.doyenz.internal/dl.asp?id=-l

[00741] That page has a link that will download the KcsAgent.exe file. Probably the VM generator code just needs to cache this file somewhere. It doesn't change much/often (only when the Kaseya software is updated).

[00742] 3. Place the KcsAgent.exe file into the VM image (mount as cdrom or download it)

[00743] 4. Execute the KcsAgent.exe inside the VM image from the Windows command line, with these options:

[00744] a. /b - Reboot the system after installation completes. Agent installation requires a reboot in order to load its drivers. Use this switch on packages given to users that do not have rights to shut down the computer.

[00745] b. /g=xxx - Specifies the group ID to use for the new account, xxx must be an alpha-numeric string and cannot contain spaces or punctuation marks. This should be the group previously set up, e.g. "TSGTechs.SpencerLaw"

[00746] c. /m=xxx - Specifies the machine ID to use for the new account, xxx must be an alpha-numeric string and cannot contain spaces or any punctuation marks except periodQ. Set this to the GUID of the VM image.

[00747] d. /p "install_path" - Overrides the default installation path by specifying the full directory path, including drive letter, in which to install the agent. By default, the agent installation creates a directory named Program Files\Kaseya\Agent off the root of the drive on which Windows is installed. [00748] e. /r - Executes the installation program and reinstalls the agent even if an agent is already on the machine.

[00749] f. /s - Runs in silent mode. Suppresses all dialog boxes.

[00750] g. /w - Overwrites the existing configuration file with a configuration file included in the agent installation. Use with the /r switch to re-install an agent with new server settings. Intended for an existing agent that is attempting to connect to a server that no longer exists.

[00751] h. /x - Disables remote control after successfully installing the agent. This option is ignored when updating or re-installing. Remote control of this machine can only occur after the user selects Enable Remote Control by right clicking the K icon on the system tray. This is done for security reasons. The end-user must explicitly enable remote control from the system tray.

[00752] So, for example, you might invoke it like this:

[00753] KcsSetup.exe /g=TSGTechs.SpencerLaw /m= Server 01. GUID /b /r /s /w /x /p "C:\Doyenz\KaseyaAgent"

[00754] Once the above command is executed, the Kaseya Agent is installed and will begin reporting status to the Kaseya Server. Note that a reboot is required to load drivers. If you don't want the installer to force a reboot, leave the /b option off but make sure the reboot does happen.

[00755] 3.4. GUI Integration

[00756] The Kaseya GUI is mostly customizable. Styles, icons, images, fonts etc. can be changed. Consequently, it is possible to make the Kaseya web site look much like our own. You can access the customization here:

[00757] https://ks.doyenz.com/SystemTab/changeLook.asp?YVal=0

[00758] With this ability, it should be possible to link various functions from the web application directly to the Kaseya pages and the site would look Doyenz branded. It is also possible to save various settings as multiple themes so we could have one for Rinksys and one for our customers.

[00759] You can change these things:

[00760] • Current Theme

[00761] • Pixel height of the top frame header

[00762] • Top Frame Header Body Style

[00763] • Inactive tab background style

[00764] • Active tab background style

[00765] • Hover tab background style

[00766] • Inactive tab text style

[00767] • Active tab text style

[00768] • Logoff link style

[00769] • Logoff link hover style

[00770] • Toolbox Background Color

[00771] • Toolbox Text Color

[00772] • Toolbox Text Hover Color

[00773] • Main Login / Select Machine ID and Machine Group Body Style

[00774] • Select Machine ID and Machine Group Text Style

[00775] • Pixel width of the function list frame

[00776] • Function List Header Style

[00777] • Function Category Header Style

[00778] • Function List Hover Style

[00779] • Function List Active Selection Style

[00780] • Function List Inactive Selection Style

[00781] • Function List Background Color

[00782] • Function List Frame Color [00783] • Function List Hilite Color

[00784] • URL that the logo links to.

[00785] • Header HTML shown on all reports

[00786] • HTML displayed on Agent download page.

[00787] • Product Title

[00788] • Nav Menu Bullet Icon

[00789] • Corporate logo image

[00790] • Agent system tray icon when Agent is online (must be .ico format)

[00791] • Agent system tray icon when Agent is offline (must be .ico format)

[00792] • Agent system tray icon when Agent is blinking (must be .ico format)

[00793] • Agent system tray icon when remote control is disabled (must be .ico format)

[00794] 3.5. Web Services Integration

[00795] To extract information from Kaseya for display on the Doyenz web site, you will need to use the VSA WS API that Kaseya provides. This API can only retrieve information from the Kaseya database for display on our web site. The information retrieved pertains to: machine details, trouble tickets, and monitoring events.

[00796] For technical documentation, please see:

[00797] http ://help . kaseya. com/WebHelp/en- US/5000000/index. htm?toc. htm?2113. htm

[00798] You can get a description of the complete list of VSA WS calls here:

[00799] http ://ks. doyenz. internal/vsaWS/KaseyaWS . asmx

[00800] You can get the WSDL here:

[00801] http ://ks. doyenz. internal/vsaWS/KaseyaWS. asmx? WSDL

[00802] Integration of the VSA WS API will require several things: [00803] • Creation of a C# module to provide an interface to the VSA WS API calls. Visual Studio can create this automatically from the WDSL file (enter the URL above into the wizard).

[00804] • Use of the C# module in various places in the Doyenz web application to access information from Kaseya, to wit:

[00805] o List of Trouble Tickets for a Machine Group ID

[00806] o Trouble Ticket details for a specific trouble ticket

[00807] o List of Events/ Alarms for a Machine Group ID

[00808] o Event/ Alarm details for a specific Event/ Alarm

[00809] o List of all machines within a Machine Group ID.

[00810]

[00811] 3.6. Database Integration

[00812] An alternative and somewhat more detailed way to access information from Kaseya is through a set of pre-defined database views. Complete documentation on this is found here:

[00813] http://help.kaseya.com/WebHelp/en- US/5000000/index.htm?toc.htm?493.htm

[00814] This functionality must be enabled in the System->Configuration page before it works. You also have to specify a password for the "Kaseya Views" user. I have set up that user on ks. doyenz. internal to have the password "Kaseya Views".

[00815] With these views, you can get much more detailed information about the machines including a complete hardware and software inventory, patch status, various execution/alert/backup/configuration logs, and the list of alarms of various types.

[00816] 3.7. Systems Management Integration

[00817] Kaseya has a number of pre-defined scripts that can be used to perform routine maintenance and management of a system remotely and automatically. [00818] 4.1. Configuration Parameters

[00819] The configuration of Devil Linux to make a fenced network requires several pieces of information based on the customer's environment. These parameters are used in various configuration files.

[00820] Name Type Description

[00821] ServeDHCP Boolean Whether or not the DL appliance serves DHCP or not

[00822] ServeDNS Boolean Whether or not the DL appliance serves DNS or not

[00823] RouterIP IP4 Address Address of the router on the public network (should be *. l)

[00824] NetMask Net Mask Network Mask of customer network (should be 255.255.255.0)

[00825] Broadcasts IP4 Address Broadcast address for network (should be *.255)

[00826] DefaultRouteIP IP4 Address Address to which non-local outbound IP packets should be forwarded (address of the gateway on Doyenz network).

[00827] LocalIP IP4 Address The address of the router on the local network.

[00828]

[00829] 4.2. Creating Floppy Image

[00830] A floppy image containing the Devil Linux configuration is required to be mounted in a virtual floppy drive in ESXi. Configuring Devil Linux consists of modifying configuration files in the /etc folder, making a bzip2 compressed tar file from the /etc directory and then copying that file to a floppy image.

[00831] The image can be created on OpenSolaris using the following commands:

[00832] mkfile 1474560 /tmp/DLconfig.flp # Create a floppy sized file [00833] lofiadm -a /tmp/DLconfig.flp /dev/lofi/1 # Turn the file into a block device with loopback driver

[00834] mkfs -F pcfs -o nofdisk /dev/rlofi/1 # Make a DOS file system on the raw device (note: rlofi)

[00835] mount -F pcfs /dev/lofi/1 /mnt # Mount the floppy image to make it read/writeable on Unix

[00836] # Now you can modify files in /mnt

[00837] umount /mnt # Unmount when done

[00838] lofiadm -d /dev/lofi/1 # Disassociate DLconfig.flp with loopback device

[00839]

[00840] Some notes about the above procedure:

[00841] • /tmp/DLconfig.flp is presumed to be the image file. This is what you would mount into ESXi as the floppy image.

[00842] • If you have an existing floppy image, you don't issue the mkfile command

[00843] • You can have numerous loopback devices, created on the fly by lofiadm. In the example above, we used /dev/lofi/1 but it could be /dev/lofi/{anyNumber}

[00844] • Note that if you specify the lofi device to lofiadm you have to also guarantee it is not already in use.

[00845] • Important: the mkfs command requires the RAW device so it is /dev/rlofi/... not /dev/lofi/...

[00846] • We should just write some control around managing the /dev/lofi/n devices. When the service starts it should do: "Is /dev/lofi" and then "lofiadm -d" any devices it finds so we always start with an empty set of devices.

[00847] [00848] 4.3. General System Configuration

[00849]

[00850] 4.4. Configuring NIC Cards

[00851] The virtual NIC cards need to be configured in the /etc/sysconfig/nic directory, as follows:

[00852] 4.4.1. /etc/sysconfig/nic/ifcfg-ethO

[00853] This NIC (ethO) should be attached to the physical NIC on the ESXi server. This one serves the external network.

[00854] DEVICE=eth0

[00855] >

[00856] MODULE="p80211 "

[00857] DHCP=no

[00858] IP="RouterIP"

[00859] NETMASK="NetMask"

[00860] BROADCAST="BroadcastIP"

[00861] ROUTE="$ROUTE default/0.0.0.0:DefaultRouteIP"

[00862]

[00863] 4.4.2. /etc/sysconfig/nic/ifcfg-ethl

[00864] This NIC (ethl) should be attached to the virtual NIC on the ESXi server. This one serves the internal network.

[00865] DEVICE=ethl

[00866] >

[00867] MODULE="p80211 "

[00868] DHCP=ServeDHCP # "yes" or "no"

[00869] IP=192.168.1.254

[00870] NETMASK="255.255.255.0" [00871] BRO ADCAST=" 192.168.1.255"

[00872] After talking to 50+ IT consultants, we have learned that these are the things that you do every day. Sound right?

[00873] You know your business way better than I do. I am not here to talk to you about this.

[00874] And, I won't bore you with a better mouse trap.

[00875] I want to talk to you about a Break Through in IT for the SMB.

[00876] The break through is the Doyenz Automated Virtual IT out-of-the-box.

[00877] We believe that this technology will enable a Change in the IT Economy for the SMB.

[00878]

[00879] Let us talk about how you can take your successful business and grow and scale it. How acquire more customers, make your customers happier and increase your profitability AND do all this without becoming a large firm.

[00880] You folks have built a great business by leveraging your knowledge, your skills and your customer relationships.

[00881] But there are changes in the Climate for the IT for the SMB

[00882]

[00883] The economy is shaky, how do you compete in that?

[00884]

[00885] How do you leverage the accelerating trend towards hosting & managed services?

[00886]

[00887] How do you leverage SaaS instead of losing more customers to it?

[00888]

[00889] How do you do SBS 2008 Migrations and Upgrades faster and better than everyone else? [00890]

[00891] This change in the climate will cause a change in the IT Economy for the SMB

[00892] There is a wave coming. A wave of virtualization, automation, hosting, SaaS and Managed Services

[00893] This will change the economics of IT for the SMB.

[00894] Today, we will talk about the happy path, where you catch this wave and put these technologies to work for you.

[00895]

[00896] This way, you:

[00897] - are in control

[00898] - are selling the value you provide and not your time

[00899] - have a competitive advantage

[00900] And you end up with more customers, happier customers and higher profits

[00901] Doyenz does not know or talk to your clients.

[00902] Doyenz has designed this solution for you. So that you can leverage your experience and customer relationships and offer your customers the same level of service as the big VARS, without becoming a big VAR.

[00903] By using our solution, you get efficiency and economies

[00904] The technology that enables all this is the Doyenz Virtual IT Platform. This technology starts with a layer of virtualization called the Hyper Visor. This runs on the bare metal and is free. It comes from VMWare and Microsoft and is robust proven technology that has been running in data centers for years. Doyenz Virtual IT Platform creates Virtual Machines that can be deployed and managed on this platform. These virtual machines can either run on customers premises or hosted in the cloud.

[00905] [00906] The Doyenz Virtual IT Platform runs in the cloud and is connected to the Doyenz Virtual Machines over the internet.

[00907] This IT Platform provides 4 key capabilities

[00908] - Automatic generation and deployment of virtual machines

[00909] - A Virtual test lab in the cloud with an up-to-date copy of the virtual machine

[00910] - Efficient monitoring and management

[00911] - Local backup/recover and fail-over in case of a failure, or disaster recovery in case of catastrophe

[00912]

[00913] On top of this platform, we build modules that makes that implement this technology for Microsoft Server Products. We start with SBS 2003 and then add support for SBS 08, Windows 08, and EBS 08.

[00914]

[00915] Finally, you access all of this through the Doyenz Life-cycle Management Portal.

[00916]

[00917] This is powerful and game changing because we provide the total solution. This is not just a better mouse-trap.

[00918] Doyenz Virtual IT support is not for any one task that you do, it is for the entire life-cycle.

[00919]

[00920] You can start with a newly created virtual machine or you can import an existing one.

[00921] [00922] And then you can go through this entire life-cycle using the Doyenz Portal, that you can access from anywhere.

[00923]

[00924] You can now service far away customers,

[00925] you can service remote branch offices,

[00926] you can service customers in your pajamas from your kitchen on Friday night without needing to be on premise.

[00927]

[00928] And, once you do this, the majority of your customer's infrastructure starts to look very similar.

[00929]

[00930] You can now scale your business by providing your customer with a solution that is more predictable, reliable, manageable, flexible.

[00931] The Adoption of the Doyenz Technology is driven by three key factors:

[00932]

[00933] Server Replacement or Rebuild

[00934] Critical customer needs like Hosting, Rapid DR, 24x7 support are not being met

[00935] New Installs and Migration - SBS 2008

[00936] According to an embodiment, the computer system gets as its input a list of states, where each state uniquely defines an element (e.g., window, form dialogue, etc.) on a screen. Each state has associated therewith operations to be performed when that state is encountered. The system continuously analyzes all elements on a computer screen in an attempt to match those elements against known input states. When a known state is encountered, the system performs as an input the steps associated with that state.

[00937] Traditional functional automation systems are built to perform a sequence of automation tasks, where each step of a sequence is usually comprised of finding an element on which the system is about to act, then performing a predefined action and then proceeding to next step of the sequence.

[00938]

[00939] The traditional approach is generally fragile to interference, whether from a human, other software executing on the computer or an inconsistency/interruption in system's behavior.

[00940]

[00941] For example consider a sequence:

[00942] 1. Find a button named "Next"

[00943] 2. Click on it. (Next button will be replaced with OK button)

[00944] 3. Find a button named "OK"

[00945] 4. Click on it.

[00946]

[00947] In such scenario, if a human intervenes before automation has performed action #1 and clicks on the "Next" button himself, the whole automation is now unable to execute, since it's sequence was broken, and it can no longer find the "Next" button.

[00948] [00949] The system according to an embodiment uses a different approach to functional automation.

[00950] Instead of treating the automation as a sequence of steps, it treats the task of automation similar to what a human would do, by monitoring the state of the user interface, and responding to what it finds based on recognized patterns.

[00951]

[00952] Computer user interface is comprised of variety of UI elements organized in a tree like structure (e.g a window may open a dialog, in which case window is a parent of dialog).

[00953]

[00954] Terminal nodes on such a tree would therefore comprise a recognizable and unique state of a given user interface.

[00955]

[00956] The system gets as its input a list of such states, where each state uniquely defines an element on a screen complex enough to be uniquely identified (e.g., window, form, dialogue, etc.) whether by its placement in element tree hierarchy or by other means (e.g. elements it itself is comprised of, its attributes etc.).

[00957]

[00958] Each state has associated therewith operations to be performed when that state is encountered. The system continuously analyzes all elements on a computer screen in an attempt to match those elements against known input states. When a known state is encountered, the system performs as an input the steps associated with that state.

[00959]

[00960] Such approach is inherently unsusceptible to external interference and is therefore more robust. [00961] During my involvement with the customer deployment exercise, it is clear to me that there are a few things we will need to automate in order to scale our business. I am going to make an attempt to describe some of these scenarios. These are not priorities or implementation recommendations, but just my early thoughts coming from the engagements.

[00962] 1. Customer environment compatibility: In order for partner to be able to deploy our solution at a customer environment, they need quick way to find out if their customer's current environment will work with our solution. If not, they will need to know what changes to make or what new hardware to get. The current process involving questionnaires is too cumbersome and it is unlikely they will provide enough information to us in a timely fashion. In my opinion, there are three broad categories of information we need to gather quickly about their customer's environment: (a) hardware configuration and its compatibility with ESXi (or HyperV in future) and other parts of our solution, (b) the software configuration and its ability to run on a virtualized platform, and (c) the internet connectivity and their ability to support what we need. Let me describe each one in more detail:

[00963] a. It should not be too difficult for us to extract the current formal and informal HCL for ESXi from the myriad of information available on the internet, and put it into some sort of a database. We can build a simple App that the partner can download to their existing server environment. This App can interrogate their current hardware configuration (via WMI and other interfaces) and software configuration (via registry etc) and upload it to our website. Here an application can check that information against the HCL and the list of Apps and configurations known not to work with virtualization. We can then prepare a report for a partner that shows their current configuration with check marks against items likely to work with our Virtual IT environment. Based on our best practices, we can also provide a list of proposed modifications (like add X GB of memory, don't attach a serial port printer to the server) in order for the environment to work well. The partner can review this information and quickly decide if this will work for a specific customer and call our support number if they need clarifications. This tool will also need to have a manual mode in case if the partner has all the information and is willing to fill out a form, instead of running an app on the customer's environment.

[00964] b. Once they have satisfied themselves that the environment is ready, they can download another bootable app from Doyenz that will wrap around the ESXi installer and drive it till the last step before it makes any changes to the underlying system (i.e., formatting, installation, etc). If this is not possible, this can be done via a combination of manual instructions, lots of warnings, and disclaimers. This step will verify that ESXi is very likely to work on their platform. If for some reason networking does not work, they may need to upgrade their network card with an Intel one.

[00965] c. The first app we downloaded can also run a quick internet speed test and check out firewall configurations to determine the customer has enough bandwidth to support (i) downloads over the web, (ii) our disaster recovery solution and its integration into our cloud based services, and (iii) the appropriate ports are open in order to make sure that all our solutions will work. We can also check for licensing and data size issues that will be needed for the new server.

[00966] At the end of this, the partner will have a really good idea if our solution will work for their customer or not, without using up a lot of time from our consulting/customer support team.

[00967] 2. Deployment Automation: (a) after creating the SBS VM, use Shadow Protect to do a full backup of that image which turned out to be around 3.5 GB of compressed data, (b) use the VM Ware Virtual Infrastructure tool to create all the empty VMDKs we need on the customer's ESXi disk, (c) push the Shadow Protect recovery disk ISO image to the ESXi data store, attach it to the CD drive of the VM, and boot the VM into the recovery environment, (d) use Shadow Protect to pull down the back up data from step (a) and populate the VMDKs. We need to find a way to automate this process, or something similar to it. Based on my understanding of the Web Services API used by the VM Ware Infrastructure tools and the APIs that I think Shadow Protect offers, we should be able to automate this. Also note that in order for this to work, either the ESXi machine will need to be directly accessible from the internet, or the automation will need to run from a computer on the same LAN on which the ESXi machine resides, with a partner controlling this on site or via a Remote Desktop.

[00968] 3. A framework for automating migration: Automating this task is likely to be a key part of our value proposition in the future. So, instead of building a tool, I think we should think about build a framework that supports migration. The framework is essentially is work flow engine where a consultant can define a sequence of tasks that are needed for migration. Each task can be either a manual step, or is automated via some sort of automation script. The consultant can define new tasks, or use tasks from a library of predefined tasks that have been defined earlier by other consultants. One way of creating these tasks may be to install recording engines (like those existing in testing tools record/playback engines) on server and workstation consoles and record all the actions that the consultant takes. The consultant can then take this recording and mark sections of it that are generic steps that can be automated, the steps that were customer specific that need to be parameterized with specific data, or done manually.

[00969]

[00970] There are also library of migration templates that have been defined by consultants that correspond to specific environments. For example, there could be a template for migrating from 5 XP desktops (with office 2003) + 1 Win98 desktop (with office 98) + 1 Win2k server to 6 XP desktops (with office 2007) + 1 Win 2k3 SBS server. These template are stored in a database annotated with a bunch of environment information so the consultants and easily search and find a suitable one. The consultant can take this template, modify it to fit their needs and then run them. The automated steps will send commands to agents running on different machines to make it do the desired steps and then report back the results. The consultant will monitor the step by step execution and look at the log files and results. In a manual step, the consultant will be prompted to do steps like "disconnect printer X from server Y", and the system will wait until the consultant has finished executing the task manually.

[00971]

[00972] This approach recognizes the following facts: (a) each migration can be potentially unique and we are likely to need a consultant to define the plan for each migration, (b) each migration will have some combination of automated and manual steps, (c) providing migration plans and high level manual instructions has value for consultants today, (d) the automation of migration can be accomplished both at the level of tasks and plans, (e) while we will not have a complete solution on day 1, and over time this framework provides a way for consultant to contribute migration approaches so we can automate larger and larger percentages of these tasks and plans, and finally (f) this is a real need today and helping consultants even with a very basic tool is likely to be quite helpful.

[00973] Scaling the IT Consultant's Business

[00974] Doyenz enables partners to deliver revolutionary automated and virtualized IT out-of-the-box for small and medium businesses. Partners of any size can now remotely install, configure, and manage their client's Windows Server IT infrastructure without the traditional expense or downtime to the client. The service is geared for the partners to support the SMB with no long-term contracts, affordable pricing, no hardware requirements, and leveraging your existing Microsoft expertise has you supporting clients in just a few minutes.

[00975] Automated Deployment - Migration

[00976] Partners can create a virtual machine in minutes using our service and ensuring that that virtual machine is created following standard best practices. This is all done remotely and removes time consuming installations at the customer site that can be ruined with a single incorrect entry. Migrating your customers from SBS 2003 to SBS 2008 has never been easier and more profitable than partners using Doyenz.

[00977] Virtual Test Lab

[00978] Partners can access a test lab in the cloud to ensure that any changes that need to be made to the client's server will work before deploying into production. No more worries about whether a service pack or changing group policies will create hours of downtime and unexpected bills for your client. All of these tests can be done remotely and when you have time to test, not just Friday night at the client's office.

[00979] Disaster Recovery - Local Failover

[00980] Doyenz offers a local failover that is backed up every 15 minutes as well as true daily offsite disaster recovery. This is done automatically with no tape backups or manual labor needed from either the client or partner. The local failover can have a customer back up running in exactly the same state as before the outage in literally a few minutes. Finally affordable piece of mind for both you and your clients. [00981] Remote Monitoring & Management

[00982] Scaling your business is easier when servers are getting regular servicing and the mundane alerts are not cluttering up our in-box. Doyenz remote monitoring and management is more efficient and effective because we know everything about the servers by creating them with our automation engine. This increases reliability while reducing costs through enabling automated routing maintenance.

Claims

CLAIMThe embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A system comprising at least one computer-executable module configured to:

collect a specification of the end user's requirements that satisfies some purpose within a computing environment;

automatically translate the end user' s requirements into a configuration model of IT components, permitting this configuration model to be adjusted;

translate the configuration model into a functioning IT infrastructure whether physical or virtual;

automatically generate and execute an automated test harness, including at least test plans, test scripts, test functions, that validates the behavior of the constructed infrastructure against the end user's requirements, such a test harness validates behavior that includes, but may not be limited to functional, performance, capacity, scalability and security factors, analyzing the results to determine suitability of the appliance for deployment;

once validated, automatically distribute the constructed infrastructure to the end user's chosen computing environment whether physical or virtual, and whether hosted, purchased or existing, once distributed, deploy the constructed infrastructure to the chosen computing environment, making it ready for execution, once deployed, provision the infrastructure for execution within the context of the computing infrastructure upon which it may be deployed;

capture measurements from the executing infrastructure to measure functional health, performance, capacity, security, automatically reviewing measurements captured from the executing infrastructure, analyze the meaning of those measurements to determine if corrective actions need to be taken and either automatically take those actions or notify the infrastructure's owners/operators of the recommended corrective action;

provide command and control capability to start, stop, pause, customize, re-configure, optimize, resize, scale, migrate, consolidate, replicate, backup, recover, load balance or otherwise manage the execution and operation of the infrastructure;

automatically apply patches, updates, version upgrades, optional functional, components, internationalization and localization components or any other changes that affect the behavior of the executing infrastructure, apply such changes in a verified manner such changes may not compromise the original end user's requirements but only extend the functional capability of the executing infrastructure;

automatically capture, transmit and store point-in-time copies, shadow copies, alternate configurations, of the executing infrastructure for archive, backup, recovery, fail- over or other operational readiness concerns; and

automatically document the requirements, specifications, configuration, options manifest, test results, operational history, change history, event history and all other aspects of the infrastructure from the point of construction to the end of its operational lifetime.