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.

High CPU usage caused by: krb5kdc: didn't find any realms when starting

We have seen several instances where a computer is unable to launch applications and suffers other performance problems when edu.mit.kerberos.krb5kdc repeatedly exits and respawns.  Look in the Console log for these errors:

To fix this, open Terminal and type:

sudo /usr/libexec/configurLocalKDC

It has also been suggested that you delete all files in the following location:

sudo /var/db/krb5kdc/

Although some people may not have any files in that location.

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

On a Mac 10.6.8 server we were experiencing poor performance and erratic behavior from Server Administrator.  Looking at the Console Logs we found that it was filled with the following error:

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

Apparently this is a fairly common error in 10.6.x and can affect a wide variety of applications.  The fix is pretty straightforward.  Open Terminal and type the following:

sudo update_dyld_shared_cache -force

Windows 2008 R2: Members of the local "Administrator" group do not have admin rights to shares

We have received many reports of a problem with Windows 2008 R2 servers where shares containing the local "Administrator" group were not accessible by members of that group.

For example: we have a GPO that makes our "Domain Admin" group a member of the local Administrator group of all our servers.  However, when a Domain Admin would log onto a server he would not have access to server shares.

We resolved the problem by  disabling User Account Control (UAC) on the server.  This Microsoft KB article describes how to turn UAC off in Server 2008 R2.

For a full overview of UAC and how to turn it off/on on other servers see this KB.

Note: these changes require a restart.

Single-Sign-On (SSO) not working for Snow Leopard clients connecting to a Windows server running ExtremeZIP

We received a report from an office that three of their Windows 2003 servers running ExtremeZIP were not allowing SSO connections from AD bound Snow Leopard Macs.

After a good deep-dive into the problem, including packet traces and help from Group Logic, we resolved the problem.  Here are the steps we took:

Make sure the Mac clients are using the FQDN to connect to the ExtremeZIP AFP volume on the server.  Short names should not be used (in Lion you must use the FQDN or you get an error).

Check that the time on the server, clients and DC match.  One of the servers' clock was out by six minutes (max Kerberos time skew is five minutes).  When the time was set correctly Lion clients were able to log in.

Check that the Server Principle Name (SPN) of the servers is correct; if they are not then authentication can fail.  Read more about SPNs here.

To check the SPN on a Windows 2003 server you must first download and install Windows Server Support Tools.  You can get them here.

After you have installed the tools go to Programs/Windows Server Support Tools and launch the app- it will open a command line.

Both the long and the short SPN for the AFP protocol need to exists for your servers:
afpserver/servername.company.com
afpserver/servername

To display the SPNs from the Support Tools command line type "setspn servername"

You should see both the FQDN and the short name.  If one is missing do the following:

- To add the long name: setspn -a afpserver/servername.company.com servername
- To add the short name: setspn -a afpserver/servername servername

We also found that although the Snow Leopard clients were authenticating users correctly, they were not generating a Kerberos ticket at login (you can verify this by going to the Ticket Viewer.app located in System/Library/Core Services).  After manually generating a Kerberos ticket, SSO worked.

To force a Snow Leopard client to generate a Kerberos ticket at login follow the instructions in this Apple KB article.

After carrying out each of these steps, the Snow Leopard clients were able to get SSO to the ExtremeZIP enabled servers.

Although it wasn't necessary in this case, make sure you update ExtremeZIP to the latest version

How to check if an Apple server is Kerberized against AD: verify Service Principals

If Mac clients are having trouble accessing a bound OS X server, check that the server is Kerberized against AD.  First, run the following command:

sudo klist -kt

You should see a number of service principals with the Kerberos realm of your.domain.com

Second, you need to ensure that the correct service principal is in use by the AFP service.  You can use the following command to do this:

sudo serveradmin settings afp:kerberosPrincipal

This should show something like "afpserver/@YOUR.DOMAIN.COM".   If it shows a value in the LKDC realm it is incorrect and will need to be fixed before you can connect using Kerberos.

Here's a command you can use to fix it:

sudo serveradmin settings afp:kerberosPrincipal = "afpserver/@YOUR.DOMAIN.COM"

Using Snow Leopard server for Lion software updates

Here is a step-by-step guide for setting up a Snow Leopard SUS server so that it will distribute Lion updates.

I do not know who originally wrote this article.  If anyone can find the author please let me know and I will credit him/her.


First things first. Fire up Server Admin and stop the Software Update service. Next fire up a Terminal window and head to /etc/swupd.

cd /etc/swupd

Now let's make backups of the .plist and .conf files for swupd.

cp swupd.plist swupd.plist.bak; cp swupd.conf swupd.conf.bak

Great. Now we are going to add a catalog to the catalog array in the swupd.plist. When we are done it will look like this:

otherCatalogs
   
    
       index-leopard.merged-1.sucatalog
       
       index-leopard-snowleopard.merged-1.sucatalog
       
       index-lion-snowleopard-leopard.merged-1.sucatalog
   
    

You can do this with a text editor, but PlistBuddy makes it easier.


sudo /usr/libexec/PlistBuddy -c 'add :otherCatalogs:2 string index-lion-snowleopard-leopard.merged-1.sucatalog' /etc/swupd/swupd.plist

Will do it in one shot. Adding this catalog is what will tell our SUS Server to go and get the Lion updates.

The next bit we need to do is to tell the server that it can provide this catalog to Lion clients. Open up swupd.conf with the editor of your choice.

vi swupd.conf

Go to the bottom of the file, or just search for Rewrite. Look for the Darwin/11 agent string and change the rewrite rule to look like this.

RewriteCond %{HTTP_USER_AGENT} Darwin/11
RewriteRule ^/index.sucatalog$ /index-lion-snowleopard-leopard.merged-1.sucatalog

Basically we are adding the word "lion" into the sucatalog name.

Now close out of the terminal and start up the Software Update Service with Server Admin again. If you watch the logs, or the updates tab, you will see the Lion updates and on-demand software appear and begin downloading. After a while they will be local and you can start updating those Lion clients!