Find out the running or failed Rules and Monitor on an agent computer

If you want to find any failed or running Rules and Monitor on an agent computer, specially, if you create or modify any Rules and Monitor and you want to find out if the agent is actually running the Rules and Monitor, follow this procedure:

1. On the SCOM 2007 R2 console, in the Monitoring view, expend Operations Manager > Agent and Select Agent Health State.

2. In the Agent Health State view select the desire server that the Rules and Monitor should be running on, from the Agent State table.

3. In the available Actions Task pane on the right side of the console (if the Actions pane is missing, click the Action button on the second top menu items). Click either Show Failed Rules and Monitors for this Health Service or Show Running Rules and Monitors for this Health Service.

4. In either opened Run Task dialog box, if the Action Account on that specific server doesn’t have the required privilege to run the task, enter the appropriate account and password and Click Run

5. After few moments, you will get the result on the Task Status window.

Create SCOM 2007 R2 monitor to alert on DFS-R backlog monitoring

By default, SCOM2007 R2, DFS-R backlog monitoring count of Windows File Service Management Pack does not notify or raise any alert in case of backlog more than a defined threshold. However, it has state view dashboard where anyone can find the current number of backlog files (provided that the data is current, default configuration is to gather data in every 4 hours). Anyone can create a Timed Script Three/Two State Monitor to get alert if there are more than specific numbers of backlog.

I am going to demonstrate a Timed Script Three State Monitor to configure alert notification of DFS-R backlog.

1.       Go to the Authoring tab on the OpsMgr console

2.       Right click Monitors under Management pack Objects and Select Create a Monitor > Unit Monitor

3.       Expend Scripting > Generic > Select either Timed Script Three State Monitor or Timed Script Two State Monitor. For the purpose of this blog, I am selecting Timed Script Three State Monitor

4.       Select the Management Pack to store this monitor. I will recommend not to using the default Management Pack. The best choice is to select the File Server Customized Management Pack. Select Next

5.       Enter a Name and description to uniquely identify the Monitor. As an example I enter: Name: DFS-R Backlog Count Monitor, description: This will monitor and raise notification in the event of the DFS-R backlog count above the threshold.

6.       Select Replication Connection  as Monitor Target

7.       Leave the default Availability as Parents Monitor

8.       Leave the Monitor is enabled as selected. Click Next

9.       Select 60 Minutes for the Monitor to run the script. Click Next

10.   Enter a name for the Script, (e.g. DFS-RBacklogMonitor.vbs)

11.   Copy and paste the following line in the Script section:

Set oArgs = WScript.Arguments
numbers=oArgs(0)
Dim oAPI, oBag
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = OAPI.CreatePropertyBag()
Call oBag.AddValue("BackLogCountFile",numbers)
Call oAPI.Return(oBag)

12.   Click Parameters….., click Target, select Backlog Count. Click OK

13.   Click OK

14.   Click Next

15.   On the Unhealthy Event Expression page: Enter, Property[@Name='BackLogCountFile'] in the Parameter Name Box, Select Greater than from the Operator option and then enter any number you want to specify the for the unhealthy state, I select 500 as an example. Click Next

16.   On the Degraded Event Expression: Enter, Property[@Name='BackLogCountFile'] in the Parameter Name Box, Select Greater than or equal to from the Operator option and then enter 100. Then click Insert and select AND Group. Then Enter, Property[@Name='BackLogCountFile'] in the Parameter Name Box again, Select Less than or equal to from the Operator option and then enter 500. Click Next

17.   On the Healthy Event Expression: Enter, Property[@Name='BackLogCountFile'] in the Parameter Name Box, Select Greater than or equal to from the Operator option and then enter 0. Then click Insert and select AND Group. Then Enter, Property[@Name='BackLogCountFile'] in the Parameter Name Box again, Select Less than or equal to rom the Operator option and then enter 100. Click Next. Click Next.

18.   Select Generate alerts for this monitor, select Automatically resolve the alert when the monitor returns to a healthy state. Enter a Name for the alert and click on … button and select the required fields you want to be on the alert body. Here is what I selected:

Replication Group: $Target/Property[Type="Windows1!Microsoft.Windows.FileServer.DFSR.ReplicationConnection"]/ReplicationGroupName$

Replicated Folder: $Target/Property[Type="Windows1!Microsoft.Windows.FileServer.DFSR.ReplicationConnection"]/ReplicatedFolderName$

Sending Member: $Target/Property[Type="Windows1!Microsoft.Windows.FileServer.DFSR.ReplicationConnection"]/SendingMemberName$

Receiving Member: $Target/Property[Type="Windows1!Microsoft.Windows.FileServer.DFSR.ReplicationConnection"]/ReceivingMemberName$

Backlog Count: $Target/Property[Type="Windows1!Microsoft.Windows.FileServer.DFSR.ReplicationConnection"]/BacklogCount$

Display Name: $Target/Property[Type="System!System.Entity"]/DisplayName$

            Select appropriate Priority and Severity.

       19. Click Create

The number used above are for indication only, you can use any number as threshold based your situation and DFS setup.

Changing SCOM 2007 R2 ACS Data Retention Period

Came across the situation where DBA team was reluctant this morning to change the database field related to ACS database retention period settings without formal lengthy official procedure. As OpsMgr Admin, I have only read-only permission on the ACS database; I couldn’t just update the field, which is good though.

After some researches on the web, from TechNet article: Managing Audit Collection Services in Operations manager 2007, found there is no option available in the OpsMgr console to control the ACS data retention period setting. The only work around is to update the database field directly. Even though, it mentioned on TechNet and other ACS deployment documents, default ACS data-retention period is set to 14, but I found it set as 2 in all my default installations, without any changes done by me during setup. So, I had to update that to 14. ACS keeps each day’s security events in separate tables called partition. ID =6 row of dtConFig table in the ACS database holds the settings corresponding to number of partitions or day’s events database will keep. Default as per the TechNet is 14 days. This means that every days, all database partitions (and their data) that are older than 14 days are dropped or deleted. The official procedure of changing the retention period for the ACS data is:

1. Log on to the computer running SQL Server that hosts the ACS database with an account that has administrative rights to the ACS database.

2. Open the SQL Server Management Studio tool, and connect to the database engine.

3. Expand the Databases folder, and select the OperationsManagerAC database.

4. Right-click to open the context menu and select New Query….

5. Run the following command to the current retention period: Select * from dtConfig

6. update the value, in the Query pane, type the following, where number of days to retain data + 1 equals the number of days you want to pass before data that has aged past that point is deleted. For example, if you want to retain data for 14 days, type 15

USE OperationsManagerAC UPDATE dtConfig SET Value = WHERE Id = 6 and then click the Execute button on the toolbar. This runs the query and then opens the Messages pane, which should read (1 row(s) affected).

7. To view the new setting, delete the previous query text from the Query pane and type SELECT * FROM dtConfig. This opens the Results pane below the Query pane.

8. Look at the value in the sixth row; it should now equal the value you entered for .

8. Restart the Operations Manager Audit Collection Service for this to take effect.

However, as DBA doesn’t ready to change retention period, instantly for me, I started looking alternative way to accomplish this, eureka, there it is, which is almost not mentioned anywhere:

Each Collector has AdtAdmin.exe command to configure ACS related settings and options. This AdtAdmin command is mainly use to define the filter to collect the security events. However, 2 parameters of this command are: -getpartitions and -setpartitions. Which are to show and manipulate the partition settings of the ACS database. –getpartitions is to get the current number of partitions settings and the –setpartitions is to update the desire value on the database according to retention period. The procedure to update the period using the –setpartitions is:

1. Log on to the collector server

2. Open the command prompt (if Windows 2008 or 2008 R2, open with elevated access)

3. Browse to %systemroot%\System32\Security\AdtServer

4. Type the following command:

AdtAdmin.exe –getpartitions

This will show the current number of partitions settings from database

5. Type the following command to update the database:

AdtAdmin –setPartitions –value: (e.g: AdtAdmin –setPartitions –value:14)

6. Type the following command again:

Adtadmin.exe –getpartitions

This will show the updated value

7. Restart “Operations Manager Audit Collection Service (AdtServer)” service on the collector for this to take effect

Finally, I was able to update the ACS database retention period without the direct SQL Server access privilege and bypassing DBA.