Abstract: Disclosed are various embodiments for recognizing state changes in client devices and managing the state of client devices using device-driven management workflows. A computing device can receive a state of a client device. The computing device can then determine if the received state matches an expected, compliant state of the client device. When the computing device determines that the received state does not match the expected state, the computing device can identify a remedial workflow that would bring the client device into compliance. The computing device can send the remedial workflow and an instruction to run the remedial workflow to the client device.

Abstract: Disclosed are various embodiments for managing the state of client devices using device-driven management workflows. A computing device can be evaluated to determine the current state of the computing device. Then, the current state of the computing device is compared to an expected state of the computing device. The expected state of the computing device may be based at least in part on a result of execution of at least one device-driven management workflow by the computing device. In response to a determination that the current state of the computing device fails to match the expected state of the computing device, the device-driven management workflow can be executed to resolve the discrepancy between the expected state and the current state.

Abstract: Various examples are described for operating system update management. In some examples, an OS update schedule is generated. The OS update schedule specifies an OS update for a plurality of client devices. A command to deploy the OS update is transmitted to a subset of the client devices. Behavior data is received from the client devices that have applied the OS update. An update incompatibility identified using the behavior data. Instructions to fix the update incompatibility are transmitted to certain client devices.

Abstract: Disclosed are various embodiments for managing the state of client devices using device-driven management workflows. A computing device can be evaluated to determine the current state of the computing device. Then, the current state of the computing device is compared to an expected state of the computing device. The expected state of the computing device may be based at least in part on a result of execution of at least one device-driven management workflow by the computing device. In response to a determination that the current state of the computing device fails to match the expected state of the computing device, the device-driven management workflow can be executed to resolve the discrepancy between the expected state and the current state.

Abstract: Various examples are described for operating system update management. In some examples, an OS update schedule is generated. The OS update schedule specifies an OS update for a plurality of client devices. A command to deploy the OS update is transmitted to a subset of the client devices. Update behavior data is received from the client devices that have applied the OS update. An analysis of the update behavior data correlates an update incompatibility with the OS update. The OS update is prevented from being deployed to additional client devices specified in the OS update schedule.

Abstract: Various examples are described for operating system update management. In some examples, an OS update schedule is generated. The OS update schedule specifies an OS update for a plurality of client devices. A command to deploy the OS update is transmitted to a subset of the client devices. Update behavior data is received from the client devices that have applied the OS update. An analysis of the update behavior data correlates an update incompatibility with the OS update. The OS update is prevented from being deployed to additional client devices specified in the OS update schedule.

Abstract: Disclosed are various examples for the silent upgrade of software and its dependencies on a client device. A client device can identify that a new version of the client application is available that upgrades a current version of the client application to the new version and download an installation package file for the new version of the client application. A unique identifier for the client application can be identified and used to search a registry of an operating system installed on the client device to locate information associated with the current version of the client application, such as a file path for the current version of the client application. The installation package file can be modified using information associated with the file path and a silent upgrade of the client application can be performed where the current version of the client application is upgraded with the new version of the client application without user interaction.

Abstract: Disclosed are various examples for the silent upgrade of software and its dependencies on a client device. A client device can identify that a new version of the client application is available that upgrades a current version of the client application to the new version and download an installation package file for the new version of the client application. A unique identifier for the client application can be identified and used to search a registry of an operating system installed on the client device to locate information associated with the current version of the client application, such as a file path for the current version of the client application. The installation package file can be modified using information associated with the file path and a silent upgrade of the client application can be performed where the current version of the client application is upgraded with the new version of the client application without user interaction.