Software Update Server and client-side update tools form the core of the patching model. 

Apple is slowly introducing client and server software elements that wrangle together all the disparate Apple hardware and software installed across the network by giving administrators control over what applications and patches are presented to users for installation.

Mac OS X Server already provides administrators centralized control over what software updates are presented to Mac clients, and it seems a sure bet that the same software platform will logically extend to the Apple iPhone. Add some support for Apple applications on Microsoft Windows PCs, and it would not be beyond the realm of possibility to find companies of all sizes suddenly adding a few Apple servers to their data centers.

Back in 2005, Apple added the SUS (Software Update Server) to Mac OS X Server 10.4, which allowed companies to host a local patch and application repository (similar to Windows Server Update Services). Mac clients could then be configured to check with the local repository for available installation packages. This allowed the company to use less bandwidth (since the files needed to be downloaded from the Internet only once) and enabled administrators to centrally control when updates would happen while enforcing a level of software standardization across their client computer base—as long as those clients were Macs.

The next version of SUS (that came with Mac OS X Server 10.5) took it a step further, offering updates for Apple's Windows applications—such as iTunes or QuickTime—but only for Windows XP or Windows Vista installed on Apple hardware via Boot Camp.

Assuming the Windows via Boot Camp updates work as advertised (which seems to be a big "if," as I could find no documentation for how to reconfigure the Boot Camp clients to check with a local SUS and very little discussion of the feature online), there seems little reason why Apple could not extend that support to Windows installations on non-Apple hardware, save for Apple obstinacy.

Many Windows PCs already have Apple client update software installed, since the application has been installed automatically with iTunes for the last several months. Users became all too aware of this update applet recently, when Apple started offering the Safari 3.1 browser as an opt-out "upgrade"—even if the browser was not yet installed on the PC.

But this version of the client update software does not appear to be configurable to point to a local repository. I've combed through the Windows registry and file system, and I have not been able to locate where the address for the update server is defined—suggesting Apple has hard-coded it into the application somewhere. Whether this will be remedied in future revisions is simply speculation at this point.

Also in the realm of speculation is the role an SUS could play in the corporate use of the iPhone. The next major revision to the iPhone software will introduce a number of enterprise-friendly features to the mobile platform—including Microsoft Exchange ActiveSync, Cisco VPN, remote wipe, digital certificate support, application installation and policy-based configuration.

Apple has even started a $299 Enterprise iPhone Developer Program—enabling developers to create what the company calls "proprietary, in-house applications for iPhone and iPod Touch." But little has been said to this point about how the configuration policies and these homegrown applications will be deployed to iPhones in an enterprise setting. SUS would be a logical platform for that kind of deployment.

However, SUS has some serious limitations for this kind of deployment. For instance, you cannot have different software distribution policies on the same SUS server. If you want different versions of applications available to different clients, then you need to have another SUS iteration available with the different policy.

This may be adequate for applications on a computer—Apple representatives would argue that the majority of IT departments want to keep software versions consistent—but this would definitely not be the case for a mobile device. Different departments would require specialized applications—so a one-size-fits-all application package would be a poor fit indeed.