Secure management of devices

Abstract

The invention relates to a management server. The management server includes: a processor; and a computer readable storage medium, the computer readable storage medium storing instructions, when executed by the processor, causing the management server to configure the specific managed device by the following steps: receiving a sign-in request from the specific managed device; determining, based at least on the sign-in request, a specific enterprise service associated with the specific managed device, the specific enterprise service being accessible to the management server over the computer network; receiving generic configuration data over the computer network from a particular enterprise service associated with the particular managed device; converting the generic configuration data to a device-specific provisioning command suitable for hardware or software characteristics of the particular managed device based at least on the hardware or software characteristics of the particular managed device; and transmitting the device-specific provisioning command to the specific managed device.

Description

[0001] Related Applications

[0002] This application is a divisional application of the invention patent application with application number 202180019422.1 and invention name “Safety Management of Equipment”. Background Art

[0003] Within organizations around the world, a common need for information technology (IT) managers is the ability to conveniently manage multiple types of devices and networks across the organization. Often, an organization may wish to enforce certain rules or requirements on devices associated with the organization. However, each device may require unique information in order to work with the organization's network, which may require IT managers to manually configure each device as part of the provisioning process. Furthermore, because the various devices used by an organization may require different configurations, IT managers cannot easily rely on configuration templates to set up the devices, resulting in additional costs and time in the process of configuring the devices to a usable state. As a result, there remains difficulty in quickly provisioning devices in a convenient manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The detailed description is described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of similar reference numbers in different instances in the description and the figures may indicate similar or identical items.

[0005] Figure 1 An example system consistent with some implementations of the present concepts is shown.

[0006] Figure 2 An example graphical user interface consistent with some implementations of the present concepts is shown.

[0007] Figure 3 An example system consistent with some implementations of the present concepts is shown.

[0008] Figure 4 An example process flow consistent with some implementations of the present concepts is shown.

[0009] Figure 5 Example methods or techniques consistent with some implementations of the present concepts are shown. DETAILED DESCRIPTION

[0010] Overview

[0011] In various organizations, IT management is often tasked with deploying devices throughout the organization and ensuring that these devices are adequately configured with various settings to ensure that the organization's network remains secure and stable. For example, an organization may need to lock down any devices issued to employees of the organization so that the employees cannot install new applications or modify the settings of the device. Alternatively, the organization may restrict the installation of applications to managed devices so that users can only install certain trusted applications. However, the wide variety of devices that an organization may deploy may make the management of these devices difficult because each device may require different configuration values ​​to ensure compliance with the organization's security requirements.

[0012] In some instances, IT management can utilize enterprise mobility management (EMM) services, which can provide a set of services and technologies that can assist in the provisioning and protection of an organization's devices. For example, an organization can deploy multiple devices, and after the device is powered on or periodically during the deployment life cycle of the device, the device can interact with the EMM to receive the necessary configuration data for provisioning. Such configuration data may include, for example, security policies, wireless passwords, required applications, and various management tools and other settings. EMMs can generally provide some flexibility for the configuration of devices, because an organization utilizing an EMM can have very different requirements from a different organization utilizing the EMM. Therefore, EMMs can be used to assist in defining various configuration settings to be applied to deployed devices associated with an organization.

[0013] However, even with EMM, IT management may still need to provide several different configuration profiles based on the type of device being deployed. For example, after deploying a smartphone and a laptop to an employee, the configuration settings for the two devices may be very different, which may require IT management to determine multiple sets of configuration settings for configuring the devices. Therefore, this can lead to a lot of work in the process of deploying various types of devices throughout the organization.

[0014] Furthermore, in certain instances, an organization may need to change from one EMM to a different EMM, such as when an organization migrates between operating systems for devices. Since each EMM utilizes a different approach to managing devices, IT management may often need to initiate new EMM services by redefining various configuration profiles associated with the different types of devices utilized by the organization. Furthermore, each device may need to be formatted and re-provisioned in order to be operable with the new EMM services.

[0015] Therefore, the concepts disclosed herein can provide a technical solution for enabling convenient deployment of devices by providing a platform management server that can act as an intermediary between one or more EMMs and various deployed devices. The platform management server can be utilized by users of the EMM to apply various configuration settings and resources on managed devices based on a common configuration template that can be utilized for all devices. The configuration template can specify various configurations to be applied to the device with the help of the EMM, including security settings and installation requirements. After the deployed device is powered on, the device can check in with the platform management server, which can include a discovery service that can assist the device in discovering whether the device should be managed by the platform management server and which specific EMM should manage the device.

[0016] Once the device determines that it will be managed by the platform management server, the platform management server can apply the specific configuration template provided by the EMM associated with the device. In some implementations, the configuration template can include one or more placeholders for additional configuration data values, such as secret passwords or other such sensitive data that the organization may not want the platform management server to share or view. In this case, the platform management server can issue a callback to the EMM to provide the secret value, which can be encrypted at the EMM and transmitted to the device in an encrypted state so that the platform management server cannot identify the details of the data. After receiving the encrypted data, the device can decrypt the data and apply the secret value during configuration of the device.

[0017] After the initial power-on of the device, before the device is checked in, the platform management server can additionally pre-compute various configuration settings and applications specified by the configuration template. For example, the platform management server can pre-compute that for certain smartphone devices utilized by the organization, certain applications on the smartphone may need to be removed before installing applications that the organization may prefer. In addition, the platform management server can determine whether the template provided by the IT management party has potential conflicting requirements, and such conflicts can be resolved and reported to the management party via the EMM.

[0018] It should be appreciated that any reference to configuration data herein may include various types of data that may be used to configure a device, such as software applications, policy settings, passwords, pre-shared keys, one-time secrets, tokens, unique identifiers, checksum values, cryptographic random numbers, or any other type of data that may be utilized in the configuration of a device to enable the device to use a network. Such configuration data may be associated with a configuration grouping that may be provided to the device via a platform management server where the device may apply various settings and applications associated with the configuration grouping.

[0019] Example System

