Tailored remote access applications

Abstract

Techniques for on-demand delivery (i.e., according to end-user needs) of remote access applications to servers are described. In several implementations, these techniques involve packaging the installed content (e.g., executable code and configuration data) of the remote access applications into containers called application packages, which are stored on shared storage, and dynamically attaching (i.e., activating) an application package to a server at the time an end user requests access to a remote access application within that package, thereby enabling the server to launch the application.

Description

Related registration

[0001] This application is based on US patent application No. 17 / 727,503, which was filed on April 22, 2022, the entire contents of which are incorporated herein by reference, and claims priority therefrom. background

[0002] Unless otherwise stated, the subject matter described in this section is not prior art within the meaning of the claims of the present application and is not recognized as prior art by its inclusion in this section.

[0003] Application remote access is a technique that allows software applications running on a central server to be streamed to and used / controlled from remote (i.e., client) end-user devices. These software applications are known as remote access applications. Existing solutions for deploying remote access applications in an enterprise or similar environment typically involve (1) defining numerous groups of servers, referred to as server farms, with each server farm dedicated to a user group within the enterprise with different application requirements, (2) creating a master software image for each server farm containing installations of the specific remote access applications relevant to that server farm's user group, and (3) deploying the server farms with their respective master software images.However, this approach leads to various challenges and administrative problems in server, image, and application management. Brief description of the drawings Fig. Figure 1 shows a typical application remote access environment. Fig. Figure 2 shows an application remote access environment that supports the on-demand delivery of remote access applications according to certain embodiments. Fig. Figure 3 shows a flowchart for packaging and granting releases of remote access applications according to certain embodiments. Fig. Figure 4 shows a flowchart for processing a remote access application access request according to certain embodiments. Detailed description

[0004] The following description includes numerous examples and details for explanatory purposes, to provide an understanding of different embodiments. However, it will be clear to a person skilled in the art that certain embodiments can also be implemented without some of these details, or with modifications or equivalents thereof. 1. Overview

[0005] Embodiments of the present disclosure relate to techniques for delivering remote access applications to servers on demand (i.e., according to the needs of the end users). In several embodiments, these techniques involve packaging the installed content (such as executable code and configuration data) of the remote access applications into containers called application packages, which are placed on shared storage, and dynamically attaching (i.e., activating) an application package to a server at the time an end user requests access to a remote access application in that package, thereby enabling the server to start the application.

[0006] With on-demand deployment, the installed content of remote access applications can be completely decoupled from the master software images loaded on the servers where these applications are deployed; that is, it can be stored and maintained independently. This, in turn, simplifies the management of servers, images, and applications and leads to further advantages, such as the elimination of downtime for remote access application updates. The aforementioned and other aspects are described in more detail below. 2. Typical application remote access environment

[0007] To clarify the context for the embodiments of the present disclosure, it shows Fig. 1 A typical application remote access environment 100 that can be implemented by an enterprise or other similar entity / organization. As shown, the application remote access environment 100 includes an application remote access management platform 102 that is communicatively coupled to a set of server farms 104(1)-(n). The application remote access management platform 102 is a software platform that enables administrators to install, organize, and manage the lifecycles of remote access applications within the application remote access environment 100. In several implementations, the application remote access management platform 102 can run on machines in a public cloud such as Microsoft Azure or Amazon AWS.In other embodiments, the Application Remote Access Management Platform 102 can be run on machines in a private cloud or in one or more on-premises data centers.

[0008] The server farms 104(1)-(n) consist of groups of servers 106(1)-(n) configured to run the remote access applications installed and managed via the application remote access management platform 102. Like the underlying hardware of the platform 102, the server farms 104(1)-(n) can be part of a public cloud, a private cloud, or one or more on-premises data centers. In certain embodiments, the servers 106(1)-(n) can be multi-session servers (for example, Remote Desktop Session (RDS) hosts or Windows 10 multi-session machines) capable of providing multiple concurrent user sessions for users of remote access applications.A "user session" or "session" is a temporal context (which usually begins when the user logs on and ends when the user logs off) within which an end user can launch and interact with a computer desktop and applications.

