Archive for March, 2010

ACS Event Transformation Demystified

March 30, 2010 Leave a comment

I came across this blog link via Layne on the technet forums. It is excellent information on ACS:


Event 31552 – Exception ‘SqlException’: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

March 29, 2010 Leave a comment

Kevin Holman posted some great information on this on the technet forums:

Kevin Holman
This is caused by your backup process – or your own in-house SQL maintenance taking all the I/O on the warehouse, and impacting the performance of the built in housekeeping of SCOM.

This is all on the warehouse database.

You should first check your backup – and set this to only backup once per week, instead of nightly, if that is the case. You should also see where it is backing up to… and make sure it isnt backing up directly to tape (which can often take too long) or backing up to the same disk spindles that the DB resides on (this will cause more I/O contention.

Next – are you doing any in house maintenance? Such as running anything like a DBCC checkDB, Update statistics, Reindex, etc? If so – you should really not do this against the warehouse. This is all built into the product – and often SQL DBA’s just apply their “standard package” of maintenance which actually causes problems.

Look in your SQL job history – find which jobs are taking the longest – and find out why – or if you really should be running these at all.

Next – consider tuning all the stuff you are throwing in the warehouse. Look at your most common event, perf, and state changes… and fix/tune/disable the unecessary junk to reduce the load and storage impact…. thereby reducing maintenance operations.

Lastly – improve the I/O by making sure you have enough spindles in a RAID 10 database, with distinct spindles for DB and logs, to provide the necessary I/O for maintenance operations on this large database.

Decommissioned Servers still appearing in console

March 29, 2010 Leave a comment

More great information from Kevin Holman posted originally on the technet forums.

If you delete an agent via agent managed – and yet you still see a Windows Computer object for it…. then this means:

1. It hasnt groomed out yet or hasnt been marked as deleted. Wait a few days.

2. A discovery is still associated with this managed object.

To determine which discoveries are still associated with a managed object that you expect to be deleted:

To determine what discoveries are still associated with a computer – helpful in finding old stale computer objects in the console that are no longer agent managed, or desired.

select BME.FullName, DS.DiscoveryRuleID, D.DiscoveryName from typedmanagedentity TME
Join BaseManagedEntity BME ON TME.BaseManagedEntityId = BME.BaseManagedEntityId
JOIN DiscoverySourceToTypedManagedEntity DSTME ON TME.TypedManagedEntityID = DSTME.TypedManagedEntityID
JOIN DiscoverySource DS ON DS.DiscoverySourceID = DSTME.DiscoverySourceID
JOIN Discovery D ON DS.DiscoveryRuleID=D.DiscoveryID
Where BME.Fullname like ‘%ComputerName%’

change computername to yours.

Categories: SQL Queries

Security Risk of Enabling Agent proxy

March 29, 2010 Leave a comment

This was a great post by Dan Rogers on the potential security risks of enabling Agent Proxy:

Dan Rogers:
If someone can get you to import a management pack, and that management pack discovers classes and assigns them to another server, then the potiential exists that you have been duped into running a managment pack rule that you thought was safe.

It’s a subtle internal social engineering attack – so there is a warning on the enable proxy box and we took steps to make it not easy to skip that warning.

That said, nearly every management pack that is coming in the future will not function adequately or at all if proxy isn’t enabled. This is because management packs are becoming sophisticated in the way they project health states in products that inherently have multiple server roles. When a management pack creates a roll-up tree in a diagram view, it typically will need proxy enabled.

The decision to enable proxy comes with a great responsibility – that is to always be sure you TRUST with absolute certainty, the source you got that management pack from. Since the proxy-enabled attack is most likely to come from inside your company, you may want to put a process in place (like we have at MSFT) to design-check every management pack before it is ready to be used in production environments.

Maintenance Mode Process Flow

March 29, 2010 Leave a comment

Another one pulled from a post by Kevin Holman on the technet forums which explains the process of setting maintenance mode/

Kevin Holman:

You put an agent in MM which is a call to the SDK to trigger MM for an agent.

A config update is recalculated and sent to that agent.

The agent gets the config update, which has instructions to unload its workflows targeting classes that were placed into MM.

The RMS checks on a schedule for all agents that have MM expiring – and then sends a config update to the agent to stop MM at the appropriate time.

The agent loads up workflows again when MM ends.

Categories: Maintenance Mode

Cumulative Update 1 – Process flow

March 29, 2010 2 comments

I hope Kevin doesn’t mind me posting this … but this is excellent information from the forums that I think is useful to a wider audience.

Kevin Holman – From the patchlist state view – you can run a task – “Flush Healthservice cache and state” – for any *agents* that are not showing up. It possible they have something stuck in their queue… are sick, etc…

The workflow responsible for populating this is a discovery:

“Discover the list of patches installed on Agents”

It targets Health Service, and runs a script (DiscoverAgentPatches.vbs) every 6 hours. Normally – when a patch is applied – and we bounce the Healthservice – this patch data will be available almost immediately, because this discovery runs on startup. However, if there is a timing issue on that initial run, you should see the patch data on the next run of the script – which will be in 6 hours. If you dont see it after 6 hours, you likely have some issue.

It runs the following script (at the end of post) This script is very simple – it connects to the WIndows Installer scripting object – and requests the patchlist for each patch attached to the MOM agent component ID.

If your isnt working, it might just need the Healthservice bounced again, it might need the HS cache cleared on the agent…. there agent’s OS might have a more serious issue like exhausted resource, broken/disabled Windows installer service, needs a reboot, etc….

You can test this by running it manually.

Find the script by name in your HealthServiceState subdirectories – copy it out to a local directory – and run it manually from a command line:

C:\bin>cscript DiscoverAgentPatches.vbs {00000000-0000-0000-0000-000000000000} {00000000-0000-0000-0000-000000000000}

Running this manually should return a blob of XML to the command line which has CU1 in it.

The outcome of the script give you ideas on what to do.


$MPElement$ $Target/Id$ $Config/ComputerName$

‘ A script that enumerates Software Updates for MOM Agent (not MOM 2005 but higher versions)
‘ For use with Windows Scripting Host, CScript.exe or WScript.exe
‘ Copyright (c) Microsoft Corporation. All rights reserved.
‘ does NOT work agentlessly

Option Explicit

Const msiInstallStateNotUsed = -7
Const msiInstallStateBadConfig = -6
Const msiInstallStateIncomplete = -5
Const msiInstallStateSourceAbsent = -4
Const msiInstallStateInvalidArg = -2
Const msiInstallStateUnknown = -1
Const msiInstallStateBroken = 0
Const msiInstallStateAdvertised = 1
Const msiInstallStateRemoved = 1
Const msiInstallStateAbsent = 2
Const msiInstallStateLocal = 3
Const msiInstallStateSource = 4
Const msiInstallStateDefault = 5

Const momAgentComponentID = “{60ADDA03-1710-4954-B299-A9F42DD889A6}”

Dim oArgs
Set oArgs = WScript.Arguments
if oArgs.Count <> 3 Then
Wscript.Quit -1
End If

Dim SourceId, ManagedEntityId, TargetComputerID

SourceId = oArgs(0)
ManagedEntityId = oArgs(1)
TargetComputerID = oArgs(2)

Dim oAPI, oAgentPatchDiscoveryData
Set oAPI = CreateObject(“MOM.ScriptAPI”)
set oAgentPatchDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

Call DoPatchDiscovery(oAgentPatchDiscoveryData )
Call oAPI.Return(oAgentPatchDiscoveryData)

‘ Connect to Windows Installer object
Function DoPatchDiscovery(ByVal oDisc)
On Error Resume Next
Dim installer : Set installer = Nothing
Set installer = Wscript.CreateObject(“WindowsInstaller.Installer”) : CheckError

Dim product, productList, count, path, patch, patchList, patchListString, oHealthServiceinstance
On Error Resume Next
Set productList = installer.ProductsEx(“”,””,4) : CheckError

patchListString = “”
For count = 0 to (productList.Count-1)
set product = productList.Item(count)
path = installer.ComponentPath(product.ProductCode, momAgentComponentID)
If path <> “” Then
Set patchList = installer.PatchesEx(product.productCode, “”, 7, 1)
For Each patch In patchList
patchListString = patchListString & patch.PatchProperty(“DisplayName”) & “; ”
End If

Set productList = Nothing

Set oHealthServiceinstance = oDisc.CreateClassInstance(“$MPElement[Name=’SCLibrary!Microsoft.SystemCenter.HealthService’]$”)
With oHealthServiceinstance
.AddProperty “$MPElement[Name=’Windows!Microsoft.Windows.Computer’]/PrincipalName$”, TargetComputerID
.AddProperty “$MPElement[Name=’SCLibrary!Microsoft.SystemCenter.HealthService’]/PatchList$”, patchListString
End With
call oDisc.AddInstance(oHealthServiceinstance)
End Function

Sub CheckError
Dim message, errRec
If Err = 0 Then Exit Sub
message = Err.Source & ” : ” & Hex(Err) & “: ” & Err.Description
If Not installer Is Nothing Then
Set errRec = installer.LastErrorRecord
If Not errRec Is Nothing Then message = message & vbNewLine & errRec.FormatText
End If
Wscript.Echo message
Wscript.Quit 2
End Sub

Managing Gateway Servers

March 29, 2010 Leave a comment