ServicesAllowedList from Bluetooth CSP Policy not applying

Question

ServicesAllowedList from Bluetooth CSP Policy not applying

Hugo Himber 20

Hello, I have a problem when I try to apply the Bluetooth CSP policy to use the ServicesAllowedList (using WMI bridge):

I ran the following command on PowerShell as a system user to only allow HID and Audio Bluetooth devices:


New-CimInstance -Namespace 'root\cimv2\mdm\dmmap' -ClassName 'MDM_Policy_Config01_Bluetooth02' -Property @{ParentID='./Vendor/MSFT/Policy/Config';InstanceID='Bluetooth';AllowDiscoverableMode=1;AllowAdvertising=1;ServicesAllowedList='{0000111E-0000-1000-8000-00805F9B34FB};{00001203-0000-1000-8000-00805F9B34FB};{00001108-0000-1000-8000-00805F9B34FB};{00001200-0000-1000-8000-00805F9B34FB};{0000110B-0000-1000-8000-00805F9B34FB};{0000110C-0000-1000-8000-00805F9B34FB};{0000110E-0000-1000-8000-00805F9B34FB};{0000110F-0000-1000-8000-00805F9B34FB};{00001801-0000-1000-8000-00805F9B34FB};{00001800-0000-1000-8000-00805F9B34FB};{0000180A-0000-1000-8000-00805F9B34FB};{00001813-0000-1000-8000-00805F9B34FB};{00001124-0000-1000-8000-00805F9B34FB};{00001812-0000-1000-8000-00805F9B34FB}';AllowPrepairing=1}

This command works as intended:


PS C:\Windows\system32> Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_Policy_Config01_Bluetooth02"

AllowAdvertising                 : 1

AllowDiscoverableMode            : 1

AllowPrepairing                  : 1

AllowPromptedProximalConnections :

InstanceID                       : Bluetooth

LocalDeviceName                  :

ParentID                         : ./Vendor/MSFT/Policy/Config

ServicesAllowedList              : {0000111E-0000-1000-8000-00805F9B34FB};{00001203-0000-1000-8000-00805F9B34FB};{00001108-0000-1000-8000-00805F9B34FB};{00001200-0000-1000-8000-00805F9B34FB};{0000110B-0000-1000-8000-00805F9B34FB};{0000110C-0000-1000-8000-00805F9B34FB};{0000110E-0000-1000-8000-00805F9B34FB};{0000110F-0000-1000-8000-00805F9B34FB};{00001801-0000-1000-8000-00805F9B34FB};{00001800-0000-1000-8000-00805F9B34FB};{0000180A-0000-1000-8000-00805F9B34FB};{00001813-0000-1000-8000-00805F9B34FB};{00001124-0000-1000-8000-00805F9B34FB};{00001812-0000-1000-8000-00805F9B34FB}

SetMinimumEncryptionKeySize      :

PSComputerName                   :

The configuration is correctly set up in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Bluetooth.

When I tried to send a file to a phone using fsquirt, it is correctly blocked and says "disabled by policy."

However, on one specific device, even though the command is successful and both Get-CimInstance and the registry return the correct results, I can still perform a file transfer without restriction. When I run the command or remove the class with Remove-CimInstance, the same event is always shown in the Event Viewer:

"A Bluetooth policy has changed. Policy Bluetooth\ServicesAllowedList has a value of: *"

Instead of showing the actual content of the ServicesAllowedList, which means the system does not use what I just defined.

This issue only occurs with this specific CSP policy. For example, the Camera CSP policy with AllowCamera works as intended.

Here's what I've tried so far:

Reset the WMI repository using winmgmt /verifyrepository, winmgmt /salvagerepository, and winmgmt /resetrepository.
Replaced the folder C:\Windows\System32\wbem\repository with one from a machine that applies the policy correctly.

I don't know what to try next, other than just reinstalling Windows. I would also like to know what causes this issue so I can avoid or repair it if needed later.

Thank you.

0 comments

2 answers

Your answer

Answer 1

VPHAN 33,910 Independent Advisor

Hello Hugo Himber,

You must force the Policy Manager to drop its "stuck" current state and accept a fresh injection from the WMI Bridge. Start by manually deleting the registry key HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Bluetooth. This removes the cached, potentially invalid policy that the system is currently reading. Immediately after deleting the key, restart the dmwappushservice (Device Management Wireless Application Protocol Pushsvc) via services.msc or PowerShell. This service acts as the router for CSP requests, and restarting it clears transient processing errors. Once the service is back up, re-run your New-CimInstance command.

If the Event Log still shows * after the re-application, you likely have a corruption in the policy definition itself on that specific machine. Navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\default\Bluetooth\ServicesAllowedList. Verify that this key exists and contains values for Type (usually REG_SZ) and MergeAlgorithm. If this default key is missing or malformed, the Policy Manager cannot validate your input and will always reject it. You can export this specific key from a working machine and import it into the problematic one to restore the definition.

Finally, stop relying on Get-CimInstance for verification, as it only confirms what was written to the WMI buffer, not what the OS is enforcing. Instead, generate a diagnostic report by running MdmDiagnosticsTool.exe -out C:\Temp\MdmDiag.html in an elevated command prompt. Open the generated HTML file and locate the Bluetooth section. This report shows the "Resultant Set of Policy" (RSOP) that the OS is actually using. If the UUIDs appear here, the policy is active; if it shows * or is empty, the rejection is definitive at the CSP layer, confirming the registry definition issue mentioned above.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Hugo Himber 20 Reputation points

2026-01-27T15:27:53.5133333+00:00

Thanks for your answer, but the issue is still present.

I deleted the Bluetooth key in registry, start dmwappushservice (set by default on manual on my PCs) and reran the New-CimInstance command.

But it tells me that it cannot be created because it is already present. So I tried again but ran Remove-CimInstance before proceeding. This time the command works but the event viewer still says "*" and file transfers can still be done.

Next I looked at the default Bluetooth Policy (the one under default) in registry and everything looks good, it is exactly the same as a working machine.

Last I ran MdmDiagnosticsTool and looked at the HTML generated, but it only shows defaults values, so it was also the same as a working machine.

Do you have any other steps to try ?

Thank you
VPHAN 33,910 Reputation points Independent Advisor

2026-01-27T15:34:30.9833333+00:00

Since you already verified the default key and reset the WMI repository, the corruption likely resides in the active enrollment provider data or the format of the string being passed is triggering a parsing exception in the CSP binary.

You need to inspect the "Intermediate" staging area which sits between the WMI input and the final current key. Open the Registry Editor and navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\Providers. Within this key, you will find several subkeys named with GUIDs. You must identify the one corresponding to your local WMI Bridge enrollment (often labeled Local_Management or a dynamic GUID based on the enrollment time). Drill down into that specific GUID key to default\Device\Bluetooth. Check the ServicesAllowedList value here. If this value exists and appears correct, the WMI Bridge successfully wrote the data, and the failure is in the Policy Manager's merge logic. If the value here is *, missing, or garbled, the issue is upstream in how the WMI provider is parsing your PowerShell input string.

If the staging value appears correct, the definitive error log will be found in the distinct Enterprise Diagnostics channel, not the standard Application log. Open Event Viewer and navigate strictly to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Clear this log, then re-run your New-CimInstance command. You are looking for Error Event ID 404, 454, or 813 immediately following the execution. The "Details" tab of these events will explicitly state why the Policy Manager rejected the string—common causes are "Invalid Parameter" due to hidden Unicode characters in the GUID list or "Validation Failed" if the specific OS build version has a regression in the Bluetooth policy handler policymanager.dll.

Finally, if the logs point to a formatting error despite the string looking correct, verify the string encoding. PowerShell sometimes passes string literals with different encodings based on the system locale. Try defining the string variable explicitly before passing it, ensuring strictly standard ASCII formatting, or test with a single GUID {0000111E-0000-1000-8000-00805F9B34FB} to see if the complexity of the list is causing the buffer overflow or parse error. If a single GUID works, you have confirmed the issue is with the list delimiter or length handling on that specific machine.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Hugo Himber 20 Reputation points

2026-02-09T16:54:42.14+00:00

Thanks again for your answer, but sadly my issue is still not solved.

I have checked the content of the registry key HKLM\SOFTWARE\Microsoft\PolicyManager\Providers and what's inside is correct : GUID > default > Device > Bluetooth does contain the same values I have defined with the New-CimInstance command.

Next, I ran the Remove-CimInstance commande and cleaned the Admin log from DeviceManagement-Enterprise-Diagnostics-Provider in the Event Viewer. After that, when I rerun the New-CimInstance command, I get 4 events : one for each of the settings set with the policy. I don't see any error there too as I only have event IDs 813 and 814 (as you can see in the linked screenshot).

Furthermore, I have also tested with a unique service GUID and all the results were the same, so it not a syntax issue.

Finally, since you talked about policymanager.dll, I thought that this DLL may be corrupted so I ran sfc /scannow. It have successfully repaired the driver bthmodem.sys, but after one more reboot it didn't solve my issue.

Thanks for your help

Answer 2

It seems like you've taken several appropriate steps to troubleshoot the issue with the Bluetooth CSP policy not applying correctly on a specific device. Here are some additional considerations that might help you resolve the problem:

Check Device Compatibility: Ensure that the device in question supports all the Bluetooth profiles you are trying to restrict. Some devices may have firmware or hardware limitations that prevent them from adhering to certain policies.
Review Group Policies: If the device is part of a domain, check if there are any Group Policies that might be overriding the settings applied through the CSP. Group Policies can sometimes take precedence over local settings.
Event Viewer Logs: Since you mentioned seeing an event in the Event Viewer indicating a policy change, check for any additional logs that might provide more context or errors related to the Bluetooth policies. This could give you clues on what might be going wrong.
Reboot the Device: After applying the policy, ensure that the device is rebooted. Some policies may require a restart to take effect fully.
Check for Conflicting Software: Look for any third-party software that might interfere with Bluetooth settings. This includes Bluetooth management software that could conflict with Windows' built-in policies.
Update Drivers and Firmware: Ensure that the Bluetooth drivers and firmware on the device are up-to-date. Sometimes, outdated drivers can cause unexpected behavior with policy applications.
Test with a Clean User Profile: If possible, create a new user profile on the device and test if the policy applies under that profile. This can help determine if the issue is user-specific or system-wide.
Windows Updates: Ensure that the device is fully updated with the latest Windows updates, as updates can fix bugs related to policy applications.

If none of these steps resolve the issue, reinstalling Windows may be a last resort, but it’s advisable to exhaust all other options first.

References:

Policy CSP - Bluetooth

Share via

ServicesAllowedList from Bluetooth CSP Policy not applying

2 answers

Your answer