Kevin Holman's OpsMgr Blog : Reporting

Writing reports against RAW Perf data in the Data Warehouse

kevinhol — Fri, 24 Jul 2009 22:51:25 GMT

By default – our generic reports access *aggregated* data in the warehouse… either daily or hourly. These contain information like number of data points, avg, min, max, and std. deviation data. However, sometimes users will want access to the RAW, individual data points.

This is kept in the warehouse – and you can see it in the Perf.vPerfRaw view in the DB. By default – we keep this data for 10 days, and in general – we do NOT recommend that you extend this to any longer retention.

I will add these to my mega-query list… HERE

Here are some core query examples/samples for RAW perf data – which you can use to write reports against this output:

Raw data – core query:

select top 10 *
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

More selective of “interesting” output data:

select top 10 Path, FullName, ObjectName, CounterName, InstanceName, SampleValue, DateTime
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Scoped to a ComputerName (FQDN)

Scoped to a Counter:

Scoped to a Computer and Counter:

Ordered By DateTime:

Modified DateTime relative to Central Time zone:

select top 10 Path, FullName, ObjectName, CounterName, InstanceName, SampleValue, dateadd(hh,-5,DateTime) as 'DateTime (GMT-5)'
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId
WHERE CounterName = 'Private Bytes'
AND Path = 'OMDB.OPSMGR.NET'
Order By DateTime DESC

How to get all the possible optional data to modify these queries above, in a list:

Select Distinct Path
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct Fullname
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct ObjectName
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct CounterName
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct InstanceName
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Outages and Maintenance Report

kevinhol — Thu, 11 Jun 2009 07:48:00 GMT

This is a little report I put together on request.

This report will query the data warehouse, and show all the outages, and maintenance, for objects in specific groups.

The outages look at all the “Failed to Connect to Computer” alerts, and list the start and end time of the outage, based on the time the alert was created, to the time it was closed (assumes it is auto-closed by the agent coming back online)

The maintenance looks at the times that the Health Service Watcher objects are placed into maintenance mode.

There is a start and end time parameters for the report – and the report defaults to the last 30 days.

There is a group choice parameter – you should pick a group that contains Health Service Watcher objects.

It looks like this:

It is based on this query, which you can tune to meet your needs:

declare @startdate datetime
declare @enddate datetime
declare @computergroups varchar(50)
SET @startdate = '2009-06-01 00:00:00.000'
SET @enddate = getutcdate()
set @computergroups = 'Agent Managed Computer Group'

select
apv.ParameterValue as SystemName,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) as DownDateTime,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),arsv.StateSetDateTime)) as RestoredDateTime,
adv.CustomField2 as OutageType,
adv.CustomField3 as RootCause,
adv.CustomField4 as Reason,
adv.DBLastModifiedByUserId as UserID
FROM Alert.vAlert av
JOIN Alert.vAlertDetail adv on av.AlertGuid = adv.AlertGuid
JOIN Alert.vAlertResolutionState arsv on av.AlertGuid = arsv.AlertGuid
JOIN Alert.vAlertParameter apv on av.AlertGuid = apv.AlertGuid
WHERE AlertName = 'Failed to Connect to Computer'
AND arsv.ResolutionState = '255'
--AND adv.CustomField2 IS NOT NULL
AND (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) between @startdate and @enddate
and apv.ParameterValue IN (
SELECT vManagedEntity.DisplayName
FROM vManagedEntity
INNER JOIN vRelationship ON vManagedEntity.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId
INNER JOIN vManagedEntity AS ManagedEntity_1 ON vRelationship.SourceManagedEntityRowId = ManagedEntity_1.ManagedEntityRowId
WHERE (ManagedEntity_1.DisplayName = @computergroups)
)

UNION ALL