[0020] refer to Figure 1 , provides an example system 100 for performing security management of deployed devices according to the techniques disclosed herein. Figure 1 As depicted, system 100 may include a platform management server 102 that may be used to manage provisioning of one or more managed devices 104, which may include, for example, a desktop or laptop device 104(1) or a portable device 104(2). Management of managed devices 104 may be initiated by an administrator 106, which may interact with one or more enterprise services 108 to define configuration templates to be used to provision managed devices and may monitor the status of the provisioning process. Enterprise service 108 may be an EMM and may include multiple different types of EMMs, such as EMM 108(1), which may be an EMM provided by a specific service provider, while EMM 108(2) may be an EMM provided by a different service provider. For example, enterprise service 108 may be any or all of the following: Microsoft VMware ,or and other such EMM services.

[0021] The platform management server 102, the managed devices 104, the management party 106, and the enterprise services 108 may all be communicatively coupled via a network 110 (e.g., the Internet or an intranet). However, it should be appreciated that although the various entities depicted in the system 100 may be communicatively coupled to the network 110, not all entities must communicate with each other. For example, in some implementations, the management party 106 may only communicate with the enterprise services 108 and may not have a direct ability to communicate with the platform management server 102. Similarly, the enterprise services 108 may not have the ability to communicate directly with the managed devices 104, as the platform management server 102 may be responsible for communicating with the managed devices.

[0022] The platform management server 102 and the managed device 104 may each include a processor 112 and a memory 114. The memory 114 may have various software modules that are executable by the processor 112 for performing the processes disclosed herein. The memory 114 may include persistent storage resources (such as magnetic or solid-state drives) and volatile storage (such as one or more random access memory devices). In some cases, the modules described herein in connection with the memory 114 may be provided as executable instructions that are stored in a persistent storage device, loaded into a random access memory (RAM), and read from the RAM by the processor for execution.

[0023] Memory 114(1) associated with platform management server 102 may include or have access to management module 116, which may be a software program executable by processor 112 for performing various management tasks associated with configuring managed devices 104. Memory 114(1) may also include API 118, which may be exposed to provide a programming interface for use by enterprise services 108, and discovery module 120 and check-in module 122 that may interact with deployed devices.

[0024] In one implementation, the enterprise service 108 may include a software application usable by the management party 106, which may include a graphical user interface (GUI) for displaying visual depictions of managed devices within an organization, and the enterprise service 108 may present information to the management party 106 regarding various options for configuring devices with the aid of templates that are applicable to devices provided by the platform management server 102. In particular, the GUI of the enterprise service 108 may interact with the management module 116 by making programmatic calls using the API 118 to pull certain information about the configuration capabilities of the management module 116 and provide the received template data in a form suitable for processing by the management module 116. Such template data may be stored, for example, in a database 124 of the platform management server 102.

[0025] In some implementations, the management module 116 may allow only certain configuration data specified in the template, regardless of the specific EMM that utilizes the platform management server 102 to manage the device. By providing API calls only for specific types of information, the platform management server 102 can ensure that the configuration settings applied by the management party 106 via the enterprise service 108 do not exceed the boundaries of the predefined template. For example, although the template utilized by the platform management server 102 may include a large list of various data fields, the EMM will not be able to specify additional secret values ​​outside of the templated fields in the template. This can ensure that the management module 116 can appropriately pre-compute the configuration groupings for the managed device 104 without encountering issues with how to handle unknown data, which may cause system instability.

[0026] In providing the enterprise service 108 with the ability to define configuration data for use by multiple types of managed devices 104, the management module 116 can abstract away the details of how the configuration is applied to each managed device, as once the device is checked in, the management module can ultimately pre-compute the necessary configuration steps for a specific device, regardless of the type of device it is. Thus, the administrator 106 can provide generic configuration data via the enterprise service 108, as well as assign the data to specific devices, by filling in any relevant data specified by the configuration template, regardless of the device implementation. The assignment of templates to specific devices can take advantage of a flexible assignment system that can easily allow the administrator 106 to specify certain devices among the organization's various deployed devices. For example, the flexible assignment system can provide a classification function in which all devices associated with a specific group within the organization can be targeted, such as a marketing group, and as described below with respect to Figure 2 Described in further detail.

[0027] Figure 2 An example graphical user interface (GUI) 200 of an assignment system is depicted that may be displayed to an administrator 106 for assigning a configuration template to certain deployed devices. Figure 2 An example GUI 200 is depicted, which can be displayed to an administrator 106 via an enterprise service 108. The example GUI 200 depicts a management page whereby an administrator 106 can search for a specific managed device or group of devices and can apply a configuration template to the device. The GUI 200 can also provide the administrator 106 with information about the application of the template on the device.

[0028] Specifically, the GUI 200 depicts an example user interface that can be used by the admin 106 to create, search, sort, or filter various managed devices that can be deployed. The GUI 200 can interact with the database 124 to extract relevant information that can be displayed, and after receiving data from the admin 106, the database 124 can be updated to reflect the changes made by the admin. The GUI 200 can include various menu options, including a new device button 202, which can allow the admin 106 to define a new device or grouping of devices, and the device or group data can be stored in the database 124 of the platform management server 102. In one implementation, the device can be identified based on the serial number of the device or other such identifying characteristics. The GUI 200 can further include a template view button 204, which can display a list of templates currently stored in the database 124, allowing templates that can be associated with a device to be added, deleted, or modified.

[0029] GUI 200 may also include multiple flexible ways to select a specific device and assign a template to the device. For example, GUI 200 may include a search field 206 that allows a developer to insert a query for a specific device, and existing devices that may be known in database 124 may be searched based on the received query. Search field 206 may be particularly useful when a device may be associated with an individual user or group that already exists, thereby allowing administrator 106 to relatively quickly identify a managed device of interest. GUI 200 may further include a user filter field 208, a group filter field 210, and a type filter field 212, which allows filtering existing devices based on various inputs: such as the name of a specific user, a group name within an organization associated with administrator 106, or a device type within an organization, such as a smart phone or laptop device. These fields may be text input fields, drop-down menus, and the like.

