Using the Content Management Server 2001 Site Deployment Manager

  • Article
On This Page

Overview Overview
How You Might Use Site Deployment Manager How You Might Use Site Deployment Manager
Best Practices Best Practices
Using Site Deployment Manager to Export Objects Using Site Deployment Manager to Export Objects
Using Site Deployment Manager to Import Objects Using Site Deployment Manager to Import Objects
Using Sample Scripts Using Sample Scripts

Overview

Microsoft Content Management Server 2001 (MSCMS 2001) Site Deployment Manager allows you to do incremental updates to your MSCMS 2001 systems, using an export and import transfer method. Using the Site Deployment Manager, you can selectively update your system, allowing for separate development and production environments.

Note Be aware that if you are trying to deploy a read-only site, the login will fail. Check Chapter 5, "Using the Server Configuration Application" in the MSCMS 2001 Setup Guide for information about setting up another Web site or pointing to an existing Web site with authoring rights to the same server the read-only site resides on.

Operating requirements

Background processing

There should always be at least one gigabyte of storage space for the MSCMS 2001 server and database. Users are advised not to do an import when background processing is active or your import will fail. However, if an import is active when the background processing starts, the background processing waits until the import is complete before it starts. You can adjust the frequency at which MSCMS 2001 does background cleanups, using the Server Configuration Application, documented in the MSCMS 2001 Setup Guide.

Source system

The system from which you export objects is the source system.

Object package

When you export objects, they are exported to a .rop file. Even when exporting one object only, it is exported to an object package.

Destination system

The system to which you transfer objects is the destination system.

MSCMS 2001 objects that can be transferred

You can transfer the following MSCMS 2001 objects:

  • folders and pages

  • channels and postings

  • resource galleries and resources

  • template galleries and templates

  • rights groups and rights groups members.

NoteApplication Center, one of the Microsoft® Windows Server System™ products, provides content deployment and management facilities for sites built on Microsoft Windows 2000 and Microsoft Internet Information Services (IIS) 5.0. It can be used to synchronize files not stored in the MSCMS 2001 repository across servers and server clusters. For more information, check out https://www.microsoft.com/technet/prodtechnol/acs/default.mspx.

MSCMS 2001 objects that cannot be transferred

Server-side includes and other files stored on the server (and not managed by MSCMS 2001 inside the database) cannot be exported or imported. They must be manually copied and moved.

Who can use Site Deployment Manager?

Only MSCMS 2001 administrators can use Site Deployment Manager.

Basic steps to transfer content

  1. On the source system, export one or more objects to an object package (contained in a .rop file).

  2. On the destination system, import the object package to complete the process. Only objects in an object package can be imported.

How Site Deployment Manager handles dependent objects

What are dependent objects?

An MSCMS 2001 page, for example, has dependent objects: the template it was created from and the resources (images, text, video) serving as its content. When an object is exported, its dependent objects are exported with it. Objects cannot be exported without their dependent objects.

How Site Deployment Manager handles dependent objects

Note that only dependent objects in the MSCMS 2001 database are exported, not files on the file system, such as server-side includes that could be referenced from a template. For example, a cover page of a channel created from a posting is exportable. However, a cover page created from an HTML file stored on the server cannot be exported. Files stored on the file system of the server must be manually moved to the destination system server.

Potential dependent objects for each type of object:

Object

Dependent objects (automatically exported with object)

Page

Page templates and resources

Posting

Page, page templates, and resources

Folder

None

Channel

Navigation template and resources, postings for cover page

Page template and navigation templates

Resources

Resource gallery and resources

None

User rights groups and users

None

How You Might Use Site Deployment Manager

Following are examples of network configurations and how Site Deployment Manager is used in each one.

Transferring content from development server to read-only production server

In deploying a site, start by creating all the containers for your site on the development server where authoring, editing, and moderating activity can be done. See "Separating the development environment from production" in the Best Practices section of this chapter.

Transferring content from a development server to two production servers

Transferring content from a development server to two production servers

