As part of the release of Office 2016 15.33.0, a number of managed preference options have been added and some have changed from what they were before. An example of one that has changed is the DefaultsToLocalOpenSave management setting, which sets the Open and Save options in Office 2016 apps to default to On My Mac instead of Online Locations.
In Microsoft Office 2016 15.32.x and earlier, the DefaultsToLocalOpenSave setting could only be managed by running a command similar to the one below on the individual user accounts:
/usr/bin/defaults write "/path/to/user/homefolder/Library/Group Containers/UBF8T346G9.Office/"com.microsoft.officeprefs DefaultsToLocalOpenSave -bool true
To set this for all accounts on a particular Mac, I had written the following script:
As of Microsoft Office 2016 15.33.x, this setting can now be set at the global level for all users by running the following command with root privileges:
/usr/bin/defaults write /Library/Preferences/com.microsoft.office DefaultsToLocalOpenSave -bool true
I’ve posted an updated script for manage this setting to GitHub, available via the link below:
This setting can now also be managed with a profile, so I’ve created a .mobileconfig file and posted it here on Github:
As part of my testing workflow, I’ve been using VMs running on a ESXi server running ESXi 6.5. To help me quickly build those VMs, I have been using a script named esxi_macos_vm_creation.sh for building VMs. This script is forked from Tamas Piros’s auto-create script for standing up Linux VMs on free ESXi:
My fork of the auto-create script is designed to create and configure virtual machines with Apple operating systems as the guest OS, hosted on a VMware ESXi server running on Apple hardware. The script assumes that the virtual machines are built using copied VMDK disk files, where the VMDK files are generated by AutoDMG and vfuse. For more details, see below the jump.
As part of working on a project recently, I ran into an unexpected problem with ESXi-hosted Mac VMs. For these VMs, I was creating VMDK files from AutoDMG-generated disk images, using vfuse to convert the disk image into a VM with ESXi-compatible VMDK disk image files.
My workflow looked like this:
1. Create disk image using AutoDMG.
2. Use vfuse to create VMDK files using a command similar to the one shown below:
sudo vfuse -i /path/to/autodmg_created_disk_image_here --esx
3. Upload the VMDK files to a convenient location on my ESXi server
4. Set up a new VM, using copies of uploaded VMDK files for the VM boot disk.
5. Resize the new VM to the desired size using VMware’s vmkfstools utility.
6. Start up the VM.
After logging in, I ran the following command to enable macOS to recognize and use the unallocated space from the VM resizing:
diskutil resizeVolume / R
Normally, this command is able to do a live re-sizing of the boot partition to use all available unallocated space. However, this time the re-sizing process failed and the following error was displayed:
How to fix this? For more details, see below the jump.
As a follow-up to my previous post about running multiple Jamf Pro policies via the API, my colleague John Kitzmiller pointed out that it was possible to achieve similar functionality by using a custom trigger. For more details, see below the jump.
As part of a project I’m working on, I need to run several policies from a Jamf Pro server using a script which is using the Jamf Pro agent to run policies. However, I also want to maintain maximum flexibility and retain the ability to add, remove or change policies as required without needing to change the script.
My colleague Marc provided a solution for this by letting me know that it was possible to use the Jamf Pro API to pull down a list of policies associated with a specific category and then running those policies in the order provided by the API. For more details, see below the jump.
I’ve had a tool available for a while named create_vmware_osx_install_dmg, but it looks like it has reached the end of the road with macOS 10.12.3. The reason for this is because macOS 10.12.4 has introduced a change that prevents the addition of third-party packages to the OS installer. create_vmware_osx_install_dmg uses the addition of a third-party installer package, so unfortunately this tool cannot be used to generate 10.12.4 or later OS installers.
That said, I still want to be able to create macOS installer disk images for VMware Fusion and ESXi, so I’ve forked create_vmware_osx_install_dmg into a new script named create_macos_vm_install_dmg. create_macos_vm_install_dmg will generate stock OS installer disk images for the following OS versions:
- Mac OS X 10.7.x
- OS X 10.8.x
- OS X 10.9.x
- OS X 10.10.x
- OS X 10.11.x
- OS X 10.12.x
This script does not use a third-party package, so it is able to build a macOS 10.12.4 installer disk image. For more details, see below the jump.
In a number of Mac environments, there is a need or requirement for a login banner (otherwise known as a lock message). This message appears in the following locations:
- FileVault 2 pre-boot login screen
- OS login window
- Screensaver lock window
Brevity is best, as staying within a maximum of three lines permits the banner text to be displayed consistently in all three locations. Exceeding the three-line limit may result in the text being cut off and not fully displayed.
You can set this banner text from the command line using the following defaults command, which should be run with root privileges:
/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"
Being able to consistently set when lines begin and end can be challenging though, as the defaults command is not able to interpret a newline command natively. However, it is possible to set a multi-line login banner and be able to consistently set when lines begin and end. For more details, see below the jump.