ShowTable of Contents
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
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.
http://myserver.mycompany.com:10039/wps/portal
NOTE: If you had completed any advanced security configurations in your standalone Portal, such as configuring SSL or TAI, then you will need to redo those at this time in the Deployment Manager.
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.
http://myserver.mycompany.com:10039/wps/portal
NOTE: If you had completed any advanced security configurations in your standalone Portal, such as configuring SSL or TAI, then you will need to redo those at this time in the Deployment Manager.
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.
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
NOTE: If you had removed the default file registry in the standalone Portal server, then you will also need to do this in the Deployment Manager at this time.
2. 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.
3. Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:
./startManager.sh
4. 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>
5. 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:
a. Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
b. Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):
-
i. Remove all Enterprise applications
ii. Remove the WebSphere_Portal server definition
iii. Remove the JDBC Provider information for WebSphere_Portal
6. Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:
./stopManager.sh -user <admin user> -password <admin pwd>
7. Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:
./startManager.sh
8. 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.
9. Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
10. 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>
11. 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>
12. Synchronize the node and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
13. 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.
14. Verify Portal is functional by accessing it in your web browser:
http://myserver.mycompany.com:10039/wps/portal
NOTE: If you had completed any advanced security configurations in your standalone Portal, such as configuring SSL or TAI, then you will need to redo those at this time in the Deployment Manager.
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.
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
NOTE: If you had removed the default file registry in the standalone Portal server, then you will also need to do this in the Deployment Manager at this time.
2. 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/wimxmlextensions.xml
3. 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.
4. Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:
./startManager.sh
5. 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>
6. 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:
a. Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
b. Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):
-
i. Remove all Enterprise applications
ii. Remove the WebSphere_Portal server definition
iii. Remove the JDBC Provider information for WebSphere_Portal
7. Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:
./stopManager.sh -user <admin user> -password <admin pwd>
8. Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:
./startManager.sh
9. 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.
10. Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
11. 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>
12. 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.
13. 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
14. 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
15. 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
16. Copy the backed up wimconfig.xml and wimxmlextensions.xml 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/wimxmlextensions.xml
17. Synchronize the nodes and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
18. 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.
19. Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
20. Verify Portal is functional by accessing it in your web browser:
http://myserver.mycompany.com:10039/wps/portal
NOTE: If you had completed any advanced security configurations in your standalone Portal, such as configuring SSL or TAI, then you will need to redo those at this time in the Deployment Manager.
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.
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
NOTE: If you had removed the default file registry in the standalone Portal server, then you will also need to do this in the Deployment Manager at this time.
2. 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/wimxmlextensions.xml
3. 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.
4. Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:
./startManager.sh
5. 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>
6. 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:
a. Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
b. Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):
-
i. Remove all Enterprise applications
ii. Remove the WebSphere_Portal server definition
iii. Remove the JDBC Provider information for WebSphere_Portal
7. Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:
./stopManager.sh -user <admin user> -password <admin pwd>
8. Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:
./startManager.sh
9. 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.
10. Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
11. 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>
12. 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.
13. 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
14. 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
15. 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
16. Copy the backed up wimconfig.xml and wimxmlextensions.xml 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/wimxmlextensions.xml
17. Synchronize the nodes and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
18. 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
19. Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
20. Verify Portal is functional by accessing it in your web browser:
http://myserver.mycompany.com:10039/wps/portal
NOTE: If you had completed any advanced security configurations in your standalone Portal, such as configuring SSL or TAI, then you will need to redo those at this time in the Deployment Manager.
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.
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_csec2.html
NOTE: If you had removed the default file registry in the standalone Portal server, then you will also need to do this in the Deployment Manager at this time.
2. 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/wimxmlextensions.xml
3. 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.
4. Ensure the DMGR is started. On the DMGR server, execute the following command from the <dmgr_profile>/bin directory:
./startManager.sh
5. 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>
6. 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:
a. Remove the node from the DMGR cell in case AddNode successfully completed that step before failing.
b. Login to the DMGR and do the following (these may not exist, depending on where the failure occurred):
-
i. Remove all Enterprise applications
ii. Remove the WebSphere_Portal server definition
iii. Remove the JDBC Provider information for WebSphere_Portal
7. Stop the deployment manager by issuing the following command from the <dmgr profile>/bin directory:
./stopManager.sh -user <admin user> -password <admin pwd>
8. Start the deployment manager by issuing the following command from the <dmgr profile root>/bin directory:
./startManager.sh
9. 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.
10. Edit <wp_profile>/ConfigEngine/properties/wkplc_comp.properties and ensure all database user IDs and passwords are accurate.
11. 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>
12. 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.
13. 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
14. 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
15. 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
16. 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.
17. Copy the backed up wimconfig.xml and
wimxmlextensions.xml 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/wimxmlextensions.xml
18. Synchronize the nodes and restart the Deployment Manager, NodeAgent, and WebSphere_Portal server.
19. 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.
20. Restart the DMGR, NodeAgent, and WebSphere_Portal servers.
21. Verify Portal is functional by accessing it in your web browser:
http://myserver.mycompany.com:10039/wps/portal
NOTE: If you had completed any advanced security configurations in your standalone Portal, such as configuring SSL or TAI, then you will need to redo those at this time in the Deployment Manager.
You should now have a functional single-node Portal cluster using a migrated Portal environment.