A Step by Step Guide to Federating a Migrated Portal v7 node

Added by

Hunter T Tweed | Edited by IBM contributor

Hunter T Tweed on April 8, 2011 | Version 17

A step by step approach to federating a Portal v7 node that has previously been migrated from an earlier Portal version.

Tags: 7.0, cluster, cluster guide; cluster; portal cluster, cluster planning, clustering, migration, portal, portal 7.0, portal migration, portal server

ShowTable of Contents

HideTable of Contents

1 Introduction
2 Before You Begin
3 Standalone LDAP
4 Standalone LDAP with Property Extension Database
5 Federated LDAP
6 Federated LDAP with Property Extension Database
7 Federated LDAP with Database User Registry
8 Federated LDAP with Property Extension Database and Database User Registry

Introduction

When you federate a cluster a Portal v7 node, the node inherits and uses the Deployment Manager's security configuration. If you have migrated WebSphere Portal from an earlier version (v6.0 or v6.1), then you will already have external security enabled in your standalone Portal environment.

In order to preserve the security configuration on your migrated Portal environment when you build a cluster, extra steps must be taken prior to federating the Portal node.

This guide is split into several sections, depending on the security configuration of your Portal environment:

Standalone LDAP
Standalone LDAP with Property Extension database
Federated LDAP
Federated LDAP with Property Extension database
Federated LDAP with Database User Registry
Federated LDAP with Property Extension database and Database User Registry

You only need to follow the section that matches your security configuration.

Before You Begin

Ensure the Deployment Manager is installed and set up following the Product Documentation. For example from Linux:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Preparing_the_WebSphere_Application_Server_Deployment_Manager_on_Linux_wp7
Enable Portal profiles on the node following the Product Documentation. This cannot be done after creating the cluster. For example, from Linux:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Preparing_the_WebSphere_Application_Server_Deployment_Manager_on_Linux_wp7
This guide assumes this will be your primary Portal node.

Standalone LDAP

In this section, you will federate a Portal environment that already has standalone LDAP configured, but either does not have a Property Extension database configured, or you do not intend to use the Property Extension database once in a cluster.

Note: The Deployment Manager should be configured for security using the out-of-the-box file registry. All references to “Dmgr Admin ID” and “Dmgr User Password” refer to the out-of-the-box user ID and password used for your deployment manager.

Security will be reconfigured for the entire cluster using standalone ldap at the end of this section.

Ensure the time on your Portal primary node is within 5 minutes of the time on your Deployment Manager (DMGR). Failure to do so will cause the addNode process to fail.
Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:

./startManager.sh
Stop WebSphere_Portal and server1 by executing the following commands from the <wp_profile root>/bin directory:

./stopServer.sh WebSphere_Portal -user <admin user> -password <admin pwd>
./stopServer.sh server1 -user <admin user> -password <admin pwd>
Execute the following command from the <wp_profile root>/bin to add the Portal node to the DMGR cell :

./addNode.sh <dmgr_hostname> <dmgr soap port> -username <dmgr admin ID> -password <dmgr user password> -includeapps -includebuses

For example:

./addNode.sh mydmgr.company.com 8879 -username wpadmin -password wppassword -includeapps -includebuses

NOTE: If you are not sure what your DMGR's soap port is, you can obtain it by logging into the DMGR and navigating to System Administration > Deployment Manager > Ports.

IMPORTANT: If the addNode script fails for any reason, you must complete the following steps before running addNode again:

Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):

Remove all Enterprise applications
Remove the WebSphere_Portal server definition
Remove the JDBC Provider information for WebSphere_Portal

Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:

./stopManager.sh -user <admin user> -password <admin pwd>
Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:

./startManager.sh
On the primary node, edit the <wp_profile>/ConfigEngine/properties/wkplc.properties file and ensure all of the following properties are set appropriately for your environment:

WasUserId=<DMGR admin user ID>
WasPassword=<DMGR admin password>
PortalAdminPwd=<password>
WasRemoteHostName=<fully qualified hostname of DMGR>
WasSoapPort=<soap port for DMGR; default is 8879>
ServerName=WebSphere_Portal
PrimaryNode=true
ClusterName=PortalCluster

NOTE: For the primary node, you must leave ServerName as WebSphere_Portal. Do not change it to any other value.
Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
Update the deployment manager configuration for the new WebSphere Portal server by executing the following ConfigEngine script:

/ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=<password>
Create the cluster definition and add the WebSphere_Portal server as a cluster member by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=<password>

Note: At this point, your WebSphere Portal environment will NOT function. This is because the Portal environment is now using the DMGR's security configuration, while Portal is expecting an LDAP to be configured. This will be corrected at the end of this section.
Ensure that the cluster definition was created correctly by logging into the DMGR Admin Console and browse to Server > Clusters > WebSphere Application Server Clusters. An entry for your Portal cluster should be present.\
At this point, even though your migrated Portal environment was using a standalone LDAP, the cluster is now configured with the DMGR's file repository. We must now reconfigure the entire cluster for the ldap.
Edit wkplc.properties and ensure that all of the standalone.ldap.* values are set for your LDAP. They should already be set since the Portal environment was previously configured with standalone ldap.
Execute the following ConfigEngine script validate the properties:

./ConfigEngine.sh validate-standalone-ldap -DWasPassword=<current DMGR password>
Execute the following ConfigEngine script to reconfigure security to use your LDAP:

./ConfigEngine.sh wp-modify-ldap-security -DWasPassword=<current DMGR password>
Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
Execute the following ConfigEngine script to check that all of the defined LDAP attributes are in the configured LDAP User Registry:

./ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=<DMGR LDAP password>
Verify Portal is functional by accessing it in your web browser:

http://myserver.mycompany.com:10039/wps/portal

You should now have a functional single-node Portal cluster with standalone ldap using a migrated Portal environment.

Standalone LDAP with Property Extension Database

In this section, you will federate a Portal environment that already has standalone LDAP configured with a property extension database. For the purposes of these steps, we will use DB2 as our property extension database.

Note: The Deployment Manager should be configured for security using the out-of-the-box file registry. All references to “Dmgr Admin ID” and “Dmgr User Password” refer to the out-of-the-box user ID and password used for your deployment manager.

The security will be reconfigured for the entire cluster using standalone ldap at the end of this section.

Ensure the time on your Portal primary node is within 5 minutes of the time on your Deployment Manager (DMGR). Failure to do so will cause the addNode process to fail.
On the WebSphere Portal node, make a backup of the following files and copy them to a temporary directory:

<wp_profile root>/config/cells/<cellname>/wim/config/wimconfig.xml
<wp_profile root>/config/cells/<cellname>/wim/model/wimextensions.xmi
Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:

./startManager.sh
Stop WebSphere_Portal and server1 by executing the following commands from the <wp_profile root>/bin directory:

./stopServer.sh WebSphere_Portal -user <admin user> -password <admin pwd>
./stopServer.sh server1 -user <admin user> -password <admin pwd>
Execute the following command from the <wp_profile root>/bin to add the Portal node to the DMGR cell :

./addNode.sh <dmgr_hostname> <dmgr soap port> -username <dmgr admin ID> -password <dmgr user password> -includeapps -includebuses

For example:

./addNode.sh mydmgr.company.com 8879 -username wpadmin -password wppassword -includeapps -includebuses

NOTE: If you are not sure what your DMGR's soap port is, you can obtain it by logging into the DMGR and navigating to System Administration > Deployment Manager > Ports.

IMPORTANT: If the addNode script fails for any reason, you must complete the following steps before running addNode again:

Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):

Remove all Enterprise applications
Remove the WebSphere_Portal server definition
Remove the JDBC Provider information for WebSphere_Portal

Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:

./stopManager.sh -user <admin user> -password <admin pwd>
Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:

./startManager.sh
On the primary node, edit the <wp_profile>/ConfigEngine/properties/wkplc.properties file and ensure all of the following properties are set appropriately for your enviornment:

WasUserId=<DMGR admin user ID>
WasPassword=<DMGR admin password>
PortalAdminPwd=<password>
WasRemoteHostName=<fully qualified hostname of DMGR>
WasSoapPort=<soap port for DMGR; default is 8879>
ServerName=WebSphere_Portal
PrimaryNode=true
ClusterName=PortalCluster
Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
Update the deployment manager configuration for the new WebSphere Portal server by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=<password>
Create the cluster definition and add the WebSphere_Portal server as a cluster member by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=<password>