select
vme.displayname,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.StartDateTime)) as DownDateTime,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.EndDateTime)) as RestoredDateTime,
'OutageType' =
CASE
vmm.PlannedMaintenanceInd
WHEN '1' THEN 'Scheduled'
WHEN '0' THEN 'Unscheduled'
END,
'RootCause' =
CASE
vmmh.ReasonCode
WHEN '0' THEN 'Other (Planned)'
WHEN '1' THEN 'Other (Unplanned)'
WHEN '2' THEN 'Hardware: Maintenance (Planned)'
WHEN '3' THEN 'Hardware: Maintenance (Unplanned)'
WHEN '4' THEN 'Hardware: Installation (Planned)'
WHEN '5' THEN 'Hardware: Installation (Unplanned)'
WHEN '6' THEN 'Operating System: Reconfiguration (Planned)'
WHEN '7' THEN 'Operating System: Reconfiguration (Unplanned)'
WHEN '8' THEN 'Application: Maintenance (Planned)'
WHEN '9' THEN 'Application: Maintenance (Unplanned)'
WHEN '10' THEN 'Application: Installation (Planned)'
WHEN '11' THEN 'Application: Unresponsive'
WHEN '12' THEN 'Application: Unstable'
WHEN '13' THEN 'Security Issue'
WHEN '14' THEN 'Loss of network connectivity (Unplanned)'
END,
vmmh.Comment as Reason,
vmmh.userid as UserID
from vMaintenanceMode vmm
join vManagedEntity vme on vmm.managedentityrowid = vme.managedentityrowid
join vMaintenanceModeHistory vmmh on vmm.maintenancemoderowid = vmmh.maintenancemoderowid
where vme.FullName LIKE '%HealthServiceWatcher%'
and (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.StartDateTime)) between @startdate and @enddate
and vme.displayname IN (
SELECT vManagedEntity.DisplayName
FROM vManagedEntity
INNER JOIN vRelationship ON vManagedEntity.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId
INNER JOIN vManagedEntity AS ManagedEntity_1 ON vRelationship.SourceManagedEntityRowId = ManagedEntity_1.ManagedEntityRowId
WHERE (ManagedEntity_1.DisplayName = @computergroups)
)
ORDER BY DownDateTime

The report is attached below.

Maintenance mode – tying the text of the category to the database

kevinhol — Fri, 05 Jun 2009 08:59:36 GMT

I havent seen this discussed before – so I figured I would post this.

In the OpsDB and DWDB – we keep some tables names MaintenanceMode and MaintenanceModeHistory.

When you place an object into maintenance mode – we will log a row in the database for this object. You could potentially write reports against this data in the data warehouse, and report on MM history.

From the following query:

select * from dbo.vMaintenanceModeHistory

There is a column named “ReasonCode” This has a numeric value. However – in the UI – this correlates to the “Category” that you must select when you place an object into MM:

Here is a table which sorts out the numeric reason code vs the text in the UI:

Other (Planned)	0
Other (Unplanned)	1
Hardware: Maintenance (Planned)	2
Hardware: Maintenance (Unplanned)	3
Hardware: Installation (Planned)	4
Hardware: Installation (Unplanned)	5
Operating System: Reconfiguration (Planned)	6
Operating System: Reconfiguration (Unplanned)	7
Application: Maintenance (Planned)	8
Application: Maintenance (Unplanned)	9
Application: Installation (Planned)	10
Application: Unresponsive	11
Application: Unstable	12
Security Issue	13
Loss of network connectivity (Unplanned)	14

Running reports – how can I run historical reports on agents that have been decommissioned?

kevinhol — Wed, 01 Apr 2009 18:22:54 GMT

When we delete an agent from monitoring, we do NOT delete the agent data from the Data Warehouse – by design of course.

However – when running a report, the deleted agent was not showing up. For instance – I am running the Windows Server 2003 Operating System – Operating System Performance report.

When I try and search for the old machine, “DMZDC” nothing comes up! Is the agent data gone from the warehouse?

Nope. I have to click the “Options” button, and change the search time, to a start date that would include this agent.

Now – I can run reports on the old data, that is still in the warehouse.

A cool way to use a web page view in the console - run a report!

kevinhol — Sat, 08 Nov 2008 01:14:28 GMT

