As part of the release of Casper 9.93, JAMF has added options for suppressing the iCloud and Diagnostics pop-up windows to the following MDM profile payloads:

• Login Window
• Security & Privacy

The iCloud pop-up window can be managed via the Login Window profile payload. To suppress the iCloud pop-up window, click on the Options tab for that payload and check the Disable Apple ID setup during login option.

The Diagnostics pop-up window can be managed via the Security & Privacy profile payload. To suppress the Diagnostics pop-up window, click on the Privacy tab for that payload and uncheck the Allow sending diagnostic and usage data to Apple, and sharing crash data and statistics with app developers option.

A colleague recently asked for assistance with opening a particular document, which was created using Microsoft Works. Microsoft Works had a long run as a lower-cost alternative to Microsoft’s Office for Microsoft Windows and MS-DOS, and was available in one version or another for about twenty years between 1988 and 2008. As a consequence, a number of older PCs still have it installed and Mac users will occasionally receive Works documents. Unfortunately, Microsoft Works was not ported to the Mac so it can be difficult to open these files.

After talking with my colleague and researching this issue, I found two ways (one is free, the other is using a paid application) to open Microsoft Works files. For more details, see below the jump.

The non-free way is to use Works Document Viewer for Mac. This is an application which allows Works documents to be opened for viewing and also converted to another format. It’s available on the Mac App Store via the link below:

https://itunes.apple.com/us/app/works-document-viewer/id551442338?mt=12

The free way leverages the Zamzar.com file conversion site. See below for the procedure to use:

1. Change the document’s file extension from .wps to .doc.

2. Open a web browser and go to the following site: http://www.zamzar.com

3. Select the Works document.

4. Select the format you want to convert the document to.

5. Enter a convenient email address where Zamzar can email you about the converted file.

6. When all is set as desired, click the Convert button.

7. Zamzar will convert the Works file to the desired format and email you a download link.

8. Once downloaded, you should be able to open the Works document.

As part of setting up a dual-boot configuration for a group at my shop, I was working with a colleague to set up a new Windows 10 installation using Boot Camp on a new Retina MacBook Pro. As part of the process, we did what we normally did and plugged in a USB flash drive to store the Windows installation files on.

The Boot Camp Assistant asked for the location of the Windows 10 .iso file, proceeded to repartition the disk, then rebooted into the Windows install process. When prompted where we wanted to install Windows, we selected the BOOTCAMP partition and clicked Format.

At that point, Windows formatted the drive. So far so good. We then selected the drive, clicked the Next button, and received the following error:

We couldn‘t create a new partition or locate an existing one. For more information, see the Setup log files.

Our thought at that point was that something had gone wrong with the format, so we booted back to OS X, had Boot Camp Assistant remove the Windows partition and tried again.

Same result, same error.

We went back to the Boot Camp documentation and read it over carefully. There is a note about unplugging Thunderbolt devices, but we didn’t have any plugged in.

So we tried again, starting over from scratch. Same result, same error.

After some additional research, we finally found the answer: The note should have read “Thunderbolt or USB storage devices”. This additional information is included in an Apple KBase article for installing Windows 8 using Boot Camp, which has the following procedure:

1. Shut down your computer.
2. Disconnect all Thunderbolt and USB storage devices, except for the USB media which contains the Windows ISO installer.
3. Try the installation again.

But the reason we had any USB drives plugged in was because we had thought Boot Camp Assistant was going to store the Windows installer on that flash drive. So why was Windows complaining?

The answer is Boot Camp in El Capitan does not store the Windows ISO installer on a USB flash drive. Instead, the Boot Camp Assistant will create a temporary FAT32 partition, name it OSXRESERVED, and store the Windows installation files on the OSXRESERVED partition.

Since the USB flash drive wasn’t being used as the source of Windows installer files, having it plugged in was causing the error to appear.

So we shut down, unplugged the USB flash drive, and again re-ran the installation. This time, no error and Windows 10 installed without a problem.

