SCCM — меняем рабочий диск для offline servicing


У SCCM есть историческая особенность – количество неведомых настроек бесконечно. Вот конкретная ситуация: сколько не выносили различные рабочие папки SCCM с диска C: на другие диски, всё равно находится хоть что-то что упорно пишет на диск C: — речь в данном случае об offline servicing установочных образов систем. Как только запустил offline servicing, SCCM тут же смонтировал образ – правильно – на диске C:. Сначала скопировал его туда с шары источника, потом смонтировал, пропатчил, отмонтировал и скопировал обратно. Но почему же на системный диск C:?! Читать далее

Одна особенность сжатия образа Windows


Последнее время плотно занимался вопросом чистки от мусора дисков на компьютерах пользователей. Наткнулся на интересную особенность:

если выполнить команду над образом после sysprep

DISM /image:<path to image> /Cleanup-Image /StartComponentCleanup /ResetBase 

то образ не уменьшится, а увеличится в размере.

Поэтому не пытайтесь сжать «сиспрепнутый» образ! Сжимайте развернутый образ, а только потом делайте захват.

SCCM – контроль здоровья дисков


Существует немало утилит, которые показывают состояние диска по технологии S.M.A.R.T. Все они не пригодны для использования в командной строке и скриптах, и, соответственно, в SCCM. Читать далее

ESD — новая функция в SCCM


В последних предварительных версиях SCCM TP появилась новая функция — Enterprise data protection (EDP).

Приятно, что функция доступна не только в Облаке, но в локальных версиях SCCM.

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

SCCM – новое обозначение версий


Майкрософт поменял обозначение версий SCCM в сентябре 2015 года. После этого сходу нелегко понять что есть что.

  1. Теперь есть две основные линейки Current branch и Technical Preview.
  2. В каждой линейке обновления нумеруются по году и месяцу выхода: CB 1511, 1601 и т.д. TP 1511, 1601 и т.д. Никакой маркировки RTM или по полному году (SCCM 2012) теперь нет.
  3. В каждой линейке обновления свои и линейки не пересекаются: нельзя преобразовать CB в TP и наоборот.
  4. Внутренняя нумерация продолжается как и раньше (например, для 1511 это 5.0.8325.1000) и для TP нет никакой особой маркировки в номере.
  5. В каждой линейке есть base line версия – версия которую можно использовать для установки с нуля, upgrade SCCM 2012 и на которую можно накатывать последующие обновления через консоль.
  6. Первая базовая версия TP была с номером 1511. Сейчас 1603. Видимо через полгода появится следующая базовая версия. Базовая версия CB 1511 на текущий день.
  7. Новые наработки появляются в версии Technical Preview, затем в последующих обновлениях они переносятся в Current branch.
  8. Триальный период версии Technical Preview – 60 дней, а базовой 90 дней. После этого периода установка очередного обновления обязательна.
  9. Technical Preview ограничена установкой 10 клиентов, нет поддержки сайтов – предназначена только для небольшой тестовой среды.

Полезные ссылки:

Updates for System Center Configuration Manager

https://buildnumbers.wordpress.com/sccm/

SCCM,Application,Powershell – software restriction policy


Все начиналось с простого: потребовалось раскатать на пользователей сертификат. С помощью групповых политик на пользователей можно распространить только корневые сертификаты. Этот вариант отпал. Т.к. под раздачу попадали древние компьютеры с Windows XP, то пришлось протестировать несколько других различных способов. Оказалось, например, что certutil на разных версиях ОС имеет разные наборы ключей, и от этого варианта пришлось отказаться. Powershell подошел, но с оговоркой – пришлось тестировать под версией 2, которая работает на Windows XP. После танцев с бубном (как беден Powershell стрых версий!) скрипт был отлажен на тестовой машине. Для его исполнения решили использовать SCCM. Сделали приложение, сделали распространение на коллекцию пользователей и … началось – мониторинг закраснел ошибками выполнения скрипта. Читать далее

SCCM – требования (requirements) при развертывании приложений


При развертывании приложений SCCM сначала выполняет обнаружение приложения. Если приложение не обнаружено, то вычисляются требования (requirements) заданные в настройках развертывания.

Разработчик написавший код создания требований был явно в ударе: количество вариантов и их комбинаций просто поражает.

Есть три стандартные категории:

user – проверка только Primary Device

Device – несколько типовых проверок: ОС, язык ОС, память, число процессоров, размер диска, сайт AD, сайт SCCM, OU в AD и т.д.

Custom – этот вариант предлагает неограниченные возможности. Вы можете создать свою проверку на основе одно из стандартных типов проверок. Кастомные требования могут включать друг друга. Например, вы можете создать проверку установленного обновления и включить его в другую проверку наличия целого набора обновлений. Когда эти требования будут проверяться на клиенте, то результаты будут отражены в логах SCCM клиента.

Стандартные (предопределенные) типы проверок (Global Conditions) можно найти в консоле \Software Library\Overview\Application Management\Global Conditions. Там же будут размещаться требования созданные пользователем.

Доступные типы:

  1. Active Directory Query – обычный запрос LDAP
  2. Assembly – проверка наличия сборки в GAC
  3. File System — проверка наличия папки или файла (UNC нельзя!), могут использоваться рекурсивный поиск, а также * и ? (осторожно – может быть много результатов!), могут использоваться системные переменные, в т.ч. %USERPROFILE% (будет поиск по всем профилям!). Опция «This file or folder is associated with a 64-bit application» на 64-битных системах добавляет проверку в каталогах %windir%\system32 и «%ProgramFiles% в добавок к проверке %windir%\syswow64 и %ProgramFiles(x86)% (если файл находится в двух этих местах, то он будет обнаружен и там, и там).
  4. IIS MetaBase – Проверка свойства в метабазе IIS
  5. Registry Key – проверка наличия ключа рестра. Опция «This registry key is associated with a 64-bit application» на 64-битной системе будет проверять не только ветку syswow64, но и основную (обнвружение может произойти и там, и там одновременно)
  6. Registry Value – проверка значения ключа. См. Предыдущий пункт.
  7. Script – это может быть PowerShell, VBScript или Jscript. Анализируется возвращаемое скриптом значение. Скрипт может запускаться в контексте пользователя и как 32-битное приложение на 64-битной системе.
  8. SQL Query – выполняется запрос к базе данных. Не поддерживаются кластерные экземпляры (обходной путь – используем скрипт). Нет возможности задать учетную запись.
  9. WQL Query – запрос WMI
  10. XPath Query – поисковый запрос к XML файлу. Поиск самогофайла аналогично типу File System.

Особенности

Требования задаются для каждого типа развертывания (Deployment Type).

Требования перевычисляются каждый цикл развертывания приложений. По умолчанию каждые 7 суток. Настройка в политике

\Administration\Overview\Client Settings -> (политика) -> Software Deployment -> Schedule re-evaluation for deployments

Полезные ссылки:

http://blogs.technet.com/b/hhoy/archive/2012/07/17/configuration-manager-2012-application-model-part-2-requirements.aspx

How to Create Global Conditions in Configuration Manager