[0030] GUI 200 may further include field 214, which includes several rows for existing managed devices, where each row may correspond to a respective device or group of devices. Each device may have an associated description (which may specify a user and / or group name), a template associated with the specified device or group (which may be modified via a drop-down menu populated from database 124), the status of the device with respect to the template, and a record of the last report received from the device or devices in the group.

[0031] The various device descriptions displayed in field 214 may be individually selected by the administrator 106. Upon selecting a description, a user interface may be generated that displays information associated with the selected device or group, depicting a particular conversation flow associated with the selected training conversation. For example, a graphical user interface may be depicted that displays the current hardware associated with the device, as well as an option to modify the registration of the device in the managed network associated with the organization. It should be understood that the information in the rows is set forth to assist the administrator 106 in distinguishing between the various managed devices and determining their appropriate status based on the applied template, but Figure 2 The information depicted in is not intended to reflect the only information that may be presented, and it should be understood that any suitable type of information that may assist administrator 106 in managing the device is contemplated.

[0032] Reference again Figure 1, upon receiving a configuration template and device assignments (such as via GUI 200), management module 116 may store the configuration template and any associated assignments in database 124, and may also precompute various installation parameters that may be provided to managed devices 104 in order to apply the settings specified in the configuration template. In addition, installation parameters may be prioritized in a manner that ensures that installation of certain configuration data does not result in conflicts with other data on the device. For example, upon a managed device 104 signing in, management module 116 may determine an appropriate template to apply to the device, and because management module 116 precomputed the installation parameters for the device when it first received the configuration template from management party 106, the installation parameters may be immediately provided to managed devices 104 without having to wait for management module 116 to perform on-the-fly calculations to discover the necessary parameters.

[0033] The discovery module 120 can be used to handle initial discovery tasks associated with the managed device 104. In some implementations, the managed device 104 may have recently been deployed to a location or user, and after the device is powered on, the device may be preconfigured to access the discovery module 120 to allow the device to determine what EMM should authenticate and manage the configuration of the device. Once the discovery module 120 determines the appropriate EMM that the managed device should be associated with, the managed device may be provided with a certificate to be used after the device is signed in, which may assist in defining a specific template to be used with the device. Having received the specific certificate for the sign-in, the managed device 104 may then interact with the sign-in module 122, where the platform management server 102 may begin the process of determining the current state of the device.

[0034] Figure 3 Memory 114(1) and various modules associated with platform management server 102 are depicted in greater detail. As described above, management module 116 can pre-compute various installation parameters that can be provided to managed devices 104 in order to apply settings specified in a configuration template. In one implementation, pre-computation of installation parameters can be performed in conjunction with inventory service 302, which can include references to various software inventories that can be included as part of the configuration of managed devices 104 based on the configuration template. Inventory service 302 can also have records specifying default configurations for specific devices, so that management module 116 can reference these records in order to determine whether certain software can generally be installed on these devices and whether it should be removed from the device based on the configuration provided by management party 106.

[0035] For example, once a device is shipped from an original equipment manufacturer (OEM), a deployed device may be automatically imaged using a certain web browser, which the administrator 106 may wish to uninstall, such as due to a potential security risk. In this case, the inventory service 302 may have a record that may indicate whether the device shipped from the OEM is pre-configured with a web browser, and the management module 116 may therefore include a step to uninstall the web browser. In another implementation, the inventory service 302 may determine the appropriate version of certain software that should be associated with a specific managed device. For example, although a new operating system may be available for a variety of managed devices, the administrator 106 may wish for certain devices to retain an old version of the operating system for compatibility purposes. Therefore, the inventory service 302 may return the appropriate software version for the device when requested.

[0036] The management module 116 may also include a conflict service 304 that can assist in prioritizing installation parameters associated with the configuration of the managed device. The conflict service 304 can prioritize the installation of certain software or the application of configuration settings in a manner that ensures that the installation of certain configuration data does not cause a conflict with other data on the device, and can ensure that any dependencies are met prior to installation. For example, the installation of certain software applications may require the presence of certain configuration settings on the managed device 104, so the conflict service 304 can determine that the configuration settings should be applied prior to installing the software. Alternatively, the conflict service 304 can determine that a template received for a device may specify the installation of certain software applications, and the template may also later indicate that the software application should be uninstalled. In this case, the conflict service 304 can resolve the conflict and provide information about the conflict resolution.

[0037] In some implementations, the conflict resolution information can be provided to a reporting service 306, which can generate information about the provisioning status of the managed device 104 for the management party 106. Specifically, the reporting service 306 can provide detailed information about each step of the provisioning process and the success or failure of certain installation steps. Once the provisioning of the managed device 104 is completed, the reporting service 306 can further generate an overview report, and the overview report can be provided to the management party 106 via the management module 116.

[0038] In some implementations, the discovery module 120 may include a discovery service 308 and a registration service 310. Upon the sign-in of a new device, the platform management server 102 may discover which (if any) EMM should manage the device. Thus, as discussed above, after the device is powered on, the device may be preconfigured to access the discovery service 308 to allow the device to determine whether the device should be associated with an EMM and which specific EMM to register with. The discovery service 308 may interact with the database 124 to determine whether the database contains information that designates the device as a device managed by the platform management server 102. In addition, the database 124 may contain data about a specific EMM that can manage the device. After determining that the device will be managed by the platform management server 102 and after determining the appropriate EMM with which the managed device should be associated, the registration service 310 may interact with the database 124 to issue an appropriate certificate to be used for device sign-in, which may assist in defining a specific template to be used with the device.

[0039] After receiving the certificate, the managed device 104 can perform a check-in process with the help of the check-in module 122, which can determine what configuration data is currently located locally on the device and what configuration data should be located on the device according to the configuration template. The check-in module 122 can include various OS and / or device-specific services that can enable the correct configuration of managed devices with different configurations. For example, the check-in module 122 can include Windows services 312, iOS / macOS services 314, Linux services 316, and Android services 318, and each of these services can utilize the translation layer 320 during operation.

