При использовании System Center 2012 R2 Data Protection Manager (DPM) в качестве инструмента для резервного копирования фермы SharePoint Server 2013 реализуются такие преимущества, как например Item-Level Recovery, когда при необходимости можно достаточно оперативно выполнить восстановление отдельного элемента списка SharePoint или какого-либо документа из библиотеки документов SharePoint. Однако, как я понимаю, для сценариев Disaster Recovery может оказаться более полезным наличие полной резервной копии фермы SharePoint, сделанной средствами самого SharePoint. В качестве исходного материала для размышлений о преимуществах и недостатках разных методов резервного копирования данных SharePoint можно взять например слайды samhassani.com - Slide deck for "SharePoint 2013 Backup and Recovery with DPM 2012" from SharePoint Evolution Conference Published. Читать далее...
-
Периодическое полное резервное копирование фермы SharePoint 2013 с помощью PowerShell
-
SCCM 2012 R2 Reporting Services Point на выделенном сервере и локализация отчетов на веб-узле SQL Server Reporting Services
В последнем развертывании System Center 2012 R2 Configuration Manager (SCCM), с которым мне пришлось иметь дело, распределение ролей SCCM было организовано таким образом, что роль точки отчетности Reporting Services Point была установлена на выделенном сервере с предварительно развернутой службой SQL Server Reporting Services (SSRS). На момент добавления роли SCCM на данный сервер было выполнено автоматическое развертывание отчетов SCCM на веб-узле SSRS, после чего отчеты стали доступны а консоли SCCM и отображались на том языке, на котором работала сама консоль…
Однако при открытии URL веб-узла SSRS связанного с экземпляром SCCM было обнаружено, что все отчеты отображаются на английском языке…
В силу того, что доступ к веб-узлу SSRS использовался для тех сотрудников, которым не устанавливалась консоль SCCM, и при этом данные сотрудники могли испытывать сложности в использовании нелокализованных отчетов, - пришлось решать вопрос этой самой локализации.
-
Интеграция SCOM 2012 R2 и SCDPM 2012 R2 со сторонней системой ServiceDesk с помощью SCOrch 2012 R2
Так уж получилось что в нашей компании используется система ServiceDesk не из состава System Center (я говорю о Service Manager). Возник вопрос об интеграции этого продукта с используемыми продуктами System Center, а конкретно с System Center 2012 R2 Data Protection Manager и System Center 2012 R2 Operations Manager. Первая задача по интеграции была следующая – необходимо отслеживать инциденты, возникающие в процессе резервного копирования, и регистрировать их в системе ServiceDesk.
Первым делом были рассмотрены возможности нашей системы ServiceDesk – у нее обнаружился удобный REST API для взаимодействия. Общей шиной для взаимодействия был выбран System Center Orchestrator и именно этот выбор побудил меня написать эту статью (а может и цикл статей, посвященный Orchestrator, так как по нему не очень много статей на русском, да и вообще).
Алгоритм работы процесса такой:
1. Operations Manager собирает информацию обо всех алертах Data Protection Manager
2. Orchestrator запускает каждые два часа RunBook в котором считывает все новые алерты из Operations Manager и создает на их основе инциденты в ServiceDesk, после чего обновляет алерты вписывая им номера инцидентов (TicketID) и меняя статус (ResolutionState).
Итак, имея все исходные данные и алгоритм работы, остается только реализовать его в виде RunBook в System Center Orchestrator.
-
System Center 2012 R2 Configuration Manager - Import failed as \\FS\Share\DriverSources\* is a Reparse Point that SMS does not support via downloads - 0x80004005
В очередном развёртывании System Center 2012 R2 Configuration Manager (SCCM) при попытке добавления драйвера, исходные файлы которого размещены на файловом кластере на Windows Server 2012 R2 (на томе с включенной дедупликацией файлов) в пакет драйверов получили ошибку…
При этом на SCCM сервере в логе \SCCMServer\SMS_<site code>\Logs\DriverCatalog.log были зафиксированы ошибки обработки исходных файлов добавляемого драйвера, говорящие о невозможности обработать эти файлы
CreateFromINF("\\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662", "HDXSRSL.INF") DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC) HashFile failed as \\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662\alcmtr.exe is a Reparse Point that SMS does not support via downloads, -1 DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC…) … Import failed as \\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662\* is a Reparse Point that SMS does not support via downloads. DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC) Failed to build driver content information for "\\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662". Code 0x80004005 DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC)
Судя по содержимому ошибок, в данной ситуации SCCM не в состоянии обработать файлы расположенные на дисковом томе, подверженном дедупликации.
-
SCOM 2012 R2 & Exchange Server 2010 Monitoring Management Pack
Настраивая новую инфраструктуру System Center 2012 R2 Operations Manager (SCOM) и устанавливая пакеты управления Management Pack (MP) в очередной раз пришлось вспоминать подводные камни Exchange Server 2010 Monitoring Management Pack.
Как уже давно известно, основная проблема этого MP заключается в том, что служба корреляции Microsoft Exchange Monitoring Correlation, которая добавляется на сервер SCOM в процессе распаковки/установки MP, имеет зависимость от роли RMS, которая имела место быть в SCOM 2007 R2. Начиная с SC 2012 архитектура OM значительно переработана, и роль RMS осталась лишь в виде эмуляции (RMS Emulator) в целях совместимости со старыми MP.
Учитывая то, что Exchange Server 2010 ещё много где в обиходе, а развитие соответствующего MP уже перестало “идти в ногу” с развитием System Center, решил написать маленькую шпаргалку о том, как подружить этот MP с новой версией SCOM.
-
Проверка GSM-устройства подключенного через виртуальный COM-порт с помощью простых AT-команд (отсылка SMS-сообщения).
Ранее мы рассмотрели процесс настройки SMS-оповещений в System Center 2012 Operations Manager (SCOM), в котором в качестве примера рассматривалось подключение устройства Siemens MC35i Terminal в виртуальный сервер SCOM через транслирующее устройство Moxa NPort . Однако “за кадром” остался процесс проверки работы подключенного GSM-устройства до того момента, как его можно начать использовать в SCOM. Как минимум нам может понадобится предварительно проверить работоспособность SIM-карты и возможность отсылки SMS-сообщений устройством через подключенного оператора связи. В этом примере будет рассмотрено всё то же GSM-устройство Siemens MC35i Terminal, которое предварительно подключено к виртуальному серверу SCOM через виртуальный COM-порт, транслируемый в ОС с помощью железки Moxa NPort 5610 8-Port RS-232 Device Server. Как и в прошлом примере для настройки COM-порта используем NPort Windows Driver Manager.
-
System Center 2012 Operations Manager - Использование Global Service Monitoring
В Microsoft System Center Operations Manager, начиная с версии System Center 2012 SP1, появилась возможность контролировать доступность внешних web-ресурсов компании. Названа данная функция просто System Center Global Service Monitor (GSM). Данный сервис мониторит доступность с 15-ти точек, расположенных в разных частях света, включая одну в Москве. Одним из условий работы GSM является использование действующей подписки Software Assurance в компании. Кроме того, сервис позволяет бесплатно использовать 90 дневную пробную версию.
Рассмотрим простой пример настройки данного сервиса в рамках развернутого в компании системы мониторинга.
-
System Center 2012 R2 Configuration Manager - Очистка каталога исходных файлов обновлений Software Update Point
Перенося каталог исходных файлов обновлений Software Update Point (SUP) для System Center 2012 R2 Configuration Manager в новое месторасположение заметил, что общий размер каталога стал меньше, чем был ранее (до миграции с System Center 2012). Это обстоятельство несколько смутило, так как никакого специального обслуживания этих файлов я не выполнял, хотя помню, что в версии RTM SC 2012 CM имела место быть проблема отсутствия автоматического обслуживания исходных файлов SUP. Об этом упоминалось в заметке SCCM 2012 - Разворачиваем Software Update Point (SUP) и приводилась ссылка на статью с VBS-скриптом предложным для выполнения этой задачи. Так как применить этот скрипт на практике до сего момента не удалось, подумал, что теперь появилась хорошая возможность проделать это. Запустил скрипт на сервере первичного сайта с ролью SUP. Скрипт отработал без ошибок, отображая при этом ход обработки пакетов обновлений в виде HTML-отчета.
-
System Center 2012 R2 Operations Manager Console - Operations Manager cannot connect to the Web service - The Microsoft Management Pack Catalog Web Service cannot be contacted at this time
При попытке выполнить импорт пакетов управления Management Pack (MP) в консоли System Center 2012 R2 Operations Manager (SCOM) Console из онлайн-каталога Microsoft мы можем нарваться на ошибку, говорящую о недоступности веб-службы этого самого каталога. Такая ситуация возможна в случае, если доступ в интернет организован через прокси-сервер, как в нашем случае например через Forefront TMG 2010.
На самом деле эта проблема "с бородой" и подобная ситуация наблюдалась мной ещё со времён работы с Operations Manager 2007 R2. Однако в силу того, что практически всегда MP загружались из предварительно загруженных на локальный диск файлов с таким же предварительным изучением сопроводительной документации к MP, этой ошибке я всегда как-то не уделял внимания. Но вот настал тот момент, когда очень захотелось посмотреть доступное содержимое этого каталога через консоль SCOM.