As part of the pre-release announcements about macOS Sierra, Apple released the following KBase article:

https://support.apple.com/HT206871

As part of the KBase article, Apple included a Changes coming with macOS Sierra section which featured this note:

Portable home directories (PHDs) were Apple’s attempt at providing roaming user profiles. Starting in Mac OS X 10.3.x, you could configure a person’s account so that the data in their home folder resided on a server in a network home folder. The data on the server was then synchronized with copies of the same data residing on the one or more Macs that particular person used on a day-to-day basis.

It was also possible to configure what data was synchronized between the Mac(s) and the server, to conserve space on the server for only essential data.

Unfortunately, the idea was better in concept than it was in execution. Depending on how much data needed to be synchronized, the copying process between the server and the individual Macs could take a while.

Synchronization conflicts were also left for the user to figure out, which usually meant a call to the local help desk.

The synchronization agent itself was prone to crashing when working particularly hard.

The problems with the synchronization process, coupled with the increasing availability of continuous backup solutions like CrashPlan and Apple’s diminishing support for PHDs, helped make portable home directory deployment something many Mac admins avoided. Nine OS releases after PHDs’ initial debut in 10.3.x., it appears Apple now agrees with that sentiment.

I do a lot of work with virtual machines running in VMware’s Fusion hypervisor software. As part of that work, I’ll occasionally run into the following issue:

1. I’m running an application inside a VM.
2. I’m done with whatever it is and want to quit out.
3. The focus of my keyboard is not inside the VM
4. I click the Command (⌘) and Q keys to quit the application running inside the VM.
5. Instead of the application inside of the VM quitting, I see this.

6. Then I say something like this.

As part of this, I’ve often wished for some way for Fusion to warn me when I’m about to accidentally quit Fusion instead of quitting an application inside a VM. That led to me making the following observation on Twitter:

I was quickly informed that Fusion in fact had exactly that.

For more information, see below the jump.

Setting VMware Fusion 8.x to confirm you want to close a VM:

1. Launch VMware Fusion

2. Under the VMware Fusion menu, select Preferences…

3. In the General tab, check the Confirm before closing checkbox.

4. Close the Preferences window

Once the Confirm before closing option has been selected, actively running Fusion VMs should now prompt you to confirm that you want to close the VM.

As part of Apple’s Upgrade to macOS Sierra documentation, there’s been a change in the system requirements for macOS Sierra as opposed to OS X El Capitan.

For OS X El Capitan, the earliest OS you can upgrade from is Mac OS X Snow Leopard 10.6.8.

For macOS Sierra, the earliest OS you can upgrade from is OS X Lion 10.7.5.

If you’re upgrading from 10.6.8, Apple’s guidance is to upgrade first to El Capitan and then to Sierra.

In the course of my testing of macOS Sierra this week, I decided to turn on iCloud Desktop and Documents syncing. This was my reaction:

I can’t discuss the details of my testing yet because the macOS Sierra NDA still applies until Sierra is released on September 20, 2016. However, for those Mac admins who have also tested this and wish to block it in their own environments ahead of macOS Sierra’s release, I’ve built a management profile and made it available via the link below:

https://github.com/rtrouton/profiles/tree/master/DisableiCloudDriveandDocumentSync

This profile has been tested and works on OS X 10.11.6 and later. It restricts access to the iCloud Drive settings in the iCloud preference pane by graying out iCloud Drive and making it non-selectable.

As part of preparing for macOS Sierra, I’m planning to provide a way for my customers to upgrade themselves to Sierra via Casper’s Self Service. Unlike the upgrade process I was able to provide for OS X Yosemite and El Capitan, where I could filter based on whether or not a particular Mac could run OS X 10.8.x, Sierra’s system requirements exclude some Macs which can support running OS X El Capitan.

To help make sure that Self Service wasn’t providing the option of upgrading to macOS Sierra to a Mac which couldn’t run it, I needed to compile lists of which Mac models could and couldn’t run macOS Sierra, based on the system requirements that Apple provided. For more details, see below the jump:

As of Tuesday, September 20 2016, here is the list of Mac models not compatible with macOS Sierra:

As of Tuesday, September 20 2016, here is the list of Mac models compatible with macOS Sierra (with both model ID and board ID):

Once both lists were compiled, I had to decide whether or not to filter based on if a Mac was compatible or incompatible with Sierra. Since the list of incompatible Macs was not likely to change, I decided to go the route of excluding incompatible Macs. As part of that, I needed to build a Casper smart group containing the model IDs of those incompatible Macs.

Since that was otherwise going to involve a lot of clicking in the web interface, I opted to build a smart group XML file and then import the complete smart group via the Casper API. The smart group XML file is available below:

To upload it to a JSS server using the API, download the XML file to a convenient location, then run the command shown below (substituting as appropriate):

curl -skfu username:password https://casper.server.here:8443/JSSResource/computergroups/id/0 -T /path/to/filename.xml -X POST;

If the smart group was successfully uploaded, you should next see output similar to that shown below:

A new smart group named Macs incompatible with macOS Sierra should also now be present on the JSS.

Starting in 10.7.2, Apple set the iCloud sign-in to pop up on the first login.

In 10.10, Apple added a new Diagnostics & Usage window that pops up at first login after the iCloud sign-in.

In 10.12, Apple added another new pop-up window for Siri.

To stop the Siri pop-up window from appearing for your home folder, run the command shown below:

defaults write com.apple.SetupAssistant DidSeeSiriSetup -bool TRUE

Since you normally will be able to run this command only after you’ve seen the Siri pop-up window, I’ve updated my script for suppressing the iCloud and Diagnostic pop-up windows to now also suppress the Siri pop-up window. For more details, see below the jump.

The script is below and is also available on my GitHub repo. This script is also available as a payload-free package on my GitHub repo, available for download from the payload_free_package directory available from the link above.

For those who want to disable the Siri pop-up window using management profiles, I’ve created a .mobileconfig file and posted it here on Github:

https://github.com/rtrouton/profiles/tree/master/SkipSiriSetup

Siri is a welcome addition to macOS Sierra, but in certain environments it’s a service which needs to be disabled. For those Mac admins who need to do this, here are the relevant keys:

Stop Siri from running:

Block Siri’s menubar icon:

For those who want to disable Siri using management profiles, I’ve created .mobileconfig files and posted them here on Github:

https://github.com/rtrouton/profiles/tree/master/DisableSiri

Hat tip to Brad Vrooman for posting about the correct settings.

One of the changes made in macOS Sierra is summed up by my colleague @n8felton below:

/Volumes is the invisible directory used by OS X and macOS as the OS’s default mount point for accessing the filesystems of other storage (like external hard drives, USB flash drives, mounted disk images, network fileshares, etc.)

Up to OS X El Capitan, the /Volumes directory was world-writable and had the following permissions:

This meant that any process or user could create a directory inside /Volumes or store files there.

World-writable directories are generally seen as a security risk, which may explain why Apple chose to change the permissions on the /Volumes directory. As of macOS Sierra, the permissions on the directory are as follows:

This change means that the /Volumes directory is readable by anyone but can only be written to by processes using root privileges.

This permissions change should not affect the system’s ability to mount storage devices or fileshares from network servers, as the OS itself is the one handling the mounting and has all the necessary permissions.

While working on some documentation, I noticed a behavioral change in macOS Sierra’s sudo tool that was different from how sudo behaves on OS X El Capitan.

El Capitan

if you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you won’t be prompted for your password in either Terminal session until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:

Sierra

If you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you’ll get asked for your password in the second Terminal session too. Meanwhile, in the first Terminal session, you won’t get prompted again until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:

The difference is that Apple has compiled sudo on Sierra to include the tty_tickets option, which ensures that users need to authenticate on a per-Terminal session basis.

This option had not been included in sudo on OS X El Capitan and earlier, which had been viewed as a privilege escalation vulnerability.