[0040] These services may include specific installation parameters necessary for proper configuration of the managed device, depending on its operating system configuration, and the translation layer 320 associated with each service may appropriately convert general instructions into specific provisioning commands that may be necessary for different types of managed devices and / or operating systems on the device. However, it should be appreciated that additional services may be utilized as part of the check-in module 122, such as services for different hardware that may be located on the managed device (e.g., ARM-based instruction sets, x86 instruction sets, etc.). Once the check-in module 122 determines the difference between the current state of the device and the desired configuration set forth in the configuration template, a configuration grouping may be provided to the managed device, which may include the configuration template and the data necessary to achieve the device state defined by the configuration template. A more detailed description of the check-in process will be provided below with reference to Figure 4 Describe in more detail.

[0041] Reference again Figure 1After the configuration package is sent to the managed device 104, the configuration package can be stored in a persistent storage area 126 associated with the managed device 104. The persistent storage area 126 can also store an image of the initial factory setup state of the device, which can be used as a backup to perform a clean installation of the operating system on the device if the device encounters difficulties in provisioning.

[0042] Orchestrator module 128 may then handle the unpacking and application of the configuration data provided in the configuration packet. In some implementations, the configuration packet may contain one or more references to external templates, and orchestrator module 128 may coordinate communications back to platform management server 102 to download the external templates.

[0043] In addition, based on instructions contained in the configuration packet from platform management server 102, or alternatively, orchestrator module 128 can further autonomously perform periodic state determinations regarding the current configuration state of managed devices 104. That is, as configuration packets are received and stored in persistent storage area 126, orchestrator module 128 can periodically determine whether the current configuration state of the device matches the configuration requirements specified in the configuration template. Thus, even if managed device 104 is not currently connected to network 110, orchestrator module 128 can maintain a given configuration on the managed device itself.

[0044] Example procedure for device check-in

[0045] Figure 4 An example process 400 is depicted in which a managed device 104 signs in and receives a configuration template from a platform management server 102 according to one implementation. Figure 4 As depicted, at step 402, the managed device 104 may issue a request to the platform management server 102 to sign in. As previously discussed, the managed device 104 may be initially configured to issue a sign-in request to the platform management server 102 upon initial power-on of the device. However, in some implementations, an older device that may have been previously deployed may not include the necessary configuration data for the device to sign in to the platform management server 102, and may instead issue a request to the identity manager. In this case, the identity manager may be configured to either redirect the request to the platform management server 102 or provide an update to the device instructing it to communicate with the platform management server 102 in the future.

[0046] The check-in request from the managed device 104 may include device information detailing the current state of the device, such as by including information on the hardware included with the device, the operating system version, a list of documents / applications, and a token indicating a user or group identity associated with the device. Since a managed device may check in multiple times during its deployment, the device information may also include version information about the templates applied on the device, and the status of any applied templates (e.g., template application successful, template resulting in an error, etc.). The device information may be collected by the orchestrator module 128 and provided during the check-in.

[0047] After receiving the device information included with the sign-in request, the platform management server 102 may update the current client state stored in the database 124 at step 404. Based at least on the current client state, the platform management server 102 may further determine whether to perform certain actions for the managed device. For example, if the current client state indicates that the managed device has not been signed in before, an additional introductory template may be provided to the device, which may display some introductory messages to the user of the device. Alternatively, if the management party 106 has indicated that the specific device should be deregistered with the enterprise service 108, some of the sign-in steps may be skipped.

[0048] Additionally, at step 406, management module 116 may access database 124 using the device information included in the check-in request to locate a configuration template for the device. For example, management module 116 may access a token included within the device information that specifies a specific user or group identification associated with the device and is coupled with the hardware information provided in the request, and management module 116 may access database 124 to determine whether a configuration template that will target the particular user and device has been defined and stored by enterprise service 108. Upon determining that the configuration template exists in the database, management module 116 may extract the template and the pre-computed installation parameters associated with the template.

[0049] At step 408, the platform management server 102 may provide a notification to the enterprise service 108 to alert the management party 106 that a check-in request has been received from the managed device. Such a notification may be generated by the reporting service 306. In addition, the notification may also indicate the user and device combination associated with the request, and may indicate the configuration template that the platform management server 102 intends to apply to the managed device. In some implementations, the management party 106 may have the ability to cancel the application of the template to the device, or may be able to supplement the provisioning process by refining the template at this stage.

[0050] For example, the management party 106 may have defined a configuration template for a managed device in the past, and may be in the process of modifying the set of applications that should be installed on the managed device. In this case, the management party 106 may modify the configuration template, or may allow the configuration template to be applied to the managed device 104, but may be informed that the specific managed device may require a configuration template update.

[0051] At step 410, the management party 106 may optionally confirm the check-in and provide any immediate response to the notification to the platform management server 102, such as by indicating that the selected configuration template should not be applied to the managed device 104. In some implementations, step 410 may be optional, as the platform management server 102 may default to automatically proceeding to applying the selected configuration template in the absence of any incoming response from the enterprise service 108.

[0052] At step 412, the management module 116 can filter certain configuration settings, such as by determining whether a configuration template associated with the managed device 104 may include certain configurations that are not applicable to a specific target device. For example, while a configuration template may be defined for all users of smartphones within a marketing group in an organization, different operating systems may be running on the smartphones. Therefore, certain settings specified in the configuration template may only apply to smartphones with operating systems higher than a certain version. In this case, the management module 116 can determine whether any pre-computed configuration settings for the device can be filtered out. Therefore, the management module 116 can modify the configuration to be applied to the device on the fly as the state of the device changes over time.

[0053] Next, management module 116 may resolve any conflicts presented by the configuration template at step 414. Since management module 116 may pre-compute various configuration settings based on the configuration template received by enterprise service 108, management module 116 may know what the device configuration should be based on the primary user associated with the device and ensure that conflicting information between the device configuration and the user's specific configuration is resolved.

[0054] Specifically, in some cases, the managed device 104 may issue a check-in request to the platform management server 102, but the primary user associated with the managed device may not have yet logged into the device. In this case, the configuration associated with the device may potentially deviate from the configuration associated with the user. For example, the administrator 106 may issue a default configuration template to each laptop associated with the organization that indicates that a certain application should be removed. However, the administrator 106 may also provide a configuration template specific to the user of one of the laptops that allows the application to remain installed because the user's work requirements may involve the application. In this case, since the primary user of the device is not logged in, the device will not be able to report the user associated with the device in the check-in request, and the application may ultimately be removed from the managed device when the configuration template is applied.

