Monday, November 21, 2011

Disabled Users in AD and WCI Portal

How to Prevent Disabled users from getting synchronized in Portal?
We recently stumbled upon a major issue with our Oracle WCI portal. We found that users who had long since left the company had their portal accounts present. The accounts were disabled but still they were present in the portal and therefore visible during searches.

Our initial thought had been that either there was something wrong with the AD or that our portal’s synchronization job was not functioning properly. However we spent some time with Google and came upon a very interesting thing. Microsoft’s AD has a limitation that you can define only one folder in your AD user query. I will explain this with an example below.



The normal structure of any companies AD looks similar to the one as below:






Now all users who work for the company are created under the Accounts folder. Now what happens when a person leaves the company? Yes, the account of the person is disabled and moved to a separate folder called Archive-Disabled. However this folder is a sub-folder of the Accounts OU folder in Active Directory.
The limitation I had mentioned earlier means that the User Query can point to one folder at a time and in our case it is the root folder called Accounts. You cannot make your user query point selectively to all folders under Accounts while explicitly not mentioning the Disabled sub folder.


Here are the original settings we had for our portal’s Authentication source and Profile Source.
Original Settings of Authentication Source
User Query Filter - (&(objectcategory=person)(objectclass=user))
Original Settings of Profile Source
User Query Filter - (&(objectcategory=person)(objectclass=user))


Microsoft AD has a work around for the issue so that even though your user query points to the root folder, it will look for a bitwise filter property which signals if the account is enabled or disabled. Then whenever the AD Synch and AD Profile Synch jobs will run, it will import only enabled users from the Accounts OU while discarding all disabled users from the OU.


Here are the modified settings:
New Settings of Authentication Source
User Query Filter - (&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
New Settings of Profile Source
User Query Filter - (&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))


The value 1.2.840.113556.1.4.803 is the LDAP_MATCHING_RULE_BIT_OR rule. After user query filter had been modified and the jobs ran, it worked as a dream and only enabled users were brought into the portal.


Just to let you guys know:
1.2.840.113556.1.4.803 - This is the LDAP_MATCHING_RULE_BIT_AND rule. The matching rule is true only if all bits from the property match the value. This rule is like the bitwise AND operator.
1.2.840.113556.1.4.804 - This is the LDAP_MATCHING_RULE_BIT_OR rule. The matching rule is true if any bits from the property match the value. This rule is like the bitwise OR operator.

Some more examples of AD filters that can be used as are follows:
Example LDAP User Filters
~ Default user filter:(&(objectCategory=Person)(objectClass=User))
~ Exclude accounts with no email address:(&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(mail=*))
~ Exclude disabled accounts:(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))
~ Exclude accounts with passwords set to expire:(&(objectCategory=person)(objectClass=user)(!userAccountControl=65536))
~ Include only the accounts with valid email addresses(&(objectCategory=Person)(objectClass=User)(mail=*com)
~ Include only the accounts that are part of the Branch1 organizational unit(&(objectCategory=Person)(objectClass=User)(memberof:1.2.840.113556.1.4.1941:=(CN=Authenticated Users,OU=Branch1,DC=domain,DC=local)))
~ Exclude accounts that don’t have a first name (&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(!givenName=*)))

PS: Thanks to Guru Geoff Garcia for helping me with this issue. :) :)

Tuesday, September 27, 2011

How to find PID in a Windows 2003 server?

Process identifier, or more commonly know as PID or process ID, is a unique number tagged with each processes running on a system.
As always the UNIX and LINUX blokes were intelligent and devised a commond ps to search for the PID of running processes. But unfortunately as always we belong to MS brethren and guess what we do not have any such easy method. So Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008 and Windows 7, there is no such utility or command available to get the PIDs.
In order to get to know, or view, retrieve and identify the process ID or PID of the processes running in Windows operating system, users or administrators can make use of Task Manager. However, Task Manager does not display PID information by default. To display the PID value in Task Manager, go to Processes tab, click on View menu, then click on Select Columns…. In the “Select Columns” or “Select Process Page Columns” dialog, tick and check the checkbox for PID (Process Identifier), and click OK.



If you are wondering why is this posted in my blog which has always been all about Portals

All BEA Publisher Portlets Down

This past weekend we had our servers rebooted after a patch maintenance and after that when the services were turned on, we noticed something peculiar. The portal was up and running but none of the Publisher portlets were working (HTTP 404 Errors) and neither was the Publisher diagnostic page opening up for us. Hoping something was wrong with publisher, we tried bouncing the Publisher server and then proceeded to do of all the servers in our portal environment…No go….Nothing…the portal page opened but the Publisher portlets were dead as a dodo :)
We opened up all the logs and ran the diagnostics…et all….but were not able to figure it out for quiet sometime….
The Portal Diagnostics bat file showed the following message:

===================================================
PORTAL_HOME=C:\bea\alui\ptportal\10.3.0Expected PORTAL_HOME=C:\bea\alui\ptportal\10.3.0Running Diagnostic Tool...OpenLog: verbosity level = 2 Diagnostic system initialization OK. Portal Startup begins: 15 total tasks.OpenLog: Registered application name: ConfigInitialization (local machine only)OpenLog: Registered application name: portal.sbymas096.svcwciadmin (local machine only)Base library name : openkernelsearch_4-3j
OpenLog native: Registered application name portal.sbymas096.svcwciadmin (localmachine only)Task #1 (InitPortalObjects) END (OK)Task #2 (CheckDevKit) END (OK)Task #3 (InitializePaths) END (OK)Task #4 (InitializeApplication) END (OK)Task #5 (InitializeAppWarmUpHelper) END (OK)Task #6 (InitializeImageServerHelper) END (OK)Task #7 (InitializeConfigHelper) END (OK)Task #8 (InitializeResourceManager) END (OK)Task #9 (LoadVersionHelper) END (OK) FATAL: Task #10 (InitializeActivitySpaces) step 2 failed to complete. InitializeManagers: Error initializing TagLibManager. LoadActivitySpace problem: managers will not load. RECOMMENDATION: Check that version.xml is located in the correct directory and is not corrupt.com.plumtree.openfoundation.util.XPException: Fatal error loading lib file taglibJoinCommunityPageEditor: Unable to locate Tag Library meta data. at com.plumtree.portaluiinfrastructure.tags.manager.TagLibManager.InternalLoadLibFile(TagLibManager.java:460) at com.plumtree.portaluiinfrastructure.tags.manager.TagLibManager.InternalLoadClasses(TagLibManager.java:400) at com.plumtree.portaluiinfrastructure.tags.manager.TagLibManager.LoadClasses(TagLibManager.java:327) at com.plumtree.portaluiinfrastructure.application.PTAppWarmUpHelper.InitializeManagers(PTAppWarmUpHelper.java:431) at com.plumtree.uiinfrastructure.application.startup.InitializeActivitySpaces.executeStepTwo(InitializeActivitySpaces.java:165) at com.plumtree.uiinfrastructure.application.startup.InitializeActivitySpaces.executeStep(InitializeActivitySpaces.java:108) at com.plumtree.uiinfrastructure.application.AppWarmUp.LoopStartupTasks(AppWarmUp.java:995) at com.plumtree.uiinfrastructure.application.AppWarmUp.RunStartupTasks(AppWarmUp.java:893) at com.plumtree.uiinfrastructure.application.AppWarmUp.Init(AppWarmUp.java:200) at com.plumtree.uiinfrastructure.diagnostic.DiagnosticRunner.executeAllTestsWithoutPause(DiagnosticRunner.java:127) at com.plumtree.uiinfrastructure.diagnostic.DiagnosticRunner.executeAllTests(DiagnosticRunner.java:138) at com.plumtree.diagtool.diagnostic_net.main(diagnostic_net.java:40)Caused by: com.plumtree.openfoundation.util.XPException: Fatal error loading lib file taglibJoinCommunityPageEditor: Unable to locate Tag Library meta data. at com.plumtree.portaluiinfrastructure.tags.manager.TagLibManager.InternalLoadLibFile(TagLibManager.java:434) ... 11 more
Task 'InitializeActivitySpaces' Failed on Startup Task #10 (InitializeActivitySpaces) Step #2--------------------------------------------------------------------------------
error: LoadActivitySpace problem: managers will not load.platform: Windows (Java)failure: FATAL: LoadActivitySpace problem: managers will not load.recommendation: RECOMMENDATION: Check that version.xml is located in the correct directory and is not corrupt.exception: XPException Fatal error loading lib file taglibJoinCommunityPageEditor: Unable to locate Tag Library meta data.
message: Fatal error loading lib file taglibJoinCommunityPageEditor: Unable to locate Tag Library meta data.secondary exception: at com.plumtree.portaluiinfrastructure.tags.manager.TagLibManager.InternalLoadLibFile(TagLibManager.java:460)--------------------------------------------------------------------------------
FAILED TO INITIALIZE SYSTEM. YOU CANNOT PROGRESS BEYOND THIS POINT. ======= Diagnostic Run Complete ======= Startup completion percentage: 62% (31 steps out of 50 complete) Diagnostic Test execution complete.Press key to exit.

==================================================================

Now if that was not confusing, the Publisher Container logs were even more confusing. However there is always light at the end of a tunnel :) Lets check what the container logs had in them
==================================================================

2011-09-26 02:05:38,032 83937 ERROR [WebModule] (main:jboss.web.deployment:war=ROOT.war,id=-89327743 WebModule) Starting failed jboss.web.deployment:war=ROOT.war,id=-89327743
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameNotFoundException: comp not bound)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:329)
at org.jboss.web.WebModule.startModule(WebModule.java:62)
at org.jboss.web.WebModule.startService(WebModule.java:40)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
……………………….
2011-09-26 02:05:04,220 50125 WARN [ServiceController] (main:) Problem starting service jboss:service=Naming javax.management.MBeanException: java.rmi.server.ExportException: Port already in use: 1098; nested exception is: java.net.BindException: Address already in use: JVM_Bind
at org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:91)
at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64)

