OM: Windows Server Management Pack Mounted Point Bug

Внимание! В статье описана проблема, возникающая в пакетах управления Microsoft Windows Server 6.0.7292.0.

Буквально на днях обнаружил очень неприятный баг – в консоли SCOM по непонятной мне причине начали отображаться по два инстанса для каждого диска. Единственное, что их отличало друг от друга это наличие обратного слэша и описание устройства,- Logical Fixed Disk и Mounted Disk.

Logical Disc Bug

Это могло быть только одно – некорректно написанное правило обнаружения, возвращающее в качестве ключевого свойства DeviceID букву диска с обратным слешом. Итак, теперь нужно разобраться, что же это за правило.

Первое, что я сделал – это отобрал все инстансы класса Microsoft.Windows.LogicalDisk с обратным слэшом через PowerShell:

$baddisk = get-scomclass -name "Microsoft.Windows.LogicalDisk" | Get-SCOMClassInstance | ? {$_.DisplayName -match "\\$"}

Затем, берем любой элемент из массива, например, самый первый и смотрим его ID:

$baddisk[0].Id

В моем случае ID элемента «533a2b61-8852-d031-523a-76fb9a8d0ec3».

Дальше необходимо получить ID правила обнаружения, которое создало этот инстанс. Делаем это через SQL запрос в оперативной базе данных:

SELECT ds.DiscoveryRuleId
FROM [OperationsManager].[dbo].[DiscoverySourceToTypedManagedEntity] dstme
INNER JOIN [OperationsManager].[dbo].[DiscoverySource] ds
ON dstme.DiscoverySourceId = ds.DiscoverySourceId
WHERE dstme.TypedManagedEntityId = '533a2b61-8852-d031-523a-76fb9a8d0ec3'

Мой запрос выдал мне ID «0EBF5558-248D-0B05-51D1-27A126C8E994»

Возвращаемся в PowerShell и смотрим, что это за правило обнаружения:

PowerShell Discovery

Видим, что это правило обнаружения «Microsoft.Windows.Server.2008.MountPoint.Discovery»(Mount Point Discovery Rule). Дальше экспортируем пакет с помощью команды (в моем примере пакет будет экспортирован в корень диска C:):

Get-SCOMManagementPack -Name "Microsoft.Windows.Server.2008.Discovery" | Export-SCOMManagementPack -Path C:\

Открываем его и ищем правило с именем «Microsoft.Windows.Server.2008.MountPoint.Discovery»:

Discovery Rule

Видим, что в качестве источника для данного правила обнаружения используется Data Source модуль с именем «Microsoft.Windows.Server.2008.MountPointDiscovery.ModuleType». Находим его:

Data Source

Содержимое данного модуля – скрипт. Самое интересное находится внизу скрипта. Видим, что данный скрипт опрашивает класс WMI Win32_MountPoint, и выполняет запрос для каждой директории, сравнивая имя директории с именем буквы диска класса Win32_Volume, значения которого записываются в выходные данные обнаружения. НО! Как я уже писал выше, как раз этим скриптом и создаются неверные инстансы дисков – возвращается DeviceID, равное имени буквы диска с обратным слэшом. Если мы опросим класс WMI Win32_Volume и посмотрим скрипт, то увидим, что в строках возвращаются значения Name, которые являются буквой со слэшом.

Data Source Script

Что в данной ситуации нужно сделать? Необходимо создать переопределение (Override) для правила обнаружения «Mount Point Discovery Rule» — переключить флаг «Enabled» в «false» и выполнить команду Remove-SCOMDisabledClassInstance. На данный момент пока нет каких либо хотфиксов как, например, делает это Алексей Журавлев, а сам я его не пишу, т.к. не знаю, что в действительности должно возвращаться, поэтому нужно ждать, пока разработчики исправят эту досадную ошибку.

Реклама

CM: Известные ошибки Configuration Manager 2012 R2

Продукт вышел относительно недавно, но ряд пользователей уже столкнулся с ошибками в ConfigMgr 2012 R2. Кто-то смог их избежать, используя обходные решения, кто-то живет с ними и по сей день, а кто-то просто дальше продолжает работать с ConfigMgr 2012 Sp1. Итак, ниже приведу список ошибок:

  • Медленная загрузка внутри WinPE. Решается установкой хотфикса;
  • Сбой службы WDS, установленной на сайт-сервере. Решается установкой хотфикса;
  • Отсутствие кнопки Uninstall в приложениях с двумя и более Deployment Type. Решения нет. Решается установкой CU1;
  • Не работают переменные последовательностей задач, назначенные на устройство. Есть скрипт, который можно запросить у Microsoft. Данный скрипт забирает данные напрямую из БД и создает локальные переменные. Решается установкой хотфикса;
  • Установка клиента может вызвать перезагрузку операционной системы. Решения нет, подробнее можно прочитать тут;
  • После обновления могут создаться копии стандартных отчетов, начинающиеся с двух нижних подчеркиваний «__». Если вы не вносили собственные изменения в данные отчеты, то их можно удалить;
  • Созданные условия для приложений могут не работать после обновления. Решение довольно простое — необходимо внести какое нибудь изменение (например, комментарий), чтобы пересоздать условие;
  • Невозможно обновить ConfigMgr 2012 Sp1 CU2+ до ConfigMgr 2012 R2 если используется Pull Distribution Point. Поддерживаемого решения пока нет, подробнее можно прочитать тут;
  • После обновления могут перестать работать отчеты. Подробнее об ошибке и обходном решении можно прочитать тут;
  • После обновления учетная запись Network Access Account пропадает. Связано это с тем, что в ConfigMgr 2012 R2 можно использовать несколько Network Access Account. Необходимо просто пересоздать учетную запись.
  • Offline обновление образов ОС в ConfigMgr 2012 R2 может занять бОльше времени, чем ConfigMgr 2012 Sp1. Связано это с долгим копированием образа в папку локального диска сайт-сервера.
  • Окна обслуживания, использующие время по Гринвичу, не переходят на следующие сутки. Подробнее можно прочитать тут.