[0055] Alternatively, because management module 116 can pre-compute configuration settings in advance, management module 116 can determine whether the primary user's configuration should be applied to the device regardless of whether the primary user is logged into the device. Thus, management module 116 can avoid flipping the device state due to limited information received from the device (i.e., when no user identification information is provided in the sign-in request).

[0056] At step 416, the platform management server 102 may communicate any conflicts that may have been discovered during step 414 to the enterprise service 108, presenting the conflicts and potential solutions to the conflicts. In some implementations, the notification may indicate that the potential solutions may be applied as default solutions, and that the administrator 106 does not need to take any action to resolve the conflicts. Alternatively, at step 418, the administrator 106 may confirm the conflicts by issuing a resolution action via the enterprise service 108.

[0057] At step 420, the management module 116 may calculate the changes necessary to achieve the state specified in the configuration template for the managed device 104. The change calculation may be based on what the device reported in the initial check-in request, and the state may be compared to the configuration template stored in the database 124. In some implementations, the management module 116 has already filtered any inapplicable configurations and resolved any conflicts according to steps 412 and 414.

[0058] Specifically, the management module 116 can associate the configuration to one of the following three possible categories: 1) configuration to be added, 2) configuration to be removed, and 3) configuration that is not assigned or not applicable but not removed from the managed device. If the management module 116 determines that the managed device 104 contains certain configurations that are not specified in the configuration template, and also determines that these settings do not conflict or interfere with any other settings on the device, the third category can be used. For example, the managed device 104 may include a wireless password for a home network associated with the primary user of the device, which may not be provided in the configuration template. However, since removing the wireless password may affect the use of the device, the management module 116 may specify that the wireless password should not be removed during the application of the configuration template. In addition, in some implementations, if a configuration falls into the third category (i.e., unassigned / not applicable configuration), the configuration can potentially become applicable to the device in the future. However, since the configuration remains on the device, the device does not have to retrieve a new template from the platform management server 102 in order to apply the required configuration.

[0059] At step 422, due to the presence of the placeholders in the configuration template, the management module 116 may issue a request to the enterprise service 108 to retrieve the secret value. As previously described, there may be certain information that the management party 106 may wish to keep confidential, and therefore placeholders may be defined in the configuration template provided to the platform management server 102. Thus, the management module 116 may coordinate the transfer of secret information from the enterprise service 108 to the managed device 104.

[0060] At step 424, the enterprise service 108 may send the requested secret value to the platform management server 102. In some implementations, the secret value sent from the enterprise service 108 may be encrypted to protect the confidentiality of the secret value. The encrypted secret value may be provided to the platform management server 102 for packaging with a configuration template that may be provided to the managed devices 104. The encrypted secret value may then be decrypted by the managed devices 104 once the configuration template is applied, thereby protecting the secret value from becoming known to the platform management server 102.

[0061] At step 426, the management module 116 can coordinate the issuance of the final configuration template (including any encrypted secret values) as a configuration packet to the managed device 104. The managed device 104 can then apply the configuration template and decrypt any included encrypted secret values ​​to complete the provisioning of the device. The management module 116 can send the configuration template directly to the managed device 104 along with any necessary files and documents, or in some implementations, the configuration packet can be uploaded to a server and a download link can be provided to the managed device 104, where the configuration packet can be located.

[0062] At step 428 , the managed device 104 may report its current state based on applying the configuration template, including any errors that may have occurred during device provisioning. At step 430 , the management module 116 may store the current device state in the database 124 .

[0063] Finally, at step 432, the management module 116 can issue a summary report indicating the results of the provisioning of the managed device 104 to the enterprise service 108 so that the management party 106 can make any necessary changes. The report can include information such as what configuration was applied to the device, any conflicts found and resolved, and configurations that failed during provisioning.

[0064] It should be realized that in addition to Figure 4 In addition to the steps specified in, alternative or additional steps may also be provided. For example, if the management module 116 determines that a configuration template does not yet exist for the device that has been checked in, a request for a configuration template may be sent to the enterprise service 108 to provide relevant information.

[0065] Example device management method

[0066] The following discussion presents an overview of functionality that may provide the management functionality described above. Figure 5 An example method 500 consistent with the present concepts is shown. The method 500 may be implemented by a single device (e.g., platform management server 102), or may be distributed across one or more servers, client devices, etc. In addition, the method 500 may be performed by one or more modules, such as management module 116, discovery module 120, check-in module 122, and / or orchestrator module 128.

[0067] First, at block 502, the method may receive a configuration template. In one implementation, the management party 106 may utilize the enterprise service 108 to provide a configuration template for managing the devices 104. The configuration template may be received by the platform management server 102 and stored in the database 124. The configuration template may be associated with a specific category of deployed devices and, in some cases, may be associated with specific users of certain deployed devices.

[0068] At block 504, the method may precompute device configuration settings based at least on the configuration template. In one implementation, the management module 116 may analyze the configuration template to determine what common configuration settings are provided in the template. The management module 116 may then determine device-specific configuration settings based on the target device so that the common configuration can be converted to device-specific settings applicable to the device targeted by the configuration template. Once the management module 116 precomputes the various configuration settings, the settings may be stored in the database 124 for access once the device is checked in to the platform management server.

[0069] At block 506 , a check-in request may be received from a managed device. For example, a managed device 104 may be newly powered on at a deployment location and may be configured to issue a check-in request to the platform management server 102 after initial startup.

[0070] At block 508, the method can discover the enterprise services associated with the managed device 104. In one implementation, the platform management server 102 can be associated with multiple enterprise services, but the platform management server 102 can discover that the managed device 104 is to be managed by a single enterprise service and can therefore prevent other enterprise services from communicating with the managed device, which can ensure that the managed device is not managed by a malicious endpoint.

