Архитектура нашей сети такова, что имеется много узких каналов, AD не целесообразно.
В итоге при обновлении сервера до новой версии возникает ситуация, при которой большинство пользователей, включающих компьютер в одно и то же время, утром, при скачке обновления с сервера:
1) забьют канал до сервера
2) пока будет грузиться обновление, начнут грузить техподдержку жалобами. Общее впечатление от перехода на MyChat будет смазано.

В связи с этим возникает несколько направлений оптимизации механизма обновления:
Предложение №1
Обратная поддержка версий, чтобы не было жесткой необходимости обязательного обновления клиента при обновлении сервера в 2-ух первых цифрах номера версии.
Тяжело реализовать, разработчики не берутся реализовать.
Вывод: Проехали.

Предложение №2
Обновление с нескольких серверов.
Например, чтобы через шаблоны настроек можно было задать http ссылку для файла обновления для разных групп клиентов.
Все просто: кто сидит в одной сети, тот и обновляется с веб-сервера в той сети.
Рализация: просто, но при неправильной настройке, клиент не сможет обновится и не сможет работать вообще.
Админам сети - особое внимание на развернутые веб-сервера, актуальность ссылок, обновлений и т.д.

Предложение №3
Кеширование файла обновления.
Т.е., через AD ( в нашей сети, без AD, через скрипты) раздает обновления, складываем их в папку UPDATES.
Клиент запускается, если видит, что версия файла обновления выше, чем сервера, то не обновляется.
Просто запускается и работает дальше.
Если видит, что файл обновления соответствует версии сервера, то сразу запускает обновление. Без траты времени на закачку и нагрузки на канал.
ИМХО самый простой в реализации вариант .

Как сейчас планируется сделать у нас (не оптимальный вариант):
1) Раскидываем скриптами файл обновления на всех клиентов. Равномерно, не создавая пиковой активности в канале.
2) Ночью обновляем сервер и включаем скрипт, который отрабатывает при запуске компьютера, обновлять клиента.
3) Утром: пользователь запускает компьютер, скрипт запускает обновление, обновляется.
4) После: свежий клиент подключается к свежему серверу. Все ок.

Но хотелось бы реализация п.2 и п.3.

Разработчики, как вам такое предложение?

Спасибо.

[Алексей Пикуров]

Здравствуйте, Юрий.

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

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

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

Team lead
Чат со мной

"Предложение №2
Обновление с нескольких серверов.
Например, чтобы через шаблоны настроек можно было задать http ссылку для файла обновления для разных групп клиентов.
Все просто: кто сидит в одной сети, тот и обновляется с веб-сервера в той сети.
Рализация: просто, но при неправильной настройке, клиент не сможет обновится и не сможет работать вообще.
Админам сети - особое внимание на развернутые веб-сервера, актуальность ссылок, обновлений и т.д."

А что мешает сделать несколько gpo для разных подсетей на установку клиента? Чтобы например политика 1 предписывала пользователям сети 1 брать клиент с ближайшего для них сервера и так далее...