Windows Updates can be run using a standard batch script. Do so using the wusa.exe is the command that runs updates that you specify. These updates are run using the wusa command, nested inside the Windows directory (%WINDIR%\SysNative to be exact). To run, specify the path to the package you’d like to install. In this case, I’ve mapped a drive to my updates, and placed each in a directory named after the update ID. To run, just run with the path to the .msu file:
To then uninstall the package (if you dare), use the /uninstall option. In this command, you don’t need to provide the path, only the kb number, along with the /kb option:
wusa.exe /uninstall /kb:2862152 /quiet /norestart
The package then completes. If needed, you will have to reboot the system. You can also indicate /warnrestart which prompts to restart or /forcerestart that automatically restarts the system without any warnings.
Packages can also be installed before a computer boots in 7 and 8 using the DISM.exe command with the /Add-Package option along with the Windows Automated Installation Kit.
krypted November 29th, 2013
These days, new services get introduced in OS X Server during point releases. OS X now has a Software Caching server built to make updates faster. This doesn’t replace Apple’s Software Update Server mind you, it supplements. And, it’s very cool technology. “What makes it so cool” you might ask, given that Software Update Server has been around for awhile. Namely, the way that clients perform software update service location and distribution with absolutely no need (or ability) for centralized administration.
Let’s say that you have 200 users with Mac Minis and an update is released. That’s 200 of the same update those devices are going to download over your Internet connection, at up to 2 to 3 gigs per download. If you’re lucky enough to have eaten at the Varsity in Atlanta, just imagine trying to drink one of those dreamy orange goodnesses through a coffee stirrer. Probably gonna’ be a little frustrating. Suck and suck and suck and it’ll probably melt enough to make it through that straw before you can pull it through. For that matter, according to how fast your Internet pipe is, there’s a chance something smaller, like an update to Expensify will blow out that same network, leaving no room for important things, like updates to Angry Birds!
Now, let’s say you have an OS X Server running the new Caching service. In this case, the first device pulls the update down and each subsequent device uses the WAN address to determine where the nearest caching service is. If there’s one on the same subnet, provided the subnet isn’t a Class B or higher, then the client will attempt to establish a connection to the caching service. If it can and the update being requested is on that server then the client will pull the update from the server once the signature of the update is verified with Apple (after all, we wouldn’t want some funky cert getting in the way of our sucking). If the download is stopped it will resume after following the same process on a different server, or directly from Apple. The client-side configuration is automatic so provides a seamless experience to end users.
Pretty cool, eh? But you’re probably thinking this new awesomeness is hard as all heck to install. Well, notsomuch. There are a few options that can be configured, but the server is smart enough to do most of the work for you. Before you get started, you should:
Once all of the requirements have been met, you will need to install the actual Caching Service. To do so, open Server.app from the /Applications directory and connect to the server with which you would like to install the Caching service.
Click on Caching from the SERVICES section of the Server sidebar. Here, you have 3 options you can configure before starting the service. The first is which volume with which to place updates. This should typically be a Pegasus or other form of mass storage that is not your boot volume. Use the Edit… button to configure which volume will be used. By default, when you select that volume you’ll be storing the updates in the Library/Server/Caching/Data of that volume.
The next button is used to clear out the cache currently used on the server. Click Reset and the entire contents of the aforementioned Data directory will be cleared.
Next, configure the Cache Size. Here, you have a slider to configure about as much space as you’d like, up to “Unlimited”. You can also use the command line to do some otherwise unavailable numbers, such as 2TB.
Once you’ve configured the correct amount of space, click on the ON button to fire up the service. Once started, grab a client from the local environment and download an update. Then do another. Time both. Check the Data folder, see that there’s stuff in there and enjoy yourself for such a job well done.
Now, let’s look at the command line management available for this service. Using the serveradmin command you can summon the settings for the caching service, as follows:
sudo serveradmin settings caching
The settings available include the following results:
caching:ReservedVolumeSpace = 25000000000
caching:SingleMachineMode = no
caching:Port = 0
caching:SavedCacheSize = 0
caching:CacheLimit = 0
caching:DataPath = "/Volumes/Base_Image/Library/Server/Caching/Data"
caching:ServerGUID = "FB78960D-F708-43C4-A1F1-3E068368655D"
caching:ServerRoot = "/Library/Server"
Don’t change the caching:ServerRoot setting on the server. This is derived from the root of the global ServerRoot. Also, the ServerGUID setting is configured automatically when connecting to Apple and so should not be set manually. When you configured that Volume setting, you set the caching:DataPath option. You can make this some place completely off, like:
sudo serveradmin settings caching:DataPath = "/Library/Server/NewCaching/NewData"
Now let’s say you wanted to set the maximum size of the cache to 800 gigs:
sudo serveradmin settings caching:CacheLimit = 812851086070
To customize the port used:
sudo serveradmin settings caching:Port = 6900
The server reserves a certain amount of filesystem space for the caching service. This is the only service I’ve seen do this. By default, it’s about 25 gigs of space. To customize that to let’s say, ‘around’ 50 gigs:
sudo serveradmin settings caching:ReservedVolumeSpace = 50000000000
To stop the service once you’ve changed some settings:
sudo serveradmin stop caching
To start it back up:
sudo serveradmin start caching
Once you’ve started the Caching service in OS X Server and familiarized yourself with the serveradmin caching options, let’s look at the status options. I always use fullstatus:
sudo serveradmin fullstatus caching
Returns the following:
caching:Active = yes
caching:state = "RUNNING"
caching:Port = 57466
caching:CacheUsed = 24083596
caching:TotalBytesRequested = 24083596
caching:CacheLimit = 0
caching:RegistrationStatus = 1
caching:CacheFree = 360581072384
caching:StartupStatus = "OK"
caching:CacheStatus = "OK"
caching:TotalBytesReturned = 24083596
caching:CacheDetails:.pkg = 24083596
The important things here:
Look into the /Library/Server/Caching/Config/Config.plist file to see even more information, such as the following:
There are also a number of other keys that can be added to the Config.plist file including CacheLimit, DataPath, Interface, ListenRanges, LogLevel, MaxConcurrentClients, Port and ReservedVolumeSpace. These are described further at http://support.apple.com/kb/HT5590.
As you can see, this provides the host name of the server and path on that server that the Caching server requires access to, the last port connected to and the last date that the contents were flushed.
In the Data directory that we mentioned earlier is a SQLite database, called AssetInfo.db. In this database, a number of files are mentioned. These are in a file hierarchy also in that Data directory. Client systems access data directly from that folder.
Finally, the Server app contains a log that is accessed using the Logs option in the Server app sidebar. If you have problems with the service, information can be accessed here (use the Caching Service Log to access Caching logs).
The Caching Service uses the AssetCache service, located at
then starts as the new user _assetcache user. It’s LaunchDaemon is at
Note: In my initial testing it appeared that after rebooting devices, that iOS updates were being cached; however, several have reported that this is not yet possible. I’ll try and replicate and report my findings later.
krypted December 17th, 2012
Tags: Caching Server, caching service, Config.plist, Flush, ios, iPad, LastPort, logs, MAC, mountain lion server, OS X Server 2.2, server.app, serveradmin, Software Update Server, Software Updates, sqlite
The software patching configuration built into most operating systems is configured to open a box at home, join your network and start using the computer right away. As environments grow from homes to offices and then offices grow into enterprises, at some point software updates and patches need to be managed centrally. Mountain Lion, as with its OS X Server predecessors has a Software Update service. The service in the Server app is known as Software Update and from the command line is known as swupdate.
The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog. These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist. The Apache version is now Apache/2.2.22.
Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:
defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist
To point a client to a server via the command line, use a command such as the following:
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://updates.krypted.com:8088/index.sucatalog
But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.
By default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.
If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.
The first item in the Updates tab is the “Austomatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).
Note: The only option for updates in an Automatic configuration environment is disable.
The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:
sudo serveradmin start swupdate
To stop the service, replace start with stop:
sudo serveradmin stop swupdate
To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:
sudo serveradmin fullstatus swupdate
The output of which appears as follows:
swupdate:state = "RUNNING"
swupdate:lastChecktime = 2012-08-04 17:04:45 +0000
swupdate:syncStatus = "DONE"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2012-08-04 17:07:10 +0000
swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log"
swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log"
swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log"
swupdate:readWriteSettingsVersion = 1
swupdate:checkError = no
swupdate:pluginVers = "10.8.91 (91)"
swupdate:updatesDocRoot = "/var/db/swupd/"
swupdate:hostServiceState = "RUNNING"
swupdate:autoMirror = no
swupdate:numOfEnabledPkg = 0
swupdate:servicePortsAreRestricted = "NO"
swupdate:numOfMirroredPkg = 0
swupdate:autoMirrorOnlyNew = no
swupdate:startTime = 2012-08-04 17:04:45 +0000
swupdate:autoEnable = no
There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:
sudo serveradmin settings swupdate:autoMirrorOnlyNew = yes
Also, the service can throttle bandwidth for clients. To use this option, run the following command:
sudo serveradmin settings swupdate:limitBandwidth = yes
And configure bandwidth using the syncBandwidth option, as follows:
sudo serveradmin settings swupdate:syncBandwidth = 10
To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:
sudo serveradmin settings swupdate:autoEnable = no
The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):
sudo serveradmin settings swupdate:portToUse = 80
Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:
sudo serveradmin swupdate:PurgeUnused = yes
One of the biggest drawbacks of the Software Update service in OS X Mountain Lion Server in my opinion is the fact that it does not allow for serving 3rd party packages, from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in OS X. But then, we wouldn’t want to make it too easy.
Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the OS X Server part of the stack, but it’s related). While many options have come up for this, one is to just run the softwareupdate command for clients via ARD or a similar tool.
Many environments have used these issues to look at tools such as reposado or third party patch management tools such as JAMF Software’s the Casper Suite (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, Absolute Manage and others. Overall, the update service in Mountain Lion is easily configured, easily managed and easily deployed to clients. It is what it needs to be for a large percentage of OS X Mountain Lion (10.8) Server administrators. This makes it a very viable option and if you’ve already got a Mountain Lion computer sitting around with clients not yet using a centralized update server, well worth enabling.
Note: Managing multiple Software Update Servers has changed in OS X Mountain Lion Server, see my previous post for more information on these changes.
krypted August 5th, 2012