[0009] As in Fig. As shown in Figure 1, each server farm 104(i), for i = 1, ..., n, is assigned to a corresponding user group i, wherein a master software image 108(i) is loaded on the servers 106(i) of server farm 104(i). This master software image comprises the installations of the specific remote access applications 110(i) required by or relevant to this user group (in addition to the installations of an operating system (OS) 112 and an application remote access agent 114 for accessing remote access applications). For example, server farm 104(1) may be assigned to a development organization, and therefore a master software image 108(1) may be loaded on its servers 106(1). This master software image comprises installations of software development tools (e.g., compilers, source code editors, debuggers, etc.).As another example, server farm 104(2) can be assigned to a finance department, so that a master software image 108(2) can be loaded on its servers 106(2), which includes installations of financial applications (such as accounting, invoicing, etc.). In this way, the application remote access environment 100 can serve each user group of the company via its corresponding server farm and its own master software image.

[0010] For example, if an end user in user group j requests access to a remote access application required by that user group, the application remote access management platform 102 can redirect the end user's client device to one of the servers 106(j) in server farm 104(j), since the requested application is installed on these servers via the master software image 108(j). The application remote access agent running on the selected target server within server farm 104(j) can then start the remote access application and stream it to the end user's client device.

[0011] Unfortunately, while the Application Remote Access Environment 100 is functional and successfully meets the diverse application requirements of different user groups, it is also problematic for several reasons. For example, administrators of the Application Remote Access Environment 100 must accurately assess the appropriate size of each server farm (e.g., the number and capacity of servers) based on the anticipated application usage patterns of the various user groups to avoid server overload and / or underutilization. Furthermore, if the organization is large, administrators must create and manage a large number of server farms and corresponding master software images (potentially on the order of hundreds or more), which is cumbersome and time-consuming.Updating a remote access application in a specific server farm also requires terminating or redirecting all active user sessions in that farm to backup servers, as the server farm's master software image, which includes both the operating system and the applications, needs to be rebuilt and reloaded. This undesirably leads to downtime for all users in the farm or delays in the rollout of new application versions. 3. Solution architecture and overarching workflow

[0012] To address the above and other similar problems, shows Fig. 2 a novel application remote access environment 200 according to embodiments of the present disclosure, which makes it possible to decouple remote access applications (1) from the master software images loaded on the servers on which the applications are executed, and (2) deliver them to any server as needed in response to access requests from end users. As shown, the application remote access environment 200 includes, among other things, an improved application remote access management platform 202 and a single server pool 204 with servers 206(1)-(m) (instead of the numerous server farms 104(1)-(n) of Fig. 1) Each server 206 in server pool 204 can be a physical or virtual machine running a multi-session service or operating system. Furthermore, it shows Fig. 2 a higher-level workflow comprising steps (1)-(9) (reference numerals 250-266) that can be executed by the extended application remote access management platform 202 and the servers 206(1)-(n) to provision remote access applications in the environment 200 and to process a request from an end-user client device 208 to access a remote access application (i.e., to start and interact with it).

[0013] Starting with step (1) (reference 250), the extended application remote access management platform 202, under the direction of one or more administrators, can create and load a single master software image 210 on each server 206(i), for i = 1, ...m. This single master software image can include the installation of an OS 212, an application remote access agent 214, and an application delivery agent 216 (see below).

[0014] In step (2) (reference 252), the extended application remote access management platform 202, at the instruction of the administrator(s), can package the remote access applications for the environment 200 into one or more application packages 218 and place / store the application packages on shared storage 220 (which may include, for example, one or more networked storage servers or arrays) that the servers 206(1)-(m) can access. In certain embodiments, each application package may include a virtual disk file (for example, a VMDK or VHD file) and a metadata file (for example, a JavaScript Object Notation (JSON) file).The virtual floppy disk file can contain the installed content (e.g., executable program code / files and configuration data such as OS registry entries) of the remote access applications packed within it, while the metadata file can contain metadata attributes for these applications (e.g., application name, manufacturer, version, executable path, application identifier (ID), entry points, etc.).

