<!-- [endif]--> <!-- [endif]-->
<!-- [if supportFields]><span lang=EN-US style='font-size:24.0pt'><span style="mso-element:field-begin" mce_style="mso-element:field-begin"></span><span style="mso-spacerun: yes"> </span>TOC /o "1-3" /h /z /u <span style='mso-element:field-separator'></span></span><![endif]-->1 客户环境 <!-- [if supportFields]><span style='color:windowtext;text-decoration:none;text-underline:none'><span style='mso-element:field-begin'></span></span><span style="color:windowtext; text-decoration:none;text-underline:none" mce_style="color:windowtext; text-decoration:none;text-underline:none"> PAGEREF _Toc203471613 /h </span><span style='color:windowtext;text-decoration:none;text-underline:none'><span style='mso-element:field-separator'></span></span><![endif]-->4 <!-- [if gte mso 9]><xml> <w:data>08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003200300033003400370031003600310033000000</w:data> </xml><![endif]--> <!-- [if supportFields]><span style="color:windowtext; text-decoration:none;text-underline:none" mce_style="color:windowtext; text-decoration:none;text-underline:none"><span style="mso-element:field-end" mce_style="mso-element:field-end"></span></span><![endif]-->
<!-- [if supportFields]><span lang=EN-US style='font-size:24.0pt'><span style="mso-element:field-end" mce_style="mso-element:field-end"></span></span><![endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
源环境: WPS5
平台: windows
门户: WebSphere Portal Server enable 5.1.0.2+WCM (WCM 发布的服务器,最好是从发布服务器迁移 )
数据库: Oracle 9i
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
目标环境: WPS6
平台: windows
门户: WebSphere Portal Server Enable 6.0.1.3 +WCM+WAS6.0.2.23
数据库: Oracle 9i
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
WPS1 10.195.88.221 10.195.88.201
WPS2 10.195.88.220
LDAP 10.195.88.221
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
补丁:
6.0.1-WP-FP003
6.0.1.3-WP-Multi-IFPK59655
6.0.1.3-WP-Multi-IFPK61633
<!-- [if !supportEmptyParas]--><!-- [endif]-->
6.0.2-WS-WAS-WinX32-FP00000023
6.0.2-WS-WASJavaSDK-WinX32-FP00000023
<!-- [if !supportEmptyParas]--><!-- [endif]-->
任务 |
列表 |
天数 |
环境准备 |
WPS5 准备(客户提供) |
1 |
WPS6 准备(现场安装) + 启用安全性 + 数据库迁移 +Fixpack |
||
迁移前门户系统配置修改 |
||
WCM 数据清理 |
||
迁移门户数据 |
迁移客户化资源 ( 主题、皮肤等 ) |
1 |
迁移门户配置 |
||
迁移权限数据 |
||
迁移 WCM |
WCM 内容迁移 |
1.5 |
User Profile 迁移 |
||
Local Rendering Portlet 迁移 |
||
Remote Rendering Portlet 迁移 |
||
验证迁移 |
验证迁移的数据 |
0.5 |
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
查看 wpconfig.properties 配置是否正确,测试是否正常连接数据库。
PortalServer/Config 目录下执行命令 :
WPSConfig.bat validate-database-connection-wps
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportLists]-->a. <!-- [endif]-->Create an update directory in your previous WebSphere Portal directory; for example, C:/Program Files/WebSphere/PortalServer/update .
<!-- [if !supportLists]-->b. <!-- [endif]-->Download the WebSphere Portal Update Installer from http://www.ibm.com/software/genservers/portal/support/ and then unpack the Installer to the update directory you created in the previous step.
<!-- [if !supportLists]-->c. <!-- [endif]-->Unzip the interim fixes from the appropriate directory of the current WebSphere Portal directory to the update directory created in the previous step:
<!-- [if !supportLists]-->§ <!-- [endif]-->portal_server_root /migration/fixes/5102
Note: All interim fixes are already built in for version 5.1.0.4; therefore, there are no interim fixes to apply.
For version 5.1.0.2:
<!-- [if !supportLists]-->§ <!-- [endif]-->PK14100
<!-- [if !supportLists]-->§ <!-- [endif]-->PK14103
<!-- [if !supportLists]-->§ <!-- [endif]-->PK15013
<!-- [if !supportLists]-->§ <!-- [endif]-->PK19790
<!-- [if !supportLists]-->§ <!-- [endif]-->PK20467
<!-- [if !supportLists]-->§ <!-- [endif]-->PK16371
<!-- [if !supportLists]-->§ <!-- [endif]-->PK16597
<!-- [if !supportLists]-->§ <!-- [endif]-->PK18538
<!-- [if !supportLists]-->§ <!-- [endif]-->PK21688
<!-- [if !supportLists]-->§ <!-- [endif]-->PK17690
<!-- [if !supportLists]-->§ <!-- [endif]-->PK21136
<!-- [if !supportLists]-->§ <!-- [endif]-->PK22244
<!-- [if !supportLists]-->§ <!-- [endif]-->PK23901
<!-- [if !supportLists]-->§ <!-- [endif]-->PK11536
<!-- [if !supportLists]-->§ <!-- [endif]-->PK40171 – Apply this fix using the WebSphere Portal database check and update tool wpdbupdate
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportLists]-->d. <!-- [endif]-->Enter the following command on the command line to set the WAS_HOME environment variable for the previous version directory where you will run the WebSphere Portal Update Installer:
Windows: set WAS_HOME=was_old_root
For example: set WAS_HOME=C:/Program Files/WebSphere/AppServer/setupCmdLine.bat
<!-- [if !supportLists]-->e. <!-- [endif]-->Enter the following command on the command line to install one or more interim fixes:
Windows: ./updatePortal.bat -install -installDir wp_old_root -fix -fixDir wp_old_root/update -fixes list of fixes
For example : updatePortal.bat -install -installDir "C:/Program Files/WebSphere/PortalServer" -fix -fixDir "C:/Program Files/WebSphere/PortalServer/update" -fixes PK07258 PK07872
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
要备份。包括目录备份 + 数据库备份。
<!-- [if !supportEmptyParas]--><!-- [endif]-->
LDAP 目录最好是同一个或者数据是一样, LDAP 版本也一致,或者数据应该一致,否则 WCM 数据当中做用户检测部分可能存在问题。
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
WPS5 的管理员账号和密码: WAS 和 PORTAL
WPS6 的管理员账号和密码: WAS 和 PORTAL
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Because migration can be a lengthy process, we suggest that you change the timeout length of your HTTP server to unlimited timeout while performing the migration task. Refer to your HTTP server documentation for information on how to change the timeout value.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Run the migrate property collector task to collect required files from the previous version to allow the migration scripts to access the previous version:
Important: You will need to stop the previous version of your Portal server if any of the following statements are true for your environment:
<!-- [if !supportLists]-->o <!-- [endif]-->If you are using a Cloudscape database
<!-- [if !supportLists]-->o <!-- [endif]-->If there is a port conflict or resource conflict when you start the current portal server
<!-- [if !supportLists]-->o <!-- [endif]-->If you modified the number of groups
<!-- [if !supportLists]-->d. <!-- [endif]-->Copy the propcollector.xml and propcollector.jar files from the portal_server_root /migration directory of the current version to the wp_old_root/config/includes directory of the previous version and run the following command from the wp_old_root/config directory of the previous version:
Note: If using i5/OS, the directory path is portal_server_root_user for the current version of WebSphere Portal and wp_user_old_root for the previous version of WebSphere Portal.
<!-- [if !supportLists]-->§ <!-- [endif]-->Windows and UNIX: WPSconfig.{sh|bat} prop-collector -DDbPassword=wpsdb_password
<!-- [if !supportLists]-->§ <!-- [endif]-->i5/OS: Choose one of the following commands based on the version of WebSphere Application Server that you are using:
<!-- [if !supportLists]-->§ <!-- [endif]-->WebSphere Application Server 5.x: WPSconfig.sh -instance instance_name prop-collector -DDbPassword=wpsdb_password
where instance_name is the name of the WebSphere Application Server profile where WebSphere Portal is installed.
<!-- [if !supportLists]-->§ <!-- [endif]-->WebSphere Application Server 6.x: WPSconfig.sh -profileName profile_root prop-collector -DDbPassword=wpsdb_password
where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.
<!-- [if !supportLists]-->§ <!-- [endif]-->Important: The following information applies to running the above command:
<!-- [if !supportLists]-->§ <!-- [endif]-->-DDbPassword=wpsdb_password is not required if the value is already defined in the wpconfig.properties file.
<!-- [if !supportLists]-->§ <!-- [endif]-->Ensure that the values for DbUrl and DbName are defined in the wpconfig.properties file.
<!-- [if !supportLists]-->§ <!-- [endif]-->Ensure that the value for WpsHostName in the wpconfig.properties file is the fully-qualified host name of the Web server that WebSphere Application Server is configured to use and is NOT "localhost".
<!-- [if !supportLists]-->e. <!-- [endif]-->Copy the wp_old_root/config/includes/propcollectorOutput.zip file from the previous version to the portal_server_root /migration directory on the current version.
<!-- [if !supportLists]-->f. <!-- [endif]-->Run the following command from the portal_server_root /migration directory of the current version to extract the propcollectorOutput.zip file:
WPmigrate.{sh|bat} collector-extract
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Make portlet applications available to migration tasks for deployment
The portal_server_root /installedApps directory contains a list of all portlet applications that are deployed on your previous WebSphere Portal system. Depending on the features that are used by these portlets, they might have to first be upgraded to work with the current version of WebSphere Portal. Refer to the instructions that are provided in the Migrating your customized resources section to determine if you need to upgrade your portlets.
Some of the WAR files in the portal_server_root /installedApps directory might have been shipped with the current version of WebSphere Portal. In that case, there is no need to manually upgrade corresponding portlets. You can safely use the corresponding WAR file from the portal_server_root /installableApps directory as an upgraded version of the portlet.
Before running migration tasks, all the upgraded portlets must be made available in the portal_server_root /installableApps directory of your current WebSphere Portal system. This directory has the sample portlets that ship with the current version of WebSphere Portal; do not overwrite these with the sample versions that shipped with earlier versions of WebSphere Portal.
Create the virtual portal from your previous version in the current version: In order to migrate the data from your previous virtual portal into the current version, you must recreate the virtual portal in the current version. Use the Virtual Portal Manager to create the virtual portal in the current version.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Required performance tuning for exporting and importing large groups and resources
<!-- [if !supportLists]-->a. <!-- [endif]-->Check your LDAP server to determine the number of groups and perform the appropriate steps if the number is greater than 200:
<!-- [if !supportLists]-->§ <!-- [endif]-->Perform the following steps on the previous version of WebSphere Portal if migrating from version 5.1.x:
<!-- [if !supportLists]--> i. <!-- [endif]-->Change to the wp_old_root/wmm directory of the 5.1.x directory.
<!-- [if !supportLists]--> ii. <!-- [endif]-->Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.
<!-- [if !supportLists]--> iii. <!-- [endif]-->Save your changes.
<!-- [if !supportLists]--> iv. <!-- [endif]-->If this is a clustered environment, change to the was_old_root/config/wmm directory of the 5.1.x system.
<!-- [if !supportLists]--> v. <!-- [endif]-->Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.
<!-- [if !supportLists]--> vi. <!-- [endif]-->Save your changes.
<!-- [if !supportLists]--> vii. <!-- [endif]-->If this is a clustered environment, change to the dmgr_old_root/config/wmm directory on the deployment manager machine of the 5.1.x system.
<!-- [if !supportLists]--> viii. <!-- [endif]-->Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.
<!-- [if !supportLists]--> ix. <!-- [endif]-->Save your changes.
<!-- [if !supportLists]-->§ <!-- [endif]-->Perform the following steps on the current version of WebSphere Portal after completing any security-related tasks, such as, but not limited to, running the enable-security-ldap task:
<!-- [if !supportLists]--> i. <!-- [endif]-->Change to the portal_server_root /wmm directory of the current version.
<!-- [if !supportLists]--> ii. <!-- [endif]-->Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.
<!-- [if !supportLists]--> iii. <!-- [endif]-->Save your changes.
<!-- [if !supportLists]-->b. <!-- [endif]-->Change the LDAP server search parameters based on your server's documentation to an unlimited value or a value large enough to handle the exporting and importing of large groups and resources; for example:
<!-- [if !supportLists]-->§ <!-- [endif]-->Search size limit: Unlimited
<!-- [if !supportLists]-->§ <!-- [endif]-->Search time limit: Unlimited
<!-- [if !supportLists]-->§ <!-- [endif]-->Idle time out for paged searches: 172800
Note: This value should be 48 hours or more; no unlimited option is documented (value is in seconds).
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
主题和皮肤:
WPS5的皮肤和主题和WPS6有些不一样,在WPS6的基础上新建一个主题,把相关的资源替换(css or Images)。
其他:
如果客户部署了协作的Portlet、Structs Framework的portlet、业务流程的Portlet或者Portal搜索数据,请参考Inforcenter的章节:
<!-- [if !supportLists]-->l <!-- [endif]-->Migrating cooperative portlets that use IBM Portlet API
<!-- [if !supportLists]-->l <!-- [endif]-->Migrating portlets built with Struts Portlet Framework
<!-- [if !supportLists]-->l <!-- [endif]-->Migrating business process applications
<!-- [if !supportLists]-->l <!-- [endif]-->Migrating Portal Search between portal versions
<!-- [if !supportEmptyParas]--><!-- [endif]-->
命令在 portal_server_root /migration 目录
The export-portal-content task exports the WebSphere Portal content from the previous version.
Important: Before running the export-portal-content task, perform the following steps:
<!-- [if !supportLists]-->1. <!-- [endif]-->Stop the current WebSphere Portal server. ( 停止 WPS6)
<!-- [if !supportLists]-->2. <!-- [endif]-->Start the server for your previous version of WebSphere Portal and ensure it is accessible to the network. ( 启动 WPS5)
The syntax for invoking a migration task is as follows:
如果没有虚拟门户,跳过这一步。
The export-portal-content task exports the WebSphere Portal content from the previous version. 但是在 WPS6 的 portal_server_root /migration 目录运行。
Important: Before running the export-portal-content task, perform the following steps:
<!-- [if !supportLists]-->1. <!-- [endif]-->Stop the current WebSphere Portal server ( 停止 WPS6).
<!-- [if !supportLists]-->2. <!-- [endif]-->Ensure the server for your previous version of WebSphere Portal is running and accessible to the network. (启动 WPS5 )
The syntax for invoking a migration task is as follows:
where:
<!-- [if !supportEmptyParas]--><!-- [endif]-->
The import-portal-content task imports the content from the previous version of WebSphere Portal into the current version of WebSphere Portal.
在 WPS6 的 portal_server_root /migration 目录运行。
Important: Before running the import-portal-content task, perform the following steps:
<!-- [if !supportLists]-->1. <!-- [endif]-->Stop the previous WebSphere Portal server. ( 停止 WPS5)
<!-- [if !supportLists]-->2. <!-- [endif]-->Start the server for your current version of WebSphere Portal and ensure it is accessible to the network. ( 启动 WPS6)
<!-- [if !supportLists]-->3. <!-- [endif]-->Specify the WasUserid and WasPassword in the wpconfig.properties file; see Configuration properties reference for information about editing the properties file.
The syntax for invoking the migration task is as follows:
where:
Note : If running the import-portal-content task multiple times, you must Restart the servers before rerunning the task.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
如果没有虚拟门户,跳过这一步。
The import-portal-content task imports the content from the previous version of WebSphere Portal into the current version of WebSphere Portal.
Important: Before running the import-portal-content task, perform the following steps:
<!-- [if !supportLists]-->1. <!-- [endif]-->Stop the previous WebSphere Portal server. ( 停止 WPS5)
<!-- [if !supportLists]-->2. <!-- [endif]-->Ensure the server for your current version of WebSphere Portal is running and accessible to the network. ( 启动 WPS6)
Tip: Before importing each Virtual Portal, backup your database.
The syntax for invoking the migration task is as follows:
where:
Note: If running the import-portal-content task multiple times, you must Restart the servers before rerunning the task.
If you cloned the FileServer portlet in previous versions and supplied HTML files in the wp_old_root/installedApps/FileServer.war/FileServerPortlet/html directory, you must copy those files to the portal_server_root /installedApps/FileServer.war/FileServerPortlet/html directory, after running the import task and before restarting the server, to make the files accessible in the current version.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
After completing the import-portal-content task, restart the following server on the current version only:
<!-- [if !supportLists]-->1. <!-- [endif]-->Open a command prompt and change to the following directory:
<!-- [if !supportLists]-->o <!-- [endif]-->Windows: was_profile_root /bin
<!-- [if !supportLists]-->2. <!-- [endif]-->Enter the following command:
<!-- [if !supportLists]-->o <!-- [endif]-->Windows : stopServer.bat WebSphere_Portal -user admin_userid -password admin_password
<!-- [if !supportLists]-->3. <!-- [endif]-->Enter the following command:
<!-- [if !supportLists]-->o <!-- [endif]-->Windows: startServer.bat WebSphere_Portal
虽然前面成功的迁移了门户配置数据,但是有些权限配置相关数据,是没有迁移的,例如:凭证保险库相关数据,资源许可权的数据等等。
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportLists]-->1. <!-- [endif]-->Migrating permissions on All Authenticated Portal Users and All Portal User Groups group
Permissions on User Groups allows principals to perform the following tasks:
<!-- [if !supportLists]-->o <!-- [endif]-->Edit group information
<!-- [if !supportLists]-->o <!-- [endif]-->Change group membership
<!-- [if !supportLists]-->o <!-- [endif]-->Change the access rights of the group members
Follow this step to migrate permissions on user groups:
On the current WebSphere Portal system, use the User and Group Permissions portlet, the Resource Permissions portlet, or the XML configuration interface to assign the principals to roles on the appropriate user groups. For more information, refer to the portlet helps or The XML configuration interface . Follow these steps to assign the principals to roles on the appropriate user groups using the Resource Permissions portlet:
<!-- [if !supportLists]--> i. <!-- [endif]-->Log in to portal using an administrator account.
<!-- [if !supportLists]--> ii. <!-- [endif]-->Open the Resource permissions portlet.
<!-- [if !supportLists]--> iii. <!-- [endif]-->Select the Resource type User Groups.
<!-- [if !supportLists]--> iv. <!-- [endif]-->Select the All Authenticated Portal Users option and analyze the existing role assignments on that user group.
<!-- [if !supportLists]--> v. <!-- [endif]-->Use the Resource permissions portlet to create the same role assignments on the new portal.
<!-- [if !supportLists]--> vi. <!-- [endif]-->Repeat these steps for All Portal User Groups .
<!-- [if !supportLists]-->2. <!-- [endif]-->Migrating permissions on WebSphere Portal 5.1.x administrative resources
Log onto your previous version of WebSphere Portal and go to the Manage pages portlet. View and make note of the access control settings for your previous version. Then log into your current version of WebSphere Portal and go to the Manage pages portlet. Recreate the access control from your previous version in your current version.
5.1.x Administrative Page |
5.1.x Administration Portlet title |
Portal User Interface <!-- [if !supportLists]-->o <!-- [endif]-->Manage Pages <!-- [if !supportLists]-->o <!-- [endif]-->Themes and Skins |
Manage Pages Themes and Skins |
Portlet Management <!-- [if !supportLists]-->o <!-- [endif]-->Web Modules <!-- [if !supportLists]-->o <!-- [endif]-->Applications <!-- [if !supportLists]-->o <!-- [endif]-->Portlets <!-- [if !supportLists]-->o <!-- [endif]-->Web Services <!-- [if !supportLists]-->o <!-- [endif]-->Web Clipping |
Manage Web Modules Manage Applications Manage Portlets Web Service Configuration Web Clipping Editor |
Access <!-- [if !supportLists]-->o <!-- [endif]-->Users and Groups <!-- [if !supportLists]-->o <!-- [endif]-->Resource Permissions <!-- [if !supportLists]-->o <!-- [endif]-->User and Group Permissions <!-- [if !supportLists]-->o <!-- [endif]-->Credential Vault |
Manage Users and Groups Resource Permissions User and Group Permissions Credential Vault |
Portal Settings <!-- [if !supportLists]-->o <!-- [endif]-->Global Settings <!-- [if !supportLists]-->o <!-- [endif]-->URL Mapping <!-- [if !supportLists]-->o <!-- [endif]-->Custom Unique Names <!-- [if !supportLists]-->o <!-- [endif]-->Supported Markups <!-- [if !supportLists]-->o <!-- [endif]-->Supported Clients <!-- [if !supportLists]-->o <!-- [endif]-->Search Administration <!-- [if !supportLists]-->o <!-- [endif]-->Import XML |
Global Settings URL Mapping portlet Manage Custom Unique Names Manage Markups Manage Clients Manage Search Collection Import XML |
Portal Analysis <!-- [if !supportLists]-->o <!-- [endif]-->Frequent Users <!-- [if !supportLists]-->o <!-- [endif]-->Enable Tracing |
Frequent Users Enable Tracing |
Portal Content <!-- [if !supportLists]-->o <!-- [endif]-->Manage Document Libraries |
Manage Document Libraries |
Virtual Portals <!-- [if !supportLists]-->o <!-- [endif]-->Manage Virtual Portals |
Virtual Portal Manager |
Page Customizer <!-- [if !supportLists]-->o <!-- [endif]-->Content Layout <!-- [if !supportLists]-->o <!-- [endif]-->Appearance <!-- [if !supportLists]-->o <!-- [endif]-->Locks <!-- [if !supportLists]-->o <!-- [endif]-->Wires |
Edit Layout Appearance portlet Page Locks Portlet Wiring Tool |
Page properties |
Page properties |
Organize Favorites |
Organize Favorites |
Login |
Login portlet |
Edit My Profile |
Edit My Profile |
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportLists]-->3. <!-- [endif]-->Migrating credential vault data
When you migrated the WebSphere Portal configuration using either the command line script or the wizard, the Credential Vault slots and segments were also migrated. This section assumes that the WebSphere Portal migration was successfully completed.
Existing credential secrets must be handled differently depending on your environment:
<!-- [if !supportLists]-->o <!-- [endif]-->WebSphere Portal Default Vault: complete the following procedure if you want to migrate existing credential secrets to the current WebSphere Portal system.
<!-- [if !supportLists]-->o <!-- [endif]-->Third-party vault implementation (Tivoli Access Manager): No additional steps are required. Existing credential secrets can be used in the current WebSphere Portal system.
Note: If you decide not to migrate existing credential secrets, users must provide their credential information the first time a Version 6.0 portlet attempts to use the data.
(参考 Inforcenter )
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Run the WPSconfig. {sh | bat} configure-wcm-migration task from the portal_server_root /config directory of your new system.
The user specified in the command must be a WebSphere Application Server administrator.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
To view a report:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEReferenceChecker
To correct reference errors, use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEReferenceChecker&fix=true
<!-- [if !supportEmptyParas]--><!-- [endif]-->
To view a report, use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPESiteChecker
To correct site errors, use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPESiteChecker&fix=true
<!-- [if !supportEmptyParas]--><!-- [endif]-->
To view a report, use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEResourceChecker
To correct resource errors, use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEResourceChecker&fix=true
<!-- [if !supportEmptyParas]--><!-- [endif]-->
To view a report, use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=MemberFixer
To update changes to Member Manager users and groups in Web Content Management items, use the following URL:
http://[HOST]:[PORT]/wps/wcm/connect?MOD=MemberFixer&fix=true
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
有加密的 excel/word/ppt 在 WCM 作为附件,会迁移失败,应该在迁移之前去掉保护。
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportLists]-->1. <!-- [endif]-->Copy the portal_server_root /wcm/config/ folder from your old system(WPS5) to a temporary migration folder on the new system(WPS6). Do not overwrite the portal_server_root /wcm/config/ on the new system.
<!-- [if !supportLists]-->2. <!-- [endif]-->Depending on which data repository your old system uses, you will need to copy the following files from your old system to the portal_server_root /wcm/migration/exporter/lib folder of your new system. These will typically be:
<!-- [if !supportLists]-->o <!-- [endif]-->Oracle Enterprise Edition : ojdbc14.jar
<!-- [if !supportLists]-->3. <!-- [endif]-->Update the portal_server_root /wcm/migration/exporter/classpath.properties by adding the names of the files you copied in step 2 to the value of the exporter.classpath property.
<!-- [if !supportLists]-->4. <!-- [endif]-->If migrating from a DB2 repository, you will need to edit the following files located in the /wcm/config/ folder you created in step 1:
<!-- [if !supportLists]-->o <!-- [endif]-->aptrixjpe.properties : Ensure jdbc.url=jdbc:db2://<db2 host name>:<port number>/wcmdb is configured to point to the database of the old system and ensure that there are no spaces before or after the URL.
<!-- [if !supportLists]-->o <!-- [endif]-->connect.cfg : Ensure <jdbc:db2://<db2 host name>:<port number>/wcmdb driver="com.ibm.db2.jcc.DB2Driver" />
Note: The port number for DB2 on your new system can be found under %systemroot%/system32/drivers/etc/services on Windows systems or /etc/services on UNIX systems.
<!-- [if !supportLists]-->5. <!-- [endif]-->If migrating from an embedded Cloudscape repository, stop the portal server on the old system and then copy this database to your new system before migrating Web Content Management. You will need to edit the following files located in the /wcm/config/ folder you created in step 1:
<!-- [if !supportLists]-->o <!-- [endif]-->aptrixjpe.properties : Ensure jdbc.url=jdbc:db2j:<path_to_database> is configured to point to the location of the Cloudscape database on the new system and ensure that there are no spaces before or after the URL.
<!-- [if !supportLists]-->o <!-- [endif]-->connect.cfg : Ensure <jdbc:db2j:<path_to_database> driver="com.ibm.db2j.jdbc.DB2jDriver" />
<!-- [if !supportLists]-->6. <!-- [endif]-->Update the portal_server_root /wcm/migration/config/migration.properties file on your new system. Confirm that the following parameters are set as specified and modify them if necessary:
<!-- [if !supportLists]-->o <!-- [endif]-->export.path : The path on the local file system where exported data will be saved.
<!-- [if !supportLists]-->o <!-- [endif]-->import.path : The directory on the local file system where transformed data is saved.
<!-- [if !supportLists]-->o <!-- [endif]-->summary.path : The path on the local file system where summary configuration files will be created. These files will be used when migrating a secondary system.
<!-- [if !supportLists]-->o <!-- [endif]-->legacy.config.path : The path on the local file system where the old Web Content Management configuration is located. See step 1.
<!-- [if !supportLists]-->o <!-- [endif]-->import.servlet.url : The URL of the import servlet, running on the new system. Replace localhost with the appropriate host name for the new system.
<!-- [if !supportLists]-->o <!-- [endif]-->import.library.name : The name of the library created during import.
<!-- [if !supportLists]-->o <!-- [endif]-->import.library.locale : zh
<!-- [if !supportLists]-->7. <!-- [endif]-->Increase the total transaction lifetime timeout of your new WebSphere Portal server to 1200 seconds through the WebSphere Application Server administrative console. Go to Application Servers server Container Services Transaction Service . See the WebSphere Application Server information center for more information. Make a note of the current total transaction lifetime timeout so that it can be restored in step 10.
<!-- [if !supportLists]-->8. <!-- [endif]-->Restart the portal application server.
<!-- [if !supportLists]-->9. <!-- [endif]-->Run the wcmmigrate all-data task from the portal_server_root /wcm/migration directory of your new system.
Important: Before you run the wcmmigrate task, make sure that the portal server on the new system is running.
<!-- [if !supportLists]-->o <!-- [endif]-->Windows: wcmmigrate.bat -user username -password password all-data
The user specified in the command must be a WebSphere Portal administrator.
Notes:
All errors, information and warnings are logged to the console as migration is performed. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to do the following:
Running individual wcmmigrate all-data commands <!-- [if !supportEmptyParas]--><!-- [endif]--> When you run the wcmmigrate all-data task, a set of commands are executed. To troubleshoot the wcmmigrate all-data task, you can run each of the commands separately. They should be run in the order shown below.
For example, to run the validate command, run the following command from the portal_server_root /wcm/migration directory.
The user specified in the command must be a WebSphere Portal administrator. Resuming or restarting wcmmigrate commands Once you have identified and fixed the issue that was causing a migration to fail, you have a choice of either restarting a wcmmigrate command, or resuming a wcmmigrate command from the point where a migration error occurred. For example, to restart the wcmmigrate all-data command, enter the following from the portal_server_root /wcm/migration directory.
The user specified in the command must be a WebSphere Portal administrator. To resume the wcmmigrate all-data command from the point where migration failed, enter the following from the portal_server_root /wcm/migration directory.
The user specified in the command must be a WebSphere Portal administrator. Log tracing levels By default, the migration log trace level is set to "fine". This is set in the portal_server_root /wcm/migration/config/migration.properties file. If you change this setting to "finer" or "finest", data migration may slow or fail. If migration is still slow with a trace level of "fine", you should change the trace-level to "info". |
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportLists]-->10. <!-- [endif]-->Verify the migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.
Note: The total number of items exported, transformed and imported may not be equal, as some items will be merged and other items added during the migration process.
<!-- [if !supportLists]-->11. <!-- [endif]-->Restore the total transaction lifetime timeout setting to the original setting that was changed in step 7.
<!-- [if !supportLists]-->12. <!-- [endif]-->Restart the portal application server.
<!-- [if !supportLists]-->13. <!-- [endif]-->Review the configuration of the library created when the data was migrated and make changes as required. For example, you will need to enable user access to this library by adding users and groups to each library role. See Working with libraries for further information on configuring a Web content library.
<!-- [if !supportLists]-->14. <!-- [endif]-->Syndicate the migrated data to all the other servers in your new Web content system. See Syndication for further information.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
After migrating your primary data you must update the portal users to use the migrated data.
Note: If you are using dynamic keywords then you must migrate Member Manager before migrating user profiles. See Migrating the remaining access control configuration for further information. If you are not using dynamic keywords, or if you have already migrated Member Manager as part of your core IBM® WebSphere® Portal migration, you do not need to do migrate Member Manager.
<!-- [if !supportLists]-->1. <!-- [endif]-->If you are migrating users on a primary system, go to step 3. If you are migrating users on a secondary system, copy the summary configuration files created when migrating your primary system to a folder on the secondary system. See summary.path in the data migration topic.
<!-- [if !supportLists]-->2. <!-- [endif]-->Update the portal_server_root /wcm/migration/config/migration.properties file. Confirm that the following parameters are set as specified and modify them if necessary:
<!-- [if !supportLists]-->o <!-- [endif]-->summary.path : The path on the local file system where the old IBM Workplace Web Content Management™ summary configuration files were copied in step 1.
<!-- [if !supportLists]-->3. <!-- [endif]-->If your LDAP server contains more than 200 users, you must perform the following steps. Otherwise, proceed to step 4.
<!-- [if !supportLists]-->a. <!-- [endif]-->Stop your WebSphere Portal server.
<!-- [if !supportLists]-->b. <!-- [endif]-->Make a backup of portal_server_root /wmm/wmm.xml named wmm.xml.bak .
Note: If using i5/OS, wmm.xml is located under portal_server_root .
<!-- [if !supportLists]-->c. <!-- [endif]-->Edit portal_server_root /wmm/wmm.xml and change the following settings:
<!-- [if !supportLists]-->§ <!-- [endif]-->Change maximumSearchResults , maximumSearchResultsForSortingAndPaging and maximumTotalSearchResultsForSortingAndPaging to a number higher than the total number of users. For example, if you have 300 users, you must change these settings to at least 301.
<!-- [if !supportLists]-->§ <!-- [endif]-->Change searchTimeOut to 2,000,000.
<!-- [if !supportLists]-->4. <!-- [endif]-->Increase the total transaction lifetime timeout of your new WebSphere Portal server to 3600 seconds through the WebSphere Application Server administrative console. Go to Application Servers server Container Services Transaction Service . See the WebSphere Application Server information center for more information. Make a note of the current total transaction lifetime timeout so that it can be restored in step 7.
<!-- [if !supportLists]-->5. <!-- [endif]-->Restart the portal application server.
<!-- [if !supportLists]-->6. <!-- [endif]-->Run the wcmmigrate users task from the portal_server_root /wcm/migration directory, where portal_server_root is the install directory path of the current version of WebSphere Portal.
<!-- [if !supportLists]-->o <!-- [endif]-->Windows: wcmmigrate.bat -user username -password password users
The user specified in the command must be a WebSphere Portal administrator.
<!-- [if !supportLists]-->7. <!-- [endif]-->Verify the user migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.
<!-- [if !supportLists]-->8. <!-- [endif]-->Restore the total transaction lifetime timeout setting to the original setting that was changed in step 4.
<!-- [if !supportLists]-->9. <!-- [endif]-->If you performed step 3, you must do the following:
<!-- [if !supportLists]--> . <!-- [endif]-->Stop your WebSphere Portal server.
<!-- [if !supportLists]-->a. <!-- [endif]-->Restore the wmm.xml.bak file you created in step 3.b to portal_server_root /wmm/wmm.xml .
<!-- [if !supportLists]-->10. <!-- [endif]-->Restart the portal application server.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
After migrating your primary data you must re-configure all local rendering portlets to use the migrated data.
Note: You must migrate Web content data before migrating a local rendering portlet. See Migrating Web content data for further information.
Note: If you have a small number of local rendering portlets, it may be simpler to install and configure new local rendering portlets to use the migrated data instead of migrating any existing portlets. See Configuring the local rendering portlet for further information.
<!-- [if !supportLists]-->1. <!-- [endif]-->If you are migrating one or more local rendering portlets on a primary system, go to step 3. If you are migrating one or more local rendering portlets on a secondary system, copy the summary configuration files created when migrating your primary system to a folder on the secondary system. See summary.path in the data migration topic.
<!-- [if !supportLists]-->2. <!-- [endif]-->Update the portal_server_root /wcm/migration/config/migration.properties file. Confirm that the following parameters are set as specified and modify them if necessary:
<!-- [if !supportLists]-->o <!-- [endif]-->summary.path : The path on the local file system where the old IBM Workplace Web Content Management™ summary configuration files were copied in step 1.
<!-- [if !supportLists]-->o <!-- [endif]-->virtual.portal : If migrating a local rendering portlet located on a virtual portal, you must enter the name of the virtual portal.
<!-- [if !supportLists]-->3. <!-- [endif]-->Run the wcmmigrate configure-local task from the portal_server_root /wcm/migration directory, where portal_server_root is the install directory path of the current version of WebSphere Portal.
<!-- [if !supportLists]-->o <!-- [endif]-->Windows: wcmmigrate.bat -user username -password password configure-local
The user specified in the command must be a WebSphere Portal administrator.
<!-- [if !supportLists]-->4. <!-- [endif]-->Verify the migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.
<!-- [if !supportLists]-->5. <!-- [endif]-->Verify the configuration of the migrated local rendering portlet. See Configuring the local rendering portlet for further information on configuring a local rendering portlet.
Note: Restart the portal server after completing the above steps to verify that the portlets have been configured correctly.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
After migrating your primary data you must re-configure all remote rendering portlets to use the migrated data.
Note: You must migrate Web content data on the system that the remote rendering portlet is configured to use before migrating a remote rendering portlet. See Migrating Web content data for further information.
Note: If you have a small number of remote rendering portlets, it may be simpler to install and configure new remote rendering portlets to use the migrated data instead of migrating any existing portlets. See Configuring the remote rendering portlet for further information.
<!-- [if !supportLists]-->1. <!-- [endif]-->If you are migrating one or more remote rendering portlets on a primary system, go to step 3. If you are migrating one or more remote rendering portlets on a secondary system, copy the summary configuration files created when migrating your primary system to a folder on the secondary system. See summary.path in the data migration topic.
<!-- [if !supportLists]-->2. <!-- [endif]-->Update the portal_server_root /wcm/migration/config/migration.properties file. Confirm that the following parameters are set as specified and modify them if necessary:
<!-- [if !supportLists]-->o <!-- [endif]-->summary.path : The path on the local file system where the old IBM Workplace Web Content Management summary configuration files were copied in step 1.
<!-- [if !supportLists]-->o <!-- [endif]-->virtual.portal : If migrating a remote rendering portlet located on a virtual portal, you must enter the name of the virtual portal.
<!-- [if !supportLists]-->3. <!-- [endif]-->Update the portal_server_root /wcm/migration/config/remote_rendering.properties file. Confirm that the following parameters are set as specified and modify them if necessary:
<!-- [if !supportLists]-->o <!-- [endif]-->remote.host.base.path.list : Enter the remote host base path of old remote rendering portlet. This is the "Web Content Management Server Host" specified in the old remote rendering portlet configuration. For example,
<!-- [if !supportLists]-->o <!-- [endif]-->remote.host.base.path.list=http://oldhostname:9081
Note: If all your old remote rendering portlets use data from a single system you can specify remote.host.base.path.list=all .
<!-- [if !supportLists]-->o <!-- [endif]-->WCM_REMOTE_HOST_BASE_PATH : Enter the remote host base path of the server the remote rendering portlet is being migrated to. For example,
<!-- [if !supportLists]-->o <!-- [endif]-->WCM_REMOTE_HOST_BASE_PATH=http://newhostname:9081
<!-- [if !supportLists]-->4. <!-- [endif]-->Run the wcmmigrate configure-remote task from the portal_server_root /wcm/migration directory, where portal_server_root is the install directory path of the current version of IBM WebSphere Portal.
<!-- [if !supportLists]-->o <!-- [endif]-->Windows: wcmmigrate.bat -user username -password password configure-remote
The user specified in the command must be a WebSphere Portal administrator.
<!-- [if !supportLists]-->5. <!-- [endif]-->Verify the migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.
<!-- [if !supportLists]-->6. <!-- [endif]-->Verify the configuration of the migrated remote rendering portlet. See Configuring the remote rendering portlet for further information on configuring a remote rendering portlet.
Note: Restart the portal server after completing the above steps to verify that the portlets have been configured correctly.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
The IBM® Workplace Web Content Management™ migration process does not automatically update your Web content to use all the new features of the current release. The following steps are recommended to update your old Web content to take advantage of the new Web Content Management features.
The Web content configuration files connect.cfg and aptrixjpe.properties have been deprecated and replaced by the WCMConfigService.properties file. No configuration settings from your old system are migrated to this file. You will need to edit this file and update settings to match your old configuration if required.
The WCMConfigService.properties file is located under:
Note: The JDBC URL property
Database driver URLs now need to contain escape characters. You will need to edit any JDBC URLs copied from an old connect.cfg file. For example:
connect.connector.sqlconnector.databases.jdbc:microsoft:sqlserver://host:port;DatabaseName=dbname
connect.connector.sqlconnector.databases.jdbc/:microsoft/:sqlserver/://host/:port;DatabaseName/=dbname
You should replace any anchor tags or URLs in presentation templates or element designs by using either a link element, or using the "add link" feature in HTML and rich text fields and elements. See the Link element and Inserting a link in an element topics for further information.
To assist in this process, the following files are created under the summary path folder specified during data migration:
These files can be used as reference material as they list the old and new names and paths of content items, components (library components), elements (content components) and presentation templates.
During migration, some items will be merged, added or renamed. You may need to update links to Web Content Management content from external sites.
To assist in this process, the following files are created under the summary path folder specified during data migration:
These files list the old and new names and paths of content items, components (library components), elements (content components) and presentation templates.
Unlike previous versions of Web Content Management, you are not able create two sibling Web Content items using the same name in IBM WebSphere® Portal version 6.0.
For example, your old system may have the following site framework:
During migration, the second site area will be renamed as "MySiteArea_1". The site framework will now look like this:
Any references to the path "MySite/MySiteArea" will be left unchanged, but will now only point to the site area named "MySiteArea". You will need to edit any paths that should now point to "MySite/MySiteArea_1" instead.
This example also applies to other siblings such as categories and content items.
Any draft sites, site areas and taxonomies that have child items will be published during migration, as will their children. Any items that have had there status changed from draft to published are listed in published_draft_items.txt located under the summary path folder specified during data migration. You should review this file and check that any changes to these published items are valid.
If no items have had there status changed from draft to published, this file will not be created.
Paging is now supported in the design of navigator elements. After migration, the maximum number of items to be displayed per page is set at one hundred by default. If any or your navigators display more than one hundred items, you will need to edit this figure. You can also add a paging element to your navigator design. See Defining navigator element design options for further information.
A "no result" design has been added to menu elements. You must edit all your menus and enter appropriate text in the "no result" design. Otherwise, nothing will be displayed when a menu finds no results. See Defining menu element formatting options for further information.
A title field has been added to the identification section of all items. The title is the text displayed to end-users when viewing a list of items in the authoring portlet. Unlike the name, titles can use double-byte and non-ASCII characters. When migrated, the current name is also copied to the title field. You will need to edit any items where you would like to use a different title than one created during migration.
Any Web content tags that use the field="name" attribute, such as the placeholder tag, can be changed to use field="title" as well.
The use of "connect" tags has been deprecated, with the exception of component caching. Content that uses "connect" tags will still work, but it is recommended that "connect" tags be replaced with other standard Web content features. See Displaying data from external sources for further information.
The Web Content Management search module is no longer supported. The WebSphere Portal search features are now used to search for Web Content.
Any search forms that use the Web Content Management search module must be replaced or updated with search forms using the WebSphere Portal search features. See Searching Sites for details on using the WebSphere Portal search features with Web content.
The Web Content Management migration process will only create a single library. To implement multiple libraries, you will need to create new libraries and move items from the migrated library into the new libraries. See Copying and moving items for further information.
After migration, any Web Content Management API code should still function as normal. The API will, by default, use the library specified in the WCMConfigService.properties file.
Once you create new libraries and add items to those libraries, you will need to update your API code to be library-specific by using the setCurrentDocumentLibrary method. See the Javadoc HTML files located under the was_profile_root /AppServer/profiles/wp_profile/installedApps/nodename/wcm.ear/ilwwcm.war/webinterface/ folder for further information on using this method.
Any JSP files used on your old system will need to be manually copied to your new system. See JSP elements for details on where to store JSP files.
You no longer assign access to the different views in the authoring portlet by configuring the authoring portlet. Access to the different views in the authoring portlet is now determined by the role assigned to users and groups. See Using item type roles within a library for further information.
Referential integrity features have been added in this release. See Collaborative authoring and Deleting items for further information.
These features are not applied to a migrated items that contain element or component tags until the item is opened and saved in the authoring portlet.
Although authoring portlets are not migrated, any portal pages that previously displayed an authoring portlet on your old system are migrated as blank pages. You can either delete these pages, or add a new authoring portlet to the blank page.
Migrated presentation templates may contain additional HTML header information not present in the original presentation template. The additional header information will not affect any content rendered in the presentation template and can be deleted.
To remove the migration tool, run the remove-wcm-migration task from the portal_server_root /config directory of your new system.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
This section provides information that you can use to verify the success of the migration tasks.
Perform the appropriate tasks to verify that your migration was successful:
<!-- [if !supportLists]-->1. <!-- [endif]-->Verify Notes and Domino Web Access (iNotes™) portlets migration
<!-- [if !supportLists]-->2. <!-- [endif]-->Verify migration of portal clients
<!-- [if !supportLists]-->3. <!-- [endif]-->Verify migration of user customizations
<!-- [if !supportLists]-->4. <!-- [endif]-->Verify migration of credential vault data
<!-- [if !supportLists]-->5. <!-- [endif]-->Verify migration of themes and skins
<!-- [if !supportLists]-->6. <!-- [endif]-->Verify migration of portlet applications
<!-- [if !supportLists]-->7. <!-- [endif]-->Verify migration of portlet configuration data
<!-- [if !supportLists]-->8. <!-- [endif]-->Verify migration of virtual resources
<!-- [if !supportLists]-->9. <!-- [endif]-->Verify migration of pages
<!-- [if !supportLists]-->a. <!-- [endif]-->Log in to the current WebSphere Portal Administrative Interface.
<!-- [if !supportLists]-->b. <!-- [endif]-->Click Portlet Management > Portlets .
<!-- [if !supportLists]-->c. <!-- [endif]-->There should be a portlet in the portlet list for each portlet that existed in the previously installed version.
Note: In some previous versions of WebSphere Portal, these portlets were individual portlets, while in the current version, they are copies of one portlet.
<!-- [if !supportLists]-->d. <!-- [endif]-->Select each migrated portlet, click Configure Portlet , and verify that the portlet settings were migrated correctly. If you are migrating pages that had Notes portlets in them, the portlets should be on the page after migration and should work as they did on the previous version.
<!-- [if !supportLists]-->e. <!-- [endif]-->Log in to the current WebSphere Portal Administrative Interface.
<!-- [if !supportLists]-->f. <!-- [endif]-->Click Administration > Portal Settings > Supported Clients .
<!-- [if !supportLists]-->g. <!-- [endif]-->Verify that the portal clients that you migrated show up in the list of supported clients.
<!-- [if !supportLists]-->h. <!-- [endif]-->Select the clients that were migrated and click Edit Selected Client to verify that all settings for the client were migrated.
<!-- [if !supportLists]-->i. <!-- [endif]-->Verify that your migrated clients are able to access WebSphere Portal.
User customizations are artifacts that are attributed to a portal user that has EDIT but not MANAGE permissions on a page. These are created when such a user changes the layout of a page or edits portlet settings.
<!-- [if !supportLists]-->j. <!-- [endif]-->Log in to the current WebSphere Portal with credentials of users having the customizations.
<!-- [if !supportLists]-->k. <!-- [endif]-->Verify that all user customizations from the previous version are present in the current version. You can also pick users at random and ensure that the users see the correct customizations in the current version by comparing them visually to customizations in the previous version.
These procedures help verify that the credential slots and segments were migrated successfully. Existing credential vault data must be migrated with a separate manual procedure that is described in the Migrating the remaining access control configuration section.
<!-- [if !supportLists]-->l. <!-- [endif]-->Log in to the current WebSphere Portal Administrative Interface.
<!-- [if !supportLists]-->m. <!-- [endif]-->Click Access and then click Credential Vault on the left navigation.
<!-- [if !supportLists]-->n. <!-- [endif]-->Using the Manage vault segments and Manage system vault slots options, verify that credential segments and slots from the previous version are now also present in the current version.
<!-- [if !supportLists]-->o. <!-- [endif]-->Log in to the current WebSphere Portal Administrative Interface.
<!-- [if !supportLists]-->p. <!-- [endif]-->Click Portal user interface > Themes and Skins in the left navigation.
<!-- [if !supportLists]-->q. <!-- [endif]-->Verify that the themes and skins that are listed are the ones that you migrated from the previous version to the current version.
<!-- [if !supportLists]-->r. <!-- [endif]-->Verify that you are able to associate migrated themes and skins to existing pages and portlets, and verify that they produce the required view.
<!-- [if !supportLists]-->s. <!-- [endif]-->Log in to the current WebSphere Portal Administrative Interface.
<!-- [if !supportLists]-->t. <!-- [endif]-->Click Portlet Management > Applications on the left navigation.
<!-- [if !supportLists]-->u. <!-- [endif]-->Verify that the portlet applications that are listed are the ones that you migrated from the previous version.
<!-- [if !supportLists]-->v. <!-- [endif]-->For each Web Module, verify that all your portlet applications also display in the Portlet Applications list.
<!-- [if !supportLists]-->w. <!-- [endif]-->For each portlet application that is migrated and for which you have set up parameters on the previous version, click Edit portlet application next to the portlet applications list and verify that the parameters were migrated correctly.
You should also verify the access control for migrated portlet application and portlets using the Administrative Interface.
<!-- [if !supportLists]-->x. <!-- [endif]-->Click Access > Resource Permissions and select Portlet Applications from Resource Types .
<!-- [if !supportLists]-->y. <!-- [endif]-->Click Assign Access to verify the access control information.
<!-- [if !supportLists]-->z. <!-- [endif]-->Click Access > Resource Permissions and select Portlets from Resource Types .
<!-- [if !supportLists]-->aa. <!-- [endif]-->Click Assign Access to verify the access control information.
You can also perform a full export of the current WebSphere Portal after migration is complete and verify the roles in the exported XML file. Refer to The XML configuration interface for more information.
<!-- [if !supportLists]-->bb. <!-- [endif]-->Log in to the current WebSphere Portal Administrative Interface.
<!-- [if !supportLists]-->cc. <!-- [endif]-->Click Portlet Management > Portlets on the left navigation.
<!-- [if !supportLists]-->dd. <!-- [endif]-->Verify that all portlet configuration data migrated from the previous version are present in the current version by selecting the portlet from the list and clicking Configure portlet .
<!-- [if !supportLists]-->ee. <!-- [endif]-->Log in to the current WebSphere Portal Administrative Interface.
<!-- [if !supportLists]-->ff. <!-- [endif]-->Click Access > Resource Permissions on the left navigation.
<!-- [if !supportLists]-->gg. <!-- [endif]-->Select Virtual Resources from Resource Types .
<!-- [if !supportLists]-->hh. <!-- [endif]-->Verify that all virtual resources migrated from the previous version are present in the current version.
If only the Welcome and Getting Started pages display, see Problem: After migration, only the Welcome and Getting Started pages are available for information; otherwise, migration of pages was successful.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- [if !supportEmptyParas]--><!-- [endif]-->
附件:
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Technical contents of ISO 639:1988 (E/F)
"Code for the representation of names of languages".
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Typed by [email protected] 1990-11-30 <ftp://dkuug.dk/i18n/ISO_639>
Minor corrections, 1992-09-08 by Keld Simonsen
Sundanese corrected, 1992-11-11 by Keld Simonsen
Telugu corrected, 1995-08-24 by Keld Simonsen
Hebrew, Indonesian, Yiddish corrected 1995-10-10 by Michael Everson
Inuktitut, Uighur, Zhuang added 1995-10-10 by Michael Everson
Sinhalese corrected, 1995-10-10 by Michael Everson
Faeroese corrected to Faroese, 1995-11-18 by Keld Simonsen
Sangro corrected to Sangho, 1996-07-28 by Keld Simonsen
<!-- [if !supportEmptyParas]--><!-- [endif]-->
Two-letter lower-case symbols are used.
The Registration Authority for ISO 639 is Infoterm, Osterreichisches
Normungsinstitut (ON), Postfach 130, A-1021 Vienna, Austria.
<!-- [if !supportEmptyParas]--><!-- [endif]-->
aa Afar
ab Abkhazian
af Afrikaans
am Amharic
ar Arabic
as Assamese
ay Aymara
az Azerbaijani
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ba Bashkir
be Byelorussian
bg Bulgarian
bh Bihari
bi Bislama
bn Bengali; Bangla
bo Tibetan
br Breton
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ca Catalan
co Corsican
cs Czech
cy Welsh
<!-- [if !supportEmptyParas]--><!-- [endif]-->
da Danish
de German
dz Bhutani
<!-- [if !supportEmptyParas]--><!-- [endif]-->
el Greek
en English
eo Esperanto
es Spanish
et Estonian
eu Basque
<!-- [if !supportEmptyParas]--><!-- [endif]-->
fa Persian
fi Finnish
fj Fiji
fo Faroese
fr French
fy Frisian
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ga Irish
gd Scots Gaelic
gl Galician
gn Guarani
gu Gujarati
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ha Hausa
he Hebrew (formerly iw)
hi Hindi
hr Croatian
hu Hungarian
hy Armenian
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ia Interlingua
id Indonesian (formerly in)
ie Interlingue
ik Inupiak
is Icelandic
it Italian
iu Inuktitut
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ja Japanese
jw Javanese
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ka Georgian
kk Kazakh
kl Greenlandic
km Cambodian
kn Kannada
ko Korean
ks Kashmiri
ku Kurdish
ky Kirghiz
<!-- [if !supportEmptyParas]--><!-- [endif]-->
la Latin
ln Lingala
lo Laothian
lt Lithuanian
lv Latvian, Lettish
<!-- [if !supportEmptyParas]--><!-- [endif]-->
mg Malagasy
mi Maori
mk Macedonian
ml Malayalam
mn Mongolian
mo Moldavian
mr Marathi
ms Malay
mt Maltese
my Burmese
<!-- [if !supportEmptyParas]--><!-- [endif]-->
na Nauru
ne Nepali
nl Dutch
no Norwegian
<!-- [if !supportEmptyParas]--><!-- [endif]-->
oc Occitan
om (Afan) Oromo
or Oriya
<!-- [if !supportEmptyParas]--><!-- [endif]-->
pa Punjabi
pl Polish
ps Pashto, Pushto
pt Portuguese
<!-- [if !supportEmptyParas]--><!-- [endif]-->
qu Quechua
<!-- [if !supportEmptyParas]--><!-- [endif]-->
rm Rhaeto-Romance
rn Kirundi
ro Romanian
ru Russian
rw Kinyarwanda
<!-- [if !supportEmptyParas]--><!-- [endif]-->
sa Sanskrit
sd Sindhi
sg Sangho
sh Serbo-Croatian
si Sinhalese
sk Slovak
sl Slovenian
sm Samoan
sn Shona
so Somali
sq Albanian
sr Serbian
ss Siswati
st Sesotho
su Sundanese
sv Swedish
sw Swahili
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ta Tamil
te Telugu
tg Tajik
th Thai
ti Tigrinya
tk Turkmen
tl Tagalog
tn Setswana
to Tonga
tr Turkish
ts Tsonga
tt Tatar
tw Twi
<!-- [if !supportEmptyParas]--><!-- [endif]-->
ug Uighur
uk Ukrainian
ur Urdu
uz Uzbek
<!-- [if !supportEmptyParas]--><!-- [endif]-->
vi Vietnamese
vo Volapuk
<!-- [if !supportEmptyParas]--><!-- [endif]-->
wo Wolof
<!-- [if !supportEmptyParas]--><!-- [endif]-->
xh Xhosa
<!-- [if !supportEmptyParas]--><!-- [endif]-->
yi Yiddish (formerly ji)
yo Yoruba
<!-- [if !supportEmptyParas]--><!-- [endif]-->
za Zhuang
zh Chinese
zu Zulu
<!-- [if !supportEmptyParas]--><!-- [endif]-->
<!-- EndFragment-->