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

SCCM – методы обнаружения


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

Существует несколько видов обнаружения: Windows Installer, файл, папка, реестр и скрипт.

Обнаружение типа Windows Installer

При использовании развертывания приложения типа Windows Installer или MSI для идентификации приложения используется GUID:

Этот же GUID используется для обнаружения установленного приложения:

Обнаружение типа Файл

Если приложение использует другой тип установки, а не MSI, то найти приложение на целевой системе можно проверив наличие файла и/или значений его атрибутов. Вот, например, находим файл Notepad++.exe и проверяем значение атрибута Version:

Можно также проверить размер файла, дату создания и дату изменения файла. При этом доступна проверка не только на равенство – есть ещё целый ряд операций.

Можно задать несколько вариантов обнаружения и объединить их условиями AND и OR. Например, можно одновременно проверить дату создания и размер файла.

Не забываем про возможность использования системной переменной %ProgramFiles% и опции «This file or folder is associated with a 32-bit application on 64-bit systems».

Обнаружение типа Папка

Аналогично обнаружению типа Файл. Только проверка более простая – существование, либо дата создания, либо дата изменения.

Обнаружение типа Реестр

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

Не забываем про удаление WOW6432Node в пути и использовании опции «This registry key is associated with a 32-bit application on 64-bit systems».

Обнаружение типа Скрипт

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

В том же окне создания метода обнаружения выбираем нижнюю опцию:

Нажимаем Edit:

Скрипт может быть – Powershell, VBScript или JScript.

Скрипт можно запустить как 32-битный процесс «Run script as 32-bit process on 64-bit clients»

Пример. «Приложение», которое прописывает на компьютере пользователя кастомные классы WMI. Обнаружить их в реестре или в виде файла в общем случае не получится. Тут и пригодится обнаружение в виде скрипта.

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

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

http://blogs.technet.com/b/hhoy/archive/2012/06/09/configuration-manager-2012-application-model-part-1.aspx

SCCM – установка ПО на 32- и 64-битные системы


Решил немного пополнить свою записную книжку сведениями по SCCM и сделать несколько заметок: ничего нового – просто полезные напоминалки, как правильно делать.

Проблема

Установка ПО на системы 32-bit всегда по умолчанию производится в папку C:\Program Files. На системах 64-bit либо в папку C:\Program Files, либо в папку C:\Program Files (x86) – и вот это различие может вызвать некоторые вопросы с обнаружением ПО и его удалением. Аналогичные вопросы возникают с ветками реестра HKLM\SOFTWARE и HKLM\SOFTWARE\Wow6432Node.

Например, удаление Notepad++ с 32-битной системы C:\Program Files\Notepad++\ uninstall.exe и с 64-битной системы C:\Program Files (x86)\Notepad++\ uninstall.exe – и как это совместить?

Установщики MSI

Когда мы создаем развертывание приложения в SCCM на основе MSI, то проблем нет: обнаружение и удаление настраиваются автоматически на основе GUID установочного пакета.

Если с MSI и возникает вопрос, то только когда приложение имеет разные пакеты 32- и 64-bit – какой пакет выбрать для установки и как правильно нацелить на систему нужной битности. Второй вопрос решается двумя способами: созданием отдельных коллекций для 32- и 64-битных систем (используются для нацеливания развертывания приложения)

(пример запросов

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client

from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId

where SMS_G_System_OPERATING_SYSTEM.OSArchitecture like «%64%»

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client

from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId

where SMS_G_System_OPERATING_SYSTEM.OSArchitecture like «%32%»

)

либо заданием в самом развертывании требования:

Когда что использовать? Каждый способ имеет свои недостатки. Коллекции более универсальны и могут автоматически срабатывать для новых версий ОС. Хотя ставить автоматически ПО на новую версию ОС без проверки совместимости и явного одобрения – это не лучшая практика. С другой стороны, требования могут задаваться только для точного списка версий ОС: когда появится Windows New, то придется ручками поставить нужную галочку (но прежде пропатчить SCCM) для всех развертываний.

Другие инсталляторы. Файл.

Большинство приложений упакованы разработчиками в инсталляционные пакеты теми или иными инсталляторами. При запуске такого пакета система определяет битность приложения и выбирает целевую папку по умолчанию либо C:\Program Files (x86), либо C:\Program Files. И вот тут возникает основная проблема, описанная выше для Notepad++. К счастью SCCM предлагает простое решение: в окне настройки развертывания есть опция «This file or folder is associated with a 32-bit application on 64-bit systems».

При выборе пути к Notepad++ получаем %ProgramFiles(x86)%\Notepad++. Затем заменяем на %ProgramFiles%\Notepad++

и включаем указанную выше опцию: теперь в зависимости от битности системы будет использоваться путь либо %ProgramFiles(x86)%\Notepad++, либо %ProgramFiles%\Notepad++ автоматически!

Другие инсталляторы. Реестр

Аналогичная настройка есть для веток реестра «This registry key is associated with a 32-bit application on 64-bit systems». Ее удобно использовать для обнаружения установленного ПО. Например, в случае Notepad++ при выборе получаем SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Notepad++, удаляем WOW6432Node и получаем:

— такая конфигурация будет правильно отрабатывать и на 32-битной системе и на 64-битной.

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

  1. http://www.windowsmanagementexperts.com/sccm-2012-application-deployment-detection-methods/sccm-2012-application-deployment-detection-methods.htm
  2. http://blog.configmgrftw.com/configmgr-2012-and-32-bit-application-installers/

Automatic User Device Affinity


Попалась интересная статья How Automatic User Device Affinity Works in SCCM 2012, которая раскрывает детали работы автоматического назначения владельца устройства (Automatic User Device Affinity).

Основные моменты:

  1. Процесс Automatic User Device Affinity происходит на устройстве пользователя, результат отправляется на сервер и потом записывается в базу данных. (Поэтому не удивляйтесь, если видите в консоли affinity для устройства, которое относительно давно не включали.)
  2. На устройстве пользователя нужно включить аудит безопасности, чтобы получить события Audit account logon events и Audit logon events (входы и выходы пользователя)
  3. Если период времени для анализа (Auto affinity threshold) установлен большой, то возможно потребуется увеличить размер журнала Security для получения корректного результата. Например, если вы установили период 2 недели, а в журнале места для событий хватает только на 1 неделю, то процесс назначения владельца устройства не будет работать ожидаемым образом.
  4. Анализ событий выполняется задачей, которая запускается сервисом ccmexec service, один раз в день или при перезапуске этого сервиса. Следовательно, если вы выставили период анализа меньше суток для более быстрого применения политик, установки ПО и т.п., то помните, что потребуется перезапускать сервис ccmexec или перезагружать компьютер, чтобы это сработало.