v6.0 post migration steps for web content

Once you have completed the WebSphere Portal migration steps, you need to perform these additional steps to complete web content migration.

Mandatory post migration steps

After migrating from version 6.0.x, run the update-wcm-data task from the WP_PROFILE/PortalServer/migration}}} directory of v7.0 server:
Windows™

WPmigrate.bat update-wcm-data -DWasUserId=username -DWasPassword=foo -DPortalAdminId=username -DPortalAdminPwd=foo -DbackupDirectory=directory

UNIX™

./WPmigrate.sh update-wcm-data -DWasUserId=username -DWasPassword=foo -DPortalAdminId=username -DPortalAdminPwd=foo -DbackupDirectory=directory

i

WPmigrate.sh update-wcm-data -DWasUserId=username -DWasPassword=foo -DPortalAdminId=username -DPortalAdminPwd=foo -DbackupDirectory=directory

Once have performed these steps, review the following optional post migration steps and update system as required.

JSP files and Web content plugins.

• Any JSP files used on old system will need to be manually copied to new system.

• Any Web content plugins used on old system, such as custom workflows, will need to be manually copied to new system and enabled.

Search Indexes

You will need to rebuild search indexes after migrating to v7.0:

1. Stop server.

2. Delete all the index directories under WP_PROFILE/PortalServer/jcr/search

3. Restart the portal server

4. The search indexes should be rebuilt the next time the index maintenance interval is reached.

5. If the index directory is not built, edit a document and save it, and tray manually rebuilding the search index.

Remote rendering portlets

If you migrated the IBM API rendering portlets, update the migrated remote rendering portlets to v7.0:

1. Log in to migrated server as an administrator.

2. Go to the Administration view and then Portlet Management.

3. Select Web Modules.

4. Click Update.

5. Click Browse.

6. Select the file called ilwwcm-remoterendering-portlet.war from the $PORTAL_HOME/wcm/prereq.wcm/installableApps folder of v7.0 server. This must be a content server installation as this file is not installed on an administration server installation.

7. Click Open.

8. Click Next.

9. Click Finish.

The configuration settings of remote rendering portlets on remote servers will be unchanged after you have migrated servers. If migrated servers use the same naming conventions as old servers, then you will not have to re-configure remote rendering portlets. If you have changed the naming conventions of migrated server, such as giving migrated cluster a different name than old server cluster, then you will have to re-configure remote rendering portlets. The migrated portal URL takes this form:

http://host_name:port_number/original-context-root_migrated/portal

For example, if original portal URL is http://www.example.com:10040/wps/portal, the URL for the migrated portal is http://www.example.com:10040/wps_migrated/portal

If you have a small number of remote rendering portlets, you can edit the configuration settings of remote rendering portlets manually. If you have a large number of remote rendering portlets, then you can use the XML configuration interface to re-configure remote rendering portlets. To do this you will have to export the pages containing remote rendering portlets:

• You can use the XML configuration interface (xmlaccess command) to export the remote rendering portlet web application and all related portal pages.

• You can also use the Export Pages portlet in the portal's administration to export the entire page hierarchy containing the remote rendering portlets.

Once exported, change the value of the WCM_REMOTE_HOST_BASE_PATH variable for all the portlets to v7.0 servers. This updated XML file can then be imported using the xmlaccess command or the Import XML portlet.

If you are migrating from version 6.0.x, a full export is also performed during a full WebSphere Portal migration, so remote rendering portlet changes can also be made to the allout.xml file before running the portal-post-upgrade task.

Authoring portlet access changes from version 6.0 to 7.0

There are a number of authoring access control features which you need to plan for and implement as part of migration. Usage of these features depends on what pattern of authoring access control you require.

In v7.0 access permissions that are set on the library are by default automatically inherited by each new item created in the library. In previous versions, access permissions were not automatically inherited by new library items. When you migrate content to a v7.0 server, the access permissions inheritance on migrated items will not have changed. If you decide that you want to enable automatically inherited access permissions, you will need to:

• Review library access permissions controls and ensure propagation is enabled for libraries.

• Enable automatic access permissions inheritance by editing the WCM WCMConfigService service and setting default.inherit.permissions.enabled to "true". See http://www.lotus.com/ldd/portalwiki.nsf/dx/Web_content_authoring_options_lwcm7 - for further information.

• As this will only apply to items created after you enable automatic access permissions inheritance, also edit existing items so that access permissions inheritance is enabled. You can also remove existing permissions that are set at an item level, but that can now be inherited. This can be done using one or a combination of the following methods:

  • To update the access permissions for all items or all items of a given type, use the Update Security administration task. See http://www.lotus.com/ldd/portalwiki.nsf/dx/Using_the_Update_Security_task_lwcm7 - .

  • To update the access permissions for multiple items at once, use the batch-editing access form. See http://www.lotus.com/ldd/portalwiki.nsf/dx/Batchediting_access_controls_lwcm7 - .

  • To update the access permissions for a single item, use the access section of the item form.

If you decide that you do not want to enable automatically inherited access permissions, you will need to:

• Disable automatic access permissions inheritance by editing the WCM WCMConfigService service and setting default.inherit.permissions.enabled to "false". See http://www.lotus.com/ldd/portalwiki.nsf/dx/Web_content_authoring_options_lwcm7 - for further information.

It is recommended that you use automatically inherited access, since this new feature greatly simplifies administrating library access.

In previous versions, to access item type views in the authoring portlet the user required "contributor" access in a library's item types settings. "User" access on the library's item type settings did not give users access to anything in the authoring portlet. In v7.0, the user only requires "user" access on the library's item type settings to access item type views in the authoring portlet. Therefore users with "user" access to the library's item type settings who don't require access to these views in the authoring portlet should have their "user" access removed from the library's item type settings.

The wcmadmins group changes from version 6.0 to 7.0

If you used the wcmadmins group in 6.0 you should be aware that wcmadmins does not automatically have administrator access in v7.0. When you migrate from version 6.0 to 7.0, the wcmadmins group will be migrated, but the members of this group will not have administrator access to web content. To grant the members of old wcmadmins group administrator access to web content either assign the wcmadmins group, or the individual members of wcmadmins, to the administrator role on migrated web content library.

HTML encoding changes from version 6.0 to 7.0

In v7.0 , reserved HTML characters stored in some elements are converted into character entities. For example, '<' will be converted to '&lt;'. This is useful if you would like to prevent users adding malicious code, or if you want to prevent users changing the look and feel of their text using HTML. This behavior is enabled by default. To disable this behavior you edit the WCM WCMConfigService service and set this value to "false":

cmpnt.htmlEncodeDefault=false

Caching changes from version 6.0 to 7.0

The default resourceserver.maxCacheObjectSize setting in the WCM WCMConfigService service has been reduced from 10000 kilobytes to 300 kilobytes to maximize cache performance.

Menu component changes from version 6.0 to 7.0

In v7.0, menus will return no search results if you select a search criteria but don't enter any search parameters. For example, if the menu is configured to return results based on categories, but no categories are specified in the menu form, then no matches will be found. In previous versions, menu searches would ignore any selected search criteria without search parameters. You need to fix any migrated menus that contain search criteria without search parameters. You can also configure menus to use the search behavior available in previous versions by setting menu.executeWhenCriteriaEmpty to "true" in the WCM WCMConfigService service.

Authoring tool component tag changes from version 6.0 to 7.0

You no longer need to use an authoring tool component tag to reference authoring tool components in menu or navigator designs. Instead, you can use a component tag with a parameter of compute="always". For example:

 [Component name="authoringtoolname" compute="always" ]

Existing authoring tool component tags will still function correctly in migrated data.

Expired item changes from version 6.0 to 7.0

In version 6.0, items that had no expire date specified would never expire. In v7.0 this has been changed so that items with no expire date will be expired as soon as an expire action is triggered. You can configure v7.0 server to use the behavior available in previous versions by setting expire.blankdate.immediately to "false" in the WCMConfigService.properties file.

Parent

Post-migration activities

Related tasks

Export configuration for migration to a remote server
Set service configuration properties

Work with xmlaccess.sh

  Added additional 6.0 > 7.0 material Submitted by Troy Astle on Aug 29, 2011 1:54:02 AM

Re: v6.0 post migration steps for web content

The link Using the Update Security task: lwcm7 is broken. I can't find the page for 7.0.

Here is the one from the 8.0 beta Using_the_Update_Security_task_wcmbeta Submitted by Richard Spinks on Nov 30, 2010 5:40:14 PM

v6.0 post migration steps for web content: wp7

Updated component example to remove context="autofill," per Matthias' comment. Submitted by Matthias Falkenberg on Nov 24, 2010 7:07:12 AM

v6.0 post migration steps for web content: wp7

The component tag sample for including authoring tools components in menu or navigator designs is:

[Component name="authoringtoolname " context="autofill" compute="always" ]

but it should be:

[Component name="authoringtoolname" compute="always"]

The reason is that the context="autofill" is only used with personalization components and cannot be used in conjuction with compute=always. Authoring tools components will always pick up the current menu result when rendered in the design field.

+

Search Tips   |   Advanced Search