[0071] At block 510, the method may select a device template associated with the discovered enterprise service and corresponding to the managed device. In one implementation, the platform management server 102 may select an appropriate device template. The device template may be stored in, for example, a database 124, and the management module 116 may extract the relevant device template from the database based on the device information provided in the check-in request and the information about the enterprise service that manages the device. As described above, in some implementations, the device template may contain a placeholder that may be used to specify a secret value to be used to configure the device. Since the platform management server 102 does not have the secret value, it may be provided by the enterprise service associated with the managed device.

[0072] Therefore, at block 512, the method can retrieve additional configuration data associated with the placeholder from the enterprise service. Specifically, the platform management server 102 can indicate to the enterprise service 108 that there is a placeholder in the template that requires a secret value. The enterprise service 108 can encrypt the secret value and provide the encrypted data back to the platform management server 102 for transparent transmission to the managed device 104. Since the platform management server 102 cannot decrypt the encrypted data, the secret value can remain secret even if the data is transparently transmitted through the platform management server 102.

[0073] Finally, at block 514, the method may issue network settings to the managed device application configuration. Specifically, management module 116 may prepare a configuration packet for transmitting instructions to the managed device 104 to apply the configuration specified in the packet. Orchestrator module 128 may coordinate the decapsulation of the configuration packet and the correct provisioning of the managed device, including decrypting the encrypted data provided by enterprise service 108 in order to apply the secret value. In some implementations, the configuration set forth in the configuration packet may include network settings, provisioning settings, and software that has been and / or should be associated with the managed device.

[0074] Device Implementation

[0075] As mentioned above about Figure 1 As described, system 100 may include several devices, including platform management server 102, managed devices 104, and enterprise services 108. It is also noted that not all device implementations may be shown, and other device implementations should be apparent to those skilled in the art based on the above and following descriptions.

[0076] The terms "device," "computer," "computing device," "client device," "server," and / or "server device" as may be used herein may refer to any type of device having certain hardware processing capabilities and / or hardware storage / memory capabilities. The processing capabilities may be provided by one or more hardware processors (e.g., hardware processing units / cores) that may execute computer-readable instructions to provide functionality. The computer-readable instructions and / or data may be stored on persistent storage or volatile memory. The term "system" as used herein may refer to a single device, multiple devices, etc.

[0077] The memory 114 can be an internal or external storage resource of any corresponding device associated therewith. The memory 114 can include one or more of the following: volatile or non-volatile storage, a hard drive, a flash memory device, and / or an optical storage device (e.g., a CD, a DVD, etc.), etc. As used herein, the term "computer-readable medium" may include signals. In contrast, the term "computer-readable storage medium" excludes signals. "Computer-readable storage medium" includes "computer-readable storage devices". Examples of computer-readable storage devices include volatile storage media, such as RAM, and non-volatile storage media that may constitute the memory 114, such as hard drives, optical disks, and flash memories, etc.

[0078] In some cases, the device is configured with a general-purpose hardware processor and storage resources. In other cases, the device may include a system-on-chip (SOC) type design. In a SOC design implementation, the functions provided by the device can be integrated in a single SOC or multiple coupled to the SOC. One or more associated processors can be configured to coordinate shared resources (such as memory, storage, etc.) and / or one or more dedicated resources (such as hardware blocks configured to perform specific functions). Therefore, the terms "processor", "hardware processor" or "hardware processing unit" used in this article may also refer to a central processing unit (CPU), a graphics processing unit (GPU), a controller, a microcontroller, a processor core, or other types of processing devices suitable for implementation in traditional computing architectures and SOC designs.

[0079] Alternatively or additionally, the functions described herein may be at least partially performed by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), etc.

[0080] In some configurations, any modules / code discussed herein may be implemented in software, hardware, and / or firmware. In any case, the modules / code may be provided during device manufacturing or by an intermediary preparing to sell the device to an end user. In other cases, the end user may later install the modules / code, such as by downloading an executable code and installing the executable code on the corresponding device.

[0081] It is also important to note that a device may generally have input and / or output functionality. For example, a computing device may have various input mechanisms, such as a keyboard, a mouse, a touchpad, voice recognition, gesture recognition (e.g., using a depth camera, such as a stereo or time-of-flight camera system, an infrared camera system, an RGB camera system, or using an accelerometer / gyroscope, facial recognition, etc.). A device may also have various output mechanisms, such as a printer, a monitor, etc.

[0082] It is also important to note that the devices described herein can function independently or in cooperation to implement the described techniques. For example, the methods described herein can be performed on a single computing device and / or distributed across multiple computing devices (such as IoT devices) communicating on one or more networks. Without limitation, such one or more networks may include one or more local area networks (LANs), wide area networks (WANs), the Internet, etc.

[0083] Various examples are described above. Additional examples are described below. One example includes a management server including a processor and a computer-readable storage medium storing instructions that, when executed by the processor, cause the management server to configure a managed device by receiving a configuration template associated with the managed device, the configuration template including a placeholder for additional configuration data, receiving a check-in request from the managed device, determining an enterprise service associated with the managed device based at least on the check-in request, requesting additional configuration data from the enterprise service associated with the managed device, and applying the configuration template including the additional configuration data to the managed device.

[0084] Another example may include any of the above and / or below examples where the management service further includes receiving additional configuration data from the enterprise service.

[0085] Another example can include any of the above and / or below examples where the additional configuration data received from the enterprise service is encrypted.

[0086] Another example may include any of the above and / or below examples where the additional configuration data is decrypted when applied to the managed device.

[0087] Another example may include any of the above and / or below examples, in which the management server further comprises: pre-calculating configuration settings according to a configuration template for the managed device before receiving the check-in request.

[0088] Another example may include any of the above and / or below examples in which a configuration template generally defines configuration data without regard to device implementation.

[0089] Another example may include any of the above and / or below examples where the precomputed configuration settings include device-specific configuration settings.

[0090] Another example may include any of the above and / or below examples where the check-in request indicates a current state of the managed device.

[0091] Another example may include any of the above and / or below examples, in which the management server further comprises: calculating a change between a current state of the managed device and a state defined by the configuration template.