[0015] Once the remote access applications are packaged as application packages 218 and stored on the shared storage 220, the enhanced remote application platform 202, under the direction of the administrator(s), can assign (or in other words, release) these remote access applications to the end users / user groups of the remote application environment 200 (step (3); reference 254). This release process allows administrators to enable each end user to view and launch their set of released remote access applications from their client device(s).

[0016] Turning to end-user request processing, an end user can log on to the client software running on the end-user client device 208 to access the remote access applications for which that end user is authorized. After launching a specific remote access application from the client software, the end-user client device 208 can send a request to the extended application remote access management platform 202 to access that remote access application. In response, the extended application remote access management platform 202 can identify a target server in server pool 204 to run the remote access application (for example, server 206(1) in Fig. 1) and initialize a user session 222 for the end user on the target server 206(1) (step (5); reference 258).

[0017] The enhanced remote application management platform 202 can then send a message to an instance of the remote application agent running within the user session 222 (i.e., the remote application agent 224) and include an application specification for the remote application (step (6); reference 260). This application specification can include, among other things, information that the target server 206(1) can use to locate the application package containing the remote application (for example, the application package ID) and to start the application (for example, the executable path).

[0018] In step (7) (reference 262), the application remote access agent 224 can receive the message and transmit the application specification to the application delivery agent running within the user session 222 (i.e., the application delivery agent 226). The application delivery agent 226 can then locate the application package in the shared memory 220 containing the remote access application, dynamically attach (or in other words, activate) the application package from the shared memory 220 to the target server 206(1), and start the remote access application within the user session 222 (steps (8) and (9); references 264 and 266).

[0019] Finally, the application remote access agent 224 can receive confirmation from the application delivery agent 226 that the remote access application has been successfully started, and can then project / stream the user interface of the started remote access application to the end-user client device 208 via a suitable remote access display protocol (such as Blast Extreme or PC over IP (PCoIP)), enabling the end user to interact with and use the application from the client device 208.

[0020] With the in Fig. The architecture and overall workflow shown in Figure 2 offer several advantages. First, since the application packages 218 – which comprise the installed content of the remote access applications in environment 200 – are managed on the shared storage 220, these remote access applications are, unlike environment 100, Fig. 1. Effectively decoupled from the master software images loaded on the servers configured to run them, this eliminates the need to create separate server farms, each containing its own software image with the specific remote access applications required by the end users of that farm. Instead, environment 200 administrators can simply create a single, "global" server pool (i.e., server pool 204) for all end users and a single master software image (i.e., image 210) loaded on every server in the pool. This eliminates the need for administrators to perform complex capacity planning for individual server farms (resulting in better overall server utilization and load balancing) and to manage the lifecycles of multiple server farms and multiple master software images (significantly reducing administrative overhead).

[0021] Secondly, when updating or patching a remote access application, administrators can update the application's installed content within its application package on shared storage 220 without affecting the master software image 210. This means that servers 206(1)-(n) can remain online throughout the update process, thus avoiding interruptions for end users and eliminating the cost and overhead of maintaining backup servers for user overflow / drainage purposes.

[0022] The remaining sections of this disclosure include additional details on executing the overall workflow of Fig. 2 according to various embodiments. It should be noted that Fig. Figure 2 is for illustrative purposes only and is not intended to limit the embodiments disclosed herein. For example, the various units shown in this drawing may be organized in different arrangements / configurations or may include subcomponents or functions not specifically described. A person skilled in the art will recognize other variations, modifications, and alternatives. 4. Application packaging and release