Note: At this point, your WebSphere Portal environment will NOT function. This is because the Portal environment is now using the DMGR's security configuration, while Portal is expecting an LDAP to be configured. This will be corrected at the end of this section.
Ensure that the cluster definition was created correctly by logging into the DMGR Admin Console and browse to Server > Clusters > WebSphere Application Server Clusters. An entry for your Portal cluster should be present.
At this point, even though your migrated Portal environment was using a standalone LDAP, the cluster is now configured with the DMGR's file repository. We must now reconfigure the entire cluster for the ldap.
Edit wkplc.properties and ensure that all of the standalone.ldap.* values are set for your LDAP. They should already be set since the Portal environment was previously configured with standalone ldap.
Execute the following ConfigEngine script validate the properties:

./ConfigEngine.sh validate-standalone-ldap -DWasPassword=<current DMGR password>
Execute the following ConfigEngine script to reconfigure security to use your LDAP:

./ConfigEngine.sh wp-modify-ldap-security -DWasPassword=<current DMGR password>
Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
Copy the database drivers used by the Property Extension database repository on your migrated Portal to the Deployment Manager server. In this case we are using DB2, so we will copy db2jcc4.jar and db2jcc_license_cu.jar to some location on the DMGR server:

/opt/db2drivers/db2jcc4.jar
/opt/db2drivers/db2jcc_license_cu.jar
Edit the wkplc.properties file on the Portal server and ensure that the la.DbType property is set to your database type. In this guide, we are using DB2:

la.DbType=db2
Execute the following ConfigEngine command from the <wp_profile root>/ConfigEngine directory to set up the database driver libraries on the Deployment Manager:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=<password> -DDbDomain=la -Ddb_type.DmgrDbLibrary=<path to database drivers on DMGR> -DDmgrNodeName=dmgr_node_name

where db_type is the database type of the database holding your VMM data and dmgr_node_name is the name of your Deployment Manager node. In our case, the db_type is db2, and the name of the Deployment Manager node is dmgrNode. For this guide, our command looks like:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=wasadmin -DDbDomain=la -Ddb2.DmgrDbLibrary=/opt/IBM/db2drivers/db2jcc4.jar:/opt/db2drivers/db2jcc_license_cu.jar -DDmgrNodeName=dmgrNode
Copy the backed up wimconfig.xml and wimextensions.xmi files that you made in Step 2 to the DMGR and place them in the following locations (removing the original files from the DMGR):

<dmgr_profile root>/config/cells/dmgrCell/wim/config/wimconfig.xml
<dmgr_profile root>/config/cells/dmgrCell/wim/model/wimextensions.xmi
Synchronize the node and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
Execute the following ConfigEngine script to check that all of the defined LDAP attributes are in the configured LDAP User Registry:

./ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=<DMGR LDAP password>
Verify Portal is functional by accessing it in your web browser:

http://myserver.mycompany.com:10039/wps/portal

You should now have a functional single-node Portal cluster using a migrated Portal environment.

Federated LDAP

In this section, you will federate a Portal environment that already has a federated LDAP configured, but either does not have a Property Extension database or Database User Repository configured, or you do not intend to use these in your cluster.

Before creating a cluster with your migrated Portal environment, you first must configure the Deployment Manager to use a federated LDAP security repository. You should use the same LDAP that your Portal is configured to, and set the Primary Administrator ID to be the same as your Portal's WAS administrator ID.

For details on how to configure security in the Deployment Manager, refer to the WebSphere Application Server Information Center:

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
Ensure the time on your Portal primary node is within 5 minutes of the time on your Deployment Manager (DMGR). Failure to do so will cause the addNode process to fail.
Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:

./startManager.sh
Stop WebSphere_Portal and server1 by executing the following commands from the <wp_profile root>/bin directory:

./stopServer.sh WebSphere_Portal -user <admin user> -password <admin pwd>
./stopServer.sh server1 -user <admin user> -password <admin pwd>
Execute the following command from the <wp_profile root>/bin to add the Portal node to the DMGR cell :

./addNode.sh <dmgr_hostname> <dmgr soap port> -username <dmgr admin ID> -password <dmgr user password> -includeapps -includebuses

For example:

./addNode.sh mydmgr.company.com 8879 -username wpadmin -password wppassword -includeapps -includebuses

NOTE: If you are not sure what your DMGR's soap port is, you can obtain it by logging into the DMGR and navigating to System Administration > Deployment Manager > Ports.

IMPORTANT: If the addNode script fails for any reason, you must complete the following steps before running addNode again:

Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):

Remove all Enterprise applications
Remove the WebSphere_Portal server definition
Remove the JDBC Provider information for WebSphere_Portal

Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:

./stopManager.sh -user <admin user> -password <admin pwd>
Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:

./startManager.sh
On the primary node, edit the <wp_profile>/ConfigEngine/properties/wkplc.properties file and ensure all of the following properties are set appropriately for your enviornment:

WasUserId=<DMGR admin user ID>
WasPassword=<DMGR admin password>
PortalAdminPwd=<password>
WasRemoteHostName=<fully qualified hostname of DMGR>
WasSoapPort=<soap port for DMGR; default is 8879>
ServerName=WebSphere_Portal
PrimaryNode=true
ClusterName=PortalCluster

NOTE: For the primary node, you must leave ServerName as WebSphere_Portal. Do not change it to any other value.
Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
Update the deployment manager configuration for the new WebSphere Portal server by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=<password>
Create the cluster definition and add the WebSphere_Portal server as a cluster member by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=<password>
Synchronize the node and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
Ensure that the cluster definition was created correctly by logging into the DMGR Admin Console and browse to Server ->}}} Clusters ->}}} WebSphere Application Server Clusters. An entry for your Portal cluster should be present.
Verify Portal is functional by accessing it in your web browser:

http://myserver.mycompany.com:10039/wps/portal

You should now have a functional single-node Portal cluster using a migrated Portal environment.

Federated LDAP with Property Extension Database

In this section, you will federate a Portal environment that already has a federated LDAP configured with a Property Extension database. For the purposes of these steps, we will use DB2 as our Property Extension database.

Before creating a cluster with your migrated Portal environment, you first must configure the Deployment Manager to use a federated LDAP security repository. You should use the same LDAP that your Portal is configured to, and set the Primary Administrator ID to be the same as your Portal's WAS administrator ID.

For details on how to configure security in the Deployment Manager, refer to the WebSphere Application Server Information Center:

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
On the WebSphere Portal node, make a backup of the following files and copy them to a temporary directory:

<wp_profile root>/config/cells/<cellname>/wim/config/wimconfig.xml
<wp_profile root>/config/cells/<cellname>/wim/model/wimextensions.xmi
Ensure the time on your Portal primary node is within 5 minutes of the time on your Deployment Manager (DMGR). Failure to do so will cause the addNode process to fail.
Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:

./startManager.sh
Stop WebSphere_Portal and server1 by executing the following commands from the <wp_profile root>/bin directory:

./stopServer.sh WebSphere_Portal -user <admin user> -password <admin pwd>
./stopServer.sh server1 -user <admin user> -password <admin pwd>
Execute the following command from the <wp_profile root>/bin to add the Portal node to the DMGR cell :

./addNode.sh <dmgr_hostname> <dmgr soap port> -username <dmgr admin ID> -password <dmgr user password> -includeapps -includebuses

For example:

./addNode.sh mydmgr.company.com 8879 -username wpadmin -password wppassword -includeapps -includebuses

NOTE: If you are not sure what your DMGR's soap port is, you can obtain it by logging into the DMGR and navigating to System Administration > Deployment Manager > Ports.

IMPORTANT: If the addNode script fails for any reason, you must complete the following steps before running addNode again:

Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):

Remove all Enterprise applications
Remove the WebSphere_Portal server definition
Remove the JDBC Provider information for WebSphere_Portal

Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:

./stopManager.sh -user <admin user> -password <admin pwd>
Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:

./startManager.sh
On the primary node, edit the <wp_profile>/ConfigEngine/properties/wkplc.properties file and ensure all of the following properties are set appropriately for your enviornment:

WasUserId=<DMGR admin user ID>
WasPassword=<DMGR admin password>
PortalAdminPwd=<password>
WasRemoteHostName=<fully qualified hostname of DMGR>
WasSoapPort=<soap port for DMGR; default is 8879>
ServerName=WebSphere_Portal
PrimaryNode=true
ClusterName=PortalCluster

NOTE: For the primary node, you must leave ServerName as WebSphere_Portal. Do not change it to any other value.
Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
Update the deployment manager configuration for the new WebSphere Portal server by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=<password>
Create the cluster definition and add the WebSphere_Portal server as a cluster member by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=<password>

