Archive for the ‘Collaboration Server’ Category

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.

New Collaboration Server IE8 Critical Fix – No Source for you!

Sunday, February 27th, 2011

Last month, we wrote to tell you about the WebCenter Interaction Collaboration Server IE8 Critical Fix.  Last week, an old Plumtree pal dropped me a line to let me know that this patch has been updated (Thanks, Eno!).  No new version information – it’s actually the exact same patch number and everything – although some of the code has changed a bit. As far as I can tell in analyzing the different packages, there are just a couple of tiny tweaks, and the release notes include a more comprehensive set of bug fixes, so you’ll just have to download the patch again to get the new binaries.

  • WebEdit does not work on IE8. (9723488)
  • Error in task submenu in IE8 (9712774)
  • Cannot upload multiple files in Collab (9274372)
  • Bulk upload JRE updated to 1.6 in order to support IE8 (8760280)
  • Notifications should be sent from a fixed address for creation and deletion (9647426) This fix involves updates to both collab and notification components.
  • Subscription to project overview causes conflicts with Immedate Subscriptions (8759642)
  • Non gatewayed webedit does not work (9434805)
  • File leak in Search Service during search index rebuild (11726008)
  • Webcenter Collaboration notifications to large numbers of recipients fail (9484113)

Oh, and while I never got around to writing a post about this, for those of you that are into this kind of stuff, this update includes a new cns.war file – and someone in engineering has removed the .jars containing some of the CNS source code.  So if you want to take a peek, check out the code in your cns.war before updating.

Guess you’ll have to find some other way to meet your code analysis needs

Collab Office Tools – “Don’t Show Again”

Monday, February 7th, 2011

When working on self-signing the Plumtree Collaboration WebEdit applet to prevent the certificate warning, I had to install WCI Collaboration Server on my server.  As I usually do, I made a backup of the collab folder, ran the install, and used Beyond Compare to diff the results.  Interestingly, I found this little gem in the collab.war file in /docman/editor/officeToolsInstall.jsp:

Wha-?  Why would 10.3 have a cookie expire on 1/1/2020, and have the same cookie expire on 1/1/2010?  Who knows, but what it likely means is that te “Do not show this again” checkbox in the Collaboration Office Tools popup will never work, because it’s setting a cookie that’s perpetually expired.

The solution?  Install that Collaboration Server IE8 Critical Fix, or just crack open the .war file and update /docman/editor/officeToolsInstall.jsp to use 2020 for the cookie expiration date.

WCI Collaboration Hotfix and Certificate Warnings

Thursday, February 3rd, 2011

While this blog isn’t the de-facto source for Oracle WebCenter Interaction critical fixes, we’ve tracked a big chunk of the latest hotfixes – including the more recent Analytics update and Collaboration Critical Fix for IE8

I’ve done a couple of installs with this Collaboration IE8 fix, and although I still haven’t seen Bulk Upload or WebEdit really get bullet-proof (frankly, WebEdit in particular is the bane of my existence), one thing is certain with these updates:  Oracle updated the code-signing certificate for the Bulk Upload applet in the latest critical fix, but never bothered updating the WebEdit applet.

What does this mean?  Well, when you’re uploading files with the Bulk Upload applet, you get a message that the certificate has been validated by a trusted source:

But, whenever you load a page with Collaboration portlets on it, the WebEditControl applet loads (more on this another time), and you get a signature warning that says “The digital signature was generated with a trusted certificate but has expired”:

Oracle’s official stance can be summarized thusly: “Pfft, what’s the big deal, anyway?  Suck it up or fix it yourself.”.  OK, so while I took some liberties with my paraphrasing there (sorry Oracle!), I went with option two: self-signing the WebEditControl applet.  It’s a non-trivial exercise, and all you get out of the deal is a nice clean prompt without the warning, but I’ve heard enough inquiries about this warning so I figured I’d just fix it:

The best part for you?  You can save yourself the huge pain of getting a code-signing cert, and download the Integryst-signed .jar file after the break, and say goodbye to that signature warning! (more…)

Collaboration Critical Fix – IE8 Support

Friday, January 14th, 2011

Now that Internet Explorer 9 is (almost) out, Oracle has gone and thrown us a new update to WCI Collaboration Server to finally support IE8.  Well, to be fair, this was released last October.

The patch does have some mixed messaging about what “officially supporting” means:

From the release notes: “The application of this patch updates Collaboration to officially support Internet Explorer 8.“.

From the Oracle Support Site, though: “Not every issue that has been identified when using IE8 with Oracle WebCenter Collaboration has necessarily been addressed by this patch.  A specific set of defects discovered in testing and resulting from customer feature requests were deemed the “essential” fixes required to establish a baseline of support for the browser version. 
If you experience issues other than those resolved by the patch, the fact that IE8 is now “Fully Supported” once the patch is implemented means that you can log an SR with support who can than verify the defect and log an appropriate bug tracking ID. 

It does have some pretty decent fixes, here, though, and I recommend this patch – I did some source analysis on the new version and did find quite a few changes in this new build – particularly around the Bulk Upload functionality:

The patch can be downloaded here; A copy of the Release Notes is after the break for your convenience…