Spotlight not working in Mountain Lion

We have received numerous report that in Mountain Lion Spotlight is not searching local HDDs.  Since Outlook also uses Spotlight, no mailbox searching was possible either.

The fix is two-fold.  The first thing to do is delete the index metadata:

sudo /rm ./metadata_never_index

Secondly, re-enable spotlight indexing:

sudo mdutil -a -i on

Technically simply turning Spotlight indexing ON using the mdutil command should resolve the problem.  However we have found that you must first delete the index file first.

Update:  We ran into a computer where the above steps did not resolve the indexing problem.  On that machine the .metadata_never_index file was in the root volume (don't know why).  Removing that file and then running "sudo mdutil -i on /" resolved the problem.
 
1.  Double check that the .metadata_never_index file is not located at the root of the volume you are attempting to index
2.  Disable spotlight indexing for the volume:  sudo mdutil -i off /
3.  Remove the index from the volume:  sudo mdutil -E /
4.  Remove the .Spotlight directory from the root if it exists
5.  If there is a .Spotlight-V100 directory in the root, remove it: sudo rm -rf .Spotlight-V100
6.  Enable indexing for the volume:  sudo mdutil -i on /

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.

10.7 and 10.8 Clients do not generate Kerberos tickets at login: FIX

(For information about forcing 10.6.x clients to get a Kerberos ticket at login see this Apple KB)

We have encountered a problem where Lion and Mountain Lion clients are not generating Kerberos tickets at login.  This causes problems with single-sign-on (SSO) to network shares as well as with Kerberos enabled applications like SAP.

Apparently Apple's latest version of Kerberos will not automatically request a ticket when a Kerberos enabled application launches.  Instead you must either go to Terminal and type "kinit" and enter your password or force a ticket to be generated at login using the following instructions.

Note: in order to correctly authenticate using Kerberos enabled applications like SAP your user name in AD and in the application itself must match.  This means that both your SAMAccount name and UPN in must be identical- including the case.  Many non-Microsoft instances of Kerberos are case-sensitive.

To generate a Kerberos ticket at login (10.7 and 10.8 clients):

•  Open Terminal
• Type "sudo -s" and authenticate as super user
• Navigate to /etc/pam.d
• Type "cp authorization authorization.bak" to make a backup of the authorization file
• Type "pico authorization" to edit the file (you could also use vi or your favourite editor)

Find the line:

auth       optional       pam_krb5.so use_first_pass use_kcminit

Add the key "default_principal" to the end of the line. For example:

auth       optional       pam_krb5.so use_first_pass use_kcminit default_principal

• Save the file
• Restart and log back into the computer
• Check that a Kerberos ticket has been generated by opening Terminal and typing "klist"

Hosting Mountain Lion Software Updates on 10.6 or 10.7 Servers

This information came directly from Apple's KB:

1. Update your server to Mac OS X Server v10.6.8 (or 10.7)
2. Stop the Software Update service if it is running.
3. Quit Server Admin if it is active.
4. Update /etc/swupd/swupd.plist to begin hosting OS X Lion software updates. (See details below.)
5. Update /etc/swupd/swupd.conf to allow OS X Lion computers to receive updates. (See details below.)
6. Open Server Admin and start the Software Update service.
7. Use the instructions in Mac OS X Server v10.6: Using the Software Update service with multiple Mac OS X client versions to point your OS X Lion clients to this server.

In step 4, you will need root access to update the file /etc/swupd/swupd.plist. To be safe, make a backup copy of the file before editing it. Add the string in bold below to the otherCatalogs array:

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

For Mountain Lion change the string to:

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

In step 5, you will need root access to update the file /etc/swupd/swupd.conf. To be safe, make a backup copy of the file before editing it. Locate the following line near the end of the file:

    RewriteCond %{HTTP_USER_AGENT} Darwin/11

Edit the following line to read:

    RewriteRule ^/index\.sucatalog$ /index-lion-snowleopard-leopard.merged-1.sucatalog

For Mountain Lion change the string to:

RewriteRule ^/index\.sucatalog$ /index-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog