One of the sweet new capabilities in 9.2 OLAP for cube developers is the Cube Job that is automatically created for each new cube. The job is used as a interface mechanism to schedule the cube refresh code without manually retrieving the PROC OLAP code and customizing it for scheduling which we "old" BI developers did years ago. (I use the term "old" as this was the exact topic of my very first blog post - in August 2005 - during those 9.1.3 days.)
In 9.2, you can use the Export/Import wizard in SAS Management Console to quickly promote content between your development, test, and production environments. I detailed this process in the second Moving OLAP Cube post. What I didn't mention was that this Cube Job, even if you decide never to use it, still must be included within the export/import process. Otherwise you receive a message like this:
Selecting the job to include in the export is one thing, but what if you plan to organize these jobs and store them elsewhere in the metadata folder structure?
Organize away
The properties of a job can be viewed from within OLAP Cube Studio, DI Studio or Management Console. Within the Location box is the current folder location (defaulting to the same place as the cube). You can click Browse to modify where the job is stored.
So with jobs and cubes in different metadata locations, how do we promote an individual cube?
An easy way to do this is to start the export on the cube, and then check the box for Include dependent objects when retrieving initial collection of objects. However, when you import these two objects into the next system it does not keep the folder structure of the two objects and places both in the location where you started the import. Then you are back to modifying the properties of the single job to move it to the proper folder.
If you want to maintain folder structures between export/import my recommendation is to store all your cube jobs one level under the cube folder location. Start the export process on the folder that contains the cube and subfolder for jobs then check only those objects to be promoted.
If you decide to store in two different folders (such as Projects -> Candy -> Cubes and Projects -> Candy -> Cube Jobs), you must start the export process at the top common folder (Projects -> Candy) which could take SAS Management Console some time to analyze all the objects in the entire folder to display the full list in the export interface.
Importing away
When importing the package into the target environment, the folder structures are maintained. If the folders do not yet exist, the import process will create them for you. Another reason to keep your metadata folder structures organized between environments. In the example below, the folders marked with red * will be created automatically in the target environment. 