If you want sudo to return to using the pre-Sierra behavior on macOS Sierra, edit /etc/sudoers to add the following option:

Apple made a change to the fdesetup authrestart command in macOS Sierra, where running fdesetup authrestart will no longer require the encrypted Mac in question to restart immediately.

The delayed restart option can be enabled by adding the -delayminutes verb to the fdesetup authrestart command and specifying one of the following:

• Time in minutes = Delay the restart command for a set number of minutes
• 0 = immediate restart
• -1 = wait indefinitely for restart

Using the -1 option means that the user can restart at their convenience and their encrypted Mac will automatically bypass the FileVault 2 pre-boot login at the next reboot.

To show what this behavior looks like, please see the videos below:

fdesetup authrestart delayminutes 0

fdesetup authrestart delayminutes 0

Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 1 minute 30 seconds.

fdesetup authrestart delayminutes 1

fdesetup authrestart delayminutes 1

Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 2 minutes 18 seconds.

fdesetup authrestart delayminutes -1

fdesetup authrestart delayminutes -1

Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 1 minute 43 seconds.

As part of the iCloud services in macOS Sierra, Apple is offering a new way to store your files in iCloud – synchronizing the contents of your account’s Desktop and Documents folder with iCloud Drive.

When you enable the option to store files from your Desktop and Documents folder, the contents of your Desktop and Documents folder are moved (not copied) from your home folder into iCloud Drive. Those folders will no longer appear in your home folder.

That means that your Desktop and Documents folder no longer are stored in your home folder. Instead, they and all their contents are now stored in iCloud Drive.

For more details on this, see below the jump.

In reality, the Desktop and Documents folders folders themselves have been moved to a new location inside your home folder, where they’re invisible to the average user but still provide a place to sync files between the Mac and iCloud Drive. The new location is as follows:

~/Library/Mobile Documents/com~apple~CloudDocs

The Good

The virtue of this idea is that, as you enable iCloud Desktop and Documents on your various Macs, you get a unified Desktop and Documents experience. As you add files to those directories on one machine, all of your other machines should get updated with the same information. You can also access the files from the iCloud web interface and the iCloud Drive app on your iOS devices, in the event that you’re away from your Mac(s) and need to get something that is stored in the Desktop or Documents folders on your Mac(s).

iCloud in this sense is serving as the authoritative source of “truth” for your files and your various Macs are checking in and updating files on themselves as needed. When all of this works, it looks like magic and all your files are everywhere you need them.

When all of this works. What happens when it doesn’t?

The Bad

Currently, Apple provides 5 GBs of storage space for free for iCloud users. That 5 GBs of storage includes storage for your iCloud email, your iCloud backups for your iOS device(s), your iCloud Photo library and iCloud Drive. If you need more than 5GBs of storage space, you have to pay for it.

Considering that most folks likely have more than 5 GBs of files stored in their home folder’s Documents directory, let alone their Desktop folder, there are immediate issues with enabling iCloud Desktop and Documents syncing if you’re not paying Apple for sufficient iCloud storage space.

As an example of this, lets try adding a VMware VM to the Documents folder then turn on iCloud Desktop and Documents syncing.

VM is 11.55 GBs in size
Available iCloud space is 5 GBs

I immediately ran out of space on iCloud Drive and was prompted to upgrade.

To its credit, iCloud was smart enough to figure this out before it tried to upload the VM and did not actually try to upload the VM to iCloud Drive. It also allowed me to move the VM unharmed to a new location.

The Ugly

At this point in my testing, I decided that iCloud Desktop and Documents was interesting but because of storage limitations, it just wasn’t going to work well for me unless I paid Apple far more money for storage than I wanted to. I then did the following:

1. Opened System Preferences
2. Selected the iCloud preference pane

3. Clicked the Options… button next to iCloud Drive

4. Unchecked Desktop & Documents Folder

At this point, I received a warning that the documents on my Desktop and in my Documents folder would only be visible in iCloud Drive.

