SCOM: Get Maintenance Mode History

I use this query whenever I need to investigate Maintenace Mode history for SCOM agents.

USE OperationsManagerDW
SELECT ManagedEntity.DisplayName, MaintenanceModeHistory.*
FROM ManagedEntity WITH (NOLOCK) 
INNER JOIN
MaintenanceMode ON ManagedEntity.ManagedEntityRowId = MaintenanceMode.ManagedEntityRowId 
INNER JOIN
MaintenanceModeHistory ON MaintenanceMode.MaintenanceModeRowId = MaintenanceModeHistory.MaintenanceModeRowId
where DisplayName Like '%SERVERNAME%'
order by ScheduledEndDateTime

– F

Useful SQL queries for OpsMgr DB

Here are some of the SQL scripts I usually use in case of… whatever.
Many of these must be credited to Kevin Holman

Set ALL agents to Remotely Managable

UPDATE MT_HealthService 
SET IsManuallyInstalled=0 
WHERE IsManuallyInstalled=1

Get Agents not Remotely Managable

select bme.DisplayName from MT_HealthService mths 
INNER JOIN BaseManagedEntity bme on bme.BaseManagedEntityId = mths.BaseManagedEntityId 
where IsManuallyInstalled = 1

Set Agent Remotely Managable

UPDATE MT_HealthService 
SET IsManuallyInstalled=0 
WHERE IsManuallyInstalled=1 
AND BaseManagedEntityId IN 
(select BaseManagedEntityID from BaseManagedEntity 
where BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710' 
AND DisplayName = '-- Servername Here --')

Get Unix Duplicates (Run if the *Nix agent view in console fails)

DECLARE @NeededTypeName NVARCHAR(256)
DECLARE @ManagedTypeIdForManagedEntitiesByManagedTypeAndDerived UNIQUEIDENTIFIER
SET @NeededTypeName = 'Microsoft.Unix.OperatingSystem'
SET @ManagedTypeIdForManagedEntitiesByManagedTypeAndDerived = (
SELECT ManagedTypeId
FROM ManagedType
WHERE TypeName = @NeededTypeName
)

SELECT
[ManagedEntityGenericView].[Id],
[ManagedEntityGenericView].[Name],
[ManagedEntityGenericView].[Path],
[ManagedEntityGenericView].[FullName],
[ManagedEntityGenericView].[LastModified],
[ManagedEntityGenericView].[TypedManagedEntityId],
NULL AS SourceEntityId

FROM dbo.ManagedEntityGenericView
INNER JOIN (
SELECT DISTINCT [BaseManagedEntityId]
FROM dbo.[TypedManagedEntity] TME WITH(NOLOCK)
JOIN [dbo].[DerivedManagedTypes] DT
ON DT.[DerivedTypeId] = TME.[ManagedTypeId]
WHERE
DT.[BaseTypeId] = @ManagedTypeIdForManagedEntitiesByManagedTypeAndDerived AND
TME.IsDeleted = 0
) AS ManagedTypeIdForManagedEntitiesByManagedTypeAndDerived
ON ManagedTypeIdForManagedEntitiesByManagedTypeAndDerived.[BaseManagedEntityId] = [Id]
WHERE
[IsDeleted] = 0 AND
[TypedMonitoringObjectIsDeleted] = 0 AND
[ManagedEntityGenericView].[Path] IN (
SELECT [BaseManagedEntity].[Path]
FROM [BaseManagedEntity]
GROUP BY [BaseManagedEntity].[Path]
HAVING COUNT([BaseManagedEntity].[Path]) > 1
)

ORDER BY [ManagedEntityGenericView].[Path]

Remove *NIX Duplicates

DECLARE @TypedManagedEntityId uniqueidentifier
DECLARE @LastErr INT
DECLARE @TimeGenerated DATETIME
SET @TimeGenerated = GETUTCDATE()
DECLARE EntitiesToBeRemovedCursor CURSOR LOCAL FORWARD_ONLY READ_ONLY FOR
SELECT TME.TypedManagedEntityId
FROM TypedManagedEntity TME

WHERE TME.TypedManagedEntityId IN (' ID 1 OF THE DUPLICATE SERVER ',' ID 2 OF THE DUPLICATE SERVER')
OPEN EntitiesToBeRemovedCursor
FETCH NEXT FROM EntitiesToBeRemovedCursor
INTO @TypedManagedEntityId
WHILE @@FETCH_STATUS = 0
BEGIN
BEGIN TRAN
EXEC @LastErr = [p_TypedManagedEntityDelete] @TypedManagedEntityId, @TimeGenerated