[0092] Another example may include any of the above and / or below examples in which a current state of a managed device is periodically compared to a state defined by a configuration template.

[0093] Another example may include any of the above and / or below examples in which the enterprise service is determined from among a plurality of enterprise services.

[0094] Another example includes a method comprising: receiving a check-in request involving a device, discovering an enterprise service associated with the device, selecting a device template associated with the enterprise service to be applied to the device, the device template including a placeholder for a secret value; retrieving data associated with the placeholder from the enterprise service; and applying configuration data associated with the device template to the device, the configuration data including data associated with the secret value.

[0095] Another example can include any of the above and / or below examples where data associated with the secret value is encrypted.

[0096] Another example may include any of the above and / or below examples where data associated with the secret value is decrypted by the device.

[0097] Another example may include any of the above and / or below examples where the check-in request includes a device state of the device.

[0098] Another example may include any of the above and / or below examples where the method further includes periodically comparing the device state to the device template and updating the device to match the device template when the device state differs from the device template.

[0099] Another example may include any of the above and / or below examples, in which the method further includes: when the device is not connected to the network, instructing the device to periodically compare the device status with the device template.

[0100] Another example may include any of the above and / or below examples in which a device state is periodically compared to a device template regardless of a user logged into the device.

[0101] Another example includes a system comprising a processor and a memory storing computer-readable instructions that, when executed by the processor, cause a platform management server to: receive a check-in request from a device; determine an enterprise service from among a plurality of enterprise services based at least on data in the check-in request, the enterprise service being configured to manage configuration of the device; and receive a configuration template from the enterprise service, the configuration template comprising configuration data and at least one placeholder indicating a secret value to be retrieved from the enterprise service upon application of the template to the device.

[0102] Another example can include any of the above and / or below examples in which the configuration data received from the enterprise service is generic configuration data and the platform management server pre-computes device-specific configuration settings corresponding to the device.

[0103] in conclusion

[0104] Although the technical solution has been described in language specific to structural features and / or method actions, it should be understood that the technical solution defined in the appended claims is not necessarily limited to the above-mentioned specific features or actions. Instead, the above-mentioned specific features and actions are disclosed as example forms of implementing the claims, and other features and actions that will be recognized by those skilled in the art are intended to fall within the scope of the claims.

Claims

1. A management server, comprising: processor; as well as A computer-readable storage medium storing instructions, wherein when the instructions are executed by the processor, the management server configures a specific managed device in the following manner: receiving a sign-in request from the specific managed device; determining, based at least on the check-in request, a specific enterprise service associated with the specific managed device, the specific enterprise service being accessible to the management server via a computer network; receiving, via the computer network, generic configuration data from the specific enterprise service associated with the specific managed device; Based at least on hardware or software characteristics of the specific managed device, converting the generic configuration data into device-specific provisioning commands appropriate for the hardware or software characteristics of the specific managed device; and The device specific provisioning command is sent to the specific managed device.

2. The management server according to claim 1, wherein when the instruction is executed by the processor, the management server configures the specific managed device in the following manner: The generic configuration data is converted into the device specific provisioning commands based at least on the device type of the specific managed device.

3. The management server according to claim 1, wherein when the instruction is executed by the processor, the management server configures the specific managed device in the following manner: The generic configuration data is converted into the device specific provisioning commands based at least on the operating system of the specific managed device.

4. The management server according to claim 1, wherein when the instructions are executed by the processor, the management server configures the specific managed device in the following manner: The generic configuration data is converted into the device specific provisioning commands based at least on the instruction set of the specific managed device.

5. The management server according to claim 4, wherein when the instructions are executed by the processor, the management server configures the specific managed device in the following manner: In a first instance where the specific managed device has an ARM instruction set, converting the generic configuration data into at least one ARM specific provisioning command; and In a second instance where the specific managed device has an x86 instruction set, the generic configuration data is converted into at least one x86 specific provisioning command.

6. The management server according to claim 1, wherein when the instructions are executed by the processor, the management server: At least one other enterprise service is blocked from managing the specific managed device.

7. The management server according to claim 6, wherein when the instructions are executed by the processor, the management server: discovering that the specific managed device will only be managed by the specific enterprise service; and In response to discovering that the specific managed device is to be managed only by the specific enterprise service, at least one other enterprise service is prevented from managing the specific managed device.

8. A method performed by a computing device, the method comprising: receiving a check-in request from a specific managed device; determining, based at least on the check-in request, a specific enterprise service associated with the specific managed device, the specific enterprise service accessible to the computing device via a computer network; receiving, via the computer network, generic configuration data from the specific enterprise service associated with the specific managed device; Based at least on hardware or software characteristics of the specific managed device, converting the generic configuration data into device-specific provisioning commands appropriate for the hardware or software characteristics of the specific managed device; and The device specific provisioning command is sent to the specific managed device.

9. The method according to claim 8, further comprising: The generic configuration data is converted into the device specific provisioning commands based at least on a device type of the specific managed device.

10. The method according to claim 8, further comprising: The generic configuration data is converted into the device specific provisioning commands based at least on the operating system of the particular managed device.

11. The method according to claim 8, further comprising: The generic configuration data is converted into the device specific provisioning commands based at least on an instruction set of the specific managed device.

12. The method according to claim 11, further comprising: In a first instance where the specific managed device has an ARM instruction set, converting the generic configuration data into at least one ARM specific provisioning command; as well as In a second instance where the specific managed device has an x86 instruction set, the generic configuration data is converted into at least one x86 specific provisioning command.

13. The method according to claim 8, further comprising: At least one other enterprise service is blocked from managing the specific managed device.

14. The method according to claim 13, further comprising: discovering that the specific managed device will only be managed by the specific enterprise service; and In response to discovering that the specific managed device is to be managed only by the specific enterprise service, at least one other enterprise service is prevented from managing the specific managed device.

