Recently in Collaboration Category

Here's a little feature that some of you may find useful:  Collaboration Server 4.5 can send you an email if it can't connect to the new Notification Service.  For those of you that have countless problems with the old Notification Server that shipped with Collab 4.2 and earlier, this is a must-have feature.

Just go to Administration: Select Utility...: Collaboration Administration: Collaboration Notification, and enable Health Monitoring:

It works, too (assuming your SMTP server doesn't require authentication for internal addresses).  Collab is even kind enough to mark the mail as "High importance":

On the other hand, for those of you that don't appreciate this new little nugget of functionality, consider this irony:  Collaboration 4.5 uses email to tell you when email is broken.  Cosmic, man.

STILL working on Collab 4.5 RSS feeds...  Today's tip will either be completely useless to you, or save you a ton of time.  If you ever see the following error:

collab.server.administrator CNS.SECURITY com.bea.notification.security.SecurityManager
Unable to authenticate user with token '1|1288135304|xarwmCj1FbIzv/Mo/yyd0tEjkgI='

Don't bother looking at the Security And Directory Service (really, what's that thing for anyway?). The following screen shot explains it all:

Open your portal database, query PTSERVERCONFIG ("select VALUE from PTSERVERCONFIG where SETTINGID=65"), and stick that value in the "Message authentication code seed value" field on the "Aqualogic Notification Service"/"Login Tokens" page.

Maybe when I'm much less annoyed at this whole process I'll dig more into the SAML2 Token Type.  And that elusive "Security and Directory Service", which still seems to provide no more valuable service than being a red herring for bizarre portal issues. 

In my (seemingly) never-ending quest to get Collaboration Notification working with 6.5, I ran into yet another error resulting in a ridiculous amount of diagnostic work.  The good news is that the error I was running into was a simple self-inflicted problem.  The bad news is there is an amazing lack of documentation about how the new Notification system works with Directory Services (the "BEA ALI LDAP Directory" service in Windows).

Here's the general premise to ALI Directory Services: ALI 6.5 ships with this new Directory Services component that provides an LDAP service for Portal User accounts.  The idea is that historically, the portal has been great at synching users from external repositories (from AD, LDAP, or custom sources) into its own database. Once those users get synched and aggregated into the portal, though, they're not exposed to any other services.  Directory Services aim to resolve that problem: 6.5 provides an LDAP server that uses the industry-standard LDAP protocol to expose users that have been synched to the portal.  So any other system can use LDAP to get user information.

Fantastic feature, right? But with the dearth of documentation out there, what may not be immediately obvious is that this Directory Service is also used by internal components such as the Notification Server.

I've only begun to scratch the surface with how all these components work together, but if you're interested in reading about how they DON'T work together (saving yourself hours of diagnostic time), hit the jump.

I mentioned the ALI Interoperability Matrix (login required) in the Publisher 6.5 post, and realized that I don't always go to the official site to check compatible versions of the Aqualogic stack; instead I just use a locally saved copy because it's quicker to pull up. 

Obviously, the locally saved snapshot can get out of date over time, but it's nice to have when you need it in a pinch (having been on sites that don't allow you to connect to their network).

If you want an Excel copy of the matrix, you can download it here.  Keep in mind it's only current as of the end of August 2008, but for prior versions of the portal, the information should be pretty static. For the latest version, visit one.bea.com (while it lasts).

All right, admittedly, this is a little more low-level tool than we feature here, but I use this tool all the time and it proved indispensible in diagnosing the issue in my last post.  The tool is called FileMon, and is hugely valuable for diagnosing "File Not Found" or "File Permission" issues.  I've used it with Visual Studio when it claims it can't find a DLL, the portal API when I get weird file version exceptions (particularly with Search Server), and in the most recent case where Notification Server claimed not to be able to find a file.

Basically, the tool reports on every single file access and which Windows process is making the request.  As you can imagine, this produces a LOT of noise - Windows is constantly accessing hundreds of files from dozens of processes, but fortunately, FileMon provides some robust filtering to help you find what you're looking for.

Let's take an example from the use case in my last post: figuring out why I'm not getting notifications.  All I had to go on was this exception:

Hm... can't find a file in "/plumtree/collab/templates/"?  But where is it looking for that file?  I know these templates used to exist in /ptnotification/4.2/settings/templates, but /ptnotification/ doesn't exist anymore.  And they're not in the /cns/ directory OR the /ptcollab/ directory.

Join me after the link for the solution!

On my journey to get ALI Collab Notification working for us again, I came across this little gem: as far as I can tell, ALI Collab Notifications are broken out of the box when using IIS 6 (or 7) because of IIS's infinite security wisdom.

