Patent ID: 12248364

DETAILED DESCRIPTION

In this specification and the claims, a managed device should be construed as including any end user computing device on which an agent is deployed to allow the end user computing device to be managed from a management server. For example, managed devices may be desktops, laptops, thin clients, tablets, smart phones, etc. A management server may be implemented in the cloud or on-premises.

FIG.1provides an example of a computing environment in which embodiments of the present invention may be implemented. The computing environment includes a management server100which is used to manage managed devices200-1through200-n(individually and collectively managed device(s)200). In some embodiments, managed devices200may pertain to multiple tenants. In other embodiments, managed devices200may pertain to a single tenant.FIG.1also shows that there may be other management servers101,102, etc., each of which may be used to manage managed devices (not shown) of other tenants. Each managed device200can include an agent201. The computing environment also includes a recovery service300. As an overview, agent201can be configured to communicate with management server100to enable management of managed devices200from management server100and can be configured to communicate with recovery service300to enable intelligent recovery of managed devices200. Management server100can also be configured to communicate with recovery service300to facilitate intelligent recovery of managed devices200. Although not shown, other managed devices that are managed from management server101,102, etc. may also include an agent201.

FIGS.2A and2Bprovide an example of how recovery service300may be leveraged to enable intelligent recovery of managed devices in a multi-tenant cloud environment. These figures represent steps that may be periodically performed to ensure that recovery service300will be available to perform the intelligent recovery when any one of managed devices200becomes unable check in with management server100or, in some embodiments, when managed devices200attempt to enroll with management server100. Although not depicted, these same steps can be performed for any other management server and corresponding managed devices that may be configured to use recovery service300.

Turning toFIG.2A, in step1, management server100can subscribe to recovery service300. For example, an administrator could configure management server100to interface with recovery service300to perform the functionality described below. In some embodiments, management server100could provide information about management server100as part of subscribing such as any management URLs it may used to manage managed devices200. Also, in embodiments where recovery service300may be used to enable managed devices200to enroll with management server100, management server100could provide device details for managed devices200in this step.

In step2, each managed device200can enroll or check in with management server100. As part of this enrollment or check in, agent201on each managed device200may provide a registration code (e.g., an identifier of the tenant and the group to which the managed device pertains and possibly an identifier of the managed device for management purposes) and may provide various “device details” of the respective managed device200such as a hostname, a MAC address, a serial number, etc. As stated above, agent201could be configured to provide such device details as part of enrollment with management server200and periodically as part of checking in with management server200. Also, an administrator could configure agent201to perform this enrollment or check in such as by providing to agent201the management URL and the identifiers it should use to construct the registration code.

FIG.2Aalso represents that agent201can be configured to maintain recovery service300's URL. For example, agent201may have a default configuration file which may define recovery service300's URL. In some embodiments, recovery service300's URL could be embedded in the binary of agent201so that recovery service300's URL remains accessible to agent201even if its default configuration file becomes corrupted or inaccessible. In short, agent201can be configured to know how to communicate with recovery service300independent of any status it may have with management server100.

Turning toFIG.2B, in step3, management server100can report information about its managed devices200to recovery service300. This information could include the device details reported by agent201for each managed device200as well as the corresponding “management server details” such as the management server URL and tenant, device, and group IDs assigned to the managed device. Management server100could be configured to report such information periodically such as whenever any changes in the device details or the management server details occur (e.g., when new managed devices200are added to or removed from a group, when new groups are created, when device details are updated, etc.).

In step4, recovery service300can store the information for each managed device200(and any other managed device) in database301. As shown, database301may associate the device details with the corresponding management server details. For example, the first entry in database301, which could represent managed device200-1, indicates that a managed device200having a hostname of Hostname1, a MAC address of B44506 . . . , and a serial number of 9NKZLG3 is assigned to a tenant having a tenant ID of TID1, is assigned to a group having a group ID of GID1, has been assigned a device ID of DID1, and is configured to use us1.company.com as the management server URL for communicating with management server100. The second entry, which could represent managed device200-2, indicates that managed device200-2is assigned to the same tenant and group as managed device200-2. The third entry, which could represent managed device200-n, indicates that managed device200-nis assigned to the same tenant as managed device200-1and200-2but to a different group from managed device200-1and200-2. The last entry indicates that the corresponding managed device is assigned to a different tenant (TID2) that uses an on-premises management server (e.g., management server101) that provides a management server URL of onprem.com.

FIG.2Balso shows that recovery service300could store a checksum in association with each entry in database301. In some embodiments, this checksum could be generated by agent201from the configuration of managed device200(e.g., by generating a checksum of a default configuration file that agent201uses to configure managed device200). In such cases, this checksum could be included in the enrollment and/or check in communications that agent201sends to management server100in step2and then included in the information that management server100reports to recovery service in step3. Alternately, in some embodiments, agent201could be configured to report the checksum directly to recovery service300. In any case, the checksum can be used to represent a state of a managed device200's configuration when the managed device is successfully configured for management.

