Changing the portal URI

You can change the default portal Uniform Resource Identifier (URI) after installation. There are a few applications that have a fixed context root that cannot be changed.

About this task

IBM® WebSphere® Portal and Web Services for Remote Portlets are installed with a default URI. You can change this URI after installation to better suit the requirements of your organization.

Notes:
  • For changing the WebSphere Portal URI: When you specify the context root, do not specify a value that is the same as a directory that exists in a portlet WAR directory. For example, if you set the WebSphere Portal context root as /images and there is also a portlet with the directory structure /myPortlet.ear/myPortlet.war/images, this issue might cause a conflict if the portlet encodes URI references to resources in its own /images directory. In this situation, the portlet would be unable to display images. WebSphere Portal looks for the image resources according to its own context root path instead of the directory path that is specified by the portlet WAR file.
  • For changing the URI of a WSRP Producer portal: Changing the WSRP Producer context root does not require that you redeploy all portlets. Run the modify-servlet-path configuration task only.
    Important: With Version 8, the URI of the context root for the WSRP Producer is /wps/wsrp. Before Version 8, this context root was /wsrp. If you migrated to Version 8 from an earlier version, you still might have WSRP Consumers that attempt to access the WSRP Producer with the previous context root (/wsrp). You can correct this issue in one of the following ways:
    • Modify the context root for the WSRP Producer to /wsrp. This change enables the Consumers to access the Producer without requiring further changes to the Consumers.
    • Update the configuration of the WSRP Consumers to use the new context root (/wps/wsrp).
  • If you use IBM Web Content Manager Syndication, the Syndicators and Subscribers servers that refer to this Portal instance must be updated with the modified URI. Log on to the WebSphere Portal syndicating to this instance. Go to Administration > Portal Content > Syndicators and click the edit icon of the Syndicator you want to edit. Update the URL with the new context root information. Then, log on to the WebSphere Portal subscribing to this instance. Go to Administration > Portal Content > Subscribers and click the edit icon of the subscriber you want to edit. Update the URL with the new context root information.
Cluster note: If you modify the URI in a clustered environment, complete the steps that are described here on the primary node only, except where specified differently. Additionally, verify that AutoSynch is set to a frequency of 1 minute.

