Learning Center
Plans & pricing Sign in
Sign Out
Get this document free

Prerequisites - DOC


									Rev 2.6

Customer DN Project for Websphere Portal

Prerequisites and General Comments
       The majority of these steps are performed only once for the entire cluster. Where steps
        are necessary on each node in the cluster, a comment is made in italicized red.

       We need to be sure there are no WCM drafts before we do these tasks (no authoring or
        editing should be taking place during this project).

       We need to be sure there are no locked JCR items such as PZN rules or WCM content

       MemberFixer, used in step 11 below, should only be run on the authoring environments.
        The resulting updates of MemberFixer will be syndicated to the rendering servers.
        Therefore, for whatever environment is being updated per these instructions, the
        accompanying authoring environment should also be updated. Then syndication should
        be re-established and verified to be working correctly.

The following steps should be taken to support a new customer DN (newid will be the new id). At
the completion of the steps below, users defined under the new DN will be able to login to Portal
and access Portal-related resources.

    1. BACKUP PortalServer and AppServer directories and Portal Databases.

    2. Install the fix for PK59896, which is a prereq for #7 below. This should be installed on
       every node, even though it will only be used on one of them.

        Using XMLaccess to generate exports, from ExportRelease.xml and Export.xml (the latter
        is for preserving personalized/private pages), export all users and groups.

        Navigate to the xml-samples directory on primary node (these files typically don’t exist on
        clones so you will need to back up the doc directory so that you will have access to the
        necessary, sample xml scripts such as Export.xml and ReleaseExport.xml)

        cd /opt/WebSphere/PortalServer/doc/xml-samples

        Once you locate the xml files, run the following using XMLAccess:

        /opt/release/run_xmlaccess_network ExportRelease.xml
        /opt/release/run_xmlaccess_network Export.xml
3. Totally disable syndication on the test servers by setting “available = false” in
   perties. This should be done on the subscriber node only.

4. Verify that the new newids for wps6bind and wps6admin exist in the new LDAP.

5. Update several configuration locations, to change the LDAP server attributes as well as
   switch CN usage from uid to newid, as follows.

    For WMM

    Backup all WMM xml files prior to making the following changes. They are located under
    the profile’s config/wmm directory.

    a. Use the configuration task check-out-wmm-cfg-files-from-
       dmgr to check these files out of DMgr’s cell into the PortalServer/wmm directory for

    b. Edit wmm.xml:

            Change all instances of uid to newid. Also reset ldapHost and ldapPort as

    c.   Edit wmmAttributes.xml:

            Switch the uid and newid attribute elements by renaming the wmmAttributeName
            attributes, not by moving them

    d. Edit wmmLDAPServerAttributes.xml:

            Switch the uid and newid attribute elements by renaming the wmmAttributeName
            attributes, not by moving them

    e. Edit wmmLDAPAttributes.xml:

            Replace all occurrences of “uid” with “newid”

    f.   Edit wmmWASAdmin.xml:

            replace all occurrences of “uid” with “newid”
            To ensure that the check-in works we must also copy the first line of the file and
            leave it with uid so there will be 3 lines in the file for wps6bind: example:
            <admin logonId="uid=wps6bind,ou=people,"

    g. Use the configuration task check-in-wmm-cfg-files-to-dmgr to
       check these files back into DMgr’s cell from the PortalServer/wmm directory.

    For Portal PUMA(to access the console you will need to login with the full uid dn of
    wps6bind - uid=wps6bind,ou=people,
Replace all instances of uid with newid in the “WP PumaService” resource environment
provider within the DMgr console. Don’t forget user.base.attributes. See screen shot
below: (use cluster scope)

For Portal Access Control

Go to the “WP AccessControlDataManagementService” in the DMgr console and update each adminuser
custom property to use newid instead of uid.

For Credential Vault
Go to the “WP VaultService” in DMgr console and update the systemcred.dn custom property to use
newid instead of uid.

For Validation Service
Go to the “WP ValidationService” in DMgr console and update the user.UNIQUEID custom property to
use newid instead of uid.

For the JCR

Edit .../PortalServer/jcr/lib/com/ibm/icm/ and modify the
jcr.admin.uniqueName property to use newid instead of uid. This must be done on
every node.
For General Portal

Edit …/PortalServer/config/ and change every instance of “uid” to
“newid”. You do not need to run any WPSconfig task at this point. This update is just to
ensure the file remains consistent with the running configuration.
This must be done on every node.


Under Global security -> Custom user registry -> Custom properties in the DMgr console,
you need to update the wmmUserSecurityNameAttr property from uid to newid (see
screen shot below).


Change the file
properties by changing the value of connect.usermanagement.userprefix=uid from uid to

Also under WAS, four different applications need their RunAs roles reset. The WAS Admin Console is not
helpful in doing this, so the best thing is to update each application’s ibm-application-bnd.xmi file directly
in DMgr’s filesystem and change “uid” to “newid”. For example:


    <runAsBindings xmi:id="RunAsBinding_1091795934156">
       <securityRole href="META-INF/application.xml#SecurityRole_1239736674665"/>

   Do this for the following applications:
            Dynamic Cache Monitor.ear

   After these have changed, you need to issue a full resynchronization to every node in the cluster, to push
   out these changes.

6. Change the WAS admin id (see screen shot below)
7. Stop Dmgr – Stop Portals – Stop NodeAgents – Start Dmgr – Start Node Agents – Start

    At this point, the switch to the new newid has been implemented if you can successfully
    log into Portal and the DMgr console. The steps below are used to “clean up” the
    environment from the remnants of the old extid.

8. Run XMLaccess on CleanupUsers.xml (PK59896 is required for WP 6013 or below)


    In the instructions in the link above, add cleanup-users=”true” to the <request> element
    in the CleanUpUsersList.XML, but do not add the migrate-users attribute. Also, find the
    wps6admin and wpsadmin users in the generated list and remove them. We will not be
    cleaning them up.

    Also remove any <group> entries. We do not need to clean those up either.
    Then use the xmlaccess command to import CleanUpUsersList.xml, like so:
            /opt/WebSphere/PortalServer/bin/ -in CleanUpUsersList.XML -user
            wps6admin -pwd ******** -out taskoutput.out -url

    This should clear out all old IDs. Afterwards, run xmlaccess again with the Task.xml input
    file to force the ids to be deleted:
              /opt/WebSphere/PortalServer/bin/ -in
              /opt/WebSphere/PortalServer/doc/xml-samples/Task.xml -user wps6admin -pwd
              ******** -out taskoutput.out -url http://localhost:10038/intranet/config

9. In the DMgr Admin Console, you need to temporarily increase the read and write
   timeouts of the HTTP layer for one server, so MemberFixer doesn’t timeout (it will have a
   lot of changes to make). Temporarily increase both the read and write timeouts of the
   HTTP Inbound Channel for each Transport Chain from 180 seconds to 1200 seconds.
        a. Go to Admin Console
        b. Go to Server -> Application Servers
        c. Select the server from the list
        d. Container Settings -> Web Container Transport Chains
        e. Click on each of the links:
f.   Click on the HTTP Inbound Channel (HTTP 1)
g. Change the timeouts for read and write from 180 to 1200
       h. Save the changes after going through each link (HTTP 1 - 4 will be changed and
          are in each of the 4 links)
       i. Also the step that has us unzip the temp fix (unzip /opt/release/DN-
          UAT/ -d /opt/WebSphere/PortalServer/wcm/shared/app/ in the
          spreadsheet) this should be actually the file /opt/release/DN-
          UAT/ and then we need to copy this class as well,
          /opt/release/DN-UAT/MemberFixerModule.class into
       j. Set max heap to 2400
       k. Set Initial heap to 2400
       l. Add this to end of jvm arguments line: -Xk25000 -Xloratio0.4
          Add this line to tracing(via admin consol):
       m. Restart the portal server

10. Update
    roperties to include the uid-to-newid mappings for MemberFixer. A copy of an updated that includes these mappings can be found under

11. Unzip the contents of /opt/release/marshall/ under
    /opt/WebSphere/PortalServer/wcm/shared/app, which contains a workaround to allow
    MemberFixer to treat invalid DNs as missing users instead of a configuration error.
    Restart portal on that node.

12. Run a custom script developed to iterate through all WCM libraries and run MemberFixer
    against them. This script will run for a long time, so it would be best to “nohup” it, like so:

    nohup /opt/release/marshall/ &

    Then the nohup.out log file can be tailed to watch the script’s progress.

    The list of libraries being processed is controlled by the file
    /opt/release/marshall/library.list. The library.list.original file contains all known libraries.
    The library.list file should only include those libraries that are necessary to update.
    Temporary and test libraries should be omitted, and hopefully eventually deleted.

    NOTE: This script should only be run on the WCM authoring servers. The results of
    these changes will be syndicated out to the test and production servers. Therefore,
    at the end of this step, syndication between the authoring and rendering servers
    should be re-enabled and verified.

13. Return the HTTP timeouts changed in step 9 above to their original 180 second values.
    These changes will be picked up the next time the server is restarted.

14. Re-enable syndication by setting “available = false” in
    perties. This should be done on the subscriber machine only.

15. Update PZN rules to have owners switched from uid= to newid=. This requires that
    someone export the PZN rules to a file, then run an ANT script against that file. The ANT
    script is /opt/release/marshall/process_pzn_exports.ant. This script needs to be edited
    and change the intputfile property value to match the PZN export file. The outputfile
    property should also be updated to provide a value for the resulting output. If no path is
    specified, the file’s location is assumed to be the same as the ANT file. After modifying
    the ANT file, it can be run as follows:

    /opt/WebSphere/AppServer/bin/ws_ant –f

    The results are stored in a file given the name of the outputfile property in the ANT file.
    This results file should be imported back into Portal PZN to update all user info. To verify
    the results, try editing one of the rules in the PZN UI and ensure you do not have any
    access control or user lookup issues.

To top