System Center 2019

Во всех доступных подписках Microsoft (VLSC, MSDN, Evaluation) стали доступны продукты линейки System Center 2019! Пробные версии продуктов можно скачать по ссылке Evaluate System Center 2019.

OM: OMS-Agent-for-Linux

https://github.com/Microsoft/OMS-Agent-for-Linux

OM: Скрипт для сброса состояния монитора

Скрипт для сброса монитора в здоровое состояние (аналогично Reset Health в Health Explorer) по критерию:

$Server = "ServerName"
$Credentials = Get-Credential
New-SCOMManagementGroupConnection -ComputerName $Server -Credential $Credentials
$ResetAlerts = Get-SCOMAlert -Criteria "IsMonitorAlert = 1 AND Name = 'Failed to Connect to Computer' AND ResolutionState < 255"
foreach ($Alert in $ResetAlerts)
{
	$MonitoringRule = Get-SCOMMonitor -Id $Alert.MonitoringRuleId
	$MonitoringObject = Get-SCOMClassInstance -Id $Alert.MonitoringObjectId
	$MonitoringObject.ResetMonitoringState($MonitoringRule)
}

OM: Docker-Provider

https://github.com/Microsoft/Docker-Provider/releases

OM: SCXCore-kits

https://github.com/Microsoft/SCXcore-kits

OM: Как закрыть активные алерты для здоровых мониторов

В Operations Manager иногда бывают ситуации, когда монитор переходит в здоровое состояние, но алерт продолжает висеть во вкладке активных алертов. В большинстве случаев это следствие ошибок оператора. Очень часто бывает, что система уже закрыла алерт, но оператор в это время заполняет поля алерта и возвращает ему прежнее состояние. Такой алерт самостоятельно уже не закроется. Чтобы не искать такие алерты вручную, можно воспользоваться следующим скриптом:

$Server = "ServerName"
$Credentials = Get-Credential
New-SCOMManagementGroupConnection -ComputerName $Server -Credential $Credentials
$ActiveAlerts = Get-SCOMAlert -Criteria "IsMonitorAlert = 1 AND ResolutionState < 255"
foreach ($Alert in $ActiveAlerts)
{
	$MonitoringRule = Get-SCOMMonitor -Id $Alert.MonitoringRuleId
	$MonitoringObject = Get-SCOMMonitoringObject -Id $Alert.MonitoringObjectId
	$MonitorList = New-Object System.Collections.Generic.List[Microsoft.EnterpriseManagement.Configuration.ManagementPackMonitor]
	$MonitorList.Add($MonitoringRule)
	$MonitoringState = $MonitoringObject.GetMonitoringStates($MonitorList)
	if ($MonitoringState.HealthState -eq [Microsoft.EnterpriseManagement.Configuration.HealthState]::Success)
	{
		$Alert
		$Alert | Resolve-SCOMAlert -Comment "The alert was manually closed because the monitor is in healthy state."
	}
}

Необходимо задать переменную $Server, указав имя сервера управления Operations Manager, после чего запустить скрипт.

OM: Обновление VSAE

Вышло обновление для Visual Studio Authoring Extention! Данное обновление позволяет создавать пакеты управления в Visual Studio 2015. Скачать дополнение можно по ссылке http://www.microsoft.com/en-us/download/details.aspx?id=30169.

SC: Update Rollup 8 for System Center 2012 R2

Новости уже 2 недели, но всё же не хотелось бы ее пропускать. Вышел восьмой по счету Update Rollup для продуктов System Center 2012 R2, которые входят в состав Cloud And Dataсenter. Список продуктов и описание к обновлению находятся на странице https://support.microsoft.com/en-us/kb/3096378.

SC: Update Rollup 7 for System Center 2012 R2

Недавно был выпущен Update для продуктов System Center 2012 R2, за исключением Operations Manager, выход обновления для него был отложен. Но сегодня и он был выпущен! Обновление Operations Manager также включает в себя обновление безопасности — Microsoft Security Bulletin MS15-086 — Important. Обновления для продуктов System Center 2012 R2 можно скачать по следующим ссылкам:

• Data Protection Manager — https://support.microsoft.com/en-us/kb/3065246
• Operations Manager — https://support.microsoft.com/en-us/kb/3064919
• Orchestrator — https://support.microsoft.com/en-us/kb/3069115
• Service Manager — https://support.microsoft.com/en-us/kb/3063263
• Virtual Machine Manager — https://support.microsoft.com/en-us/kb/3066340

 

OM: Windows Server Management Pack Mounted Point Bug

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

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

Это могло быть только одно – некорректно написанное правило обнаружения, возвращающее в качестве ключевого свойства 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 и смотрим, что это за правило обнаружения:

Видим, что это правило обнаружения «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»:

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

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

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