Currently, ZENworks has no built-in mechanism to centrally track the ZENworks FDE Encryption Status of managed devices in the ZCC. 

However, achieving this is relatively simple.  To do this, I create a bundle with a few system requirements to either my "Workstation" folder or perhaps a Device Group that is assigned the FDE policy such as a "Laptop" Dynamic Group.  The bundle does not require any schedule nor does it have to execute on the managed devices.  It simply needs to be assigned and have the system requirement status roll up to the ZCC.

The video above demonstrates what the article below describes.

In the sample bundle below, if the status of a bundle is “Effective”, it will mean FDE is working as expected on the device.  “Not Effective” means something is not working as expected.  “Pending” simply means the device has not yet performed a refresh and rolled up the bundle status since the bundle was assigned.

Based on how the bundle is configured, “Effective” indicates that either the device is successfully encrypted or that FDE is successfully installed but a policy is not assigned.  “Not Effective” would indicate that either FDE is not successfully installed or that if it is installed the drive is not yet encrypted despite having an FDE Policy assigned.  Keep in mind that a device will require a reboot after a policy is assigned before it starts encrypting so “Not Effective” does not necessarily indicate an error condition.  The reboot requirement exists to ensure the required ZENworks FDE UEFI boot files properly load upon boot.  Encrypting before verifying the successful loading of the UEFI files at boot could potentially render the device unbootable.

The chart above is generated by defining a series of system requirements for the bundle as shown below.

The first two requirements are the core requirements and should always be used.  The first ensures the “ProgressPercent” is 100 indicating it has fully encrypted the drive.  “OperationInProgress” with a value of “1” indicates the drive is currently performing encryption on the drive.  A value of “0” would indicate decryption is in progress.  (Note: Decryption does not update “ProgressPercent”, which is why both should be checked.)

With the requirements above, any device that is fully encrypted will pass and show success.  Any device not fully encrypted for any reason will show a failure. 

In an environment where not all devices are assigned an FDE Policy, this could generate false positives for devices not assigned a policy.  Two additional requirements were added to avoid such false positives.  The first verifies if a policy is or is not assigned to the device.  If there is not a policy assigned, we do not want to flag this device as potentially having an issue.  However, It also checks to verify if the FDE components are installed.  The reason it does this is that if FDE is not installed, it may not detect the assigned FDE policy.

(Note: If it is expected that 100% of all managed devices should be assigned the policy the second set of checks is not required.  Furthermore, if the policy assignment is to a device group or container, the second set of checks can also be removed and the bundle simply assigned to the same devices.  The second set of checks is most useful if individual assignments are made to the FDE Policy.)

Once the bundle has been assigned to devices and those devices have had a chance to refresh and update the bundle status to the ZCC, one can click on the “Yellow” Not Effective” part of the circle to see a list of potentially impacted devices.  One can even click on each device in the list so you can remote-control and remediate any encryption issues.  The top right of the screen has an option to export the bundle status report to a CSV file which can be imported into Excel for use in reporting.  The circle with an arrow can be used to update the dashlet with the latest data from the database if desired.

Note: A copy of the sample bundle above is attached to the end of the article.

Before actually importing and deploying the bundle above, I recommend reviewing known issues and remediation steps for those issues.  This way they can be deployed in advance to ensure the list of devices with issues is minimal and the required steps to resolve issues discovered.

I would recommend reviewing: https://portal.microfocus.com/s/article/KM000019593?language=en_US

One of the most common causes is if the drive is already encrypted with Automatic BitLocker encryption.  The next most common cause is overly aggressive prerequisite checks around RAID checks and free space on the UEFI partition.  I have created another bundle that can be run against devices to help remediate those issues and the details will be covered shortly.

A more recent issue could revolve around “Microsoft Secured-Core PCs” which often ship with a UEFI setting that disallows the use of any Non-Native MS UEFI bootloader by default but is configurable.

See - https://portal.microfocus.com/s/article/KM000026331?language=en_US

While ZENworks could in theory control this, it would require vendor-specific UEFI management utilities.  While some customers are using ZENworks to manage the UEFI using the OEM vendor UEFI tools, that is outside the scope of this article.

The bundle is quite simple……

It pushes the registry keys in the article…..

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Novell-FDE\Parameters]
"OverRideRaidCheck"=dword:00000001
"SkipUefiCheck"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker]
"PreventDeviceEncryption"=dword:00000001

And it runs the PowerShell commands noted in the article.

The only “twist” is that instead of using a PowerShell Script to run the commands, runs Powershell.exe and passes in the following parameter: "$BLV=Get-BitLockerVolume ; Disable-Bitlocker -MountPOint $BLV".  The semicolon concatenates the two commands.  There are some customers where PowerShell scripts are completely disabled by GPOs but interactive PowerShell.exe usage is permitted.  This allows the bundle to work in a wider range of environments by default.  There bundle also contains a “script” version of the command that could be enabled and used instead if preferred.

Note: In most cases, the PowerShell script will return the following “Error” because the drive is not encrypted with Automatic BitLocker Encryption.  If the drive had been encrypted, one would see a message about the drive being decrypted.

To deploy the bundle, simply assign it to your devices to run on “refresh”.  Any devices that were failing encryption for the issues it addresses should begin to the process shortly after a ZENworks agent refresh.  (Reminder: A reboot would likely be needed prior before actual encryption begins.)

FDE Status Bundle:

 FDE_STATUS_Bundle.zip

FDE Deployment Remediation Bundle:

FDE_Remediation_Bundle.zip

Note: If you want to automatically decrypt devices encrypted with "Encryption Lockdown", simply assign the device a policy that only encrypts "Drive Z:".

See - https://portal.microfocus.com/s/article/KM000034735

To see some of my favorite “ZENworks Tips and Tricks” check out the link: https://community.microfocus.com/members/craigdwilson/bookmarks