Собрал пост по крупицам о том, как автоматизировать обновления Microsoft Office 2016 для macOS. Да, вот так вот внезапно. В посте присутствуют такие слова, как bash, python, powershell, docker, ConfigMgr, Parallels и всё только самое современное. ;) Ну, что? Поехали?

Предисловие

Идея в том, что у нас есть пачка девайсов под управление macOS на которых стоит Microsoft Office. Софт на них централизованно катится с ConfigMgr, какие-то апдейты для операционки из аппстора, а вот с офисом беда была. MS Office пока нет в маковском аппсторе, а обновлять и следить за ним очень надо, поэтому было решено, что нам требуется что-то, что будет его обновлять. ;)

Вы ведь знаете, как работают обновления для офиса на Windows? Microsoft выпустила апдейты, wsus отсинхронизировал каталог, вы скачали обновления и раздали их через WSUS или SUP у ConfigMgr, апдейт агенты отчитались с клиентов до WSUS и дальше процесс более-менее понятен. На macOS нет Windows Update Agent, маки не отчитываются на WSUS. Так что же нам с ними делать?

У Microsoft есть Microsoft AutoUpdate (MAU). Вот он и занимается проверкой версий и стучит в CDN Microsoft для проверки и скачиваний последних обновлений. MAU можно скачать здесь — https://docs.microsoft.com/en-us/officeupdates/release-history-microsoft-autoupdate

С версии MAU 3.18 и выше в /Library/Application\ Support/Microsoft/MAU2.0/Microsoft\ AutoUpdate.app/Contents/MacOS появилась консольная утилина msupdate. Весь список команд можно глянуть через ./msupdate —help
Вот она и занимается обновлением офиса. Что нам от неё надо? Она читает настройки из plist com.microsoft.autoupdate2, в котором мы уже можем настроить всё, что нам надо. Запомните главную вещь, настройки MAU берёт только из пользовательского плиста в ~/Library/Preferences/, это важно.

Но мы ведь хотим, чтобы обновления раздавались из внутренней сети, поэтому в первую очередь нам требуется утянуть из CDN все апдейты для офисных продуктов. В этом нам поможет powershell скрипт.
Всего есть 5 каналов поставки офиса: Production (ежемесячные релизы), External (или Insider Slow — ранний доступ), Internal (без понятия, но в документации присутствует), Custom (наш собственный) и InsiderFast (недельные релизы).

Внимание! Одна ветка Production занимает > 13 ГБ, если добавлять остальные, то выйдет > 25 ГБ.

.\psMacUpdatesOFFICEv2.ps1 -channel Production -IISRoot C:\inetpub\wwwroot -IisFolder maucache -TempShare C:\Temp

Скачали? Молодцы.

Первым делом нам надо раскатить на клиентов новую версию MAU, чтобы полностью контролировать ситуацию. Для тех, у кого управление маками нативное через ConfigMgr, то развлекайтесь сами с конвертацией pkg пакета, у меня всё это давно перестало работать на High Sierra. В Parallels все ставится через пакет: installer -pkg Microsoft_AutoUpdate_4.0.18061000_Updater.pkg -target /
И всё, раскатили MAU.

Далее, нам же нужно куда-то сложить 25 гигов, чтобы клиенты могли забрать. Вариантов несколько.

Вариант первый — используем нашу точку распространения на ConfigMgr, а точнее наш IIS. Только нужно чуточку подшаманить.


В Default Web Site создадим директорию, которая будет слинкована на UNC путь, где у нас будут лежать апдейты. Не на диск же Ц всё это складывать. ж) И не забываем добавить MIME types, а то IIS ничего не знает про файлы форматов dmg/pkg и будет возвращать 404.


.dmg — file/download
.pkg — file/download

Вариант два — засунуть всё это в докер образ и с выходом очередных апдейтов для офиса просто делать ребилд докер контейнера.
За основу возьмем контейнер nginx из докерхаба и в две строчки в dockerfile соберём контейнер с апдейтами.

docker build -t office-updates .

Запуск docker run —name office-updates -d -p 8080:80 office-updates

После запуска nginx отдаёт нам всё, что надо.

Вариант два с половинкой — маунтить волюмом в докер шару с апдейтами. Здесь билд уже будет проходить за 3 секунды.

Так, теперь клиенты у нас по http смогут забрать апдейты. Пора разобраться, как им объяснить, где же их забирать и как контролировать этот процесс.

В ConfigMgr у нас есть замечательная штука под названием Configuration Items. Все настройки MAU берёт из пользовательского com.microsoft.autoupdate2. Читаем его: defaults read com.microsoft.autoupdate2 и видим что-то подобное.

В плист надо добавить несколько настроек. Я думаю, что из названия самих настроек всё понятно, кто и что делает. Если нет, то самый подробный документ, I’ve ever seen, лежит здесь и тут. Частота проверки указывается в минутах. Для разных коллекций, могут быть разные настройки и разные каналы обновлений офиса, чтобы мы могли проверить новый релиз на тестовых клиентах.

Нас интересуют эти настройки:

HowToCheck -string AutomaticDownload
DisableInsiderCheckbox -bool TRUE
ChannelName -string ‘Custom’
ManifestServer -string ‘http://srv-sccm-ps/officeupdates/’
UpdateCache -string ‘http://srv-sccm-ps/officeupdates/’
UpdateCheckFrequency -int 240
SendAllTelemetryEnabled -int 0

Но, как выяснилось в процессе тестирования для того, чтобы MAU начал обновлять, то его необходимо ассоциировать по версиям с приложениями Офиса. Значит перед тем, как раздать все настройки в плист, требуется на клиентах сделать всё красиво.

Мы возьмём текущую сессию пользователя, прогоним все приложения Офиса по версии и запишем всё, что нам надо в пользовательский com.microsoft.autoupdate2 вот таким скриптом.

Скрипт для проверки настроек.

Что нам с этим всем делать? Надо создать Configuration Items и всё. ж)

И поймать Success на выходе.

Все логи MAU смотрим в /Library/Logs/Microsoft/autoupdate.log

Как мы видим, клиент успешно забирает xml, если MAU видит, что билд Офиса сменился, там же в логе вы увидите и процесс установки.

Несколько лайфхаков. ж)

Если в stdout вернется еще что-нибудь кроме Success, то клиент будет все равно Non-Compliant. Возможно, что это такое поведение самого агента Parallels. Про ConfigMgr уже не знаю.

Если записываем через su $CurrentloggedInUser -c defaults write /Users/$CurrentloggedInUser/Library/Preferences/com.microsoft.autoupdate2, то плист поломается. Что агент ConfigMgr, что агент Parallels уже всё выполняют с повышенными привилегиями. Не забывайте делать бэкапы плистов, просто поднимать интерактивную сессию sudo -i и там уже проверять, что всё работает так, как надо.

Главный лайфхак. В Windows 10 инсайдер билд notepad уже должен нормально работать с файлами, созданными в Unix, Linux и macOS, но если вы залили шелл скрипт на свою точку распространения, добавили в пакет, поправили файл в блокноте на WS2012 R2, например, то всё, всё сломалось. ;) Помните про это, т.к. после многочасовых траблшутингов можно долго бить себе фейспалмы.

Добавить комментарий