Procedure

  1. Complete the following steps to manually modify the WebSphere Portal context root:
    Attention: If you changed the context root on the Configuration for IBM WebSphere Portal: Profile configuration details: Advanced panel during installation, proceed to step 2.
    1. Stop the WebSphere_Portal server.
    2. Open a UNIX System Services (z/OS UNIX System Services) command prompt.
      Note: The file is an ASCII file. Open it with the appropriate tool.
    3. Locate the wkplc.properties and wkplc_comp.properties files in the wp_profile_root/ConfigEngine/properties directory and create backup copies before you change any values.
    4. Use a text editor to open the wkplc.properties file and enter the appropriate value for your environment in the WpsContextRoot property.
    5. Save and close the file.
    6. Use a text editor to open the wkplc_comp.properties file and enter the appropriate value for your environment in the following properties:
      • WsrpContextRoot
      • WpsPersonalizedHome
      • WpsDefaultHome
      Attention: Do not enter the same value for WpsPersonalizedHome and WpsDefaultHome.
    7. Save and close the file.
    8. Start the WebSphere_Portal server in a stand-alone environment or the deployment manager and node agent in a clustered environment.
    9. Open a command prompt and change to the wp_profile_root/ConfigEngine directory.
    10. Complete the following steps to change the WebSphere Portal URI:
      1. To change the context root for the values that you entered in the WpsContextRoot, WsrpContextRoot, WpsPersonalizedHome, and or WpsDefaultHome properties, run the following task:
        • AIX® Linux Solaris:./ConfigEngine.sh modify-servlet-path -DPortalAdminPwd=password -DWasPassword=password
        • Windows: ConfigEngine.bat modify-servlet-path -DPortalAdminPwd=password -DWasPassword=password
        • IBM i: ConfigEngine.sh modify-servlet-path -DPortalAdminPwd=password -DWasPassword=password
        • z/OS®:./ConfigEngine.sh modify-servlet-path -DPortalAdminPwd=password -DWasPassword=password
        Note: Check the output for any error messages before you proceed with the next task. If any of the configuration tasks fail, verify the values in the wkplc.properties and wkplc_comp.properties files.
      2. Restart the WebSphere_Portal server.
    11. Run the following task to change the context root for the portlets:
      • AIX Linux Solaris: ./ConfigEngine.sh modify-servlet-path-portlets -DPortalAdminPwd=password -DWasPassword=password
      • Windows: ConfigEngine.bat modify-servlet-path-portlets -DPortalAdminPwd=password -DWasPassword=password
      • IBM i: ConfigEngine.sh modify-servlet-path-portlets -DPortalAdminPwd=password -DWasPassword=password
      • z/OS: ./ConfigEngine.sh modify-servlet-path-portlets -DPortalAdminPwd=password -DWasPassword=password
      Note: Check the output for any error messages before you proceed with the next task. If any of the configuration tasks fail, verify the values in the wkplc.properties and wkplc_comp.properties files.
  2. If necessary, start the WebSphere_Portal server in a stand-alone environment or the deployment manager and node agent in a clustered environment.
  3. Complete the following steps if you are using an external web server, such as an HTTP Server:
    1. Choose one of the following options that are based on your WebSphere Portal environment:
      Table 1. configurewebservername command options
      WebSphere Portal environment Steps
      Stand-alone configuration Complete the following steps in a stand-alone configuration:
      1. Copy the following script from the plugin_root/bin directory on the web server to the wp_profile_root/bin directory on your WebSphere Portal server:
        • AIX Linux Solaris: ./configurewebservername.sh
        • Windows: configurewebservername.bat
        • IBM i: configurewebservername.sh
        • z/OS: ./configurewebservername.sh

        where webservername is the web server definition name you defined previously when you configured the HTTP Server for WebSphere Portal, for example: configurewebserver1.bat.

      2. Run the following command, from the wp_profile_root/bin directory:
        • AIX Linux Solaris: ./configurewebservername.sh
        • Windows: configurewebservername.bat
        • IBM i: configurewebservername.sh
        • z/OS: ./configurewebservername.sh
      Clustered configuration Complete the following steps in a clustered configuration:
      1. Copy the following script from the plugin_root/bin directory on the web server to the dmgr_profile/bin directory on your Deployment Manager server:
        • AIX Linux Solaris : ./configurewebservername.sh
        • Windows: configurewebservername.bat
        • IBM i: configurewebservername.sh
        • z/OS: ./configurewebservername.sh

        where webservername is the web server definition name you defined previously when you configured the HTTP Server for WebSphere Portal, for example: configurewebserver1.bat.

      2. Run the following command on the Deployment Manager server:
        • AIX Linux Solaris: ./configurewebservername.sh
        • Windows: configurewebservername.bat
        • IBM i: configurewebservername.sh
        • z/OS: ./configurewebservername.sh
    2. Regenerate the web server plug-in in WebSphere Application Server. If you are using a remote web server, copy the generated plugin-cfg.xml file to the remote server.
      Important: Do not complete these steps if you are changing only the WSRP Producer URI.
    3. Restart the web server.
    4. Restart the WebSphere_Portal server.
  4. Complete the following steps to update the registered Application URI entries in the JCR.ICMSTJCRNODEREGISTER table:
    Cluster note: In a clustered environment, complete these steps on the primary node only.
    1. Stop the WebSphere_Portal server.
    2. Back up the database.
    3. Start the WebSphere_Portal server.
    4. Complete the following steps to unregister the node types:
      • Open the ibmcontentwcm.registernodetypes file, which is in the /WebSphere/PortalServer/wcm/prereq.wcm/config/nodetypes/ directory.
      • Change <registerAction action="register"/> to <registerAction action="deregister"/>.
      • Save your changes.
      • Run the following task:
        • AIX Linux Solaris: ./ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
        • Windows: ConfigEngine.bat action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
        • IBM i: ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
        • : ./ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
    5. Complete the following steps to register the node types:
      • Open the ibmcontentwcm.registernodetypes file, which is in the /WebSphere/PortalServer/wcm/prereq.wcm/config/nodetypes/ directory.
      • Change <registerAction action="deregister"/> to <registerAction action="register"/>.
      • Update all lines that contain the <ApplicationURI name="wps/mypoc/?view=auth&uri=wcm:oid:"/> content.

        Change the name of the attribute value to reflect the new WpsContextRoot value that is found in the wkplc.properties file. For example, if the original value for WpsContextRoot was wps and the new value is wp8, change the lines to <ApplicationURI name="wp8/mypoc/?view=auth&uri=wcm:oid:"/>.

      • Run the following task:
        • AIX Linux Solaris: ./ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
        • Windows: ConfigEngine.bat action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
        • IBM i: ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
        • z/OS: ./ConfigEngine.sh action-register-wcm-nodetypes -DWasPassword=password -DPortalAdminPwd=password
    6. Run the following SQL query to verify that the entries in the table now show the new URI: 
      select * from JCR.ICMSTJCRNODEREGISTER
    7. Restart the WebSphere_Portal server.
  5. Required if you use IBM Web Content Manager: Complete the following steps to manually change the JSP components in the Web Resources v70 Library:
    Cluster note: If a clustered environment, complete these steps on the primary node only.
    1. Log on to WebSphere Portal.
    2. Go to Applications > Content > Web Content Management.
    3. Under Preferences, select Edit Shared Settings.
    4. Under Library Selection, add Web Resources v70 to the Selected Libraries list.
    5. Click OK.
    6. Under Item Views, select All Items > All > Components > JSP.
    7. Select every JSP component from the Web Resources v70 library and then click Edit.
    8. Update the Path field for every JSP component with the new context root path.

      The JSP path includes two parts, which are separated by a semi-colon. The first part is the context path to the IBM Web Content Manager extensions web application and then the second part is the path to the JSP. Update the path to the web application.

      For example, the other path might be: /wcmextension;/jsp/html/general/UpdateItem.jsp. If you changed the context root to mynewcontext, change the old path to /mynewcontext/wcmextension;/jsp/html/general/UpdateItem.jsp.

  6. Optional: Update your custom themes to reference the correct Dojo context root.

    The default Dojo context root in WebSphere Portal is /wps/portal_dojo. After you run the modify-servlet-path and modify-servlet-path-portlets tasks, the Dojo context root is changed to include the new value in the WpsContextRoot parameter as the prefix. For instance, if the new WpsContextRoot value is myco, then the new Dojo context root becomes /myco/portal_dojo. If your theme includes hardcoded references to "/wps/portal_dojo", update those references to the new context root. If you migrated a custom theme, you might find that it has references to /portal_dojo without the /wps prefix. Look for these references in both the WAR file and in the WebDAV storage for your theme.

    Cluster note: In a clustered environment, complete these steps on the primary node only.
  7. Complete the following steps if you changed the context root and you have existing search collections:
    Attention: Edit the content root for each existing search collection.
    1. Log on to WebSphere Portal as the administrator.
    2. Click the Administration tab.
    3. Go to Search Administration > Manage Search.
    4. Click Search Collections.
    5. Click the search collection that you want to update. For example: Default Search Collection.
    6. Click the Edit Content Source icon for the first content source in the list.
    7. Edit the URL listed in the Collect documents link from the URL with the new context root.
    8. Click Save.
    9. Edit the URL in each remaining content source and then save you changes.
    10. Click Collections from All Services in the breadcrumb trail and select the next search collection to modify.
  8. Optional: Complete the following steps if you are using IBM Lotus® Quickr® Doc Picker:
    Cluster note: In a clustered environment, complete these steps on the primary node only.
    1. Log on to the WebSphere Integrated Solutions Console.
    2. Go to Applications > Application Types > WebSphere enterprise applications.
    3. Find and click the Quickr Document Picker application link.
    4. Under the Web Module Properties heading, click Context Root For Web Modules.
    5. Change the context root to new_context_root.
    6. Click OK.
    7. Click Save to save your changes to the master configuration.
    8. Log out of the WebSphere Integrated Solutions Console.
    9. Update the context root information in the following files to match your new context root:
      • wp_profile_root/installedApps/node name/Quickr_Document_Picker.ear/METAINF/application.xml
      • wp_profile_root/installedApps/node name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/WEBINF/jsp/js/config.jsp
      • wp_profile_root/installedApps/node name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/picker-packaged.js
      • wp_profile_root/installedApps/node name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/picker-packaged.js.uncompressed.js
      • wp_profile_root/installedApps/node name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/widgets/DocumentPicker.js
      • wp_profile_root/installedApps/node name/Quickr_Document_Picker.ear/qkr.docpicker.widgets.war/js/quickr/picker/widgets/PickerDialog.js
      • wp_profile_root/installedApps/node name/EphoxEditLive.ear/editoreditlive.war/jsp/html/EditLiveJavaEditor.jsp
      • wp_profile_root/installedApps/node name/PA_WCM_Authoring_UI.ear/ilwwcmauthoring.war/jsp/html/OdcEditor.jsp
  9. Clustered environment only: Resynchronize the nodes and restart the cluster.
    Table 2. Steps to resynchronize the nodes and restart the cluster.
    Cluster type Steps
    Static cluster Complete the following steps if you have a static cluster:
    1. Open the deployment manager WebSphere Integrated Solutions Console.
    2. Click System Administration > Nodes, select the primary node from the list, and click Full Resynchronize.
    3. Click Servers > Clusters.
    4. Select the cluster and click Stop.
    5. After the cluster stops, restart it by selecting the cluster. Then, click Start.
    Dynamic cluster Complete the following steps if you have a dynamic cluster:
    1. Open the deployment manager WebSphere Integrated Solutions Console.
    2. Click System Administration > Nodes, select the primary node from the list, and click Full Resynchronize.
    3. Click Servers > Dynamic Clusters.
    4. Click the required dynamic cluster that you want to stop and restart.
    5. Click Dynamic cluster members.
    6. Select the member name that you want to stop and then click Stop.
    7. Select the member name that you want to start and then click Start.
  10. Complete the following steps on the stand-alone server or on each node within your cluster to create the WebSphere environment variables that IBM Web Content Manager needs:
    1. Locate the wkplc.properties and wkplc_comp.properties files on the additional nodes in the wp_profile_root/ConfigEngine/properties directory and create backup copies before you change any values.
    2. Use a text editor to open the wkplc.properties file and enter the appropriate value for your environment in the WpsContextRoot property.
    3. Save and close the file.
    4. Use a text editor to open the wkplc_comp.properties file and enter the appropriate value for your environment in the following properties:
      • WsrpContextRoot
      • WpsPersonalizedHome
      • WpsDefaultHome
      Attention: Do not enter the same value for WpsPersonalizedHome and WpsDefaultHome.
    5. Save and close the file.
    6. Run the following task to create the WebSphere environment variables for Web Content Manager:
      • AIX Linux Solaris: ./ConfigEngine.sh create-wcm-servletpath-variables -DServerName=your_application_server_name -DWasPassword=password
      • Windows: ConfigEngine.bat create-wcm-servletpath-variables -DServerName=your_application_server_name -DWasPassword=password
      • IBM i: ConfigEngine.sh create-wcm-servletpath-variables -DServerName=your_application_server_name -DWasPassword=password
      • z/OS: ./ConfigEngine.sh create-wcm-servletpath-variables -DServerName=your_application_server_name -DWasPassword=password
      Note: Check the output for any error messages before you proceed with the next task. If any of the configuration tasks fail, verify the values in the wkplc.properties and wkplc_comp.properties files.
  11. Resynchronize the nodes and restart the cluster.