Nightly Data Warehouse Cube Jobs – System Center Cube Jobs Do Not Run As Scheduled

2 out of my 3 Data Warehouse areas are running as expected. The Data Warehouse ETL and the Cube processing are stable, but the scheduled nightly runs weren’t kicking off as expected. DWMaintenance kicks off my process each night at 10 pm and then the other job were spaced throughout the night, allowing for each job to complete before the next one started.

Heads up – PowerShell Data Warehouse jobs display schedules as GMT while your SCSM 2012 console shows your local time.

Once I manually set the schedules via powershell, the DWMaintenance, MPSyncJob, and the ETL jobs and all but one cube ran as expected. ConfigItemCube would not start as scheduled and returned the following error:

Event ID 11366 – The Microsoft Operations Manager Scheduler Data Source Module failed to initialize because some window has no day of the week set.

I had manually set all of my cubes to run daily via PowerShell after the GUI schedule stopped working.

Set-SCDWJobSchedule -JobName Process.SystemCenterConfigItemCube -ScheduleType Weekly -WeeklyFrequency Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday -WeeklyStart 06:00

Set-SCDWJobSchedule -JobName Process.SystemCenterWorkItemsCube -ScheduleType Weekly -WeeklyFrequency Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday -WeeklyStart 07:00

There is a bug in the SCSM 2012 GUI and/or PowerShell scheduling process and the way to fix it is to manually update the offending Management Pack – Microsoft.SystemCenter.Orchestration.Configuration.xml

This management pack coordinates the Data Warehouse jobs. Since you can’t export this management pack, you use PowerShell to export the entire suite of MPs to a local directory using this PowerShell command:

get-scsmmanagementpack -computername <servername> |export-scsmmanagementpack -path <path>

Copy and save the Microsoft.SystemCenter.Orchestration.Configuration.xml to another location. You always want to update the copy and save the master copy.

After that, open Microsoft.SystemCenter.Orchestration.Configuration.xml and search for “SystemCenterConfigItem” in the XML text. Evaluate the “<Scheduler>” tag. Notice how mine has a sync time of 00:00 (midnight)? Look at the Interval unit and the setting of 0, which is the repeat cycle. Based on the settings the job runs each night and midnight and kicks off every zero seconds. The job won’t run with those settings.

<Interval Unit=”Minutes”>0</Interval>
<ExcludeDates />

The PowerShell and/or the GUI scheduler hammered this entry. To correct this problem, copy and paste this working <Scheduler> text into each cube processing scheduler section, but change the start times appropriately:

        <Interval Unit=”Days”>1</Interval>
        <ExcludeDates />

Reimport the MP with this command:

import-scsmmanagementpack -computername ussjcscsm002prd -path <path>/Microsoft.SystemCenter.Orchestration.Configuration.xml

Wrap Up

After the import, check the Data Warehouse Operations Manager event log for this entry:

Event ID 1201 New Management Pack with id:”Microsoft.SystemCenter.Orchestration.Configuration”, version:”7.5.1561.0″ received.

This is your indication that all went well.

You should un-process all your cubes at the SSAS (or not, your call) and let the regularly scheduled processes run overnight. This should fix your scheduling problems.



About Doug Sigmon

IT Helpdesk manager in southern California. Love technology, gadgets, and golf.
This entry was posted in SCDW, SCSM 2012 and tagged , . Bookmark the permalink.

5 Responses to Nightly Data Warehouse Cube Jobs – System Center Cube Jobs Do Not Run As Scheduled

  1. Pingback: Troubleshooting SCSM 2012 Cubes | Doug's IT Operations Support Blog

  2. Nicolas says:

    Hey Doug,
    I’m getting the same error as you had indicated. However, we set our rules to go through from a GUI perspective instead.
    I exported the MP and took at look at the XML, and this is what I see for mine.




    From what I can see, that is the cause of the failure in our event log, but I can’t see where the XML is wrong.
    Any help woudl be great

  3. Alex Marsh says:

    Hi Doug
    Do you know if this issue is still present in 2012 R2?

    • Doug Sigmon says:

      Hi Alex,

      If you install all the roll ups, you’ll see marked improvements and greater controls on timeouts (you can configure this now). We’re just starting our R2 deployment and I’ll post an article once wrapped up. We’re deploying to all SSD storage, so I expect so great results.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s