Thoughts on Portal from Level 2 Support
jwbarnes 06000271DW 2.471 Visualizações
First entry in the blog for level 2 support. Several of us here in Portal Level 2 support had the idea to create a blog to help foster communication with the community. We also plan to include helpful articles as often as possible covering as many topics as we can. We will start of in the development realm with taking a look at the controller spi and studying for the 7.0 developer exam. If you have any topics you would like to see us cover in the coming months please let us know.
I would like to take a high level overview of the various programming entry points that WebSphere Portal provides to allow you access into the internals of the Portal to both make changes as well as request information about various aspects of the Portal.
The first thing to understand is that you will almost always have to get a home object which represents the starting point for interactions in that package. Such that if you wanted information on access control you would use a JNDI lookup to retrieve AccessControlHome, or for PumaHome if you want to get information on the Portal User interface. Once you have the Home you will need to get either the Model or the Provider object depending on the needs of the code. Next we will look at the most common packages and their uses.
Creating a new theme in WebDAV:
In Websphere Portal v7, themes are broken apart into static template files and dynamic files. The static template files are stored in WebDAV and use dynamic content spots to reference JSPs or other dynamic resources. The dynamic resources are stored in a WAR file. WebDAV directories include files for the following theme functionality: theme, skin and layouts.
The following steps will create a new theme in portal using WebDAV.
note: best practice is to use the fs-type1 entry point for modifying the files and not the themelist entry point. The themelist entry point is an admin entry point and is used for altering theme metadata including the titles. Please note the cache above will only effect the themelist entry point not the fs-type1. As an additional exercise reset the caching to default values, restart the server, and then make a change via the fs-type1 entry point and see that your changes are immediately visible.
Now that the new theme is created lets take a few minutes to understand what happened by generating a complete xmlAccess export of the server using the following technote:
Note that you will be using this XMLAccess export in a future step.
You should now see a theme defined like the following (the objectid may be different):
<theme action="update" active="false" context-root="/PageBuilder2" default="false" domain="rel" objectid="ZJ_4GFA8VO20G3ID0IMR5PK562006" resourceroot="PageBuilder2">
<parameter name="theme.capability.dojo" type="string" update="set"><![CDATA[1.4.3]]></parameter>
<parameter name="com.ibm.portal.friendly.name" type="string" update="set"><![CDATA[sample.theme]]></parameter>
<parameter name="com.ibm.portal.themetype" type="string" update="set"><![CDATA[CSA2]]></parameter>
<parameter name="theme.capability.oneUI" type="string" update="set"><![CDATA[2.1]]></parameter>
<parameter name="com.ibm.portal.theme.template.ref" type="string" update="set"><![CDATA[dav:fs-type1/themes/sample.theme/]]></parameter>
<parameter name="theme.capability.mashups.enabler" type="string" update="set"><![CDATA[2.4]]></parameter>
The newly created sample theme is using the PageBuilder2 war file. This can be seen from the context-root and resourceroot attributes. There are also several parameters defined for the theme. If present, the ?com.ibm.portal.friendly.name? parameter is used as the display name for the theme in the themelist webDAV entry point. This should be a unique value in the system but this is not enforced. If the ?com.ibm.portal.friendly.name? parameter is not available then the uniquename of the theme is used as the display name. If neither the ?com.ibm.portal.friendly.name ? or the uniquename are defined for the theme then the theme's OID will be used as the display name.
The themelist webdav entry point mirrors the fs-type1 entry point. Since the themelist uses the ?com.ibm.portal.friendly.name as the display name it has to be unique. If there are two themes that have the same value, only one will be displayed.
When our sample theme is rendered the default.jsp of the PageBuilder2 WAR is the main entry point. The default.jsp will then call the correct theme.html file to execute. It determines the correct path by using the com.ibm.portal.theme.template.ref parameter.
Creating a new theme WAR file
The theme WAR file will contain the dynamic resources. As stated in the previous section the default.jsp of the
PageBuilder2 theme is used when our sample theme renders. If you want to modify the default.jsp or any of the dynamic resources you should create a new WAR to contain them.
The default.jsp of the Sample
Theme is used when rendering the page with the theme applied. However
as stated previously the default.jsp will call the static theme
template that is defined in the themes metadata. For the sample theme
<!-- responsible for the top most navigation links (horizontal list) -->
<a rel="dynamic-content" href="dyn-cs:id:bannerNav@tl:oid:csa2.theme"></a>
This markup will inform the static page parser in WebSphere Portal to look for dynamic-content-spot with an id of bannerNav. You will also notice that the href contains @tl:oid:csa2.theme. This instructs the static page parser to look in the theme with a uniquename of csa2.theme for any dynamic-content-spot overrides. All this means is that your theme is still using the bannerNav.jsp from the PageBuilder2 WAR file and not from your custom SampleTheme WAR.
If you want it to your content spots
to pull from your custom war you would need to change them to
reference your custom war.
Many folks are getting started looking at getting certified for WebSphere Portal v7.0. In this first part we will take a look at the test, its makeup, information on it and how to prepare.
First thing to know is that this test is more difficult than the previous versions of the tests. The questions are much more specific and will cover a wider array of topics given all the new v7 functionality.
Taking a look at the test there will be 60 questions, in which you have 75 minutes to answer them. You must get 67% right to pass the certification. Those questions will be compromised of the following areas.
There will also be 2 unscored questions.
From the chart above we can see that the test is broken up into 7 core areas with some areas getting more focus that others. For this test you will want to understand the themes and skins of Portal 7.0, the APIs for both portlet specs, as well as the additional portlet services and frameworks that are provided. This covers a very broad range of topics so plan to spend a significant amount of time on each of the major sections.
To start off with your main areas of study will be the following:
You can find more about the test here. There you can find links to additional test information as well as link to a sample test. It would be a good idea to go through the sample test at least once to get yourself prepared for the test.
In future installments we will delve into the specific sections with more study pointers on each section.
JMW98 2000000MY6 5.684 Visualizações
WebSphere Portal relies on setting certain cookies to enforce its security controls. As an administrator, you should carefully consider how to protect these cookies in your environment. Unauthorized parties could circumvent WebSphere Portal's security controls given access to:
LTPAToken2 (and LTPAToken, if Interoperability Mode is enabled): Lightweight Third-Party Authentication: WebSphere Application Server relies on this cookie for Single Sign-On. WebSphere Application Server considers a client to be authenticated if it presents a valid LTPAToken2.
JSESSIONID: from the Java Servlet specification: WebSphere Portal's session management uses this cookie.
1. To guard against network eavesdropping, enable SSL for all communications between the browser and the web server. Without an HTTPS pipe, you are relying on the security of the network (which could be a valid option in intranet or VPN environments). If you cannot guarantee network security, it is essential that these cookies be transmitted only within an HTTPS pipe.
2. Define these cookies' domains as narrowly as possible. If a cookie's domain is left unset, the browser should present it to only the server that set the cookie.
3. In conjunction with (1) and (2), consider setting the secure attribute on these cookies. For example, a browser accesses https://portal1.ibm.com/wps/myportal, authenticates, and LTPAToken2 is set with domain=ibm.com. When the browser later requests http://server2.ibm.com, it presents LTPAToken2 over HTTP because of the domain. Setting the secure attribute tells the browser to present the cookie only over HTTPS, regardless of domain.
4. Set HTTPOnly to guard against cross-site scripting (XSS). When HTTPOnly is set for a cookie, the browser should not allow scripts to access the cookie. Of these several recommendations, this is the most highly reliant upon browser implementation. HTTPOnly is a useful tool, but application developers should be vigilant in guarding against XSS regardless of HTTPOnly.
5. Consider your securtiy requirements when configuring LTPA token expiration and session timeouts. Expiration is actually encoded into an LTPA token's value. Simply restricting access to the server long enough for all issued LTPA tokens to expire would mitigate a known breach.
Note: If WebSphere Portal is integrated with an external security manager (ESM) in your environment, you might also need to consider the ESM's cookies. For example, given a valid ESM cookie, a trust association interceptor could instruct WebSphere Application Server to issue a new LTPAToken2.
For more information on these and other WebSphere Portal security topics, refer to:
In this second part we want to take a look at the section on "Architecting a Portal solution". There will be 7 questions on this area on the test.
Topics covered are
Find more about the Unified Task list please click here Unified Task List Please be aware that when the test was created it was in reference to version 3.0 of the portal, and version 4.0 is now out.
Live Text is used mostly for click to action. You can find more information here. You should read through this section of the infocenter and understand how it works to create source and targets for c2a. Do not spend to much time on this as it is a small part of the exam.
Next time we will deal with a bigger area of the test, portlet development.
JMW98 2000000MY6 2.182 Visualizações
Updates to the list I posted previously:
6. Enable Security Integration.
7. Make sure WAS APAR PM00610 is installed.
8. If possible, disable Interoperability Mode.
9. Restrict access to clients maintained by your organization (i.e. patch browser & OS vulnerabilities).
10. Restrict access to networks maintained by your organization (e.g. consider especially security of DNS to the client).
When a problem occurs the most important step in resolving the issue is providing IBM Portal L2 Support with a complete set of diagnostic data including traces and logs. The task of doing this manually involves enabling tracing, recreating the issue, manually packaging files, and uploading them to support. In the past we have recommended ISALite, which is a tool available for download, that automates the process of selecting a problem type, recreating the issue, collecting the needed logs and files, and uploading them to support. We are currently in the process of moving to a web based tool called IBM Support Assistant Data Collector (ISADC). When available, the ISADC will not require the end user to download and install a collection tool, however it will still provide the same benefits as ISALite. ISADC will have the following advantages over the existing ISALite tool...
- You will not have to download and install an application.
- Since ISADC is client-server based, you will always be using the latest scripts.
- When opening electronic problem tickets with IBM via SR you will be able to start a data collection and provide the initial logs and files to Portal L2 Support.
- When an automated data collection is provided at PMR creation the problem investigation and determination is expedited.
The ISADC for WebSphere Portal will be released as a Tech Preview very soon. More functionality will be released in the coming months. Stay tuned to the blog for additional details and watch for the ISADC link in the SR tool. We welcome any feedback or suggestions regarding ISADC or automated data collection in general.
Websphere Portal L2 support
About two weeks ago, we published a tool that we use internally to troubleshoot failures with ConfigEngine scripts, and failures during WebSphere_Portal startup. The tool is called 'IBM Portal Log Analyzer' and can be found on the Lotus Greenhouse here:
The tool parses the ConfigTrace.log and the SystemOut.log for easier reading and allows you to quickly find failures so that you can begin troubleshooting.
Ideally you would use the tool for the following situations:
- Any ConfigEngine script fails (ConfigTrace.log)
- Fixpack or cumulative fix installation failure (ConfigTrace.log)
- WebSphere_Portal fails to initialize (SystemOut.log)
- WebSphere_Portal is open for e-business, but you cannot access it in a browser. (e.g. you see '404 one or more services failed to initialize'. This means the 'wps' application failed to start correctly.). (SystemOut.log)
- WebSphere_Portal is open for e-business, but one or more of your applications are unavailable. (SystemOut.log)
Here it is, the new white paper showing how to clone an installation of IBM WebSphere Portal version 7.0 that has been configured for specific deployment needs:
I have been testing the document myself and have come up with a number of observations:
1. The steps have been vastly simplified since the Portal 6.1.x instructions came out. Also there have been some improvements which allow for more flexibility if the new node is on the same LAN, unlike previous versions.
2. These steps are only usable if your OS to OS is comparable -- i.e. Windows 32-bit to Windows 32-bit, or RHEL 32 bit to RHEL 32 bit, etc.
3. Certain 64 bit OS versions will not support the GUI. My first attempt was with RHEL 64 bit in which the exceedingly more complicated ifcli.sh|bat must be run instead of the ifgui.sh|bat which is much simpler to use. At the very least I would suggest that one's initial test should be using the GUI version shown in the white paper.
4. I'm still playing around with but I have noticed that on certain target systems there have been some apparent port conflict problems. I'm still working on what may have caused this as it's not very clear how this occurred.
twcornwe 0600025RJ4 3.603 Visualizações
We have seen a few cases when customers reported that Portal users could no longer create new pages all of a sudden. This used to work before and had recently stopped working. In the "Manage Pages" portlet, after the user clicks the button "New Page" to create a new page, instead of seeing the Page Properties being loaded, the user gets an exception:
"EJPAS0012E: The Properties page has been launched with no context information"
This issue is usually seen in environment where the "Page Properties" is using a custom theme, either via explicit theme assignment to the page or via inheritance.
The Portal logs do not record much detailed information about this exception. It's generally helpful to get a full export of the Portal configuration for review.
Administration portlets depend on services provided by the Portal theme. If those services are not available to the administrative portlets, exception EJPAS0012E will be thrown. The "Page Properties" page requires the use of the adminNavHelper JSP tag, which must be present in the Default.jsp. If the assigned custom theme is lacking this tag, this issue will occur.
For this scenario, there are two possible solutions for the problem:
+ Solution 1: Assigning the out-of-the-box "Portal" theme for the 'Page Properties" page so that the required services are available.
+ Solution 2: Modify the custom theme and add the <portal:adminNavHelper/> JSP tag to the Default.jsp.
This scenario and details about the solutions are described in IBM Technote # 1395801.
There is also a specific scenario when this issue may occur in older versions of Portal, even though the "Page Properties" page is using the out-of-the-box Portal theme, no custom theme involved. In this case, the issue occurs if there exists a friendly URL called "pageproperies" for the "Page Properties" page.
Support has tested and verified that this issue occurred in Portal 220.127.116.11 but is indirectly fixed in Portal 18.104.22.168 and later versions.
The solution in this scenario is removing the offending friendly URL using XMLAccess (because, due to this issue, the user is unable to launch the "Page Properies" page via the Portal Administration UI to delete the friendly URL).
A sample XMLAccess input script is something similar to:
<?xml version="1.0" encoding="UTF-8"?>
<!-- IBM WebSphere Portal/22.214.171.124 build wp6101_115_01 exported on Wed Oct 05 08:48:05 EDT 2011 from MyPortal6101/127.0.0.1 -->
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp6101_115_01" type="update" version="126.96.36.199" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd">
<content-node action="locate" domain="rel" objectid="6_000000000000000000000000A0" uniquename="wps.content.root"/>
<content-node action="update" content-parentref="6_000000000000000000000000A0" create-type="explicit" domain="rel" objectid="6_CGAH47L008DF802B56IQ0D0G94" preserve-old-layout="true" type="page" uniquename="ibm.portal.Page Properties">
<parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
<parameter name="com.ibm.portal.ThemePolicy" type="string" update="set"><![CDATA[theme/SingleTopNav]]></parameter>
<parameter name="com.ibm.portal.bookmarkable" type="string" update="set"><![CDATA[No]]></parameter>
<parameter name="com.ibm.portal.friendly.name" type="string" update="remove"><![CDATA[pageproperties]]></parameter> <parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA]></parameter> <parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter> </content-node> </portal> </request>
<parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA]></parameter> <parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter> </content-node> </portal> </request>
<parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter>
twcornwe 0600025RJ4 Marcações:  unencrypted encrypted url login protected auto-login authentication secured sniff password 15.565 Visualizações
Login URL overview:
WebSphere Portal 6.0 and later offer the ability to login to the Portal using a specially crafted user of the following format:
A full example of this URL in use would be:
This URL does not bypass normal authentication mechanisms. The username and password are passed along the PUMA, WAS, and VMM/WMM layers as would occur with a normal login via the login portlet. Once authentication completes, users will be redirected to the first page which they have authorization to access (for example, the Getting Started page). The login URL offers a means of convenience for Portal administrators to bookmark their sites and automatically login each time. Other applications also make use of this URL; Rational Application Developer, for example, uses this same URL when invoking the Portal Admin Console. This login URL can also offer a potential means for Portal adminsitrators to access the Portal Admin console if unable to do so via normal means (i.e. the login portlet, theme, etc. are not functioning correctly). Namely, you can enter the following URL:
...which should in turn bring the Portal administrator to the Administration area without ever accessing the login portlet. There are many other uses of the login URL, and these example illustrate a few of the more common use cases.
Using the Login URL over the internet:
A STRONG warning should be given for the utilizing this URL over the internet. The existing URL by itself is unencrypted with the http protocol. Using software such as Fiddler (http://www.fiddler2.com/) or WireShark (http://www.wireshark.org/), it is trivial to sniff the unencrypted http URL and thereby obtain a valid username and password into the Portal system. Therefore, it is recommended to secure this URL if it will be sent over an unsecure network (such as the internet) prior to arriving at the Portal server.
Although there are means to force the WebSphere Portal login portlet to use a secureURL when authenticating users, that same option is not available for the login URL. The login URL can be encrypted with SSL security. However, if this is enabled, then the entire Portal site must also be enabled with SSL, which may not be desirable. If utilizing a web server to access the Portal, such as IBM HTTP Server, it may be possible to include a mod_rewrite rule to force this specific URL over SSL, while all other requests would be permitted over HTTP. However, note this should only be used as a failsafe. Meaning, if a user accesses the login URL over the internet, and accidentally sends the request over HTTP, then the username and password would already be sent in the clear prior to it ever reaching the web server and/or Portal server. The web server with the mod_rewrite rule could reject such requests over HTTP, but, the action would have already been committed and the username and password already potentially sniffed off the network. The web server can still act as a failsafe, but, the client-side must be updated to ensure the first request sent out is not sent out in the clear.
Therefore, if using the auto-login URL, on the client-side, whether it be via a web browser, a custom application, etc., be SURE to utilize the auto-login URL over SSL as a best practice.
Disabling the Auto-login URL
The automagic login URL may be disabled in Portal 8001 cumulative fix 12 or later, or, any version of Portal 8.5.. To do so:
i. Login to the WebSphere Administration Console
If you are not on one of these versions of Portal and need to block the auto-login URL, utilize a rewrite rule on your web server.
New to Websphere Portal Performance? Need to better review and understand all aspects of a javacore? Want to have meaningful discussions with L2 support on performance issues based on javacore and data collected?
IBM Research has created a new tool to enable you to review , troubleshoot and analyze performance issues regardless of expertise.
IBM Whole-system Analysis of Idle Time (WAIT) is a lightweight and powerful tool that can be used in almost any Portal or other Java environment. The tool is graphical and can be used by anyone, newbies and experts alike. You can determine the source of performance issueS, easily review call stacks and determine who wrote any piece of code in a portal call stack(WebSphere , Portal , WCM other IBM product or other third party entities)
There is an upcoming demo and discussion of the WAIT tool for Websphere Portal Customers on November 10, 2011
See the following document for more information on the event .
Customer Open Mic: The WAIT tool - Portal Performance Diagnosis and Beyond http://www-01.ibm.com/support/docview.wss?uid=swg27023208
You can review the tool at the following locations
Sneak previews here: http://snappy.watson.ibm.com/wait
External Site http://wait.researchlabs.ibm.com
twcornwe 0600025RJ4 Marcações:  security initialization script portal virtual initialize vp permision xml 6.970 Visualizações
*** Location of Virtual Portal Scripts
When you create the virtual portal by using the Virtual Portal Manager portlet, the virtual portal is pre-filled with default content. This default content is determined by the default XML script file for initializing virtual portals.
In previous versions of Portal, the Virtual Portal (VP) initialization xml scripts are stored on the file system in the directory ...//wp_profile/installedApps/<node_name>/wps.ear/wps.war/virtualportal. In Portal 7, the VP initialization scripts are located in a WebSphere Application Server (WAS) asset named VirtualPortal.zip. To get to this file, access a WebSphere Application Server administrative console, select Applications -> Application Types -> Assets, and locate the file in the list.
This VirtualPortal.zip file is physically located in:<wp_profile>/config/cells/<cellname>/assets/VirtualPortal.zip/aver/BASE/bin (in a stand-alone Portal environment)
<DMGR_profile>config/calls/<DMGR_Cell_name>/assets/VirtualPortal.zip/aver/BASE/bin (in a clustered environment)
In a migrated Portal v7 environment, as part of the migration process the virtual portal scripts are removed from the .../wps.ear/wps.war/virtualportal directory and moved to a WAS asset zip file named MigratedVirtualPortal.zip and is located in the .../VirtualPortal.zip/aver/BASE/bin directory as mentioned above.
*** WebSphere security role required
As the VP initialization scripts are now located in a WAS asset, WAS security comes into consideration when Portal class is accessing WAS services. As a result, if the user who attempts to create or initialize the VP has no proper privileges on the WAS, the task cannot access the XML file used to initialize the virtual portal and it will fail with the exception "EJPAH2012E: Can not find xmlaccess script".
This issue was reported under APAR PM39581, and a fix was released as part of Cumulative Fix CF006 for Portal 188.8.131.52, but unfortunately the WAR is not redeployed in CF06, CF07, or CF08. The WAR is properly redeployed in CF09.
Therefore, in CF06, CF07, or CF08 to take advantage of this fix, customers should manually redeploy the WAR by copying PortalServer/ap/wp.ap.virtualportal/installableApps/ManageVirtualPortals.war to PortalServer/installableApps/ManageVirtualPortals.war and then running the ConfigEngine.sh/bat deploy-portlet-upgrade-wp.ap.virtualportal
If you can not upgrade Portal to the later CF that includes this fix, you can workaround this issue by logging in to the IBM® WebSphere® Integrated Solutions Console (ISC) admin console as the WAS administrative user and giving the user who is trying to create or initialize the virtual portal the "Monitor" role, which is the minimum requirement.
* Steps to add "Monitor" role for a user:
- Go to: Users and Groups >> Administrative user roles >> Add
- Highlight the "Monitor" role in the Role(s) box
- Search for the user and select the user from the search results
- Click the "Add" button
- Click "OK". Then save to the master configuration.
- Restart Portal
After these steps, user should be able to create virtual portals using the Virtual Portal Manager portlet and to initialize the virtual portal created previously that failed to initialize.
This situation is described in more details in IBM Technote # 1469910
*** Migrated VP scripts vs. Fresh Install VP scripts Another issue that may occur in Portal v7 environment migrated from Portal v6.1 is caused by a missing Portal resource in Portal v7. The migrated VP initialization script may contain references to the "Manage Seed List" portlet, which has become obsolete in Portal v7 and will cause the script to fail with exception such as: "EJPXA0025E: The resource was not found in the portal, either because it does not exist or because you have not specified an identifying attribute in the XML input. [portlet <portlet_objectID> name=Manage Seed List]" The reason that these scripts are not updated during migration is that they are considered customer scripts. The scripts that ship with Portal just have the sample content and pages in them. So there is an assumption that the customer may have updated the scripts with their own pages and content; therefore, the migration process just moves these scripts untouched into the WAS asset VirtualPortal.zip in the target Portal v7 environment. To avoid this issue, * BEFORE MIGRATION: Remove those references to "Manage Seed List" in your VP xml scripts. For example, remove these lines: <portlet action="locate" name="Manage Seed List" objectid="<Manage_Seed_List_objectID"></portlet> And this: <portletinstance action="update" domain="rel" objectid="portletinstance_objectID" portletref="<Manage_Seed_List_objectID>" shareref="5_CGAH47L008DE402BK8543I18D4"></portletinstance> (The object ids, portletrefs, sharerefs, etc ... may vary in your installation.) * AFTER MIGRATION: If you have already migrated, use the WAS admin console to export the VirtualPortal.zip asset, update the VP initialization script as above, then re-import the asset. Refer to the section "Asset Collection" of the Websphere Application Server v7 Information Center for details on how to update the asset.
Another issue that may occur in Portal v7 environment migrated from Portal v6.1 is caused by a missing Portal resource in Portal v7. The migrated VP initialization script may contain references to the "Manage Seed List" portlet, which has become obsolete in Portal v7 and will cause the script to fail with exception such as:
"EJPXA0025E: The resource was not found in the portal, either because it does not exist or because you have not specified an identifying attribute in the XML input. [portlet <portlet_objectID> name=Manage Seed List]"
The reason that these scripts are not updated during migration is that they are considered customer scripts. The scripts that ship with Portal just have the sample content and pages in them. So there is an assumption that the customer may have updated the scripts with their own pages and content; therefore, the migration process just moves these scripts untouched into the WAS asset VirtualPortal.zip in the target Portal v7 environment.
To avoid this issue,
* BEFORE MIGRATION: Remove those references to "Manage Seed List" in your VP xml scripts. For example, remove these lines:
<portlet action="locate" name="Manage Seed List" objectid="<Manage_Seed_List_objectID"></portlet>
<portletinstance action="update" domain="rel" objectid="portletinstance_objectID" portletref="<Manage_Seed_List_objectID>" shareref="5_CGAH47L008DE402BK8543I18D4"></portletinstance>
(The object ids, portletrefs, sharerefs, etc ... may vary in your installation.)
* AFTER MIGRATION: If you have already migrated, use the WAS admin console to export the VirtualPortal.zip asset, update the VP initialization script as above, then re-import the asset. Refer to the section "Asset Collection" of the Websphere Application Server v7 Information Center for details on how to update the asset.
After creating or modifying a URL mapping in a virtual portal, users may no longer be able to access the virtual portal via browser, and administrators may no longer be able to successfully administer the virtual portal via XMLAccess. Such issue has been confirmed by IBM Support as a defect and reported via APAR PM47138. If you are using virtual portals in your environment, Support highly recommends installing cumulative fix (CF) 9 for WebSphere Portal 184.108.40.206 in order to prevent this problem scenario. For those users who already experience such an issue, there are two options for recovery:
1) Restore the Portal database from backup.
2) Open a PMR with IBM Support to request assistance in remapping the URL context to the virtual portal. Upon opening such PMR, the following database tables from database domain "release" should be provided for review by Support:
Note 1: The defect can manifest itself such that when you log into a virtual portal and navigate to the URL mapping portlet, you are unable to see the context root for your virtual portal. Thus, you are unable to create any URL mappings for the virtual portal via the UI since they need to be created as children of the context root. Any URL mappings you do try to create in this case get created as additional context roots and cause undesired results (e.g. redirecting to base portal) if you attempt to utilize them.
Note 2: A flash technote will be published today communicating this same information.
twcornwe 0600025RJ4 Marcações:  federate file-based security fileregistry.xml repository 5.417 Visualizações
WebSphere Portal 6.1 and later out of the box utilize a file repository in a Virtual Member Manager (VMM) federated repositories. During installation of WebSphere Portal, a prompt is given to create a new username and password. The username and password are created in the file repository and utilized by WebSphere Portal during runtime, and during installation/configuration tasks. When the system is ready to be configured to an enterprise LDAP, with a standalone LDAP configuration, the file repository no longer is available and only a single LDAP is available for use. With a federated repositories configuration, a file repository and one or more LDAP may exist simultaneously. A decision should be made as to whether to keep the file repository, or, remove it. In general, the recommendation is to remove the file repository.
Why Keep the File Repository?
The most common reason to keep the file repository is to have a location other than the LDAP to store the administrative users. In the event of an LDAP outage, the file repository would still be available and allow login to the WebSphere Application Server and/or Portal server. For these scenarios, we instead strongly recommend customers setup a database user registry with their Portals. The database user registries do not have nearly the number of limitations as do the file repositories, allow for a more flexible configuration of the system, and do not have nearly the performance penalty as do file repositories. More information on database user registries are available here:
Why Remove the File Repository?
In general, WebSphere Portal v6.1-8.0 recommends to remove the file repository in production systems:
"Note: It is not recommended to use the file-based repository in a production environment".
WebSphere Portal v8.5 and later require its removal in production systems:
"Only the database entry mapping repositories support the creation of a group with members that exist in repositories outside the database repository. If you use a Lightweight Directory Access Protocol (LDAP) registry, you can assign a member to a group within that same LDAP registry. Similarly, if you use a file repository, you can assign a member to a group within that same file repository. "
End Result: You may not have an administrative user in the file repository which belongs to an administrators group in the LDAP, and vice-versa.
"Client certificate login is not supported in a realm that includes a single built-in, file-based repository or a single built-in, file-based repository with other repositories."
Addendum: This is now supported with WAS 70023, WAS 8004 and WAS 8550 and later. More details available at this link:
End Result: This is a rare, but valid security configuration not available with the file repository.
"Changes to built-in, file-based repositories are not automatically replicated to managed nodes in a federated repositories configuration. You need to use the administrative console to replicate the changes you make to a built-in, file-based repository."
"If the WebSphere Application Server is installed in a clustered environment, then these files are distributed to all the cluster members based on the standard WebSphere Application Server configuration distribution mechanism. All the write functions occur only at the Network Deployment Manager (NDM) server, but the read functions are performed using the local file repositories."
End Result: You may not use "Edit my Profile" to modify users or their passwords in a File Repository. It must be done via the Deployment Manager console.
"The registry used by WebSphere is not the Active Directory domain LDAP, or Global Catalogue, but is some other virtual registry (for example, a file-based custom user registry)."
End Result: Administrative users in the file repository will not be able to use SPENGO if configured.
"You can configure only one LDAP repository under federated repositories, and that LDAP repository configuration must match the LDAP server configuration under Tivoli Access Manager."
End Result: Administrative users in the file repository will need to access the Portal server, rather than through TAM. Note, the same is likely true for other External Security Managers (such as Siteminder), as those ESMs typically do not have access to the users in the file repository.
"Note: Application groups only apply to WebSphere Portal; it does not apply to external security managers. Also, application groups is not supported when using the default federated repository with a built-in file repository."
End Result: If an administrative user exists in the file repository, it is not supported to make that user a member of one or more application groups. This is a WebSphere Portal specific limitation.
"The VMM file-based repository does not support search queries with multiple wildcards"
End Result: If searching for users in the Portal with multiple wildcard, e.g. searching for John Doe via Jo* Do*, such searches will fail. Both the file repository and LDAP will be searched with this query, and the query will fail on the file repository, causing the entire search operation to fail and have no results return to the end user.
RHEL bug could be problematic for Quickr 8.5 for Portal installations with a non-localized /home directory
As many of you are aware, Quickr 8.5 has the option to install DB2 along with server itself. Unfortunately if the /home directory is not local errors may appear after DB2 is being installed. They indicates that the 'qkradmin' user cannot run any db2 commands:
-bash: db2start: command not found
The only recourse is to install to a local /home directory until these duplicate RHEL bugs are fixed:
I will post more updates on resolving this issue as I get them
twcornwe 0600025RJ4 Marcações:  isc configuration disable remove unused applications 5.629 Visualizações
A frequent question asked is "WebSphere Portal ships with a lot of applications. But, I don't need all of those applications. Each of the applications takes time to start when the Portal server starts, and, consumes memory/CPU during runtime. How do I know which applications are required for the Portal server to function, and which are optional and can be safely disabled?".
For Portal 6.1.x, please see the following Technote: "How to disable unused applications in WebSphere Portal V6.1.x"
For Portal 70x, please see the following Technote: "How to disable unused applications in WebSphere Portal 7.0.x"
JMW98 2000000MY6 3.363 Visualizações
Many login performance issues turn out to be delays in resolving group membership. WebSphere Portal attempts to resolve group membership at each login. There are a few things a Portal administrator can do to make the process of resolving group membership as efficient as possible. Reducing the load on the LDAP is a bonus.
1. If your LDAP supports it, implement a membership attribute. Set the scope as broadly as your LDAP supports. Hopefully, the LDAP's membership attribute lists all of a user's group memberships (direct, nested, and dynamic).
Note: Be sure that any groups returned by the membership attribute can be resolved within the realm defined in VMM. Failures will occur if the membership attribute returns a group DN that VMM cannot look up.
2. Unless your application requires them, avoid using dynamic groups since resolving their membership exacts a high cost. If you need dynamic groups in your application, consider keeping them locally with this alternative.
3. If the membership attribute resolves nested groups, disable nested groups in Portal.
4. Configure a federated repository so that VMM resolves group membership during the WAS login process. Then configure Portal to reuse WAS group information (user management only, to maximize performance).
Note: You can reuse WAS group information even in a standalone LDAP configuration - I just like the VMM functionality for resolving group membership better.
There are some additional tweaks you can make with PAC caches, VMM caches, and context pooling, but these four items should help a great deal in resolving any performance delays in resolving group membership during Portal login.
Ordinarily all cache tuning information are found in the Portal tuning guides below at the bottom of the page . The documentation usually contain the recommended cache sizes and lifetime as well as how/where to set. WSSECUREMAP is not one of them . There is the description but not how to set it even though it must be stated you probably may not need to tune this cache often
Here is how and where to tune it
WSSecureMap is the DynaCache used for Security Attribute Propagation. This cache should be created with DynaCache default size of 2000.
The DynaCache default could be changed but that would affect all caches created with the DynaCache default.
1. If you wish to change only the size of WSSecureMap, you can use following 2 custom properties:
com.ibm.ws.security.WSSecureMapSize=X (X = desired size - positive integer more than 100)
Note that the specified size is used ONLY if the ...InitAtStartup property is also configured and set to true.
To set the property from administrative console page,
Click Security > Global security > Custom properties
Click New to add new custom properties and associated values as mentioned.
2. The lifetime of entries cannot be configured. Entries in this cache remain valid until the Subject contained in the entry is no longer
valid. This is usually the LTPA timeout which defaults to 2 hours. If you have any problem ( Ex: WSSecureMap is not working as expected)
If you have any issues with this cache, Open a support pmr with the Security Mustgather http://www-01.ibm.com/support/docview.wss?uid=swg21470063
Portal Caches information [http://www-10.lotus.com/ldd/portalwiki.nsf/dx/WebSphere_Portal_caches_%28Tuning_Guide_6.1.x%29]
Portal 7 tuning guide [http://www-10.lotus.com/ldd/portalwiki.nsf/dx/WebSphere_Portal_Tun]