WebSphere Portal - Moving from a test to production server

Moving from a test to production server using the XML configuration interface

Often a test server is used to create the portal environment before it goes into production mode. The XML configuration interface allows you to export the portal settings from the test server and import them to a production server. This topic is a guideline detailing the steps that should be taken to accomplish the move.
Users and groups are not exported or imported automatically. If you are exporting users and groups, perform the steps in Moving users and groups with the XML configuration interface below before importing the configuration.
These guidelines make the following assumptions about the test and production environments:

Portal configuration will be exported from a test server.
Portal configuration will be imported to a production server.
Portal configuration will include moving portlets that were added after the WebSphere Portal installation. These may be portlets that the company has developed or that were downloaded from another source, such as the Portal Catalog.
Any new or modified themes and skins will be included in the portal configuration.
Users and groups will not be exported or imported. See Moving users and groups with the XML configuration interface for details on performing this task.
A remote administrator machine will be used to access both servers and perform the export and import tasks.

There are three machines on a company intranet used in this scenario:

Server Description
Test Has a complete instance of WebSphere Portal installed. Portlets may have been added to this machine, the server has been tested, and the configuration represents what you plan to put into production. No special modifications are required to export the portal.
Production Has WebSphere Portal installed, but the selected install option has prevented the deployment of portlets. Some modifications must be made to this machine to prepare for the import.
Administrator Used to connect with both the test server and production server and issue commands during export and import. Because the portal administrator's password is sent unencrypted during XML configuration, all three machines should be within a protected intranet. Some modification must be made to this machine to prepare for the import.

Install WebSphere Portal on the production server

This configuration import described here requires that the production portal be installed without portlets. A special command must be issued to launch the WebSphere Portal installation without deploying portlets. Use one of the following commands from the root directory of the setup CD:

iSeries: install.sh -W installPortletsSequence.active="false"

Exporting the test server configuration

Several steps must be taken on the administrator machine to prepare for the portal configuration to be exported. Be sure that the connection between the test server and the administrative machine is maintained throughout these steps.
Copy the WAR files of any portlets that were deployed to the test server after the WebSphere Portal installation. WAR files must have names that are less than 25 characters. Place the WAR files in the <wp_root>/installableApps/ on the production server.
If you have extra JAR files, these must also be copied to the production machine and added to the WebSphere Portal application server classpath on the production machine.
Copy any new or modified themes and skins folders from <was_root>/installedApps/hostname/wps.ear/wps.war/themes/markup on the test server to the same location on the production server.
Copy the following files from the WebSphere Portal root directory on the test server to the administrator machine:

<wp_root>/bin/tools.jar
iSeries: <wp_root>/bin/xmlaccess.sh

Edit the following items in xmlaccess.bat or xmlaccess.sh file:

Change set JAVA="C:/WEBSPH~1/APPSER~1/java/bin/java" to point to the Java instance you are using. For example, if using the Java instance on the test portal, the value might be "R:/WEBSPHERE/APPSERVER/java/bin/java" where R represents that drive letter mapped to the test portal.
Change %WPS_HOME%/bin/tools.jar to point to the location of the tools.jar file that was copied onto the administrator machine. For example, if tools.jar was copied to C:\wpconfig on the administrator machine, so the value is C:\wpconfig\tools.jar.

Save and close the file.
Create export.xml with a text editor and save the file. This file should contain the following contents to export the test server configuration without users and user groups:
<?xml version="1.0" encoding="UTF-8"?>
<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
    type="export"
    export-users="false">

    <portal action="export"/>
</request>
If this file is not saved to the same directory, the full path must be provided when issuing the export command.
From the directory that contains the xmlaccess file on the administrator machine, enter the following from the command line:

iSeries: xmlaccess.sh -in export.xml -user user -pwd password -url http://yourco.testserver.com:port -out testserver.xml

where user is the portal administrator ID, password is the password for the administrative ID, yourco.testserver.com:port is the test server URL and port number, and testserver.xml is the name of output file that will hold the test server configuration. export.xml is the XML file created in previous step. Note: The full path name is required if this file does not reside in the same directory as the xmlaccess file.

Note: You must have Java on the administrator machine or point to the Java used by WAS. If you point to the WAS instance of Java, the connection with that machine must be maintained whenever the XML configuration interface is run.
The configuration content is displayed in the command line window. When a command prompt returns, open testserve.xml, the output file, and verify that the file ends with the following:

<status element="all" result="ok">
</request>
If this tag exists, the export was successful. If you receive an error, see Troubleshooting the XML configuration interface.
Importing the configuration to a production server

After the export has generated the testserver.xml output file, the portal configuration is ready to be imported to the production server. Be sure that the connection between the production server and the administrator machine is maintained throughout these steps.
If you are exporting and importing users and groups, be sure to perform the steps in Moving users and groups with the XML configuration interface before importing the configuration to the production server.

Verify that the WAR files of all portlets that were deployed after WebSphere Portal was installed on the test server have been copied to <wp_root>/installableApps/ on the production server.
Verify that any new or modified themes and skins folders have been copied to <was_root>/installedApps/hostname/wps.ear/wps.war/themes/markups on the production server.
From the directory that contains the xmlaccess file on the administrator machine, enter the following from the command line:

iSeries: xmlaccess.sh -in testserver.xml -user user -pwd password -url http://yourco.prodserver.com:port/wps/config

where user is the portal administrator ID, password is the password for the administrative ID, yourco.prodserver.com:port is the production server URL and port number, and testserver.xml is the name of output file that contains the test server configuration that is being imported. Importing the portal configuration may take some time, particularly from a remote location. The full path name is required if testserver.xml does not reside in the same directory as the xmlaccess file.
If portal configuration was a success, the following message appears in the command line:

<status element="all" result="ok">
</request>

If you receive an error, see Troubleshooting the XML configuration interface.

Moving users and groups with the XML configuration interface

This section describes how to move from a test to a production server using xmlaccess to export the test system and then using xmlaccess to import to the production server. This export and import will not work correctly if the test system has LDAP enabled. To work around this problem, some groups must be deleted from the database and recreated in the LDAP environment.
Steps 1 and 2 below will delete the groups from the database, Step 3 will recreate the groups in the LDAP environment. These steps must be done on the test server before you import the configuration to the production server. Use the following steps to move users and groups from the test server:
Create DeleteGroups.xml with a text editor and save the file. This file should contain the following contents to delete specific groups and users from the database:
<?xml version="1.0" encoding="UTF-8"?>
<request 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
  type="update" create-oids="true">
  
  <portal action="locate">   
   <user action="delete" name="WCPAdmin"/>
   <user action="delete" name="rob"/>
   <user action="delete" name="greg"/>
   <user action="delete" name="tara"/>
   <user action="delete" name="dave"/>
   <group action="delete" name="Domain Expert"/>
   <group action="delete" name="Project Lead"/>
   <group action="delete" name="Content Contributor"/>
   <group action="delete" name="Content Publisher"/>
   <group action="delete" name="WPCPUsers"/>
   <group action="delete" name="WPCPAdmins"/>
   <group action="delete" name="wpsDocReviewer"/>
   <group action="delete" name="wpsDocAuthor"/>
   <group action="delete" name="wpsDocAdmins"/>
   <group action="delete" name="wpsDocUsers"/>    
  </portal>   
</request>
From the directory that contains the xmlaccess.bat (or .sh) file on the administrator machine, enter the following from the command line for DeleteGroups.xml substituting the fully qualified filename for the xmlfilename:

iSeries: xmlaccess.sh -in xmlfilename -user user -pwd password -url http://yourco.prodserver.com:port/wps/config

where user is the portal administrator ID, password is the password for the administrative ID, yourco.prodserver.com:port is the production server URL and port number, and xmlfilename is the fully qualified name of the xml file (use double quotes if the path contains spaces).
Enable LDAP on the test machine.
From the directory that contains the xmlaccess file on the administrator machine, enter the following from the command line for each of the following (6) xml files substituting the fully qualified file name for the xml file name:
<wp_root>/wpcp/v5.0/author/portlet/wpcpGroups.xml 
<wp_root>/wpcp/v5.0/author/portlet/wpcpworkspace.xml 
<wp_root>/wpcp/v5.0/author/samples_v5/db2/sampleUtilities/samplePAC.xml 
<wp_root>/wpcp/v5.0/author/samples_v5/db2/sampleUtilities/sampleUsers.xml
<wp_root>/config/templates/DocumentManagerGroups.xml
<wp_root>/config/templates/DocumentManagerPAC.xml
iSeries: xmlaccess.sh -in xmlfilename -user user -pwd password -url http://yourco.prodserver.com:port/wps/config

where user is the portal administrator ID, password is the password for the administrative ID, yourco.prodserver.com:port is the production server URL and port number, and xmlfilename is the fully qualified name of the xml file (use double quotes if the path contains spaces).
From the <wp_root>/wpcp/v5.0/config directory, run the following configuration task:
WPCPconfig.bat action-cfg-author-security
Important note about Document Manager

After performing the steps described in this topic, the Document Manager portlet could be left in a state where it reports "The portlet is unavailable. Please contact the administrator". This problem occurs because the XML configuration interface does not move database contents or database connectivity information.
You will need to verify the following items:

Did the database backup and restore work successfully if you used that method to move the database contents to the production server? Keep in mind that if you have folders or documents created in Document Manager, those items are stored in the database. When moving from a test server to a production server, in order to move the contents, you will need to take the appropriate actions to get the information from the database on the test server to the production server.
Do the tables found in the SystemErr.log exist in the database?
Are the JDBC datasources in the WAS Administrative Console pointing to the correct database?

See also

About the XML configuration interface
Changes in XML for WebSphere Portal Version 5.0.2
Work with the XML configuration interface
XML reference
Troubleshooting the XML configuration interface
XML messages
Reference: Sample XML configuration files

Portal configuration
Administer the portal

Server	Description
Test	Has a complete instance of WebSphere Portal installed. Portlets may have been added to this machine, the server has been tested, and the configuration represents what you plan to put into production. No special modifications are required to export the portal.
Production	Has WebSphere Portal installed, but the selected install option has prevented the deployment of portlets. Some modifications must be made to this machine to prepare for the import.
Administrator	Used to connect with both the test server and production server and issue commands during export and import. Because the portal administrator's password is sent unencrypted during XML configuration, all three machines should be within a protected intranet. Some modification must be made to this machine to prepare for the import.