FIGS.3A-3Eprovide and example of how a managed device200can be intelligently recovered. As stated above, in some embodiments, the functionality represented in this example could also be performed to enroll a managed device200. In step1, shown inFIG.3A, it is assumed that managed device200-1loses connectivity to management server100due to agent201no longer having/knowing the management server details (e.g., management server100's URL and/or any of the information necessary for constructing the correct registration code). This loss of connectivity could occur in different ways such as when an update to the operating system, to agent201or to another component is performed or as a result of tampering or user error which causes a file storing the necessary information to become lost, corrupted, or otherwise inaccessible. Also, in some embodiments, managed device200-1may not have connectivity simply because it has not yet been enrolled with management server100.

In step2, and upon detecting that it cannot connect with management server100, agent201can use recovery service300's URL to submit a recovery request. As stated above, agent201could maintain recovery service300's URL in a default configuration file and/or recovery service300's URL could be embedded in agent201's binary so that recovery service300remains accessible even when other content on managed device200-1may be lost, corrupted, or inaccessible. As represented inFIG.3A, agent201can include device details for managed device200-1in the recovery request such as the hostname, MAC address, and serial number.

Turning toFIG.3B, recovery service300is shown as having received the recovery request. Then, in step3, recovery service300can use the device details specified in the recovery request to locate a matching entry in database301. In this example, recovery service300will locate the first entry in database301. If, however, a matching entry does not exist for a recovery request, recovery service300could attempt to identify the management server to which the managed device requesting recovery pertains and, if found, could notify the management server that manual intervention may be required. Notably, in scenarios where agent201is requesting recovery as part of enrollment as opposed to in response to lost connectivity, a match could be found due to management server100having provided the relevant information to recovery service300(e.g., as part of subscribing to recovery service300or in conjunction with deploying new managed devices).

FIGS.3C and3Drepresent steps4and5that may be performed in some embodiments to add security to the recovery process. Although these steps are depicted separately from steps2and3, they could be performed as part of steps2and3in some cases. In step4, and as part of or in conjunction with sending the recovery request to recovery service300, agent201can access a configuration of managed device200-1to create a checksum from the configuration and send the checksum to recovery service300. For example, the configuration could be a file, a set of registry entries, or another set of stored parameters that may remain consistent even when a managed device loses connectivity to its management server.

Turning toFIG.3D, in step5, recovery service300can verify that the checksum received from agent201as part of or in conjunction with the recovery request matches the checksum stored in the corresponding entry in database301. In this example, the checksum matches and therefore recovery service300can determine that the configuration of managed device200-1has not been altered since the time when the stored checksum was provided. Accordingly, this verification of the checksum can be used to detect scenarios where the loss in connectivity is due to tampering, whether malicious or otherwise. In some embodiments, if the checksum is not verified, recovery service300could move the managed device that is requesting recovery to a quarantine group and may perform a factory reset to remove any possible vulnerabilities. The managed device could then be re-enrolled.

Turning toFIG.3E, in step6and in response to finding a matching entry in database301, recovery service300can send a recovery response to agent201on managed device200-1. This recovery response can specify the management server details that are associated with the device details in database301such as the management server URL of management server100that managed device200-1is supposed to use and the tenant ID, device ID, and group ID that management server100had assigned to managed device200-1.

Finally, in step7, agent201can use the management server details provided in the recovery response to check in (or enroll) with management server100as if managed device200-1had never lost connectivity. For example, agent201could direct a communication to the management server URL specified in the recovery response and could construct a registration code using the other management server details. Upon establishing connectivity with management server100, agent201can request any policies or other configurations that may be necessary to allow managed device200-1to resume its role in the managed device environment.

As can be seen, any of managed devices200as well as any other managed devices whose management server may be subscribed to use recovery service300can be automatically recovered using the techniques of the present invention. A single recovery service can therefore support recovery of managed devices spanning multiple tenants and multiple management servers.

Embodiments of the present invention may comprise or utilize special purpose or general-purpose computers including computer hardware, such as, for example, one or more processors and system memory. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system.

Computer-readable media are categorized into two disjoint categories: computer storage media and transmission media. Computer storage media (devices) include RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other similar storage medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Transmission media include signals and carrier waves. Because computer storage media and transmission media are disjoint categories, computer storage media does not include signals or carrier waves.

Computer-executable instructions comprise, for example, instructions and data which, when executed by a processor, cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language or P-Code, or even source code.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, smart watches, pagers, routers, switches, and the like.

The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices. An example of a distributed system environment is a cloud of networked servers or server resources. Accordingly, the present invention can be hosted in a cloud environment.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description.