Creating your first boot script

By Amsys

Anyone who is using the modular deployment technique will have hit the first stumbling block very early on. If you’re deploying an unbooted, unconfigured OS, how do you get it past the Apple setup assistant? After getting past this hurdle, lots of other questions start cropping up like “how do I get the Mac localised for my geographical region?” and “how do I add a local admin account?”
There are a bunch of different approaches people are using but the most popular by far is a first boot script. This is a script that is set to run on first boot, after the OS has been deployed / installed, that sets up all of these extra items so the Mac is ready for use.

Why should I build my own and not just use one I find on the Internet?

There are lots of good sources of example first boot scripts shared by the community and as long as you trust the source there is nothing wrong with using what you find. The goal of this blog is to demystify some of the first boot script contents and help you to learn how to create your own, or at the very least, understand the code that is included in others.

What language should you use for the script?

Technically speaking, any language that the Mac can understand would be OK. I generally use bash as it has most of the commands I need already built-in.
Most of the examples I’ve seen posted by other Mac admins have been in bash so although you could go for perl, python or something else, you may find getting help with tricky problems a bit of a challenge (I’m sure some perl and python masters out there will strongly disagree but this is just my opinion!)

What should I use to write the script?

You need a simple text editor for this task. I would avoid applications like TextEdit and definitely stay away from Word or other word processing apps. I have used Fraise for quite a few years and have recently started using Sublime Text. Other good options are Text Wrangler and BBEdit. In addition to these being basic text editors, they color code your text really nicely so you can see what’s a variable, a string, a comment etc.

User Template and Existing Users

There are quite a few settings that are per-user. This means that some settings are stored in a preference file in each users home folder (i.e. /Users/dave/Library/Preferences/co.uk.amsys.mygreatsetting.plist, rather than /Library/ Preferences/co.uk.amsys.mygreatsetting.plist).
As a lot of you will already know, home folders are (by default) stored in /Users and when a new user logs in, the home folder is created from the template in /System/Library/User Templates. There are a few different techniques people like to use to get their custom settings into the users home Library:

Use a LaunchAgent to write in the setting during login – This is a newer technique and it involves adding the settings to a script that will run at login, rather than as a first boot item. I have to say that I’m not a fan of this method mainly due to its consistency. There is a lot going on at login and in the past I have had mixed results trying to configure user level settings quickly enough for them to always apply for every user at every login.

Write the data into the user template – This is my current preferred method. Run the commands as part of the first boot script straight into the user template folders. Any new users will then get these settings by default.

If you do use the user template method, you may need to write the data into any pre-existing home folders (for any users that logged in before you made the change). In theory, if you have just deployed the Mac, there shouldn’t be any, but it is worth including the code so you can also use it on machines that have been in use for a while.
My method for this is to loop through any folders found in /Users (as documented here).
Some people have commented that it is better to read the value from the directory service. That would also work, although it would pick up all of the system users, which would then need excluding. My personal preference is to just go for what’s in /Users. If I put the homes in a non-standard location, I can easily change the path for that particular environment).
I wanted to include this explanation regarding users and preferences in home folders so it adds some context around the code included in this blog. There’s no particular right or wrong way really so go for which every method you prefer, as long as you get to where you need to be.

Commands Used

In my first boot scripts, the main commands I’m using are:

/usr/sbin/sysadminctl – Available in 10.10.x, used to add local accounts
/usr/sbin/systemsetup – Used to set NTP servers, time zones and other clock options (and lots of other things)
/usr/libexec/PlistBuddy – Used for reading and writing data into xml arrays
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart – ARD command-line tool
/usr/bin/defaults – Used to read and write xml keys in plist files
/usr/sbin/spctl – For switching Gatekeeper on and off

Other Unix Features

Functions – Used to simplify the repetition of chunks of code
Loops – Used to repeat code based on pre-defined criteria (in this case the contents of folders)

A Quick Note About The Loops Used in The Example Script

You will notice in our example that we run very similar loops over and over again. This isn’t necessarily the most efficient use of the code, which could be shorter. The main reason for laying it out this way is to make each section of the script self-contained.
This will enable you to chop out specific sections that interest you. In reality, when we are writing a series of commands into the user template folder and existing user home folders, we would run them all in a single loop. In this example we didn’t want you to have to find the bits you need hidden amongst other lines of unrelated code.

