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.