==================================================================

The clincher was here. The port 1098 was already in use. Although at the time of first seeing this, I had overlooked this as it came under a warning message. But that’s how BEA Publisher works…lolz…the most important information comes in a warning, while the error message shows something which is too difficult to comprehend…. :)
Anyways…we then found out that BEA Publisher uses the concept of ephemeral ports. The port 1098 is an ephemeral port which BEA Publisher needs for some time when the service is restarted. However BEA Publisher does not reserve this port 1098 exclusively for itself. As a result it might happen that port 1098 is gobbled up by some other application running on your machine……

Solution:
We used NETSTAT command to find out if port 1098 is free or not. As it turned out, port 1098 was indeed not free and being used by some other application running on the server. Once we found it was in use, we found out the PID associated with the process and using the Task Manger killed the process corresponding to the PID. Thereafter a restart of BEA ALI Publisher service resulted in Publisher starting up correctly.

Friday, March 18, 2011

Bypassing SSO while logging into portal

A nifty trick I found out.....Okies...I am not an expert...so probably everyone knows about it but still there might be someone out there who might not know this....

This ones dedicated to all Portal Administrator's .......Remember the times when you have to work on VPN which has SSO enabled in it...as a result when you login into the VPN....the same credentials are automatically used for logging into the portal......thereby removing the intermediate step of entering login credentials for accessing the portal.

Here's a nifty trick I learned yesterday which will bypass this SSO and force you to enter your login credentials....Just type in space=Login at the end of your .pt URL... (The L of Login should be in upper case)
For example the normal URL for accessing my sandbox is http://mavericks/portal/server.pt
Just append at the end so that the URL looks like http://mavericks/portal/server.pt?space=Login

This is especially useful when you are testing out some changes in the portal using a different login but the damn SSO...automatically logs using your account as soon as you type in the URL. This nifty trick should work fine in these situations....

Njoy!!!!!!

Monday, February 7, 2011

Customizing Default WCI Error Messages

Hi there...long time no see......No i wasn't busy...just plain simple lazy as usual :)

Recently, i thought of doing some experimentaion on the custom error messages coming on our 10gR3 portal. Some of the error message pop ups which come up are pretty bare and give you absolutely nothing. So in order to make things interesting....we decided to make ammends to some of the default error messages.

All of the values are stored in XML files and can be changed pretty easily. The location of the default error messages is as follows:

*******************************************
Drive:\bea\alui\ptportal\10.3.0\i18n\en
*******************************************

We did some neat things here, unfortunately the funny ones were discarded.
Sigh!!! So much for some fun ;-)

Monday, October 18, 2010

Stubborn Publisher Cache

So you have been working on BEA Publisher and you face that issue, which I think everyone faces with Publisher……the dreaded Caching of content. It is evil my friends. Evil because, Publisher has the habit of caching content and displaying this content. While this is good on some occasions because it helps in faster page load, however, when you are working on some portlet and want to immediately see the effects of your change, this same boon becomes your bane.
Recently I was working on this and found out some tips which can provide relief from the caching content of Publisher.

This is a 2 step process:

Step1: The easiest way is turn off caching in the Publisher WebService.



In the HTTP Configuration page of your Publisher Web Service, look for the Gateway Caching section present at the top of the page. Make both the Minimum Cache Time and Maximum Cache Time as ZERO seconds. Don’t forget to un-check the check box for Suppress errors where possible, so that it is blank.
Click on Finish and your Publisher portlets will no longer show cached content. However do take note, that you should keep a record of you Min and Max Cache Times and restore them once your work is completed, otherwise you are gonna hear a lot of complaining that portlets are taking a long long time to load in the page.


Step 2:
While the Step 1 above works every time, there is one other thing which you can do to make absolutely certain that no cached content remains anywhere. This step needs access to the server on which BEA Publisher 6.5 is installed.
The steps to perform are as follows:
~ Log into the server where BEA Publisher is installed
~ Stop the Publisher service running on that system
~ Search for the folder named localhost in the ptcs installation directory. Normally it will be found like D://BEA/alui/ptcs/6.5/container/work/jboss.web
~ Delete the whole local host folder
~ Restart the Publisher web service once again (The localhost folder will be re-created once again)



Monday, August 2, 2010

Oracle WCI Webinars for Download

Oracle has started recording thier Webinars and even allowing for some of their webinars related to Oracle WCI Portal to be downloaded now.

The Oracle WebCenter Interaction support team will post links to new webinars in this article as they develop them. These can be accessed from the below URL:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ANNOUNCEMENT&id=1114631.1