5. Clicked the Turn Off button on the warning dialog message.

At this point, I received a message letting me know that my documents are in the Desktop and Documents folders in iCloud Drive and that I could copy or move them back.

6. Clicked the OK button on the message.

Sierra then showed me that my Desktop and Documents folders were back in my account’s home folder. Great!

They were completely empty. What!?!?!?!

When you turn off the Desktop & Documents Folder feature in iCloud, Sierra recreates empty Desktop and Documents folders in your home folder. It’s on you to copy or move your files back from iCloud Drive.

However, that assumes that all of your files and folders made it to iCloud in the first place. What if they didn’t? Hopefully they can still be found in the Desktop and Documents folders in ~/Library/Mobile Documents/com~apple~CloudDocs.

If they’re not, hope you had other backups because those files and folders may just be completely gone.

Conclusions

Based on the results of my testing, I have no plans for enabling iCloud Desktop and Documents syncing on any of my Macs for the foreseeable future. Leaving aside that Apple isn’t offering enough storage space at prices I want to pay, the results I saw from my testing of the synchronization process did not inspire my trust in it.

It did give me an insight into why Apple chose to remove support for portable home directories (PHDs) in Sierra. The havoc that could be caused by two separate synchronization processes trying to sync the same set of files, especially when portable home directories were using a two-way sync process, would be breathtaking to behold. The only certain result would be that data loss would occur. Kudos to Apple for at least foreseeing that result and removing the possibility of PHDs and iCloud Desktop and Documents fighting with each other for file sync supremacy.

For those Mac admins that want to block iCloud Desktop and Documents in their own environments, please see the post linked below:

https://derflounder.wordpress.com/2016/09/20/disabling-icloud-drive-and-document-syncing/

My colleague @mikeymikey put out a call over Twitter to find out what folks want to manage with MDM profiles, but currently cannot.

There were so many great ideas that came out of the discussion that I wanted to capture as many as I could in one place. After some hunting this morning, I’ve posted them to Storify:

https://storify.com/rtrouton/making-mdm-manage-more

Got more ideas for things you want MDM to manage? File feature requests with Apple using Apple’s bug reporter. If you haven’t done this before, using QuickRadar makes filling bug reports much easier:

https://derflounder.wordpress.com/2015/08/26/using-quickradar-to-file-bug-reports-with-apple/

As was reported today, Apple is beginning to automatically download the macOS Sierra installer to compatible Macs. The installation process is not automatic, much like installing the macOS Sierra upgrade via the App Store. Instead, the macOS Sierra installation application will automatically download to /Applications.

Once finished downloading, the logged-in user will be alerted that the upgrade is available.

For environments where this automatic download is undesirable, there is a way to block it. For more details, see below the jump.

If you do not want the automatic download of the macOS Sierra installer application to occur, one important thing to know is that the Software Update function on the system in question must be set to automatically download updates in the background.

If this option is disabled, the macOS Sierra installer application will not download automatically.

You can manage this via the command line using the defaults command. To enable the automatic downloading of updates using the defaults command line tool, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticDownload -bool TRUE

To disable the automatic downloading of updates using defaults, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticDownload -bool FALSE

Update: 10-4-2016 – I made a mistake in my initial research of this issue, where I thought that the automatic check for updates needed to be disabled. Only the automatic download of updates needs to be disabled. Thank you to those folks who alerted me to the fact that I had the wrong information.

One other way to make certain that the macOS Sierra installer application will not download is to disable the automatic check for updates.

Without the automatic update check being enabled, the Mac will not check in for updates at all and background downloading of updates like the macOS Sierra installer application is automatically disabled.

Note: Disabling the automatic update check will also disable Gatekeeper, XProtect and SIP-related updates.

To control the automatic update check using the softwareupdate command line tool, run the following commands with root privileges:

To enable the automatic update check:

softwareupdate --schedule on

To disable the automatic update check:

softwareupdate --schedule off