Note: At this point, your WebSphere Portal environment may NOT function correctly. This is because the Portal environment is now using the DMGR's security configuration. If your Portal environment dependeds on Lookaside data or the property extension database, then the DMGR is currently not configured for this. This will be corrected in the next set of steps.
Copy the database drivers used by the Property Extension database on your migrated Portal to the Deployment Manager server. In this case we are using DB2, so we will copy db2jcc4.jar and db2jcc_license_cu.jar to some location on the DMGR server:

/opt/db2drivers/db2jcc4.jar
/opt/db2drivers/db2jcc_license_cu.jar
Edit the wkplc.properties file on the Portal server and ensure that the la.DbType property is set to your database type. In this guide, we are using DB2:

la.DbType=db2
Execute the following ConfigEngine command from the <wp_profile root>/ConfigEngine directory to set up the database driver libraries on the Deployment Manager:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=<password> -DDbDomain=la -Ddb_type.DmgrDbLibrary=<path to database drivers on DMGR> -DDmgrNodeName=dmgr_node_name

where db_type is the database type of the database holding your VMM data and dmgr_node_name is the name of your Deployment Manager node. In our case, the db_type is db2, and the name of the Deployment Manager node is dmgrNode. For this guide, our command looks like:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=wasadmin -DDbDomain=la -Ddb2.DmgrDbLibrary=/opt/IBM/db2drivers/db2jcc4.jar:/opt/db2drivers/db2jcc_license_cu.jar -DDmgrNodeName=dmgrNode
Copy the backed up wimconfig.xml and wimextensions.xmi files that you made in Step 2 to the DMGR and place them in the following locations (removing the original files from the DMGR):

<dmgr_profile root>/config/cells/dmgrCell/wim/config/wimconfig.xml
<dmgr_profile root>/config/cells/dmgrCell/wim/model/wimextensions.xmi
Synchronize the nodes and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
Ensure that the cluster definition was created correctly by logging into the DMGR Admin Console and browse to Server >}}} Clusters >}}} WebSphere Application Server Clusters. An entry for your Portal cluster should be present.
Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
Verify Portal is functional by accessing it in your web browser:

http://myserver.mycompany.com:10039/wps/portal

You should now have a functional single-node Portal cluster using a migrated Portal environment.

Federated LDAP with Database User Registry

In this section, you will federate a Portal environment that already has a federated LDAP configured with a Database User Registry. For the purposes of these steps, we will use DB2 as our Database User Registry.

Before creating a cluster with your migrated Portal environment, you first must configure the Deployment Manager to use a federated LDAP security repository. You should use the same LDAP that your Portal is configured to, and set the Primary Administrator ID to be the same as your Portal's WAS administrator ID.

For details on how to configure security in the Deployment Manager, refer to the WebSphere Application Server Information Center:

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
On the WebSphere Portal node, make a backup of the following files and copy them to a temporary directory:

<wp_profile root>/config/cells/<cellname>/wim/config/wimconfig.xml
<wp_profile root>/config/cells/<cellname>/wim/model/wimextensions.xmi
Ensure the time on your Portal primary node is within 5 minutes of the time on your Deployment Manager (DMGR). Failure to do so will cause the addNode process to fail.
Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:

./startManager.sh
Stop WebSphere_Portal and server1 by executing the following commands from the <wp_profile root>/bin directory:

./stopServer.sh WebSphere_Portal -user <admin user> -password <admin pwd>
./stopServer.sh server1 -user <admin user> -password <admin pwd>
Execute the following command from the <wp_profile root>/bin to add the Portal node to the DMGR cell :

./addNode.sh <dmgr_hostname> <dmgr soap port> -username <dmgr admin ID> -password <dmgr user password> -includeapps -includebuses

For example:

./addNode.sh mydmgr.company.com 8879 -username wpadmin -password wppassword -includeapps -includebuses

NOTE: If you are not sure what your DMGR's soap port is, you can obtain it by logging into the DMGR and navigating to System Administration > Deployment Manager > Ports.

IMPORTANT: If the addNode script fails for any reason, you must complete the following steps before running addNode again:

Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):

Remove all Enterprise applications
Remove the WebSphere_Portal server definition
Remove the JDBC Provider information for WebSphere_Portal

Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:

./stopManager.sh -user <admin user> -password <admin pwd>
Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:

./startManager.sh
On the primary node, edit the <wp_profile>/ConfigEngine/properties/wkplc.properties file and ensure all of the following properties are set appropriately for your enviornment:

