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)
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.
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:
Work in progress (WIP)
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.
Apps are packaged with AppsAnywhere default configuration as standard, according to AppsAnywhere Packaging Service 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.
Once packaged, appsets are provided in STP format, ready-to-deploy through AppsAnywhere.
Please note: An additional cost may apply if an app needs to be (re)packaged to work in a specific Windows environment.
Projects, including the Project Name and project files, should be named as per this convention:
All spaces in the filename are to be replaced with underscores.
The commonly used title of the application, including any major strand. e.g. Filezilla, Stata_MP4, Dreamweaver_CC, or Endnote_X.
The application version number. Replace dots with hyphens. e.g. 14-1, 22-0-0-0 or 2014a.
Application architecture. Either 32bit or 64bit.
Supported OS architecture:
Identifies the type of application license included in the appset:
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.
Language of the application.
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:
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:
Uninstall registry keys will be set to layer 4
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)
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.
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.