Here is a unique way to use web page views in the OpsMgr console.

You can create a web page view in the Ops Console for pretty much any HTML - whether local to your hard drive - or a real web page.

When you run an SRS based report, you can drop this link into a web page view.

Here is an example:

I will use a generic report that I wrote to show all servers that are currently not pingable - that I posted HERE

This is just a simple SRS report, that runs a query and returns all servers that are currently not pingable... if you look at the URL when you run the report - it actually calls out the specific report to run:

So - lets copy this URL, and we will paste it into our new web page view, in the console.

Go to the console, and create a new managemwent pack for your custom views, or create the view in an existing MP you already have. Mine is called "Demo".

Then, create a new web page view.

Paste in the URL for the report as such:

Hit ok.

Now - this new web page view will execute this report, on demand, right from the main view of a console....

For another REALLY cool use of the web page view - check out my co-workers blog - Steve Rachui - he has written a cool maintenance mode web page, and uses this same web page view to add it to the console:

http://blogs.msdn.com/steverac/archive/2008/11/07/maintenance-mode-in-the-console.aspx

Get the maint mode website tool here:

http://blogs.msdn.com/steverac/archive/2008/10/27/enough-with-the-maintenance-mode-tools.aspx

How many consoles are connected to my RMS?

kevinhol — Mon, 27 Oct 2008 19:59:52 GMT

This discussion comes up quite a bit.

There are a couple ways to track this data.... even to alert us if it breaches a threshold.

One way to look at the number of connected consoles, is to examine the number of users that are connected to the SDK service. We can do this via powershell, and perfmon:

In powershell, this will show each connection to the SDK – whether it be a console session, or powershell session, or some other SDK connection, like managed code running:

$mgc=get-managementgroupconnection
$mgc.ManagementGroup.GetConnectedUserNames()

Here is a one liner version:

Get-ManagementGroupConnection | foreach-object {$_.ManagementGroup.getConnectedUserNames()}

If you’re looking for the actual NUMBER of users connected

Get-ManagementGroupConnection | foreach-object {$_.ManagementGroup.getConnectedUserNames()} | Measure-Object

That is great.... however, as stated, this shows SDK connections.... not specific to the console. I dont know of a way offhand to demonstrate which are true CONSOLE connections... but unless you run a lot of SDK processes like timed scripts against the SDK... most will be consoles in a typical environment.

Another way to view connections is via Perfmon. The perf object "OpsMgr SDK Service\Client Connections" and "OpsMgr SDK Service\Client Connections using cache" From what I can tell offhand, the "using cache" counter is the same as connected clients, minus the 2 default SDK connections from the service account.

We don't have a rule collecting this by default. However, you can create a collection rule, or even a performance threshold rule to alert you when this count goes above what you feel is supportable in your environment. Here is an example: (Note - Root Management Server is a good target for these rules/monitors... since it will be the only role with the SDK service running)

And the output of a monitoring view you can create:

For reporting purposes – you can see “connections” to the SDK – by writing an event collections rule for the following events, which is logged on each console session or powershell session that connects to the SDK: (this is logged on the RMS only)

Event Type:      Information
Event Source:   OpsMgr SDK Service
Event Category:            None
Event ID:          26328
Date:                10/16/2008
Time:                9:23:01 AM
User:                N/A
Computer:         OMRMS
Description:
A new client has connected.
UserName: OPSMGR\adadmin
SessionId: uuid:12e8d840-9cca-45df-b889-db39203136e0;id=15

Event Type:      Information
Event Source:   OpsMgr SDK Service
Event Category:            None
Event ID:          26329
Date:                10/16/2008
Time:                9:24:04 AM
User:                N/A
Computer:         OMRMS
Description:
A client has disconnected.
UserName: OPSMGR\adadmin
SessionId: uuid:12e8d840-9cca-45df-b889-db39203136e0;id=15

However – this won’t show you good concurrence…. just “who” is using the console…. and how often connections are made and disconnected. Since the username is a parameter..... you could potentially write reports and examine your most common console users, etc.

