Today I presented a session about Mastering Apple OS X with Configuration Manager 2012 R2 at the Swiss Configuration Manager User Group in Bern. Mac OS X support by Configuration Manager 2012 R2 has two ways of supporting Settings Management namely, managing settings through preferences directly or managing it through Shell Scripts. One of the things I showed was the ability to change user preferences in Mac OS X. In an earlier blog I described how you could use the $USER variable if you want to change a user setting, but for some reason how the Configuration Manager clients interacts with Mac OS X is changed. The context in which the Configuration Manager client runs and now changes preferences or running scripts is not the current user but the ROOT user. System preferences can still be changed via the native Mac OS X preferences.

So for this reason you see that nothing is changed when pointing to a preference file in a Configuration Item in Configuration Manager like this ~/Library/Preferences/com.apple.safari . The Tilde (~) means current user so when checking and changing “~/Library/Preferences/com.apple.safari” you will actually check and change the file located in /users/root/Library/Preferences/ . This took me a while to figure that out but, but it is logical that the Configuration Manager client runs in a different context since the client needs unlimited access to the system.

So to be able to change user preferences, like the default homepage of Safari, we need to create a script that is able to gather and use the user that is currently logged on the Mac OS X device, check the setting and remediate it if necessary.

Creating the discovery and remediation scripts

Discovery Script

The discovery script is used to find and return the value of a setting that you want to assess, so for us the first step is checking the current user, thanks to the great community I was able to figure this out quickly. With the command stat -f%Su /dev/console you are able to report the current user that is logged on. Placing the current user to a variable which can be used in the script is done as follows myuser=$(stat -f%Su /dev/console).

The second step is gathering the current setting of the default homepage of Safari. With the command defaults read you are able to read certain settings. If we combine the variable with the defaults read command you should be able to retrieve the current setting of the default homepage of Safari. The command defaults read /users/$myuser/library/preferences/com.apple.Safari HomePage will report the current value. Because we want to check the current value, it is wise to also place the value to a variable like shown above.

The discovery script

Next we need to check if the current value is set the way we want to and report (echoed) a value based of the result. This value can be used while checking if the setting needs to be remediated or not.

Setting rule to define the compliance for this setting

Remediation Script

If the default homepage needs to be remediated we need to create a remediation script. The first step is again retrieving the username of the user that is logged on to the system before we are going to actually remediate the preference setting. With the command default write you are able to change settings of a specific value in a preference file. To be able to change the default homepage of Safari you need to execute the following command; defaults write /users/$myuser/library/preferences/com.apple.safari HomePage -string “http://configmgrlab.com” . After the setting is changed also the permissions to the com.apple.safari.plist file are changed so that users cannot access the file anymore. So you need to revert the permissions with the following command; chmod ugo=rwx /users/$myuser/library/preferences/com.apple.safari.plist. Meaning that all users will be having Read, Write and Access permissions to the file.

Remediation Script

Download the CAB file of the exported Configuration Baseline here and please let me know what you think! Always test the baseline first in a lab environment before using it in a production environment

About Peter Daalmans

Peter is a Principal Consultant, Trainer and Enterprise Mobility (Configuration Manager/Microsoft Intune/Enterprise Mobility Suite) MVP with Daalmans Consulting with a primary focus on the Enterprise Client Management and Enterprise Mobility. Writing blogs and sharing his knowlegde since 2010 on ConfigMgrBlog.com / PeterDaalmans.com.

Also one of the founders and leads of the Windows Management User Group Netherlands.

Peter tries to speak every year on several events like TechDays Netherlands, ExpertsLive, IT/Dev Connections, BriForum, Midwest Management Summit, TechEd Australia, TechEd New Zealand and in 2017 Peter had the honor to speak at Microsoft Ignite. See more here.

Author of four books about Configurtion Manager and Microsoft Enterprise Mobility +Security