O R G A N I C / F E R T I L I Z E R: 05.05

May 27, 2005

mom reporting article published...

As promised, I posted all the MOM Reporting jive into an article on myitforum.com. Here's the link: http://myitforum.com/articles/2/view.asp?id=8639.

May 19, 2005

diggin' reporting...

I think it's time to start digging into reporting. After all, this is what MOM should be able to deliver on with promises of System Center Reporting coming down the pipe. As I've begun looking ... it turns out that ADMP AD Replication Connection Object report doesn't like to run.
I get back an error stating:
Could not allocate ancillary table for view or function resolution. The maximum number of tables in a query (256) was exceeded.
Apparently, it's resolved in SQL Server 2000 SP4. Guess I'll be loading that up soon.

May 9, 2005

more info on mom grooming

don't worry... i plan to move all this to an article at some point in the future. :)

Anyway, going through the Ops Guide, chapter 4 outlines some other things you can do with the SystemCenterReportingDB to help shape the amount of data you want to retain in MOM 2005.

Regarding the Latency switch, look for the title “Moving a Large Amount of Data using DTS Latency” around page 30. BTW, I was given a new table to query for the LastDTSRunTime timestamp. I updated my previous post to reflect it. Anyway, interesting note here that explains it all:

The grooming for the MOM Database uses information in the Reporting DTS job to prevent the grooming from removing data that has not been transferred to the Reporting database. If the DTS job fails, MOM will not groom the MOM Database for the full 60 days, to avoid removing data that has not been transferred to the Reporting database.

So there you go. Now, there's some really interesting stuff on the “Grooming” section. Evidently MOM Warehouse grooms itself but on a time frame of 395 days (or 13 months). Thankfully this can be changed pretty easily by issuing this command:

exec p_updategroomdays 'TableName', DaysToRetainData
 

At any rate, you got to run this against all six tables if you want to modify them all. TableName and DaysToRetainData are variables of course. Here's a SQL script that Clive wrote to help address this:

-- Update the Datawarehouse Groom settings Declare @Groomdays int -- Retain data for 180 days Select @Groomdays=180

exec p_updateGroomDays 'SC_SampledNumericDataFact_Table', @Groomdays exec p_updateGroomDays 'SC_AlertFact_Table', @Groomdays exec p_updateGroomDays 'SC_EventParameterFact_Table', @Groomdays exec p_updateGroomDays 'SC_AlertToEventFact_Table', @Groomdays exec p_updateGroomDays 'SC_EventFact_Table', @Groomdays exec p_updateGroomDays 'SC_AlertHistoryFact_Table', @Groomdays


Just change the @Groomdays to something other than 180 if you want a different date set. Anyway, I found it on this post: http://www.momcommunity.com/ShowPost.aspx?PostID=83.


marcusoh.blogspot.com

May 3, 2005

miis - the promised code

Awhile back, I promised I'd post some sample code once I got the provisioning components working for simple sync for ADAM. I don't understand programming at all. I hack through scripts ... and that's about it. However, this isn't that far off from scripting I suppose. Most of the stuff you have to do is in the “Public Sub“ part. There's a simple select case statement to alter the container that the object is created in. That's really about it. Anyway, here it is:

Imports Microsoft.MetadirectoryServices

Public Class MVExtensionObject Implements IMVSynchronization

Public Sub Initialize() Implements IMvSynchronization.Initialize ' TODO: Add initialization code here End Sub

Public Sub Terminate() Implements IMvSynchronization.Terminate ' TODO: Add termination code here End Sub

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision ' TODO: Remove this throw statement if you implement this method Dim container As String Dim rdn As String Dim FabrikamADMA As ConnectedMA Dim numConnectors As Integer Dim myConnector As CSEntry Dim csentry As CSEntry Dim dn As ReferenceValue

' Ensure that the cn attribute is present. If Not mventry("cn").IsPresent Then Throw New UnexpectedDataException("cn attribute is not present.") End If

' Determine the container and relative distinguished name ' of the new connector space entry.

