SMB2 and 3 Enrichment Reading

Ever since Apple announced they were replacing Apple Filing Protocol (AFP) with Server Message Block (SMB) as the default file sharing language in OS X 10.9 “Mavericks” and beyond, Mac admins have had a love and hate relationship with trying to get SMB working in their environment.  A love of not having to be the odd man out in the file sharing world, and a hate of trying to make SMB perform as reliably as the well-worn AFP.  If your environment is supporting Macs that use SMB servers, a handful of links should be enlightening (and required) reading regarding why performance issues exist.  While these links alone won’t fix issues, they will provide insight into what’s going on:

• [Samba] Mac OS Mavericks über slow
  An enlightening mailing list post from Ralph Böhme detailing the behavior of the Finder when obtaining file lists from a SMB server, as well as discussing Apple’s addition of the “AAPL” SMB2 Create Context.  Ralph’s emails on the MacEnterprise Mailing List (Google Groups link for MacEnterprise Mailing list for easier reading) and other mailing lists are always worth reading.
• Ask The Expert, OneFS and the Mac: Command+K to Awesome!
  An online Q and A session with Bernie Case of EMC regarding OS X interacting with EMC’s NAS products. Worth reading even if you’re not an EMC customer.
• vfs_fruit (better Samba/Netatalk integration)
  “Starting with Samba 4.2 a new VFS module called vfs_fruit (instead of vfs_apple) will be available to Samba that will address the most common challenges accessing the same set of data from OS X clients via AFP and SMB: File/record locking, encoding quirks introduced by Apple and especially access to Finder metadata and ressource forks.” Note Samba 4.2 was released on March 4, 2015.

If your current file sharing vendor doesn’t support a feature like “vfs_fruit” (the last bullet above), use the above links to write a feature request for your vendor.  In our case, we submitted a NetApp feature request (FPVR-00046972, feel free to add the voice of your organization!) to implement the “AAPL” SMB2 Create Context as discussed in the SMB2 source for OS X 10.9 Mavericks and OS X 10.10 Yosemite.

Advertisements

Disabling Java 8 Sponsor Offer Installation

Oracle Java 8u40 for OS X includes a new, unwanted payload–for those who aren’t paying attention, clicking right through the installation means the ask.com toolbar is now installed on their computer.  Oracle does offer a support page which details installing Java 8u40 without the toolbar, but the options boil down to two techniques:

1. Install Java first so sponsor offers can be disabled though the Java Control Panel
2. Use the command line and pass in the appropriate argument

#1 is kinda silly (installing software just to access a setting seems a bit unusual), and while #2 isn’t so bad it’s not the path the Java 8 updater wants to take you.  The Java 8 updater happily reattempts to install the sponsor offers.  So let’s say there are users with admin rights in your organization who theoretically could update or reinstall Java 8, how can we prevent sponsor offers on their computers?  Using fseventer, let’s see what files are modified when technique #1 above is applied:

defaults read ~/Library/Preferences/com.oracle.javadeployment.plist

{
 "/com/oracle/javadeployment/" = {
 "deployment.modified.timestamp" = 1426392515218;
 "deployment.version" = 8;
 "install.disable.sponsor.offers" = true;
 };
}

defaults read ~/Library/Application\ Support/JREInstaller/ThirdParty.plist

{
  SPONSORS = 0;
}

cat ~/Library/Application\ Support/Oracle/Java/Deployment/deployment.properties

#deployment.properties
#Sat Mar 14 21:11:41 PDT 2015
deployment.modified.timestamp=1426392701602
deployment.version=8
install.disable.sponsor.offers=true
#Java Deployment jre's
#Sat Mar 14 21:11:41 PDT 2015
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.8
deployment.javaws.jre.0.osname=Mac OS X
deployment.javaws.jre.0.path=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
deployment.javaws.jre.0.product=1.8.0_40
deployment.javaws.jre.0.osarch=x86_64
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.args=

Beyond this, there are mentions across the Internet of placing the following lines in the system’s deployment.properties:

install.disable.sponsor.offers=true
install.disable.sponsor.offers.locked

However in my testing, currently the only file that matters is ThirdParty.plist, and the Oracle Java 8 installer only (per opensnoop) looks in the user’s home for this file:

  501    209 cfprefsd       4 /Users/admin/Library/Preferences/com.apple.HIToolbox.plist 
  501    851 MacJREInstaller  -1 /Users/admin/Library/Autosave Information/Oracle.MacJREInstaller.plist 
  501    851 MacJREInstaller  27 /Users/admin/Library/Application Support/JREInstaller/JREInstallLog.txt 
  501    851 MacJREInstaller  -1 /Users/admin/Library/Application Support/JREInstaller/ThirdParty.plist 
  501    851 MacJREInstaller  27 /Users/admin/Library/Application Support/JREInstaller/JREInstallLog.txt 
  501    851 MacJREInstaller  27 /.vol/16777218/185166 
  501    851 MacJREInstaller  27 /Users/admin/Library/Application Support/JREInstaller/JREInstallLog.txt

Setting any or all of the above files except ThirdParty.plist and the sponsor offers are still offered.  ThirdParty.plist can be set with the following command:

defaults write ~/Library/Application\ Support/JREInstaller/ThirdParty SPONSORS -string "0"

run via a LaunchAgent, Outset, or some equivalent method.  Once ThirdParty.plist is set, future GUI installations of Java 8 will completely skip the sponsor offers step and immediately install Java.  Of course, keep in mind this all could change with the next release of Java.

Thanks to Johannes Seitz for researching the situation.  I was working on this so late at night I don’t recall whether Johannes originally wrote the above command or if I did (or maybe we both reached the same conclusion).  Cheers Johannes!

Outlook 2011 Folder Item Count Recommendations

Recently a user asked what the limits were for good performance in Outlook 2011.  Checking around the various support articles I found (italics mine):

• Microsoft KBase Article 905803, “Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server“
  “We recommend that you maintain a range of 2,500 to 5,000 items in a folder, depending on the capacity of the Exchange Server environment. Additionally, you can create more top-level folders or create subfolders under Inbox, Sent Items, and Deleted Items. When you do this, the costs that are associated with index creation are greatly reduced, if the number of items in any one folder does not exceed 5,000.”
• Microsoft article “Best practices for Outlook for Mac 2011“
  “If this folder becomes too large (10,000 items or more), Outlook for Mac 2011 might become slow when switching to this folder.”
• Microsoft article “How do I improve the performance of Outlook for Mac 2011?“
  “Keep a maximum of 20,000 items each in the Inbox and Sent Items folders (includes the folders and subfolders). For optimal performance, keeping less than 5000 items each in calendar, contacts, tasks, and notes folders is highly recommended.”

So the number of items is in question and also whether or not subfolders count toward that number.  I contacted Microsoft support and asked which answers were correct–here is the response:

• “I would recommend keeping the Inbox, Sent and Deleted items folders below 10,000 items if possible.”
• “Keep a maximum of 20,000 items each in the Inbox and Sent Items folders (includes the folders and subfolders).”
• “The Calendar, Contacts and Tasks should stay below 5,000 if possible.”

Note that these recommendations were easier for Microsoft support since my company uses Office 365 Hosted Exchange and thus the Exchange environment was known by support.  Different Exchange servers may not be able to support this sort of load and may require lower item counts.