Archive for March, 2011

Customize IIS error pages to augment WIA authentication

Wednesday, March 30th, 2011

When you configure SSO (Single Sign-On) in the WCI portal, you’re basically telling the portal to redirect to the /portal/sso/SSOLogin.aspx page, and configuring your SSO product to “protect” that page.  I could write volumes about this topic – and probably will at some point – but for this post let’s consider Windows Integrated Authentication (WIA).

The trick to configuring Windows Integrated Authentication for the portal is to enable Integrated Windows authentication on the “sso” folder like this:

This allows IIS to authenticate the user and pass the username to the portal through the portal session.  But, if the user can’t authenticate for some reason, they may see a screen like this:

While I’ll call out a portal bug any day of the week, this isn’t one of them: the portal is doing exactly what it’s supposed to, and in this case that is NOTHING.  The above error comes from IIS, and the portal never even sees the request to take action on it. [side note: in my last post, I mentioned working on a WebDav fix for Collab; it's looking like the problems with Windows 7/Office 2010 aren't Collab's "fault", but - like this issue - are the fault of the application server handling the requests.]

Now that we’ve established the issue is with IIS and not the portal, the “fix” is pretty straight-forward.  Just craft a custom HTML error page that redirects the browser back to the portal with this code:


… then, configure IIS to use that error page when the unauthorized message is generated:

This way, if IIS can’t authenticate the user, instead of presenting the error page, it’ll send a redirect to the browser to bounce back to the portal – which will know that it’s already attempted SSO and just present the user with the forms-based login.

Java 1.6.0_24 Breaks Collaboration Server Bulk Upload

Thursday, March 24th, 2011

If you, like me, were foolish enough to upgrade your Java Runtime Environment to 1.6.0_24 (I mean, REALLY, who DOES THAT!?), then you’ve likely found that Bulk Upload (and possibly WebEdit) no longer work in WCI Collaboration Server.

Why?  This post by gimble2 about sums it up:

Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn’t be surprised if Oracle takes the policy of security first, compatibility second.

Indeed, this is a big problem because Java 1.6.0_24 lies to users:

Unrestricted Access, huh? Bullsh*t.

You can confirm this by viewing the Java Console when trying to run Bulk Upload:

There you’ll likely see an exception like this:

Java Plug-in 1.6.0_24
Using JRE version 1.6.0_24-b07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Administrator
Exception in thread “Basic L&F File Loading Thread” access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
Exception occurred during event dispatching: access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
at bulkupload.BulkUploadApplet. chooseFiles(
at bulkupload.BulkUploadApplet. access$100(
at bulkupload.BulkUploadApplet$ (

at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$ Source)
at java.awt.EventQueue$ Source)
at Method)
at$1. doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at Source)


Bug Blog 10: NTCWS doesn’t work with .NET 2.0

Tuesday, March 22nd, 2011

Today’s post is a quicky:  if you are installing WebCenter Interaction NTCWS (NT Crawler Web Service), you can test the service by navigating to http://NTCWSSERVER/ntcws/ContainerProviderSoapBinding.asmx, and you should see something like this:

If you get something like this, though:

Server Error in ‘/ntcws’ Application.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: The configuration section cannot contain a CDATA or text element.
Source Error:
Line 37: <appSettings>
Line 38: <!– 4.5WS Portal or not? Effects clickthrough and admin preferences. Acceptable values are 1 and 0. 0 implies a 5.0+ portal. –>
Line 39: 0

… you’re likely running the service with .NET 2.0 instead of 1.0.  The simple fix is to update ntcws\10.3.0\webapp\ntcws\web.config and change:

<add key="Is45Portal" value="@IS_45WS_PORTAL@">0</add>


<add key="Is45Portal" value="0"/>

Happy crawling!

Office 2010 WebEdit Corrupts Document Downloads

Friday, March 18th, 2011

We’ve now discussed why Office 2010 doesn’t work with Oracle WebCenter Collaboration Server, how it can be patched, and even the enigmatic post about Office 2010 document formats.  So we know that Office 2010 WebDAV can work with Collab.  But even though the Apache/AJP hack fixes WebEdit for Office 2010, unfortunately it breaks something else.  Specifically, when you close a document that you’re “Web-Editing”, Office 2010 sends the file back to Collab, and it doesn’t seem to include a Content-Type header (damn headers…).

Because Collab isn’t told what the Content Type is, it has to guess, and as mentioned, the Office 2010 document format is a .zip file that contains XML.  What ends up happening is that, after a successful WebEdit operation, if you try a simple download of that document in the portal, you get a .zip file with all those .xml docs in there.  This threw me off for a bit, thinking that the original document was lost to this crazy .xml file.  But, once I realized that renaming the file to .docx and opening in Word 2010 still worked, it was clear the problem was with the MIME type of the document, not the bits themselves.