WasUserId=<DMGR admin user ID>
WasPassword=<DMGR admin password>
PortalAdminPwd=<password>
WasRemoteHostName=<fully qualified hostname of DMGR>
WasSoapPort=<soap port for DMGR; default is 8879>
ServerName=WebSphere_Portal
PrimaryNode=true
ClusterName=PortalCluster

NOTE: For the primary node, you must leave ServerName as WebSphere_Portal. Do not change it to any other value.
Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
Update the deployment manager configuration for the new WebSphere Portal server by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=<password>
Create the cluster definition and add the WebSphere_Portal server as a cluster member by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=<password>

Note: At this point, your WebSphere Portal environment may NOT function correctly. This is because the Portal environment is now using the DMGR's security configuration. If your Portal environment dependeds on Lookaside data or the property extension database, then the DMGR is currently not configured for this. This will be corrected in the next set of steps.
Copy the database drivers used by the Database User repository on your migrated Portal to the Deployment Manager server. In this case we are using DB2, so we will copy db2jcc4.jar and db2jcc_license_cu.jar to some location on the DMGR server:

/opt/db2drivers/db2jcc4.jar
/opt/db2drivers/db2jcc_license_cu.jar
Edit the wkplc.properties file on the Portal server and ensure that the federated.db.DbType property is set to your database type. In this guide, we are using DB2:

federated.db.DbType=db2
Execute the following ConfigEngine command from the <wp_profile root>/ConfigEngine directory to set up the database driver libraries on the Deployment Manager:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=<password> -DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=<path to database drivers on DMGR> -DDmgrNodeName=dmgr_node_name

where db_type is the database type of the database holding your VMM data and dmgr_node_name is the name of your Deployment Manager node. In our case, the db_type is db2, and the name of the Deployment Manager node is dmgrNode. For this guide, our command looks like:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=wasadmin -DDbDomain=federated.db -Ddb2.DmgrDbLibrary=/opt/IBM/db2drivers/db2jcc4.jar:/opt/db2drivers/db2jcc_license_cu.jar -DDmgrNodeName=dmgrNode
Copy the backed up wimconfig.xml and wimextensions.xmi files that you made in Step 2 to the DMGR and place them in the following locations (removing the original files from the DMGR):

<dmgr_profile root>/config/cells/dmgrCell/wim/config/wimconfig.xml
<dmgr_profile root>/config/cells/dmgrCell/wim/model/wimextensions.xmi
Synchronize the nodes and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
Ensure that the cluster definition was created correctly by logging into the DMGR Admin Console and browse to Server > Clusters > WebSphere Application Server Clusters. An entry for your Portal cluster should be present
Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
Verify Portal is functional by accessing it in your web browser:

http://myserver.mycompany.com:10039/wps/portal

You should now have a functional single-node Portal cluster using a migrated Portal environment.

Federated LDAP with Property Extension Database and Database User Registry

In this section, you will federate a Portal environment that already has a federated LDAP configured with a Property Extension database and a Database User Registry. For the purposes of these steps, we will use DB2 as our Property Extension database and Database User Registry.

Before creating a cluster with your migrated Portal environment, you first must configure the Deployment Manager to use a federated LDAP security repository. You should use the same LDAP that your Portal is configured to, and set the Primary Administrator ID to be the same as your Portal's WAS administrator ID.

For details on how to configure security in the Deployment Manager, refer to the WebSphere Application Server Information Center:

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
On the WebSphere Portal node, make a backup of the following files and copy them to a temporary directory:

<wp_profile root>/config/cells/<cellname>/wim/config/wimconfig.xml
<wp_profile root>/config/cells/<cellname>/wim/model/wimextensions.xmi
Ensure the time on your Portal primary node is within 5 minutes of the time on your Deployment Manager (DMGR). Failure to do so will cause the addNode process to fail.
Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:

./startManager.sh
Stop WebSphere_Portal and server1 by executing the following commands from the <wp_profile root>/bin directory:

./stopServer.sh WebSphere_Portal -user <admin user> -password <admin pwd>
./stopServer.sh server1 -user <admin user> -password <admin pwd>
Execute the following command from the <wp_profile root>/bin to add the Portal node to the DMGR cell :

./addNode.sh <dmgr_hostname> <dmgr soap port> -username <dmgr admin ID> -password <dmgr user password> -includeapps -includebuses

For example:

./addNode.sh mydmgr.company.com 8879 -username wpadmin -password wppassword -includeapps -includebuses