I just couldn't get Collab Notification working, so I fired up PTSpy and saw this ("Unable to retrieve the template named '/plumtree/collab/templates/NotifyLinkNotificationText.nst'"):

Through a long and arduous process (more on how in my next post), I found this out:

The 6.5 Notification server uses the image server to store notification templates in bea\alui\ptimages\imageserver\plumtree\collab\templates.  (You remember notification templates, right?)

This is interesting; ALI has really gone in the direction of making everything "remote" (remember, Adaptive Layouts are remote so they're easy to edit and access in a central location). 

But if you're using IIS as an image server, you're in trouble.  Hit the link to find out why!

Hm.  I was planning on doing a quick post on the new RSS feed in Collab 4.5 / Portal Notification Server 6.5, but apparently this is turning out to be a real pain.  We did our portal install as an in-place upgrade (which is bad; again, more details on 6.5 upgrades will come in the near future), and pretty much have a completely munged install with both bea\alui\ptnotification\ and bea\alui\cns (the new notification service in the portal) folders, multiple notification services, and things stepping all over each other (starting the CNS service starts the old notification service).

So I did a reinstall of these components (Collab 4.5 and the Portal 6.5 notification service) and have a couple of tips to share in the upcoming posts.

First, remember to import those PTEs!  I got the following error in Collab ("HTTP Status 400: Invalid path /tasklist/ was requested") when I first started everything up, and clicked the RSS button in a Collaboration project:

Turns out this was because PTSpy was reporting something about Notification Server not being able to "load the Notification Web Service ID".  Once I imported the ALI Notification Service PTE file (bea\alui\cns\1.0\serverpackages\notification.pte) and restarted the service, I got this error cleared up.

But this was just the start of my problems.  Stay tuned for more on getting RSS working in Collab.

Oops - looks like this one slipped past QA:  Collab 4.5 ships with "INFO" set as the logging threshold, which isn't that much of a problem in and of itself (aside from giant log files being generated).  But when INFO is turned on, Collab actually records the UNENCRYPTED password to the ptcollab\4.5\settings\logs\wrapper.log file:

The authentication ID and the DB password are both written out to the file.  Obviously this isn't a critical security hole (if a malicious user has access to your system, you've got other things to worry about), but a concern nonetheless.  Until the issue is resolved, I'd recommend just upping your log threshold to WARN by modifying the \ptcollab\4.5\settings\config\wrapper.conf file.  Change:

wrapper.logfile.loglevel=INFO

to:

wrapper.logfile.loglevel=WARN

Well, Oracle's gift keeps givin':  First, they published unlimited license keys for all ALUI products, and now, they've release maintenance packs for everything with all the licensing stripped out completely!

Go Oracle!

Update June 9, 2008: Sorry ladies and gents, I just spent the day trying to upgrade our dev environment here.  After downloading hundreds of megabytes worth of installer packages that wouldn't even open in Winzip, I tried again and was able to open them.  Sadly, they (at least Publisher and Collab, and I assume the rest of them) still required license keys.  I suspect what happened is that whovever uploaded the real updated installers didn't FTP them as binary files (which would corrupt the files), and they rolled back to the original versions today.  I'm sure it's coming, but I was also a little disappointed in this false start...

Update June 10, 2008:  OK, my fault.  The link above makes it pretty clear that the delicensed products are on Oracle's download site and not available through BEA's download center.

My love for e-licensing at BEA, or lack thereof, was no secret.  I was mostly appalled as an employee when I was working at client sites - who completely trusted me with administrative access to their servers - and tried to get a license key.  Often this process took days, and occasionally took weeks.  In fact, we've got a client struggling with trying to wrangle legit keys from eLicensing now, who didn't even know that that particular product (Analytics) even HAD keys!

Well, no more.  The wicked witch is dead.  The clouds have parted.  Angels are singing.  Oracle has released generic license keys to legitimately licensed customers.

Now, people, I'm not saying this gives everyone free reign to steal Oracle products or use them in ways they're not licensed for.  I have no idea what Oracle's new licensing scheme is - particularly around using instances in development and DR environments (a common sore point with license keys) - so be good with these things.  I understand Oracle focuses more on customer audits than oppressive licensing schemes, so make sure you stay legit - contact your sales person if you've got any questions!

Without further ado, you can download the generic ALI keys here. 

Use them responsibly - our customers always maintained compliance at Plumtree without the keys, and I'm sure you all will again (well, I guess they did: I was just a consultant - what do I know?).