15. A computer-readable storage medium storing instructions, wherein when the instructions are executed by the processor, the processor performs an action, wherein the action comprises: receiving a sign-in request from the specific managed device; determining, based at least on the check-in request, a specific enterprise service associated with the specific managed device, the specific enterprise service being accessible via a computer network; receiving, via the computer network, generic configuration data from the specific enterprise service associated with the specific managed device; Based at least on hardware or software characteristics of the specific managed device, converting the generic configuration data into device-specific provisioning commands appropriate for the hardware or software characteristics of the specific managed device; and The device specific provisioning command is sent to the specific managed device.

16. The computer-readable storage medium of claim 15, the actions further comprising: The generic configuration data is converted into the device specific provisioning commands based at least on the device type of the specific managed device.

17. The computer-readable storage medium of claim 15, the actions further comprising: The generic configuration data is converted into the device specific provisioning commands based at least on the operating system of the specific managed device.

18. The computer-readable storage medium of claim 15, the actions further comprising: The generic configuration data is converted into the device specific provisioning commands based at least on the instruction set of the specific managed device.

19. The computer-readable storage medium of claim 18, the actions further comprising: In a first instance where the specific managed device has an ARM instruction set, converting the generic configuration data into at least one ARM specific provisioning command; as well as In a second instance where the specific managed device has an x86 instruction set, the generic configuration data is converted into at least one x86 specific provisioning command.

20. The computer-readable storage medium of claim 15, the actions further comprising: discovering that the specific managed device will only be managed by the specific enterprise service; and In response to discovering that the specific managed device is to be managed only by the specific enterprise service, at least one other enterprise service is prevented from managing the specific managed device.

21. A method performed by a computing device, the method comprising: storing in a database data identifying different enterprise services designated to manage different managed devices; receiving a check-in request from a specific managed device; In response to receiving the check-in request, discovering from the data stored in the database that the specific managed device is to be managed by a specific enterprise service, the specific enterprise service being accessible to the computing device via a computer network; receiving configuration data from the specific enterprise service via the computer network, the configuration data being associated with the specific managed device; determining, based at least on the configuration data, device-specific provisioning commands to be provided to the particular managed device; and The device specific provisioning command is sent to the specific managed device.

22. The method according to claim 21, further comprising: At least one other enterprise service is blocked from managing the specific managed device.

23. The method according to claim 22, further comprising: In response to discovering that the specific managed device is to be managed by the specific enterprise service, a certificate is sent to the specific managed device.

24. The method according to claim 23, further comprising: A sign-in process is performed using the specific managed device, the specific managed device initiating the sign-in process in response to receiving the certificate.

25. The method according to claim 24, further comprising: Determining current configuration data of the specific managed device; determining a difference between the current configuration data for the specific managed device and the configuration data received from the specific enterprise service; and The device specific provisioning command is generated based at least on the difference.

26. The method of claim 22, further comprising: receiving an encrypted value from the specific enterprise service; as well as The encrypted value is sent to the specific managed device.

27. A management server comprising: a database storing data identifying different enterprise services designated to manage different managed devices; processor; as well as A computer-readable storage medium storing instructions, which, when executed by the processor, cause the management server to: receiving a check-in request from a specific managed device; In response to receiving the check-in request, discovering from the data stored in the database that the specific managed device is to be managed by a specific enterprise service, the specific enterprise service being accessible to the management server via a computer network; receiving configuration data from the specific enterprise service via the computer network, the configuration data being associated with the specific managed device; determining, based at least on the configuration data, device-specific provisioning commands to be provided to the particular managed device; and The device specific provisioning command is sent to the specific managed device.

28. The management server of claim 27, wherein the instructions, when executed by the processor, cause the management server to: At least one other enterprise service is blocked from managing the specific managed device.

29. The management server of claim 28, wherein the instructions, when executed by the processor, cause the management server to: In response to discovering that the specific managed device is to be managed by the specific enterprise service, a certificate is sent to the specific managed device.

30. The management server of claim 29, wherein the instructions, when executed by the processor, cause the management server to: A sign-in process is performed using the specific managed device, the specific managed device initiating the sign-in process in response to receiving the certificate.

31. The management server of claim 30, wherein the instructions, when executed by the processor, cause the management server to: Determining current configuration data of the specific managed device; determining a difference between the current configuration data for the specific managed device and the configuration data received from the specific enterprise service; and The device specific provisioning command is generated based at least on the difference.

32. The management server of claim 27, wherein the instructions, when executed by the processor, cause the management server to: receiving an encrypted value from the specific enterprise service; and The encrypted value is sent to the specific managed device.

33. The management server of claim 32, wherein the encrypted value is decrypted by the specific managed device to obtain a secret value unknown to the management server.

34. The management server of claim 27, wherein the device-specific provisioning commands are specific to a specific operating system of the specific managed device.

35. A computer-readable storage medium storing computer-readable instructions, wherein when the computer-readable instructions are executed by a processor, the processor is caused to perform actions, the actions comprising: storing in a database data identifying different enterprise services designated to manage different managed devices; receiving a check-in request from a specific managed device; In response to receiving the check-in request, discovering from the data stored in the database that the specific managed device is to be managed by a specific enterprise service, the specific enterprise service being accessible to the processor via a computer network; receiving configuration data from the specific enterprise service via the computer network, the configuration data being associated with the specific managed device; determining, based at least on the configuration data, device-specific provisioning commands to be provided to the particular managed device; and The device specific provisioning command is sent to the specific managed device.

36. The computer-readable storage medium of claim 35, the actions further comprising: At least one other enterprise service is blocked from managing the specific managed device.

37. The computer-readable storage medium of claim 36, the actions further comprising: In response to discovering that the specific managed device is to be managed by the specific enterprise service, a certificate is sent to the specific managed device.

38. The computer-readable storage medium of claim 37, the actions further comprising: A sign-in process is performed using the specific managed device, the specific managed device initiating the sign-in process in response to receiving the certificate.

39. The computer-readable storage medium of claim 35, the actions further comprising: Determining current configuration data of the specific managed device; determining a difference between the current configuration data for the specific managed device and the configuration data received from the specific enterprise service; and The device specific provisioning command is generated based at least on the difference.

40. The computer-readable storage medium of claim 35, the actions further comprising: receiving an encrypted value from the specific enterprise service; as well as The encrypted value is sent to the specific managed device.

Images