This is essentially a failover or replication scenario wherein content is developed then distributed to a production server A. Production server B is a mirror image of A. Use the database replication utilities of your choice once the deployment from the development server to production server A is done.

Best Practices

Copying an entire site

Site Deployment Manager is for making incremental updates to a destination server for small sets of objects. To copy an entire site, use a database replication utility.

Deploying in a server farm

When the Site Deployment Manager is used in a server farm, it has to connect to individual servers in the cluster.

Optimal time to use Site Deployment Manager

Use Site Deployment Manager when it causes the least amount of inconvenience to the users on your site. Moving parts of your site may take time, and Site Deployment Manager locks out modifications to the destination system (the server you are transferring objects to) during this period. This prevents users from making modifications to objects in the destination server; however they still have read access to the destination server. If multiple interconnected servers are supported in the server configuration, the lock will be in effect across all servers.

Another reason to move objects at periods of low activity is to prevent users from losing work, since objects open for editing at the time of import may be replaced by the import.

Separating development environment from production

If your site operates over more than one server, we recommend separating your development work from production work. Additionally, you could include a second level of development server for quality assurance, as shown in the following diagram as B (otherwise the tasks shown in the diagram on B are done on the development server A).

  • Create site and information structure on the development server, as represented in the diagram by A.

  • Using Site Deployment Manager, move the site architecture to another development server B.

  • Isolate all content development work (authoring, editing, template creation, and moderating) to the development server B.

  • Any changes to the site structure designed on server A can be applied to server B to synchronize its site structure while leaving the content in place.

  • Do not allow any content development work on the production server. Use the Site Deployment Manager to move content from the development server B to production server C.

This should ensure tight control over the navigation, hierarchy, and content of your site. It also saves time rewriting navigation templates, which rely heavily on the site's channel structure to perform their functions.

Separating development environment from production

Exporting security information

