+

Search Tips   |   Advanced Search

Migrate an administrative agent profile and its registered set of managed base application servers

Administrative agent profiles manage multiple base application servers in environments such as development, unit test or that portion of a server farm that resides on a single machine. Before we can migrate managed base application servers from v7.0 or later to v9.0, we must first migrate the administrative agent.

Review the migration planning information. See Knowledge Collection: Migration planning for WAS.

Tip: Rather than specifying individual parameters on migration commands, we can specify the -properties file_name.properties parameter to input a properties file. See Define our migration through properties.

A base application server becomes managed when it is registered with a single administrative agent. An administrative agent may manage one or more base application servers and must be at the same release level and on the same machine as the base application servers it is managing. Because of this restriction, the administrative agents on both the old and new release run simultaneously until all managed base application servers are migrated. The migration of an administrative agent does not bring forward its old port values, however, all other configuration data is migrated.

Access the v9.0 admin agent console using the WC_ adminhost or WC_ adminhost_ secure ports as defined in the new v9.0 admin agent's serverindex.xml file. Additionally, the v7.0 or later administrative agent must not be shut down or disabled during this procedure.

For migrating the managed base application server in a flexible management environment, ensure that the node names are the same on v9.0 and previous releases.

Ensure that your setting for the maximum number of open files is 10000 or greater. If the number of open files is too low, this can cause a variety of migration failures.


Tasks

  1. Install WAS v9.0 onto the target host in a new directory.

    See installation documentation.

  2. Create a v9.0 administrative agent profile that will be the target of the administrative agent migration.

    Run the manageprofiles command with the appropriate parameters to create a new administrative agent profile.

    For example: 
    C:\WebSphere\AppServer90\bin>manageprofiles.bat -create -profileName 90AdminAgent01 -profilePath 
C:\WebSphere\AppServer90\profiles\AdminAgent01 -templatePath C:\WebSphere\AppServer90\profileTemplates\management 
-serverType ADMIN_AGENT -nodeName AdminAgentNode01 -cellName AdminAgentCell01 -hostName mydmgrhost.company.com

  3. Ensure that all in-progress jobs are completed on the managed profiles.

  4. Stop polling the job manager on profiles that are getting jobs from the job manager.

    Before starting polling for jobs, complete WASPreUpgrade and WASPostUpgrade for the managed profile. See ManagedNodeAgent command group for the AdminTask object using wsadmin.sh.

  5. Save the current administrative agent configuration to the migration backup directory by running the WASPreUpgrade command from the new WAS installation root bin directory.

    The WASPreUpgrade command does not make any changes to the old configuration.

    1. Run the WASPreUpgrade command, specifying the migration backup directory and the v7.0 or later installation root directory.

      For information about command parameters, see WASPreUpgrade command.

      For example: 
      C:\WebSphere\AppServer90\bin>WASPreUpgrade.bat C:\WAS70AdminAgentbackup C:\WebSphere\AppServer70 -oldProfile 70AdminAgent01 
-traceString *=all=enabled -tracefile C:\WAS70AdminAgentbackup\logs\WASPreMigrationSummary.log

    2. Review warnings or errors in the console output and WASPreUpgrade logs. After the WASPreUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the following log files for any warnings or errors:

      • migration_backup_dir/logs/WASPreMigrationSummary.log
      • WASPreUpgrade.timestamp.log
      • WASPreUpgrade.trace

      If there are errors, fix the errors and run the WASPreUpgrade command again. Check whether the warnings affect any other migration or runtime activities on v9.0.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

  6. Restore the previous administrative agent configuration by running the WASPostUpgrade command from the new WAS install root bin directory.

    1. Run the WASPostUpgrade command to restore the saved administrative agent configuration into the new v9.0 administrative agent profile. For example: 
      C:\IBM\WebSphere\AppServer90\bin>WASPostUpgrade.bat C:\WAS70AdminAgentbackup -oldProfile 70AdminAgent01 -profileName 90AdminAgent01 
