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/

Powershell — импорт сертификата


По просьбе коллеги публикую скрипт импорта сертификата, который работает на Powershell 2.0 и выше (по идее и на 1.0, но не проверял). Автоматизация обслуживания пользовательских систем требует запуска множества скриптов с помощью SCCM, но к сожалению не все системы возможно обновить до современных версий. В результате приходится писать скрипты, которые работают не только на Powershell 5, но и на Powershell 2.0 (Windows XP), что влечет за собой отказ от расширенных возможностей более новых версий Powershell.

function Import-PfxCertificate {
param([String]$certPath,[String]$certRootStore = "CurrentUser",[String]$certStore = "My",$pfxPass = (ConvertTo-SecureString -String "7Gg2Vq4Hd" -Force -AsPlainText))</pre>
$pfx = new-object System.Security.Cryptography.X509Certificates.X509Certificate2

#if ($pfxPass -eq $null) {$pfxPass = read-host "Enter the pfx password" -assecurestring}

$pfx.import($certPath,$pfxPass,"Exportable,PersistKeySet")

$store = new-object System.Security.Cryptography.X509Certificates.X509Store($certStore,$certRootStore)
$store.open("MaxAllowed")
$store.add($pfx)
$store.close()
}
Import-PfxCertificate "$((Get-Location).Path)\cert.pfx"

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

Как извлечь учетные данные из Sharepoint Secure Store


Переносил на днях базу данных используемую в External Type на сайте Sharepoint, и потребовалось уточнить от имени какой учётной записи производится доступ к базе данных. Всю цепочку настроек можно посмотреть через сайт управления кроме используемой учётной записи.

Нашелся вот такой простой скриптик, который выводит все Secure Store Target Application Id и соответствующие им логины и пароли:


$SecureStoreProvider=[Microsoft.Office.SecureStoreService.Server.SecureStoreProviderFactory]::Create()
$site = Get-SPSite -Identity $(Get-SPWebApplication -IncludeCentralAdministration | ?{ $_.IsAdministrationWebApplication}).Url
$SecureStoreProvider.Context = Get-SPServiceContext -Site ($site)
$SecureStoreProvider.GetTargetApplications() |  ForEach-Object {
Write-Host $_.Name
try {
$SecureStoreProvider.GetCredentials($_.ApplicationId) | ForEach-Object {
$Credential = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($_.Credential))
Write-Host "`t$($_.CredentialType): $($Credential)"
}
} catch  {
Write-Host "`t$($_)"  -ForegroundColor yellow
}
}
<div class="container">
<div class="line number1 index0 alt2"><code class="powershell plain"> </code></div>
</div>

Скрипт взят отсюда https://sharepointobservations.wordpress.com/2015/02/05/retrievingrecovering-secure-store-credentials/