[0023] Fig. Figure 3 shows a flowchart 300 that describes in detail the processing performed by the extended application remote access management platform 202 for the installation / packaging of remote access applications into application packages and the release of the applications to end users (according to steps (3)-(5) of the overarching workflow in Fig. 2) can be implemented according to certain embodiments. Flowchart 300 assumes that the enhanced application remote access management platform 202 includes an administrative console that can be used by the administrators of the application remote access environment 200 to interact with the platform 202, an application inventory configured to contain information about installed / packaged remote access applications, and a portal service configured to perform application sharing and accept end-user access requests to applications.

[0024] Starting at block 302, the Enhanced Remote Access Application Management Platform 202 can receive a list of one or more remote access applications to be installed for use in environment 200 via the management console. The Enhanced Remote Access Application Management Platform 202 can then install / package the remote access applications into one or more application packages (block 304) and place the application packages on shared storage 220 (block 306). As mentioned earlier, each application package can include a virtual disk file containing the contents of the remote access applications installed within it, as well as a metadata file containing metadata attributes of the installed applications (such as the application package ID, application name, application ID, path to the executable application, application entry points, etc.).In several implementations, the Extended Application Remote Access Management Platform 202 can install / package each remote access application in its own application package. In other cases, the Extended Application Remote Access Management Platform 202 can group multiple remote access applications into a single application package based on one or more criteria (for example, application type, vendor, etc.).

[0025] In Block 308, the enhanced application remote access management platform 202 can include the metadata attributes for each remote access application installed via Block 306 in its application inventory and make this inventory available to the portal service.

[0026] The portal service can then receive a request via the management console to view the installed remote access applications for sharing purposes (Block 310) and return the details of the installed applications (Block 312).

[0027] In block 314, the portal service can receive one or more requests to release the remote access applications returned in block 312 to end users. Finally, in block 316, the portal service can create release records based on the received release requests and the metadata maintained in the application inventory. For example, in response to receiving a request to grant access to a remote access application A to an end user U, the portal service can create a release record that includes the ID / name of user U, the ID / name of application A, and other metadata about A (such as the ID of application package A, the path to the executable file, etc.). 5. Handling end-user requests

[0028] Fig. Figure 4 shows a flowchart 400 that details the processing performed by the extended application remote access management platform 202 and the target server 206(1) of server pool 204 for handling an application access request sent by an end-user client device 208 (according to steps (6)-(11) of the parent workflow of Fig. 2) can be implemented according to certain embodiments. Flowchart 400 assumes that a release data record according to flowchart 300 of Fig.3 was created, which authorizes the end user of device 208 for the requested remote access application. Furthermore, flowchart 400 assumes that the extended application remote access management platform 202 includes a connection service configured to manage the assignment / redirection of end users to servers in server pool 204.

[0029] Starting with blocks 402-406, the portal service of the Extended Application Remote Access Management Platform 202 can receive the application access request from the end-user client device 208, create a desktop specification for the end user and an application specification for the requested remote access application based on the share record, and forward the request (with the desktop and application specifications) to the platform 202's connection service. The desktop specification can include information that can be used to initialize a new user session for the end user on a server in server pool 204. The application specification can include information that can be used to identify the installation location of the remote access application (for example, the application package ID) and to start the application (for example, the path to the executable file).

[0030] In block 408, the connection service can select a target server in server pool 204 (i.e., server 206(1)) to host the remote access application. In certain embodiments, the connection service can make this selection based on one or more rules / criteria such as server load, availability, features, etc. The connection service can then initialize a user session for the end user on target server 206(1) (i.e., user session 222) (block 410) and send a message containing the application specification to the application remote access agent running within that user session (i.e., application remote access agent 224) (block 412).

[0031] In block 414, the application remote access agent 224 can receive the message, determine that the application specification contained therein relates to a remote access application installed in an application package, and can make the application specification available to the application delivery agent running within the user session 222 (i.e., the application delivery agent 226).