NOTE: If you are not sure what your DMGR's soap port is, you can obtain it by logging into the DMGR and navigating to System Administration > Deployment Manager > Ports.

IMPORTANT: If the addNode script fails for any reason, you must complete the following steps before running addNode again:

Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):

Remove all Enterprise applications
Remove the WebSphere_Portal server definition
Remove the JDBC Provider information for WebSphere_Portal

Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:

./stopManager.sh -user <admin user> -password <admin pwd>
Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:

./startManager.sh
On the primary node, edit the <wp_profile>/ConfigEngine/properties/wkplc.properties file and ensure all of the following properties are set appropriately for your enviornment:

WasUserId=<DMGR admin user ID>
WasPassword=<DMGR admin password>
PortalAdminPwd=<password>
WasRemoteHostName=<fully qualified hostname of DMGR>
WasSoapPort=<soap port for DMGR; default is 8879>
ServerName=WebSphere_Portal
PrimaryNode=true
ClusterName=PortalCluster

NOTE: For the primary node, you must leave ServerName as WebSphere_Portal. Do not change it to any other value.
Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
Update the deployment manager configuration for the new WebSphere Portal server by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=<password>
Create the cluster definition and add the WebSphere_Portal server as a cluster member by executing the following ConfigEngine script:

./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=<password>

Note: At this point, your WebSphere Portal environment may NOT function correctly. This is because the Portal environment is now using the DMGR's security configuration. If your Portal environment dependeds on Lookaside data or the property extension database, then the DMGR is currently not configured for this. This will be corrected in the next set of steps.
Copy the database drivers used by the Database User repository on your migrated Portal to the Deployment Manager server. In this case we are using DB2, so we will copy db2jcc4.jar and db2jcc_license_cu.jar to some location on the DMGR server:

/opt/db2drivers/db2jcc4.jar
/opt/db2drivers/db2jcc_license_cu.jar
Edit the wkplc.properties file on the Portal server and ensure that the la.DbType and federated.db.DbType properties are set to your database type. In this guide, we are using DB2:

la.DbType=db2
federated.db.DbType=db2
Execute the following ConfigEngine command from the <wp_profile root>/ConfigEngine directory to set up the database driver libraries on the Deployment Manager for the Property Extension database:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=<password> -DDbDomain=la -Ddb_type.DmgrDbLibrary=<path to database drivers on DMGR> -DDmgrNodeName=dmgr_node_name

where db_type is the database type of the database holding your VMM data and dmgr_node_name is the name of your Deployment Manager node. In our case, the db_type is db2, and the name of the Deployment Manager node is dmgrNode. For this guide, our command looks like:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=wasadmin -DDbDomain=la -Ddb2.DmgrDbLibrary=/opt/IBM/db2drivers/db2jcc4.jar:/opt/db2drivers/db2jcc_license_cu.jar -DDmgrNodeName=dmgrNode
Execute the following ConfigEngine command from the <wp_profile root>/ConfigEngine directory to set up the database driver libraries on the Deployment Manager for the Database User Registry:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=<password> -DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=<path to database drivers on DMGR> -DDmgrNodeName=dmgr_node_name

where db_type is the database type of the database holding your VMM data and dmgr_node_name is the name of your Deployment Manager node. In our case, the db_type is db2, and the name of the Deployment Manager node is dmgrNode. For this guide, our command looks like:

./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=wasadmin -DDbDomain=federated.db -Ddb2.DmgrDbLibrary=/opt/IBM/db2drivers/db2jcc4.jar:/opt/db2drivers/db2jcc_license_cu.jar -DDmgrNodeName=dmgrNode

NOTE: The difference between this step and the previous step is the value for -DDbDomain. One is “la” and the other is “federated.db”. Otherwise both steps are identical.
Copy the backed up wimconfig.xml and wimextensions.xmi files that you made in Step 2 to the DMGR and place them in the following locations (removing the original files from the DMGR):

<dmgr_profile root>/config/cells/dmgrCell/wim/config/wimconfig.xml
<dmgr_profile root>/config/cells/dmgrCell/wim/model/wimextensions.xmi
Synchronize the nodes and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
Ensure that the cluster definition was created correctly by logging into the DMGR Admin Console and browse to Server > Clusters > WebSphere Application Server Clusters. An entry for your Portal cluster should be present.
Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
Verify Portal is functional by accessing it in your web browser:

http://myserver.mycompany.com:10039/wps/portal