Ports required for Apple Push Notification Service

We encountered a problem where Macs managed by Casper were unable to communicate with the JSS for Mobile Device Management (MDM).  The solution was to allow the following ports access to Apple's 17.0.0.0/8 range (complete owned by Apple):

• TCP port 5223 (used by devices to communicate to the APNs servers) 
• TCP port 2195 (used to send notifications to the APNs)
• TCP port 2196 (used by the APNs feedback service)
• TCP Port 443 (used as a fallback on Wi-fi only, when devices are unable to communicate to APNs on port 5223)

Here is a link to Apple's support page on the topic.

Device Signature Error when attempting to install packages through Casper

When attempting to install printers (and other packages) some Macs (10.9.x) would report an error "Device Signature Error-A valid device signature is required to perform the action."  The helpful folks at JAMF Nation provided the following fix:

In ARD push out the following commands:

launchctl stop com.apple.apsd
rm /Library/Keychains/apsd.keychain
launchctl start com.apple.apsd

After the commands have been applied, Recon the machine again.  You should now be able to install packages.

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

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

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.

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.

Recon failed during the submit process. Could not recognize the JSS response

After upgrading to JSS 8.6 a site noticed that none of the Jamf binaries on the clients were being updated.

When we attempted to Recon the Macs again the process would fail with a message "Error enrolling computer.  Could not recognize the JSS response."

 
We would receive the same error no matter what method we used to get the computer into inventory: local Recon, Quick-Add Package, command line enrolment, etc.

From the screen-shot it would seem that the problem had to do with the client or server's certificate.  However, after renewing the JSS' certificate, double-checking that it was valid and that existing clients could communicate with the JSS we were at a loss to explain why Recon was failing.

The answer was both simple and completely crazy.  It seems that if there is a non-standard character in the "Display message to User:" field in Restricted Software it causes Recon to fail with the above mentioned error.

The text of the original message:  Este software no está permitido en la red corporativo

After changing "está"  to "esta" we were able to Recon computers normally.

How bizarre is that?

A big thanks to Derek at Jamf support for figuring out the problem.  We would have spent years hunting for a fix on our own.

Office 2011 14.2 update installation problems

We have received numerous reports of problems when attempting to install the Office 2011 SP2 (14.2) update remotely using Casper.  However, the update seems to deploy using ARD but you should be aware of a few peculiarities. 

Microsoft changed the format of their update package from an .mpkg to a .pkg.  While this might not sound like much of a change there are significant differences in how the two types work. .pkg files are flat packages that don't do anything more than bundle up files into an installation wrapper.  .mpkg files are much more customizable and can link to other packages.

It seems that even though the 14.2 updater is a .pkg it is not actually a flat file.  I don't know what magic Microsoft has tried to work but there seems to be many problems relating to this new composition.

While the updater runs fine from a local machine, attempting to deploy it though Casper does not work.  Even though Casper (and the Mac) report that the installation was successful, the Office version remains the same and the update does not get installed.

Installing the .pkg through ARD works, however when you launch Outlook you get the following error:

Deleting the daemon from the user's startup items and restarting fixes this problem.

If you launch Word before restarting you will probably see this error:

After a restart this error should go away.

Once you restart, launch Outlook and you will get the following message:

Before clicking "Upgrade" it is a good idea to back-up the user's Main Identity.

Once you click "Upgrade" you are committed- you must let it finish or you will get data corruption.  A 2GB profile on an i5 iMac took about 7 minutes to upgrade.

The upshot of all this is that SP2 is not a "fire and forget" update.  A good deal of intervention is required to ensure that the process goes smoothly.

Deploying McAfee ePO agent using Casper

Jamf has an excellent KB article on how to deploy the McAfee ePO agent.

https://jamfnation.jamfsoftware.com/article.html?id=182

However, if you have already installed the unmanaged client you will need to remove the agent before reinstalling.

1)  Uninstall the existing (stand-alone) agent using Casper Remote by running the following command:

/Library/McAfee/cma/uninstall.sh

2)  Install the agent using Casper Remote and the following command:

 /Library/Application\ Support/McAfee/install.sh -i

If you do not first uninstall the agent you will receive the following error:

"An higher or same version of the agent is already installed installer: Error - The installed version of the agent is already greater than or equal to this version. Installation cannot continue"

Casper Admin Can Not Mount a Distribution Point

Problem:  When attempting to Launch Casper Admin the distribution point will fail to mount and an error is displayed saying "The master Distribution Point (server name) could not be mounted".  It then gives you some tips to resolve the issue.

Solutions:  Follow the tips and check that the correct permissions and passwords are set on the Distribution Point's file share.

One good way to check if the permissions are set correctly is to connect to the server share from another Mac using the "casperadmin" and "casperinstall" accounts.  If you can mount the Distribution Point then the permissions should be OK.

With the Distribution Point mounted launch Casper Admin.  If it opens without an error then your problems are very likely not related to permissions but rather a corrupt or missing symbolic link to the CasperShare folder.

In /Library/WebServer/Documents there is a folder called CasperShare that is a symbolic link to the "real" CasperShare.   If you suspect that the link is corrupt the easiest thing to do is simply delete the symbolic link and create a new one. 

Note: in Casper versions prior to 8.31 you could use the JSS Setup Utility to recreate the symbolic link.  Unfortunately since version 8.31 the JSS Setup Utility has been removed and you have to do the process manually.

To recreate a symbolic link to the CasperShare do the following:

• Open Terminal
• Type "cd/"
•  Type "sudo ln -s /Shared\ Items/CasperShare/ CasperShare" this will create a symbolic link to the CasperShare and put it in the root of the drive
•  Move the CasperShare symbolic link to /Library/WebServer/Documents and replace any existing CasperShare link
• If you do an "Apple-I" to get information on the Symbolic Link you will see that next to "Original" it has the path to the CasperShare

 

After you have recreated the symbolic link launch Casper Admin to test connection to the share.

Remember, you can not launch Casper Admin from the server that hosts the primary Distribution Point.

For a good overview of symbolic links see this article.

Where are JSS database backups located?

sudo /private/var/backups/jss/

How to build a Casper netboot set using Apple's System Image Utility

Information directly from the Jamf site:

https://jamfnation.jamfsoftware.com/article.html?id=64

The instructions tell you how to create a netboot set that will automatically launch the Casper Imaging Utility.  However if you want to use your netboot set in different environments then you should not auto-launch Casper Imaging.  Rather, just put the icon in the Dock and enter the JSS info when prompted.  It's one more step but worth it if you need to share your netboot set with other sites.

Tomcat problems on a JSS

It is important that Apple's Tomcat does not conflict with Jamf's on your JSS.  If both instances of Tomcat are trying to run at the same time you can experience an inability to access the JSS along with over all poor server performance.

To disable Apple's Tomcat follow these steps:

On your JSS, launch Server Admin
Click on "Web"
Click on the "Settings" icon
Click on the "General" tab
Remove the tick from "Enable Tomcat"