[0032] In response, the application delivery agent 226 can extract the application package ID contained in the application specification (block 416), identify the shared memory 220 as the storage location for this application package (block 418), and dynamically attach / activate the application package from the shared memory 220 to the server 206(1) (block 420). Within block 420, the application delivery agent 226 can also virtualize the file system of the remote access application so that the installed files and registry entries are visible / accessible in the user session 222.

[0033] After attaching / activating the application package, the application delivery agent 226 can start the remote access application via the activated application package using the executable path defined in the application specification (block 422) and send an acknowledgment back to the application remote access agent 224 indicating that the application started successfully (block 424). Finally, in block 426, the application remote access agent 224 can inform the end-user client device 208 that the remote access application has started and proceed with projecting / streaming the application's user interface to the client device.

[0034] Certain embodiments described herein can employ various computer-implemented operations on data stored in computer systems. These operations may, for example, require physical manipulation of physical quantities—usually, though not necessarily, these quantities take the form of electrical or magnetic signals—which (or representations thereof) can be stored, transmitted, combined, compared, or otherwise manipulated. Such manipulations are often described using terms such as generating, identifying, determining, comparing, and so on. All of the operations described herein that are part of one or more embodiments can be useful machine operations.

[0035] Furthermore, one or more embodiments may relate to a device or apparatus for performing the aforementioned operations. The apparatus may be specifically designed for certain required purposes, or it may be a general-purpose computer system comprising one or more general-purpose processors (for example, Intel or AMD x86 processors) that are selectively activated or configured by program code stored in the computer system. In particular, various general-purpose computer systems with computer programs written in accordance with the teaching contained herein may be used, or it may be more convenient to construct a more specialized apparatus for performing the required operations.The various embodiments described here can be practiced with other computer system configurations such as handheld devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframes and the like.

[0036] Furthermore, one or more embodiments can be executed as one or more computer programs or as one or more computer program modules embodied in one or more non-transitory computer-readable storage media. The term non-transitory computer-readable storage medium refers to any storage device based on existing or subsequently developed technology that can store data and / or computer programs in a non-transitory state for access by a computer system. Examples of non-transitory computer-readable media include a hard disk, network-attached storage (NAS), flash memory, random-access storage, flash-based non-volatile memory (e.g., a flash memory card or a solid-state drive), persistent storage, an NVMe device, and a CD (compact disc) (e.g., CD-ROM, CD-R, CD-RW, etc.).), a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The non-transitory computer-readable media can also be distributed across a network-connected computer system, so that the computer-readable code is stored and executed in a distributed manner.

[0037] Finally, the boundaries between different components, operations, and data stores are somewhat arbitrary, with certain operations being depicted in connection with specific illustrative configurations. Further assignments of functions are conceivable and may fall within the scope of the invention(s). In general, structures and functions represented as separate components in the example configurations can be executed as a combined structure or component. Similarly, structures and functions represented as a single component can be executed as separate components.

[0038] As used in the present description and in the following claims, "a" and "the" include the plural unless the context clearly indicates otherwise. As used in the present description and in the following claims, the meaning of "in" also includes "in" and "on" unless the context clearly indicates otherwise.

[0039] The above description illustrates various embodiments along with examples of how aspects of certain embodiments can be implemented. These examples and embodiments should not be considered the only embodiments and are presented to illustrate the flexibility and advantages of certain embodiments as defined by the following claims. Other arrangements, embodiments, applications, and equivalents may be used without departing from the scope defined by the claims. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 17 / 727,503

[0001]

Claims

