Skip to main content


Showing posts from May, 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.;en-us;828269

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. Evi

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 yo

problems with MOMma

update : this information has been posted to an article on 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 ti