An excerpt from Portal Wiki Site about Site Management:
Site Management features provided by WebSphere Portal v6.1 make managing multiple
portal deployments easier. Portal administrators can use Site Management and the
Resource Manager portlet to develop and test a portal page on a test server, then copy the
page to a target server for review and later promotion to a live page. Once you publish the
page to a target server where only a selected group of users can preview and do additional
test before promoting the page to all users and groups with the appropriate access rights.
After the page is modified , republished and re-promoted, the previous promoted page
becomes a version page. The demote function makes the page no longer visible in the
target server if a rollback is needed.
The following example illustrates how to use Site Management to perform a portal
transfer.
Enabling remote access to your servers
The portal site management publish feature requires at least two portal systems: a source
system, where you create new pages that you need to publish, and a target system, where
you make the new pages visible to portal users. You can also use one server with two or
more virtual portals for your source and target systems. The Resource Manager portlet
can display the contents of the systems. By default, the portal server is pre-configured to
allow remote access.
If you have a portal cluster, you need to run the enable-http-basic-auth-taisitemgmt
task before you start managing your site. A WebSphere Application Server
Trust Association Interceptor (TAI) is used to authorize access to the servers.
Note: Individual virtual portals on a single portal server do not require the enablehttp-
basic-auth-tai-sitemgmt task to be run more than once.
In this River Bend project, the development server is a standalone portal server, both
staging and production environments are vertical portal clusters with two portal instances
installed on the same physical Windows 2003 server. In order to manage the sites, the
task enable-http-basic-auth-tai-sitemgmt needs to be run on the staging
and production servers for each portal instance, details of running this task are described
Open a command prompt and change to the directory where WebSphere Portal
ConfigEngine is installed (wp_profile_root\configengine on windows) and issue the
following command:
ConfigEngine.bat enable-http-basic-auth-tai-sitemgmt –
DPortalAdminPwd=password -DWasPassword=password
Use -DPortalAdminPwd=password -DWasPassword=password to specify
the portal and WebSphere Application Server IDs passwords.
Note: This task uses the settings in the file wkplc_comp.properties to configure
the TAI. Although the TAI settings are pre-configured to work without requiring
adjustment, you can change the settings before running the task if you need to configure
the TAI differently.
The build successful messages of this task showed as following:
BUILD SUCCESSFUL
Total time: 1 minute 0 seconds
isIseries currently set to: null
uploading registry
Created admin client: com.ibm.ws.management.AdminClientImpl@7f5e7f5e
Created config Service Proxy: com.ibm.websphere.management.configservice.ConfigS
erviceProxy@3f2a3f2a
CELL: wps02Cell01
Websphere:_Websphere_Config_Data_Type=Registry,_Websphere_Config_Data_Id=cel
ls/wps02Cell01|registry.xml#Registry_1225855618625,_WEBSPHERE_CONFIG_SESS
ION=anonymous1225980772093
HTTPBasicAuthTAI setting can be verified through WebSphere Application Server
administrative console.
Important: After this task runs successfully on each portal instance, the deployment
manager server, nodeagents and portal servers in the cluster environment need to be
stopped and restarted for the TAI configuration settings to take effect.
If any of the servers are enabled for Secure Socket Layer (SSL), you must perform
additional steps on the server where you will manage your site. Please refer to the
WebSphere Portal Server Infocenter for details on this topic.
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp
Managing your servers
Before you begin to manage your site using the Site Management page, you must add the
source and target servers to the Resource Manager portlet. After adding the servers to the
portlet, you can edit and remove servers and manage access to the servers.
You must be an administrator to use the site management functions. To manage the
servers, select Administration > Site Management > Manage Servers.
1. Add a new server
First you need to add a new server, click Manage servers > Add new server.
Enter the fully qualified Host name for the server and the port. You can accept the default
path, for example:/wps/mycontenthandler as the server path. Then assign a
unique name for the server and check the Use Secure Sockets Layer option if the server is
set up for SSL.
Note: If you configure a virtual portal, then the path is
/wps/mycontenthandler/vpid where vpid is the URL context of the virtual
portal.
First add the development server as a source server and assign a unique name: Local
Then add the staging server as a target server and assign a unique name: Staging
2. Manage server access
Use the Manage server access option to provide or update the login credentials to servers
that you are managing.
Click Manage servers and then select Manage server access.
Select the server that you want to access from the drop-down menu, and enter the User
name and Password for the server, click Save to save the information, or click Done to
exit without saving the information.
You can also edit or remove a server using the Manage Servers option.
Publishing your page
After you have created and tested your content, which could be a page, a label, or a URL,
you can publish it to a target server. You can perform the publish task by using the
Resource Manager portlet on the Site Management page, or by using the Portal Scripting
Interface. This topic describes publishing through the Resource Manager portlet.
-
Create and test a page on your source server.
The following information, or referenced items, are published if they are included in a
page:
Unique names
Page properties
Page layout
Page metadata
Friendly URLs
References to portlets on the page
Note: The same portlets with the same unique name as on the source portal must
also exist on your target portal. References to JSR portlets and to IBM portlet
without binary parameters are supported.
Shared or default portlet preferences
Portlet wires
Advanced options under Edit page properties.
Limitations:
You can only publish pages that have a unique name.
The following items that a page can reference do not get published:
o Page permissions or access controls
o URL mappings
o Derived pages
o Composite applications
o Web Content Management content or libraries
o Private resources
o Private wires
o Personalized portlet preferences
o Portlets or portlet WAR files. You can publish references to portlets only
if the portlets exist on the target server.
o Personalization rules. These must exist on the target server.
Site management does not support the merge of multiple publish events from
different users. The last publish process overwrites previous publish versions.
You can go back only one version on a publish, promote, and demote scenario. If
you want to go back farther than that, you need to create backups of the versions
that you might want to go back to. You can do this by using the XML
configuration interface.
Site management publishing does not support cross page wires.
2. Select a server
Select a source server and a target server before publishing the page.
Click Administration > Site Management, select the server from the pull-down list.
3. Publish a page/pages
You can publish a single page or label or the entire page or label hierarchy from a
source server to the target server.
Right click on the page or label and select Publish to > servername.
On the publish page details screen .Select the Page radio button
to publish a single page or label. If this is a hierarchy that you want to publish, select
the Entire subtree radio button. Enter the Parent page unique name, which is the
unique name of the parent page on the target server. There is an optional field for
Sibling page unique name, which is the unique name of the page that comes after the
published page in the target server hierarchy.
You can logon to the target server as a portal administrator to view the published
page and verify that the page that you published is available on the server and is
working as designed.
Notes:
1. Parent and sibling pages or portlets that you publish by using site management
must have a unique name assigned to them on both the source and target servers.
For a portlet the unique name must be the same on both the source and the target
server. Make sure that when you create your page that you assign it a unique
name; otherwise, you cannot publish the page to another server.
2. If the pages or portlets that you publish have existing personalization visibility
rules associated with them, site management will publish the rule associations, but
not the rules themselves. You must make sure that the same rules exist on both the
source and target servers, and preserve the correct page-to-rule association.
3. Publishing a page into the public area of the portal is not supported.
4. When a page hierarchy that you publish contains a page that is marked private for
yourself on the source server, that private page is published as a public page on
the target server. This also applies to private changes that you made to a page that
you publish. When you publish that page, other users can see the page just the
same as you with all private changes that you made to the page.
5. Pages that exist on the target server, but have not been created by a by site
management publish step cannot be replaced by using the site management
functionality. In such a scenario an error message is displayed.
6. Pages managed by site management must only be changed on the source server,
not on the target server; otherwise the site management function may not work
any more.
7. If two administrative users attempt to publish different versions of the same page
at the same time, there is no support for merging these multiple publish actions.
The last version of the page to be published is displayed. It overwrites other
versions.
Providing reviewer access to a published page
A special personalization rule is used to make a published page visible to a specific set of
users, who will review the page before it is promoted. You can customize this rule to
control which users can review the page.
When you publish a page using the Site Management publish feature, or the JACL
publish script, the page is copied from one portal system to another, or from one virtual
portal to another. When the page is published but not yet promoted, it is not visible to all
users and is hidden by a special personalization visibility rule named publishRule. By
default, the publishRule visibility rule allows members of the Portal administrators
(wpsadmins) group to see and review published pages that have not been promoted. This
rule can be modified using the Personalization Rule Editor.
To access Personalization Rule editor, from portal administrative console, click
Applications > Content > Personalization > Business Rules,
Promoting your page
Once the reviewers have reviewed the page, use the Site Management promote feature to
move the page from the published (review) state to the promoted (live) state, where all
users on the target server with the appropriate access rights can view the page.
To promote a page on the target server, click Administration > Site Management, then
right click on the label or page or URL that you want to promote, then click Promote this
page.
After the page is promoted, it shows a promoted sign ( )in front of the page within the
Resource Manager Portlet panel
If you promote a label or a URL, the promotion takes place without further prompting.
When you promote a page or a page sub tree, and a page or sub tree with the same unique
name exists already, you must choose a customization option, as described below.
Promoting a single page on the target server
If you promote a single page on the target server, you choose from the following
options:
o And remove customization
This option overwrites customized preferences on replaced pages.
o But preserve customization
This option preserves customized preferences on replaced pages.
Promoting a page sub tree on the target server
If you promote a page sub tree on the target server, you choose from the following
options:
o To add and update pages and remove customization
This option adds and replaces pages and nodes on the target portal by those from
the source portal and leaves nodes that are not affected unchanged. It overwrites
customized preferences on replaced pages.
o To add and update pages but preserve customization
This option adds and replaces pages and nodes on the target portal by those from
the source portal and leaves nodes that are not affected unchanged. It preserves
customized preferences on replaced pages.
o To create a duplicate sub tree and remove customization
This option adds, replaces, and removes pages and nodes on the target portal to
exactly match the sub tree of the source portal. It overwrites customized
preferences on replaced pages.
o To create a duplicate sub tree but preserve customization
This option adds, replaces, and removes pages and nodes on the target portal to
exactly match the sub tree of the source portal. It preserves customized
preferences on replaced pages.
If a promoted page with the same unique name exists already, the previously promoted
page becomes the old version of the page. If an old version of the page with the same
unique name exists already, that page is overwritten. Any personalization settings that
were applied to the old page or portlet are retained and used by the new version of the
page. Also, any URL references to the old page now point to the new page.
Republishing and promoting a page
When you make changes to a promoted page, you can republish the page and promote it
again to update the version that users can see on the target server. When you promote the
page again, one previous version of the page is maintained on the server so that you can
back out changes if necessary.
To republish and promote a page, click Administration > Site Management, right click
on the page name located in the source server site tree, click Republish to. Click All to
republish the page to all servers where it has previously been published, or click server
name to republish to just that target server.
The RiverBend page is now republished and the new version is visible only to the group
of users defined as reviewers. Figure shows the republished RiverBend page
with the published sign at the bottom. To update the page so that all users on the target
server can view it, you must promote the republished page.
After promote the republished page, the page can be viewed on the target server by all
users with the appropriate access rights. One previous version of the page is maintained
on the target server, which becomes a version page and it can be used to back out the
changes if necessary. Version pages ( ) are no longer visible to the users and they
have a visibility rule assigned
Demoting your page
After you promote your page on the target server, you can demote the page so that the
page is no longer visible on the target server. The page returns to a published state.
To demote a page from the target server, click Administration > Site Management,
right click on the promoted page and select Demote this page.
After the page is demoted, it returns to a published state. If an old version of the page
with the same unique name exists, the old page becomes the promoted page again. Figure
shows that the old version of RiverBend page becomes the promoted page as the
same unique name exists in the target server and the newer version of the page is back in
published state.
next:
Adding Custom Attributes to WebSphere Portal 6.x
Enable session failover in clusters
Look Aside Database
Dublicate Component error on Websphere Portal 6.1
Enable lazy load of portlet applications during Portal startup 
How to use WCM Memberfixer to replace a non-existent user or group with an existing user or group
bu kadar yer ayrıldığına göre sanırım iyi bişeyy :))
Thanks for your comment .I hope this website help people like you.