См. также:

Подробнее о планировании обновления ConfigMgr 2012 Sp1 до ConfigMgr 2012 R2 можно прочитать тут — http://technet.microsoft.com/en-us/library/jj822981.aspx.

CM: Установка CU3 для ConfigMgr 2012 SP1 может вызвать проблемы

Cumulative Update 3 для ConfigMgr 2012 SP1 вышел совсем недавно, но многие его уже планируют установить, ведь именно это обновление официально поддерживает недавно вышедшие Windows Server 2012 R2 и Windows 8.1. Так вот, сразу хочу предупредить, что в некоторых случаях, после установки обновления, на SQL сервере может возникнуть примерно такая ошибка:

Msg 6502, Level 16, State 7, Line 2
CREATE ASSEMBLY failed because it could not read from the physical file ‘[[SMS_ROOT]]\bin\x64\MessageHandlerService.dll’: 50(The request is not supported.).
Msg 6528, Level 16, State 1, Procedure fnCompressData, Line 10
Assembly ‘MessageHandlerService’ was not found in the SQL catalog of database ‘CM_000’.

Данная проблема связана с изменением хранимых процедур CLR SQL сервера. Если Вы столкнулись с данной проблемой, то исправляется она следующим образом:

  • Если у Вас роль баз данных и роль сайт-сервера расположены на одном сервере то необходимо:
    • Запустить SQL Server Management Studio и открыть файл update.sql, который расположен на сайт-сервере. Путь по-умолчанию до него выглядит так — «C:\Program Files\Microsoft Configuration Manager\hotfix\KB2882125\update.sql»;
    • В Management Studio исправить запись вида [[SMS_ROOT]]\bin\x64\MessageHandlerService.dll на полный путь до файла MessageHandlerService.dll. По-умолчанию путь до данного файла выглядит так — «C:\Program Files\Microsoft Configuration Manager\bin\x64\MessageHandlerService.dll»;
    • Выполните данный скрипт. Перед выполнением не забудьте выбрать правильную базу данных.
  • Если у Вас роль базы данных и роль сайт-сервера расположены на разных серверах:
    • Необходимо скопировать с сайт-сервера файл MessageHandlerService.dll на сервер баз данных во временную папку, например в папку C:\Temp;
    • Запустить SQL Server Management Studio и открыть файл update.sql, который расположен на сайт-сервере. Путь по-умолчанию до него выглядит так — «C:\Program Files\Microsoft Configuration Manager\hotfix\KB2882125\update.sql»;
    • В Management Studio исправить запись вида [[SMS_ROOT]]\bin\x64\MessageHandlerService.dll на полный путь до файла MessageHandlerService.dll, т.е. на тот, по которому был скопирован файл MessageHandlerService.dll — «C:\Temp\MessageHandlerService.dll»;
    • Выполните данный скрипт. Перед выполнением не забудьте выбрать правильную базу данных;
    • После выполнения sql скрипта папку Temp на сервере баз данных можно удалить.

P.S.: Сотрудники Майкрософт уже написали небольшую публикацию о данной проблеме и способе её устранения. Описанный способ абсолютно идентичен — http://blogs.technet.com/b/configmgrteam/archive/2013/09/27/now-available-cu3-for-system-center-2012-configmgr-sp1.aspx.

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: Установка KB2840628 может вызвать сбой в инфраструктуре ConfigMgr

В общем-то название статьи говорит само за себя. Сбой наблюдается как на Configuration Manager 2007, так и на 2012. Удаление обновления KB2840628 решает проблему, но всё же это крайняя мера. Уже есть несколько обходных решений, которые описаны здесь — http://myitforum.com/myitforumwp/2013/07/13/cm-issues-with-ms13-052-kb2840628.

CM: После установки Cumulative Update 2 установка Secondary Site завершается ошибкой

На форуме появилось большое количество людей, которое столкнулось с проблемой после установки CU2 для ConfigMgr 2012 SP1. После установки данного обновления установка Secondary Site завершается ошибкой. Разработчикам уже известно об ошибке. Есть уже workaround, но пока рано говорить о его работоспособности. Так что, если Вы используете Secondary Site, то лучше дождаться исправления или официальной статьи базы знаний, где будет описана процедура решения данной проблемы.
P.S.: Появилась запись в официальном блоге разработчиков о данной проблеме

CM: Вышла новая версия *nix клиентов Configuration Manager 2012

Для System Center 2012 — Configuration Manager 2012 Service Pack 1 были выпущены новые *nix-клиенты с версией 1.0.0.4014. В данных клиентах исправлена ошибка с инвентаризацией. Ранее, при получении клиентом политики инвентаризации клиент переходил в неактивное состояние, а в лог-файле Scxcm.log можно было наблюдать запись следующего содержания:

ATTEMPT TO EXECUTE A FILE SYSTEM INVENTORY CYCLE HAS BEEN TRAPPED
Для дальнейшей работоспособности клиента приходилось отключать Software Inventory.
Страница загрузки нового клиента доступна по ссылке http://www.microsoft.com/en-us/download/details.aspx?id=36212.
Статья базы знаний находится по адресу http://support.microsoft.com/kb/2813759/en-us.