Software updates URL

You can probably check the logs in either Console or the Logs tab of OS X Server to see which IP address or URL the Mac connects to for updates... Just don't do anything else while it's contacting the update server, makes it easier to tell what's what in the Console/ Logs.

But no, I don't think anyone actually knows off the top of their head, needless to say, that's kind of odd that you want to do that, but I'm sure there's a good reason, and to each their own.

The service uses various URLs, but they're all at one of four servers listed here:

http://support.apple.com/kb/ht3923

Note that you must allow by name, not numeric IP address, since the actual services are provided by server farms which share the load, and you can't predict which computer will respond to each request.

In addition to the domains in HT3923 and if you've not already considered it, look at implementing Caching Server 2 and Software Update Server. If those features are available to you (Caching Server 2 availability can vary by network and geography), they work very nicely for reducing the network load related to updates.

I stand corrected!

I'm glad someone had the answers.

Caching Server is one of the services provided by OS X Server. If you want to cache software updates for your organisation (perhaps to reduce external network traffic), buy a copy of OS X Server and a Mac to run it on.

http://www.apple.com/uk/osx/server/features/#caching-server

ipad0135 wrote:

Does it allow us to schedule the clients downloads or limit the clients sessions as a way to control the internal network bandwidth as well ?

Caching Server 2 and Software Update Server provide a means to host the updates, with the former hosting various software updates and iOS updates, while the latter hosts all current OS X and OS X Server updates and related materials. The two services reportedly do sometimes duplicate some data.

Caching Server 2 is restricted to certain network configurations and to certain geographies; it's apparently not available world-wide, and only works with a properly structured NAT'd network. This based on comments around the forums. One of the few somewhat-detailed discussions I've encountered is here.

With Mavericks, the overnight updates typically happen between 2 and 5AM local time. With earlier versions, there are some controls on the scheduling and the frequency listed here. (Off-hand, I don't know of a way to schedule the Mavericks software update checks, and don't see any obvious settings in the defaults. It wouldn't surprise me to find push updates being used underneath the update notifications, either now or real soon now. That'd be a way to push out updates off-cycle, but to also avoid overloading the Apple servers.) It is possible to cascade the Software Update Servers, so you could tailor the updates to specific local servers using this and DNS entries; that'd be a way to move the updates closer to your clients.

After having set up local services, I haven't seen all that much load with multiple Apple devices around, though you will get the first updates going to the Apple servers for updates that aren't cached, and Software Update Server will chew up a whole lot of bandwidth when you first start it.

internalcheck.apple.com

1-courier.push.apple.com

init-p01st.push.apple.com

1-courier.sandbox.push.apple.com

radarsubmissions.apple.com

Those domains are Apple hosts related to push notifications, crashes, and Apple bug reports. The internalcheck.apple.com domain is reportedly a check for some Apple-specific processing for systems that are connected directly to the Apple internal network. Reportedly for crash handling. For some additional details, scroll down to the bottom here and start reading.

Interestingly, it appear Open DNS and some other DNS providers can cause problems for DNS services that expect to get non-existent domains responses; by responding to non-existent DNS requests. Running with local DNS services is one of the ways to avoid that. OS X Server does support local DNS, and effectively requires it. Windows Server Active Directory configurations also usually have LAN-local DNS services, and that will work here as well.

The first four are used as part of the Software Update service. Some are used to analyse your computer or device's installed software and figure out what updates you need. Others are the servers the new pieces of software are downloaded from. The system isn't limited to those four addresses, and each of those four addresses can lead to many different servers, all sharing the load. If you don't want your devices to access these servers, turn off automatic updating.

The last one is used as part of automatic fault reporting built into OS X and iOS. When apps crash they generate crash logs which have details in them about what the app was doing when it crashed and why it couldn't complete the operation. These are automatically sent to Apple for analysis so that the programmers can improve the program, either by removing a bug or by turning the crash into a useful error message that tells the user what went wrong and lets them try again. If you don't want your devices to access these servers, turn off automatic crash reporting.

None of the information sent to any of the above servers can be used to uniquely identify a specific computer or a specific user. Although IP addresses have to be included, it doesn't include serial numbers or MAC addresses or anything like that.

If you want or need to restrict updates, then by all means do experiment with bandwidth-limiting settings, assuming your firewall supports those features.

As mentioned up-thread, I have the local OS X clients access a local cache of updates via SUS, might cascade SUS in a larger environment, do use caching server 2, and I definitely do chew up some network bandwidth overnight as SUS does its thing. This as I prefer to keep the local devices more current on patches.

Push out the client settings that reference your local SUS via ARD or ssh or Open Directory, or block access at the firewall and encourage (force) the users to enter the SUS reference themselves. (There are tools around to make that task easier, and a script is simple to code; it's as short as a couple of lines of bash.)

But do go try what you need or want here, of course.