Select Case mventry.ObjectType.ToLower() Case "person" container = "CN=users,CN=MailObjects,CN=ironadam1,DC=adam" Case "user" container = "CN=users,CN=MailObjects,CN=ironadam1,DC=adam" Case "contact" container = "CN=contacts,CN=MailObjects,CN=ironadam1,DC=adam" Case "publicfolder" container = "CN=publicFolders,CN=MailObjects,CN=ironadam1,DC=adam" Case Else Throw New UnexpectedDataException( _ "Unhandled object type in provision" _ & "called with mventry " & mventry.ToString) End Select

rdn = "CN=" & mventry("cn").Value

FabrikamADMA = mventry.ConnectedMAs("Ironmail ADAM") dn = FabrikamADMA.EscapeDNComponent(rdn).Concat(container)

numConnectors = FabrikamADMA.Connectors.Count

' If there is no connector present, create a new connector. If 0 = numConnectors Then csentry = FabrikamADMA.Connectors.StartNewConnector("user") csentry.DN = dn csentry.CommitNewConnector()

ElseIf 1 = numConnectors Then ' Check if the connector has a different DN and rename if necessary. ' Get the connector. myConnector = FabrikamADMA.Connectors.ByIndex(0)

' Microsoft Identity Integration Server 2003 will rename/move if different, if not, nothing will happen. myConnector.DN = dn Else Throw New UnexpectedDataException("multiple connectors:" + numConnectors.ToString) End If End Sub

Public Function ShouldDeleteFromMV(ByVal csentry As CSEntry, ByVal mventry As MVEntry) As Boolean Implements IMVSynchronization.ShouldDeleteFromMV ' TODO: Add MV deletion code here Throw New EntryPointNotImplementedException End Function End Class

problems with MOMma

update: this information has been posted to an article on myitforum.com. Since implementation, it seems like the database has done nothing but grow, grow, grow. I've blamed the Exchange guys relentlessly for having a very noisy environment. No matter how many times I ran the MOMX Partitioning and Grooming job, the database would not free up any space. It turns out there are some mechanisms tied directly into grooming if you have a MOM warehouse enabled.
Here's the details. If you want to know the last time your DTS job completed successfully, you can comb through the event log on the reporting server or you can issue this command to your OnePoint database:
select * from ReportingSettings
The first column labeled TimeDTSLastRan indicates the last successful marker. Turns out if this isn't current, your grooming jobs aren't doing anything. Mine was set to the end of February. Hmmm. That'd explain the obscene growth pattern. I've run the job 5 times using the latency switch. The time stamp hasn't moved.
By the way, the job is scheduled on the reporting server. It's executed as something like this:

MOM.Datawarehousing.DTSPackageGenerator.exe /latency:20 /srcserver:OnePointDBServer /srcdb:OnePoint /dwserver:WarehouseServer /dwdb:SystemCenterReporting /product:"Microsoft Operations Manager”.

It's in the %ProgramFiles%\Microsoft System Center Reporting directory.
If you notice, there's a /latency switch. This let's you specifies what items to transfer to the warehouse. For example, 20 means anything older than 20 days old. This is useful if your DTS job is timing out because of an exorbitantly large amount of data being transferred - potentially overwhelming the transaction log, etc. Also, there's a /silent switch that you're supposed to use when issued as a scheduled task. I pulled it out to see what this job was doing exactly. In the event of a successful execution, you should see an event message like this:

The execution of the following DTS Package succeeded: Package Name: SC_Inner_DTS_Package Package Description: This package transfers data from datafoo\foo.OnePoint to foo.SystemCenterReporting Package ID: {481AA51A-8C84-42E3-9879-D228290895D0} Package Version: {24A473AA-4C8A-486B-9ED4-970D35A70047} Package Execution Lineage: {55B111CE-72ED-4231-821B-AAE321763EC5}

Well, after going through many latency switches and kicking off the groom jobs (MOMX Partitioning and Grooming), I was able to get the 15 GB DB back down to 5 GB. Interesting though, the time stamp still hasn't changed. Hmmm...