Как не потерять работу, администрируя Configuration Manager - часть 1

Как и многие "серверные" продукты, System Center Configuration Manager (далее ConfigMgr) никогда не спит.  Он круглосуточно готов делать то, что вы ему скажете. Если, конечно, он у вас исправен, добавлю я, как инженер поддержки. 

Так вот, он готов в точности выполнить то, что вы ему укажете, и не спросит, действительно ли вы хотите переустановить ОС на всех компьютерах компании прямо сейчас, или вы просто ошиблись в правилах наполнения коллекции. В этом и состоит его отличие от прочих технологий и продуктов, вошедших в повседневную жизнь системных администраторов.  Администраторов Active Directory, Exchange или Hyper-V никогда не уволят за то, что их система отлично сработала.

Опытные администраторы могут посчитать приведённые в статье советы банальными, и раньше я с этим согласился бы. Однако когда я услышал об очередном инциденте с тотальной "перезаливкой" ОС на всех рабочих станциях и серверах, то уверился, что такая статья должна быть. Даже если вы -  профи, и уже все знаете, когда-нибудь вы передадите управление системой своему менее опытному коллеге, со всеми вытекающими последствиями.  Почти каждый, так или иначе, наступал на эти "грабли" с разной степенью тяжести, но многим это ещё предстоит. В этой статье из двух частей я рассмотрю несколько опасных сценариев в Configuration Manager (2007 и 2012), угрожающих репутации и карьере, избежать которых можно конкретными настройками.

Неожиданная массовая переустановка ОС

Несомненно, самый бескомпромиссный сценарий, в котором есть даже крупица чёрного юмора. Несмотря на свою гротескность, случается довольно часто. В результате неверных действий администраторов происходит форматирование дисков и/или переустановка ОС на одном или многих компьютерах. В мировой практике случались случаи, когда "перезаливались" все компьютеры и даже все серверы компании, и предприятие было полностью парализовано. Если не принять некоторых предосторожностей, от ошибки не застрахован никто. Почти в каждой карьере администратора Configuration Manager был или будет тот самый неловкий момент, когда какой-нибудь компьютер запускает Task Sequence невовремя. На ваш выбор есть несколько способов, каждый со своими особенностями - используйте только те, которые посчитаете нужным.

 

! Никогда не назначайте установку ОС на коллекцию All Systems или другую встроенную коллекцию.

Даже если установка будет необязательная. В этом случае, если не применить остальные советы ниже, катастрофа будет в паре кликов мыши от вас - кто-то из администраторов может случайно назначить обязательное расписание этой задаче, либо пользователь случайно запустит установку на своем компьютере. К счастью, в последней версии Configuration Manager убрали возможность сделать необязательное назначение принудительным - для этого придётся создать его заново.

 

! Установите пароль на загрузку по PXE (если она используется):

ConfigMgr 2007: В свойствах роли PXE Point, в поле require a password for computers to boot using PXE задайте пароль, хотя бы самый простой. Держите его в секрете от посторонних. Это предотвратит случайную установку ОС при двух одновременных условиях: загрузке по PXE и наличию обязательного (mandatory) назначения установки ОС на компьютер. Если переустановка ОС начинается в уже установленной системе через Run Advertised Programs или Software Center, то пароль не запрашивается. Пароль сам по себе не спасает от принудительной установки ОС когда её инициируют работающие клиенты!

 

ConfigMgr 2012: в этой версии отдельной роли PXE Point нет, теперь это просто настройка Distribution Point. Пароль включается на закладке "PXE":

 

! Предотвратите запуск OSD Task Sequence в запущенной операционной системе.

 В этом случае, чтобы переустановить ОС на компьютере, потребуется перезапустить его, и загрузиться через PXE или загрузочный носитель в Windows PE. Это подходит не всем, конечно. Некоторые все-таки предпочитают переустанавливать операционную систему удаленно, и в таком случае этот способ неприменим.

ConfigMgr 2007: В свойствах Task Sequence на закладке Advanced выберите This Task Sequence can run only on specified client platforms.