To not have any information about users and domains from the source imported to the destination (perhaps they don't share any common domains), do not export rights groups members (users).

Double-checking all objects for export

Make sure that all objects to be exported have been approved before doing the export operation. Only the approved versions of objects are exported.

Exporting and importing frequently updated content

A good practice is to create channels dedicated to content that is frequently updated. For example, if your company issues press releases regularly, you might want to create a channel to hold postings of press releases to be exported. This saves time when transferring timely content.

Deploying versioned content

A posting's revision history can reflect changes to its dependents. If a page containing two resource gallery items is deployed and during deployment the page and its template and the two resources are replaced, then any posting that uses this page will have four new revisions in its revision history: one for the page replacement, one for the template and two for the resources. Revision histories cannot be exported.

Setting up an export/import for a later date

Using Export profiles

Export profiles are a convenient way to set up an export for use at a later date, or save a selected group of objects and options. However, a saved export profile might not contain the most current information when used for an export. To determine whether the export profile accurately lists the objects to be exported, run an Export Preview. The Export Preview identifies which objects have been deleted since the Export profile was created, and which links might be broken once objects in the ROP are imported.

Using Import Preview

Import Preview reports provide a more accurate snapshot when no publishing activity occurs on the destination system between the time the Import Preview is run and the actual import is started. If users have modified objects, the Import Preview may not be completely accurate. Use this report to verify that no unexpected replacements will occur as a result of the import.

Planning an import

Important Be sure to back up the destination database before doing any importing.

Using the reports

Save the Export Preview and Export Report every time you export objects. These reports provide a record of your selections and options, which you may need to review when you are configuring options for your import. Also, these reports provide a record of the state of all objects that were exported, and objects that could not be exported, some of which (user names, rights groups, dependent objects) do not appear in the Export dialog box.

Also, keep copies of the Import Preview and Import Reports and add them to your records. The next time you import objects, you can refer to the reports from the last import to help you choose the right settings to ensure the import policy is kept consistent with previous deployments.

Importing dependent objects

Dependent objects can replace objects on the destination system when imported. For example, if you import a page, the dependent objects of the page (all templates and resources associated with the page) are also imported. If the templates and resources in the object package already exist on the destination system, they are replaced with the ones being imported. This affects all objects on the destination system that use those templates and resources.

Setting ownership of objects

Be careful when setting ownership for objects you are importing. To ensure that users can act on objects imported, set the owner of an object to a user who has rights on the domain for the destination system, or set the ownership to Everybody. Or, remember to set ownership on imported objects individually after import.

Changing the name of an object

Changing the name of an object to the name of another object doesn't make the two objects the same. This is because objects are not identified by name in the MSCMS 2001 system but by a globally-unique identifier (GUID). For example, object "A" is created on the source server and object "A" is created on the destination server. The source object "A" will not replace the destination object "A" even though they share the same name. The imported object is created as new.

Changing the destination system hierarchy

If you select the "Change container hierarchy on destination to match the package hierarchy" option, it may reorganize containers on your destination system.

Changing the destination system hierarchy

Preserving the destination system object hierarchy

If the "Change container hierarchy on destination to match the package hierarchy" option is not selected, the destination system will maintain its object hierarchy before import.

When you are doing an import, if you select the "Delete all existing container contents when replacing a container" option, container contents are deleted before they are imported and their sub-items are added. The exception is templates that are used by pages.

Using Site Deployment Manager to Export Objects

About exporting objects

Following are some key definitions and concepts regarding the export objects process:

  • Objects are exported to an "object package" that is composed of the objects selected for export.

  • Site Deployment Manager exports only the approved version of pages, postings, and templates.

  • Revisions cannot be exported.

  • If an object has a link to another object, you must export both objects for the link to work on the destination system. Links will also work if the linked object is already on the destination system. Broken links do not appear in published pages, but they appear when the page is opened for editing in the Site Builder. Also, export and import reports indicate which objects contain broken links.

Dependent objects

  • The dependent objects of a user-selected object are automatically exported, including its parent container hierarchy up to the root container.

  • The dependent objects exported from the Deleted Items container on the source system are imported to a "default" container on the destination system if the object doesn't already exist on the destination system. The dependent objects stay in Deleted Items if they already exist there. Using the Import options, you can specify a container to function as the "default" container, where objects are stored in such cases. Also stored in the default container are exported objects whose parent wasn't exported and whose parent doesn't exist on the destination system.

Postings for pages that use multiple views

Site Deployment Manager exports the page associated with a posting. Note that if the author created multiple views of that page, Site Deployment Manager exports the page templates used for each view.

Viewing dependent objects

After selecting objects for export you can view their dependent objects that will be exported, by running an Export Preview. It shows a list of all objects selected for export, including their dependent objects.

Rights groups and rights groups members

MSCMS 2001 rights groups can be exported with or without the rights group members. If the destination system uses a common domain and users as the source system, you can export both the rights groups and rights groups members that have been assigned to the containers being exported. If the domains are different, we recommend you do not export members, because the user information is meaningless on the destination system.

Reporting options when exporting

There are four types of reporting information you have access to when exporting objects as described in the following table.

Report title

How to run

Dependency Report lists the pages or templates that rely on a resource. Includes information such as status, name, location, owner.

Select a page or template and either run the report from the Report menu, or right-click and select Dependency Report.

Resource Report for a template lists the resources and placeholders used. For a page, the templates, resources, and placeholders it uses are listed.

Select a page or template and either run the report from the Report menu, or right-click and select Resource Report.

Export Preview lists the objects selected for export.

See "Exporting, step 3: generating an Export Preview," in this chapter.

Export Report lists the objects that were successfully exported to the object package.

See "Exporting, step 5: activating the export and saving the Export Report."

Running the Export operation

Open the Export dialog box in either of these two ways:

  • Right-click an object in the Site Builder window in list or tree view, and select Export to Package. You can also right-click multiselected objects. The Export dialog box opens, displaying the selected objects.

  • In the Site Builder window, click File>Package>Export.

Icons for containers and objects in the Export dialog box

Exporting, step 1: selecting one or more objects for export

  1. Open the Export dialog box as described in the previous section.

  2. If you are exporting containers without their contents—exporting object hierarchy or site structure only—select the Export Containers Only option on the Item Selection tab.

    Screen shot

  3. Select containers in the Choose Objects for Export area, if you did not select them from the Site Builder window. Selected containers and their objects appear in the contents box to the right.

  4. Select objects and click Include. The selected objects are moved to the Included and Excluded Export Objects area. Only approved versions of MSCMS 2001 postings, pages, and templates are exported; if a re-edited version of an approved page or template is selected, it won't be exported.

  5. If there are objects that you do not want exported (particularly children of a container that was selected for export), select them and click Exclude. Any container in the Included and Excluded Export Objects area will have all its contents exported, unless you select the child objects for exclusion. The parent containers for selected objects are not automatically exported.

    You can always select Exclude, but the actual exclusion done during the export operation depends on these conditions—you can exclude sub-items of selected container objects, but you cannot exclude objects that are dependent objects of objects being exported. These objects are exported regardless of the include/exclude setting.

Exporting, step 2: setting the Rights Options for export

  1. Click the Rights Options tab in the Export dialog box.

    Screen shot

  2. Select Export Rights Groups, in the Rights Groups Security area, to export the rights groups that have been assigned to containers being exported.

  3. Select Export Users to export the user names for members of the rights groups being exported. Note that the exported users must exist on the domain of the destination system in order for them to have access to the imported objects.

Note To preserve security and not export user information, or when source and destination don't share domains, don't check the Export Users box.

Exporting, step 3: generating an Export Preview

Use the Export Preview to review and save a list of the objects selected for export, including sub-items and dependent objects. User-selected objects are in bold and dependent objects are in normal text.

Run the Export Preview from the Export dialog box, after you have moved selected objects to the Included and Excluded Export Objects area.

  1. To run an Export Preview, select Export Preview from the Report menu in the Export dialog box. The report contains the following areas of information.

    Report heading

    Comments

    Report Information

    Includes information about the package file, such as generated date and time, report generator (user), client machine, version, the source system's URL, and the server version.

    Selected Export Parameters

    Parameters such as security settings.

    Selected Containers and Items

    Items selected by a user are shown in bold. Dependent objects of selected objects are not in bold. Includes the following: Channels and Postings, Folder and Pages, Template Galleries and Templates, and Resource Galleries and Resources.

    User Rights Groups

    User rights groups and user, including the path name for the rights groups in the report for easier identification.

    Selected Export objects not currently available for Export

    Items selected but not available.

    Select objects containing broken MSCMS 2001 links

    Links that could potentially be broken on import.

  2. Click File>Save As and File>Print. Saved Export Preview reports are HTML documents.

Exporting, step 4: saving the export selections to an Export Profile

If you think you'll export the same objects and options again, or if you want to export your selections later, save the settings to an Export Profile.

  1. Select File>Save Export Profile As from the File menu on the Export dialog box. The Save Export Profile As dialog box opens.

  2. Select a directory, and enter a name for the profile. A saved MSCMS 2001 Export Profile has a .rep extension.

Saved Export Profiles can be opened from the File menu on the Export dialog box.

If you plan to use the Export Profile later, see "Setting up Exports/Imports for a later date" in the Best Practices section of this chapter.

Exporting, step 5: activating the export and saving the Export Report

Once you have moved the objects to the Included and Excluded Export Objects area, and have saved and printed an Export Preview (recommended), you can export the objects to an object package.

  1. If you are using an Export Profile, open it from the File menu on the Export dialog box. The Export Profile opens.

  2. Enter a valid path and file name in the Export to File field, or click Browse to specify a file.

    Click Export. The export begins, with a progress indicator displayed. You can cancel the export operation at any time, however the cancel may not occur immediately but a short time later.

  3. The Export confirmation dialog box indicates successful creation of the Object Package. An error message is displayed if the export wasn't successful.

    From this dialog box you can launch the generation of the Export Report which lists the objects that were successfully exported to the object package. If you generated and saved a Preview Export, you can compare it to the Export Report to note any discrepancies (for example, someone has deleted an object that you planned to export).

  4. Click Show Report on the Export confirmation dialog box. The Export Report opens, displaying information similar to the Preview Export report.

  5. Click File>Save As. Saved Export reports are HTML documents.

  6. When exporting a file to a machine with very low disk space, an Object Package (.rop) file with a size of zero is created. Free up some disk space and try the export again.

Using Site Deployment Manager to Import Objects

Before you start

  • Back up the destination server before importing by backing up the database.

  • We recommend you read the Best Practices section at the beginning of this chapter to help ensure a successful import.

About importing objects

Synchronization

Site Deployment Manager objects are always synchronized—objects on a destination system are always replaced when re-imported from an object package.

If an object contains links to another object, both must be in the object package in order for the link to work on the destination system. If the linked object is already on the destination system, the link will also work. Note that broken links will be inactive at run time.

Importing dependent objects

An object's dependent objects could replace objects on the destination system when imported. This, in turn, can affect other objects on the destination server that use those same dependent objects. See the Best Practices section, "Importing Dependent Objects" in this chapter for more details.

Rights groups and members

You can import rights groups with or without their members.

Make sure the members of imported rights groups exist on the domain of the destination system. Users on the destination system will be unable to access the imported containers and objects, if the destination system cannot authenticate the imported user names.

System-wide lock

Imports should be done in periods of no or low activity because the Site Deployment Manager places a lock on the destination system during import. This means that the users on the site won't be able to do tasks involving modification of objects, such as modifying or submitting pages. If multiple interconnected servers are supported in the server configuration, the lock will be in effect across all servers.

Edited objects

Objects on the destination system that were edited before import might get replaced by their published version. It is not recommended to import to a destination system when editing occurs.

Changing the destination system container hierarchy

Regarding the destination system container hierarchy, even after existing objects get moved around, their linkages or relationships to other objects remain intact (for example, page to template, posting to page, or page to resource).

Import Mode

Site Deployment Manager allows only one import mode to "add and replace" objects on the destination system. Objects from the object package that do not exist on the destination system are added while objects from the object package that already exist on the destination system are replaced.

Note If you import a template that is in use by pages and postings on the destination system, those pages and postings switch to the newly-imported template. Be sure the template is compatible, otherwise your site may not function properly.

Running the Import operation

Importing, step 1: setting options

  1. Open the Site Builder window on the destination server and select
    File>Package> Import. The Site Deployment Import dialog box opens. Select the Container Rules tab.

    Screen shot

  2. Select an option from the "When Adding Containers" area.

    • "Inherit destination parent rights" means that imported containers inherit the privileges assigned to the parent container on the destination system. Use this option when security configuration is managed from the destination system.

    • "Use package container rights" imports the containers in the object package and the users assigned to them. Security settings from the source system are mirrored.

    • "Leave container rights list empty" imports the containers in the object package with no user rights group assigned to them. Use this option if you want containers to be created with no access rights.

  3. Select an option from the "When Replacing Containers" area.

    • "Inherit destination parent rights" means that replaced containers inherit the users assigned to the parent container on the destination system.

    • "Replace with package container rights" imports the containers in the object package and replaces the users assigned to them on the destination system with the users assigned to the containers in the object package. Mirrors security setting from source system.

    • "Keep destination container rights" replaces the containers while leaving their existing security setting.

    • "Combine package and destination rights" imports the containers in the object package with their assigned users and adds them to the existing list of users assigned to the container on the destination system.

  4. When replacing containers, if you select the "Change container hierarchy on destination to match the package hierarchy," the imported objects have the same hierarchy they did on the source system. See "Changing the destination system hierarchy" in the Best Practices section at the beginning of this chapter for examples of how this option re-organizes containers on the destination system.

  5. If you select the "Delete all existing container contents when replacing a container" option, container contents are deleted before they are imported and their sub-items are added. The exception is templates that are used by pages.

Note You can select this option only if the "Change container hierarchy on destination to match the package hierarchy" option is selected.

This ensures that the contents of the imported container mirrors the source system (additional or obsolete objects are removed).

Importing, step 2: setting options on the Rights Groups tab

The options on the Rights Groups tab apply only if rights groups and users were exported to the object package.

Tip Check the Export Report (if one was printed after export) to see which rights groups and users were exported to the object package.

  1. In the "Select how Rights Groups are imported" area you can specify whether security information for rights groups and users on the source system is to be imported.

    Screen shot

  2. If you select the "Import User Rights Groups and Users" option, you can select an option in the "Select how Users are imported" area.

    • "Use only the package user lists" adds the users in the object package who belong to the rights group and, if the user rights group is already on the destination system and being replaced, the members list is overwritten.

    • "Use package and destination user lists combining them for replaced Rights Groups" adds the users in the ROP file. If the user rights group already exists, its members list is merged with users imported from the ROP file.

  3. Specify ownership in "Set Owner for Imported Objects" or click Browse to set the ownership to a user from the destination system. If you set ownership to Everybody, all users with rights on the destination system can act on the object.

Importing, step 3: setting options on the Orphaned Objects tab

  1. Select the Orphaned Objects tab on the Import dialog box.

    Screen shot

  3. Click Browse (...) to configure the default containers for orphaned objects.

Importing, step 4: generating an Import Preview

Use the Import Preview to review a list of the objects selected for import, including the import modes and options selected for them. Note that it may take time to generate this report, depending on the number of objects in the package.

No changes are made to the destination system.

Import issues

  1. From the Import dialog box, select Import Preview from the Report menu. A progress indicator displays and then the Import Preview opens. The report contains the following sections:

    Report heading

    Comments

    Report Information

    Includes information about package file, date and time generated, generated by, client machine and version, server URL, and server version.

    Import Parameters

    Includes parameters such as user rights groups, destination containers for orphaned objects, import mode, and container rules.

    Object Placement from Source to Destination System

    Itemized by container type and indicates Source and Destination. There is also an indication of whether the object being imported is relocated (container or object is imported to a location that is not identical to the object package), same (location is identical to object package), or new container or object is imported to a new location that will be added to the destination location.

    Destination Objects that will be Deleted on Import

    Includes information about duplicate objects listed under the Destination Objects that will be deleted on Import.

    Destination Objects that may Contain Broken Links after Import

    		  

  2. Click File>Save As and File>Print to print the Import Preview which is an HTML document.

Importing, step 5: saving the settings to an Import Profile

You can save the settings to an Import Profile if the same objects and options might be imported again, or to import the object package later.

  1. Click File>Save Import Profile As on the Import dialog box. The "Import Profile As" dialog box opens.

  2. Select a directory, and enter a name for the Profile. Saved Import Profiles have a .rip file extension.

You can open Saved Import Profiles from the File menu on the Import dialog box.

If you plan to use the Import Profile for export later, see "Setting up Exports/Imports for a later date" in the Best Practices section at the beginning of this chapter.

If you have previously set options for an import package, and saved them to an Import Profile, click File>Open Import Profile from the Import dialog box. The settings in the Import dialog box are set according to the options that were saved to the Import Profile.

Importing, step 6: activating the import

Warning Once you start the import operation, it cannot be stopped. Stopping the import could leave the site in an unknown state.

Once you've set the import options, and have saved and printed a Preview Import (recommended), you can import objects from the object package. An import operation can take considerable time, depending on its scope. Operate the import during periods of low usage, or ensure no user other than yourself is logged in to the MSCMS 2001 destination system.

If you are importing from an Import Profile, open the Import Profile from the File menu of the Import dialog box. Click Import to start the import operation.

A successful import is indicated by an Import confirmation dialog box. An error message is displayed if the import wasn't successful—the Import Report will contain more information.

Importing, step 7: viewing and saving the Import Report

The Import Report lists the transactions that occurred during import, such as locked objects that were unlocked, deleted objects, or objects that contain potential broken links. Note that for deleted objects, the path that is reported is the path before they were deleted.

The import confirmation dialog box, which appears after the import is complete, offers the option to view the Import Report. Click Show Report on the dialog box to display the Import Report.

Importing templates: setting up server and system files

After importing navigation templates and frameless page templates, all system files referenced by the imported templates must be added to the destination system. These files can include:

  • files external to the MSCMS 2001 database that are referenced by a URL

  • files included using ASP scripting

  • all component files of a frameset

  • external JavaScript files

  • external Cascading Style Sheet (CSS) files.

Note If you have modified the destination server and system files, back them up before copying over them.

NoteApplication Center, one of the Windows Server System products, provides content deployment and management facilities for sites built on Microsoft Windows 2000 and Microsoft Internet Information Services (IIS) 5.0. It can be used to synchronize files not stored in the MSCMS 2001 repository across servers and server clusters. For more information, check out https://www.microsoft.com/technet/prodtechnol/acs/default.mspx.

If imported templates use Microsoft Internet Information Server (IIS) virtual directories to reference MSCMS 2001 system files, these virtual directories must also be duplicated on the destination system.

Using Sample Scripts

We have included sample scripts for site deployment operations in a folder on the MSCMS 2001 Installation CD. With these samples, you have scripting access to the Site Deployment Manager to allow automated deployment, such as scheduling a deployment operation at a specific time (for example, midnight) and for a specific occurrence (once a week).

The sample scripts can be used for doing basic tasks with the Site Deployment Manager, including load a profile, export and import, check for errors, and generate the resultant report (Export Report or Import Report, depending on the operation performed).

Currently, you will be setting all your preferences and objects selections for export or import using the Site Deployment user interface. These settings are saved as export and import profiles and are loaded by the script. The following sections explain how to schedule an import with the Site Deployment Manager, and how to use the sample scripts.

Scheduling an import

  1. Copy the sample script folder for import on the installation CD to your local file system.

  2. Locate Task Scheduler by selecting Scheduled Tasks in the My Computer folder in Windows Explorer. Click Scheduled Tasks, then Add Scheduled Task. The Scheduled Task Wizard appears.

    For Windows 2000, select Scheduled Tasks from the Control Panel (Start>Settings>Control Panel), then click Add Scheduled Tasks to activate the Scheduled Task wizard.

  3. Click Next on the wizard.

  4. Use the Browse button to locate the import sample script file you saved in step 1.

  5. Configure the remainder of the options according to your requirements.

  6. On the User Information tab, enter the MSCMS 2001 user login name and password (person who is authorized to access the Site Deployment Manager—only administrators have this privilege).

  7. Click Finish.

When the sample import script is executed, the following occurs:

  • The Object Package (ROP) is imported to your target MSCMS 2001 system.

  • The Import Report is displayed.

  • The Import Report is saved to the file you specified.

Using the sample scripts

Following are the basic steps to customize and reuse the sample script which carries out an import with the Site Deployment Manager.

  1. Open the import script file for editing in your preferred editor.

  2. Locate the section marked "User Configurable Constants" which is the area you will be working with—ignore the rest. Provide the machine address where the target server resides. Enter the IP or host name to the right of the constant for the server name constant.

  3. Next, you need to customize the filename of the import profile you'll be using. An import profile is created with the Site Deployment Manager user interface. Refer to previous sections in this chapter for information about creating profiles. Enter the path of your import profile as indicated in the script.

  4. Normally, the Object Package (ROP) file to be imported is specified in the import profile, in which case there is no need to set it in the script. However, if you need to create and reuse a set of pre-configured import options without repeatedly modifying the profile to specify a different ROP file through the Site Builder window, you can have the script reference the import profile and specify a different ROP file in the script every time you use it. To do this, set the ROP path value to the appropriate constant.

  5. Set the flag on whether the Import Report needs to be saved.

  6. If the Import Report is to be saved, specify the path and base filename from which a unique filename will be generated for each import operation.

  7. Set the flag to toggle an Import Preview to be generated before the import starts.

You are now ready to execute the sample script, either Site Deployment Export or Site Deployment Import, on the install CD.