Создание динамических, экономичных и универсальных пакетов для Приложения Microsoft 365

Примечание.

В этой статье, созданной Приложения Microsoft 365 Rangers, описаны распространенные практики, наблюдаемые в реализации клиентов. Мы рекомендуем оценить актуальность этого руководства для вашей организации и адаптировать подход по мере необходимости.

Администратор может запланировать развертывание Приложения Microsoft 365 в организации. Такое развертывание часто не просто передает базовые Приложения Microsoft 365 на устройства. Пользователям могут потребоваться дополнительные компоненты, например языковые пакеты, средства проверки правописания или дополнительные продукты, такие как Visio или Project. Мы часто называем эти сценарии второй установкой, а начальную установку Приложения Microsoft 365 часто называют первой установкой. Для сценариев 1-й установки ознакомьтесь с параметрами установки и лучшим способом правильного размера развертывания.

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

Задача

Исторически задача поддержки сценариев второй установки была решена путем создания выделенного пакета установки для каждого из них. Обычно администратор объединяет необходимые исходные файлы (около 3 гигабайт) с копией средства развертывания Office (ODT) и файлом конфигурации, адаптированным для этого сценария.

Но, особенно в крупных организациях, у вас часто нет единого набора конфигураций Приложения Microsoft 365. У вас может быть несколько каналов обновления, например, большинство из них находится на Monthly Enterprise Channel, а несколько устройств специального назначения — в Semi-Annual Enterprise Channel. Может быть, в настоящее время вы переходите с 32-разрядной на 64-разрядную, и вам нужно поддерживать обе архитектуры в течение некоторого времени.

Если вы создаете выделенное развертывание, например языковой пакет для каждого канала и архитектуры в предыдущем примере, вы запустите четыре пакета: Monthly Enterprise Channel x86, Monthly Enterprise Channel x64, Semi-Annual Enterprise Channel x86, Semi-Annual Enterprise Channel x64. Этот подход не является устойчивым и имеет следующие недостатки:

  • Высокие затраты на обслуживание
    • Большое количество пакетов для создания и обслуживания.
    • Внедренные исходные файлы со временем устаревают и нуждаются в обслуживании.
    • Высокое потребление пропускной способности во время развертывания, так как полный пакет размером 3 ГБ синхронизируется с устройством до начала фактической установки.
  • Плохое взаимодействие с пользователем
    • Пользователи должны понять свою текущую конфигурацию и выбрать соответствующий пакет на портале программного обеспечения.
    • Долгое время развертывания, так как полные исходные файлы синхронизируются в первую очередь.
    • Если внедренные исходные файлы устарели, установка понижает полную версию установки до запуска цикла обновления и обновления всех приложений.

Итак, как создать пакеты, которые менее затратны для обслуживания с течением времени и являются более удобными для пользователя?

Решение: динамические, экономичные и универсальные пакеты

Эти проблемы можно устранить, реализовав самонастраивающиеся, небольшие и универсальные пакеты. Давайте рассмотрим основные понятия, прежде чем перейти к примерам сценариев.

Создавайте динамические пакеты, в которых вы ничего не можете жестко кодить. Используйте функции средства развертывания Office (ODT), чтобы позволить пакетам самостоятельно адаптироваться к требованиям:

  • Используйте Version=MatchInstalled , чтобы предотвратить непредвиденные обновления и контролировать версию, установленную на клиенте. Нет жесткого кода номера сборки, который быстро устаревает.
  • Используйте Language=MatchInstalled , чтобы указать, например, Visio или Project установить с тем же набором языков, что и Office. Не нужно перечислять их или создавать скрипт, который внедряет необходимые языки.

Создавайте бережливые пакеты, удалив исходные файлы из пакетов. Это имеет несколько преимуществ:

  • Размер пакета меньше— от 3 ГБ до менее 10 мегабайт для ODT и его файла конфигурации.
  • Вместо отправки пакета установки размером 3 ГБ на клиенты вы можете позволить клиентам извлекать все, что им нужно, из сети доставки содержимого Office (CDN), что позволяет сэкономить пропускную способность.
    • При добавлении Project в существующую Приложения Microsoft 365 установку необходимо скачать менее 50 мегабайт, так как общие компоненты Office уже установлены.
    • Установка Visio обычно составляет 100–200 мегабайт в зависимости от количества языков, так как шаблоны и наборы элементов являются существенной частью скачивания.
    • Установка средств проверки правописания обычно составляет 30–50 мегабайт, а полный языковой пакет — 200–300 мегабайт.
  • Второй сценарий установки часто выполняется реже, что снижает нагрузку на интернет-трафик, что в конечном итоге снижает влияние.
  • Вам не нужно обновлять исходные файлы каждый раз, когда корпорация Майкрософт выпускает новые функции или исправления безопасности и качества.

Создавайте универсальные пакеты без жесткого программирования, таких как архитектура или канал обновления. ODT будет динамически соответствовать существующей установке, поэтому пакеты работают во всех каналах обновления и архитектурах. Вместо четырех пакетов для установки Visio, например, у вас есть один универсальный пакет, который работает во всех перестановках каналов обновления и архитектур.

  • Если не использовать OfficeClientEdition , пакет будет универсальным для смешанных сред x86/x64.
  • Если не уходить из channel, пакет будет универсальным для каналов обновления.