IF @LastErr <> 0
GOTO Err
COMMIT TRAN
FETCH NEXT FROM EntitiesToBeRemovedCursor
INTO @TypedManagedEntityId
END
CLOSE EntitiesToBeRemovedCursor

DEALLOCATE EntitiesToBeRemovedCursor
GOTO Done

Err:
ROLLBACK TRAN
GOTO Done
Done:
SELECT '!!! SUCCESS !!!'

Get Alerts where CustomField1 is used, and ResolutionState is 1

select  alertname, alertdescription, statesetbyuserid, resolutionstate, statesetdatetime, severity, repeatcount, ars.alertguid, customfield1
from Alert.vAlertResolutionState ars 
join alert.valert alt on ars.alertguid = alt.alertguid
join alert.valertdetail on ars.AlertGuid = vAlertDetail.AlertGuid
where ResolutionState like '1' AND customfield1 IS NOT NULL
order by statesetdatetime

Get the reason why your agent was gray

SELECT
ME.FullName,
HSO.StartDateTime AS OutageStartDateTime,
DATEDIFF (DD, hso.StartDateTime, GETDATE()) AS OutageDays,
HSO.ReasonCode,
DS.Name AS ReasonString
FROM  vManagedEntity AS ME
INNER JOIN     vHealthServiceOutage AS HSO ON HSO.ManagedEntityRowId = ME.ManagedEntityRowId
INNER JOIN     vStringResource AS SR ON HSO.ReasonCode =
REPLACE(LEFT(SR.StringResourceSystemName, LEN(SR.StringResourceSystemName)
- CHARINDEX('.', REVERSE(SR.StringResourceSystemName))), 'System.Availability.StateData.Reasons.', '')
INNER JOIN     vDisplayString AS DS ON DS.ElementGuid = SR.StringResourceGuid
WHERE (SR.StringResourceSystemName LIKE 'System.Availability.StateData.Reasons.[0-9]%')
AND DS.LanguageCode = 'ENU'
AND ME.FullName like '% SERVERNAME HERE %'
ORDER BY OutageDays

– F

SCOM Agent install fails – Returncode 1603

My entire OpsMgr environment runs SCOM 2012 R2 UR1.
Occationally I come across Windows Servers that dont have any Agents installed – or so it seems.

A couple of days ago, this happened. I came across three servers without an agent, and started the Discorvery wizard.
All servers was discovered successfully, and I stared to push agents to them.
After a minute, they all failed, and the AgentInstall.log file on the Management Server returned with this funny little fucker.

————

MSI (s) (94:44) [11:41:02:856]: Product: Microsoft Monitoring Agent — Installation operation failed.

MSI (s) (94:44) [11:41:02:856]: Windows Installer installed the product. Product Name: Microsoft Monitoring Agent. Product Version: 7.1.10184.0. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 1603.

MSI (s) (94:44) [11:41:02:872]: Deferring clean up of packages/files, if any exist
MSI (s) (94:44) [11:41:02:872]: MainEngineThread is returning 1603
MSI (s) (94:64) [11:41:02:872]: No System Restore sequence number for this installation.
=== Logging stopped: 9/19/2014 11:41:02 ===
MSI (s) (94:64) [11:41:02:872]: User policy value ‘DisableRollback’ is 0
MSI (s) (94:64) [11:41:02:872]: Machine policy value ‘DisableRollback’ is 0
MSI (s) (94:64) [11:41:02:872]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerRollbackScripts 3: 2
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerRollbackScripts 3: 2
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerInProgress 3: 2
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerInProgress 3: 2
MSI (s) (94:64) [11:41:02:872]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (94:64) [11:41:02:872]: Restoring environment variables
MSI (s) (94:64) [11:41:02:872]: Destroying RemoteAPI object.
MSI (s) (94:2C) [11:41:02:872]: Custom Action Manager thread ending.
MSI (c) (4C:68) [11:41:02:872]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (4C:68) [11:41:02:872]: MainEngineThread is returning 1603
=== Verbose logging stopped: 9/19/2014 11:41:02 ===

————

Turns out there was an old SCOM 2007 agent installed on all of them.
Apparently, while upgrading our environment from 2007 R5 til 2012 SP1, we missed these servers.
As the SCOM DB server and management group was created from scratch, we did not receive any events on servers trying to connect to the management group with an old OpsMgr Agent.

After manually uninstalling the 2007 agents, the 2012 agents was pushed successfully from the SCOM console.

Lesson learned.

– F