Archive

Archive for August, 2009

Availability Reports

August 25, 2009 Leave a comment

Steven Halsey from Microsoft provided a great explanation about why you couldn’t do group based availability reporting covering periods of time prior to the creation of the group.

“Yes this is normal behavior. When you are looking at the availability report you are not looking at the availability of the items contained in the group. You are looking at the avialability of the group object iteself. The group object gets its’ availability state by recording the changes to the objects that are contained in the group, but it only records the changes that happen after the group is created.

Before you created the group all the items in the group have availability. But the group object doesn’t exist so it doesn’t have any availability. Once you create the group object, the items in the group pass their current availability information to the group. And the group starts keeping track of its’ availability based on what the contains objects pass to it.”

Advertisements
Categories: Groups

OpsMgr Queues

August 25, 2009 Leave a comment

A good explanation came up today on the technet forums about the OpsMgr queues. The answer was provided by Hui Wang:

1: OpsMgr uses 1 ESE DB to store all data sent from the agent, this ESE DB is called “Health Service Store” DB. It’s normally under “\Health Service State\Health Service Store”, you will see several files under this directory, all these files are for that “Health Service Store” ESE DB.
Within this ESE DB, not only queues are in it, workflows also store state in it.

2. When agent loses communication with the mangement server, “Health Service Store” will start to grow because of the Queue within it is backing up. To check the size of the queue you can check performance counter “Health Service Management Groups(*)\Send Queue % Used”” and “Health Service Management Groups(*)\Send Queue Size”.

3. Not sure I understand what do u mean by limit the growth, the queue will grow when local workflow is running and collecting data but agent is not connected to MS. Unless you disable workflow, the queue will grow untill agent is conneted to MS. There is a registry setting u can use to set the maximum queue size limit.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups\\MaximumQueueSizeKb

4. When queue is full, it will groom data according to “delete priority” and then “age” of the data in the queue, the idea is less important and old data gets groomed first.

Categories: Concepts, Queues

Database Grooming

August 24, 2009 Leave a comment

SQL Server Configuration

August 24, 2009 Leave a comment

OpsMgr database security requirements

August 11, 2009 Leave a comment

OpsMgr MS Action Account:

Server Role – Public

OperationsManager database:
Ø Db_datareader
Ø Db_datawriter
Ø Db_ddladmin
Ø Db_module_users
Ø Public

OpsMgr SDK \ Config

Server Role – Public

OperationsManager database:
Ø Db_datareader
Ø Db_datawriter
Ø Db_ddladmin
Ø Configsvc_user
Ø Dwsynch_users
Ø Sdk_Users
Ø Public

OperationsManagerDW:
Ø Db_datareader
Ø OpsMgrReader
Ø Public

OpsMgr Data Reader

Server Role – Public

Master:
Ø Public
Ø RSExecRole

MSDB:
Ø Public
Ø RSExecRole
Ø SQLAgentOperatorRole
Ø SQLAgentReaderRole
Ø SQLAgentUserRole

Operations ManagerDW:
Ø Db_datareader
Ø OpsMgrReader
Ø Public

Report Server:
Ø Db_owner
Ø Public
Ø RSExecRole

ReportServerTempDB:
Ø Db_owner
Ø Public
Ø RSExecRole

Ops Mgr Data Writer:
OperationsManager database:
Ø Db_datareader
Ø Dwsynch_users
Ø public

OperationsManagerDW:
Ø Db_owner
Ø OpsMgrWriter
Ø Public

Categories: Security

Overrides

August 2, 2009 Leave a comment

Best Practice:
http://support.microsoft.com/default.aspx/kb/943239

Cory Delamatar from Microsoft gave this excellent explanation about overrides – “Yes, this is a Best Practice. Create a new MP to store overrides for each logical grouping of MP’s. So, if you Import the three SQL 2005 MP’s, I’d create a new MP called SQL 2005 Overrides. Any Overrides you create that are targeted at SQL 2005 types, you should store them in that overrides MP you created.

The reason for this is that every time you create and save an override, that changes the MP that you stored it in. If the MP contains overrides (or anything else really) that’s targeted at something that every agent has (Windows.Computer for example) then that MP is going to get re-downloaded to every agent that has at least 1 instance of that type. So, if you save an Override for a SQL Database and store it into the Default Management Pack, that’s going to cause every agent in your environment to request a new copy
of the Default Management Pack. Now, if you were to save that SQL Database override into an MP that only has SQL Server stuff it in, then only the SQL Server agents will request a copy of that MP.

Bottom line, lots of small and highly targeted MP’s are better than the
single monolithic Default MP with every override in it.”

A poster called Rule and Monitor Targeting Best Practices is available in pdf format at:
http://go.microsoft.com/fwlink/?LinkId=125048

Probably the easiest way to list overrides is via the Override Report (part of the generic reports library). Microsoft have a training video on how to do this here:
http://www.microsoft.com/winme/0712/31678/OverrideReports_300kbps.asx

You can also user powershell:
get-managementpack | get-override | format-list name,parameter,value

You can also see the overrides in the Authoring Pane on Operations Manager 2007 R2 although the scope only really works if the override is targetted at a specific class. If it is targetted at a group then only “group” is specified, not the actual group.

Kevin Holman also posted this on the technet forums if SQL is your preferred scripting solution:

select rv.DisplayName as WorkFlowName, OverrideName, mo.Value as OverrideValue,
mt.TypeName as OverrideScope, bme.DisplayName as InstanceName, bme.Path as InstancePath,
mpv.DisplayName as ORMPName, mo.LastModified as LastModified
from ModuleOverride mo
inner join managementpackview mpv on mpv.Id = mo.ManagementPackId
inner join ruleview rv on rv.Id = mo.ParentId
inner join ManagedType mt on mt.managedtypeid = mo.TypeContext
left join BaseManagedEntity bme on bme.BaseManagedEntityId = mo.InstanceContext
Where mpv.Sealed = 0
UNION ALL
select mv.DisplayName as WorkFlowName, OverrideName, mto.Value as OverrideValue,
mt.TypeName as OverrideScope, bme.DisplayName as InstanceName, bme.Path as InstancePath,
mpv.DisplayName as ORMPName, mto.LastModified as LastModified
from MonitorOverride mto
inner join managementpackview mpv on mpv.Id = mto.ManagementPackId
inner join monitorview mv on mv.Id = mto.MonitorId
inner join ManagedType mt on mt.managedtypeid = mto.TypeContext
left join BaseManagedEntity bme on bme.BaseManagedEntityId = mto.InstanceContext
Where mpv.Sealed = 0
Order By mpv.DisplayName


In the GUI, you can only set one override at a time but Boris has released a Bulk Override Tool into the wild:
http://blogs.msdn.com/boris_yanushpolsky/archive/2007/08/04/disabling-enabling-multiple-rules-monitors-discoveries-at-once.aspx

Audit Collection Services – unusual problems

August 2, 2009 Leave a comment

The ACS Forwarder seems to have a dependency on the DNS Service – it did cause problems in one environment I was working in.

Additionally, Joseph Chan of Microsoft has stated that “At a minimum, Adtagent needs to be running as Network Service (to communicate with the collector) with SeAuditPrivilege right (to read the security event log)”