Migrating a WebSphere Portal cluster to WebSphere Application Server V9.0

You can migrate your IBM® WebSphere® Portal profile to IBM WebSphere Application Server Version 9.0.0.2 or higher. Two options exist for this migration process: local or remote. For a local migration only: Install the latest WebSphere Application Server version on the same server where WebSphere Portal V9 is installed. For a remote migration only: Install WebSphere Portal V9 with the latest IBM WebSphere Application Server on a separate server, which will be the target server for the migration. In both scenarios, make a copy of the source database to use on the target server. The remote migration is a better option because it leaves the source migration environment intact. For a local migration, the source migration profile is no longer usable after the migration.

1. Install WebSphere Application Server v9.0.0.2 on the DMGR target migration server.
   Tip: Ensure that WebSphere Portal V9 and the WebSphere binary files for each cluster node are also installed.
   Important: For a remote migration only: Use the same WebSphere Application Server installation directory path as the source server.
2. Complete the following steps to migrate the Deployment Manager:
   1. On the DMGR target migration server, create a DMGR profile by using the manageprofiles command-line option.
      Important:

      • Use the exact same cell name and node name that you used for the WebSphere Application Server v8.5.5 or higher DMGR installation.
      • AIX®: ./manageprofiles.sh -create -profileName v90_dmgr_profile_name -profilePath v90_dmgr_profile_path -templatePath v90_was_root_path/profile Templates/management -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault
      • Linux: ./manageprofiles.sh -create -profileName v90_dmgr_profile_name -profilePath v90_dmgr_profile_path -templatePath v90_was_root_path/profile Templates/management -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault
      • Windows: manageprofiles.bat -create -profileName v90_dmgr_profile_name -profilePath v90_dmgr_profile_path -templatePath v90_was_root_path/profile Templates/management -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault
      Where the following values are set:

      source_node_name

      The node name on the source installation.

      source_cell_name

      The cell name on the source installation.

      host_name

      The host name of the environment.

   2. Open a command prompt.
      Note: If you are instructed to open a properties file, they are ASCII files. Open them with the appropriate tool.
   3. Copy the PortalServer/filesForDmgr/filesForDmgr.zip file from the primary WebSphere Portal node to the WebSphere Application Server v9.0 DMGR server and extract it into the v90_was_root_path directory.
   4. Ensure OSGi cache was cleared from the new WebSphere Application Server v9.0 installation by running the following command from the v90_dmgr_profile_name/bin directory:
      • AIX: ./osgiCfgInit.sh -all
      • Linux: ./osgiCfgInit.sh -all
      • Windows: osgiCfgInit -all
   5. For a remote migration only: On the WebSphere Application Server V9.0 DMGR server, run the following command to create the WAS_V90_RemoteMigrSupport.jar file.
      • AIX: cd v90_was_root_path/bin/migration/bin ./createRemoteMigrJar.sh -targetDir remote_zip_dir
      • Linux: cd v90_was_root_path/bin/migration/bin ./createRemoteMigrJar.sh -targetDir remote_zip_dir
      • Windows: cd v90_was_root_path\bin\migration\bin createRemoteMigrJar.bat -targetDir remote_zip_dir

      Where remote_zip_dir is an existing directory that is used to contain the generated file. Make sure that you specify the full path to the directory. Copy the WAS_V90_RemoteMigrSupport.jar file from the WebSphere Application Server V9 DMGR target server to the WebSphere Application Server DMGR source server. Extract the JAR file into a working directory. For example, run unzip WAS_V90_RemoteMigrSupport.jar.

      Linux only: Ensure that read and run permissions are set on the extracted files. For example, run chmod -R 755 supp_dir.
   6. The WASPreUpgrade and WASPostUpgrade commands that are used in WebSphere Portal migration use much memory and might result in an OutOfMemoryException. To prevent this issue from happening, complete the following steps:
      1. Ensure that you are using a large enough heap size. Generally, using 2 GB heap size is sufficient, specified by using the -javaoption -Xmx2048m variable when you run WASPreUpgrade or WASPostUpgrade commands. Increase the Heap Size by increasing the -Xmx2048m variable. A possible value might be -Xmx4096m.
      2. Ensure that the size of the Deployment Manager profile was minimized by deleting unnecessary files. In most cases, the Deployment Manager profile (Dmgr01) should not be larger than 2 GB. It is a good idea to do a search for files larger than 10 MB to find any possible files that can be contributing to a large profile size.
         For example:

         • In Linux you can use the following command to find files larger than 10 MB: > find . -type f -size +10000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'.
         • In Windows, you can run the following search in Windows Explorer: *.* size:> 10MB
   7. Set the file descriptor limit to at least 20480.

      ulimit -n 20480

   8. Set the stack limit to at least 65536.

      ulimit -s 65536

   9. AIX only: Use the following steps to increase the maximum length of the command line with environment variables:
      1. Run the following command to query the system attributes:

         lsattr -EH -l sys0 | grep ncargs

         The command returns a value similar to the following example:

         ncargs  256  ARG/ENV list size in 4K byte blocks  True

      2. If the ncargs value is less than 512, run the following command to increase the value:

         chdev -l sys0 -a ncargs=1024

   10. Stop the Deployment Manager server before you run the WASPreUpgrade command.
   11. For a local migration only: Run the WASPreUpgrade command from the v90_was_root_path/bin directory. For a remote migration only: Run the WASPreUpgrade command from the working_directory/bin directory that contains the remote migration package copied earlier. For a remote migration only: Add the extra parameter -machineChange true.
       • AIX: ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd
       • Linux: ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd
       • Windows: WASPreUpgrade.bat temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd
       Where the following values are set:

       temp_dir

       Temporary directory where the backup is stored.

       Note:

       • For Windows, Windows, the temp_dir cannot have spaces in the path.

       For example, your command on might look like: ./WASPreUpgrade.sh /opt/IBM/wasMigrateBackup /opt/IBM/WebSphere/AppServer -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd

   12. For a remote migration only: Compress and copy the backup created by the WASPreUpgrade command from the DMGR source server to the DMGR target server. For a local migration only: Use the backup image made with WasPreUpgrade on the local server. From the v90_was_root_path/bin directory, run the WASPostUpgrade command to migrate the backed-up source profile into the new profile:
       Note: If security is enabled on your profile, add the -username was_userid -password was_userid_password parameters to your WASPostUpgrade task.
       • AIX: ./WASPostUpgrade.sh temp_dir -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
       • Linux: ./WASPostUpgrade.sh temp_dir -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
       • Windows: WASPostUpgrade.bat temp_dir -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
       For example, your command might look like: ./WASPostUpgrade.sh /opt/IBM/wasMigratedBackup -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
       If the WASPreUpgrade was successful, but the WASPostUpgrade command results in an error, complete the following steps:

       1. Verify that only one profile is in the backup profile.
       2. Consider deleting Search Collection to decrease the data size.
       3. Move JCR Data during migration.
          Note: The Java™ Content Repository might store index-related files in subdirectories in the WebSphere profile, such as jcr, that can use much space. This data is not altered by the migration process, so it can be temporarily moved out of the old profile or the backup directory in preparation for migration. Move the directory into the new profile after migration completes.
       4. Ensure that no paths contain the ":" character. This character might cause problems for WASPreUpgrade and WASPostUpgrade commands.
       Important: After you run WASPostUpgrade on the Deployment Manager or WebSphere Portal node, log in to the WebSphere Integrated Solutions Console and verify that AutoSync is off.
   13. Open a command prompt and change to the v90_dmgr_profile_path/bin/ directory.
   14. Run the following command to start the Deployment Manager:
       • AIX: ./startManager.sh
       • Linux: ./startManager.sh
       • Windows: startManager.bat