You can also manage this using the defaults command. To enable the automatic update check using the defaults command line tool, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool TRUE

To disable the automatic update check using defaults, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool FALSE

For those who wanted a copy of my filesystem talk at MacSysAdmin 2016, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MSA2016FileSystemPDF

Keynote – http://tinyurl.com/MSA2016FileSystemKeynote

For those who wanted a copy of my virtualization talk at MacSysAdmin 2016, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MSA2016VirtualizationPDF

Keynote – http://tinyurl.com/MSA2016VirtualizationKeynote

As part of the various announcements at WWDC 2016 in June 2016, Apple announced that there would be a new filesystem named Apple File System (APFS) being released in 2017. As part of the functionality of APFS, encryption is being natively supported by APFS as a primary feature of the filesystem.

Encryption and APFS

APFS supports the following levels of encryption:

• No encryption – no data is encrypted
• One key per volume (for encrypting both metadata and data) – This is equivalent to how FileVault 2 works today
• Multi-Key encryption
  • – Metadata encryption
  • – Per-File encryption
  • – Per-Extant encryption

What was not overtly stated as part of the presentation is that while Apple may continue to name the encryption “FileVault”, it will work differently than FileVault 2 does today. The reason for this is that FileVault 2 is using encrypted Core Storage volumes to provide full-volume encryption. Core Storage is built on top of HFS+ and it does not appear that Core Storage will be transitioning to APFS. Instead, it appears that Core Storage will remain an HFS+ – specific solution.

As of this date, I haven’t yet seen how APFS encryption works in practice, but one thing is clear – The move away from Core Storage is a fundamental change for how encryption will be handled for Macs, with the following areas being affected:

• How Macs become encrypted
• How to unlock the encryption
• How to decrypt an encrypted Mac
• How to repair problems affecting an encrypted Mac

In short, everything currently documented for handling encrypted Macs will likely become obsolete and new documentation will need to be written for APFS’ encryption solution.

What does this mean for FileVault 2?

With APFS already being available as a developer preview, I don’t anticipate Apple making any more changes to how FileVault 2 works. I believe that Apple is putting FileVault 2 into maintenance mode where (hopefully) bugs will be fixed but development otherwise has stopped in favor of developing APFS’ encryption.

In terms of FileVault 2 management, Apple may choose to add functionality in Sierra to Apple’s fdesetup management tool for FileVault 2 but I believe that any changes will be enhancement to existing functionality in fdesetup instead of adding new functionality. A good example of this is Sierra’s changes to fdesetup authrestart.

Starting in OS X Yosemite 10.10.x, I noticed an issue when enabling FileVault 2 via System Preferences when using an institutional recovery key.

In Mavericks and earlier versions of OS X, the behavior of System Preferences looked like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A list of users that can be enabled for FileVault 2 is displayed. The logged-in user account is marked with the green checkbox that shows that the account is enabled.
4. A message is displayed that a recovery key has been set by a company, school or institution.
5. A message prompting the user to restart is displayed.
6. Once the Restart button has been clicked, the FileVault 2 initialization process continues and restarts the Mac.
7. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

In OS X Yosemite and OS X El Capitan, the behavior of System Preferences looks like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A message is displayed that a recovery key has been set by a company, school or institution.
4. System Preferences then displays no additional messages and will appear to hang for up to two minutes.
5. The Mac restarts without further input from the user.
6. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

I had filed a bug report on the problem, which has now been closed as fixed after I was able to verify that the problem was resolved in macOS Sierra 10.12.0.

As of macOS Sierra 10.12.0, the behavior of System Preferences has returned to approximating the pre-Yosemite behavior. The process now looks like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A message is displayed that a recovery key has been set by a company, school or institution.
4. A list of users that can be enabled for FileVault 2 is displayed. The logged-in user account is marked with the green checkbox that shows that the account is enabled.
5. A message prompting the user to restart is displayed.
6. Once the Restart button has been clicked, the FileVault 2 initialization process continues and restarts the Mac.
7. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.