script1.xml:

<?xml version=”1.0″ encoding=”UTF-8″?>
<request type=”export” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=”PortalConfig_1.4.xsd”>
<portal action=”locate”>
<url-mapping-context action=”export” objectid=”*” />
</portal>
</request>

Script2.xml

Following script will export page2 which is nested inside page1 urlmpping:

<?xml version=”1.0″ encoding=”UTF-8″?>
<request type=”export” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” build=”wp6014_010_01″ version=”6.0.1.4″ xsi:noNamespaceSchemaLocation=”PortalConfig_6.0.1_2.xsd”>
<portal action=”locate”>
<url-mapping-context action=”locate” label=”page1urlmappingcontext”>
<url-mapping-context action=”export” label=”page2urlmappingcontext” />
</url-mapping-context>
</portal>
</request>

xmlaccess -in D:\Temp\export\urlmapping.xml -user wpsadmin -password wpsadmin -url http://localhost:10038/wps/config -out D:\Temp\script1_out.xml

2. Following scripts shows to export urlmapping inside a virtual portal:

Script3.xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<request type=”export“ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” build=”wp6014_010_01″ version=”6.0.1.4″ xsi:noNamespaceSchemaLocation=”PortalConfig_6.0.1_2.xsd”>
<portal action=”locate”>
<url-mapping-context action=”export” label=”vp1″ />
</portal>
</request>

Script4.xml

Following script will export page2 which is nested inside page1 urlmpping under a virtual poratl:

<?xml version=”1.0″ encoding=”UTF-8″?>
<request type=”export“ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” build=”wp6014_010_01″ version=”6.0.1.4″ xsi:noNamespaceSchemaLocation=”PortalConfig_6.0.1_2.xsd”>
<portal action=”locate”>

<url-mapping-context action=”locate” label=”vp1″>
<url-mapping-context action=”locate” label=”page1urlmappingcontext”>
<url-mapping-context action=”export” label=”page2urlmappingcontext” />
</url-mapping-context>
</portal>
</request>

xmlaccess -in D:\Temp\export\scrip3.xml -user wpsadmin -password wpsadmin -url http://localhost:10038/wps/config/vp1 -out D:\Temp\script3_out.xml

Note: By default all the child urlmapping contexts if exist would be exported along with parent.

Rerferences:

https://www-304.ibm.com/support/docview.wss?uid=swg21267262

This error was resolved by following steps:

1. Downgrading WAS version onto Dmgr and all nodes by uninstall WAS fixpack which was installed after fresh installation.

2. Install the portal fix PK38907 and PK68347 onto the new member.

3. Run WPSconfig cluster-setup task.

References:

http://www-01.ibm.com/support/docview.wss?uid=swg24015073

https://www-304.ibm.com/support/docview.wss?uid=swg1PK68347

http://groups.google.com/group/ibm.software.websphere.portal-server/browse_thread/thread/56c61658a417ddf3

It turns out that memory locations in a 32-bit system are referenced by 32-bit unsigned integers. This allows up to 2^32 possible memory locations. Since each location stores 1 byte you get 2^32 bytes or 4 GB if you prefer. On a 64 bit system there are 2^64 locations, or 16 exabytes.

Now, in Windows, the contiguous part becomes a big issue, but that is just how Windows does things. The idea is that you need to have an entire “uninterrupted” range for your heap. Sadly, Windows allocates some memory somewhere in the middle. This basically leaves you with about half the left side or half the right side, about 1.5-2GB chunks, to allocate your heap.

References:

http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-32bit-vs-64bit

<status element="unknown" result="failed">
<message id="EJPXA0049E">com.ibm.wps.command.xml.XmlFormatException: EJPXA0049E: Input syntax error in line 1 column 1: the XML input does not conform to the XML schema.</message>
<message>org.xml.sax.SAXParseException: Content is not allowed in prolog.</message>
</status>

It’s usually because of some garbage characters added in the xml which was first exported by xmlaccess command.

If the garbage characters are not visible in the initial input file, then do the following:

1. Copy the contents starting at line 2 to last line from the input file
2. Paste the contents in the notepad and save it as xml file
3. Retry the XmlAccess import using the new xml file.

2. Run the following command to encrypt the password

\PortalServer\config\wpsconfig.bat wmm-encrypt –Dpassword=password

2.1 If it’s “Clustered environment”, then checkout wmm files from Dmgr by running the following command but before that make sure you have take backup of existing wmm directory:

wpsconfig.bat check-out-wmm-cfg-files-from-dmgr –DWasPassword=<waspassword>

3. Add the following entry into the file PortalServer\wmm\wmmWASAdmin.xml, use  and use encypted password return by config task in step-2

<admin logonId=”test” logonPassword=”encrypted password return in step-2” uniqueUserId=”uid=test,o=Default Organization”/>

3.1 If clustered environment then checkin wmm files into Dmgr by running the following command

wpsconfig.bat check-in-wmm-cfg-files-to-dmgr –DWasPassword=<waspassword>

OR alternatively you can skip step-2 and step-3 above and follow the step below:

2. Run the following command to add the user inside wmmWASAdmin.xml file:

\PortalServer\config\work\wmm\bin\updateWmmWASAdminRegistry.bat -action 1 -logonId test -logonPassword test -uniqueUserId "uid=test,cn=users,ou=software,o=ibm"

Actions can be:

1 – add a user
2 – modify a user
3 – delete a user

References:

https://www-304.ibm.com/support/docview.wss?uid=swg21246919

http://fernandokarnagi.wordpress.com/page/4/

2. WASPreUpgrade C:\Users\WebSphere7\waspreupgradebk C:\IBM\WebSphere\AppServer -oldProfile wp_profile

3. WASPostUpgrade C:\Users\WebSphere7\waspreupgradebk -profileName wp_profile7 -oldProfile wp_profile -username wpsadmin  -password wpsadmin -includeApps true -backupConfig false

4. In admin guide it’s suggested to change WPv7 ports after the upgradeConfigEnigne task but as both portal servers are listening on same ports so it may update WPv6.1 configenigne tool. That’s why it’s suggested to do either remote migration or change the ports before running the upgradeConfigEngine task.

In my environment I guess it updated the WPv6.1 configenigne tool because it was not able to run successfully and it was pointing to WPv7 installation location during run time.
5. upgradeConfigEngine wp_profile7 -conntype SOAP -hostname  277930-hlthap32.arahlthcare.com -port 16040 -user wpsadmin -password wpsadmin

References:

https://www-304.ibm.com/support/docview.wss?uid=swg27021370&aid=1

1. ConfigEngine.bat list-server-ports -DWasPassword=password OR

ConfigEngine.bat list-server-ports-by-name -DServerName=server1 -DwasPassword=password

2. ConfigEngine.bat modify-ports-by-startport -DModifyPortsServer=servername -DStartPort=starting port number OR

ConfigEngine.bat modify-ports-by-portsfile -DModifyPortsServer=servername -DPortsFile=full path to ports file

Here are the contents of sample ports file:

BOOTSTRAP_ADDRESS=10031
SOAP_CONNECTOR_ADDRESS=10033
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=10032
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=10025
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=10036
WC_adminhost=10027
WC_defaulthost=33344
DCS_UNICAST_ADDRESS=10029
WC_adminhost_secure=10039
WC_defaulthost_secure=10035
SIB_ENDPOINT_ADDRESS=10026
SIB_ENDPOINT_SECURE_ADDRESS=10037
SIB_MQ_ENDPOINT_ADDRESS=10030
SIB_MQ_ENDPOINT_SECURE_ADDRESS=10028
ORB_LISTENER_ADDRESS=10034

References: http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/install/stdalone_win_inst_wp.html

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/install/stdalone_win_inst_wp.html