So - we have the ability to:

1. See "who is connected right now" - Powershell

2. Count the client connections right now - Powershell and Perfmon.

3. Collect the client count from the RMS - Perfmon rule

4. Alert when it reaches a threshold we set - Perfmon Monitor

5. Collect and report on actual user connections - Event rule and report.

Using OpsMgr to see which servers have not been logged on to via RDP

kevinhol — Thu, 04 Sep 2008 00:46:36 GMT

This came up in a discussion group.... and while it maybe not be all that interesting of a topic.... it is interesting to see the kinds of reports you can write with OpsMgr and look for unique scenarios.

The question was - "How can I run a report - and see all my servers that have NOT been logged onto via RDP in the last 30 days?"

First - we need to find out what events are logged, so we can capture which servers ARE being logged on to via RDP. If you have an audit policy that logs successfull logons, we will log an event 528 in the security event log, and the "LogonType" for a RDP logon is "10".

Here is a link which describes these logon types and what they mean: http://www.windowsecurity.com/articles/Logon-Types.html

So - we want to collect event 528.... but ONLY those events that are RDP... or logon type 10.... so we need to know which Event Parameter that logontype corresponds to, so we can write a rule which will ONLY collect these events. You can use the logparser tool I mentioned here: http://blogs.technet.com/kevinholman/archive/2008/04/22/using-event-description-as-criteria-for-a-rule.aspx

As an alternative - if you don't want to use LogParser for some crazy reason... you can create an alert generating event rule for all event 528's, and then in the alert description, simply paste the following - to show you what each parameter in an event equals:

Parameter 1: $Data/Params/Param[1]$

Parameter 2: $Data/Params/Param[2]$

Parameter 3: $Data/Params/Param[3]$

Parameter 4: $Data/Params/Param[4]$

Parameter 5: $Data/Params/Param[5]$

Parameter 6: $Data/Params/Param[6]$

Ok.... so now.... we need to write our event collection rule. It should look something like this:

At this point.... we can run a simple generic "Event Analysis" Report and look for all event 528's in the Data Warehouse in a given time period. Any servers that DONT show up.... haven't logged this event.

However, what we REALLY want is something that just shows me the list of all machines in the data warehouse that HAVE NOT generated this event.... for that, we can use a custom query:

select distinct elc.computername from Event.vEvent ev
inner join vEventLoggingComputer elc on elc.eventloggingcomputerrowid = ev.loggingcomputerrowid
where NOT eventdisplaynumber = '528'
order by elc.computername

Just paste this into a simple visual studio report, add some time/data parameters, and there you have it. In fact - lets walk through that. You can use the copy if Visual Studio that gets installed with the SQL 2005 client tools.

1. Start up visual studio.

2. File, New Project. Choose the Report Server Project Wizard:

3. Click Next to start the Report Wizard.

4. Create a new Data Source (we will swithc our report to use an existing one later)

5. Click Edit, and put in the server\instance, and then choose the data warehouse database. Choose Test Connection to make sure it's all good:

6. Click OK, then Next. Paste in your query that gives you the output you want... from the query I listed above:

7. Click Next, and Finish on Report type.

8. Type a name for the report, such as "Inactive RDP Servers" Check the box to Preview the report.

9. Click Finish. The preview comes up. This is a pretty inefficient query, so it might take some time to run in a big datawarehouse. We will need to adjust some of the column widths using a drag and drop function on the layout tab.... the initial formatting is bad. Click the Layout tab, and you can drag the column headers to make the report look good:

10. Now my report looks good.... but I need to add some date/time parameters.... Click the "Data" tab now. From the top menu, choose Report, Report Parameters. Click Add. Add a StartDate and EndDate paramter, and choose DateTime as the data type, exactly as shown:

11. Choose OK, and now when you preview your report, you will have some nice date pickers.

12. From the top menu, choose build, build report project. Then browse to your user profile, and find the RDL file we created under \Documents\VisualStudio.

