Microsoft Lync Keeps Requesting a Keychain Password for OC_KeyContainer

We have received several reports that Microsoft Lync (version 14.x) was constantly requesting a Keychain Password and displaying the following dialogue box:

The blocked out area shows the user's e-mail address.

On working systems there was an "OC_KeyContainer" in Keychain:

As well as a saved password in Keychain:

On system that had a problem these items were missing.

The solution we found was to go into ~/Library/Keychains and delete the "OC_KeyContainer_[user's e-mail address]. 

Remember that on 10.7 and above the user's library folder is hidden and you must show it by opening Terminal and typing "chflags nohidden /Users/[user's home folder name]/Library

After deleting the OC_KeyContainer file, launch Lync and log in and you should no longer receive the Keychain pop-up.

If you open Keychain Access.app you will notice that a new OC_KeyContainer Keychain and password have been created.

Note: if the OC_KeyContainer Keychain and password already exist in Keychain Access.app, delete them before removing the file from the user's Library folder.

Macs Unable to Connect to Secure Sites: OCSPD File Deleted

We received a report that 400+ Macs in two countries and a dozen locations were suddenly unable to login.  A quick fix was to remove the network cable, log in using the locally cached credentials and then plug the Ethernet cable back in.  However, the users were then unable to connect to any web-page using https, Outlook mail (using OWA) or any other connection that required secure communication.

All the Macs were bound to AD and being managed by Casper.

We soon found that by removing the JAMF binary we were able to log in but we still could not access any secure resources.  This made sense because at login/start-up the computer attempts to talk to the JSS and if secure communication is not possible the computer will hang.

Working with Apple Alliance Support (excellent as always) we were able to determine that the root of the problem lay in the fact that all the computers were missing the ocspd file from /usr/sbin/.  The ocspd file is used during certificate validation and if it is missing or corrupt a secure connection can not be established.

Using Composer we created packages to deploy new ocspd files.  Note: you must install like-for like, i.e. a good ocspd file from a 10.7.5 Mac must be deployed to another 10.7.5 Mac.

Unfortunately within a few minutes of deploying a new ocspd file, it was deleted.  After more digging through logs we found that it was a JAMF process that was causing the deletion so we removed the JAMF binary from all the Macs, pushed the good ocspd packages using ARD and it resolved the issue.

After the good ocspd packages are deployed, remove all the old computers from the JSS, ensure that a valid push-notification certificate is installed and that "enable certificate-based communication" is ticked in the framework settings of the JSS.  You should then be able to re-Recon all your Macs and the ocspd file will not be removed.  TEST FIRST on a few Macs!

If you suspect this issue the first thing to do is go to /usr/sbin and see if the ocspd file is missing.  If it is you must replace it with a known good ocspd file.  As described above, the easiest way to do this is with Casper Composer but if you do not have a copy of it you can do the following steps and deploy using ARD.

• Copy a good ocspd file to /usr/sbin/ to the non-working system
• Set ownership and permissions:

sudo chown root:wheel /usr/sbin/ocspd
sudo chmod 755 /usr/sbin/ocspd

•  Once the file has been copied and permissions applied the issue should be resolved- no reboot is required

The iPhone [name] could not be synced because the sync session failed to start

I started seeing this error after "upgrading" to iOS7.  There were lots of suggestions on the Net but this is the one that worked for me:

• Close iTunes and disconnect all iOS devices
• Open Terminal
• Go to /var/db/lockdown
• rm * (remove the contents of the folder, not the folder itself)
• Relaunch iTunes and reconnect your iOS device

Casper not Correctly Setting Software Update Server

We have received hundreds of reports that 10.8.4 Macs have been updating themselves to 10.8.5 even if they are managed by a local Software Update Server and the 10.8.5 update has not been authorized.

Although we do not have a single root cause, the problem definitely lies within the configurations being distributed (or not) by Casper.  Based on the conversations we have been having with Apple, Jamf and our agencies here are a few recommendations for your Casper set up:

• Set the Software Update Server through MCX for 10.6.8 Macs or a Configuration Profile for 10.7 and 10.8 Macs
• In the "Overwrite Default Policy Settings" area of any Software Update policy you have created use the pull-down next to "Software Update Server" to select "Each Computer's Default Server"
• Put a tick in "Set Server System Wide" (under Settings/Servers/Software Update Server) after you have done the above should correctly set the SUS for the managed clients on your subnets
• You could also set the default SUS in any Network Segments you have created (Settings/Update Network Segments) and it should set the correct SUS if you run a policy with just "Set Server" ticked in Packages/Set Server.

If you want Casper to collect the SUS a client is pointed to add the Extension Attribute "Apple Software Update Server" and replace the default script contents with:

#!/bin/sh

SWU=`defaults read /Library/Preferences/com.apple.SoftwareUpdate CatalogURL`

echo "$SWU"


Lastly if you want to brute-force the SUS settings to your computers, remove all references to the SUS from Casper policies, MCX, Configuration Profiles and Network Segments and deploy a script that contains these lines:

#!/bin/sh

defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://[your SUS server.yourCompany.com]:8088/index.sucatalog

killall Terminal

Error opening terminal: xterm-256color

After opening a remote ssh session to Lion and Mountain Lion clients and attempting to launch pico (I know, I know, "real men use vi") I get the following error:

"Error opening terminal: xterm-256color"

Here is the fix (must be run from Terminal on the machine itself):