Выберите ОС, которой у вас наверняка нет - Windows 2000. Это не позволит задаче отображаться в окне Run Advertised Programs у пользователей, и она не сможет запуститься у во время работы компьютера, однако по-прежнему будет доступна через PXE.Недостаток этого метода в том, что компьютеры с клиентами всё равно получат эту задачу, и будут посылать на сервер статусные сообщения о её неприменимости к ним. Если клиентов на сайте не очень много, а сервер сайта достаточно производителен, то проблемы с наплывом сообщений не будет.

 

ConfigMgr 2007: создайте альтернативный защитный механизм в самой логике Task Sequence.  Все свои шаги внутри TS "облачите" в одну группу "Run Only in WinPE". Задайте условие, что если TS запускается не в WinPE, то группа завершается с ошибкой. Этот приём подробнее описан в статье базы знаний Microsoft: https://support.microsoft.com/kb/2000656.

- Выше всех шагов создайте группу Run Only in WinPE. Убедитесь, что все шаги TS находятся в ней, и не изменили в результате ваших действий свою очерёдность.

- На вкладке Options этой группы убедитесь, что обе галочки не отмечены, и нажмите Add Condition> If statement> All conditions.

- Вновь нажмите на Add Condition> Task Sequence Variable.

- В появившемся окне в поле Variable введите "_SMSTSInWinPE" без кавычек, не забывая нижнее подчёркивание в начале.

- В поле Condition оставьте "Equals"

- В поле Value пропишите "True" без кавычек, нажмите OK и сохраните Task Sequence. В итоге группа "Run Only in WinPE" должна выглядить как изображено ниже.

ConfigMgr 2012: начиная с Service Pack 1, в этой версии появилась удобная настройка, которая заменяет указанные выше приемы. В настройках развёртывания(Deployment) для этой последовательности задач укажите параметр "Only media and PXE".

Гибель данных пользователя

Данные пользователя можно условно разделить на те, которые он создал в течение дня, не сохраняя работу в Excel или PowerPoint, и те, что находятся у на жестком диске его компьютера.

 

! Всегда предупреждайте пользователей об установке ПО/обновлений

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

 

! Не потеряйте файлы пользователя при миграции на другой компьютер или ОС

Для сохранения документов в ходе переустановки ОС есть несколько подходов - это автоматическая миграция при помощи пакета USMT, работающего вместе с Configuration Manager, либо сохранение документов вручную самим пользователем или сотрудником технической поддержки.

 

Настройка USMT требует соответствующих навыков, обширного тестирования и времени на "обкатку", однако потом позволит уделять переносу данных минимум усилий. Если есть время на внедрение этой технологии, то лучше выбрать такой подход. Тем не менее, помните, что пока вы не доведете механизм миграции до идеала, вероятность потери пользовательских данных высока, так что нужно тестировать, тестировать, тестировать. К примеру, если в момент переноса пользовательских данных открыт Outlook, то Личные папки (файл *.pst) не перенесутся, и будут утрачены навсегда. Однако если вдумчиво подойти к внедрению этой технологии, и все предусмотреть, она избавит от десятков часов монотонной ручной работы по миграции данных.

Подробнее об USMT можно прочитать здесь: https://technet.microsoft.com/ru-ru/library/dd883247(v=ws.10).aspx. В Интернете есть сотни статей и даже видео, как настроить USMT + ConfigMgr.

 

Альтернативу - перенос пользовательских файлов вручную сотрудником IT-отдела описывать не имеет смысла, и он выходит за рамки нашей темы. Перенос файлов самим пользователем можно прописать в политику организации, если ее масштаб небольшой, и так избавиться от большей части проблем. В таких случаях иногда применить интересную страховку от недоразумений - заменить жесткий диск компьютеру на чистый, переместить данные в "чистую" ОС со старого диска, и поместить тот в "отстойник" на неделю-другую, на случай если пользователь что-то забыл там. Потом старый диск можно очистить и использовать в другом компьютере.

Установка нового ПО или обновления идет не так

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

 

! Испытывайте обновления вначале на нескольких компьютерах...

...и реальных пользователях, которые работают с различным специфическим ПО. Выделите компьютеры в каждом отделе - бухгалтерия, склад, маркетинг, охрана - у кого-нибудь из них может быть программа, которая перестанет работать после обновления одной крошечной DLL. Выбирайте компьютеры также в разных филиалах компании, если таковые есть. Заручитесь одобрением руководства, если это новая версия ПО - в некоторых организациях слово "согласовано" имеет огромное значение.

 

! Распространяйте фазировано, сначала на десятки машин, через неделю на сотни, потом и на тысячи.

 

! И ещё раз - предупреждайте пользователей

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

 

! Берегитесь незапланированной перезагрузки после установки обновлений

С настройками по умолчанию, когда установлены обновления, требующие перезагрузки, Windows Update Agent перезагружает компьютер в три часа ночи. На это не влияет запрет перезагрузки в настройках развёртывания (Deployment). Согласно статье KB2476479 (https://support.microsoft.com/kb/2476479), это потенциально опасное поведение Windows Update Agent можно исправить через Групповые политики - Computer configuration> Administrative Templates> Windows Components> Windows update> Configure Automatic updates - disable Automatic Updates.

 

"Пользовательское" ПО может установиться на серверы

Некоторым программам или обновлениям не место на серверах. Во многих организациях серверами занимается отдельная иерархия Configuration Manager, не связанная с "пользовательской" иерархией. Если у вас это не так, то примите меры предосторожности.

! Следите, чтобы критически важные серверы не попали в коллекции с простыми рабочими станциями.

Я видел пример, когда один из узлов NLB-кластера случайно оказался в коллекции с простыми компьютерами, на которые было нацелено очередное обновление .NET. В результате остальные узлы не смогли с ним работать, и критически важный кластер вышел из строя на долгое время. Ставьте ограничивающие правила"Только клиентская ОС" на пользовательские коллекции.

 

Проблемы VIP-пользователей или очень важных компьютеров

Известная закономерность - если при массовой установке что-то может пойти не так, это произойдёт либо на компьютере у вашего начальства, либо у руководителя более высокого ранга. У топ-менеджеров часто особенные конфигурации системы и это может привести к неожиданностям. Также, люди такого уровня часто обладают нетерпимостью к ошибкам подчинённых. Мне рассказывали о случае, когда ИТ-специалист был уволен за то, что оставил незакрытое окно с дистрибутивом на компьютере одного топ-менеджера! Что уж говорить о работе нашей системы, когда компьютер VIP-пользователя по недосмотру может внезапно перезагрузиться во время важной презентации или работы над единственным экземпляром документа?

! Создайте спец-коллекцию, они это любят

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

Добавьте в эту коллекцию такие компьютеры через Direct Rule, или придумайте какой-нибудь признак для них. В коллекциях для массовых установок добавляйте к своем правилам членства исключающее дополнение "and SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_PRI00000)" где PRI00000 нужно заменить наID коллекции с важными компьютерами - это способ для Configuration Manager 2007. 

Для ConfigMgr 2012 всё проще - прямо в свойствах коллекции есть параметр Exclude Collection.

В коллекцию с назначенным заданием могут попасть случайные компьютеры

К сожалению, во всех версиях Configuration Manager до сих пор нет какого-то механизма защиты от ошибки в правилах, или хотя бы предпросмотра результата работы этих правил. Если вы ошибаетесь в запросе, в коллекцию может попасть больше компьютеров, чем вы хотели. Туда могут попасть все компьютеры. Информация об этом уйдёт на дочерние сайты, если они есть. Для этих машин будет сформирована политика. Если за время, пока вы будете исправлять ошибку, компьютеры запросят её, то они начнут выполнять задачу этой коллекции, какая бы она ни была. Вот что можно сделать, чтобы этого не произошло.

 

! Используйте тестовые коллекции, куда ничего не назначено. Отрабатывайте новые правила на них.

! На критически важных и опасных коллекциях отключите динамическое обновление (Dynamically add new resources или Use incremental updates for this collection - зависит от версии Configuration Manager).

Это половина тех опасных сценариев, что мне удалось собрать. Остальное - во второй части статьи.