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.