13. You can take this RDL and import it into your reporting website. http://servername/Reports You should create a custom folder there for custom reports. They will automatically show up in the SCOM console.

14. Once you import this file, we need to select it in the reporting website, and update the Data Source.

15. Browse the shared data sources, and select the Data Warehouse Main. Click OK, and make sure you click APPLY on the next screen.

16. Now run your report. Pick a start and end time, and run it - here is mine:

You can repeat the above process using this wizard for any query that you want to turn into a report.

Auditing on Alerts from the Data Warehouse

kevinhol — Tue, 22 Jul 2008 00:22:00 GMT

Do you want auditing information on how many alerts are being closed or modified by your OpsMgr users?

You can use the following queries to get this information from the data warehouse, and I have attached some reports below as well:

To get all raw alert data from the data warehouse to build reports from:

select * from Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.alertguid = adt.alertguid
inner join Alert.vAlert alt on ars.alertguid = alt.alertguid

To view data on all alerts modified by a specific user:

select ars.alertguid, alertname, alertdescription, statesetbyuserid, resolutionstate, statesetdatetime, severity, priority, managedentityrowID, repeatcount
from Alert.vAlertResolutionState ars
inner join Alert.vAlert alt on ars.alertguid = alt.alertguid
where statesetbyuserid like '%username%'
order by statesetdatetime

To view a count of all alerts closed by all users:

select statesetbyuserid, count(*) as 'Number of Alerts'
from Alert.vAlertResolutionState ars
where resolutionstate = '255'
group by statesetbyuserid
order by 'Number of Alerts' DESC

In the reports I have attached, you can pick a date and a time window, and run these same basic queries

Files attached below:

The Exchange Server Configuration report doesn't return any data

kevinhol — Tue, 15 Jul 2008 21:34:00 GMT

I figured out why - and instead of just posting about the workaround... I thought I'd take a moment and post on the process I used to determine the how and the why:

When you run the "Exchange Configuration Report" per the guide, you are supposed to add objects of type "Exchange 2003 Role". Well, if you do this - the reports will never return any data.

So - to try and look at the SQL code... I went to the RDL file in the reporting website.... http://reportingservername/reports

I browsed over to the report - which I found at: Home > Microsoft.Exchange.Server.2003.Monitoring > Report.Exchange.ExchangeServerConfiguration. Select the "Properties" link.... and normally there would be an "Edit" button here... where I could download the RDL (report definition) file.... but instead - I see this is a linked report:

Aha! It is linked to: /Microsoft.SystemCenter.DataWarehouse.Report.Library/Microsoft.SystemCenter.DataWarehouse.Report.CustomConfiguration

Microsoft.SystemCenter.DataWarehouse.Report.Library is the Generic Report library.... so off I go looking for a generic report.

Found it:

So - I simply run this report.... and immediately I can see something different... I am now offered a new parameter area... called Report Fields. So, I add the Exchange 2003 Roles instance to the report as an object.... and now I can pick and choose from a whole list of discovered attribute data.... and customize the order I want it to show up in:

Here I am running the report for the same object... and now I get to pick the cool things I want to see:

Now.... if I want to run this report in the future... and add more servers, etc... I simply save it to my favorites. Then - on future runs of the report, I can drop the parameter header back down and make any changes I want.

A report to show all agents missing a specific hotfix

kevinhol — Sat, 28 Jun 2008 01:11:00 GMT

This is a continuation of my previous post on determining which agents are missing a hot-fix:

How do I know which hotfixes have been applied to which agents-

I wrote up a report that allows you to paste in a KB article number into the report as a parameter, and then it will show all agents that are potentially missing that hotfix. This will help you easily find agent which need to be patched and got missed for some reason.

You can run this report if you create the SQL reporting data source as specified in my previous post:

Creating a new data source for reporting against the Operational Database

Once imported - it will show up in the console. Open the report, and paste in any KB article number for a OpsMgr hotfix you have applied. The number MUST begin and end with "%".... such as %951380% as shown:

