CM: Обновление клиента ConfigMgr. Какой способ выбрать?

С начала анонса Configuration Manager 2012 прошло достаточно времени, чтобы для него начали появляться обновления и заплатки. В 2012 версии появился такой функционал, как автоматическое обновление клиента… но что-то где-то не срослось. Хотя разработчики утверждали, что новый способ работает так, что версия клиента автоматически обновляется в установленные сроки до версии сайта, но на деле это просто не работает! Итак, подводя итоги, что нам доступно? Ниже я перечислю какие способы есть и постараюсь описать плюсы и минусы.

Способ 1. Обновление с помощью пакетов.

Данный способ является самым простым. При установке кумулятивных обновлений мастер установки предлагает автоматически создать пакеты, после чего мы их объявляем на коллекции. Такой способ тянется с самых ранних версий. А теперь о плюсах и минусах. Простота данного способа несомненно является плюсом. Минус данного способа – его ненадежность. В добавок, в отличие от ConfigMgr 2007, клиент 2012 имеет разрядность – для 32 и 64 битных систем, что в свою очередь требует настройки каждой программы, либо создание 2х коллекций соответственно.

Способ 2. Обновление с помощью приложений.

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

Способ 3. Push-Install.

Данный способ подходит только для ConfigMgr 2007. В 2012 про него можно забыть, т.к. клиент теперь имеет разрядность, соответственно, использовать параметр PATCH нет смысла. Также минусом данного способа является то, что для него требуется вызов удаленных процедур и общая папка. А как же брандмауэры, а как же DMZ, а как же интернет-клиенты? А никак… поэтому данный способ даже не следует рассматривать.

Способ 4. Windows Update.

Тут разработчикам можно поставить большой плюс, т.к. с установкой очередного обновления разворачивается каталог для System Center Updates Publisher в папке SCUP. Всё, что нужно сделать – это импортировать данный каталог в Updates Publisher, после чего уже распространять это обновление на клиенты. Т.е. в данном случае, плюсом является максимально быстрое развертывание с минимальными затратами времени, а также гарантированное обновление клиента до нужной версии. Минусами данного способа является то, что требуется инфраструктура WSUS, более того, крайне желательно использовать SUP в качестве источника обновлений.

Способ 5. Установка нового клиента при развертывании ОС.

Данный способ является вполне приемлемым. Но! В ConfigMgr 2012 невозможно установить обновления клиента через пакеты и приложения. В первом случае Вы получите ошибку 0x87d00215, которая говорит об остановке службы CcmExec, а во втором – зависший Task Sequence. Так что единственный способ – это использование параметра PATCH. Минусом данного способа является то, что командную строку придется менять во всех последовательностях задач при выходе новой заплатки, а также то, что данный способ не обновит существующие и переустановленные клиенты.

Способ 6. Использование папки ClientPatch.

ВНИМАНИЕ! Данный способ является неподдерживаемым!

Плюсом данного решения является то, что все заплатки находящиеся в данной папке будут применены как при использовании Push Install, так и при OSD. Минусом… Нет… МИНУСИЩЕМ данного способа является то, что начиная с версии 2007 данный способ не поддерживается Microsoft, хотя и работает даже в версии 2012, а также то, что данный способ не обновит существующие клиенты до тех пор, пока Вы не нажмете кнопку «Repair client».

Вполне возможно, что я упустил еще какие-то способы для обновления клиентов. Я умышленно не рассмотрел стартап-скрипты и прочие скрипты, т.к. это отдельная тема и данные способы, на мой взгляд, являются побочными. В следующих циклах статей я постараюсь более подробно (с картинками и примерами) описать каждый из вышеописанных способов, чтобы можно было составить для себя какое-то комплексное решение и оставить именно то, что нужно Вам.

Реклама

CM: SCUP2011 — Verification of file signature failed

Совсем недавно развернул свежую инфраструктуру ConfigMgr 2012 Sp1, а заодно и System Center Updates Publisher 2011. Вроде бы всё делаю как обычно — установил SCUP, интегрировал в ConfigMgr, выписал с Enterprise CA сертификат с расширением «Code Signing» и импортировал его в SCUP. Вроде бы всё, можно приступать — писать свои или загружать 3rd party каталоги и распространять. Но… Сколько бы я не загружал, ни один пакет так и не загрузился. Сперва я грешил на интернет-канал, но когда я скачал файлы локально, то результат был тот же самый. В итоге, открыв логи, я увидел примерно следующее сообщение:

2013-07-08 07:10:03.238 UTC Error Scup2011.7 Publisher.PublishPackage PublishPackage(): Operation Failed with Error: Verification of file signature failed for file: \\Domain.local\configmgrdfsroot\wsus\UpdateServicesPackages\2d5208f4-7e9c-492f-894c-c338d6f795b3\c08eb883-55e6-4730-9c02-15434cc5f11f_1.cab

Тут меня насторожило, что проблема с сертификатом. Проверив дважды сертификат и не найдя ошибок я решил копать дальше. В итоге, после того как я еще немного попыхтел, я вспомнил что я не сделал то, чего обычно делаю прежде, чем начинать первую работу с SCUP — я не добавил копию открытого ключа в каталог сертификатов «Trusted Publishers»:

Cretificate Store

После этого я еще раз проверил загрузку обновлений и всё прошло успешно!

SUP: Обновление Mozilla Firefox с помощью SCUP 2011

Firefox updateВ прошлый раз я рассказывал, как можно обновить Java. Ввиду того, что в некоторых компаниях используют Mozilla Firefox, как альтернативный корпоративный браузер (и такое бывает :)), то я покажу, как можно процесс обновления «поставить на поток». И так, в первую очередь нам нужно определиться, на какую версию будем обновляться. На момент написания статьи последняя версия — 13.0.1. Скачиваем с сайта по ссылке http://download.mozilla.org/?product=firefox-13.0.1&os=win&lang=ru дистрибутив и выкладываем в общедоступную сетевую папку. Далее, открываем SCUP жмем кнопку «Create vendor» и создаем каталог «Mozilla», в созданном каталоге нажимаем кнопку «Create Product» и создаем каталог «Firefox»:

SCUP Overview

В верхней части окна нажимаем кнопку «Create» и выбираем Software Update. В открывшемся окне мы указываем основные параметры, которые у нас будут использоваться при установке:

  • Package Source — Имя файла. В нашем случае это «Firefox Setup 13.0.1.exe»
  • Download URL (or UNC) — Тут мы указываем полный путь до нашего файла. Я в своем примере использую доменный DFS путь
  • Command line — Ключ тихой инсталляции. В нашем случае «/s».

Firefox Package Information

Далее нажимаем «Next» и переходим к следующему окну. В окне «Required Information» мы вводим информацию о нашем обновлении:

  • Language — тут мы выбираем язык, для которого мы будем вводить информаци. В обновлении WSUS описание может быть написано на разных языках, я не буду этого делать и создам только на английском.
  • Title — имя обновления, «Mozilla Firefox 13.0.1»
  • Description — это поле заполнять не обязательно, тут мы можем вписать описание обновления. В моем случае, я просто взял описание браузера с официальной страницы — http://www.mozilla.org/en-US/projects/
  • Classification — Update
  • Vendor — Mozilla
  • Product — Firefox
  • More Info URL — http://www.mozilla.org

Firefox Required Information

Жмем «Next» и переходим к окну «Optional Information». В этом окне особо вбивать нечего, разве что только можем добавить поле Support URL — http://support.mozilla.org. Жмем кнопку «Next», в окнах Prerequisites и Superseded Updates нам особо делать нечего, т.к. у нас пакет не требует каких либо дополнительных элементов и переходим к окну правил установки — «Installable Rules». Тут как раз у нас потребуется сноровка и мастерство 🙂 Мы нажимаем на кнопку с изображением звездочки и выбираем:

  • Rule type — Registry
  • Subkey — SOFTWARE\Mozilla\Mozilla Firefox