• Open Terminal
• Type "pico ~/.profile" (if it doesn't exist go ahead and create it)
• Enter the lines:
• TERM="xterm"
• export TERM

• Exit and save

ssh to the computer again and when you launch pico it should now open

Recon fails on Macs running CS6: Adobe SpeedGrade issue

We have noticed a very annoying problem where Casper Recon fails repeatedly with the logs showing a BUS error.

There is a good discussion over on Jamf Nation about the issue.  The problem is caused by a symbolic link in the Adobe SpeedGrade application that links to the application itself.  Recon essentially gets caught in a loop and will eventually fail.

The fix is to either delete SpeedGrade if you don't need it or remove the symbolic link. You can do this manually or create a Casper package to automate the process.  Here is the location to the link:

/Applications/Adobe SpeedGrade CS6/Adobe SpeedGrade CS6.app/Contents/MacOS/Adobe SpeedGrade CS6.app

Remove the "Adobe SpeedGrade CS6.app" and then Recon should complete successfully.

Change Mac hostname from Terminal

Sometimes I have found that changing the Mac's hostname from System Preferences/Sharing doesn't do the job.  In these cases it is best to change the hostname from Terminal:

sudo scutil --set HostName [new hostname]

Example: sudo scutil --set HostName LDNMAC-1234




Show hidden user Library folder in 10.7 and 10.8

I keep having to look this up because I can never remember the Terminal command:

chflags nohidden /Users/[user folder name]/Library

example: chflags nohidden /Users/tom.smith/Library

High CPU usage with Lync and Outlook 2011

We have received numerous reports that having Lync and Outlook 2011 open at the same time is causing one, or both, of the processes to use 100% of the CPU.  This in turn causes Outlook to become unresponsive until you force quit either Outlook or Lync.  Having the applications open separately does not cause a problem- only when they are both open at the same time.

To troubleshoot the problem, open Lync, go to Preferences/General and put a tick in "Turn on logging for troubleshooting".  Restart Lync and then Open Outlook and Process Viewer.  Work normally until Outlook freezes and you see in Process Viewer that the CPU use for Lync and/or Outlook has spiked.

Close (or force quit) Outlook and Lync and open Console Viewer.

In Console Viewer, under Files/~/Library/Logs open the Microsfot-Lync-0.log.  Search the log for multiple (hundreds) of entries referencing the same e-mail address and having an "INFO" line of "FindOrCreateFakeContactModelForQuery"

Open Outlook and remove all references to the offending e-mail account.  This includes contacts and any auto-complete entries.

To clear the auto-complete entries, open a new mail and start typing the user's name; a box should open that displays the e-mail address; to the right will be an "X".  Click on the "X" to remove the entry.

Relaunch Outlook, open Lync and check that you no longer experience the high CPU problem.

When you are sure the problem has been resolved, make sure you turn off logging in Lync.

Search function on this blog is broken

I'm sorry to report that for the past several weeks the search function on this blog has been broken.  It returns "no results" to every enquiry. 

It seems to be a very common problem and there are lots of posts on Google's help site about it- unfortunately there is no fix as of yet. 

Since this blog is used as a knowledge base the search function is vital.  If Google can't resolve the problem soon I am going to switch to a hosting provider.

Very sorry for the problem!

Casper package installs fail: Cannont mount distribtuion point

There is an issue deploying packages via Self Service and policies to bound Mac clients (with the user logged in) when the distribution point is on a Windows server and the deployment method is set to "force distribution point to use AFP/SMB".  Under these conditions, package installs can fail with an error of "Cannot mount distribution point."

The root cause of the problem is down to the fact that the bound Mac is attempting to mount the distribution point with the user's AD credentials and not the "casperinstall" account that has permission to the share.

The easiest work-around is to first enable IIS on the Windows server then on the JSS go to /Settings/Servers/Distribution Point/HTTP and put a tick in "HTTP Downloads are enabled for this Distribution Point".

In your policies make sure to remove the tick from "Force Distribution Points to use AFP/SMB instead of HTTP".

The advantage of HTTP package distribution is that it allows interrupted downloads to restart.  The disadvantage is that it is slower than AFP/SMB.

Anyone using a bound Apple server as a Distribution Point should also make sure that web services are turned on before attempting to use HTTP package installs.

Mountain Lion Server: An SSL error has occurred and a secure connection to the server cannot be made

After a recent Server.app update I was unable to log into a Mountain Lion server. 

I deleted Server.app from the Applications folder and downloaded it again from the App Store.  When I launched Server.app after the download it asked for the administrator credentials and then displayed the error "An SSL error has occurred and a secure connection to the server cannot be made."

My solution was to open Keychain Access, click on "System" (under Keychains) and then "Keys" (under Categories) and delete all the keys referencing my server name.  This includes both public and private keys so OS X will prompt if you really, really, want to do it.

I also removed the certificates for the server under System/My Certificates as well as "com.apple.servermgrd".

I crossed my fingers and restarted the server.  I logged in as local admin, launched Server.app and was able to configure it normally.  After the server was up and running I looked in Keychain Access and all the certificates had been re-populated.

Apple's KB on the problem wins the prize for the least helpful tech note ever.  You can see for yourself here:  http://support.apple.com/kb/TS4493.  All they suggest is upgrading to Server 2.2.1.  Guess what I was running when I encountered the error?  2.2.1.  What upgrade locked me out of my server?  2.2.1.  Thanks guys!

Safari Oracle Java Blocking: RESOVED

Oracle has released Version 7 Update 13 build 1.7.0_13-b20 that addresses the security concerns outlined in this Apple KB: http://support.apple.com/kb/HT5647

The Oracle Java update can be downloaded here: http://java.com/en/download/mac_download.jsp?locale=en

Users who have been unable to access Juniper VPN and other web-based Java apps from Mac clients should download and install the patch, this should restore functionality.

Safari Blocking Oracle 7.11.21 Plug-in: Can't Connect to Juniper VPN

The war between Apple and Java continues.  Apple is blocking the latest Java saying that it is susceptible to malware. 

We have received several reports that Mountain Lion clients are unable to contact the Juniper VPN launch page.  The users are presented with an error that says "Blocked Plug-in":


They may also be prompted that Java is out of date and that they should download Java:

They are then redirected to the Oracle download page.  Even after they download the latest Java, they will still see the "Blocked Plug-in" error.  The cause of this error appears to be Apple's anti-malware protection.

The only work-around we have found is to do the following:

Go to /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/

Type "sudo pico XProtect.meta.plist"

Look for the line "MinimumPlugInBundleVersion"

Note that the version is set to 1.7.11.22 but the latest version of Oracle Java is 1.7.11.21.  This prevents the browser from loading the current Oracle Java because it says the minimum version is .22 but the latest is currently .21

It is possible to edit the "MinimumPlugInBundleVersion" and change the minimum value to 1.7.11.21:






After making the change, save the file, restart Safari and go to the VPN page- you should be able to log in.

Not only is this affecting Juniper VPN but several of our other web-based Java apps.