Skip to main content
Skip table of contents

App Request SLA

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:

Title1_Version2_Architecture3_Platform4_License5_Other6_Language7_Release8

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

1

Title

The commonly used title of the application, including any major strand. e.g. Filezilla, Stata_MP4, Dreamweaver_CC, or Endnote_X.

2

Version

The application version number. Replace dots with hyphens. e.g. 14-1, 22-0-0-0 or 2014a.

3

Architecture

Application architecture. Either 32bit or 64bit.

4

Platform

Supported OS architecture:

  • x86 – Only works on 32-bit OS

  • x64 – Only works on 64-bit OS

  • x86_x64 – Works on 32-bit and 64-bit OS

5

License

Identifies the type of application license included in the appset:

  • Local– license key or license file is included in the appset

  • Server– a network license server is configured to be used

  • Online– internet required for license activation (i.e. remote license server)

  • NLR– No License Required. Application doesn’t require license activation

6

Other

Optionally included to distinguish between .stp files if required. For example, multiple versions of the same app may exist but with different department licenses, e.g. Engineering or Computing.

7

Language

Language of the application.

8

Release

Release version of the final appset in the format rel1, rel2. Must be incremented when an appset is altered e.g. to fix an issue with rel1.

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:

ProgramData

ProgramFilesX64

ProgramFilesX86

SystemDir

SystemX86Dir

WindowsDir

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:

AppData

UserAdminTools

UserCDBurning

UserContacts

UsersCookies

UserDesktop

UserDocuments

UserDownloads

UserDownloads

UserFavorites

UserGameTasks

UserGameTasks

UserHistory

UserHistory

UserInternetCache

UserInternetCache

UserLinksDir

UserLocalAppDataLow

UserMusic

UserNetworkShortcuts

UserOriginalImages

UserPhotoAlbums

UserPictures

UserPinned

UserPrinterShortcuts

UserProfile

UserProfiles

UserQuickLaunch

UserRecent

UserSavedGames

UserSearches

UserSendTo

UserStartMenu

UserStartup

UserTemplates

UserVideos

VideosLibrary

 

 

 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

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.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.