-traceString *=all=enabled -tracefile C:\WAS70AdminAgentbackup\logs\WASPostMigrationSummary.log -username myuser -password mypass

    2. Review warnings or errors in the console output and WASPostUpgrade logs. After the WASPostUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the following log files for any warnings or errors:

      If there are errors, fix the errors and run the WASPostUpgrade command again. Check whether the warnings affect any other migration or runtime activities on v9.0.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

  7. Start the v9.0 administrative agent and ensure that both v7.0 or later and v9.0 administrative agents are running.

    1. Change to the new v9.0 administrative agent profile bin directory.

    2. Run the startServer adminagent command.

    3. Check the SystemOut.log file for warnings or errors.

      IBM recommends using the High Performance Extensible Logging (HPEL) log and trace infrastructure . We view HPEL log and trace information using the logViewer .

  8. Migrate managed base application servers.

    For the migration to be successful:

    • Managed base application servers must be located on the same machine as the associated administrative agent.

    • The node names must be the same on the v9.0 and previous releases.
    • (Windows) Stop the AppSrv server before running a migration if we have a Windows platform and plan to migrate a SIB component.

    For each managed base application server that we plan to migrate to v9.0...

    1. Create the target base application server profile. Run the manageprofiles command with the appropriate parameters to create a new managed profile. For example: 
      C:\WebSphere\AppServer90\bin>manageprofiles.bat -create -profileName 90AppSrv01 
-profilePath C:\WebSphere\AppServer90\profiles\AppSrv01
-templatePath C:\WebSphere\AppServer90\profileTemplates\default 
-serverType APPLICATION_SERVER -nodeName AppSrv01Node01 
-cellName AppSrv01Cell01 -hostName mynode1host.company.com

    2. Run the WASPreUpgrade command to save the current managed base application server information to a migration backup directory. Choose a new directory for the backup files. For example: 
      C:\WebSphere\AppServer90\bin>WASPreUpgrade.bat C:\WAS70Appserver01backup 
C:\WebSphere\AppServer70 -oldProfile 70AppSrv01 -traceString *=all=enabled 
-summaryLogName C:\WAS70Appserver01backup\logs\WASPreMigrationSummary.log

    3. Review warnings or errors in the console output and WASPreUpgrade logs. After the WASPreUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the following log files for any warnings or errors:

      • migration_backup_dir/logs/WASPreMigrationSummary.log
      • WASPreUpgrade.timestamp.log
      • WASPreUpgrade.trace

      If there are errors, fix the errors and run the WASPreUpgrade command again. Check whether the warnings affect any other migration or runtime activities on v9.0.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

    4. Run the WASPostUpgrade command to restore the saved managed application server profile configuration into the new v9.0 base application server profile.

      This command requires additional parameters and the following example assumes that security is enabled on both administrative agents. For example: 

      C:\IBM\WebSphere\AppServer90\bin>WASPostUpgrade.bat C:\WAS70Appserver01backup 
-oldProfile 70AppSrv01 -profileName 90AppSrv01 -traceString *=all=enabled 
-summaryLogName C:\WAS70Appserver01backup\logs\WASPostMigrationSummary.log 
-oldAdminAgentProfilePath C:\WebSphere\Appserver70\profiles\70AdminAgent01
-oldAdminAgentHostname myhostname -oldAdminAgentSoapPort 8879 
-oldAdminAgentUsername myusername -oldAdminAgentPassword mypassword 
-newAdminAgentProfilePath C:\WebSphere\AppServer90\profiles\90AdminAgent01 
-newAdminAgentHostname myhostname -newAdminAgentSoapPort 8887 
-newAdminAgentUsername myusername1 -newAdminAgentPassword mypassword1

    5. Review warnings or errors in the console output and WASPostUpgrade logs. After the WASPostUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the following log files for any warnings or errors:

      If there are errors, fix the errors and run the WASPostUpgrade command again. Check whether the warnings affect any other migration or runtime activities on v9.0.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

    6. Start the migrated v9.0 managed application server.
    7. Check the v9.0 managed application server SystemOut.log file for warnings or errors.

      IBM recommends using the High Performance Extensible Logging (HPEL) log and trace infrastructure . We view HPEL log and trace information using the logViewer .

We migrated an administrative agent profile and its associated managed base application servers from WAS v7.0 or later to v9.0 using the migration tools. We can stop the v7.0 or later administrative agent, and we can assign the v7.0 or later ports to the v9.0 administrative agent.

  • WASPreUpgrade command
  • WASPostUpgrade command
  • Migration Toolkit on WASdev