The report is attached below:

Which servers are DOWN in my company, and which just have a heartbeat failure, RIGHT NOW?

kevinhol — Sat, 28 Jun 2008 00:39:00 GMT

In OpsMgr 2007, when a agent experiences a heartbeat failure, several things happen. There are diagnostics, and possibly recoveries that are run. Alerts, and possibly notifications go out.

But what happens if my Operations team misses on of these alerts? What can I do to "spot check" agents with issues?

Well, any time an agent has a heartbeat failure, we gray out the state icon of the agents last known state for in each state view.

However - you CAN create a State view that will turn Red or Yellow just like any other state views. Simply create a new State View, and scope the class to Health Service Watcher (Agent).

I called mine Heartbeat State View:

This view will show us when any of the agent health service watcher monitors are unhealthy: In my case - OWA and EXCH1 have issues. OWA is DOWN, while EXCH1 agent healthservice is stopped.

However - here is the issue. This view shows us when ANY monitor rolls up unhealthy state.... this includes heartbeat failures AND computer unreachable (server IP stack is down):

What if I want a State View - to ONLY show me computers that are DOWN.... as in... not heartbeating AND not responding to any PING? Most customers consider this their "most critical situation". Well, I haven't found an easy way to do that.... so I wrote a report which handles it. This report will query the OpsDB for the state of the "Computer Not Reachable" monitor, and only display those servers. It is based on the following query:

SELECT bme.DisplayName, s.LastModified as LastModifiedUTC, dateadd(hh,-5,s.LastModified) as 'LastModifiedCST (GMT-5)'
FROM state AS s, BaseManagedEntity as bme
WHERE s.basemanagedentityid = bme.basemanagedentityid AND s.monitorid
IN (SELECT MonitorId FROM Monitor WHERE MonitorName = 'Microsoft.SystemCenter.HealthService.ComputerDown')
AND s.Healthstate = '3' AND bme.IsDeleted = '0'
ORDER BY s.Lastmodified DESC

You can import this report if you have created a data source as shown in my previous post:

http://blogs.technet.com/kevinholman/archive/2008/06/27/creating-a-new-data-source-for-reporting-against-the-operational-database.aspx

Import this report into your custom folder... and run it. You can schedule it to receive it first thing every day... if you like the output:

***** Update 6-30-08 I removed a section of the original query relating to maintenance mode. We found that if a down server had never been in maintenance mode, the server would not show up in the report. The query and report download have been updated to address this.

Report is attached below:

Agent Proxy alerts - finding the right machine to enable agent proxy on using a custom report

kevinhol — Sat, 28 Jun 2008 00:04:00 GMT

Certain types of agents need the agent proxy setting enabled. These are documented in various guides... such as Exchange Active Directory, Cluster nodes, etc...

However, sometimes, we still get alerts that Agent Proxy needs to be enabled for a HealthService. The problem is... the Alert often doesn't tell us which agent needs this enabled!!!

Here is an example alert:

The alert context tab is telling us about something called "SQLCLUSTER".... but I know that is a virtual cluster instance name... not the name of a real agent.

Marius blogged about a SQL query... that will help us find the agent that needs this turned on:

http://blogs.msdn.com/mariussutara/archive/2007/11/09/agent-proxying-alert.aspx

The sql query I like to use is:

select DisplayName, Path, basemanagedentityid from basemanagedentity where basemanagedentityid = 'guid'

Where "guid" = the GUID of the healthservice in the alert.

So in my example above - the part in bold is the GUID we need..... the HealthService that is causing the problem....

Health service ( 4F6BCCD4-2A41-1C39-DC50-5CE6CA10E0D3 ) should not generate data about this managed object ( A6D9CC33-3EF7-00BF-3E78-B368B32F1486 ).

If we drop this into the query.... it will look like so:

select DisplayName, Path, basemanagedentityid from basemanagedentity where basemanagedentityid = '4F6BCCD4-2A41-1C39-DC50-5CE6CA10E0D3'

Which when run in a SQL query returns:

DisplayName	Path	basemanagedentityid
sqlnode2.opsmgr.net	sqlnode2.opsmgr.net	4F6BCCD4-2A41-1C39-DC50-5CE6CA10E0D3

Aha! So - SQLNODE2 needs agent proxy enabled.

Well.... how instead of all this dropping to SQL.... we create a report with the query above, and have an input parameter where you can just paste in the GUID from the alert? I have created just that, and you can download it below!

Please see my previous post on creating a data source for the OpsDB here: Creating a new data source for reporting against the Operational Database You will need to do that first in order to see this report.... since it runs against the Operational Database, not the Data Warehouse.

Simply download this RDL file, then browse to your reporting website (http://reportingservername/reports) browse to your new custom folder for reports, and choose "Upload File". Your new report is uploaded, and you should be able to see it in the Ops Console under Reporting now:

Open the report. The report just needs you to paste in the healthservice GUID you saw in the Agent Proxy alert:

This should make it a bit easier and faster to tackle these types of alerts in the future.... for the few agents you are missing this setting on.

A simpler way to do this without running a report.... is to use "Discovered Inventory" in the monitoring console.

Select "Change Target Type" from the actions pane, and then choose "View All Targets" and then type "Health Service Watcher" in the "Look For" box. Select the Health Service Watcher Class and click OK.

Now paste your GUID into the "FIND" box and click OK. Make sure you dont have any trainling spaces in the GUID:

The Report download is here:

Creating a new data source for reporting against the Operational Database

kevinhol — Fri, 27 Jun 2008 23:39:30 GMT

I am going to be publishing several reports over the next few months, that query the Operational Database instead of the Data warehouse. We will use these reports for getting all sorts of administrative information... which will allow us to get data without having to launch a SQL query analyzer window all the time.

First thing... we will need to create a new Data Source for the OpsDB.

Start, by opening a web page, and browsing to http://SRSServer/Reports where "SRSServer" is the name of your reporting server.

Click "New Data source"

1. For the Name - type "OpsDB" This will be the data source that I will be using for all my reports. If you want a different name, thats fine and dandy... you will just have to modify each report to link to your data source name. Not a big deal.

2. In the "Connections String" paste in the following: data source=DBSERVER;initial catalog=OperationsManager;Integrated Security=SSPI

DBSERVER is the name of the SQL server hosting your operational database. Initial Catalog is the name of your Operational Database.

3. Under "Connect Using" choose "Credentials are not required" Click OK.

Here is my example:

All done with the data source!

Now... we need a custom folder to place our custom reports. Click New Folder:

Give this folder a name. This name will appear to all reporting users in the OpsMgr console. I am calling mine "Custom - Reports"

Click OK.

Now - in the OpsMgr Console - we can see our new report folder:

When we publish or import new reports in the future, we can use this folder.

AD Role Holders Report - how to get data

kevinhol — Thu, 26 Jun 2008 22:37:00 GMT

The "AD Role Holders" report has some incorrect description information on how to run the report. If you follow the instructions... adding the "Active Directory Domain Controller Computer Role" you will get no data returned. This will be fixed in an upcoming ADMP update... but in the meantime:

Instead - you need to add the "Forest" object as a group:

Open the report.

Select "Add Group"

Search for a domain name of the forest root.

Sort by "Type" and add the object for "Active Directory Forest"

Run the report.

This will give you the RID Master, Schema Master, and PDC Emulator role information for the forest.

When searching for objects to include in reports - the results are limited to 500 objects

kevinhol — Thu, 26 Jun 2008 00:01:52 GMT

Keep this in mind when searching for an object when creating a report. If you don't give very specific search criteria... or if you just select "Add Object" then select "Search" with no criteria.... the result set is limited to 500 objects returned. Therefore - if the object you are looking for doesn't show up - make sure you are specific enough in your search.

To demonstrate this - I created a performance report, and clicked "Add Object" then hit "Search" and then added all objects to my report.... the report builder will show use the number of objects selected on the right: