You may notice issues with the 10.13.4 update not showing as available on some machines if they are using a reposado server for Apple software updates.
Here's why:
(This looks like an sucatalog authoring error on Apple's part)
There are currently two "BridgeOSUpdateCustomer" updates offered:
041-31307 BridgeOSUpdateCustomer 10.14.3 2019-01-22
041-31307::1 BridgeOSUpdateCustomer 10.14.3 2019-01-22
In the 10.13 sucatalog, product 041-31307 has paths starting with `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/`
in the 10.14 sucatalog, product 041-31307 has paths starting with `content/downloads/28/02/041-31307/ix7l1mpxyd4mykuv8c7gamghohr74d2tks/`
product 041-31307::1 has paths starting with `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/`
repo_sync normally syncs the 10.13 sucatalog first, populating `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/`
Then it syncs the 10.14 catalog, but notices it already synced product 041-31307, so it skips that.
It then syncs product 041-31307::1, possibly replacing some of the items it previously synced to `content/downloads/28/02/041-31307/xvibxlykpmbsmi3novwdlppa7vi2cpma86/` when it did the 10.13 sucatalog sync.
So repo_sync doesn't do a complete sync of the two products, and clients running 10.14.x that need the BridgeOSUpdateCustomer may not be able to download the needed files. This results in a "Error 100" from softwareupdate. If you examine the log at /var/log/install.log you may see entries like this:
The workaround for now is to set (or modify) AppleCatalogURLs in reposado's preferences to ensure reposado syncs the 10.14 sucatalog _before_ the 10.13 sucatalog. For example:
Only time will tell if this is intentional on Apple's part and if a more robust fix will have to be added to reposado's code.
Thank you to Eric Holtam and other members of the MacAdmins Slack for helping diagnose this issue.