Rev 2.6
Customer DN Project for Websphere Portal 6.0.1.3
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.
Scope
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.
Instructions
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
/opt/WebSphere/PortalServer/wcm/shared/app/config/wcmservices/SchedulerService.pro
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 WPSconfig.sh configuration task check-out-wmm-cfg-files-fromdmgr to check these files out of DMgr’s cell into the PortalServer/wmm directory for
editing.
b. Edit wmm.xml:
Change all instances of uid to newid. Also reset ldapHost and ldapPort as
appropriate.
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,o=company.com"
logonPassword="zwDd/rDxiFju+N7Nbag35A=="
uniqueUserId="uid=wps6bind,ou=people,o=company.com"/>
g. Use the WPSconfig.sh 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,o=company.com)
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/icm.properties 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/wpconfig.properties 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 wpconfig.properties file remains consistent with the running configuration.
This must be done on every node.
For WAS
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).
For WCM
Change the file
//opt/WebSphere/PortalServer/wcm/shared/app/config/wcmservices/WCMConfigService.
properties by changing the value of connect.usermanagement.userprefix=uid from uid to
newid.
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:
/opt/WebSphere/DeploymentManager/profiles/profileDmgr/config/cells/DMGRWP6U1/applications/LWP_CAI.ear/deployments/LWP_CAI/META-INF/ibm-application-bnd.xmi.
<runAsBindings xmi:id="RunAsBinding_1091795934156">
<authData
xmi:type="com.ibm.ejs.models.base.bindings.commonbnd:BasicAuthData"
xmi:id="BasicAuthData_1091795934156"
userId="uid=wps6admin,ou=people,o=company.com"
password="{xor}Bmkhajs5KT0="/>
<securityRole href="META-INF/application.xml#SecurityRole_1239736674665"/>
</runAsBindings>
Do this for the following applications:
LWP_CAI.ear
LWP_Security_Ext.ear
Pznscheduler.ear
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)
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.zos.doc/wpf/sec_p
swds.html?resultof=%22%63%68%61%6e%67%65%22%20%22%63%68%61%6e%67
%22%20%22%70%61%73%73%77%6f%72%64%22%20#sec_pswds__rep_was_id
7. Stop Dmgr – Stop Portals – Stop NodeAgents – Start Dmgr – Start Node Agents – Start
Portals
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)
http://www01.ibm.com/support/docview.wss?rs=688&context=SSHRKX&context=SS3JLV&context=
SS3NNG&context=SSYJ99&context=SSRUWN&context=SS6JVW&q1=migrate%20user
%20extID&uid=swg21322037&loc=en_US&cs=utf-8&lang=en
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/xmlaccess.sh -in CleanUpUsersList.XML -user
wps6admin -pwd ******** -out taskoutput.out -url
http://localhost:10038/intranet/config
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/xmlaccess.sh -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/DNUAT/comMF3.zip -d /opt/WebSphere/PortalServer/wcm/shared/app/ in the
spreadsheet) this should be actually the file /opt/release/DNUAT/memberfixerpatch.zip and then we need to copy this class as well,
/opt/release/DN-UAT/MemberFixerModule.class into
/opt/WebSphere/PortalServer/wcm/shared/app/com/aptrix/pluto/security/
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):
com.presence.connect.wmmcomms.PrincipalInformation=error
m. Restart the portal server
10. Update
/opt/WebSphere/PortalServer/wcm/shared/app/config/wcmservices/WCMConfigService.p
roperties to include the uid-to-newid mappings for MemberFixer. A copy of an updated
WCMConfigService.properties that includes these mappings can be found under
/opt/release/marshall.
11. Unzip the contents of /opt/release/marshall/comMF3.zip 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/process_all_libraries.sh &
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
/opt/WebSphere/PortalServer/wcm/shared/app/config/wcmservices/SchedulerService.pro
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
/opt/release/marshall/process_pzn_exports.ant
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.