Apple Software Updates not working from home.

[DanSam]

We have been trying to encourage our students to run their apple updates in Self Service from home, but they have not been successful in doing so. Whenever the student (or faculty member) attempt to get updates from Self Service, it looks like it runs for about 30 seconds and then stops and nothing happens. Looking at the logs I get the following for every attempt:

/usr/sbin/jamf is version 8.64
Executing Policy Install Apple Updates (Offsite)...
[STEP 1 of 3]
Setting Software Update preferences to apple.com for all accounts...
Setting Software Update preferences to apple.com for root...
[STEP 2 of 3]
Installing all available Software Updates...
Result of Software Update: Error: The request timed out.
Software Update Tool
Copyright 2002-2010 Apple

[STEP 3 of 3]
Running Recon...

As you can tell by the error, we have it switching to the apple.com SUS for while they are at home, it looks like everything should be running correctly, but it times out and fails. Does anyone have any ideas that could help me out here? We are approaching the end of he year and I am really not looking forward to running updates manually on 1600+ computers.

Thanks,
Dan

[tkimpton]

1. Create the file and folder path folder called /Library/Management/Triggers/applesoftwareupdates

2.create a Launch Daemon with Lingon. Watchpath should be /Library/Management/Triggers/applesoftwareupdates

http://sourceforge.net/projects/lingon/files/Lingon/

so it looks like this

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.applesoftwareupdate.Launchd</string>
    <key>ProgramArguments</key>
    <array>
        <string>/System/Library/CoreServices/Software Update.app/Contents/MacOS/Software Update</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>/Library/Management/Triggers/applesoftwareupdate</string>
    </array>
</dict>
</plist>

1. Create an Applescript and Export it as a run only app

try
    display dialog "Do you want to run Apple Software Update?" buttons {"No", "Yes"} default button "Yes" with title "Warning!"

    if button returned of result is "Yes" then
        do shell script "touch /Library/Management/Triggers/applesoftwareupdates"
    end if
end try

1. Package Every thing up in Composer and deploy it out to your test box first.

[mm2270]

@tim, while that's a nice script/launchd combo, it may not solve the OP's original issue, which is that it seems his Macs are timing out when attempting to connect to Apple's SUS URL.

@DanSam- are you using the 'jamf removeSWUSettings' command to point your clients back to Apple, or are you attempting to point their Software Update clients to a specific address entered in your JSS as part of your workflow? If you're doing the latter, you would probably have better luck doing the former. Let the jamf binary remove the SWU settings and the Software Update.app will automatically point back to Apple's default address.

[DanSam]

@mm2270, thanks for the response.

We have a local SUS that the students and faculty use to download updates, but when they are at home we prefer they use apple for their updates.

As such, I have the following set in the policy:

Under "Override default policy settings"
Software Update Server: apple.com (the default, not something I have entered)

Under "Packages"
Set Server and Install Software Updates are checked.

I am honestly not sure what "jamf removeSWUSettings" refers to. I am kind of new to this.

[mm2270]

jamf removeSWUSettings is a command line function that removes the section in the com.apple.SoftwareUpdate.plist file labeled as "CatalogURL" I think what ypu've set in the policy is doing the exact same thing, it just doesn't show the command in the policy log. The output in Terminal from running 'sudo jamf removeSWUSettings' looks like:

Setting Software Update preferences to apple.com for all accounts...
Setting Software Update preferences to apple.com for root...

So, looks the same to me.

Sounds like it should be working. Only thing I can think of is, maybe the change isn't being registered fast enough when Software Update attempts to check for updates. If you can split those process up somehow it may help. Just taking a guess.

[tkimpton]

Take the applescript and add a line at the top with a defaults write to point the client to apples servers

When the machine comes back in then jamf framework will take over.

Think you guys are scratching your heads too much on this one!

[nkalister]

I must be missing something here . . . .Why bother to use an internal SUS in this scenario in the first place? If you're OK with the clients going out to apple at home, why not at the school as well?

[gregneagle]

One word: bandwidth.

[DanSam]

What Greg said...

We want the students to have the ability to quickly download updates while they are at school. Apple does not offer quick updates, and it would absolutely kill our bandwidth (1600 students attempting to update on a external server = bad)

