Leave Bluetooth on but undiscoverable?

Not applicable

Hi gang,

Anyone know of a way to script turning off the "Discoverable" option in the
Bluetooth Preferences. We want to leave Bluetooth on by default, as the new
iMacs are coming with the bluetooth keyboard/mouse. But we'd like to uncheck
that discoverable box.

Has anyone done it? Anyone have any suggestions?

Thanks,
Bob

5 REPLIES 5

Not applicable

Just in case you didn't know you can request wired keyboard and mouse
instead of the Bluetooth. That's what we are doing anyway.

- JD

corbinmharris
Contributor

My security director has asked for this as well. Tried using Managed Preferences in Casper to disable and it hasn't worked. Jamf support mentioned that Managed Preferences in 10.8 is not reliable and not able find anything in Configuration Profiles to such. I don't want to disable the entire bluetooth set of preferences or utilities, just disable discovery.

Any ideas?

justinrummel
Contributor III

That will be interesting as you need to search in each User's ~/Library/Preferences/ByHost/ folder and for each com.apple.Bluetooth.plist file verify that:

[code]DiscoverableState = 0;[/code]

Take a look at Rich's Java script to get an idea about playing with ByHost info:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/enable_java_web_plugins/enable_java_web_plugins.sh

corbinmharris
Contributor

I am trying to accomplish the same task for our security requirements. The Managed Preferences option does not seem work with 10.8 and System Profiles is a sledgehammer approach by disable BT preferences all together.

I did test this command line script on my own Mac -

defaults -currentHost write com.apple.Bluetooth DiscoverableState -bool no

It was successful, but didn't work when I pushed it out to a Mac I use for Casper testing.

Any other ideas are appreciated.

Thanks!
Corbin

mm2270
Legendary Contributor III

You can't use the -currentHost flag in a defaults command run from Casper because that flag assumes the user account running the command, which when done via a policy, etc is root. So its writing the value into root's ByHost Bluetooth plist file, assuming one even exists.

is there a reason you can't do this with MCX? We do and it works perfectly as far as I can tell.

If there's a valid reason, have you had a look at the link justinrummel posted to Rich's script? It should give you an example of how to write into user ByHost plist files and also set the User Template account settings the same way.