[1] Method comprising: Receiving, by a computer system from a client device operated by an end user, a request to access a remote access application; identifying, by the computer system, a target server from a plurality of servers for executing the remote access application, wherein the remote access application is installed in an application package maintained on a shared storage component separate from the plurality of servers; Initializing a user session for the end user on the target server by the computer system; and Sending, by the computer system, to a remote access application agent running in the user session on the target server, an application specification for the remote access application, the application specification comprising an identifier of the application package and an executable path for the remote access application. [2] The method of claim 1, wherein the application remote access agent, upon receiving the application specification, provides the application specification to an application delivery agent running in the user session. [3] The method of claim 2, wherein the application delivery agent: determines, based on the application specification, that the remote access application is installed in the application package; the application package is dynamically activated from the shared storage component for the target server; and the remote access application starts via the activated application package within the user session. [4] The method of claim 3, wherein the application remote access agent subsequently streams a user interface of the launched remote access application to the end user's client device. [5] The method of claim 1, wherein the plurality of servers are loaded with a common software image that precludes the installation of remote access applications. [6] The method of claim 1, wherein the application package comprises a virtual floppy file comprising the installed content of the remote access application and metadata attributes of the remote access application. [7] The method of claim 1, wherein the computer system identifies the target server based on one or more criteria comprising the current loads of the plurality of servers. [8] A non-transitory, computer-readable storage medium having stored thereon program code executable by a computer system, the program code performing a method comprising: Receiving, from a client device operated by an end user, a request to access a remote access application; Identifying a target server from a plurality of servers for executing the remote access application, wherein the remote access application is installed in an application package maintained on a shared storage component separate from the plurality of servers; Initializing a user session for the end user on the target server; and Sending an application specification for the remote access application to a remote access application agent running in the user session on the target server, the application specification comprising an identifier of the application package and an executable path for the remote access application. [9] The non-transitory computer-readable storage medium of claim 8, wherein the application remote access agent, upon receiving the application specification, provides the application specification to an application delivery agent running in the user session. [10] The non-transitory computer-readable storage medium of claim 9, wherein the application delivery agent: determines, based on the application specification, that the remote access application is installed in the application package; the application package is dynamically activated from the shared storage component for the target server; and the remote access application starts via the activated application package within the user session. [11] The non-transitory computer-readable storage medium of claim 10, wherein the application remote access agent subsequently streams a user interface of the launched remote access application to the end user's client device. [12] A non-transitory computer-readable storage medium according to claim 8, wherein the plurality of servers are loaded with a common software image that precludes the installation of remote access applications. [13] The non-transitory computer-readable storage medium of claim 8, wherein the application package comprises a virtual floppy disk file comprising the installed content of the remote access application and metadata attributes of the remote access application. [14] The non-transitory computer-readable storage medium of claim 8, wherein the computer system identifies the target server based on one or more criteria comprising current loads on the plurality of servers. [15] Computer system comprising: a processor; and a non-transitory computer-readable medium on which is stored program code which, when executed, causes the processor to: receive a request to access a remote access application from a client device operated by an end user; identifying a target server from a plurality of servers for executing the remote access application, wherein the remote access application is installed in an application package maintained on a shared storage component separate from the plurality of servers; to initialize a user session for the end user on the target server; and to send an application specification for the remote access application to a remote access application agent running in the user session on the target server, wherein the application specification includes an identifier of the application package and an executable path for the remote access application. [16] The computer system of claim 15, wherein the application remote access agent, upon receiving the application specification, provides the application specification to an application delivery agent running in the user session. [17] A computer system according to claim 16, wherein the application delivery agent: determines, based on the application specification, that the remote access application is installed in the application package; the application package is dynamically activated from the shared storage component for the target server; and the remote access application starts via the activated application package within the user session. [18] The computer system of claim 17, wherein the application remote access agent subsequently streams a user interface of the launched remote access application to the end user's client device. [19] A computer system according to claim 15, wherein the plurality of servers are loaded with a common software image that precludes the installation of remote access applications. [20] The computer system of claim 15, wherein the application package comprises a virtual floppy disk file comprising the installed content of the remote access application and metadata attributes of the remote access application. [21] The computer system of claim 15, wherein the computer system identifies the target server based on one or more criteria including current loads on the plurality of servers.

Images