Monthly Archives: July 2009

A Family Feud

“A feud is this way: A man has a quarrel with another man, and kills him; then that other man’s brother kills him; then the other brothers, on both sides, goes for one another; then the cousins chip in — and by and by everybody’s killed off, and there ain’t no more feud. But it’s kind of slow, and takes a long time.”
– Adventures of Huckleberry Finn: Mark Twain  

Perhaps given the nature of a lot of recent banter, without knowing a lot of what is going on in the background — my somewhat simple and perhaps naive suggestion would be that those parties directly involved set up a face to face meeting. Given that we have so many electronic mechanisms to express our opinions – blogs, tweets, IM’s etc. that can be misconstrued, maybe what is really needed is a good old fashioned sit down with food and beer so that all parties can sort out their differences, or at least agree to go back to the perspective corners without malice. So many of the individuals involved seem to have been colleagues and friends for so long, why not sort this out in person? Otherwise this may be a slow, slow burn. Wouldn’t you rather spend your time and energy focused on what we in the yellowverse have come to expect – collaboration and innovation?

“It takes 20 years to build a reputation and 5 minutes to ruin it. If you think about that you will do things differently.”

-Warren Buffett

A poll: How do you authenticate to iNotes and web-based apps?

I’m getting ready to update our HTTP login processes and I thought I’d post a few questions regarding how other sites authenticate to Domino for HTTP.

  • Do your users authenticate via the HTTP password in the Domino Directory?
  • Or do they use an LDAP password and if so do you use a Domino LDAP server or another LDAP server (what type)?
  • Do you use the Domino Web Access Redirect database for your login front end? Or have you developed your own?
  • If you use the Domino Web Access Redirect, do users login to each server or do you use a central DWA Redirect along with SSO?
  • Is your HTTP environment clustered?
  • Do you use a load balancer and if so what flavor/type?

In our environment, our users authenticate with a central userid that matches the shortname in the Domino Directory.  The central userid and password are stored in our corporate LDAP (Novell edirectory).  We use a pair of Websphere EdgeServers to load balance HTTP processes, including a pair of clustered Domino servers that serve as a central point for all iNotes authentication.  Because we have so many Domino servers (more than 50), having one central point of authentication was easier for our users to remember and simpler for us to maintain.  We have modified the Domino Web Access Redirect template somewhat to manage this process.  All and all this works very well with Domino SSO (we also connect to Sametime with iNotes too!).

I’d be happy to post more details if anyone is interested.  Don’t hesitate to share your own configurations and experiences!  Thanks!

Google Apps – Try it before you buy it…my two cents…

I was counting to a thousand this morning trying to decide if I was going to launch into a response to the commentary today about reasons to move to Google Apps.

Well….having moved users to Google Apps myself.  I would pose the following to those who are considering it.

1.  Try it before you buy it.  If you are a Enterprise customer – set up a pilot configuration.

2.  Read the feature fine print and have your legal department read the contract fine print.  Negotiating the contract with Google may take several months.

3.  Remember that web systems are dependent on the network, and when the network is down Google is down.

4.  The cpanel console for managing users is primitive – columns do not sort.  Searching only works to a limited degree – especially in large domains.

5.  Account create processes are threaded.  And recently we have seen an increasing number of failures (perhaps as the Google domain gets busier?).

6.  For Enterprise customers – everything extra costs extra.

7.  Changes to the Google mail interface will take place whether you want them to take place or not.

8.  Privacy settings are not granular for users — settings are basically all or nothing.

9.  There are attachment limitations — read the fine print.  Can you live with only 25 Mb attachments?

10.  Migration tools — again read the fine print.

11.  Authentication and SSO are not as straightforward as you might think.  If you configure SSO, be aware that IMAP/POP may require another password set as they do not synchronize.  And Google does not authenticate with LDAP or Active Directory.

All I’m really trying to say here, is be fully aware up front of what you are buying.  Don’t jump on the bandwagon because of the hype or because Google is the trend du jour.  It’s your email data and be wise about where you store it.

The Incredible Shrinking Machine – DAOS & Domino 8.5

If you having some difficulty justifying the upgrade to Domino 8.5, then do one thing.   Download the Domino Attachment Object Store estimator.  Run it, and then stand back.  You will be amazed at the numbers you will see. 

I’m currently running it against our archive server — which occupies a 4 TB footprint.  The tool is still running after five days (this server has several thousand files), but the numbers I’m seeing are nothing but AWESOME!  For example a 12 GB mail database will be “smooshed” to 1 GB; another example – a 5 GB mail database to 624 Mb. 