This is good news – it means that Collab’s not really broken, but Office 2010 is sending the wrong Content Type when the document is closed (strangely, this happens when the doc is closed, not when it’s saved), and Collab is recording that Content Type to its CSFILES table in the database.  Specifically, the ContentType field in the CSFILES gets set to text/xml; charset=”utf-8″:


The best fix (hack?) I’ve found here is to create a trigger on this table to cancel out any changes that set this content type to that value.  In other words, the MS SQL trigger looks for the value of “text/xml; charset=”utf-8″” during and update, and if it’s there, the trigger rolls back the value to the original value.  As usual, proceed at your own risk, and while I can’t foresee any problems – even when uploading XML files to Collab, which are likely to have a different Content Type – this is a high-risk DB update that Oracle definitely won’t support.


Microsoft Office 2010 (.docx) files are .zip files

Wednesday, March 16th, 2011

Sit back and let me rap atchya, slinging some factasms about the Office 2010 document format (.docx, .xlsx, .pptx).

You’ve no doubt been using Office 2010 for a while and saving files with those new formats that don’t work in Office 2007.  Those .docx, .xlsx, and .pptx files are part of the Office Open XML file format.  What you may not know is that they’re actually ZIP files.  Really – try taking any .docx file you’ve got and adding .zip to the end – it’s a .zip file:

Who knew, huh?  More importantly, what’s this post doing on a Plumtree bog?

If you’re planning on using WebEdit with WCI Collaboration and Office 2010, it’s a very important nuance, because yesterday’s Collaboration WebEdit Hack isn’t going to be practical without this nugget of knowledge.

A fix for WCI Collaboration WebEdit using Office 2010

Tuesday, March 15th, 2011

As we saw a couple days ago, WebCenter Collaboration Server doesn’t work with Office 2010. The problem is rooted in the fact that WebDAV calls to Collab from Office 2010 aren’t strictly RFC-compliant because they’re missing a Content-Length header, and Tomcat rejects them because of that – even before Collab gets the HTTP requests.

Which got me to thinking: what if we could create an intermediate server that would add this header for us?   Then Tomcat would accept the connection and we’d be able to tell if Collab was able to “do its thing”. I started down the path of creating an Apache ProxyPass to do just this, when a friend and fellow Hak’er (Brian Hak) – who has been fighting his own fires with Collab these days – suggested that I try AJP. Even better, he pointed out, Collab’s default configuration settings allow you to turn this on by just flipping a switch; with it, we could then use mod_headers to add the Content-Length header.

Tip o’ the the hat to Brian for the AJP idea – it turns out that if Apache and AJP are handling the HTTP requests rather than Tomcat and its embedded web server, we don’t even need to muck with HTTP headers, as the request does NOT get blocked:

… and WebEdit (mostly) works in Office 2010!

I should warn you before proceeding: While I can absolutely say that WebEdit works in my test environment with Office 2010, .NET WCI Portal 10.3.0, on IIS 6, your mileage may vary, and I can’t guarantee this will work. I’ve found that Office 2007 has its own quirks – it works with the Collab Office Tools plugin in the ribbon bar, but not the out-of-the-box “save” implementation using Office’s own WebDAV calls. Perhaps that’s a post for another day, but early results show that while this hack doesn’t hurt Office 2007 support, it doesn’t seem to help either. Obviously, do extensive testing before even considering moving to a production environment.  Stay tuned for the next update in these pages, as there’s yet another database hack needed to make it fully functional.

Disclaimers out of the way, let’s dig in. Basically, what we’re going to do is:

  1. Install Apache Web Server on the Collab Machine, with the AJP plugin
  2. Configure Collab to accept AJP calls
  3. Configure the portal to send requests to Apache instead of directly to Collab (Tomcat)


WCI Collaboration Server Not Working in Office 2010

Tuesday, March 15th, 2011

I’ve blogged a LOT about Collaboration Server, and have spent countless hours fighting with the WebEdit features – it’s the “bane of my existence“, a term I used because I thought “crime against humanity” was a little too strong.  More often than not I’ve thrown up my hands and said “sorry, fella, nothing to see here – it just plain don’t work”.  The problem is there are a near-infinite number of combinations, between the different versions of:

  • Plumtree / ALUI / WebCenter Interaction Portal (6.1, 6.5, 10.3.0,, 10.3/Neo)
  • Collaboration Server (4.2, 4.5, 10.3.0,, 10.3/Neo)
  • Windows (XP, Vista, 7), plus various patches
  • Office (2003, 2007, 2010), plus various patches
  • Application Servers (IIS, WebLogic, Tomcat)
  • Web Browsers (IE7 and IE8 – good luck if you have IE9, FireFox or Chrome)

Officially, Oracle only supports the following for WebEdit with version – the latest publicly available version: MS Office 2003 on Windows XP SP2; MS Office 2007 on Windows XP SP2. No Office 2010, no Windows 7. Even Office 2007 is patchy at best.

I’d heard enough complaints, and decided to dig in and try to figure out why one very specific combination doesn’t work: Office 2010 running on Windows 7 against an IIS 6 .NET portal running WebCenter Collaboration 10.3.0.  Here’s what the out-of-the-box install shows when trying to save a file opened through WebDAV:

Your changes were saved but could not be uploaded because of an error.  You may be able to upload this file using the server Web page.

Having not accepted that it was impossible to get WebDAV working in Office 2010, I’ve spent countless hours reverse-engineering Office’s WebDAV protocol, WebCenter Interaction gateway calls, Apache Tomcat protocol handling, and everything in between.

Based on my research, this hack may be helpful for other versions of Office, Windows, and Collab, but I can’t even guarantee the hack I’ll discuss in the next couple of days is perfect, even with these very specific versions.  Proceed at your own risk, and drop me a line if you’d like to discuss your specific situation.


Try non-gatewayed WebEdit for better Collaboration WebDAV access

Sunday, March 13th, 2011

Last month, I posted a patch for the unsigned applets in WebCenter Collaboration Server. At the time, I said:

When your users click on the “More Information” link, you’ll see a message about Integryst asserting that the application is safe. That is true. But you’ll never hear me asserting that the application doesn’t suck.

That may have been a bit of an unfair jab – Plumtree Collaboration Server was a decent product in general, so let me refine the jab: as it evolved to ALUI Collaboration Server it remained a decent product that got the job done, even while showing its age as the years marched by. But WebDAV / WebEdit access in WebCenter Interaction is a complete mess – unless your end users are still using Windows XP and Office 2003. If they are, you’re in luck! The functionality merely “sucks”, which is much better than what I can say for your more modern users with Vista or Windows 7 using Office 2007 or Office 2010.

This tip is a simple and documented one: if all your users are on the corporate intranet and can directly access your Collab Server, you may get better results with WebEdit if you don’t gateway the requests through the portal. Just change “nonGatewayedAccess” to “yes” – and make sure your entire user base can access that URL (i.e., you’re not running an extranet where the Collab Server is behind a firewall).

<webEdit enabled="yes">
<nonGatewayedAccess enabled="yes">
<tokenBasedAuthentication enabled="true">
<useClustering enabled="no">
<installOfficeToolsPopUp enabled="yes"/>

Stay tuned for some even bigger news in a future post; with some extensive reverse-engineering of Microsoft Office’s WebDAV protocol implementation and Apache Tomcat’s HTTP implementation, I’ve gotten WebEdit and WebDAV working for Office 2010 on Windows 7. There are some side effects that I’m working through as we do some regression testing but I’m pretty confident we’ll have a solution ready soon for using Collab WebDAV with modern versions of Windows and Office. Drop us a line if you’d be interested in testing out the solution.

WCI Collaboration Search Server re-indexing

Thursday, March 10th, 2011

Oracle’s Upgrade Guide for WebCenter Interaction Collaboration Server include “Rebuild the Oracle WebCenter Collaboration search collection“.

A while back, I ran into an issue where the rebuild process was spiking the CPU on the Collab Server at 100% forever (which, I suppose, is more of a plateau than a spike).  In viewing the PTSpy logs, I saw hundreds of thousands of messages that included this SQL statement:

select * from csIndexBulkDeletes where status = 1

Checking that table, I found over 110 MILLION rows. Which is particularly odd, given that this client only had 42,000 Collab Docs. Now, I have no idea how the table got that enormous, but it’s clear that Collab’s Search Rebuild process uses that table to determine which documents to update, much like the Search Update job uses the PTCARDSTATUS table – which, incidentally, can also get messed up.

It was clear that if the search rebuild process goes haywire, Collab starts queuing up search server updates in this table, and if the table gets too big, cascading failures start to occur where the queue grows faster than it can get purged.

The solution is: before starting the Collab Search Re-index process, clear this entire table, which is rebuilt during the re-index process anyway. To do so, just run:

truncate table csIndexBulkDeletes

I should note that this isn’t all that common, as I’ve only seen it once, but at least now you know one possible solution if your rebuild process can’t seem to gain escape velocity.

WCI Community Cache-building woes: Give Everyone access to your headers

Sunday, March 6th, 2011

A year ago (wow – time flies!) I promised to elaborate on some other causes of the “Error displaying Dropdown menu tabs” error in WebCenter Interaction headers (which didn’t seem to affect the Plumtree or ALUI versions that predated it).

Well, it’s time to do some more ‘splaining: In most cases I’ve seen, this has to do with the fact that the current user (guest or authenticated) doesn’t have at least SELECT access to the header portlet.  So, if you’re just looking for the executive summary of this post, the first thing to check is whether EVERYONE has at least SELECT access to the header portlet.

Ms. Cooper (my made-up 8th grade algebra teacher) always told me: “Show your work“.  Hell, even if I got the right answer the old bag would still dock me points if I didn’t.  [Before you get offended, note that I can say that because Ms. Cooper is a figment of my imagination - I have great respect for the entire teaching profession and especially every teacher I've ever had that wasn't made up.  I would never refer to any of them as an "old bag".]

So, let’s show the work: