Provisioning management engine in a cloud access management system

Abstract

Methods, systems, and computer storage media for providing provisioning management using a provisioning management engine of a cloud access management system are described. The provisioning management engine supports provisioning a fully-prepared remote client without assigning a user. In particular, an agent-driven Device Preparation Profile (DPP), enables fast provisioning of fully-prepared remote clients without any user interaction (e.g., user login). Remote clients are ready for immediate use by a user, ensuring compliance with organizational policies and seamless access to required resources from the first login of users. In operation, a device preparation profile (DPP) identifier associated with a DPP is accessed. DPP is associated with agent-driven device preparation operations. A remote client is assigned to the DPP identifier. The remote client is initialized to cause enrollment of the remote client with a device management engine. A provisioning status associated with provisioning the remote client is received. The provisioning status is communicated.

Description

PROVISIONING MANAGEMENT ENGINE IN A CLOUD ACCESS MANAGEMENT SYSTEMBACKGROUND

[0001] Users rely on computing environments with applications and services to accomplish computing tasks. Distributed computing systems (or cloud computing platforms) host and support different types of applications and services in managed computing environments. In particular, a cloud computing platform can implement a cloud access management system that provides access management functionality for different types of cloud computing offerings. For example, a cloud access management system can support onboarding organizations for different types of cloud computing offerings –including managed desktop services that include virtual machines assigned to individual users as virtual desktop devices configured with productivity, security, and collaboration tools.SUMMARY

[0002] Various aspects of the technology described herein are generally directed to systems, methods, and computer storage media for, among other things, providing provisioning management using a provisioning management engine of a cloud access management system provisioning management engine. The provisioning management engine supports provisioning fully-prepared remote clients without assigning a user. In particular, an agent-driven Device Preparation Profile (DPP) , enables fast provisioning of fully-prepared remote clients without user interaction (e.g., user login) . A fully-prepared remote client refers to a remote client that is configured using an assigned DPP, the assigned DPP is associated with applications, scripts, security policies, and network settings that are installed and verified on the fully-prepared remote client. The remote client is ready for immediate use by a user, ensuring compliance with organizational policies and seamless access to required resources from the first login.

[0003] The provisioning management engine leverages an agent-driven DPP provisioning policy manager, a device management engine, a remote client provisioning engine, a DPP plugin, and a bootstrapping agent to support provisioning fully-prepared remote clients. The DPP refers to a provisioning configuration associated with agents, applications, and / or scripts that enables the remote client to receive policies, updates, and applications from the device management engine. Notably, the DPP defines the agents, applications, and / or scripts that support remote client preparation without assignment of the remote client to a user or user group.

[0004] The DPP is an agent-driven DPP that is different from a user-driven DPP. The DPP can be specifically designed for virtual machines to bypass an Out-of-Box Experience (OOBE) stage during remote client provisioning and preparation. The DPP also enables bypassing user interaction to prepare the remote client. As such, when a user first logs into a remote client, the user will experience a significantly faster login without waiting for remote client preparation operations (e.g., application installation or script execution during login) .

[0005] Conventionally, cloud access management systems are not configured with a comprehensive computing logic and infrastructure to efficiently provide fully-provisioned remote clients without user interaction. The provisioning of remote clients often relies heavily on user-driven setups. This traditional model requires user login to trigger key setup steps, like application installations and policy configurations. However, this traditional approach introduces several significant drawbacks, including a dependency on user login, resource-intensive maintenance of custom operating system (OS) images, and limited flexibility for user-less enrollments. For example, the current setup process for devices relies heavily on user interaction during the OOBE and / or a setup experience (e.g., Enhanced Setup Experience (ESP) ) , causing delays in achieving full device readiness until after the user logs in. This leads to longer wait times and disrupts productivity as applications and configurations install only after the user has logged in.

[0006] Additionally, under conventional approaches, administrators create and maintain custom OS images with pre-installed applications and configurations to streamline the setup process. Maintenance of the custom OS images can be resource-intensive and lack flexibility in dynamic environments, where business needs and technology evolve quickly. In such environments, software requirements can change frequently, new applications may be introduced, and security updates or patches need to be applied regularly. As a result, maintaining and updating these custom OS images becomes complex and time-consuming, as administrators must repeatedly create and test new images to keep up with changes. Furthermore, existing systems primarily focus on assigning profiles to specific users, which creates challenges in scenarios like shared workstations or pooled resources, where devices need to be prepared without being tied to a particular user. As such, a provisioning management solution is necessary to ensure improved performance (e.g., operations and interfaces) for computing functionality and user satisfaction in provisioning and preparing remote clients.

[0007] A technical solution –to the limitations of conventional device management systems –can include providing provisioning management resources via a provisioning management engine in a cloud access management system. Provisioning management resources management resources enable the orchestration of remote client provisioning and preparation using a provisioning management engine. The provisioning management engine is designed to overcome the challenges in cloud access management systems by implementing a streamlined, user-independent device preparation process. This is achieved through the use of an agent-driven Device Preparation Profile (DPP) , a configuration that enables fast and secure provisioning of remote clients without requiring a user to initiate the setup process. This technical approach not only improves setup efficiency but also enhances security, scalability, and flexibility across virtual device environments.

[0008] In operation, in a first embodiment, a DPP identifier associated with a DPP is accessed at a remote client provisioning engine. The DPP is associated with agent-driven device preparation operations. A remote client is assigned to the DPP identifier. The remote client is initialized to cause enrollment of the remote client with a device management engine. A provisioning status associated with provisioning the remote client is received at the remote client provisioning engine. The provisioning status is communicated and caused to be displayed.

[0009] In a second embodiment, a request to generate a DPP is accessed at a device management engine. A DPP associated with a DPP identifier is generated based on the request. The DPP identifier is communicated to a provisioning policy manager. A request to download a bootstrapping agent is received at the device management engine from a DPP plugin associated with the DPP identifier and a remote client. The bootstrapping agent is communicated to the remote client. The remote client is enrolled based on agent-driven device preparation operations associated with the device management engine to cause provisioning of the remote client.

[0010] In a third embodiment, a request to download a bootstrapping agent is requested by a DPP plugin on a remote client. The request is associated with a DPP identifier. DPP configuration comprising enrolling and provisioning the remote client is enabled at the remote client via the bootstrapping agent. The remote client is enrolled based on agent-deice preparation operations associated with a device management engine. The remote client is provisioned as a fully-prepared remote client with user interaction.

[0011] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The technology described herein is described in detail below with reference to the attached drawing figures, wherein:

[0013] FIG. 1A is a block diagram of an exemplary cloud access management system including a provisioning management engine, in accordance with aspects of the technology described herein;

[0014] FIGS. 1B and 1C are flow diagrams associated with an exemplary cloud access management system including a provisioning management engine, in accordance with aspects of the technology described herein;

[0015] FIGS. 2A and 2B are flow diagrams associated with an exemplary cloud access management system including a provisioning management engine, in accordance with aspects of the technology described herein;

[0016] FIG. 3 provides a first exemplary method of providing provisioning management using a provisioning management engine, in accordance with aspects of the technology described herein;

[0017] FIG. 4 provides a second exemplary method of providing provisioning management using a provisioning management engine, in accordance with aspects of the technology described herein;

[0018] FIG. 5 provides a third exemplary method of providing provisioning management using a provisioning management engine, in accordance with aspects of the technology described herein;

[0019] FIG. 6 provides a block diagram of an exemplary cloud access management system suitable for use in implementing aspects of the technology described herein;

[0020] FIG. 7 provides a block diagram of an exemplary distributed computing environment suitable for use in implementing aspects of the technology described herein; and

[0021] FIG. 8 is a block diagram of an exemplary computing environment suitable for use in implementing aspects of the technology described herein.DETAILED DESCRIPTION

[0022] OVERVIEW

[0023] A cloud access management system supports user identities and access management in the cloud. The cloud access management system can, for example, give both onsite and remote employees seamless access to their organization’s resources, enable secure and seamless access to applications, and protect and govern access. For example, the cloud access management system can efficiently manage identities by ensuring the right people have the right access to the right resources. The cloud access management system can further support access to different types of cloud offerings. For example, a cloud access management system can support onboarding organizations for different types of cloud computing offerings –including managed desktop services that include virtual machines assigned to individual users as virtual desktop devices configured with productivity, security, and collaboration tools.

[0024] A device management system provides device management functionality for different types of devices in computing environments. The device management system ensures manageability, security, and compliance of devices within a computing network (e.g., an organizational network) , particularly in environments where Bring Your Own Device (BYOD) or corporate-owned, personally enabled (COPE) policies are in place. Device management can include monitoring and securing managed devices and / or unmanaged devices within a computing environment network. Device management provides administrators with centralized control over devices, allowing them to enforce policies, deploy applications, configure settings, and ensure compliance with security requirements. Device management can be implemented based on additional services including policy management services and provisioning services.

[0025] Conventionally, cloud access management systems are not configured with a comprehensive computing logic and infrastructure to efficiently provide fully-provisioned remote clients without user interaction. Traditionally, provisioning remote clients requires user-driven processes where device setup and application installations depend on a user logging in to initiate setup. However, this approach introduces several significant drawbacks, including a dependency on user login, resource-intensive maintenance of custom OS images, and limited flexibility for user-less enrollments.

[0026] Currently, Out-Of-Box Experience (OOBE) and setup experience (e.g., Enhanced Setup Experience (ESP) ) processes require user interaction to complete device setup. This leads to delays, as end users must wait for applications and configurations to finish installing post-login. The dependency on user login hinders productivity, causing login times to stretch from seconds to minutes as the setup completes. To streamline setup, administrators frequently maintain custom operating system (OS) images preloaded with necessary applications and configurations. This is a resource-heavy solution, consuming time and limiting flexibility, especially in fast-changing, dynamic environments. Existing enrollment processes often necessitate assigning profiles directly to users, which restricts flexibility in cases like shared workstations or resource pools, where devices need to be provisioned without a user-specific assignment. As such, a comprehensive provisioning management system –with an alternative basis for performing provisioning management operations –can improve computing operations and interfaces in cloud access management systems.

[0027] DESCRIPTION OF TECHNICAL SOLUTION

[0028] At a high level, a provisioning management engine supports provisioning a fully-prepared remote client without assigning a user. In particular, an agent-driven Device Preparation Profile (DPP) enables fast provisioning of fully-prepared remote clients without user interaction (e.g., user login) . A fully-prepared remote client refers to a remote client that is configured using an assigned DPP, the assigned DPP is associated with applications, scripts, security policies, and network settings that are installed and verified on the fully-prepared remote client. The fully-prepared remote client is ready for immediate use by a user, ensuring compliance with organizational policies and seamless access to required resources from the first login.

[0029] By way of background, tenant and user information are often necessary for remote devices to join a cloud access management system including a device management system. Such device management systems employ user-driven enrollments because they rely on a DPP assigned to the user to proceed with enrollment. The present technical solution enables registering remote clients without needing a specific user assignment. This is achieved by using a provisioning management engine including a device management engine which allocates applications to remote client groups through a new agent-driven DPP linked by the remote client identifier. The provisioning management engine enables dynamic provisioning through agent-driven DPPs. Unlike traditional OS images, which rely on pre-built, static configurations, the agent-driven solution dynamically provisions and configures devices in real time. Policies, applications, and settings are applied based on agent-driven DPP operations that eliminate the need for pre-built images.

[0030] For example, with agent-driven DPP operations, a remote employee’s device is automatically provisioned based on a DPP identifier associated with a group. The system dynamically installs necessary applications, applies role-specific security policies, and configures tools-all without needing a pre-built OS image. This eliminates the need for manual image updates or rebuilding. This dynamic approach allows for seamless updates and modifications without the overhead of creating or deploying new OS images. In particular, OS images are fixed snapshots of operating systems that include a predetermined set of configurations, applications, and policies. Deploying these images onto devices requires significant manual effort when updates are needed, as new images must be created and redeployed. For example, if a new application is required, the agent-driven solution can install it dynamically during provisioning. With OS images, however, introducing the same application would necessitate rebuilding and redistributing the entire image, making it less efficient and adaptable in dynamic environments.

[0031] A DPP plugin in a remote client –associated with a DPP identifier –initiates the application installation process independently of user login, preparing the remote client in advance and removing the requirement for user assignment. In contrast, the current ESP / OOBE process necessitates user login and interaction. Remote clients can employ the DPP plugin instead of relying on built-in OOBE components, allowing remote client setup. A remote client can be updated with the DPP plugin and a bootstrapping agent to detect agent-driven provisioning and engage with the device management engine upon installation. The bootstrapping agent may operate as a sidecar agent that employs a sidecar Application Programming Interface (API) to communicate with a device management engine for performing agent-driven device preparation operations.

[0032] The provisioning management engine maximizes remote client preparation before the user’s initial remote client login. By updating the device management engine to integrate with the DPP plugin, applications are installed immediately upon enrollment, reducing login time from several minutes to just seconds. The remote client is provisioned fully compliant and secure, pre-configured with the necessary security and compliance settings. Users receive a fully-prepared remote client at login, avoiding post-login installations of compliance applications and / or scripts.

[0033] Operationally, the provisioning management engine is a multi-component architecture that integrates several key engines and profiles, including a provisioning policy manager, device management engine, remote client provisioning engine, DPP plugin, and bootstrapping agent to deliver a fully-prepared, user-ready remote client without the need for user interaction. In some examples, the provisioning workflow includes the following steps: accessing and assigning a DPP identifier; initialization and enrollment; bootstrapping and setup; and provisioning completion (e.g., completion state) and status reporting. The completion state, based on provisioning progress, represents the stage where all provisioning tasks-such as application installations, security configurations, and network setups-are successfully executed, and the remote client transitions to a fully operational and ready-to-use status as indicated by the final provisioning status update.

[0034] Accessing and assigning a DPP identifier begins with the provisioning policy manager accessing a DPP identifier associated with agent-driven device preparation operations and configuration. The remote client is then assigned to this DPP identifier, linking it to the set of predefined agent-driven setup operations.

[0035] Upon assignment, during an initialization and enrollment phase, the remote client provisioning engine initializes the remote client, prompting it to enroll with the device management engine. During this phase, the DPP plugin installed on the remote client requests a bootstrapping agent, responsible for triggering the DPP configuration.

[0036] The bootstrapping agent enables bootstrapping and setup. The bootstrapping agent may be sidecar implementation, where a sidecar software component or service that runs alongside a primary application to provide additional functionality or support, typically without modifying the main application’s core processes. The bootstrapping agent, which operates as a “sidecar” agent to the DPP plugin, utilizes API calls to complete the configuration process, including the enrollment and provisioning of the remote client. The bootstrapping agent installs applications, executes scripts, and enforces policies as defined in the DPP.

[0037] A provisioning and status report is facilitated by the DPP plugin and communicates provisioning status back to the provisioning policy manager, providing real-time updates on setup progress. Once complete, the remote client is fully prepared and does not require any additional setup at the time of user login.

[0038] By way of illustration, to initiate the agent-driven DPP workflow, the provisioning policy manager sends a request to the device management engine to generate a DPP specifically designed for agent-driven setup. The agent-driven DPP enables device configuration without requiring any user interaction. The device management engine then creates the DPP, assigning it a unique identifier, which links the DPP to specific policies, scripts, and / or applications for installation on the remote client. The provisioning policy manager assigns this DPP identifier to a remote client, making the remote client ready for configuration under the specified DPP.

[0039] As a remote client boots, a DPP plugin detects the assigned DPP identifier, recognizing that the remote client is to be set up through an agent-driven process. The DPP plugin then initiates the download of a bootstrapping agent associated with the DPP, which drives the enrollment and provisioning operations on the remote client. Once downloaded on the remote client, the bootstrapping agent connects to the device management engine via an API, initiating application installation, script execution, and security policy enforcement as defined by the DPP.

[0040] The bootstrapping agent then performs a series of automated installations and configurations, applying security measures such as antivirus installation, firewall settings, and user restrictions to ensure compliance with security standards. It also configures network settings according to DPP specifications, setting up Virtual Private Network (VPN) configurations, network access permissions, and any other required security protocols to align the device with organizational policies.

[0041] Throughout this process, the DPP plugin monitors the provisioning progress, providing real-time status updates back to the provisioning policy manager. These updates track the remote client’s preparation stage, from initial setup through to completion. Once provisioning is complete, the remote client is fully configured and ready for user access. The setup includes all necessary applications, security policies, and network configurations, ensuring the device is ready for immediate use. When a user logs in for the first time, they find a fully prepared remote client, with no further software installations or policy applications required. This pre-configuration results in a seamless and quick login experience, allowing employees to begin working without any setup delays, ultimately enhancing productivity.

[0042] Advantageously, the embodiments of the present technical solution include several inventive features (e.g., operations, systems, engines, and components) associated with a cloud access management system having a provisioning management engine. The provisioning management engine optimizes the setup of remote clients by using agent-driven DPPs to deliver fully configured, user-ready devices without the need for user interaction. This technical approach not only improves setup efficiency but also enhances security, scalability, and flexibility across virtual device environments. In particular, by bypassing the traditional user-driven OOBE and setup experience (e.g., ESP) processes, the provisioning management engine significantly reduces login times for end users. Users can access a fully prepared device immediately, with login times reduced from minutes to seconds. The agent-driven DPP allows for user-less device setup, making it ideal for shared workstations, pooled resources, or any scenario requiring flexible, on-demand provisioning. The provisioning management engine ensures that configurations are applied prior to user login, delivering a fully-prepared remote client, without relying on post-login configurations.

[0043] EXAMPLE SYSTEMS AND RESOURCES

[0044] Aspects of the technical solution can be described by way of examples and with reference to FIGS. 1A –1C, 2A, and 2B. FIG. 1A illustrates a cloud computing environment (system) 100, cloud access management system 100A, provisioning management engine 110, provisioning management resources 120, provisioning policy manager 130, device management engine 140 including DPP configuration 142 and DPP identifier 144, remote client provisioning engine 150, remote client 160 including DPP plugin 162, bootstrapping agent 164, and remote desktop agent 166, cloud access management client 170 including device management client 172, and local client 180 including remote desktop client 182.

[0045] The technical solution can be implemented on cloud access management system 100A that is designed to streamline and automate the provisioning of remote clients. By removing dependencies on user logins, cloud access management system 100A enables preparing devices quickly and securely. Cloud access management system 100A centralizes identity, security, and provisioning policies for remote clients across multiple environments. Cloud access management system 100A authenticates devices, enforces compliance policies, assigns provisioning configurations, and manages user access securely.

[0046] Provisioning management engine 110 manages the end-to-end provisioning of remote clients without requiring user interaction. Provisioning management engine 110 manages DPP identifiers, device configurations, and provisioning status for each device. Provisioning management engine 110 exposes interfaces for the provisioning policy manager 130 to generate agent-driven DPPs and to connect to the remote client provisioning engine 150 to assign agent-driven DPPs to remote clients. Provisioning management engine 110 coordinates the provisioning process by assigning DPPs to remote clients, overseeing the configuration and deployment of remote clients.

[0047] Provisioning management resources 120 include the assets and scripts necessary for provisioning. For example, provisioning management resources 120 can include application installers, configuration scripts, security policies, and resource templates. Provisioning management resources 120 facilitate DPP configuration of remote clients via the device management engine 140. For example, pre-configured templates and scripts for remote clients can be used to ensure remote clients are prepared with the necessary resources immediately upon activation.

[0048] Provisioning policy manager 130 manages provisioning policy configurations and DPP generation within the provisioning management engine 110. Provisioning policy manager 130 stores provisioning policies and DPP identifiers (e.g., DPP identifiers 144 from the device management engine) . Provisioning policy manager 130 exposes APIs (e.g., provisioning policy manager API 132) for administrators to configure provisioning policies and cause generation of DPPs. Provisioning policy manager 130 also communicates with the device management engine 140 to retrieve DPP identifiers (i.e., DPP identifier 144) . Provisioning policy manager 130 further supports administering the DPP lifecycle, from creation to assignment to remote clients.

[0049] Device management engine 140 executes device configuration and management, applying DPPs for fully automated provisioning. Device management engine 140 manages DPP configurations and DPP identifiers (e.g., DPP configuration 142 and DPP identifier 144) which link remote clients to specific setup profiles. Device management engine 140 interfaces with a remote client (e.g., via DPP plugin 162) to provide and apply bootstrapping agents and DPPs to remote clients. Device management engine 140 enrolls remote clients by applying configurations from DPPs, installing applications, and enforcing security policies based on DPP metadata.

[0050] DPP configuration 142 defines device setup rules and policies within the DPP. DPP configuration 142 can include setup rules, assigned applications, security policies, and network configurations. DPP configuration 142 can support configuring remote clients according to organizational specifications, ensuring consistent deployment.

[0051] DPP identifier 144 is a unique identifier assigned to each DPP, used to link a specific configuration to a remote client. DPP identifier may contain metadata associating the DPP with specific device configurations and policies. DPP identifier 144 ensures that each remote client is accurately provisioned by linking it to the appropriate DPP.

[0052] Remote client provisioning engine 150 is responsible for executing provisioning commands on the remote client 160 based on the assigned DPP. Remote client provisioning engine 150 manages enrollment statuses, provisioning progress, and configuration statuses. Remote client provisioning engine 150 communicates with the remote client 160 to apply DPPs and receive status updates from the remote client. Remote client provisioning engine 150 enables enrolling and preparing remote clients by initiating application and policy installations as directed by the DPP. Remote client provisioning engine 150 monitors and reports the provisioning progress to device management client 172..

[0053] Remote client 160 refers to the target virtual machine or endpoint being configured. Remote client 160 includes components necessary for executing and monitoring provisioning steps, enabling it to be fully operational and accessible immediately upon login. Remote client 160 can store provisioning status, configuration details, and installed application logs. Remote client 160 connects to device management engine 140 through the DPP plugin 162 and bootstrapping agent 164. Remote client 160 executes provisioning commands, installs necessary software, configures network settings, and applies security measures as defined by the DPP.

[0054] DPP plugin 162 acts as the intermediary on the remote client 160, detecting the DPP identifier 144 and initiating the provisioning process. DPP plugin 162 may retrieve the DPP identifier (e.g., DPP identifier 144) , which triggers the provisioning operations, or a link thereto. DPP plugin 162 communicates with the device management engine 140 to request and download the bootstrapping agent 164. DPP plugin 162 may further monitor the remote client configuration status and ensure that DPP operations are completed accurately.

[0055] Bootstrapping agent 164 is responsible for installing applications, enforcing policies, and managing security configurations as per the DPP on the remote client 160. Bootstrapping agent 164 may be a sidecar agent. Bootstrapping agent 164 stores installation logs, policy application statuses, and configuration settings. Bootstrapping agent 164 connects to the device management engine 140 via API calls to retrieve and apply provisioning resources. Bootstrapping agent 164 executes DPP-based configurations, including application installations and network settings, ensuring the remote client 160 is fully prepared for use.

[0056] Remote desktop agent 166 facilitates user access and interaction on the remote client 160 once provisioning is complete. Remote desktop agent 166 may manage session configurations, user profiles, and security settings. Remote desktop agent 166 may also maintain connection protocols, allowing users to securely access the remote client 160 without further setup.

[0057] Cloud access management client 170 enables (e.g., via a local device) for an administrator to connect to organizational resources and policies. Cloud access management client 160 acts as a bridge to the cloud access management system 100A, enforcing identity and access management protocols. Device management client 172 is the local representation of the device management engine 140 on the cloud access management client 170, enabling monitoring and enforcement of policies. Device management client 172 supports managing application of device policies locally, synchronizing with the device management engine for real-time operations.

[0058] Local client 180 is an endpoint on the end-user’s device, providing access to the remote client 160. Local client 180 provides access to the remote client 160 through the remote desktop client 182 and facilitates secure access and relays a user session to the remote client 160. Remote desktop client 182 enables the user’s local device to connect with the remote client 160, providing a user experience for performing remote operations. Remote desktop client 172 can store session metadata and connection information and manages user access to the remote client 160, handling secure session initialization and termination.

[0059] In this way, during agent-driven device preparation, remote clients can be provisioned entirely through automated operations managed by a bootstrapping agent 164, eliminating the need for any user interaction during setup. This method contrasts with user-driven device preparation, where user input is required to initiate and complete device provisioning. Specifically designed for virtual machines, agent-driven operations bypass the OOBE stage, which is typically a user-driven component in traditional setups. By bypassing OOBE, agent-driven provisioning enables remote clients to be fully configured without user intervention, ensuring that the device is ready for immediate use as soon as the setup completes.

[0060] The agent-driven preparation process begins by automatically applying system configurations tailored to the organization’s requirements. For example, the bootstrapping agent 164 can set language, time zone, and network preferences without prompting the user. It also enforces security protocols by installing antivirus software, configuring firewalls, and / or applying encryption standards that meet corporate compliance requirements, all without any user action.

[0061] Beyond initial configurations, the bootstrapping agent 164 installs necessary applications based on the DPP associated with each role. For example, appropriate productivity tools, project management software, and communication applications are installed. The bootstrapping agent 164 also customizes the device through role-based scripts that establish specific settings or permissions. Throughout the setup, the bootstrapping agent 164 monitors and reports progress back to the provisioning policy manager 130, for example, allowing IT professionals to track provisioning in real-time and receive updates on any issues that may require their attention.

[0062] By removing the need for user interaction, agent-driven device preparation operations streamline the setup process, reduce errors, and ensure that devices meet organizational standards before employees ever log in. This approach is particularly advantageous in virtual environments where time-sensitive deployment and immediate accessibility are critical. With agent-driven provisioning, a user gains access to a fully-prepared remote client that is secure, compliant, and ready for productivity from the moment they first log in.

[0063] With reference to FIG. 1B, FIG. 1B illustrates a flow diagram associated with a provisioning management engine. The provisioning management engine is configured to execute the provisioning of remote clients using an agent-driven DPP, bypassing the need for user interaction. A step-by-step example of the provisioning process includes:

[0064] Step 101B –Provisioning policy manager 130 initiates a provisioning request by causing the device management engine 140 to generate a DPP. This request may specify that the DPP should be an agent-driven setup, enabling the provisioning of devices without user intervention. The provisioning request includes specifications for the policies, applications, and security configurations required by the remote client, as well as any network configurations mandated by the organization.

[0065] Step 102B –In response to the provisioning request, device management engine 140 generates the requested DPP for DPP configuration management. This DPP includes all necessary setup instructions, such as application installers, security policy definitions, and network settings that the remote client must adopt. A DPP identifier is assigned to uniquely identify this DPP. Once created, the device management engine 140 communicates the DPP identifier back to the provisioning policy manager 130, linking the profile with the provisioning request.

[0066] Step 103B –Provisioning policy manager 130 sends the DPP identifier, along with any associated provisioning policy group identifier (if applicable) , to the remote client provisioning engine 150. The provisioning policy group identifier may represent a collection of devices or users under similar provisioning requirements, providing a streamlined way to enforce uniform configurations across multiple remote clients. The DPP identifier allows the remote client provisioning engine to access and enforce specific policies defined by the DPP for the assigned remote clients.

[0067] Step 104B –Remote client provisioning engine 150 assigns a unique remote client identifier to the DPP identifier, establishing a direct link between the DPP and the specific remote client to be provisioned. Remote client provisioning engine 150 initializes the remote client 160 associated with the DPP identifier, triggering the initial enrollment process through the device management engine 140. During this initialization, the remote client 160 is set up with DPP plugin 162 configured to interact seamlessly with the device management engine 140, allowing it to manage provisioning tasks on the remote client in an agent-driven manner.

[0068] Step 105B –DPP plugin 162 on the remote client detects the DPP identifier assigned to it, and this triggers the download of a bootstrapping agent 164 onto the device. Bootstrapping agent 164 (e.g., a sidecar agent) supports provisioning, as it coordinates the initial installation of applications, security policies, and / or network configurations per the DPP.

[0069] Step 106B –The DPP plugin 162 also activates the bootstrapping agent 164 on the remote client, which works in conjunction with a dedicated bootstrapping agent API. The bootstrapping agent API enables the bootstrapping agent 164 to communicate with the device management engine 140, ensuring that DPP configurations are applied accurately to the remote client.

[0070] At step 107B, bootstrapping agent 164 on the remote client 160 accesses the DPP identifier and syncs the DPP identifier with the device management engine 140, prompting it to begin the complete provisioning sequence. This process includes the automated installation of applications including scripts specified in the DPP, the enforcement of security settings (such as firewall configurations and access controls) , and the application of network configurations like VPN setup and domain access. By following the DPP specifications, the bootstrapping agent ensures that the remote client 160 is fully prepared for end-user use, with all necessary components and policies in place.

[0071] Step 108B –Throughout the provisioning process, the DPP plugin 162 continuously monitors the status of the remote client 160, tracking progress and any issues that may arise. DPP plugin 162 provides real-time updates on the remote client preparation progress and status back to the remote client provisioning engine 150 ensuring administrators have visibility into the readiness of the remote client 160. This reporting allows administrators to verify successful configuration and address any provisioning errors, ensuring that the remote client 160 meets all specified requirements and is prepared for immediate use upon completion.

[0072] With reference to FIG. 1C, FIG. 1C illustrates a flow diagram associated with a provisioning management engine. The provisioning management engine is configured to execute the provisioning of remote clients using an agent-driven DPP, bypassing the need for user interaction. A step-by-step example of the provisioning process includes:

[0073] Step 101C: Initiating the DPP with the provisioning policy manager including communicating a provisioning policy request, DPP generation, and assignment of DPP to remote client. An administrator communicates a request from the provisioning policy manager to the device management engine to generate a DPP. This request specifies that the DPP should use an agent-driven setup, allowing devices to be configured without any user login interaction. The device management engine receives the request and generates the DPP, which is associated with a unique DPP identifier. This identifier links the DPP to specific policies, scripts, and / or applications that are to be installed on the remote client. The provisioning policy manager assigns the generated DPP identifier to a remote client in the provisioning queue, preparing them to be configured under this profile.

[0074] Step 102C: Bootstrapping the remote client with the DPP including DPP plugin activation, requesting the bootstrapping agent, and bootstrapping agent configuration. As a remote client boots up, a DPP plugin on the remote client detects the assigned DPP identifier. This DPP plugin recognizes that the remote client is to be set up through an agent-driven process. The DPP plugin sends a request to download a bootstrapping agent associated with the DPP. This bootstrapping agent drives the enrollment and provisioning operations on the remote client. The bootstrapping agent is downloaded onto the remote client and uses an API to connect to the device management engine. Through these API, the bootstrapping agent begins installing applications, running scripts, and applying security policies as defined in the DPP.

[0075] Step 103C: Provisioning and configuration including automated application installation and security policy enforcement and network configuration and access control. The bootstrapping agent installs applications (e.g., productivity suite, communication tools, and any other required software) . It also applies security configurations (e.g., antivirus installation, firewall settings, and user restrictions) , ensuring the remote client security standards. The bootstrapping agent configures the remote client network settings to align with DPP specifications. It may also set up VPN configurations, network access permissions, and any other network security protocols that are required.

[0076] Step 104C: Completion and status reporting including provisioning status updated and deploying fully-prepared remote clients. Throughout the process, the DPP plugin monitors provisioning progress and communicates status updates back to the provisioning policy manager. This status includes real-time updates on a remote client’s preparation state, from initial setup through to completion. Once the provisioning is complete, the remote client is now fully configured and ready for the user. The device setup is complete with all necessary applications, security policies, and network configurations in place.

[0077] Step 105C: User’s first login and immediate accessibility including instant accessibility and user productivity. When a user logs into their remote client for the first time, they are greeted with a fully-configured remote client. There is no delay for additional software installations or policy configurations, as everything was handled during the provisioning phase. The login process is quick, taking only seconds. Since the remote client is pre-configured, employees can begin working immediately without waiting for setup, reducing downtime and increasing productivity.

[0078] With reference to FIGS. 2A and 2B, FIG. 2A illustrates a schematic associated with a conventional user-driven DPP workflow and FIG. 2B illustrates a schematic associated with the present agent-driven DPP workflow. As discussed, provisioning a remote client conventionally involves a user-driven process, relying heavily on user interaction for initial setup, while an agent-driven DPP eliminates the dependency on user-specific assignments and user interaction.

[0079] The user-driven DPP workflow and the agent-driven DPP workflow are distinct in how they approach remote client provisioning and the level of user involvement required. The user-driven workflow depends on active user participation. A user logs into the remote client, engages in specific configuration steps, and verifies credentials when prompted. A user-driven DPP workflow is often used in cases that require user-specific settings, preferences, or confirmations, making it suitable for environments where individual customization is essential. For instance, it may be used for employees who need tailored configurations based on their roles, where a sales team member might require a different suite of applications than an engineering user. This setup prioritizes customization and allows the system to adapt to various roles within the same environment, relying on the user’s interaction to initiate and guide parts of the configuration process.

[0080] The agent-driven DPP workflow, on the other hand, operates independently of user input, enabling fully automated provisioning. In this model, all necessary configurations, applications, and policies are applied uniformly without requiring the user to log in or engage with the system. However, this workflow can still accommodate lighter-weight user customization as part of outside of a set of baseline agent-driven DPP operations. For example, an employee associated with a remote client would find the core provisioning automated and standardized, but employee could still personalize their experience. This approach maintains a baseline configuration agent-driven DPP configuration while providing users with the freedom to make non-critical customizations, ensuring both efficiency and user satisfaction.

[0081] Once the DPP is assigned and the bootstrapping agent is activated, the process moves forward autonomously. This approach can be designed for cases where uniformity and consistency across devices are prioritized, such as in shared or multi-user environments like kiosks, educational institutions, or managed IT deployments. By bypassing the need for user interaction, the agent-driven DPP workflow allows remote clients to be prepared and configured before the user’s first login, minimizing setup time and ensuring remote clients are immediately functional upon first use.

[0082] In contrast to the user-driven DPP’s emphasis on individual customization, the agent-driven DPP workflow focuses on enforcing organizational standards and is ideal for situations where rapid, large-scale provisioning is needed. Each workflow therefore serves different purposes: the user-driven model supports personalized configurations tailored to user roles and preferences, while the agent-driven model facilitates streamlined, standardized deployment, making it well-suited for scenarios that benefit from automated, user-independent setup processes.

[0083] The user-driven DPP workflow includes the following steps:

[0084] Step 202A –User Login: The provisioning process begins only after the user logs in, initiating interaction with the OOBE and / or setup experience (e.g., ESP) for device setup.

[0085] Step 204A –Register Remote Client: The remote client registers with the remote client provisioning engine, establishing initial connectivity to initiate setup.

[0086] Step 206A –User Authentication and Token Acquisition: The user authenticates through the Enhanced Security Token Service, obtaining a token necessary to register the remote client with the provisioning and device management systems.

[0087] Step 208A –Token Transfer to Device Management Engine: The obtained token is sent to the Device Management Engine, initiating the enrollment process for the remote client.

[0088] Step 210A –Remote client enrollment: The device management engine accesses the user’s enrollment profile and executes the provisioning using a user-driven DPP, which is assigned based on the specific user logging in.

[0089] Step 212A –OOBE Setup via User-Driven DPP: The user-driven DPP directs OOBE setup, which includes authenticating the user’s corporate credentials, assigning a user-specific DPP, and configuring static device settings. This step installs required applications and scripts, forcing the remote client into a specified configuration.

[0090] Step 214A –Remote Client Ready for Use: After the above steps, the remote client is finally ready, with all applications and scripts installed, allowing the user to begin working.

[0091] Turning to FIG. 2B, the agent-driven DPP workflow includes the following steps:

[0092] Step 202B –Remote Client Registration: The remote client registers with the remote client provisioning engine.

[0093] Step 204B –Remote Client Token Acquisition: The remote client receives a token from the remote client provisioning engine to enroll it with the device management engine.

[0094] Step 206B –Remote Client Enrollment: The device management engine accesses the agent-driven DPP using the unique DPP identifier (ID) , retrieving metadata and configuration details necessary for preparing the device according to organizational policies and configurations.

[0095] Step 208B –Remote Client Preparation Using Agent-Driven DPP: The agent-driven DPP initiates remote client preparation, including: employing interfaces to query the operating system and for device preparation operations; bootstrapping (e.g., sidecar) agent is installed to manage applications and scripts installation; essential applications, security policies, and scripts are deployed as per the DPP metadata; and monitoring the provisioning status, ensuring all configurations are successfully applied before completion.

[0096] Step 210B –Device Ready for Use: With the agent-driven DPP, the device is fully prepared before any user login, bypassing the OOBE and setup experience (e.g., ESP) processes, which reduces setup time significantly.

[0097] Step 212B –User Login: When the user logs in for the first time, the device is fully configured, allowing for immediate use without additional provisioning or setup delays.

[0098] EXAMPLE METHODS

[0099] With reference to FIGS. 3, 4, and 5, flow diagrams are provided illustrating methods for providing provisioning management using a provisioning management engine in a device management system. The methods may be performed using the device management system described herein. In embodiments, one or more computer-storage media having computer-executable or computer-useable instructions embodied thereon that, when executed, by one or more processors can cause the one or more processors to perform the methods (e.g., computer-implemented method) in the device management system (e.g., a computerized system) .

[0100] Turning to FIG. 3, a flow diagram is provided that illustrates a method 300 for providing provisioning management using a provisioning management engine in a device management system. FIG. 3 is associated with operations that illustrate the connection between the provisioning policy manager, the remote client provisioning engine, and the remote client itself. This stage sets up the groundwork for linking the remote client to the device management engine. At block 302, the remote client provisioning engine accesses a DPP identifier associated with a DPP from the provisioning policy manager. At block 304, the remote client provisioning engine assigns a remote client to the DPP identifier. At block 306, remote client provisioning engine initializes the remote client to cause enrollment of the remote client with a device management engine. At block 308, remote client provisioning engine receives a provisioning status associated with the provisioning of the remote client. At block 310, communicate the provisioning status to a device management client.

[0101] Turning to FIG. 4, a flow diagram is provided that illustrates a method 400 for providing provisioning management using a provisioning management engine in a device management system. FIG. 4 is associated with operations that create a DPP and associate it with a DPP identifier, which is then communicated to the provisioning policy manager. This operations also include handling requests related to the DPP, such as downloading the bootstrapping agent. At block 402, the device management engine accesses a request to generate a DPP. At block 404, the device management engine generates a DPP associated with a DPP identifier. At block 406, the device management engine communicates the DPP identifier to a provisioning policy manager. At block 408, the device management engine access a request associated with the DPP identifier to download a bootstrapping agent. At block 410, the device management engine communicates the bootstrapping agent. At block 412, the device management engine enrolls the remote client to cause provisioning of the remote client.

[0102] Turning to FIG. 5, a flow diagram is provided that illustrates a method 500 for providing provisioning management using a provisioning management engine in a device management system. FIG. 5 is associated with operations that support execution of the provisioning operations on the remote client, starting with the communication and download of the bootstrapping agent. At block 502, the DPP plugin communicates a request associated with a DPP identifier to download a bootstrapping agent. At block 504, the DPP plugin downloads the bootstrapping agent. At block 506, the bootstrapping agent provisions the remote client without user interaction. Aspects of the technical solution have been described by way of examples and with reference  to FIGS. 1A, 1B, 1C, 2A and 2B. FIG. 1A is a block diagram of an exemplary technical solution environment, based on example environments described with reference to FIGS. 6, 7 and 8 for use in implementing embodiments of the technical solution are shown. Generally the technical solution environment includes a technical solution system suitable for providing the example cloud computing system 100 in which methods of the present disclosure may be employed. In particular, FIG 1A illustrates a high level architecture of the cloud computing system 100 in accordance with implementations of the present disclosure, among other engines, managers, generators, selectors, or components not shown (collectively referred to herein as “components” ) .

[0103] TECHNICAL IMPROVEMENT

[0104] Embodiments of the present techniques have been described with reference to several inventive features (e.g., operations, systems, engines, and components) associated with a device management system. Inventive features described include: operations, interfaces, data structures, and arrangements of computing resources associated with providing the functionality described herein with reference to a provisioning management engine. Functionality of the embodiments of the present technical solution have further been described, by way of an implementation and anecdotal examples –to demonstrate that the operations for providing the provisioning management engine as a solution to a specific problem in device management technology to improve computing operations in cloud computing systems.

[0105] By way of example, the provisioning management engine optimizes the setup of a remote client by using agent-driven DPPs to deliver a fully configured, user-ready device without the need for user interaction. This provisioning management engine maximizes remote client preparation before the user’s initial remote client login. This technical approach not only improves setup efficiency but also enhances security, scalability, and flexibility across virtual device environments. In particular, by bypassing the traditional user-driven OOBE and setup experience (e.g., ESP) processes, the provisioning management engine significantly reduces login times for end users. Users can access a fully prepared device immediately, with login times reduced from minutes to seconds. The agent-driven DPP allows for user-less device setup, making it ideal for shared workstations, pooled resources, or any scenario requiring flexible, on-demand provisioning. The provisioning management engine ensures that all security and compliance configurations are applied prior to user login, delivering a fully compliant, secure device environment without relying on post-login configurations.

[0106] ADDITIONAL SUPPORT FOR DETAILED DESCRIPTION

[0107] EXAMPLE CLOUD ACCESS MANAGEMENT SYSTEM IN A COMPUTING ENVIRONMENT

[0108] Referring now to FIG. 6, FIG. 6 illustrates a computing environment in which implementations of the present disclosure may be employed. In particular, FIG. 6 shows a high level architecture of an example cloud computing platform 600 and cloud access management system 610 that can host a technical solution environment. It should be understood that this and other arrangements described herein are set forth only as examples. For example, as described above, many of the elements described herein may be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location. Other arrangements and elements (e.g., machines, interfaces, functions, orders, and groupings of functions) can be used in addition to or instead of those shown.

[0109] The cloud computing environment 100 provides computing system resources for different types of managed computing environments. For example, the cloud computing platform supports delivery of computing services –including compute, servers, storage, databases, networking, and intelligence. The components of cloud computing environment 600 may communicate with each other over a network 600A which may include, without limitation, one or more local area networks (LANs) and / or wide area networks (WANs) .

[0110] The cloud access management system 610 provides cloud access management functionality for different types of cloud computing offerings. The cloud access management system can be a centralized platform designed to facilitate secure and efficient access to cloud-based resources from various devices, including traditional desktops, laptops, and thin clients. The cloud access management system can include software, hardware, and infrastructure components that enable users to authenticate, connect, and interact with remote resources hosted in the cloud. The cloud access management system manages operations associated with user identities, permissions, and access policies to ensure that only authorized users can access specific resources. Additionally, it may incorporate features such as single sign-on (SSO) , multi-factor authentication (MFA) , and session management to enhance security and user experience.

[0111] Cloud access management system 610 enables secure and efficient access for local clients to remote resources, such as remote clients, through a centralized platform. It encompasses authentication mechanisms to verify the identities of users and devices seeking access, including multi-factor authentication for enhanced security. Authorization protocols govern user permissions and access levels, dictating which resources or applications each user can utilize. Session management functionalities handle the establishment, monitoring, and termination of user sessions, optimizing performance while ensuring compliance with security policies. The cloud access management system also manages connections between local clients and remote clients, employing robust encryption and data integrity measures to protect sensitive information during transmission.

[0112] The cloud access management system 610 includes a cloud access management engine 620 that is a computing environment that supports executing computational tasks associated with the cloud access management system 610. The cloud access management engine 620 can be a hardware or software component that performs computational operations, such as, mathematical calculations, data processing, and algorithm execution. The cloud access management system 610 integrates cloud access management resources 630 into cloud access management system 610 to effectively provide cloud access management in a computing environment.

[0113] The cloud access management resources 630 refer to computing elements (e.g., components, capability, or entities) that collectively enable the cloud access management engine 620 operations. The cloud access management resources 630 encompass a spectrum of computing elements, beginning with the diverse operations the cloud access management resources 630 can perform, ranging from complex computations to data manipulations. Interfaces, an integral part of the cloud access management resources 630, provide the means for both user interaction and seamless integration with external systems, ensuring a dynamic and interactive computing experience. The data facet of the cloud access management resources 630 involves various types: input data, which is the information provided for processing; processing data, representing the data manipulated during computational tasks; and output data, the results generated by the cloud access management engine 620. In this way, the cloud access management resources 630 support the broader cloud access management engine 620 and cloud access management system 610.

[0114] The cloud access management system 610 provisions remote clients (e.g., remote client 640) . A remote client 640 can be virtual desktop environment (e.g., Desktop as a Service –DaaS) . The remote client 640 leverages virtualization, cloud computing, and network technologies to deliver scalable, secure, and cost-effective virtual desktop environments to users, enabling flexible remote access to computing resources from any location, on any device. DaaS providers provide Virtualized Desktop Infrastructures (VDI) that host virtual desktops on servers in their data centers. These virtual desktops are created using virtualization technologies such as hypervisors or containerization platforms. Each virtual desktop includes an operating system, applications, data, and user settings.

[0115] The local client 650 connects to the remote client 640. The local client 650 can be a software application or device installed or used on the end-user's local hardware, such as a desktop computer, laptop, thin client, or mobile device. This client software facilitates the remote connection to the VDI hosted by the remote client provider, allowing end-users to access their virtual desktop environments over the internet. Local client 650 can be a managed client that is centrally controlled and monitored by cloud access management system 610. Managed clients typically have device management software installed or configured on them, allowing administrators to enforce security policies, configure settings, deploy applications, and perform remote management tasks. The local client 650 can be an unmanaged client that operates independently without being centrally controlled or monitored. These devices lack device management software or configurations, and users have full control over their settings and applications.

[0116] The cloud access management system 610 can include a device management system that provides device management functionality for devices in computing environments. The device management system ensures manageability, security and compliance of devices within a computing network (e.g., an organizational network) , particularly in environments where Bring Your Own Device (BYOD) or corporate-owned, personally enabled (COPE) policies are in place. Device management systems can streamline device management processes through automated enrollment methods like over-the-air or dedicated portals, ensuring seamless onboarding onto a computing network. Administrators can remotely configure device settings for consistency and compliance, including Wi-Fi, VPN, email, and security configurations.

[0117] Device management system can support a wide range of features and functionality including: application management features that allow for the distribution, updating, and licensing management of mobile apps, alongside enforcing whitelisting / blacklisting policies; security policies that encompass passcode requirements, encryption, screen lock timeouts, and remote wiping capabilities for lost or stolen devices; monitoring capabilities that provide insights into device usage, compliance, and security events, generating reports for inventory and incident tracking; and remote troubleshooting tools enable administrators to view screens, troubleshoot issues, and perform actions like device rebooting.

[0118] The cloud access management client 660 supports access to cloud access management system 610. Cloud access management client 660 provides a graphical or command-line interface for users or administrators to monitor and manage user sessions to ensure proper termination, timeout, and session activity logging. Configuring authentication methods such as passwords, multi-factor authentication (MFA) , biometrics, or single sign-on (SSO) to verify user identities, and setting up authorization rules and permissions to govern user access to specific resources, applications, or data. The cloud access management client 660 supports centralized access management within a computing environment empowering efficient access administration.

[0119] EXAMPLE DISTRIBUTED COMPUTING SYSTEM ENVIRONMENT

[0120] Referring now to FIG. 7, FIG. 7 illustrates an example distributed computing environment 700 in which implementations of the present disclosure may be employed. In particular, FIG. 7 shows a high level architecture of an example cloud computing platform 710 that can host a technical solution environment, or a portion thereof (e.g., a data trustee environment) . It should be understood that this and other arrangements described herein are set forth only as examples. For example, as described above, many of the elements described herein may be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location. Other arrangements and elements (e.g., machines, interfaces, functions, orders, and groupings of functions) can be used in addition to or instead of those shown.

[0121] Data centers can support distributed computing environment 700 that includes cloud computing platform 710, rack 720, and node 730 (e.g., computing devices, processing units, or blades) in rack 720. The technical solution environment can be implemented with cloud computing platform 710 that runs cloud services across different data centers and geographic regions. Cloud computing platform 710 can implement fabric controller 740 component for provisioning and managing resource allocation, deployment, upgrade, and management of cloud services. Typically, cloud computing platform 710 acts to store data or run service applications in a distributed manner. Cloud computing infrastructure 710 in a data center can be configured to host and support operation of endpoints of a particular service application. Cloud computing infrastructure 710 may be a public cloud, a private cloud, or a dedicated cloud.

[0122] Node 730 can be provisioned with host 750 (e.g., operating system or runtime environment) running a defined software stack on node 730. Node 730 can also be configured to perform specialized functionality (e.g., compute nodes or storage nodes) within cloud computing platform 710. Node 730 is allocated to run one or more portions of a service application of a tenant. A tenant can refer to a customer utilizing resources of cloud computing platform 710. Service application components of cloud computing platform 710 that support a particular tenant can be referred to as a multi-tenant infrastructure or tenancy. The terms service application, application, or service are used interchangeably herein and broadly refer to any software, or portions of software, that run on top of, or access storage and compute device locations within, a datacenter.

[0123] When more than one separate service application is being supported by nodes 730, nodes 730 may be partitioned into virtual machines (e.g., virtual machine 752 and virtual machine 754) . Physical machines can also concurrently run separate service applications. The virtual machines or physical machines can be configured as individualized computing environments that are supported by resources 760 (e.g., hardware resources and software resources) in cloud computing platform 710. It is contemplated that resources can be configured for specific service applications. Further, each service application may be divided into functional portions such that each functional portion is able to run on a separate virtual machine. In cloud computing platform 710, multiple servers may be used to run service applications and perform data storage operations in a cluster. In particular, the servers may perform data operations independently but exposed as a single device referred to as a cluster. Each server in the cluster can be implemented as a node.

[0124] Client device 780 may be linked to a service application in cloud computing platform 710. Client device 780 may be any type of computing device, which may correspond to computing device 700 described with reference to FIG. 7, for example, client device 780 can be configured to issue commands to cloud computing platform 710. In embodiments, client device 780 may communicate with service applications through a virtual Internet Protocol (IP) and load balancer or other means that direct communication requests to designated endpoints in cloud computing platform 710. The components of cloud computing platform 710 may communicate with each other over a network (not shown) , which may include, without limitation, one or more local area networks (LANs) and / or wide area networks (WANs) .

[0125] EXAMPLE COMPUTING ENVIRONMENT

[0126] Having briefly described an overview of embodiments of the present technical solution, an example operating environment in which embodiments of the present technical solution may be implemented is described below in order to provide a general context for various aspects of the present technical solution. Referring initially to FIG. 8 in particular, an example operating environment for implementing embodiments of the present technical solution is shown and designated generally as computing device 800. Computing device 800 is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the technical solution. Neither should computing device 800 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

[0127] The technical solution may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program modules including routines, programs, objects, components, data structures, etc. refer to code that perform particular tasks or implement particular abstract data types. The technical solution may be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general-purpose computers, more specialty computing devices, etc. The technical solution may also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network.

[0128] With reference to FIG. 8, computing device 800 includes bus 810 that directly or indirectly couples the following devices: memory 812, one or more processors 814, one or more presentation components 816, input / output ports 818, input / output components 820, and illustrative power supply 822. Bus 810 represents what may be one or more buses (such as an address bus, data bus, or combination thereof) . The various blocks of FIG. 8 are shown with lines for the sake of conceptual clarity, and other arrangements of the described components and / or component functionality are also contemplated. For example, one may consider a presentation component such as a display device to be an I / O component. Also, processors have memory. We recognize that such is the nature of the art, and reiterate that the diagram of FIG. 8 is merely illustrative of an example computing device that can be used in connection with one or more embodiments of the present technical solution. Distinction is not made between such categories as “workstation, ” “server, ” “laptop, ” “hand-held device, ” etc., as all are contemplated within the scope of FIG. 8 and reference to “computing device. ”

[0129] Computing device 800 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computing device 800 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media.

[0130] Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 800. Computer storage media excludes signals per se.

[0131] Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0132] Memory 812 includes computer storage media in the form of volatile and / or nonvolatile memory. The memory may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical-disc drives, etc. Computing device 800 includes one or more processors that read data from various entities such as memory 812 or I / O components 820. Presentation component (s) 816 present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc.

[0133] I / O ports 818 allow computing device 800 to be logically coupled to other devices including I / O components 820, some of which may be built in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc.

[0134] ADDITIONAL STRUCTURAL AND FUNCTIONAL FEATURES OF EMBODIMENTS OF THE TECHNICAL SOLUTION

[0135] Having identified various components utilized herein, it should be understood that any number of components and arrangements may be employed to achieve the desired functionality within the scope of the present disclosure. For example, the components in the embodiments depicted in the figures are shown with lines for the sake of conceptual clarity. Other arrangements of these and other components may also be implemented. For example, although some components are depicted as single components, many of the elements described herein may be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location. Some elements may be omitted altogether. Moreover, various functions described herein as being performed by one or more entities may be carried out by hardware, firmware, and / or software, as described below. For instance, various functions may be carried out by a processor executing instructions stored in memory. As such, other arrangements and elements (e.g., machines, interfaces, functions, orders, and groupings of functions) can be used in addition to or instead of those shown.

[0136] Embodiments described in the paragraphs below may be combined with one or more of the specifically described alternatives. In particular, an embodiment that is claimed may contain a reference, in the alternative, to more than one other embodiment. The embodiment that is claimed may specify a further limitation of the subject matter claimed.

[0137] The subject matter of embodiments of the technical solution is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and / or “block” may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

[0138] For purposes of this disclosure, the word “including” has the same broad meaning as the word “comprising, ” and the word “accessing” comprises “receiving, ” “referencing, ” or “retrieving. ” Further the word “communicating” has the same broad meaning as the word “receiving, ” or “transmitting” facilitated by software or hardware-based buses, receivers, or transmitters using communication media described herein. In addition, words such as “a” and “an, ” unless otherwise indicated to the contrary, include the plural as well as the singular. Thus, for example, the constraint of “afeature” is satisfied where one or more features are present. Also, the term “or” includes the conjunctive, the disjunctive, and both (aor b thus includes either a or b, as well as a and b) .

[0139] For purposes of a detailed discussion above, embodiments of the present technical solution are described with reference to a distributed computing environment; however the distributed computing environment depicted herein is merely exemplary. Components can be configured for performing novel aspects of embodiments, where the term “configured for” can refer to “programmed to” perform particular tasks or implement particular abstract data types using code. Further, while embodiments of the present technical solution may generally refer to the technical solution environment and the schematics described herein, it is understood that the techniques described may be extended to other implementation contexts.

[0140] For purposes of this disclosure the word “support” refers to provisioning of functionality, services, or assistance by a computing component or through computing operations within a broader computing system. When a computing component or set of operations supports a specific functionality, it means that it plays a role in enabling or executing that particular aspect of the computing system. This support can manifest in various ways, including the processing of data, execution of operations, management of resources, and ensuring compatibility or interoperability with other components. Additionally, support may involve providing interfaces, APIs (Application Programming Interfaces) , or protocols that allow seamless interaction and integration with other elements of the computing system. The concept of support extends beyond mere functionality provision to encompass maintenance, troubleshooting, and the overall optimization of computing resources to ensure the robust and efficient operation of the computing system.

[0141] Embodiments of the present technical solution have been described in relation to particular embodiments which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the present technical solution pertains without departing from its scope.

[0142] From the foregoing, it will be seen that this technical solution is one well adapted to attain all the ends and objects hereinabove set forth together with other advantages which are obvious and which are inherent to the structure.

[0143] It will be understood that certain features and sub-combinations are of utility and may be employed without reference to other features or sub-combinations. This is contemplated by and is within the scope of the claims.

Claims

1.A computerized system comprising:one or more computer processors; andcomputer memory storing computer-useable instructions that, when used by the one or more computer processors, cause the one or more computer processors to perform operations, the operations comprising:accessing a device preparation profile (DPP) identifier associated with a DPP, wherein the DPP is associated with agent-driven device preparation operations;assigning a remote client to the DPP identifier;based on the agent-driven device preparation operations, initializing the remote client to cause enrollment of the remote client with a device management engine;receiving a provisioning status associated with provisioning the remote client; andcommunicating the provisioning status to a device management client.2.The system of claim 1, wherein the agent-driven device preparation operations are different from user-driven device preparation operations, the agent-driven device preparations are operational on one or more virtual machines and bypass an Out-of-Box Experience (OOBE) provisioning process, and the agent-driven device preparations do not require user interaction.3.The system of claim 1, wherein the agent-driven DPP operations are associated with a provisioning management engine comprising a provisioning policy manager, the device management engine, and a remote client provisioning engine that enable provisioning the remote client without user interaction.4.The system of claim 1, wherein the agent-driven DPP operations are associated with a provisioning management engine comprising a provisioning policy manager, the device management engine, and a remote client provisioning engine that enable provisioning remote client without user interaction.5.The system of claim 1, wherein the provisioning status indicates a completion state of the remote client based on progress with provisioning the remote client.6.The system of claim 1, the operations further comprising:communicating, to the device management engine, a request to generate the DPP;based on communicating the request, receiving the DPP identifier from the device management engine; andcommunicating the DPP identifier to a remote client provisioning engine to cause the remote client provisioning engine to initialize the remote client for configuration with the DPP, wherein the remote client is provisioned without user interaction.7.The system of claim 1, wherein the DPP identifier is accessed via a device management engine that is configured to generate the DPP and communicate the DPP identifier to a provisioning policy manager.8.The system of claim 1, wherein the remote client comprises a DPP plugin that supports downloading a bootstrapping agent, the bootstrapping agent is configured to provision the remote client based on the agent-driven device preparation operations without user interaction.9.The system of claim 8, wherein the bootstrapping agent is a sidecar agent, and the provisioning is performed using Application Programming Interface (API) of the sidecar agent.10.One or more computer-storage media having computer-executable instructions embodied thereon that, when executed by a computing system having a processor and memory, cause the processor to perform operations, the operations comprising:accessing a request to generate a device preparation profile (DPP) , wherein DPP is associated with agent-driven device preparation operations;based on request, generating a DPP associated with a DPP identifier;communicating the DPP identifier to a provisioning policy manager, wherein the provisioning policy manager communicates the DPP identifier to a remote client provisioning engine to cause the remote client provisioning engine to initialize a remote client for configuration with the DPP, the remote client is provisioned without user interaction;accessing a request from the remote client to download a bootstrapping agent, wherein the bootstrapping agent is associated with the agent-driven device preparation operations;communicating the bootstrapping agent to the remote client; andbased on bootstrapping agent enabling DPP configuration on the remote client, enrolling the remote client based on the agent-driven device preparation operations to cause provisioning of the remote client.11.The media of claim 10, wherein the agent-driven device preparation operations are different from user-driven device preparation operations, the agent-driven device preparations are operational on one or more virtual machines and bypass an Out-of-Box Experience (OOBE) provisioning process, and the agent-driven device preparations do not require user interaction.12.The media of claim 10, wherein the request to download the bootstrapping agent is communicated from a DPP plugin running on the remote client, the DPP plugin is initialized on the remote client based on the DPP identifier.13.The media of claim 10, wherein the agent-driven DPP operations are associated with a provisioning management engine comprising a provisioning policy manager, the device management engine, and a remote client provisioning engine that enable provisioning remote client without user interaction.14.The media of claim 10, wherein enrolling the remote client comprises syncing the DPP identifier to enrollment services to install applications and scripts.15.A computer-implemented method, the method comprising:communicating a request to download a bootstrapping agent, the request is associated with associated with a device preparation profile (DPP) identifier, the bootstrapping agent is associated with agent-driven device preparation operations;downloading the bootstrapping agent;using the bootstrapping agent, provisioning the remote client based on the agent-driven device preparation operations without user interaction.16.The method of claim 15, wherein the agent-driven DPP operations are associated with a provisioning management engine comprising a provisioning policy manager, the device management engine, and a remote client provisioning engine that enable provisioning fully-prepared client without user interaction.17.The method of claim 15, wherein the remote client is initialized using a remote client provisioning management engine that uses the DPP identifier to initialize the remote client and trigger enrollment of the remote client with a device management engine.18.The method of claim 15, wherein the request is communicated from a DPP plugin installed on the remote client, the DPP plugin is initialized on the remote client based on the DPP identifier.19.The method of claim 15, wherein the bootstrapping agent is a sidecar agent, and the provisioning is performed using Application Programming Interface (API) of the sidecar agent.20.The method of claim 15, the operations further comprising communicating the provisioning status to a remote client provisioning service, wherein the provisioning status indicates a completion state of the remote client based on progress with provisioning the remote client.

Images