3. Complete the following steps for each WebSphere Portal node you have in your cluster.
   1. On the WebSphere Application Server v9.0 target migration server installation, create a new base profile by using the manageprofiles command-line option. For a remote migration only: First delete the existing wp_profile that was created during the full installation of WebSphere Portal v9 on the target migration server.
      • AIX: ./manageprofiles.sh -create -defaultPorts -enableAdminSecurity false -profileName v90_wp_profile_name -profilePath v90_wp_profile_path -templatePath v90_was_root_path/profileTemplates/managed -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig default AppDeployAndConfig
      • Linux: ./manageprofiles.sh -create -defaultPorts -enableAdminSecurity false -profileName v90_wp_profile_name -profilePath v90_wp_profile_path -templatePath v90_was_root_path/profileTemplates/managed -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig default AppDeployAndConfig
      • Windows: manageprofiles.bat -create -defaultPorts -enableAdminSecurity false -profileName v90_wp_profile_name -profilePath v90_wp_profile_path -templatePath v90_was_root_path/profileTemplates/managed -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig default AppDeployAndConfig
      Where the following values are set:

      source_node_name

      The node name on the source installation.

      source_cell_name

      The cell name on the source installation.

      host_name

      The host name of the environment.

      Important:

      • Use the exact same cell name and node name that you used for the WebSphere Portal and WebSphere Application Server v8.5.5 or higher installation.
   2. Open a command prompt.
      Note: If you are instructed to open a properties file, they are ASCII files. Open them with the appropriate tool.
   3. For a local migration only: Run the following install-wp-migration-files command from the v85_wp_profile_path/ConfigEngine directory to install WebSphere Portal-specific files into the WebSphere Application Server v9.0 installation.
      Note: Ensure that the file folder that contains the source binary files is read/write enabled. If the folder is read only, the install-wp-migration-files command fails.
      • AIX: ./ConfigEngine.sh install-wp-migration-files -DNewWasLocation=v90_was_root_path -DWasPassword=password
      • Linux: ./ConfigEngine.sh install-wp-migration-files -DNewWasLocation=v90_was_root_path -DWasPassword=password
      • Windows: ConfigEngine.bat install-wp-migration-files -DNewWasLocation=v90_was_root_path -DWasPassword=password
      Note:

      • If this step fails, ConfigEngine might not be working. To fix this error, restore the ConfigEngine.migration.bak file that was created in the ConfigEngine root directory. Change ConfigEngine.migration.bak to ConfigEngine.sh or ConfigEngine.bat, depending on your operating system.
        Note: If ConfigEngine.migration.bak was not created, the failure occurred before the file was changed. Therefore, ConfigEngine should work.
   4. For a local migration only: Copy the jndi.properties file from the v85_was_root_path/properties directory to the v90_was_root_path/properties directory specified by the DNewWasLocation command.
   5. Ensure OSGi cache was cleared from the new WebSphere Application Server v9.0 installation by running the following command from the v90_wp_profile_path/bin directory:
      • AIX: ./osgiCfgInit.sh -all
      • Linux: ./osgiCfgInit.sh -all
      • Windows: osgiCfgInit -all
   6. For a remote migration only: On the WebSphere Portal V9.0 server, run the following command to create the PORTAL_V8.5.0.0_WAS_V90_OS.arch_RemoteMigrSupport.jar file. For example, the file might be PORTAL_V8.5.0.0_WAS_V90_windows.x86_RemoteMigrSupport.jar.
      • AIX: cd PortalServer_root/bin ./genRemMigPkg.sh remote_zip_dir
      • Linux: cd PortalServer_root/bin ./genRemMigPkg.sh remote_zip_dir
      • Windows: cd PortalServer_root\bin genRemMigPkg.bat remote_zip_dir

      Where remote_zip_dir is an existing directory that is used to contain the generated file. Make sure that you specify the full path to the directory. Copy the PORTAL_V8.5.0.0_WAS_V90_OS.arch_RemoteMigrSupport.jar file from the WebSphere Portal V9 target server to the WebSphere Portal source server. Extract the JAR file into a working directory. For example, extract PORTAL_V8.5.0.0_WAS_V90_linux.amd64_RemoteMigrSupport.jar.

   7. Complete the following steps to prepare the WebSphere Portal profile for the WASPreUpgrade command.
      1. Uninstall any unneeded applications.
      2. Delete backup and uninstalled applications.
      3. Delete any old large log files or temp files that are no longer needed. If necessary, stop the WebSphere Portal server. Common temp file locations are:
         • v85_wp_profile_path/temp/
         • v85_wp_profile_path/wstemp/
         • v85_wp_profile_path/config/temp/
   8. The WASPreUpgrade and WASPostUpgrade commands that are used in WebSphere Portal migration use much memory and might result in an OutOfMemoryException. To prevent this issue from happening, complete the following steps:
      1. Ensure that you are using a large enough heap size. Generally, using 2 GB heap size is sufficient, specified by using the -javaoption -Xmx2048m variable when you run WASPreUpgrade or WASPostUpgrade commands. Increase the Heap Size by increasing the -Xmx2048m variable. A possible value might be -Xmx4096m.
      2. Ensure that the size of the Deployment Manager profile was minimized by deleting unnecessary files. In most cases, the Deployment Manager profile (Dmgr01) should not be larger than 2 GB. It is a good idea to do a search for files larger than 10 MB to find any possible files that can be contributing to a large profile size.
         For example:

         • In Linux you can use the following command to find files larger than 10 MB: > find . -type f -size +10000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'.
         • In Windows, you can run the following search in Windows Explorer: *.* size:> 10MB
   9. Set the file descriptor limit to at least 20480.

      ulimit -n 20480

   10. Set the stack limit to at least 65536.

       ulimit -s 65536

   11. AIX only: Use the following steps to increase the maximum length of the command line with environment variables:
       1. Run the following command to query the system attributes:

          lsattr -EH -l sys0 | grep ncargs

          The command returns a value similar to the following example:

          ncargs  256  ARG/ENV list size in 4K byte blocks  True

       2. If the ncargs value is less than 512, run the following command to increase the value:

          chdev -l sys0 -a ncargs=1024

   12. Stop the WebSphere Portal server before you run the WASPreUpgrade command.
   13. For a local migration only: Run the WASPreUpgrade command from the v90_was_root_path/bin directory. For a remote migration only: Run the WASPreUpgrade command from the working_directory/bin directory that contains the remote migration package that is copied earlier. For a remote migration only: Add the extra parameter -machineChange true.
       • AIX: ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd
       • Linux: ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd
       • Windows: WASPreUpgrade.bat temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd
       Where the following values are set:

       temp_dir

       Temporary directory where the backup is stored.

       Note:

       • For Windows, Windows, the temp_dir cannot have spaces in the path.

       For example, your command on might look like: ./WASPreUpgrade.sh /opt/IBM/wasMigrateBackup /opt/IBM/WebSphere/AppServer -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd

   14. For a remote migration only: Compress and copy the backup that is created by the WASPreUpgrade command from the source server to the remote target server. Extract the backup into a temporary directory such as temp_dir.
   15. For a remote migration only: Update the deployment manager settings.

       If the deployment manager host name or soap port changed, update the source deployment manager host name and soap port with the target deployment manager host name and soap port in the serverindex.xml and wsadmin.properties in the backup profile at /tmp/wp_profile_bak/profiles/wp_profile/config/cells/CellName/nodes/dmgr/serverindex.xml and /tmp/wp_profile_bak/profiles/wp_profile/properties/wsadmin.properties.

   16. For a local migration only: Run the WASPostUpgrade command from the v90_was_root_path/bin directory on the local server. For a remote migration only: Run the WASPostUpgrade command from the v90_was_root_path/bin directory on the remote target server. The WasPostUpgrade command migrates the backed-up source profile into the new profile.
       Note: If security is enabled on your profile, add the -username was_userid -password was_userid_password parameters to your WASPostUpgrade task.
       • AIX: ./WASPostUpgrade.sh temp_dir -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
       • Linux: ./WASPostUpgrade.sh temp_dir -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
       • Windows: WASPostUpgrade.bat temp_dir -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
       For example, your command might look like: ./WASPostUpgrade.sh /opt/IBM/wasMigratedBackup -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
       If the WASPreUpgrade was successful, but the WASPostUpgrade command results in an error, complete the following steps:

       1. Check that only one profile exists in the backup profile.
       2. Consider deleting Search Collection to decrease the data size.
       3. Move JCR Data during migration.
          Note: The Java Content Repository might store index-related files in subdirectories in the WebSphere profile, such as jcr, that can use much space. This data is not altered by the migration process, so it can be temporarily moved out of the old profile or the backup directory in preparation for migration. Move the directory into the new profile after migration completes.
       4. Ensure that no paths contain the ":" character. This character might cause problems for WASPreUpgrade and WASPostUpgrade commands.
       Important: After you run WASPostUpgrade on the Deployment Manager or WebSphere Portal node, log in to the WebSphere Integrated Solutions Console and verify that AutoSync is on. Go to System Administration > Nodes. Confirm that the node that is being migrated is in sync. If it is not, issue a sync for that node and wait for it to complete.
   17. Open a command prompt and change to the v90_wp_profile_path/bin/ directory.
   18. Run the following command to start the node agent:
       • AIX: ./startNode.sh
       • Linux: ./startNode.sh
       • Windows: startNode.bat
   19. Log in to the WebSphere Integrated Solutions Console.
   20. Confirm that the node that is being migrated is in sync. If it is not, run a Full resynch for that node and wait for it to complete.
   21. If the source and target profile names are not the same, in the target ConfigEngine path, run the action-copy-ce-script-native-encoding task:
       Note: The target ConfigEngine path should be in the same path as the PortalServer and AppServer paths. Do not run this command from the ConfigEngine path that is located within the target profile.
       • AIX: ./ConfigEngine.sh -profileName v90_wp_profile_name action-copy-ce-script-native-encoding
       • Linux: ./ConfigEngine.sh -profileName v90_wp_profile_name action-copy-ce-script-native-encoding
       • Windows: ConfigEngine.bat -profileName v90_wp_profile_name action-copy-ce-script-native-encoding
   22. Create a copy of the WebSphere Portal source database. Refer to your database documentation for instructions on how to create the backup. Modify the wkplc_dbdomain.properties file on the WebSphere Portal V9 target server to point to the database copy.
   23. Modify the following properties files so the parameters point to the new WebSphere Portal V9 directory locations:
       1. From the v90_wp_profile_path/ConfigEngine/properties directory:
          • Verify that the DbLibrary parameter in the wkplc_dbtype.properties file points to the correct JDBC driver class. The value is either .zip or .jar. For example: /derby/lib/derby.jar.
          • Verify that the WpsInstallLocation parameter in the wkplc.properties file points to the correct installation location of WebSphere Portal.
          • Verify that the administrative passwords in the wkplc_dbdomain.properties file were not deleted by the fix pack.
          • Verify that the WasRemoteHostName, WasSoapPort, WpsHostName properties in the wkplc.properties are set to the correct values.
       2. For a local migration only: From the /PortalServer directory, modify the following parameters in the wps.properties file:
          • WasRootDir=v90_was_root_path/
          • ProfileDirectory=v90_wp_profile_path
       3. For a remote migration only: From the v90_wp_profile_path/ConfigEngine/properties directory, modify the following parameters in the wkplc.properties file:
          • WasRemoteHostName=host name of the Deployment Manager target server
          • WpsHostName=host name of the WebSphere Portal target server
   24. Open a command prompt and change to the v90_wp_profile_path/ConfigEngine directory.
   25. Run the following command:
       • AIX: ./ConfigEngine.sh validate-database -DWasPassword=password -DPortalAdminPwd=password
       • Linux: ./ConfigEngine.sh validate-database -DWasPassword=password -DPortalAdminPwd=password
       • Windows: ConfigEngine.bat validate-database -DWasPassword=password -DPortalAdminPwd=password
   26. Run the following command to recreate your data sources:
       • AIX: ./ConfigEngine.sh connect-database -DWasPassword=password -DPortalAdminPwd=password
       • Linux: ./ConfigEngine.sh connect-database -DWasPassword=password -DPortalAdminPwd=password
       • Windows: ConfigEngine.bat connect-database -DWasPassword=password -DPortalAdminPwd=password
   27. Multiple clustered environments only: Run the following command on the second cluster (Cluster B) that you are migrating. Only run the task if each cluster's database domains use a different database user and password. Read the multiple clustered documentation for information: Roadmap: Multiple clusters
       • AIX: ./ConfigEngine.sh create-alias-multiple-cluster -DauthDomainList=release,jcr,community,customization,feedback,likeminds -DWasPassword=password -DPortalAdminPwd=password
       • Linux: ./ConfigEngine.sh create-alias-multiple-cluster -DauthDomainList=release,jcr,community,customization,feedback,likeminds -DWasPassword=password -DPortalAdminPwd=password
       • Windows: ConfigEngine.bat create-alias-multiple-cluster -DauthDomainList=release,jcr,community,customization,feedback,likeminds -DWasPassword=password -DPortalAdminPwd=password
   28. Run the following post-was-migration-update command:
       • AIX: ./ConfigEngine.sh post-was-migration-update -DWasPassword=password -DoldProfileLocation=v85_wp_profile_path
       • Linux: ./ConfigEngine.sh post-was-migration-update -DWasPassword=password -DoldProfileLocation=v85_wp_profile_path
       • Windows: ConfigEngine.bat post-was-migration-update -DWasPassword=password -DoldProfileLocation=v85_wp_profile_path
       Note: If the post-was-migration-update task fails, check the v90_wp_profile_path/logs/WebSphere_Portal/SystemOut.log file for errors. Search for error code CWPKI0428I. If you find the following message, complete the instructions that are provided in the log file to add the signer certificate. After the certificate is added, restart the node agent and run the post-was-migration-update task again.
4. For a remote migration only: Complete the following steps to update the ports for the deployment manager and on every node:

   You can still have your source servers running and broadcasting services within your network. After migration, the deployment manager name for example remains unchanged. To avoid conflicts with the new target environment server and services, you need to set unique ports. If you do not run this task, it is possible for the source and target environments to become corrupted.

   As a rule, increase the original port number by 100. You still need to make sure that the same ports are not used in the source environment.

   1. Log in to the WebSphere Integrated Solutions Console.
   2. Click System administration > Deployment manager > Ports.
   3. Update the following ports for the node:
      • CELL_DISCOVERY_ADDRESS
      • DCS_UNICAST_ADDRESS
   4. Click System administration > Node agents > node_agent > Ports.
   5. Update the following ports for the node:
      • DCS_UNICAST_ADDRESS
      • NODE_DISCOVERY_ADDRESS
      • NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS
      • NODE_MULTICAST_DISCOVERY_ADDRESS
   6. Click Servers > Server types > WebSphere application servers > application_servers > Ports.
      Note: The default value for the application_servers is WebSphere_Portal; however, you can have more servers that are defined. Update the ports on all application servers listed.
   7. Update the following port for the node:
      • DCS_UNICAST_ADDRESS
   8. Click System administration > Nodes to resynchronize the primary node.
   9. Select the check box for the primary node.
   10. Click Full Resynchronize.
       Note: For resynchronization of the primary node, the node agent on the primary node must be running.
   11. Wait 30 minutes before you continue on to the next step. It takes several minutes for the synchronization to complete. The WebSphere Integrated Solutions Console might indicate that synchronization is complete. However, wait 30 minutes before you continue to the next step. If you begin the next step before the completion of the synchronization, applications might not be deployed properly to the nodes.
   12. Restart the deployment manager and all of the node agents after you update the ports for every node and complete resynchronization.
   13. Continue to run the deployment manager and the node agent of the node that is being updated. However, stop all other node agents before you continue to the next step.
       Important: If you update the SOAP port of the target Deployment Manager, then you must update the WPS_SOAP_PORT value in the wpscript.sh file. The wpscript.sh file is in the wp_profile_root/PortalServer/bin/ and PortalServer_root/bin directory for each node.

       Both the source and target environments can now run simultaneously.

5. Start the WebSphere Portal server. If the WebSphere Application Server migration fails, review the logs to troubleshoot any migration errors. Then, rerun the install-wp-migration-files command.
6. Log in to the WebSphere Integrated Solutions Console and turn on AutoSync.
7. After you migrate your profile to WebSphere Application Server 9.0.0.2, the Configuration Wizard in the v85_AppServer root/profiles/cw_profile directory is still usable. If you want to have the wizard also running on WebSphere Application Server 9.0.0.2, run the following command from the v90_wp_profile_path/ConfigEngine directory.
   • AIX: ./ConfigEngine.sh create-config-wizard -DWizardUserid=userID -DWizardPassword=password -DWasPassword=password
   • Linux: ./ConfigEngine.sh create-config-wizard -DWizardUserid=userID -DWizardPassword=password -DWasPassword=password
   • Windows: ConfigEngine.bat create-config-wizard -DWizardUserid=userID -DWizardPassword=password -DWasPassword=password