Get-ControlPanelItem/show-controlpanelitem anomaly

When I run Get-ControlPanelItem on domain workstations I find the canonical name I am looking for:


However when I run this as windows login script, only some of the workstations find this ControlPanelItem.

Most worstations will find this and all other ControlPanelItems, but some of them find all other but not this one.

These workstations will return error message when this controlpanel item is called with show-controlpanelitem “ErrorMessage: Cannot find any Control Panel item with the given canonical name Microsoft.BitLockerDriveEncryption.”

Any idea why BitLockerDriveEncryption behaves differently from other ControlPanelItems or ideas how to overcome this issue?


Is the issue only when you execute as login script ? how about executing this by logging in locally on those systems ?

This is an issue only when executing as login script.

Users can run the same script manually and get different results.

Different users can run the script and get different results on the same system?
Different users can run the script and get different results on different systems?
Users with different privileges can run the script and get different results?

Are the systems that behave differently consistent? Is it always the same systems that don’t respond as expected? Do these systems behave the same after rebooting? Do any systems that responded as expected before behave differently after rebooting?
Are all systems using the same version of PowerShell? the same build of Windows? are they all on the same domain? under the same domain controller? using the same group policies?
Is BitLocker configured the same way for all systems? (e.g. unlock method, FDE vs. used space, etc) is BitLocker suspended on any of them?
Are the hard drive configurations similar for all systems? (single disk/multiple disks/SATA/RAID/…)
Is BitLocker linked with TPMs on these systems? do all systems have the same TPM version?

Are you doing this:

Get-ControlPanelItem ‘Microsoft.BitLockerDriveEncryption

Or this:

Get-ControlPanelItem -CanonicalName ‘Microsoft.BitLockerDriveEncryption’

Mine failed as yours did using the first option but not using the second.

Are you doing this:

Get-ControlPanelItem ‘Microsoft.BitLockerDriveEncryption’

Or This:

Get-ControlPanelItem -CanonicalName ‘Microsoft.BitLockerDriveEncryption’

Mine failed as yours did using the first option.


Good catch, but I have specified this in the script:

show-controlpanelitem -canonicalname Microsoft.BitLockerDriveEncryption

Also I am using this command as single liner: Get-ControlPanelItem

It lists all available control panel items. When running as logon scripts, all other items are available except bitlocker. When ran manually by the user, it returns bitlocker as well.



Thanks grokkit!

Different users can run the script and get different results on different systems.

It only seems to depend on the workstation. Using logon script, User A can get bitlocker open on system 1 but not on system 2.

When ran manually bitlocker control panel item is available on all systems for all users.

  • Systems that behave differently are consistent.
  • It is always the same systems that don't respond as expected.
  • Rebooting has no effect. This script has been in testing for months on for a pilot group.
  • All workstations have the same build of Windows.
  • All are on the same domain, with 2 DCs.
  • Group policies between workstations may vary.
  • BitLocker is configured the same way for all systems during the installation.
  • Hard drive configurations and TPM settings I will have to look into.
I have not figured this out yet.

I think next I will test if calling the bitlocker -control panel item via scheduled tasks performs more reliably.


Frankly, this sounds like you haven’t done consistent testing.

[quote quote=201654]Systems that behave differently are consistent.
It is always the same systems that don’t respond as expected.[/quote]
This is more specific and would seem to point to a local configuration problem, but it’s not specific enough to isolate system config vs. user config.

Do different users get the same results on the same system? (local system configuration issue)
Does the same user get different results on different systems? (user profile issue)
Does the same user get the same results every time on the same system? (sanity check)

It doesn’t sound like this is a PowerShell issue, really - it’s more likely a configuration issue or a Windows bug. You’ll need to cross-check a problem system against a working system. Group policy settings may be causing you real issues. You can hide Control Panel settings with group policy or via the registry, so you should check the settings described in that article. Also, there is potential variation for whether (local) computer policies are applied before (domain) user policies at logon, and which takes precedence. You should check the settings discussed here and verify that systems that are having this problem are configured the same as other systems.

Assuming that your user accounts are domain accounts, it would probably be worthwhile to try logging in to a problem system with a local account (I assume there’s an original local account that was used for install/config prior to domain deployment). If the local user doesn’t show BitLocker in the list post-logon, it would point to a local configuration issue.

If the BitLocker control panel item is disabled via local computer policy settings or registry settings as described in the article above, which then get overridden by the domain group policy after user logon, that could explain the symptoms you’ve described. Fixing the problem systems might be as simple as running gpupdate /force and rebooting (maybe).

After some searching, I couldn’t find anything specific about how Get-ControlPanelItem actually works. The documentation says

but it doesn’t say if the list of options is produced by searching the directory that holds control panel files (which is actually C:\Windows\system32) or if it gets a list from somewhere else in the operating system (like the registry). Without knowing how exactly the cmdlet produces the list it’s hard to even figure out where the source of the problem would be (insert rant against proprietary software here). I couldn’t find a source for this cmdlet. There are several available in the github repository but not Get-ControlPanelItem, so the only way to get a look at how it works would be to decompile the Microsoft.PowerShell.Commands.Management.dll that the cmdlet is part of - but that’s a bit further than I’m willing to go right now.

I think it’s also worth noting that Microsoft has been making changes to Control Panel over the last several releases, basically trying to replace it with the Settings application (which pales in comparison and still relies heavily on control panel applications to perform any advanced tasks). In addition, the Get-ControlPanelItem documentation hasn’t been updated for PowerShell v6 or 7, which may be a bad sign (it may be deprecated).
Are any of the problem systems notably different in age? That is, if you have systems that were previously Windows 10 r1803 and then were updated to r1809 and then r1903, they may behave differently than systems that were installed with a clean r1903 image. It might be worth your time to blank one of the problem systems and re-install Windows to see if the behavior changes.

After testing an alternative method, I can now confirm that Get-ControlPanelItem is able to find the bitlocker ControlPanelItem when the same script is ran as scheduled task as current user.

I could not find out if this is a bug,intended limitation or some variation in the test machine installations, but for some reason not all windows 10 workstations can call this control panel item in login script.