Short answer
Yes, for reboots that Automox itself initiates. As part of its reboot process, Automox suspends the BitLocker lockout so the device can restart and finish applying updates without stopping at the pre-boot BitLocker screen.
It is worth being precise about the mechanism, because it has consequences. BitLocker protection is suspended for the restart rather than defeated. The volume stays encrypted, and protection is expected to resume automatically once the device comes back up.
Which reboots this applies to
The suspension is part of the Automox reboot process, so it applies when the restart is initiated by Automox:
- A patch policy or Worklet with automatic restart enabled
- A manual restart triggered from the console
- An end user accepting a restart from an Automox notification prompt
It does not apply to restarts Automox did not initiate. A user restarting the device themselves, or Windows restarting it on its own schedule, follows normal BitLocker behavior and will present the pre-boot screen if your configuration requires it.
Protection can remain suspended afterwards
In some cases BitLocker protection does not resume automatically after the update and restart cycle finishes, leaving the volume encrypted but unprotected until something re-enables it. This matters because it is a real gap in your encryption posture, and nothing on the device surfaces it to the user.
Do not treat a successful patch run as confirmation that protection resumed. Verify it, either on a device:
manage-bde -status
or with PowerShell:
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, ProtectionStatus
A ProtectionStatus of Off on an encrypted volume means protection is suspended.
To handle this across a fleet, the Automox Worklet Catalog includes an Enforce BitLocker Encryption Worklet, which checks drives for their protection status and re-enables protection where it is suspended. Deploy it as a recurring policy scheduled a few hours after your patch window, so it catches any device that came back with protection off. This is more reliable than waiting for someone to notice, and it removes the need for a custom catch script.
If the BitLocker screen appears anyway
If a device presents the recovery or PIN screen after an Automox-initiated restart, that is worth investigating rather than accepting. Collect the following before raising it with Support:
- The device hostname.
- The name or ID of the policy that triggered the restart, and whether the restart came from a policy, the console, or a user accepting a notification.
- The
amagent.logfrom that device. See Retrieving Automox Agent logs. - The BitLocker event logs from the same device, covering the restart. See Microsoft's BitLocker event logs reference.
- The approximate time of the restart, so the two logs can be lined up.
Both logs together are what allow the sequence to be reconstructed. The agent log alone cannot show what BitLocker did.