You can check in your C:\IBM\WebSphere\wp_profile\PortalServer\wps.properties, whether you have installed the server version which does not contain WCM.

Following is Server installation which does not contains WCM:
WPFamilyName=server
WPInstallType=full

Following is Content installation which does contain WCM:

WPFamilyName=content
WPInstallType=full

References:

https://www-304.ibm.com/support/docview.wss?uid=swg21320888

Run the following command to update parent property file wkplc.properties and validate the connection to LDAP:
-> ConfigEngine validate-federated-ldap -DparentProperties=C:\IBM\WebSphere\wp_profile\ConfigEngine\config\helpers\wp_add_federated_ad.properties -DSaveParentProperties=true -DWasPassword=wpsadmin -DPortalAdminPwd=wpsadmin

2. Run the following command to add a federated ldap and then restart WebSphere_Portal server:
-> ConfigEngine.bat wp-create-ldap -DWasPassword=wpsadmin

3. Check that all defined attributes are available in the configured LDAP user registry.Run the following task :
NOTE: After running the following task, check the ConfigEngine/log/ConfigTrace.log file for missing attributes in portal. Then proceed to the following steps.
-> ConfigEngine wp-validate-federated-ldap-attribute-config -DWasPassword=password

4. Run the following task : The task will create “availableAttributes.html” file in wp_profile_root/ConfigEngine/log dir.
-> ConfigEngine.bat wp-query-attribute-config -DWasPassword=password

5. Enter a value for one of the following sets of parameters in the wkplc.properties file found under the VMM Federated repository properties heading to correct any issues found in the config trace file:
federated.ldap.attributes.nonSupported
federated.ldap.attributes.nonSupported.delete
federated.ldap.attributes.mapping.ldapName
federated.ldap.attributes.mapping.portalName
federated.ldap.attributes.mapping.entityTypes

Run the following task to update the LDAP user registry configuration and then restart WebSphere_Portal:
-> ConfigEngine.bat wp-update-federated-ldap-attribute-config -DWasPassword=wpsadmin

6. Update the values for the following required parameters in the wkplc.properties file under the VMM supported entity types configuration heading:
personAccountParent=cn=users,dc=ibm,dc=com
groupParent=cn=groups,dc=ibm,dc=com
personAccountRdnProperties=uid
groupRdnProperties=cn

Run the following command to update Group and PersonAccount entity types and then restart WebSphere_Portal:
-> ConfigEngine wp-update-entitytypes -DWasPassword=wpsadmin

7. Update the following parameters in the property file wkplc.properties:
newAdminId=
newAdminPw=
newAdminGroupId=

Change WAS admin Id by running the command and then restart WebSphere_Portal:
-> ConfigEngine.bat wp-change-was-admin-user -DWasPassword=wpsadmin -Dskip.ldap.validation=true

Change Portal admin Id by running the command and then restart WebSphere_Portal:
-> configEngine.bat wp-change-portal-admin-user -DWasPassword=wpsadmin -Dskip.ldap.validation=true

8. Enter a value for the following required parameters in the wkplc.properties file under the VMM realm configuration section:
realmName=ADrealm1
addBaseEntry=dc=us,dc=ibm,dc=com
securityUse=active
delimiter=/

Run the following command to create realm:
-> ConfigEngine.bat wp-create-realm -DWasPassword=password

9. To update the default parents per entity type and realm
realmName=IDSRealm1
realm.personAccountParent=cn=users,dc=us,dc=ibm,dc=com
realm.groupParent=cn=groups,cn=groups,dc=us,dc=ibm,dc=com
realm.orgContainerParent=dc=us,dc=ibm,dc=com

To update the default parents per entity type and realm.Run the following task and then restart WebSphere_Portal
-> ConfigEngine.bat wp-modify-realm-defaultparents -DWasPassword=password

References:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/MultipleRealms.pdf/$file/MultipleRealms.pdf

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/topic/com.ibm.wp.ent.doc_v615/install/win_add_ldap_ureg_ssl.html