How are you guys saving Bitlocker Keys?

Currently we are saving Bitlocker keys manually after the Immybot onboarding process. Does anyone here have a workflow that automates that process?

1 Like

@Diego_Arteaga if you are using the Bitlocker task in ImmyBot it has logic built into it that if the computer is domain joined it will attempt to backup the bitlocker keys to the DC.
If the computer is AzureAD joined, it will backup the keys to the Azure key vault.
Ensure the task runs after your Set Computer Name and Domain Join / Join AzureAD task under Deployment Ordering.

2 Likes

We use the builtin script to push this to Automate EDF and from there we sync it to Manage as a computer type configuration question (Custom) which then syncs back into Hudu

Would love to see quickbooks licenses get saved somewhere for now we just run a quick task if we don’t have it on file

We are currently using our RMM to do some “Post Immy” things we can’t do with Immy. A part of that is grabbing the BitLocker Key and storing it in the RMM to sync to our CRM. This way we don’t risk the gap between when the RMM automation runs (that would normally grab the key) and our deployment in case the Key is needed.

1 Like

With the latest 0.62 update, I’ve started running a custom inventory script for Bitlocker keys. They get updated daily and can be viewed in the Computer inventory report page

1 Like

Hey @Dakota_Lewis,

Would you be willing to share the inventory script you are using to grab that?

Sure thing, here ya go!

$Results = Invoke-ImmyCommand -ScriptBlock {
    $BitlockerVolumes = Get-BitLockerVolume | ForEach-Object {
    $MountPoint = $_.MountPoint
    $VolumeStatus = $_.VolumeStatus
    $ProtectionStatus = $_.ProtectionStatus
    $_.KeyProtector | Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" } | ForEach-Object {
        $RecoveryId = $_.KeyProtectorId -replace '[{}]'
        $RecoveryKey = $_.RecoveryPassword
        [PSCustomObject]@{
			Hostname   = $(hostname)
            MountPoint = $MountPoint
            VolumeStatus = $VolumeStatus
            ProtectionStatus = $ProtectionStatus
            RecoveryId = $RecoveryId
            RecoveryKey = $RecoveryKey
        }
    }
    }
    $Output = $BitLockerVolumes | Format-List
    if ($Output.Count -lt 1){
        return "BitLocker is disabled, or no keys are present on the machine."
    } else {
        return $Output | Out-String
    }
}
return $Results

The Inventory Script is called “Bitlocker Inventory Script”, the Inventory Task is called “Bitlocker Keys”, and the Inventory Key is just called “Keys”. That’s my setup anyway, feel free to use your own labels.

1 Like

It will look something like this in the reports

It shows when BitLocker is enabled vs when it is disabled.

1 Like

We use our RPA to store them in ITG. We store them at the org level, with machine name, Primary user, Identifier, and key in a flexible asset. The thinking there is, it is stored in AD, Azure AD, ITGlue, PSA, and the RMM, at the device config level. There have been times that a device is decommissioned, and in our process we remove it and all configs, then 3 months later someone needs something off of the disk that has been sitting in a closet for 3 months, and the BL Keys have been purged.
The RMM runs a script periodically to grab all of the info directly from the device, and sends it via webhook to the RPA. The RPA checks ITG, and if the info is not in ITG, it creates a new record. we keep these records indefinitely in ITG.

We also had issues where we were enforcing BL via Intune, and if Immy was running an update that required BL to be disabled, and Intune happened to check policy compliance in that time, Intune would create a new key and that was overriding the key in Azure AD and most other places. so the Script checks for multiple keys on the machine, and ensures there is only one. the Next Immy session will make sure the key in AD / Azure AD will match.