If you’re planning to upgrade to OS X El Capitan and you use Outlook 2011 to get email from Microsoft Exchange, you may want to delay upgrading. On El Capitan, connecting to Exchange email servers causes Outlook 2011 to freeze and display a beachball cursor.
Update 10-7-2015: Microsoft has released Microsoft Office for Mac 2011 14.5.6 Update, which resolves the problem with Outlook freezing. To get the update, please use the Microsoft AutoUpdate application or download it manually from the link below:
The issue appears to only affect Outlook 2011 when configured to access Exchange servers. When set up with only IMAP accounts, Outlook 2011 does not appear to display this behavior.
Microsoft is aware of the issue and has posted a knowledgebase article about it:
As of September 28th, 2015, Apple has apparently removed the listings for older versions of OS X and other discontinued software from the Purchased tab of users who had previously purchased or downloaded them.
With this software unavailable in the Mac App Store, this change means that it’s no longer possible to download the following versions of OS X from the Mac App Store:
- Mac OS X Lion
- OS X Mountain Lion
- OS X Mavericks
Update – 9-29-2015: The listings for older versions of OS X and other discontinued software have re-appeared in the Purchased tab as of this morning, so this software is now available for download again.
Fortunately, it’s still possible to download installers for these versions of OS X, provided you have access to a Mac or virtual machine running the version of OS X that you need to download. For more details, see below the jump.
In the wake of the release of Casper 9.8, where the Casper agent’s jamf and jamfAgent binaries have made their planned move from /usr/sbin to /usr/local/jamf/bin, a number of Casper-using folks who were used to running commands that referenced the jamf and jamfAgent binaries from Apple Remote Desktop (ARD) or other tools began to see errors that indicated that the jamf and jamfAgent binaries could not be found.
Conversely, opening a Terminal session and running the exact same command works fine.
Why are different tools acting differently? The root cause is that they each have different PATH environmental variables, usually referred to as $PATH. For more details, see below the jump.
OS X El Capitan’s new System Integrity Protection (SIP) security feature stores its active security configuration in NVRAM. This allows SIP’s configuration to persist across OS installs, but this design choice also means that resetting NVRAM will cause SIP to reset as well. In my testing, this reset will result in the following SIP configuration:
- SIP will be enabled with all protections in place
- No entries will be set in the SIP NetBoot whitelist
Resetting the NVRAM, otherwise known as a PRAM reset or PRAM zap, has been a standard part of the Mac troubleshooting toolkit for a long time and is performed by pressing and holding down the Option, Command (⌘), P, and R keyboard keys at startup.
For shops that do not plan to change SIP’s default configuration or set a NetBoot whitelist, NVRAM resets causing SIP’s configuration to also reset should not affect normal operations.
However, for those shops who will need to maintain a NetBoot whitelist or a custom SIP configuration, I would advise education where needed about this change and how it affects SIP configuration in your environment.
OS X El Capitan adds a new security feature named System Integrity Protection (SIP). Among other things, SIP prevents parties other than Apple from adding, deleting or modifying directories and files stored in certain directories:
Apple has indicated that the following directories are available for developers to access:
All directories in /usr except for /usr/local are protected by SIP.
SIP’s protection of /System affects XProtect’s XProtect.plist and XProtect.meta.plist configuration files as they are stored in the following location inside /System:
As the XProtect configuration files will be locked against editing on OS X El Capitan, this means that they can no longer be managed to allow older versions of the Flash and Java browser plug-ins to run.
If your shop includes a mission-critical system that requires using older Flash or Java browser plug-ins, I recommend working with your vendor and/or in-house developers to find out:
- If the use of the Java and/or Flash browser plug-ins can be discontinued.
- If their use can’t be discontinued, if the system in question can be updated to support the latest versions of these plug-ins and continue to be compatible as new versions of the Java and/or Flash browser plug-ins are released.
Update – 9-14-2015: Josh Dyson has pointed out that there is a way to allow older plug-ins to access specific sites.
By adding the needed sites to a whitelist in Safari and setting those specific sites to Allow Always, those sites’ functions will be accessible with the older browser plug-in even if XProtect would otherwise block the use of the plug-in. Websites not included in the whitelist would still have the use of the plug-in blocked.
Apple has provided a KBase article showing how to manage Safari plug-in options, including how to whitelist websites, using a configuration profile. It’s available via the link below:
Apple took an unusual step this week and released a knowledgebase (KBase) article that refers to an as-yet unreleased operating system:
I can only praise the decision to create it. The content covered affects a number of enterprise Mac environments and gives the Mac admins who support those environments time to prepare for an important change which may affect them.
That said, the KBase article itself is confusingly written and also includes an error. For more details, see below the jump.