App Request SLA

Overview

This article sets out the Service Level Agreement (SLA) and standards that AppsAnywhere recommends and follows when packaging applications for Menu Apps and Bespoke Requests.

• Apps Requests are not included in the Support SLA, and follow the conventions listed on this page.

• Access is only permitted for approved users and is configured during customer onboarding.

• New users must be requested by a user within the organization that has access to AppsAnywhere Support.

Service Level Agreement (SLA)

• All applications are developed using the latest releases of Cloudpaging Studio and Player.

• Applications are captured on a Windows 64-bit operating system (unless the application is incompatible with this platform).

• Compatibility is targeted to minimum versions Windows 10 and Windows Server 2016.

• Future versions of Windows and Windows Server OS are compatible, unless otherwise stated.

• The SLA delivery time for package requests is 30 business days.

• Business days are an accumulation of the standard working hours a request is open with AppsAnywhere Packaging.

• Time is paused while the request is pending with the requestor.

• AppsAnywhere reserves the right to reject packaging requests or to advise on alternative solutions.

• Packages are tested for vulnerabilities at the time of creation.

• Customers are responsible for ensuring packages provided meet and maintain their security requirements (see UAT and warranty for more information)

• Apps are packaged with AppsAnywhere default configuration as standard, according to AppsAnywhere conventions (below).

• All apps are packaged in English (either UK or US) language – if another language is required, this is classified as a bespoke request.

• Apps are packaged for deployment to Microsoft Windows 10, or Windows Server 2016 and above.

• An additional cost may apply if an app needs to be (re)packaged to work in a specific Windows environment.

• Once packaged, appsets are provided in STP format, ready-to-deploy through AppsAnywhere.

Opening Hours

The standard working hours for the service are:

• Monday - Friday | 9.00 - 17.30 (UK time)

With reduced or no coverage during bank holidays in England and Wales.

Outside standard working hours, customers can still submit requests via the Packaging Portal. These will be handled and prioritized during standard working hours.

Request Workflow

Requests are submitted via the AppsAnywhere Packaging Service using AppsAnywhere Support (Zendesk) login credentials.

Once a request has been submitted; it is managed as a ticket in AppsAnywhere Support.

The ticket is in the open status with AppsAnywhere whilst it is being worked on and pending with the customer when information is required.

The following tags will be added to the title of the ticket show the status of the request:

• Discovery

• Verified

• Work in progress (WIP)

• Done

Once the package has been provided, the ticket will be set to solved and will automatically close after 5 working days.

If remediation is required, the ticket can be reopened or a follow up ticket opened.

Media and licensing

AppsAnywhere does not provide any software licenses. It is the customer’s responsibility to provide installation media and valid license details to be included with each appset.

Please note: If access to a license server is required to install or configure an app, this must be provided by the customer. License servers must be contactable over the internet, or via a customer-provided VPN connection.

Packaging conventions

Appset Naming

Projects, including the Project Name and project files, should be named as per this convention:

Title¹_Version²_Architecture³_Platform⁴_License⁵_Other⁶_Language⁷_Release⁸

All spaces in the filename are to be replaced with underscores.

Examples of appset filenames:

• NVivo_11-3-2-7291_32bit_x86_Local_English_rel1.stp

• Atmel_Studio_7-0_32bit_x86_x64_Server_Engineering_Spanish_rel2.stp

• Unity_5-50f_64bit_x64_Online_Danish_rel1.stp

• Filezilla_3-24-0_32bit_x64_NLR_English_rel1.stp

Files and Folders

• All application shortcuts will be removed from the desktop and quick launch areas

• All shortcuts in the Start Menu that require elevation will be excluded (unless otherwise requested)

• Start Menu shortcuts will be placed in the All Users Start Menu location (Any shortcuts in the UserProfile location will be moved or excluded)

• All Uninstall shortcuts will be excluded

• Root folders will be set to Merged

• Files or folders that need to be installed to the local machine (e.g. service files or drivers) and which are not excluded, will be set to Layer 2:

Files and folders that are recreated in User Profile directories at runtime will not be included in the appset. Otherwise, they will be set to Layer 1 to ensure compatibility with redirected folders, and so that user data is preserved:

 Registry

• Uninstall registry keys will be set to layer 4

Environmental Variables

• Only variables required for the current app will be included in an appset

Services / Drivers

• Services will be configured to operate in the same way as the original installation (e.g. set to “Start” if the service is always running in the background)

Configurable AppEvents

• Compiled PowerShell, VBScript and Command scripts may be used as needed to ensure the correct licensing and execution of apps (using Configurable App Events)

• Applications that require Firewall rules will have those rules added by CAE’s at the After Registration trigger and removed at the Before Deactivation trigger

Command Line (Launch Command)

• The command line will always be set to the obvious choice i.e. the same as the main Start Menu shortcut, unless it is unclear which is the preferred executable.

• Should an application have multiple shortcuts and executables e.g. a software suite, the customer will be contacted for their preferred Launch Command.

Cloudifying

• Final Appsets will have Compression and Encryption set to the highest settings

• If an application is over 500MB in size, a capture prefetch will be included to improve responsiveness when the app is launched for the first time

• Unnecessary assets ('noise') will be removed from appsets in accordance with the AppsAnywhere Package Cleaning Guide article.

UAT and warranty

Each appset includes a 90-day warranty as standard. Any issues or changes raised after this time (e.g. addition of plug-ins, updates and security vulnerabilities) may incur a cost.

Any questions or issues should be raised with AppsAnywhere Support.