You can certainly describe Domino 8.5 and DAOS as the incredible shrinking machine.  Your SAN/Storage folks will be happy, your backup/tape folks will be happy, and you’ll be happy because you can take advantage of some of the other features like ID Vault, etc.  Be sure to check with your backup vendor to make sure they’ve got a mechanism for handling the NLO files (the objects that are removed during the DAOS process), and that the software supports ODS 51 (Domino 8.5).

So get going — run the estimator, generate the numbers and hand them to your boss!

P.S. Wouldn’t it be nice if DAOS would shrink calorie counts re: cookies, Peanut M&Ms, etc.?

Repeating Events in Notes 8.5 – new repair utility available

Check out the new utility available from Lotus Support for repairing repeating calendar events in the Notes 8.5 client.  See technote 1326680

Our users have not encountered issues with repeating events (knock on wood), but in case you have, here’s something to help you out!

We’re going to have to agree to disagree on this one…

I usually review the latest Lotus technotes once a week to keep up with fixes and such.  And today found the following 1315508. The error listed in this technote is:

    “Error connecting to server SERVER/SRV/XYZ: The server is not responding. The server may be down or you may be experiencing network problems. Contact your system administrator if this problem persists.”

Well ladies and gents, the idea that the cause of this issue is a corrupt server document just blows me right out of the water!  We have had several PMRs open about this very same issue over the past three years.  In each instance we closed the PMR because no resolution was offered after several months and there was never a suggestion of recreating a server document.  In some cases we deleted the cluster.ncf file and in other cases the issue appeared to be network related.  But never, never, never have I had someone suggest that a server document has become corrupt – especially with a later version of Domino.  Views yes – documents no.

So as I said, we’re going to have to agree to disagree on this one.

Will the real Google please stand up and other summer fun!

I haven’t posted a blog entry in some time.  As a university, we schedule many technology maintenance projects for the May through August time frame when fewer students and faculty are on campus. On my plate this summer has been the deployment of Google Apps for Education to our incoming freshmen class, the continued roll-out of Notes 8.5 to our faculty and staff, and the upgrade of several servers to Domino 8.5. 

The Google Apps for Education deployment has been an interesting experience needless to say.  Google recommends a six week time period from start to finish.  We were able to deploy two weeks early.  Thanks go to some very able programming staff here who were able to integrate the Google API and Postini directory process with our current LDAP account create process.  We continued to maintain student entries within the Domino Directory so that faculty/staff will be able to email students using Notes.

A important reminder for those who might be reading this – Google Apps for Education – is free to universities.  FREE.  And students, for the most part, LOVE Google.  Or at least Google is that system with which they are most familiar (that is my theory regarding their apparent affection for Google).  We have implemented single sign-on with the SAML API that works with our Central Authentication System or CAS-based system that we use for our portal and other web systems.  It does have a draw back.  If you use SAML, SAML does not provide password authentication to IMAP or POP.  So users must use a separate non-synchronized password for IMAP or POP access.  Google Apps for Premier customers also have access to Postini spam/antivirus reports for analyzing inbound traffic, etc.  Education customers do not receive access to that feature set.  Management of the Google account process is through APIs or the Postini directory synchronization product.  We used Postini to get a large group of users imported, but are considering moving to the Google APIs for more granular control, as we are seeing many false positives with error reports in Postini.  We have also had some issues with creating portlets that would work with our current portal (Oracle) and our future portal (Liferay) as there are limitations with the implementation of 2-legged OAuth vs. 3-legged OAuth.  When Google Support was contacted to discuss this, we received a rather ambiguous response in terms of when the technical issues would be resolved. Of course this is type of response is not unlike other software vendors.

When Google moved from being a beta to non-beta product, we did not receive notification, nor did we receive a system-wide alert about the label architecture changes that took place globally (despite having set up notification options in our Google domain).  With global web changes taking place on 10,000 web accounts, it was a bit disconcerting not to receive some warning.

On the Notes/Domino side of the house, our Notes 8.5 migration continues to roll forward with the primary issue being upgrading workstations that do not have more than 512 Mb of memory.  We have seen overall that the Notes 8.5 standard client requires 1 Gb or more on Windows XP – hands down.  From a user perspective, the users have required minimal training and continue to comment positively on features that they find useful.

I am preparing to upgrade our archive server to Domino 8.5 from Domino 7.0.3 over the next few weeks.  I’m really looking forward to implementing DAOS on this server as it is currently a disk and backup resource hog.  The disk footprint alone is 4 TB.  I have not had an opportunity to run the DAOS estimator, but I’m sure I’ll see many GBs of disk savings, and will be sure to post our results.  This server contains data going back to 1991 for some faculty! 

I hope others are enjoying some lazier days this summer! Have fun!