Ставим галочки напротив полей:

  • Value Name — Default Value, т.к. нас не интересуют какие либо значения, нас интересует только наличие данной ветки реестра
  • This registry key is for a 32-bit application on a 64-bit system — эта галочка используется для того, чтобы 64 битные ОС искали запись в 32 битной ветке реестра (Wow6432Node)

И выбираем The registry setting must exist on the target computer to indicate applicability, т.к. как я уже написал выше — значения нас не интересуют. Нажимаем OK.

Firefox Registry Applicability Rule

Создаем еще одно правило, чтобы не вышло так, что под наш критерий попадут компьютеры с более поздней версией браузера. Также нажимаем кнопку с изображением звездочки и выбираем:

  • Rule type — File
  • File Name — firefox.exe

Ставим галочку напротив Use the registry to determine file location, мало ли кто куда поставил себе браузер :). В открывшихся строках пишем:

  • Subkey — SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe
  • Value — Path

Переключаем button на The file must satisfy the following rule on the target computer to indicate applicability и выбираем:

  • Property — Version
  • Operator — Less Than
  • Value — 13.0.1.4548 (это версия исполняемого файла firefox.exe на момент написания статьи)

File Firefox Applicability Rule

Жмем ОК. В итоге наше правило применения будет выглядеть следующим образом:

Firefox Installable Rules

Далее, чтобы не повторять один и тот же набор действий, мы сохраним созданный набор правил. Для этого необходимо перевести курсор мыши на самый верхний уровень, в нашем случае это оператор AND :), и нажать на иконку с изобажением дискеты. Назовем наше правило Firefox Rules. Нажимаем кнопку «Next» и переходим к следующему окну.

В окне «Installed Rules» создаем правила проверки того, что приложение установлено. Для этого нажимаем опять кнопку с изображением звездочки и в поле Rule type выбираем Saved Rule, далее выбираем наше сохраненное правило. Все, что нам нужно сделать, это в правиле File ‘[REGISTRY_PATH]\firefox.exe’ Version < ‘13.0.1.4548’ изменить значение Operator с «Less than» на «Equal to».

Installed Rules

Далее следует завершить все остальные шаги мастера и опубликовать наше обновление.

SUP: FlashPlayer 11 x64 на 32 битных компьютерах

Наверное, многие, кто использует SCUP 2011 наблюдали в своих отчетах после установки FlashPlayer 11, что на 32 битных компьютерах отображались установленными также и 64 битные версии этого обновления, хотя они по определению там не могут быть установлены. Всё на самом деле достаточно банально — разработчики сделали проверку архитектуры в Installable Rules, а в Installed Rules нет. В результате этого ветки реестра совпадают для обеих архитектур и система определяет что обновления как для 32, так и для 64 битных архитектур применены. Лечится просто — достаточно в Installed Rules добавить Processor Architecture x64:

Image

SUP: Обновление Java с помощью SCUP 2011

На работе была поставлена задача — обновить Java до версии 6.31 (7я пока не рассматривается:)). Делать это через коллекции Configuration Manager не интересно, коллекций и без того большое количество и это всё таки обновление. Процесс не совсем тривиальный, поэтому опишу его.

СSCUP Catalog сайта Oracle скачиваем 32 и 64 битные версии. Далее в Updates Publisher 2011 создаем каталог «Sun Microsystems, Inc.» и в этой папке «Java Runtime Environment». Для 64 битных операционных систем требуется обновить обе версии. Начну рассказывать с простого — обновление именно 64 битной версии. С 32 битной пришлось попотеть, о чем я расскажу ниже. Далее мы нажимаем кнопку Create -> Software Update. В открывшемся окне мы заполняем следующую информацию:

Package Source: <Путь до скачанного 64 битного пакета>

