Recently a customer requested an addition to his existing capacity report (maintained in SSRS using the OperationsManagerDW as primary datasource). In additional to general performance information he wanted to see the number of local logons that happened.
Fyi, this report is meant to pinpoint unused servers and remove them to free up resources on a development cluster. So an overview of logons per server is a good measurement of activity on each system.
I initially suggested to use Audit Collection Services to create a detailed overview of security events, but that was deemed too much of an overkill.
So I began to check my laptop’s eventlog for common events that occurred during a local logon.
I quickly found this event. It gets written each time a successful logon occurs, perfect!
So I went to SCOM’s authoring-pane and created a new event collection-rule:
|Rule Name||Succesful Logon Collector|
|Management Pack||Same as target-group MP|
|Rule Category||Event Collection|
|Rule Target||Windows computer|
Then in the Eventlog-configuration of the role, I specified these settings:
I will link the standalone MP below so you can have a look for yourself
I only enabled it for the group where all development machines resided, so the load would be minimized.
NOTE: You cannot apply a rule from one custom MP to a group of another custom MP. Either seal your group MP (not recommended as you can’t add members anymore), or store this rule together with your group-MP.
In the monitoring-pane, I created an event view that displayed all events generated from the rule.
After some time several login-events where logged successfully!
This was only step one. The next step would be to get the number of logons in a certain period and display it on the report.
So I dived into the OperationsManagerDW and found the following relationship between monitored entities and events:
So the Event.EventRule-table links Entities to Events. Ok, very straightforward! So I created the following query in SSRS:
isnull(count(ev.EventDisplayNumber),0) as ‘logons’
vManagedEntity e left outer join Event.vEventRule er
on e.ManagedEntityRowId = er.ManagedEntityRowId
left outer join
on er.EventOriginId = ev.EventOriginId and ev.EventDisplayNumber = ‘4101’ and ev.DateTime between @start and @end,
where e.ManagedEntityTypeRowId = et.ManagedEntityTypeRowId
et.ManagedEntityTypeSystemName = ‘Microsoft.Windows.Computer’
and e.ManagedEntityRowId in (select e.ManagedEntityRowId from vManagedEntity e, perf.vPerfHourly perf, vPerformanceRuleInstance pri, vPerformanceRule pr where pr.RuleRowId = pri.RuleRowId and perf.PerformanceRuleInstanceRowId = pri.PerformanceRuleInstanceRowId and perf.DateTime between @start and @end and (pr.CounterName = ‘% Processor time’ or pr.CounterName = ‘% Comitted Bytes In Use’) and e.ManagedEntityRowId = perf.ManagedEntityRowId)
and e.Name in (select DNSName from MPSCOM_OperationsManager..MTV_Computer where Management_Mode_74F79C70_9252_CB16_0F40_2B27E4F7983E not like ‘%Agentless%’)
group by e.name order by e.Name ;
This would include all machines whether they had any logon-events or not because of the outer joins. A count function would aggregate all events into a numeric value representing the times a server was accessed. I then grouped this to the servernames and voila, logon-counts per server!
I created a new dataset to prevent a overcomplex query. I made sure the returned data matched that of the other datasets. I checked for valid performance data so the returned amount of servers was identical to the performancedata-dataset. Otherwise unmonitored or servers would be listed as well. I also had to exclude clusters. This probably isn’t necessary if you scope the rule to a more specific target than Windows Computer (eg Windows Operating System).
Eventually I got this output, very sleek!
If you want to checkout this MP, here you go!