First boot script, step-by-step

Creating a local admin account
There are a couple of ways you can go about creating a local admin user. One of my favorites for the past year or two has been CreateUserPkg. This app lets you specify the account details and will generate a pkg from the resulting code that you can include in your deployment workflow. Prior to this I was running a series of unfriendly dscl commands so this was much easier.
Since 10.10, a new command-line binary has been included called sysadminctl. This binary lets you create and manage local user accounts. In my 10.10 first boot script I just include a line like this:
sysadminctl -addUser localadmin -fullName “Local Admin” -UID 499 -password “apassword” -home /var/localadmin -admin
As this is a new command, here is the step-by-step breakdown:

Specifying the unix command to run: sysadminctl
Telling it I want to add a user account with the name “localadmin”: -addUser localadmin
Telling the command that I want the fullname to be “Local Admin”: -fullName “Local Admin”
Setting the UID to 499 (classed as a system account below 500): -UID 499
Setting a password: -password “apassword”
Specifying the home folder location (in a hidden directory): -home /var/localadmin
Specifying that I want the account to be an admin: -admin

Setting time zone and time server
There are a few different steps needed to get the time configured. For each of these commands we are using the systemsetup command line tool. systemsetup can configure all sorts of things like sleep settings, the time, and the computer name. To see all of its options use systemsetup -help.
For our first boot script, first we need to set the time zone:

/usr/sbin/systemsetup -settimezone "Europe/London"

You can use systemsetup -listtimezones to get a full list of the available time zones.
Next I set the Mac to use a time server. This isn’t specifying the actual time server (that’s in the next command), but rather its just saying “use a time server”:

/usr/sbin/systemsetup -setusingnetworktime on

Finally I tell the Mac which time server to use:

/usr/sbin/systemsetup -setnetworktimeserver "ntp.amsys.co.uk"

If you’re not sure which time server to use, you can always set it to your AD domain controller (if you have one) as they are configured to be time servers by default.

Region, keyboard and language

There are three separate elements we have to work on:

The keyboard layout
The language
The region (for the default currency etc.)

In this example I’ll be setting the Mac to use the British keyboard layout, en language and en_GB region.

The Keyboard Layout

This first part (in fact all three parts of the localization settings) require the use of plistbuddy. This is because the data is stored in arrays. While it might be possible with the defaults command, plistbuddy is the right tool for the job.
This part of the script is broken into two parts, first we create the function that will perform the actual task:

PLBUDDY=/usr/libexec/PlistBuddy
NAME="British"
LAYOUT="2"
update_kdb_layout() {
  ${PLBUDDY} -c "Delete :AppleCurrentKeyboardLayoutInputSourceID" "${1}" &>/dev/null
  if [ ${?} -eq 0 ]
  then
    ${PLBUDDY} -c "Add :AppleCurrentKeyboardLayoutInputSourceID string com.apple.keylayout.${NAME}" "${1}"
  fi
  for SOURCE in AppleDefaultAsciiInputSource AppleCurrentAsciiInputSource
AppleCurrentInputSource AppleEnabledInputSources AppleSelectedInputSources
  do
    ${PLBUDDY} -c "Delete :${SOURCE}" "${1}" &>/dev/null
    if [ ${?} -eq 0 ]
    then
      ${PLBUDDY} -c "Add :${SOURCE} array" "${1}"
      ${PLBUDDY} -c "Add :${SOURCE}:0 dict" "${1}"
      ${PLBUDDY} -c "Add :${SOURCE}:0:InputSourceKind string 'Keyboard Layout'" "${1}"
      ${PLBUDDY} -c "Add :${SOURCE}:0:KeyboardLayout ID integer ${LAYOUT}" "${1}"
      ${PLBUDDY} -c "Add :${SOURCE}:0:KeyboardLayout Name string '${NAME}'" "${1}"
    fi
  done
}

This function will delete the current keyboard layout entry (if present) and add in the new entries.
Next we set the keyboard layout in /Library/Preferences and in each user’s home directory. The setting is stored in the com.apple.HIToolbox.plist file.

update_kdb_layout "/Library/Preferences/com.apple.HIToolbox.plist" "${NAME}"
"${LAYOUT}"
for HOME in /Users/*
  do
    if [ -d "${HOME}"/Library/Preferences ]
    then
      cd "${HOME}"/Library/Preferences
      HITOOLBOX_FILES=`find . -name "com.apple.HIToolbox.*plist"`
      for HITOOLBOX_FILE in ${HITOOLBOX_FILES}
      do
        update_kdb_layout "${HITOOLBOX_FILE}" "${NAME}" "${LAYOUT}"
      done
    fi
done

Setting the OS language

Similar to the keyboard layout, we create a function to set the language:

LANG="en"
update_language() {
  ${PLBUDDY} -c "Delete :AppleLanguages" "${1}" &>/dev/null
  if [ ${?} -eq 0 ]
  then
    ${PLBUDDY} -c "Add :AppleLanguages array" "${1}"
    ${PLBUDDY} -c "Add :AppleLanguages:0 string '${LANG}'" "${1}"
  fi
}

Then we use a loop script to write the value into /Library/Preferences and each user’s home folder. The language setting is stored in the .GlobalPreferences.plist file.

update_language "/Library/Preferences/.GlobalPreferences.plist" "${LANG}"
for HOME in /Users/*
  do
    if [ -d "${HOME}"/Library/Preferences ]
    then
      cd "${HOME}"/Library/Preferences
      GLOBALPREFERENCES_FILES=`find . -name ".GlobalPreferences.*plist"`
      for GLOBALPREFERENCES_FILE in ${GLOBALPREFERENCES_FILES}
      do
        update_language "${GLOBALPREFERENCES_FILE}" "${LANG}"
      done
    fi
done

Setting the region

Finally we need to set the region (for default currency and a few other values).
As before, it’s another function:

REGION="en_GB"
update_region() {
  ${PLBUDDY} -c "Delete :AppleLocale" "${1}" &>/dev/null
  ${PLBUDDY} -c "Add :AppleLocale string ${REGION}" "${1}" &>/dev/null
  ${PLBUDDY} -c "Delete :Country" "${1}" &>/dev/null
  ${PLBUDDY} -c "Add :Country string ${REGION:3:2}" "${1}" &>/dev/null
}

Followed by a script to set the values in /Library/Preferences and each user’s home:

update_region "/Library/Preferences/.GlobalPreferences.plist" "${REGION}"
for HOME in /Users/*
  do
    if [ -d "${HOME}"/Library/Preferences ]
    then
      cd "${HOME}"/Library/Preferences
      GLOBALPREFERENCES_FILES=`find . -name ".GlobalPreferences.*plist"`
      for GLOBALPREFERENCES_FILE in ${GLOBALPREFERENCES_FILES}
      do
        update_region "${GLOBALPREFERENCES_FILE}" "${REGION}"
      done
    fi
done

Apple Remote Desktop

Apple Remote Desktop has a number of options available that can be configured via a first boot script. The command-line tool is buried in the System Library so it is worth setting its location to a variable to make the other commands a bit more readable:

ARD="/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart"

First off we will need to switch ARD on:

$ARD -configure -activate

Next we need to lock the service down to specific users and decide what they can and can’t do.

$ARD -configure -access -on
$ARD -configure -allowAccessFor -specifiedUsers
$ARD -configure -access -on -users localadmin -privs -all

These options will enable access for the Macs local accounts, ensure that only the specified users can get access, and then sets specific options for the localadmin account.
The -privs all tells ARD that localadmin is allowed to use all of the sub-options available in ARD. Other options for -privs include:

-none
-DeleteFiles
-ControlObserve
-TextMessages
-ShowObserve
-OpenQuitApps
-GenerateReports
-RestartShutDown
-SendFiles
-ChangeSettings
-ObserveOnly
-mask

It is important to ensure that ARD can only be used by specified users. This is due to a security loophole with the “all users” option. When ARD is set to allow all users, this includes all users in any directory the target Mac is bound to. In the ARD app, you can send Unix commands as the root user. If all users are allowed to use ARD, this means that a non-admin domain user could send root commands to the Mac.
There are a lot more options available in the kickstart binary. Use the -help option to see the full list.
Tip: Make sure you include the ARD code AFTER creating the local admin user account (it can’t give access to a user that doesn’t exist).

Enabling SSH access

Either in addition to, or instead of ARD, you can enable SSH access with the following command:

systemsetup -setremotelogin on

Setting up the Login Window

There are a few options we normally configure for the Login Window.
First off we like to set it to username and password text fields rather than displaying a list of local users. This can be set with a one-line command:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow SHOWFULLNAME -bool
true

The second change is to allow admin host information to be visible. When this is enabled, you can click the hostname in the top right corner of the screen to get other information such as the Mac’s IP address:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow AdminHostInfo
HostName

Finally, we disable External Accounts at the Login Window. External Accounts were introduced with an earlier version of Mac OS X (I can’t remember exactly which one but it was around 10.5) that allows you to store a user account and its home folder on an external drive. When you plug in the drive (after entering admin account details), the user can log in with the external account.
This isn’t a feature we want enabled so we disable it with the following command:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow
EnableExternalAccounts -bool false

Disable iCloud Setup at login

The next alteration is to stop the iCloud setup screen appearing when users log in to the Mac. This is particularly useful in education environments as the students would not normally (certainly in shared device setups) need to login with an iCloud account.
This setting has always been a little tricky to configure as it changes depending on the OS version of the Mac. Thanks to Rich Trouton’s code, the following information can be written into the com.apple.SetupAssistant.plist file in each user’s home folder:
First we get the OS version and save the info into a variable:

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
sw_vers=$(sw_vers -productVersion)

Next we write the value into the files in the user template:

for USER_TEMPLATE in "/System/Library/User Template"/*
	do
    /usr/bin/defaults write
"${USER_TEMPLATE}"/Library/Preferences/com.apple.SetupAssistant DidSeeCloudSetup -bool
TRUE
    /usr/bin/defaults write
"${USER_TEMPLATE}"/Library/Preferences/com.apple.SetupAssistant GestureMovieSeen none
    /usr/bin/defaults write
"${USER_TEMPLATE}"/Library/Preferences/com.apple.SetupAssistant
LastSeenCloudProductVersion "${sw_vers}"
    /usr/bin/defaults write
"${USER_TEMPLATE}"/Library/Preferences/com.apple.SetupAssistant
LastSeenBuddyBuildVersion "${sw_build}"
	done

Finally we write the value into any existing user home folders in /Users:

for USER_HOME in /Users/*
	do
		USER_UID=`basename "${USER_HOME}"`
		if [ ! "${USER_UID}" = "Shared" ]
		then
		if [ ! -d "${USER_HOME}"/Library/Preferences ]
		then
			mkdir -p "${USER_HOME}"/Library/Preferences
			chown "${USER_UID}" "${USER_HOME}"/Library
			chown "${USER_UID}" "${USER_HOME}"/Library/Preferences
		fi
		if [ -d "${USER_HOME}"/Library/Preferences ]
		then
			/usr/bin/defaults write
"${USER_HOME}"/Library/Preferences/com.apple.SetupAssistant DidSeeCloudSetup -bool
TRUE
			/usr/bin/defaults write
"${USER_HOME}"/Library/Preferences/com.apple.SetupAssistant GestureMovieSeen none
			/usr/bin/defaults write
"${USER_HOME}"/Library/Preferences/com.apple.SetupAssistant LastSeenCloudProductVersion "${sw_vers}"
			/usr/bin/defaults write
"${USER_HOME}"/Library/Preferences/com.apple.SetupAssistant LastSeenBuddyBuildVersion "${sw_build}"
			chown "${USER_UID}"
"${USER_HOME}"/Library/Preferences/com.apple.SetupAssistant.plist
		fi
	fi
	done

Disable diagnostics at login

A second prompt that OS X has started offering at login is whether the user would like to submit diagnostic information. In a lot of our setups this isn’t something we want to ask the user so we disable it using a similar method to iCloud, although in this case we are back to plistbuddy as the information is stored in an array:
We normally use two variables for submitting info to Apple and to developers. This is just to make it easy to toggle them on and off as needed:

SUBMIT_TO_APPLE=NO
SUBMIT_TO_APP_DEVELOPERS=NO

Then the main body of the script:

PlistBuddy="/usr/libexec/PlistBuddy"
os_rev_major=`/usr/bin/sw_vers -productVersion | awk -F "." '{ print $2 }'`
if [ $os_rev_major -ge 10 ]; then
  CRASHREPORTER_SUPPORT="/Library/Application Support/CrashReporter"
  CRASHREPORTER_DIAG_PLIST="${CRASHREPORTER_SUPPORT}/DiagnosticMessagesHistory.plist"
  if [ ! -d "${CRASHREPORTER_SUPPORT}" ]; then
    mkdir "${CRASHREPORTER_SUPPORT}"
    chmod 775 "${CRASHREPORTER_SUPPORT}"
    chown root:admin "${CRASHREPORTER_SUPPORT}"
  fi
  for key in AutoSubmit AutoSubmitVersion ThirdPartyDataSubmit
ThirdPartyDataSubmitVersion; do
    $PlistBuddy -c "Delete :$key" "${CRASHREPORTER_DIAG_PLIST}" 2> /dev/null
  done
  $PlistBuddy -c "Add :AutoSubmit bool ${SUBMIT_TO_APPLE}"
"${CRASHREPORTER_DIAG_PLIST}"
  $PlistBuddy -c "Add :AutoSubmitVersion integer 4"
"${CRASHREPORTER_DIAG_PLIST}"
  $PlistBuddy -c "Add :ThirdPartyDataSubmit bool ${SUBMIT_TO_APP_DEVELOPERS}"
"${CRASHREPORTER_DIAG_PLIST}"
  $PlistBuddy -c "Add :ThirdPartyDataSubmitVersion integer 4"
"${CRASHREPORTER_DIAG_PLIST}"
fi

Disable Time Machine Popups Offering for New Disks

When you plug in an external drive to a Mac, it will automatically offer to use it as a Time Machine destination. While most users would know which option to select, it is often not worth the risk. You can disable Time Machine offering new disks for backup with the following command:

 /usr/bin/defaults write /Library/Preferences/com.apple.TimeMachine
DoNotOfferNewDisksForBackup -bool true

Turn off Gatekeeper

This is possibly a questionable command from a security perspective. Personally I like to keep Gatekeeper in its strictest setting, as I can manually allow new apps if needed. In some situations however you may want to disable Gatekeeper so that your install PKGs and other apps can run without warning messages. To configure this setting use the following command:

spctl --master-disable

This is only advisable if you have good control over who can run and install what on the Macs. If your users are admins, or if they use the Macs on unfiltered Internet connections, this might not be such a good idea.
For more information about Gatekeeper, take a look at these previous blogs:

Turn on right-click

We often get requests to enable right-click by default. This is another one that needs to be set in the user template for any new users and the existing home folders for any users that have already logged in:
To add the setting to the user template:

for USER_TEMPLATE in "/System/Library/User Template"/*
	do
	/usr/bin/defaults write
"${USER_TEMPLATE}"/Library/Preferences/com.apple.driver.AppleHIDMouse Button2 -int 2
    /usr/bin/defaults write
"${USER_TEMPLATE}"/Library/Preferences/com.apple.driver.AppleBluetoothMultitouch.mouse MouseButtonMode -string TwoButton
    /usr/bin/defaults write
"${USER_TEMPLATE}"/Library/Preferences/com.apple.driver.AppleBluetoothMultitouch.trackpad TrackpadRightClick -int 1
done

To add it to existing user home folders:

for USER_HOME in /Users/*
	do
		USER_UID=`basename "${USER_HOME}"`
		if [ ! "${USER_UID}" = "Shared" ]
		then
			if [ ! -d "${USER_HOME}"/Library/Preferences ]
			then
			mkdir -p "${USER_HOME}"/Library/Preferences
			chown "${USER_UID}" "${USER_HOME}"/Library
			chown "${USER_UID}" "${USER_HOME}"/Library/Preferences
			fi
			if [ -d "${USER_HOME}"/Library/Preferences ]
			then
				killall -u $USER_UID cfprefsd
				/usr/bin/defaults write
"${USER_HOME}"/Library/Preferences/com.apple.driver.AppleHIDMouse Button2 -int 2
    			/usr/bin/defaults write
"${USER_HOME}"/Library/Preferences/com.apple.driver.AppleBluetoothMultitouch.mouse
MouseButtonMode -string TwoButton
    			/usr/bin/defaults write
"${USER_HOME}"/Library/Preferences/com.apple.driver.AppleBluetoothMultitouch.trackpad
TrackpadRightClick -int 1
			fi
		fi
done

Turn off restore windows
If you don’t want application windows to automatically re-open when apps are re-launched, you can use the following script:

for USER_TEMPLATE in "/System/Library/User Template"/*
	do
	/usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/
.GlobalPreferences NSQuitAlwaysKeepsWindows -boolean FALSE
done

To add it to existing user home folders:

for USER_HOME in /Users/*
	do
		USER_UID=`basename "${USER_HOME}"`
		if [ ! "${USER_UID}" = "Shared" ]
		then
			if [ ! -d "${USER_HOME}"/Library/Preferences ]
			then
			mkdir -p "${USER_HOME}"/Library/Preferences
			chown "${USER_UID}" "${USER_HOME}"/Library
			chown "${USER_UID}" "${USER_HOME}"/Library/Preferences
			fi
			if [ -d "${USER_HOME}"/Library/Preferences ]
			then
			killall -u $USER_UID cfprefsd
			/usr/bin/defaults write "${USER_HOME}"/Library/Preferences/
.GlobalPreferences NSQuitAlwaysKeepsWindows -boolean FALSE
			fi
		fi
done

Stop writing .DS_Store files on the network

This is one for the Windows admins. To stop the Mac clients leaving a trail of .DS_Store files on network drives, use the following:

for USER_TEMPLATE in "/System/Library/User Template"/*
	do
	/usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/.GlobalPreferences DSDontWriteNetworkStores -bool TRUE
done

To add it to existing user home folders:

for USER_HOME in /Users/*
	do
		USER_UID=`basename "${USER_HOME}"`
		if [ ! "${USER_UID}" = "Shared" ]
		then
			if [ ! -d "${USER_HOME}"/Library/Preferences ]
			then
			mkdir -p "${USER_HOME}"/Library/Preferences
			chown "${USER_UID}" "${USER_HOME}"/Library
			chown "${USER_UID}" "${USER_HOME}"/Library/Preferences
			fi
			if [ -d "${USER_HOME}"/Library/Preferences ]
			then
			killall -u $USER_UID cfprefsd
			/usr/bin/defaults write "${USER_HOME}"/Library/Preferences/.GlobalPreferences DSDontWriteNetworkStores -bool TRUE
			fi
		fi
done

Set the Users Homepage

Safari home pages can be set various different ways. I have often included this in first run scripts so I can be sure that new windows and tabs are behaving just as I need them:

HOMEPAGE="www.amsys.co.uk"
for USER_TEMPLATE in "/System/Library/User Template"/*
	do
	/usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari.plist HomePage -string "$HOMEPAGE"
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari.plist NewTabBehavior -integer 0
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari.plist NewWindowBehavior -integer 0
done
# Existing users
killall cfprefsd
for USER_HOME in /Users/*
	do
		USER_UID=`basename "${USER_HOME}"`
		if [ ! "${USER_UID}" = "Shared" ]
		then
			if [ ! -d "${USER_HOME}"/Library/Preferences ]
			then
			mkdir -p "${USER_HOME}"/Library/Preferences
			chown "${USER_UID}" "${USER_HOME}"/Library
			chown "${USER_UID}" "${USER_HOME}"/Library/Preferences
			fi
			if [ -d "${USER_HOME}"/Library/Preferences ]
			then
				echo "Working on home folder preference file: ${USER_HOME}/Library/Preferences/com.apple.Safari.plist"
				mv "${USER_HOME}"/Library/Preferences/com.apple.Safari.plist "${USER_HOME}"/Library/Preferences/com.apple.Safari.plist_bak
				/usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.Safari.plist HomePage -string "$HOMEPAGE"
    			/usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.Safari.plist NewTabBehavior -integer 0
    			/usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.Safari.plist NewWindowBehavior -integer 0
    			chown $USER_UID "${USER_HOME}"/Library/Preferences/com.apple.Safari.plist
			fi
		fi
done

The numbers after the -integer option refer to specific settings accepted by the Safari preference file:
0 – Homepage
1 – Empty Page
2 – Same Page
4 – Top Sites

Example Completed Script

If you would like to test out a completed version of this script you can find it on our Github page
Read “Best Practices in 2015: Managing Settings in Mac OS X and iOS” next

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.