Download URL: http://download.oracle.com/otn-pub/java/jdk/6u31-b05/jre-6u31-windows-x64.exe (на момент написания статьи это последняя версия на сайте).

Command Line: /s

Pack Info

Жмем Next. Здесь мы заполняем информацию об обновлении:

Language: English

Title: Java SE Runtime Environment 6 Update 31 (64-bit)

Description: По своему усмотрению, я не менял ничего.

Classification: Update

Выбираем вендора и продукт из списка.

More info URL: http://java.com

SCUP Info

Теперь задаем правила установки, прописываем критерии по которым происходит поиск продукта и информации о том, что продукту требуется обновление, переходим на вкладку Installable Rules.

Жмем на изображение желтой снежинки (Alt+T) и в открывшемся окне выбираем Rule Type: System и Processor Architecture: x64. Жмем ОК.

Этого критерия мало 🙂 Поэтому мы опять жмем звездочку ивыбираем Rule Type: Registry и в поле Subkey прописываем SOFTWARE\JavaSoft\Java Runtime Environment\1.6, ставим галочку напротив Default Value, жмем ОК.

Registry Applicability

Теперь проверяем версию файла java.exe. Версия файла соостветствует версии продукта. Для этого мы делаем еще одно правило. Жмем звездочку и выбираем Rule type: File. Ставим галочку напротив Use the registry to determine file location, прописываем в поля

Path: bin

File Name: java.exe.

Subkey: SOFTWARE\JavaSoft\Java Runtime Environment\1.6

Value: JavaHome

Ведем курсор в нижнюю часть окна и выбираем The file must satisfy the following rule in the target computer to indicate applicability и выбираем:

Property: Version

Operator: Less Than

Value: 6.0.310.5

File Rule

Жмем ОК.
Всё, правило применения написано, сохраняем его как набор, выбрав самый верхний уровень (стрелочка с оператором AND) и нажав на иконку дискеты. Переходим на следующую закладку. На следующей закладке нажимаем на звездочку и выбираем Saved Rule, выбираем сохраненное правило и в последнем правиле из списка меняем Operator Less Than на Equal. Жмем ОК и завершаем мастер создания обновления. Всё! Обновление Java для 64 битных систем создано.

Теперь переходим к более сложному — создание пакета обновления для 32 битных систем. Чем оно сложнее? А тем, что стандартный установщик этого пакета падает с ошибкой 0x00000653 на 64 битных системах. Сам по себе exe файл установщика представляет собой самораспаковывающийся архив с msi файлом, библиотекой архиватора и самим архивом. Для его распаковки достаточно на любом компьютере запустить установку и достать эти файлы из папки %APPDATA%LocalLowSunJavajre1.6.0_31. Дальше препарируем больного:

Качаем 7zip, пакуем эти файлы в формате 7z. Файл называем java.7z.

Качаем модуль 7zsd.sfx с сайта http://7zsfx.info/files/7zsd_150_2100.7z, распаковываем в ту же папку

Создаем файл config.txt, прописываем в него следующие строки:

;!@Install@!UTF-8!
RunProgram=»jre1.6.0_31.msi /q»
;!@InstallEnd@!

Сохраняем файл в формате UTF-8, все три файла кладем в одну папку, открываем окно командной строки и переходим в папку с файлами. Далее набираем команду:

copy /b 7zsd.sfx + Config.txt + java.7z jre-6u31-windows-i586.exe.

На всякий случай проверяем, что установка работает нормально и переходим к процедуре подготовки пакета обновления. Вся процедура аналогична той, что мы уже проделывали для 64 битной версии. Единственное отличие — для данного пакета не нужно указывать какие либо ключи тихой инсталляции. И в правилах, где идет проверка по реестру требуется поставить галочку The registry rule is for a 32-bit application on a 64-bit system.

32-app on 64-bit

Приблизительно так будут выглядеть обновления для java.

SCUP

Дальше публикуем обновления на сервере WSUS и запускаем синхронизацию на сервере SCCM. PROFIT!