武汉竟升公司 WebSphere Portal 内容管理升级实施方案
2012-03-09 00:00
295 查看
1 客户环境
4
2 升级步骤
4
3 准备工作
5
3.1 WPS5机器
5
3.1.1 验证数据库连接是否正确
5
3.1.2 准备迁移工具的 Fix
5
3.2 WPS6机器
6
3.2.1 安装 Portal6.0.1.3+WCM
6
3.2.2 迁移数据库 +启用安全性
6
3.2.3 获取相关管理员账号
7
3.2.4 修改 HTTP Server 的超时时间
7
3.2.5 收集 WPS5必要的文件，便于从 WPS6访问 WPS5
7
3.2.6 确认所有已经发布的 Portlet在 WPS5 的 PortalServer/installableApps当中有 WAR包
8
3.2.7 重新创建虚拟门户
9
3.2.8 调整迁移的性能
9
4 迁移客户化资源
10
5 迁移门户配置
11
5.1 在 WPS6使用命令行方式迁移
11
5.2 从 WPS5导出门户数据
11
5.3 从 WPS5导出虚拟门户数据
12
5.4 导入门户数据到 WPS6
12
5.5 导入虚拟门户数据
13
5.6 迁移 FileServlet Portlet(可选 )
13
5.7 重起 WPS6
13
6 迁移权限相关数据
14
7 迁移 WCM数据
16
7.1 安装迁移工具 (Web content migration tool)
16
7.2 清理 WPS5的 WCM的错误数据
17
7.2.1 Reference checker
17
7.2.2 Site checker
17
7.2.3 Resource checker
17
7.2.4 Member fixer
17
7.2.5 确定没有加密的 Excel,WORD， PPT等文件
18
7.3 WCM内容迁移
18
7.4 迁移 user profiles
22
7.5 迁移 local rendering portlet
23
7.6 迁移 remote rendering portlet
24
7.7 WCM迁移成功后修改工作
25
7.7.1 Web content configuration files
25
7.7.2 Anchor tags and URLs
26
7.7.3 Links to Web Content Management content from external sites
26
7.7.4 Siblings with the same name
27
7.7.5 Draft items
27
7.7.6 Navigator elements
27
7.7.7 Menu elements
28
7.7.8 Name and title fields
28
7.7.9 Connect tags
28
7.7.10 Web Content Management search
28
7.7.11 Moving objects to new libraries
28
7.7.12 API code
29
7.7.13 JSP files
29
7.7.14 Authoring portlet access changes
29
7.7.15 Referential integrity
29
7.7.16 Authoring portlet pages
29
7.7.17 Presentation templates
30
7.7.18 Removing the migration tool
30
8 迁移后验证任务
30
8.1 Verify Notes and Domino Web Access (iNotes) portlets migration
30
8.2 Verify migration of portal clients
31
8.3 Verify migration of user customizations
31
8.4 Verify migration of credential vault segments and slots
31
8.5 Verify migration of themes and skins
32
8.6 Verify migration of portlet applications
32
8.7 Verify migration of portlet configuration data
32
8.8 Verify migration of virtual resources
33
8.9 Verify migration of pages
33
源环境： WPS5
平台： windows
门户： WebSphere Portal Server enable 5.1.0.2+WCM (WCM 发布的服务器，最好是从发布服务器迁移 )
数据库： Oracle 9i
目标环境： WPS6
平台： windows
门户： WebSphere Portal Server Enable 6.0.1.3 +WCM+WAS6.0.2.23
数据库： Oracle 9i
WPS1 10.195.88.221 10.195.88.201
WPS2 10.195.88.220
LDAP 10.195.88.221
补丁：
6.0.1-WP-FP003
6.0.1.3-WP-Multi-IFPK59655
6.0.1.3-WP-Multi-IFPK61633
6.0.2-WS-WAS-WinX32-FP00000023
6.0.2-WS-WASJavaSDK-WinX32-FP00000023
查看 wpconfig.properties 配置是否正确，测试是否正常连接数据库。
PortalServer/Config 目录下执行命令 :
WPSConfig.bat validate-database-connection-wps
a.
Create an update directory in your previous WebSphere Portal directory; for example, C:/Program Files/WebSphere/PortalServer/update .
b.
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.
c.
Unzip the interim fixes from the appropriate directory of the current WebSphere Portal directory to the update directory created in the previous step:
§
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:
§
PK14100
§
PK14103
§
PK15013
§
PK19790
§
PK20467
§
PK16371
§
PK16597
§
PK18538
§
PK21688
§
PK17690
§
PK21136
§
PK22244
§
PK23901
§
PK11536
§
PK40171 – Apply this fix using the WebSphere Portal database check and update tool wpdbupdate
d.
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
e.
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
要备份。包括目录备份 + 数据库备份。
LDAP 目录最好是同一个或者数据是一样， LDAP 版本也一致，或者数据应该一致，否则 WCM 数据当中做用户检测部分可能存在问题。
WPS5 的管理员账号和密码： WAS 和 PORTAL
WPS6 的管理员账号和密码： WAS 和 PORTAL
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.
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:
o
If you are using a Cloudscape database
o
If there is a port conflict or resource conflict when you start the current portal server
o
If you modified the number of groups
d.
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.
§
Windows and UNIX: WPSconfig.{sh|bat} prop-collector -DDbPassword=wpsdb_password
§
i5/OS: Choose one of the following commands based on the version of WebSphere Application Server that you are using:
§
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.
§
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.
§
Important: The following information applies to running the above command:
§
-DDbPassword=wpsdb_password is not required if the value is already defined in the wpconfig.properties file.
§
Ensure that the values for DbUrl and DbName are defined in the wpconfig.properties file.
§
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".
e.
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.
f.
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
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.
Required performance tuning for exporting and importing large groups and resources
a.
Check your LDAP server to determine the number of groups and perform the appropriate steps if the number is greater than 200:
§
Perform the following steps on the previous version of WebSphere Portal if migrating from version 5.1.x:
i.
Change to the wp_old_root/wmm directory of the 5.1.x directory.
ii.
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.
iii.
Save your changes.
iv.
If this is a clustered environment, change to the was_old_root/config/wmm directory of the 5.1.x system.
v.
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.
vi.
Save your changes.
vii.
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.
viii.
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.
ix.
Save your changes.
§
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:
i.
Change to the portal_server_root /wmm directory of the current version.
ii.
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.
iii.
Save your changes.
b.
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:
§
Search size limit: Unlimited
§
Search time limit: Unlimited
§
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).
主题和皮肤：
WPS5的皮肤和主题和WPS6有些不一样，在WPS6的基础上新建一个主题，把相关的资源替换（css or Images）。
其他：
如果客户部署了协作的Portlet、Structs Framework的portlet、业务流程的Portlet或者Portal搜索数据，请参考Inforcenter的章节:
l
Migrating cooperative portlets that use IBM Portlet API
l
Migrating portlets built with Struts Portlet Framework
l
Migrating business process applications
l
Migrating Portal Search between portal versions
命令在 portal_server_root /migration 目录
Windows: WPmigrate.bat
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:
1.
Stop the current WebSphere Portal server. ( 停止 WPS6)
2.
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:
Windows: WPmigrate.bat export-portal-content -DPrevPortalAdminId=portaladminid -DPrevPortalAdminPwd=password
PrevPortalAdminId indicates a portaladminid from the previous version of WebSphere Portal
PrevPortalAdminPwd indicates the password for the above portaladminid
如果没有虚拟门户，跳过这一步。
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:
1.
Stop the current WebSphere Portal server ( 停止 WPS6).
2.
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:
Windows: WPmigrate.bat export-portal-content -DPrevPortalAdminId=portaladminid -DPrevPortalAdminPwd=password -DVirtualPortal=URL context
where:
PrevPortalAdminId indicates a portaladminid from the previous version of WebSphere Portal
PrevPortalAdminPwd indicates the password for the above portaladminid
URL context is the context extension for the virtual portal URL; see the URL Context description row in the Virtual Portal Manager portlet
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:
1.
Stop the previous WebSphere Portal server. ( 停止 WPS5)
2.
Start the server for your current version of WebSphere Portal and ensure it is accessible to the network. ( 启动 WPS6)
3.
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:
Windows: WPmigrate.bat import-portal-content -DPortalAdminId= portaladminid -DPortalAdminPwd= password
where:
PortalAdminId indicates a portaladminid from the current version of WebSphere Portal
PortalAdminPwd indicates the password from the above portaladminid
Note : If running the import-portal-content task multiple times, you must Restart the servers before rerunning the task.
如果没有虚拟门户，跳过这一步。
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:
1.
Stop the previous WebSphere Portal server. ( 停止 WPS5)
2.
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:
Windows: WPmigrate.bat import-portal-content -DPortalAdminId= portaladminid -DPortalAdminPwd= password -DVirtualPortal= URL context
where:
PortalAdminId indicates a portaladminid from the current version of WebSphere Portal
PortalAdminPwd indicates the password from the above portaladminid
URL context is the context extension for the virtual portal URL; see the URL Context description row in the Virtual Portal Manager portlet
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.
After completing the import-portal-content task, restart the following server on the current version only:
1.
Open a command prompt and change to the following directory:
o
Windows: was_profile_root /bin
2.
Enter the following command:
o
Windows : stopServer.bat WebSphere_Portal -user admin_userid -password admin_password
3.
Enter the following command:
o
Windows: startServer.bat WebSphere_Portal
虽然前面成功的迁移了门户配置数据，但是有些权限配置相关数据，是没有迁移的，例如：凭证保险库相关数据，资源许可权的数据等等。
1.
Migrating permissions on All Authenticated Portal Users and All Portal User Groups group
Permissions on User Groups allows principals to perform the following tasks:
o
Edit group information
o
Change group membership
o
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:
i.
Log in to portal using an administrator account.
ii.
Open the Resource permissions portlet.
iii.
Select the Resource type User Groups.
iv.
Select the All Authenticated Portal Users option and analyze the existing role assignments on that user group.
v.
Use the Resource permissions portlet to create the same role assignments on the new portal.
vi.
Repeat these steps for All Portal User Groups .
2.
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.
3.
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:
o
WebSphere Portal Default Vault: complete the following procedure if you want to migrate existing credential secrets to the current WebSphere Portal system.
o
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 ）
Run the WPSconfig. {sh | bat} configure-wcm-migration task from the portal_server_root /config directory of your new system.
Windows: WPSconfig.bat configure-wcm-migration -DWasUserId=username -DWasPassword=password
The user specified in the command must be a WebSphere Application Server administrator.
To view a report:
To correct reference errors, use the following URL:
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
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
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
有加密的 excel/word/ppt 在 WCM 作为附件，会迁移失败，应该在迁移之前去掉保护。
1.
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.
2.
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:
o
Oracle Enterprise Edition : ojdbc14.jar
3.
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.
4.
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:
o
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.
o
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.
5.
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:
o
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.
o
connect.cfg : Ensure <jdbc:db2j:<path_to_database> driver="com.ibm.db2j.jdbc.DB2jDriver" />
6.
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:
o
export.path : The path on the local file system where exported data will be saved.
o
import.path : The directory on the local file system where transformed data is saved.
o
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.
o
legacy.config.path : The path on the local file system where the old Web Content Management configuration is located. See step 1.
o
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.
o
import.library.name : The name of the library created during import.
o
import.library.locale : zh
7.
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.
8.
Restart the portal application server.
9.
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.
o
Windows: wcmmigrate.bat -user username -password password all-data
The user specified in the command must be a WebSphere Portal administrator.
Notes:
10.
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.
11.
Restore the total transaction lifetime timeout setting to the original setting that was changed in step 7.
12.
Restart the portal application server.
13.
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.
14.
Syndicate the migrated data to all the other servers in your new Web content system. See Syndication for further information.
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.
1.
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.
2.
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:
o
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.
3.
If your LDAP server contains more than 200 users, you must perform the following steps. Otherwise, proceed to step 4.
a.
Stop your WebSphere Portal server.
b.
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 .
c.
Edit portal_server_root /wmm/wmm.xml and change the following settings:
§
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.
§
Change searchTimeOut to 2,000,000.
4.
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.
5.
Restart the portal application server.
6.
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.
o
Windows: wcmmigrate.bat -user username -password password users
The user specified in the command must be a WebSphere Portal administrator.
7.
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.
8.
Restore the total transaction lifetime timeout setting to the original setting that was changed in step 4.
9.
If you performed step 3, you must do the following:
.
Stop your WebSphere Portal server.
a.
Restore the wmm.xml.bak file you created in step 3.b to portal_server_root /wmm/wmm.xml .
10.
Restart the portal application server.
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.
1.
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.
2.
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:
o
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.
o
virtual.portal : If migrating a local rendering portlet located on a virtual portal, you must enter the name of the virtual portal.
3.
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.
o
Windows: wcmmigrate.bat -user username -password password configure-local
The user specified in the command must be a WebSphere Portal administrator.
4.
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.
5.
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.
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.
1.
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.
2.
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:
o
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.
o
virtual.portal : If migrating a remote rendering portlet located on a virtual portal, you must enter the name of the virtual portal.
3.
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:
o
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,
Note: If all your old remote rendering portlets use data from a single system you can specify remote.host.base.path.list=all .
o
WCM_REMOTE_HOST_BASE_PATH : Enter the remote host base path of the server the remote rendering portlet is being migrated to. For example,
4.
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.
o
Windows: wcmmigrate.bat -user username -password password configure-remote
The user specified in the command must be a WebSphere Portal administrator.
5.
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.
6.
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.
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:
Windows: portal_server_root /wcm/shared/app/config/wcmservices
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:
Old URL:
New URL:
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:
transformed_contents.links
transformed_library_components.links
transformed_content_components.links
transformed_presentation_templates.links
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:
transformed_contents.links
transformed_library_components.links
transformed_content_components.links
transformed_presentation_templates.links
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:
MySite
MySiteArea
MySiteArea
During migration, the second site area will be renamed as "MySiteArea_1". The site framework will now look like this:
MySite
MySiteArea
MySiteArea_1
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.
Windows: WPSconfig.bat remove-wcm-migration
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:
1.
Verify Notes and Domino Web Access (iNotes™) portlets migration
2.
Verify migration of portal clients
3.
Verify migration of user customizations
4.
Verify migration of credential vault data
5.
Verify migration of themes and skins
6.
Verify migration of portlet applications
7.
Verify migration of portlet configuration data
8.
Verify migration of virtual resources
9.
Verify migration of pages
a.
Log in to the current WebSphere Portal Administrative Interface.
b.
Click Portlet Management > Portlets .
c.
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.
d.
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.
e.
Log in to the current WebSphere Portal Administrative Interface.
f.
Click Administration > Portal Settings > Supported Clients .
g.
Verify that the portal clients that you migrated show up in the list of supported clients.
h.
Select the clients that were migrated and click Edit Selected Client to verify that all settings for the client were migrated.
i.
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.
j.
Log in to the current WebSphere Portal with credentials of users having the customizations.
k.
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.
l.
Log in to the current WebSphere Portal Administrative Interface.
m.
Click Access and then click Credential Vault on the left navigation.
n.
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.
o.
Log in to the current WebSphere Portal Administrative Interface.
p.
Click Portal user interface > Themes and Skins in the left navigation.
q.
Verify that the themes and skins that are listed are the ones that you migrated from the previous version to the current version.
r.
Verify that you are able to associate migrated themes and skins to existing pages and portlets, and verify that they produce the required view.
s.
Log in to the current WebSphere Portal Administrative Interface.
t.
Click Portlet Management > Applications on the left navigation.
u.
Verify that the portlet applications that are listed are the ones that you migrated from the previous version.
v.
For each Web Module, verify that all your portlet applications also display in the Portlet Applications list.
w.
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.
x.
Click Access > Resource Permissions and select Portlet Applications from Resource Types .
y.
Click Assign Access to verify the access control information.
z.
Click Access > Resource Permissions and select Portlets from Resource Types .
aa.
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.
bb.
Log in to the current WebSphere Portal Administrative Interface.
cc.
Click Portlet Management > Portlets on the left navigation.
dd.
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 .
ee.
Log in to the current WebSphere Portal Administrative Interface.
ff.
Click Access > Resource Permissions on the left navigation.
gg.
Select Virtual Resources from Resource Types .
hh.
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.
附件：
Technical contents of ISO 639:1988 (E/F)
"Code for the representation of names of languages".
Typed by Keld.Simonsen@dkuug.dk 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
Two-letter lower-case symbols are used.
The Registration Authority for ISO 639 is Infoterm, Osterreichisches
Normungsinstitut (ON), Postfach 130, A-1021 Vienna, Austria.
aa Afar
ab Abkhazian
af Afrikaans
am Amharic
ar Arabic
as Assamese
ay Aymara
az Azerbaijani
ba Bashkir
be Byelorussian
bg Bulgarian
bh Bihari
bi Bislama
bn Bengali; Bangla
bo Tibetan
br Breton
ca Catalan
co Corsican
cs Czech
cy Welsh
da Danish
de German
dz Bhutani
el Greek
en English
eo Esperanto
es Spanish
et Estonian
eu Basque
fa Persian
fi Finnish
fj Fiji
fo Faroese
fr French
fy Frisian
ga Irish
gd Scots Gaelic
gl Galician
gn Guarani
gu Gujarati
ha Hausa
he Hebrew (formerly iw)
hi Hindi
hr Croatian
hu Hungarian
hy Armenian
ia Interlingua
id Indonesian (formerly in)
ie Interlingue
ik Inupiak
is Icelandic
it Italian
iu Inuktitut
ja Japanese
jw Javanese
ka Georgian
kk Kazakh
kl Greenlandic
km Cambodian
kn Kannada
ko Korean
ks Kashmiri
ku Kurdish
ky Kirghiz
la Latin
ln Lingala
lo Laothian
lt Lithuanian
lv Latvian, Lettish
mg Malagasy
mi Maori
mk Macedonian
ml Malayalam
mn Mongolian
mo Moldavian
mr Marathi
ms Malay
mt Maltese
my Burmese
na Nauru
ne Nepali
nl Dutch
no Norwegian
oc Occitan
om (Afan) Oromo
or Oriya
pa Punjabi
pl Polish
ps Pashto, Pushto
pt Portuguese
qu Quechua
rm Rhaeto-Romance
rn Kirundi
ro Romanian
ru Russian
rw Kinyarwanda
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
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
ug Uighur
uk Ukrainian
ur Urdu
uz Uzbek
vi Vietnamese
vo Volapuk
wo Wolof
xh Xhosa
yi Yiddish (formerly ji)
yo Yoruba
za Zhuang
zh Chinese
zu Zulu
$(document).ready(function(){dp.SyntaxHighlighter.HighlightAll('code');});
原文链接：
http://blog.csdn.net/jaminwm/article/details/4561467
4
2 升级步骤
4
3 准备工作
5
3.1 WPS5机器
5
3.1.1 验证数据库连接是否正确
5
3.1.2 准备迁移工具的 Fix
5
3.2 WPS6机器
6
3.2.1 安装 Portal6.0.1.3+WCM
6
3.2.2 迁移数据库 +启用安全性
6
3.2.3 获取相关管理员账号
7
3.2.4 修改 HTTP Server 的超时时间
7
3.2.5 收集 WPS5必要的文件，便于从 WPS6访问 WPS5
7
3.2.6 确认所有已经发布的 Portlet在 WPS5 的 PortalServer/installableApps当中有 WAR包
8
3.2.7 重新创建虚拟门户
9
3.2.8 调整迁移的性能
9
4 迁移客户化资源
10
5 迁移门户配置
11
5.1 在 WPS6使用命令行方式迁移
11
5.2 从 WPS5导出门户数据
11
5.3 从 WPS5导出虚拟门户数据
12
5.4 导入门户数据到 WPS6
12
5.5 导入虚拟门户数据
13
5.6 迁移 FileServlet Portlet(可选 )
13
5.7 重起 WPS6
13
6 迁移权限相关数据
14
7 迁移 WCM数据
16
7.1 安装迁移工具 (Web content migration tool)
16
7.2 清理 WPS5的 WCM的错误数据
17
7.2.1 Reference checker
17
7.2.2 Site checker
17
7.2.3 Resource checker
17
7.2.4 Member fixer
17
7.2.5 确定没有加密的 Excel,WORD， PPT等文件
18
7.3 WCM内容迁移
18
7.4 迁移 user profiles
22
7.5 迁移 local rendering portlet
23
7.6 迁移 remote rendering portlet
24
7.7 WCM迁移成功后修改工作
25
7.7.1 Web content configuration files
25
7.7.2 Anchor tags and URLs
26
7.7.3 Links to Web Content Management content from external sites
26
7.7.4 Siblings with the same name
27
7.7.5 Draft items
27
7.7.6 Navigator elements
27
7.7.7 Menu elements
28
7.7.8 Name and title fields
28
7.7.9 Connect tags
28
7.7.10 Web Content Management search
28
7.7.11 Moving objects to new libraries
28
7.7.12 API code
29
7.7.13 JSP files
29
7.7.14 Authoring portlet access changes
29
7.7.15 Referential integrity
29
7.7.16 Authoring portlet pages
29
7.7.17 Presentation templates
30
7.7.18 Removing the migration tool
30
8 迁移后验证任务
30
8.1 Verify Notes and Domino Web Access (iNotes) portlets migration
30
8.2 Verify migration of portal clients
31
8.3 Verify migration of user customizations
31
8.4 Verify migration of credential vault segments and slots
31
8.5 Verify migration of themes and skins
32
8.6 Verify migration of portlet applications
32
8.7 Verify migration of portlet configuration data
32
8.8 Verify migration of virtual resources
33
8.9 Verify migration of pages
33
1
客户环境
源环境： WPS5平台： windows
门户： WebSphere Portal Server enable 5.1.0.2+WCM (WCM 发布的服务器，最好是从发布服务器迁移 )
数据库： Oracle 9i
目标环境： WPS6
平台： windows
门户： WebSphere Portal Server Enable 6.0.1.3 +WCM+WAS6.0.2.23
数据库： Oracle 9i
WPS1 10.195.88.221 10.195.88.201
WPS2 10.195.88.220
LDAP 10.195.88.221
补丁：
6.0.1-WP-FP003
6.0.1.3-WP-Multi-IFPK59655
6.0.1.3-WP-Multi-IFPK61633
6.0.2-WS-WAS-WinX32-FP00000023
6.0.2-WS-WASJavaSDK-WinX32-FP00000023
2
升级步骤
| 任务 | 列表 | 天数 |
| 环境准备 | WPS5 准备（客户提供） | 1 |
| WPS6 准备（现场安装） + 启用安全性 + 数据库迁移 +Fixpack | ||
| 迁移前门户系统配置修改 | ||
| WCM 数据清理 | ||
| 迁移门户数据 | 迁移客户化资源 ( 主题、皮肤等 ) | 1 |
| 迁移门户配置 | ||
| 迁移权限数据 | ||
| 迁移 WCM | WCM 内容迁移 | 1.5 |
| User Profile 迁移 | ||
| Local Rendering Portlet 迁移 | ||
| Remote Rendering Portlet 迁移 | ||
| 验证迁移 | 验证迁移的数据 | 0.5 |
3
准备工作
3.1
WPS5 机器
3.1.1
验证数据库连接是否正确
查看 wpconfig.properties 配置是否正确，测试是否正常连接数据库。PortalServer/Config 目录下执行命令 :
WPSConfig.bat validate-database-connection-wps
3.1.2
准备迁移工具的 Fix
a.Create an update directory in your previous WebSphere Portal directory; for example, C:/Program Files/WebSphere/PortalServer/update .
b.
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.
c.
Unzip the interim fixes from the appropriate directory of the current WebSphere Portal directory to the update directory created in the previous step:
§
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:
§
PK14100
§
PK14103
§
PK15013
§
PK19790
§
PK20467
§
PK16371
§
PK16597
§
PK18538
§
PK21688
§
PK17690
§
PK21136
§
PK22244
§
PK23901
§
PK11536
§
PK40171 – Apply this fix using the WebSphere Portal database check and update tool wpdbupdate
d.
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
e.
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
3.2
WPS6 机器
3.2.1
安装 Portal6.0.1.3+WCM
要备份。包括目录备份 + 数据库备份。
3.2.2
迁移数据库 + 启用安全性
LDAP 目录最好是同一个或者数据是一样， LDAP 版本也一致，或者数据应该一致，否则 WCM 数据当中做用户检测部分可能存在问题。
3.2.3
获取相关管理员账号
WPS5 的管理员账号和密码： WAS 和 PORTALWPS6 的管理员账号和密码： WAS 和 PORTAL
3.2.4
修改 HTTP Server 的超时时间
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.
3.2.5
收集 WPS5 必要的文件，便于从 WPS6 访问 WPS5
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:
o
If you are using a Cloudscape database
o
If there is a port conflict or resource conflict when you start the current portal server
o
If you modified the number of groups
d.
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.
§
Windows and UNIX: WPSconfig.{sh|bat} prop-collector -DDbPassword=wpsdb_password
§
i5/OS: Choose one of the following commands based on the version of WebSphere Application Server that you are using:
§
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.
§
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.
§
Important: The following information applies to running the above command:
§
-DDbPassword=wpsdb_password is not required if the value is already defined in the wpconfig.properties file.
§
Ensure that the values for DbUrl and DbName are defined in the wpconfig.properties file.
§
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".
e.
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.
f.
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
3.2.6
确认所有已经发布的 Portlet 在 WPS5
的 PortalServer/installableApps 当中有 WAR 包
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.
3.2.7
重新创建虚拟门户
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.
3.2.8
调整迁移的性能
Required performance tuning for exporting and importing large groups and resources a.
Check your LDAP server to determine the number of groups and perform the appropriate steps if the number is greater than 200:
§
Perform the following steps on the previous version of WebSphere Portal if migrating from version 5.1.x:
i.
Change to the wp_old_root/wmm directory of the 5.1.x directory.
ii.
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.
iii.
Save your changes.
iv.
If this is a clustered environment, change to the was_old_root/config/wmm directory of the 5.1.x system.
v.
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.
vi.
Save your changes.
vii.
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.
viii.
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.
ix.
Save your changes.
§
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:
i.
Change to the portal_server_root /wmm directory of the current version.
ii.
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.
iii.
Save your changes.
b.
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:
§
Search size limit: Unlimited
§
Search time limit: Unlimited
§
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).
4
迁移客户化资源
主题和皮肤：WPS5的皮肤和主题和WPS6有些不一样，在WPS6的基础上新建一个主题，把相关的资源替换（css or Images）。
其他：
如果客户部署了协作的Portlet、Structs Framework的portlet、业务流程的Portlet或者Portal搜索数据，请参考Inforcenter的章节:
l
Migrating cooperative portlets that use IBM Portlet API
l
Migrating portlets built with Struts Portlet Framework
l
Migrating business process applications
l
Migrating Portal Search between portal versions
5
迁移门户配置
5.1
在 WPS6 使用命令行方式迁移
命令在 portal_server_root /migration 目录Windows: WPmigrate.bat
5.2
从 WPS5 导出门户数据
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:
1.
Stop the current WebSphere Portal server. ( 停止 WPS6)
2.
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:
Windows: WPmigrate.bat export-portal-content -DPrevPortalAdminId=portaladminid -DPrevPortalAdminPwd=password
PrevPortalAdminId indicates a portaladminid from the previous version of WebSphere Portal
PrevPortalAdminPwd indicates the password for the above portaladminid
5.3
从 WPS5 导出虚拟门户数据
如果没有虚拟门户，跳过这一步。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:
1.
Stop the current WebSphere Portal server ( 停止 WPS6).
2.
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:
Windows: WPmigrate.bat export-portal-content -DPrevPortalAdminId=portaladminid -DPrevPortalAdminPwd=password -DVirtualPortal=URL context
where:
PrevPortalAdminId indicates a portaladminid from the previous version of WebSphere Portal
PrevPortalAdminPwd indicates the password for the above portaladminid
URL context is the context extension for the virtual portal URL; see the URL Context description row in the Virtual Portal Manager portlet
5.4
导入门户数据到 WPS6
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:
1.
Stop the previous WebSphere Portal server. ( 停止 WPS5)
2.
Start the server for your current version of WebSphere Portal and ensure it is accessible to the network. ( 启动 WPS6)
3.
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:
Windows: WPmigrate.bat import-portal-content -DPortalAdminId= portaladminid -DPortalAdminPwd= password
where:
PortalAdminId indicates a portaladminid from the current version of WebSphere Portal
PortalAdminPwd indicates the password from the above portaladminid
Note : If running the import-portal-content task multiple times, you must Restart the servers before rerunning the task.
5.5
导入虚拟门户数据
如果没有虚拟门户，跳过这一步。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:
1.
Stop the previous WebSphere Portal server. ( 停止 WPS5)
2.
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:
Windows: WPmigrate.bat import-portal-content -DPortalAdminId= portaladminid -DPortalAdminPwd= password -DVirtualPortal= URL context
where:
PortalAdminId indicates a portaladminid from the current version of WebSphere Portal
PortalAdminPwd indicates the password from the above portaladminid
URL context is the context extension for the virtual portal URL; see the URL Context description row in the Virtual Portal Manager portlet
Note: If running the import-portal-content task multiple times, you must Restart the servers before rerunning the task.
5.6
迁移 FileServlet Portlet( 可选 )
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.
5.7
重起 WPS6
After completing the import-portal-content task, restart the following server on the current version only:1.
Open a command prompt and change to the following directory:
o
Windows: was_profile_root /bin
2.
Enter the following command:
o
Windows : stopServer.bat WebSphere_Portal -user admin_userid -password admin_password
3.
Enter the following command:
o
Windows: startServer.bat WebSphere_Portal
6
迁移权限相关数据
虽然前面成功的迁移了门户配置数据，但是有些权限配置相关数据，是没有迁移的，例如：凭证保险库相关数据，资源许可权的数据等等。1.
Migrating permissions on All Authenticated Portal Users and All Portal User Groups group
Permissions on User Groups allows principals to perform the following tasks:
o
Edit group information
o
Change group membership
o
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:
i.
Log in to portal using an administrator account.
ii.
Open the Resource permissions portlet.
iii.
Select the Resource type User Groups.
iv.
Select the All Authenticated Portal Users option and analyze the existing role assignments on that user group.
v.
Use the Resource permissions portlet to create the same role assignments on the new portal.
vi.
Repeat these steps for All Portal User Groups .
2.
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 o Manage Pages o Themes and Skins | Manage Pages Themes and Skins |
| Portlet Management o Web Modules o Applications o Portlets o Web Services o Web Clipping | Manage Web Modules Manage Applications Manage Portlets Web Service Configuration Web Clipping Editor |
| Access o Users and Groups o Resource Permissions o User and Group Permissions o Credential Vault | Manage Users and Groups Resource Permissions User and Group Permissions Credential Vault |
| Portal Settings o Global Settings o URL Mapping o Custom Unique Names o Supported Markups o Supported Clients o Search Administration o Import XML | Global Settings URL Mapping portlet Manage Custom Unique Names Manage Markups Manage Clients Manage Search Collection Import XML |
| Portal Analysis o Frequent Users o Enable Tracing | Frequent Users Enable Tracing |
| Portal Content o Manage Document Libraries | Manage Document Libraries |
| Virtual Portals o Manage Virtual Portals | Virtual Portal Manager |
| Page Customizer o Content Layout o Appearance o Locks o 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 |
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:
o
WebSphere Portal Default Vault: complete the following procedure if you want to migrate existing credential secrets to the current WebSphere Portal system.
o
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 ）
7
迁移 WCM 数据
7.1
安装迁移工具 (Web content migration tool)
Run the WPSconfig. {sh | bat} configure-wcm-migration task from the portal_server_root /config directory of your new system.Windows: WPSconfig.bat configure-wcm-migration -DWasUserId=username -DWasPassword=password
The user specified in the command must be a WebSphere Application Server administrator.
7.2
清理 WPS5 的 WCM 的错误数据
7.2.1
Reference checker
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
7.2.2
Site checker
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
7.2.3
Resource checker
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
7.2.4
Member fixer
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
7.2.5
确定没有加密的 Excel,WORD ， PPT 等文件
有加密的 excel/word/ppt 在 WCM 作为附件，会迁移失败，应该在迁移之前去掉保护。
7.3
WCM 内容迁移
1.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.
2.
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:
o
Oracle Enterprise Edition : ojdbc14.jar
3.
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.
4.
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:
o
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.
o
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.
5.
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:
o
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.
o
connect.cfg : Ensure <jdbc:db2j:<path_to_database> driver="com.ibm.db2j.jdbc.DB2jDriver" />
6.
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:
o
export.path : The path on the local file system where exported data will be saved.
o
import.path : The directory on the local file system where transformed data is saved.
o
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.
o
legacy.config.path : The path on the local file system where the old Web Content Management configuration is located. See step 1.
o
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.
o
import.library.name : The name of the library created during import.
o
import.library.locale : zh
7.
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.
8.
Restart the portal application server.
9.
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.
o
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: Review any error messages displayed during the migration. Review the migration log files located under the portal_server_root /wcm/migration/log folder. Make sure you have copied the correct files and directories as described in the primary and secondary migration tasks. Review the settings in the portal_server_root /wcm/migration/config/migration.properties file. Running individual wcmmigrate all-data commands 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.
Windows: wcmmigrate.bat -user username -password password validate 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. Windows: wcmmigrate.bat -user username -password password all-data -restart UNIX: ./wcmmigrate.sh -user username -password password all-data -restart i5/OS: wcmmigrate.sh -user username -password password all-data -restart 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. Windows: wcmmigrate.bat -user username -password password all-data -resume UNIX: ./wcmmigrate.sh -user username -password password all-data -resume i5/OS: wcmmigrate.sh -user username -password password all-data -resume 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". |
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.
11.
Restore the total transaction lifetime timeout setting to the original setting that was changed in step 7.
12.
Restart the portal application server.
13.
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.
14.
Syndicate the migrated data to all the other servers in your new Web content system. See Syndication for further information.
7.4
迁移 user profiles
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.
1.
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.
2.
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:
o
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.
3.
If your LDAP server contains more than 200 users, you must perform the following steps. Otherwise, proceed to step 4.
a.
Stop your WebSphere Portal server.
b.
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 .
c.
Edit portal_server_root /wmm/wmm.xml and change the following settings:
§
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.
§
Change searchTimeOut to 2,000,000.
4.
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.
5.
Restart the portal application server.
6.
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.
o
Windows: wcmmigrate.bat -user username -password password users
The user specified in the command must be a WebSphere Portal administrator.
7.
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.
8.
Restore the total transaction lifetime timeout setting to the original setting that was changed in step 4.
9.
If you performed step 3, you must do the following:
.
Stop your WebSphere Portal server.
a.
Restore the wmm.xml.bak file you created in step 3.b to portal_server_root /wmm/wmm.xml .
10.
Restart the portal application server.
7.5
迁移 local rendering portlet
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.
1.
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.
2.
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:
o
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.
o
virtual.portal : If migrating a local rendering portlet located on a virtual portal, you must enter the name of the virtual portal.
3.
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.
o
Windows: wcmmigrate.bat -user username -password password configure-local
The user specified in the command must be a WebSphere Portal administrator.
4.
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.
5.
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.
7.6
迁移 remote rendering portlet
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.
1.
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.
2.
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:
o
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.
o
virtual.portal : If migrating a remote rendering portlet located on a virtual portal, you must enter the name of the virtual portal.
3.
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:
o
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,
o 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 .
o
WCM_REMOTE_HOST_BASE_PATH : Enter the remote host base path of the server the remote rendering portlet is being migrated to. For example,
o WCM_REMOTE_HOST_BASE_PATH=http://newhostname:9081
4.
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.
o
Windows: wcmmigrate.bat -user username -password password configure-remote
The user specified in the command must be a WebSphere Portal administrator.
5.
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.
6.
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.
7.7
WCM 迁移成功后修改工作
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.
7.7.1
Web content configuration files
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:
Windows: portal_server_root /wcm/shared/app/config/wcmservices
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:
Old URL:
connect.connector.sqlconnector.databases.jdbc:microsoft:sqlserver://host:port;DatabaseName=dbname
New URL:
connect.connector.sqlconnector.databases.jdbc/:microsoft/:sqlserver/://host/:port;DatabaseName/=dbname
7.7.2
Anchor tags and URLs
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:
transformed_contents.links
transformed_library_components.links
transformed_content_components.links
transformed_presentation_templates.links
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.
7.7.3
Links to Web Content Management content from external sites
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:
transformed_contents.links
transformed_library_components.links
transformed_content_components.links
transformed_presentation_templates.links
These files list the old and new names and paths of content items, components (library components), elements (content components) and presentation templates.
7.7.4
Siblings with the same name
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:
MySite
MySiteArea
MySiteArea
During migration, the second site area will be renamed as "MySiteArea_1". The site framework will now look like this:
MySite
MySiteArea
MySiteArea_1
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.
7.7.5
Draft 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.
7.7.6
Navigator elements
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.
7.7.7
Menu elements
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.
7.7.8
Name and title fields
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.
7.7.9
Connect tags
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.
7.7.10
Web Content Management search
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.
7.7.11
Moving objects to new libraries
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.
7.7.12
API code
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.
7.7.13
JSP files
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.
7.7.14
Authoring portlet access changes
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.
7.7.15
Referential integrity
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.
7.7.16
Authoring portlet pages
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.
7.7.17
Presentation templates
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.
7.7.18
Removing the migration tool
To remove the migration tool, run the remove-wcm-migration task from the portal_server_root /config directory of your new system.Windows: WPSconfig.bat remove-wcm-migration
8
迁移后验证任务
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:
1.
Verify Notes and Domino Web Access (iNotes™) portlets migration
2.
Verify migration of portal clients
3.
Verify migration of user customizations
4.
Verify migration of credential vault data
5.
Verify migration of themes and skins
6.
Verify migration of portlet applications
7.
Verify migration of portlet configuration data
8.
Verify migration of virtual resources
9.
Verify migration of pages
8.1
Verify Notes and Domino Web Access (iNotes) portlets migration
a.Log in to the current WebSphere Portal Administrative Interface.
b.
Click Portlet Management > Portlets .
c.
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.
d.
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.
8.2
Verify migration of portal clients
e.Log in to the current WebSphere Portal Administrative Interface.
f.
Click Administration > Portal Settings > Supported Clients .
g.
Verify that the portal clients that you migrated show up in the list of supported clients.
h.
Select the clients that were migrated and click Edit Selected Client to verify that all settings for the client were migrated.
i.
Verify that your migrated clients are able to access WebSphere Portal.
8.3
Verify migration of user customizations
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.j.
Log in to the current WebSphere Portal with credentials of users having the customizations.
k.
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.
8.4
Verify migration of credential vault segments and slots
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.l.
Log in to the current WebSphere Portal Administrative Interface.
m.
Click Access and then click Credential Vault on the left navigation.
n.
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.
8.5
Verify migration of themes and skins
o.Log in to the current WebSphere Portal Administrative Interface.
p.
Click Portal user interface > Themes and Skins in the left navigation.
q.
Verify that the themes and skins that are listed are the ones that you migrated from the previous version to the current version.
r.
Verify that you are able to associate migrated themes and skins to existing pages and portlets, and verify that they produce the required view.
8.6
Verify migration of portlet applications
s.Log in to the current WebSphere Portal Administrative Interface.
t.
Click Portlet Management > Applications on the left navigation.
u.
Verify that the portlet applications that are listed are the ones that you migrated from the previous version.
v.
For each Web Module, verify that all your portlet applications also display in the Portlet Applications list.
w.
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.
x.
Click Access > Resource Permissions and select Portlet Applications from Resource Types .
y.
Click Assign Access to verify the access control information.
z.
Click Access > Resource Permissions and select Portlets from Resource Types .
aa.
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.
8.7
Verify migration of portlet configuration data
bb.Log in to the current WebSphere Portal Administrative Interface.
cc.
Click Portlet Management > Portlets on the left navigation.
dd.
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 .
8.8
Verify migration of virtual resources
ee.Log in to the current WebSphere Portal Administrative Interface.
ff.
Click Access > Resource Permissions on the left navigation.
gg.
Select Virtual Resources from Resource Types .
hh.
Verify that all virtual resources migrated from the previous version are present in the current version.
8.9
Verify migration of pages
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.附件：
Technical contents of ISO 639:1988 (E/F)
"Code for the representation of names of languages".
Typed by Keld.Simonsen@dkuug.dk 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
Two-letter lower-case symbols are used.
The Registration Authority for ISO 639 is Infoterm, Osterreichisches
Normungsinstitut (ON), Postfach 130, A-1021 Vienna, Austria.
aa Afar
ab Abkhazian
af Afrikaans
am Amharic
ar Arabic
as Assamese
ay Aymara
az Azerbaijani
ba Bashkir
be Byelorussian
bg Bulgarian
bh Bihari
bi Bislama
bn Bengali; Bangla
bo Tibetan
br Breton
ca Catalan
co Corsican
cs Czech
cy Welsh
da Danish
de German
dz Bhutani
el Greek
en English
eo Esperanto
es Spanish
et Estonian
eu Basque
fa Persian
fi Finnish
fj Fiji
fo Faroese
fr French
fy Frisian
ga Irish
gd Scots Gaelic
gl Galician
gn Guarani
gu Gujarati
ha Hausa
he Hebrew (formerly iw)
hi Hindi
hr Croatian
hu Hungarian
hy Armenian
ia Interlingua
id Indonesian (formerly in)
ie Interlingue
ik Inupiak
is Icelandic
it Italian
iu Inuktitut
ja Japanese
jw Javanese
ka Georgian
kk Kazakh
kl Greenlandic
km Cambodian
kn Kannada
ko Korean
ks Kashmiri
ku Kurdish
ky Kirghiz
la Latin
ln Lingala
lo Laothian
lt Lithuanian
lv Latvian, Lettish
mg Malagasy
mi Maori
mk Macedonian
ml Malayalam
mn Mongolian
mo Moldavian
mr Marathi
ms Malay
mt Maltese
my Burmese
na Nauru
ne Nepali
nl Dutch
no Norwegian
oc Occitan
om (Afan) Oromo
or Oriya
pa Punjabi
pl Polish
ps Pashto, Pushto
pt Portuguese
qu Quechua
rm Rhaeto-Romance
rn Kirundi
ro Romanian
ru Russian
rw Kinyarwanda
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
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
ug Uighur
uk Ukrainian
ur Urdu
uz Uzbek
vi Vietnamese
vo Volapuk
wo Wolof
xh Xhosa
yi Yiddish (formerly ji)
yo Yoruba
za Zhuang
zh Chinese
zu Zulu
$(document).ready(function(){dp.SyntaxHighlighter.HighlightAll('code');});
原文链接：
http://blog.csdn.net/jaminwm/article/details/4561467
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 武汉竟升公司 WebSphere Portal 内容管理升级实施方案
- 通过域策略管理电源方案（公司PC节能方案）
- 使用mysql_upgrade升级mysql5.1至5.6的数据库升级实施方案
- 2014年武汉的IT行情好像不太好(续)：20个月过后，再看当时面试过的几个公司--武汉财富基石-崩盘，辣妈萌宝-创业失败，朋友公司转交他人管理
- 软件项目管理作业实施方案 草案
- 推荐一个公司内部接口文档管理方案
- 小公司如何实施软件配置管理
- 54款开源服务器软件（内容管理、数据库、电子商务、邮件服务器、文件传输、操作系统、安全、小公司服务
- 公司接受了我的方案，使用独立主机来运行生产管理系统
- 2014年武汉的IT行情好像不太好(续)：20个月过后，再看当时面试过的几个公司--武汉财富基石-崩盘，辣妈萌宝-创业失败，朋友公司转交他人管理
- 公司级项目管理例会的汇报内容
- 关于初创型公司对公司网站的开发与管理内容
- 求公司电脑升级方案 求升级顺序 配置价格
- Microsoft操作系统远程管理实施方案(绿盟)
- 浅析CMS内容管理系统的两种方案
- 公司MongoDB 实施方案
- 求公司电脑升级方案 求升级顺序 配置价格
- 关于初创型公司对公司网站的开发与管理内容
- 公司USB设备管理策略方案