Создание динамических, экономичных и универсальных пакетов и использование их преимуществ

Идея заключается в том, чтобы не жестко закодировать ничего в файле конфигурации, а вместо этого использовать хитроумность средства развертывания Office как можно больше.

Давайте рассмотрим "классический" пакет, который был создан для добавления Project в существующую установку Приложения Microsoft 365. У нас есть исходные файлы (~3 гигабайта) и файл конфигурации, в котором явно указано, чего мы хотим достичь:

Пример пакета.

<Configuration>
 <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
  <Product ID="ProjectProRetail">
   <Language ID="en-us" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

При применении концепций динамических, экономичных и универсальных пакетов результат будет выглядеть следующим образом:

Бережливый пример пакета.

<Configuration>
 <Add Version="MatchInstalled">
  <Product ID="ProjectProRetail">
   <Language ID="MatchInstalled" TargetProduct="O365ProPlusRetail" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

Так что же мы изменили, и каковы преимущества?

  • Мы удалили атрибут OfficeClientEdition-, так как ODT будет автоматически соответствовать установленной версии.
    • Преимущество. Файл конфигурации теперь подходит для сценариев x86 и x64.
  • Мы удалили канал по той же причине. ODT будет автоматически соответствовать уже назначенному каналу обновления.
    • Преимущество I. Пакет работает для всех каналов обновления (Current Channel, Monthly Enterprise Channel, Semi-Annual Enterprise Channel и др.).
    • Преимущество II. Он также подходит для каналов обновления, которые вы не предлагаете в качестве центральных ИТ-отделов. Некоторые пользователи используют Current Channel, некоторые используют сборки программы предварительной оценки? Не волнуйтесь, это просто работает.
  • Мы добавили Version="MatchInstalled", что гарантирует, что ODT установит ту же версию, которая уже установлена.
    • Преимущество. Вы управляете развернутыми версиями без непредвиденных обновлений.
  • Мы добавили language ID="MatchInstalled" и TargetProduct в соответствии с установленными языками, заменив жестко заданный список устанавливаемых языков.
    • Преимущество I. У пользователя те же языки для Project, что и для Office.
    • Преимущество II. Нет необходимости повторно запрашивать установку языковых пакетов.
    • Преимущество III. Также работает для редко используемых языков, которые вы как центральный ИТ-администратор не предлагаете, что делает пользователей счастливыми.
  • Мы удалили исходные файлы. ODT точно вовремя получает правильный набор исходных файлов из сети CDN Office.
    • Преимущество I. Пакет никогда не устаревает. Обслуживание исходных файлов не требуется.
    • Преимущество II. Загрузка составляет около 50 мегабайт, а не около 3 ГБ.

Другой пример: добавление языковых пакетов и средств проверки правописания динамическим, экономичным и универсальным способом

Давайте кратко рассмотрим и другие сценарии, например добавление языковых пакетов и средств проверки правописания. Классический файл конфигурации для установки немецкого языкового пакета может выглядеть следующим образом:

<Configuration>
 <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
  <Product ID="LanguagePack">
   <Language ID="de-de" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

Опять же, этот файл конфигурации будет работать только для одного конкретного сценария (для канала обновления задано значение Monthly Enterprise Channel, установлен 64-разрядный). Другие сценарии должны быть охвачены дополнительными файлами и пакетами, которые повысят сложность и стоимость владения. Это можно исправить, просто перейдя к динамическому, экономичному и универсальному способу:

<Configuration>
 <Add Version="MatchInstalled">
  <Product ID="LanguagePack">
   <Language ID="de-de" />
  </Product>
 </Add>
 <Display Level="None" />
</Configuration>

Этот один файл конфигурации работает в x86/x64 и во всех каналах обновления, таких как Current Channel, Monthly Enterprise Channel, Semi-Annual Enterprise Channel и т. д. Таким образом, если вы хотите предложить пять дополнительных языков в вашей среде, просто создайте пять из этих пакетов "файл конфигурации + ODT". Для средств проверки правописания просто измените ProductID на "ProofingTools".

Создание собственной конфигурации

Вышеприведенная концепция универсально применима ко всем установкам и продуктам на основе "нажми и запуск", при условии, что используется ODT. Вы можете изменить указанный идентификатор продукта в соответствии с вашим сценарием. Дополнительные сведения см. в списке поддерживаемых идентификаторов продуктов .

Предварительные требования и примечания

Ниже приведены некоторые предварительные требования, которые необходимо выполнить, чтобы эта концепция работала в вашей среде, и некоторые примечания:

  • Используйте средство развертывания Office 16.0.11615.33602 или более поздней версии, чтобы включить функцию Version="MatchInstalled".
  • ODT должен иметь возможность найти соответствующие исходные файлы в сети CDN Office.
  • Убедитесь, что контекст, который вы используете для запуска установки, может проходить через прокси-сервер. Дополнительные сведения см. в разделе Руководство по развертыванию и прокси-серверу Office 365 профессиональный плюс.
  • Убедитесь, что учетная запись (пользователь или система), используемая для установки приложений, может подключаться к Интернету.
  • Указанные ранее специализированные файлы конфигурации подходят для установки продуктов (с параметром /configure), но не работают с параметром /download. Это ожидаемо, так как в ODT отсутствуют некоторые сведения для загрузки (например, архитектура). Для указанной выше концепции нет необходимости скачивать файлы заранее.