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.

10.7 clients unable to connect to legacy NAS and AFP devices

In Lion Apple disabled older, less secure protocols like DHCAST128.  This has caused problems with older NAS devices running AFP and some Novell servers.

Most manufactures have released updates to resolve this problem but there is also a way to re-enable the protocol from the command line.

Here are the instructions from Apple's KB:

Lion maintains a list of authentication methods that are not allowed. These are the older, less secure authentication methods. You may need to enable one or more of these methods to support legacy devices or protocols.

Open Terminal.
Execute the following commands:

sudo chmod o+w /Library/Preferences
sudo defaults write /Library/Preferences/com.apple.AppleShareClient afp_host_prefs_version -int 1

Make an AFP connection to another system so that the AFP Client preference file will be filled in with the default set of values. Note: You must connect as a registered user, not as a guest.
Execute the following command to see a list of the disabled User Authentication Methods (UAMs)

defaults read /Library/Preferences/com.apple.AppleShareClient afp_disabled_uams

By default the disabled UAMs are "Cleartxt Passwrd", "MS2.0", "2-Way Randnum exchange", and "DHCAST128". Note: if you don't see a list, restart your computer and repeat step 3.

To enable one of these UAMs, remove it from the list of disabled UAMs. For example, this command enables DHCAST128 by removing it from the list of disabled authentication methods:

sudo defaults write /Library/Preferences/com.apple.AppleShareClient afp_disabled_uams -array "Cleartxt Passwrd" "MS2.0" "2-Way Randnum exchange"
After the desired changes have been made, restore the permissions on the Preferences folder with this command:

sudo chmod o-w /Library/Preferences
Additional Information
If you want to undo the changes described above, you can either delete the /Library/Preferences/com.apple.AppleShareClient file or use the following command to re-disable the default set of older UAMs:

sudo defaults write /Library/Preferences/com.apple.AppleShareClient afp_disabled_uams -array "Cleartxt Passwrd" "MS2.0" "2-Way Randnum exchange" "DHCAST128"

The full article can be found here:  http://support.apple.com/kb/HT4700

OS X Server: users can not connect to SMB or AFP shares

We have been troubleshooting several reports from offices with bound OS X servers where Mac and PC clients are unable to connect to shares using AFP or SMB.  Additionally these offices have reported that Macs will randomly drop their AFP connections to the OS X server.

When the connection problem occurs often times the server shares will display generic ACL GUIDs: a series of numbers and letters instead of the group name.   In cases such as these restarting Directory Services generally resolves the problem- at least temporarily:

sudo /usr/bin/killall DirectoryService

Other times the GUIDs display normally but the connection problems still persist.  In these cases two things are suggested:

1. Nest AD users into local groups and then use the local groups to populate the ACLs
2. Flush the group membership cache by running this command:  

sudo dsmemberutil flushcache

Generally these problems occur most often on Leopard servers- Snow Leopard servers have improved group membership caching.

Bound Leopard Server not allowing SMB or AFP connections

Problem:  A 10.5.8 server was not allowing SMB or AFP connections.  The server was bound to AD but "id" commands were failing- sometimes.

Looking at the logs I saw that they were filled with launchd errors:

 com.apple.launchd[1] (org.openldap.slapd): Throttling respawn: Will start in 10

These were causing very, very poor performance and pretty much preventing Directory Service from operating; that in turn prevented any logins.

The first thing I attempted was to unbind the server but as it couldn't connect to the domain I did a Force Unbind, deleted the edu.mit.kerberos file and the Directory Services folder and restarted.  I then re-bound the server and immediately unbound: this ensured that the server's AD account would be removed.

From the unbound server I took these actions:

• Changed the Windows role to Standalone server
• Stopped the SMB services
• Opened Terminal and ran "sudo –s /usr/libexec/slapd –Tt"

This returned:

could not stat config file "/etc/openldap/slapd.conf": No such file or directory (2)
slaptest: bad configuration file!

I then viewed the contents of the directory:  cd /etc/openldap/ls

There was no slapd.conf file present but there was a slapd.conf.default file so I renamed  it: "cp slapd.conf.default slapd.conf"

I then re-ran the slapd command:  "/usr/libexec/slapd –Tt" and it returned:

bdb_db_open: Warning - No DB_CONFIG file found in directory /private/var/db/openldap/openldap-data: (2)
Expect poor performance for suffix dc=my-domain,dc=com.
config file testing succeeded

Since LDAPv3 is turned off in Directory Services this shouldn't be a problem

• Reboot 
• Launch Server Manager
• Change the Windows role to Domain Member
• Start the SMB service

AFP and SMB log-ins now worked.

These steps and more info can be found here:  http://discussions.apple.com/message.jspa?messageID=10613310