[tkimpton]

A change to my launch daemon.

Instead of the program argument pointing towards the software update, you will want to point it to a script.

The scripts should check the machines ip address. If its off the network say starting with 192 then the command sudo jamf removeSWUSettings runs.

Otherwise if its on the network then a command runs pointing it to your internal SUS.

All you need to do then is tell your users to use the app you created and let the script do its magic :)

[DanSam]

Ok. I split the switch to the apple SUS and the updates onto 2 separate policies with a pause and trigger to allow for some time before the updates start. I am still getting the same error message. I'm not sure if policy is not switching the update server like it should or what. It is kind of starting to get frustrating.

[matthew-c]

Are your machines pointed at a proxy when on your network or do you set any static DNS servers?
If so are your students switching to a network location with just DHCP settings when at home?

Assuming that after your policy both

/usr/bin/defaults read /var/root/Library/Preferences/com.apple.SoftwareUpdate CatalogURL

and

/usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

give output something like

2013-04-22 18:21:55.362 defaults[11988:303] 
The domain/default pair of (/Library/Preferences/com.apple.SoftwareUpdate, CatalogURL) does not exist

then you can probably assume DNS or proxy settings are at fault here. If you can give some info on your network setup maybe a simple shell script can solve this.

cheers

Matt

[tkimpton]

Possibly try this script with a launch daemon running say every 15 minutes and then use the apple scripted app i mention above for a user to double click on at home to run without admin rights.

Need fully testing though

#!/bin/bash


######################################################################### VARIABLES ##########################################################################################

# Get the currently logged in user
user=`ls -l /dev/console | cut -d " " -f4`

### Carry out an OS version check
OS=`/usr/bin/defaults read /System/Library/CoreServices/SystemVersion ProductVersion | awk '{print substr($1,1,4)}'`

### Internal SUS
isus="XXX"

### SUS port
port="XXXX"

### see if the plist already has a CatalogURL
caturlcheck="defaults read /Library/Preferences/com.apple.SoftwareUpdate | grep CatalogURL | awk '{print $1}'"

############################################################## DO NOT MODIFY BELOW THIS LINE ################################################################################

### See if the plist arlready has a CatalogURL set
if [[ "caturlcheck" == "CatalogURL" ]]; then

### Delete the Catalog url
defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL
fi

sleep 10

### Check to see it the internal sus is reachable
if
ping -t3 ${isus} | grep "packets transmitted"; then

#### OS 10.8 Check. If the OS is 10.8 then set the relevant custom CatalogURL
if [[ "$OS" == "10.8" ]]; then
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://${isus}:${port}/index-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog


### OS 10.6 Check. If the OS is 10.6 then set the relevant CatalogURL
elif [[ "$OS" == "10.6" ]]; then
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://${isus}:${port}/index-lion-snowleopard-leopard.merged-1.sucatalog
fi
fi

### Sleep 10
sleep 10

### See if the internal sus is unreachable
if
ping -t3 $isus | grep "cannot resolve"
then

### Delete the Catalog url
defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL
fi

### Sleep 10
sleep 10

### open softwareupdate
softwareupdate -i -a

[tkimpton]

I add the script above as part of my sleepwatcher wake script and works well for laptops :)

https://jamfnation.jamfsoftware.com/discussion.html?id=4813

[DanSam · Accepted solution]

So.. the problem was that the MCX Preferences for Software Updates were not allowing the Updates policy to change servers. What I ended up doing was removing the MCX Preference (Workgroup Manager) and let the policy dictate which server it would pull from. Because the students rarely (if ever) restart or log out of there computers, I made a small script to refresh the MCX preferences after I removed the SUS preference from Workgroup manage:

#!/bin/sh

currentuser=`/usr/bin/defaults read /Library/Preferences/com.apple.loginwindow lastUserName`

/usr/bin/mcxrefresh -n "$currentuser" 

exit 0;

I've tested this on a few at home and school and they seem to work fine. I'm not sure if my approach was a little to simplistic, but it worked for me and now everything appears to be running as it should.

[tkimpton]

What's the script you use in your policy for Self Service?

[tkimpton]

hello....